Qualificação UFPI Irva

Universidade Federal do Piauí
Centro de Ciências da Natureza

Programa de Pós-Graduação em Ciência da Computação
MiD: Simplificando a Integração entre Sistemas
Irvayne Matheus de Sousa Ibiapina
Número de Ordem PPGCC: M001

Teresina-PI, 30 de Agosto de 2019
Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Ciência da
Computação da UFPI (área de concentração:
Sistemas de Computação), como parte dos re-
quisitos necessários para a obtenção do Título
de Mestre em Ciência da Computação.
Universidade Federal do Piauí – UFPI

Programa de Pós-Graduação em Ciência da Computação
Orientador: Pedro de Alcântara dos Santos Neto
Teresina-PI
30 de Agosto de 2019
MiD: Simplificando a Integração entre Sistemas/ Irvayne Matheus de Sousa
Ibiapina. – Teresina-PI, 30 de Agosto de 2019-
54 p. : il. (algumas color.) ; 30 cm.
Orientador: Pedro de Alcântara dos Santos Neto
Dissertação (Mestrado) – Universidade Federal do Piauí – UFPI

Programa de Pós-Graduação em Ciência da Computação, 30 de Agosto de 2019.
1. Desenvolvimento de Software. 2. Integração de Sistemas. 3. Sistemas Legados.
4. Web Service. 5. Web Scrapping. I. Pedro de Alcântara dos Santos Neto. II.
Universidade Federal do Piauí.
CDU 02:141:005.7
Dissertação de Mestrado apresentada ao

Programa de Pós-Graduação em Ciência da
Computação da UFPI (área de concentração:
Sistemas de Computação), como parte dos re-
quisitos necessários para a obtenção do Título
de Mestre em Ciência da Computação.
Trabalho aprovado. Teresina-PI, 30 de Agosto de 2019:
Pedro de Alcântara dos Santos Neto

Orientador
Thiago Carvalho de Sousa

Avaliador
Guilherme Amaral Avelino

Avaliador
Teresina-PI
30 de Agosto de 2019
Resumo
As soluções tecnológicas estão cada vez mais presentes no cotidiano dos ambientes cor-
porativos. Essas soluções auxiliam em diversas atividades que são de suma importância
para seus funcionários, clientes e parceiros. Entretanto, conforme as demandas crescem,
aumentam a complexidade das necessidades empresariais e com isso, os sistemas tecnoló-
gicos necessitam evoluir para manter o padrão de qualidade dos serviços. Nesse sentido,
a integração entre sistemas é uma alternativa para auxiliar nesse cenário evolutivo, pos-
sibilitando o compartilhamento de recursos entre sistemas diferentes, contemplando a
interoperabilidade, reduzindo as redundâncias indesejadas e eliminando os gargalos e
incompatibilidades. Para padronizar a comunicação e serviços, viabilizando a troca de
mensagens entre sistemas heterogêneos, potencializando a reutilização, e simplificando o
processo de integração entre softwares, que surgiram os Web Services. Contudo, apesar das
vantagens e benefícios, existem algumas dificuldades inerentes a realização de integração,
que são: o esforço gasto para o desenvolvimento, o processo de integração com Sistemas
Legados, os riscos associados as modificações em softwares e a integração com softwares
desenvolvido por terceiros. Por conta disso, propõe-se uma abordagem e uma ferramenta,
intitulada MiD, para contornar tais dificuldades inerentes a construção de Web Services.
O objetivo do MiD é simplifica o desenvolvimento de Web Services para integração entre
sistemas Web, possibilitando a realização da integração sem necessidade de acesso ao
código-fonte do sistema alvo, de manera não invasiva, independente da tecnologia e com
baixo custo relacionado ao desenvolvimento e manutenção. Foi realizada uma avaliação
para investigar os benefícios da utilização do MiD em um projeto real de integração. Os
resultados preliminares concluíram que, para o contexto utilizada na conjuntura avaliativa,
o MiD tem potencial para reduzir o esforço no desenvolvimento de Web Services para
integração.
Palavras-chaves: Web Services. Integração de Sistemas. Sistemas Legados.

Abstract
Technological solutions are increasingly present in everyday corporate environments. These
solutions assist in a variety of activities that are of paramount importance to your employees,
customers and partners. However, as demands grow, the complexity of business needs
increases, and as a result, technology systems need to evolve to maintain the standard
of service quality. In this sense, the integration between systems is an alternative to
help in this evolutionary scenario, enabling the sharing of resources between different
systems, contemplating interoperability, reducing unwanted redundancies and eliminating
bottlenecks and incompatibilities. To standardize communication and services, enabling the
exchange of messages between heterogeneous systems, enhancing reuse, and simplifying the
process of integration between software, which emerged Web Services. However, despite the
advantages and benefits, there are some inherent difficulties to achieve integration, which
are: the effort spent on development, the integration process with Legacy Systems, the
risks associated with software modifications and the integration with software developed by
third parties. . Because of this, we propose an approach and a tool, called MiD, to overcome
such difficulties inherent in building Web Services. MiD simplifies the development of
Web Services for integration between Web systems, enabling integration without the need
for access to target system source code and low cost development and maintenance. An
evaluation was performed to verify the advantages of using MiD in a real integration project.
Preliminary results concluded that for the context used in the assessment environment,
MiD has the potential to reduce effort in developing Web Services for integration.
Keywords: Web services. Integrations Systems. Legacy Systems.

Lista de ilustrações
Figura 1 – Regras para comunicação por Web Services (W3C, 2004). . . . . . . . . 13

Figura 2 – Representação da tag HTML no navegador. . . . . . . . . . . . . . . . 15
Figura 3 – Exemplo de como é calculado o xPath de um elemento HTML. . . . . . 16
Figura 4 – Formulário para realização do login no módulo acadêmico do SIGAA. . 17
Figura 5 – Código HTML para renderização do layout para formulário de realização
do login no módulo acadêmico do SIGAA. . . . . . . . . . . . . . . . . 17
Figura 6 – Código em Python da utilização do Selenium Web Driver na realização
do login no módulo acadêmico do SIGAA. . . . . . . . . . . . . . . . . 18
Figura 7 – Etapas da abordagem MiD. . . . . . . . . . . . . . . . . . . . . . . . . 25
Figura 8 – Fluxo de ações capturadas na Etapa 2 do MiD. . . . . . . . . . . . . . 26
Figura 9 – Fluxo processado na Etapa 3 do MiD. . . . . . . . . . . . . . . . . . . 27
Figura 10 – Fluxo processado na Etapa 3 do MiD. . . . . . . . . . . . . . . . . . . 28
Figura 11 – Página inicial do módulo MiDWeb . . . . . . . . . . . . . . . . . . . . 32
Figura 12 – Modelo de requisição e resposta HTTP utilizadas para executar deter-
minada tarefa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 13 – Sumarização do processo de captura dos logs de execução no lado cliente. 34
Figura 14 – Cadastro de sistemas na MiDWeb. . . . . . . . . . . . . . . . . . . . . 35
Figura 15 – Captura de dados no lado cliente no sistema JEMS no login. . . . . . . 36
Figura 16 – Captura de dados no lado cliente no sistema JEMS na opção de listar
todos os eventos disponíveis. . . . . . . . . . . . . . . . . . . . . . . . . 36
Figura 17 – Ferramenta POSTMAN para simulação de requisições. . . . . . . . . . 37
Figura 18 – Tempo de resposta para acessos simultâneos. . . . . . . . . . . . . . . 43
Lista de tabelas
Tabela 1 – Tags HTML e seus respectivos tipos. . . . . . . . . . . . . . . . . . . . 27

Tabela 2 – Resultado do experimento quanto a eficiência das abordagens para
integração entre sistemas. . . . . . . . . . . . . . . . . . . . . . . . . . 44
Tabela 3 – Resultado do experimento quanto a eficácia dos sistemas de integração. 45
Tabela 4 – Resultado do experimento quanto ao esforço despendido no desenvolvi-
mento de Web Service de Integração. . . . . . . . . . . . . . . . . . . . 46
Tabela 5 – Cronograma de atividades para a continuidade da pesquisa. . . . . . . 50
Lista de abreviaturas e siglas
WS Web Service
API Application Programming Interface
SOA Service-Oriented Architecture
HTML Hypertext Markup Language
REST Representational State Transfer
WSDL Web Services Description Language
XML Extensible Markup Language
JSON JavaScript Object Notation
SOAP Simple Object Access Protocol
HTTP HyperText Transfer Protocol
URL Uniform Resource Locator
URI Uniform Resource Identifier
xPath XML Path Language

Sumário
I INTRODUÇÃO 1
Contexto e Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Visão Geral da Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
II ESTADO DA ARTE 9
1 FUNDAMENTAÇÃO TEÓRICA . . . . . . . . . . . . . . . . . . . . 11
1.1 Sistema Legado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 xPath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Selenium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 19
2.1 Migração de Sistemas Legados . . . . . . . . . . . . . . . . . . . . . . 19
2.2 Integração de Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
III PROPOSTA 23
3 ABORDAGEM PROPOSTA . . . . . . . . . . . . . . . . . . . . . . 25
3.1 Mapeamento e execução das tarefas . . . . . . . . . . . . . . . . . . 25
3.2 Captura dos logs de execução . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Processamento dos logs de ações . . . . . . . . . . . . . . . . . . . . 26
3.4 Automação da execução da tarefa . . . . . . . . . . . . . . . . . . . . 28
3.5 Disponibilização da tarefa como serviço . . . . . . . . . . . . . . . . . 28
4 A FERRAMENTA MID . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1 MiDWeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 MiDScraping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 MiDWebService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 MiDChrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5 MID EM AÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
IV RESULTADOS E DISCUSSÕES 39
6 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.1 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.2 Resultados e Discussão . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.3 Ameaças à validade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 49
7.1 Desafios e Limitações . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.2 Continuidade da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.3 Publicações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Parte I
Introdução
3
Contexto e Motivação
Os ambientes corporativos modernos possuem um conjunto de soluções tecnológicas

que auxiliam em diversas atividades de negócio e que são de suma importância para
o cotidiano de seus funcionários, clientes e parceiros (RICHTER et al., 2013). Além
disso, essas soluções representam ativos que auxiliam em diversos processos presente no
cotidiano operacional. Contudo, conforme as demandas crescem, aumenta a complexidade
das necessidades empresariais e com isso, os sistemas tecnológicos necessitam evoluir e
assim manter o padrão de qualidade dos serviços e tornar os processos e gestão de recursos
mais eficientes (MENS et al., 2005; VOGEL-HEUSER et al., 2015; VELD; KROGSTIE,
2019).
Visando melhorar seus processos de negócios, as empresas tendem a aumentar
cada vez mais o suporte ao seu ecossistema de software, que pode ser constituído por
softwares desenvolvidos internamente ou adquiridos por terceiros (MANIKAS, 2016). O
resultado disso é um ecossistema de software heterogêneo, no qual os aplicativos devem
trabalhar juntos e colaborar, trocando dados e compartilhando funcionalidades para
suportar um processo de negócios(MENDICINO; WODTKE, 2010; GROSSE-RHODE,
2013). No entanto, nem todos os aplicativos são projetados e dotados de recursos que
possibilitam a colaboração (FREIRE; FRANTZ; ROOS-FRANTZ, 2019).
Nesse sentido, a integração entre sistemas é uma alternativa para auxiliar nesse
cenário evolutivo que ocorre em muitos ambientes corporativos (FOSTER, 2002). As
empresas que são capazes de integrar seus diversos sistemas têm uma vantagem competitiva
em relação as que não possuem essa característica, como a utilização estratégica dos dados
e da tecnologia da empresa para maior eficiência e lucro (LINTHICUM, 2000; FOSTER,
2002; HENNINGSSON; KETTINGER, 2016). Dificilmente, em ambientes corporativos
complexos, os softwares operam como entidades independentes sem ter um efeito negativo
na eficiência dos processos e negócios empresariais (SZEPIELAK, 2006). Portanto, a
integração entre sistemas de informação é um desafio frequente em ambientes corporativos
(MENS et al., 2005).
A integração entre sistemas possibilita uma melhoria na eficiência organizacional
fornecendo soluções para problemas reais (LINTHICUM, 2000; PRENCIPE; DAVIES;
HOBDAY, 2003). No entanto, as integrações devem ser realizadas de maneira adequada
ou então podem tornar um ponto de desperdício de dinheiro e esforço para as corporações.
Quando analisado da perspectiva ideal, uma integração eficiente cria vantagens competitivas
significativa, simplificando inúmeros processos críticos, otimizando tarefas imprescindíveis
para o progresso organizacional, reduzindo os riscos de erros provenientes da atividade
manual, dentre outras (HENNINGSSON; KETTINGER, 2016).
O objetivo da integração entre softwares é possibilitar o compartilhamento de
4 Introdução
recursos, seja ele dados ou funcionalidades, entre softwares díspares (HENNINGSSON;

KETTINGER, 2016). O conceito de integração contempla a interoperabilidade entre
sistemas no sentido em que eles são colocados a comunicar e interagir, independentemente
das suas características. Além disso, a integração de sistemas possibilita a que as fontes
de dados, aplicativos e fluxos de negócios sejam integrados ao mesmo ambiente de modo
que as redundâncias indesejadas sejam reduzidas e os gargalos e incompatibilidades sejam
eliminados (VINOSKI, 2003; PENG; LI, 2016).
Nesse cenário, os Web Services nasceram com o objetivo de solucionar ou pelo menos
simplificar o problema de integração entre sistemas de software (GUSTAVO et al., 2004). O
poder da tecnologia Web Service reside no fato de que ela estabelece uma plataforma comum
para integrar sistemas distribuídos em intranets e na internet em geral (GUSTAVO et al.,
2004; MENG; MEI; YAN, 2009). Com o Web Service foi possível padronizar a comunicação
com protocolos e serviços, viabilizando uma computação orientada a componentes, em
ambientes distribuídos e heterogêneo (GUSTAVO et al., 2004; ROMAN et al., 2005;
MENG; MEI; YAN, 2009). As principais vantagens dos Web Services são a possibilidade de
reutilização, redução na redundância de funcionalidades e redução no custo de manutenção.
Entretanto, apesar de todas as vantagens e benefícios, existem alguns desafios
relacionados a realização de integração entre softwares. Esses desafios têm motivado a
realização de diversas pesquisas relacionadas ao desenvolvimento de métodos, abordagens
e ferramentas para auxiliar nas atividades de integração (UPADHYAYA; KHOMH; ZOU,
2012; UPADHYAYA; ZOU; KHOMH, 2015). Essas dificuldades são descritas na próxima
seção, na qual define-se o problema alvo do trabalho.
Definição do Problema
Existem alguns problemas que dificultam a realização da integração entre softwares.
Muitos ambientes corporativos ainda se deparam com essas dificuldades, e assim, têm seus
processos operacionais prejudicados. As dificuldades elencadas são as seguintes:
• Esforço gasto para desenvolvimento (d1): muitas organizações se deparam com

situações em que existe uma certa demanda de integração para ser realizada, porém
os orçamentos estão restritos e os recursos são limitados. Com isso, a abordagem
tradicional que consiste em desenvolver um Web Service de forma manual, com auxilio
de API, continuam com todos os desafios normais relacionados ao desenvolvimento
de software, como o desenho técnico, codificação e teste. Nesse sentido, esse processo
necessita de esforço de desenvolvimento que consome muitos recursos e tempo.
• Integração com sistemas legados (d2): normalmente as organizações possuem

sistemas diferentes desenvolvidos há décadas, no qual ainda são indispensáveis às
5
organizações dando suporte a um conjunto de funcionalidades imprescindíveis no

qual necessitam de modernização. Esses sistemas são denominados na literatura como
Sistemas Legados (BENNETT, 1995; PRESSMAN ROGER S, 2014). Entretanto,
devido a tecnologia utilizada nesses sistemas estarem obsoletas, existe uma certa
dificuldade em encontrar mão de obra qualificada para modificar tais sistemas. Além
disso, em muitos casos, esses sistemas possuem uma documentação bem imatura,
uma arquitetura pouco extensível, e muitas dívidas técnicas.
• Riscos associados a modificação em softwares (d3): a integração tradicional

de sistemas depende do total controle do software, e com isso poder modificá-lo
internamente. Isso geralmente resulta em custos significativos, já que a maioria dos
projetos de integração de sistemas representam esforços de desenvolvimento muito
grandes usando pessoal altamente qualificado. Inerente a esses projetos maiores,
existe um alto risco de atraso e um possível impacto na infraestrutura geral da
organização.
• Utilização de softwares desenvolvido por terceiros (d4): quando as organiza-

ções utilizam sistemas desenvolvidos por terceiros e não possuem acesso os códigos, as
modificações para integração realizadas pelos métodos tradicionais não são possíveis.
Mesmo quando um parceiro ou cliente está disposto a disponibilizar o código dos
seus sistemas, a capacidade de integração pode ser impraticável. Como resultado,
a maioria dos projetos críticos de negócios que exigem integração com aplicativos
externos é extremamente difícil na melhor das hipóteses, impossível na pior das
hipóteses. Para a maioria das organizações, isso pode se traduzir diretamente em
oportunidades de negócios perdidas e no aumento dos custos operacionais.
Essas dificuldades são encontradas em muitas empresas de software. Para exemplifi-

car, vamos supor a seguinte situação: uma empresa de desenvolvimento de software utiliza
sistemas desenvolvidos há décadas por outra empresa, além de ter uma equipe bastante
sobrecarregada com outras demandas de suporte e sustentação. Com isso, necessita-se
realizar a integração entre os sistemas internos, contudo a empresa deverá superar a
dificuldade {d2, d3}, relacionados ao sistema legado e software desenvolvido por terceiros.
Além disso, mesmo que a equipe tivesse acesso ao projeto e tenha mão de obra qualificada
para alterar o projeto, ainda assim as dificuldades {d1, d4} devem ser enfrentadas.
De acordo com os dificuldades pautadas, definimos formalmente o problema: dado
o conjunto de dificuldades {d1, d2, d3, d4}, definir uma solução capaz de contornar tais
desafios relacionados ao desenvolvimento de sistemas para integração entre softwares,
considerando o contexto real comum em muitos ambientes corporativos. A seguir é
apresentada a visão geral da proposta para resolver esse problema.
6 Introdução
Visão Geral da Proposta

O objetivo deste trabalho é simplificar a construção de Web Services para integração
entre sistemas. A proposta é tornar possível a integração sem a necessidade de conhecimento
em linguagem de programação, acesso ao código-fonte do sistema alvo para integração,
com a capacidade de alertar falhas nos pontos de integração para facilitar as correções e
com baixo custo relacionado ao desenvolvimento e manutenção. Além disso, pretende-se
possibilitar a integração entre softwares algo prático, que demanda pouco esforço, se
comparado com o desenvolvimento manual de Web Services.
Por conta disso, foi proposta inicialmente uma abordagem para viabilizar a im-
plementação de uma solução que atenda os requisitos necessários para tornar o processo
de desenvolvimento de Web Services para integração algo simples e prático. Também
foi utilizado como norteador da proposta, a capacidade de a solução superar os desafios
relacionados ao processo de integração entre softwares apresentados anteriormente.
Depois que a abordagem foi concebida, desenvolveu-se uma ferramenta Web para
possibilitar que a abordagem pudesse ser utilizada por desenvolvedores em projetos reais.
A avaliação preliminar realizada apontou que a abordagem e a ferramenta proposta no
âmbito deste trabalho obteve bom indicadores de desempenho em alguns cenários, e com
isso, viabilizou-se sua utilização no contexto real de desenvolvimento de software. Ambas,
abordagem e ferramenta, representam juntas a principal contribuição deste trabalho e
foram intituladas de MiD. Esse nome foi escolhido por representar uma palavra de fácil
memorização e que em algumas situações pode ser traduzido para o português como meio,
entre e médio, que no caso representa bem nosso objetivo, que é criar uma camada entre
os sistemas para integrá-los.
Objetivos
O principal objetivo deste trabalho é simplificar a integração entre softwares,
reduzindo o esforço e tempo gasto nessas atividades, sem depender da tecnologia utilizada
nesses sistemas, de forma acessível, eficaz e não invasiva. Vale ressaltar que esse objetivo
foi definido com o intuito de mitigar as dificuldades apresentadas na Seção de Definição
do Problema.
Para alcançar o objetivo principal, foram definidos os seguintes objetivos específicos:
1. Especificar uma abordagem que possibilite o desenvolvimento de Web Services sem

a necessidade de modificar o sistema alvo para integração. A abordagem deve conter
algumas características como: simplicidade, escalabilidade e alta coesão;
2. Desenvolver uma ferramenta Web para implementar a abordagem proposta, bem

7
como disponibilizá-lo utilização em um ambiente real. A ferramenta encontra-se

disponível em: <https://mid-integrations.herokuapp.com/>;
3. Realizar uma avaliação para avaliar o uso da abordagem em cenários reais, explorando
as singularidades de projetos envolvendo sistemas em produção, explorando as
questões ligadas a eficiência, eficácia e esforço necessário para utilizá-la.
Justificativa
O objetivo deste trabalho é apresentar uma nova solução para facilitar a realização
da integração entre sistemas. Para isso, propõe-se uma abordagem e uma ferramenta,
denominada MiD, que possibilita desenvolver Web Services a partir de outro sistema, no
qual não necessita modificá-lo ou acessá-lo internamente para realizar o processo integração.
Inicialmente, percebeu-se empiricamente que muitas empresas de desenvolvimento
de software possuíam a necessidade de integrar seus sistemas, porém não tinham como
realizar essa atividade porque seus desenvolvedores estavam ocupados com outras tarefas.
Com isso, elaborou-se um mecanismo que simplifica o processo de construção de Web
Services para integração, possibilitando apenas a necessidade de conhecimento na funci-
onalidade que desejasse integrar para realizar a construção desse Web Service, e assim
tornar o processo algo mais rápido e menos custo.
Outra situação que muitas empresas corriqueiramente se deparam é com a utilização
de sistemas desenvolvido por terceiros, no qual em muitos casos o acesso ao código-fonte
desse sistema é impossível, e mesmo quando o acesso é disponível, ele utiliza tecnologias
obsoletas que são de difícil manutenção. Para isso, decidiu-se realizar o processo de
engenharia reversa no lado cliente da aplicação (LUCCA et al., 2002), e assim tornar
a criação de pontos de integração algo não invasivo. Nesse sentido, a complexidade da
funcionalidade é abstraída e a tarefa é considerada uma caixa-preta na qual a sua estrutura
interna é desconhecida, limitando-se assim apenas as entradas e saídas.
Por fim, é importante destacar que o MiD não visa substituir o desenvolvimento
manual de Web Services para integração. Nossa abordagem e ferramenta busca disponibili-
zar uma nova alternativa para a construção de pontos de integração por serviço. O MiD é
recomendado em situações na qual o desenvolvimento de Web Services para integração
entre softwares de maneira manual não é possível ou bastante custoso.
Contribuições
Destaca-se como principal contribuição deste trabalho a proposta de uma abordagem
capaz de simplificar o desenvolvimento de Web Services para utilização no processo de
integração entre softwares. Entretanto, existem outras contribuições, citadas a seguir:
8 Introdução
• O desenvolvimento de uma ferramenta que implementa a abordagem especificada

neste trabalho. O MiD está disponível na Web e funciona independente da plataforma,
por meio de um navegador;
• Uma avaliação preliminar utilizando o MiD em um projeto real. Essa avaliação

ocorreu com o objetivo de analisar o desempenho da abordagem em comparação
com o método tradicional de desenvolvimento, que consiste em utilizar API de forma
manual.
Estrutura do Trabalho
Este trabalho está divido em cinco capítulos e a introdução, que aborda o contexto
do trabalho, sua motivação, a definição do problema, a visão geral da proposta, os objetivos
gerais e específicos, a justificativa, além do relato das principais contribuições e desta
seção, com a estruturação do trabalho.
O Capítulo 1 apresenta os conceitos fundamentais sobre técnicas e componentes
utilizados neste trabalho.
O Capítulo 2 discute os trabalhos relacionados identificados.
No Capítulo 3 é detalhada a abordagem proposta neste trabalho, bem como a
ferramenta Web desenvolvida e sua utilização em uma contexto real.
O Capítulo 6 apresenta uma avaliação da abordagem MiD em um projeto real de
integração entres softwares.
Por fim, o Capítulo 7 apresenta as considerações finais deste trabalho, assim como
desafios, limitações, e as perspectivas para continuação da pesquisa.
Parte II
Estado da Arte
11
1 Fundamentação Teórica
Este capítulo apresenta os principais conceitos relacionados ao trabalho. Primei-

ramente, apresenta-se a definição de sistemas legados utilizada pelo trabalho, bem como
as propriedades necessárias para caracterizar um sistema como legado. Além disso, é
apresentado os tipos de técnicas para modernização desses sistemas, no qual inspiraram
em algumas escolhas em nossa abordagem.
Em seguida são apresentados os conceitos sobre Web Service e REST, uma vez que
a compreensão desses tópicos é de suma importância para o entendimento da abordagem
proposta. Por fim, são apresentados conceitos de HTML, xPath e Selenium, pois são
conceitos que estão atrelados ao funcionamento técnico da ferramenta que implementa a
abordagem.
1.1 Sistema Legado

Existem muitos softwares que se tornaram obsoletos, porém ainda são indispensáveis
às organizações, uma vez que dão suporte a um conjunto de funcionalidades vitais ao negócio
(ALMONAIES; CORDY; DEAN, 2010). Esses sistemas são denominados na literatura
como Sistemas Legados (BENNETT, 1995; PRESSMAN ROGER S, 2014). Geralmente
esses sistemas foram desenvolvidos há anos, ou mesmo décadas, com a característica
arquitetural monolítica e que sofreram adaptações ao longo dos anos para atender as
necessidades das organizações (PRESSMAN ROGER S, 2014).
Um sistema pode ser classificado como legado quando ele é um sistema antigo,
frequentemente mal projetado ou documentado, com uma tecnologia obsoleta, porém é de
fundamental importância para o funcionamento dos ambientes empresariais (PRESSMAN
ROGER S, 2014). Além disso, esses sistemas possuem uma baixa qualidade técnica,
apresentando problemas como deficiência arquitetural, uso de tecnologias depreciadas e
alta complexidade de manutenção (KHADKA et al., 2013).
Enquanto um sistema legado atende as necessidades do negócio, não existe necessa-
riamente um problema com todas essas características negativas comentadas anteriormente.
No entanto, com o passar do tempo esses sistemas necessitam evoluir devido a uma ou
mais razões a seguir:
• O software deve ser adaptado para atender às necessidades de novos ambientes ou

de novas tecnologias computacionais;
• O software deve ser aperfeiçoado para implementar novos requisitos de negócio;

12 Capítulo 1. Fundamentação Teórica
• O software deve ser expandido para torná-lo capaz de integrá-lo com outros sistemas
mais modernos;
• O software deve ser reprojetado para torná-lo viável dentro de um ambiente compu-
tacional em evolução.
Uma alternativa para contornar tais problemas associado aos riscos contidos na
utilização de sistemas legados é realizar o processo de modernização (KHADKA et al.,
2014). A modernização envolve mudanças mais acentuadas que as tarefas de manutenção
habitual, conservando uma porção significante do sistema em uso (COMELLA-DORDA et
al., 2000). Essas mudanças geralmente incluem à sua reestruturação, melhorias funcionais
e adição de novos atributos.
As modernizações podem ser divididas em dois grandes grupos: Direta e Indireta
(SALVATIERRA et al., 2013). O primeiro tipo consiste em encapsular uma funcionalidade
legada, analisando as entradas e saídas, baseada nas técnicas de Wrapping, seguindo o
estilo Black-Box ou Caixa Preta (SALVATIERRA et al., 2013; COMELLA-DORDA et
al., 2000). Já o segundo tipo realiza uma engenharia reversa da funcionalidade legada,
para após realizar uma analise do código, e então extrair informações juntamente com
a tentativa de compreensão do código, seguindo o estilo White-Box ou Caixa-Branca
(SALVATIERRA et al., 2013; COMELLA-DORDA et al., 2000).
1.2 Web Service

Um Web Service pode ser definido como um software desenvolvido para suportar
a interação com outros sistemas pela Web (W3C, 2004). Em outras palavras, o Web
Service consiste em um software que suporta a interação interoperável máquina-a-máquina
sobre uma rede (W3C, 2004). As suas vantagens e oportunidades, que surgiram a partir
das Arquiteturas Orientadas a Serviços, do inglês Service Oriented Architecture (SOA),
proporcionaram a popularidade dos Web Services (NEWCOMER; LOMOW, 2005). É
importante salientar que existe diferença entre uma Arquitetura Orientada a Serviços e um
Web Service. Uma Arquitetura Orientada a Serviços é uma maneira lógica de construção
de sistemas para prover serviços. Já um Web Service é uma implementação de um SOA
(ERRADI; MAHESHWARI, 2005).
Na Figura 1 é apresentada o modelo de Web Service proposto pela W3C. Os
principais passos desse modelo de serviço são:
1. Entidades Requester e Provider se conhecem (ou ao menos um conhece o outro);
2. Ambos concordam com a descrição do serviço e a semântica que norteará a interação

entre eles;
1.2. Web Service 13
Figura 1 – Regras para comunicação por Web Services (W3C, 2004).
3. A descrição do serviço e a semântica são compreendidas pelos agentes Requester e

Provider;
4. Agentes Requester e Provider trocam mensagens, realizando assim tarefas em nome

de suas respectivas entidades.
Web Services facilitam a integração entre sistemas, além de padronizar a comunica-

ção com protocolos e serviços, viabilizando uma computação orientada a serviços, baseada
em componentes, em ambientes distribuídos e heterogêneos. As principais vantagens dos
Web Services são a possibilidade de reutilização, redução na redundância de funcionalidades
e redução no custo de manutenção. É recomendável que os Web Services possuam as
seguintes características (ERL, 2016): contratos padronizados, baixo acoplamento, abs-
tração, reuso, autonomia, independência de estado, visibilidade do serviço e facilidade de
composição.
Podemos destacar dois tipos distintos de Web Service: os que utilizam o protocolo
SOAP e os que utilizam dos serviços REST. Os Web Services baseados no protocolo SOAP
(Simple Object Acess Protocol) são descritos por meio do WSDL (Web Service Description
Language), que é um contrato de uso daquele serviço. As mensagens SOAP trafegadas
utilizam o formato XML e são transmitidas pelo protocolo HTTP (CURBERA et al.,
2002). Os sistemas que utilizam este tipo de serviços precisam seguir as especificações
disponibilizadas no WSDL. Devido a falta de flexibilidade dos serviços SOAP, posterior-
mente em (FIELDING; TAYLOR, 2000), foi o criado paradigma REST (Representational
State Transfer), que visa diminuir a dependência da especificação imposta pelo WSDL.
Na próxima subseção é apresentado o serviço REST detalhadamente.
1.3 REST
O Representational State Transfer (REST) é uma abstração dos princípios da
World Wide Web que tem como ênfase a escalabilidade das aplicações, segurança e baixo
acoplamento (FIELDING; TAYLOR, 2000). No REST os serviços são identificados pela
Uniform Resource Identifier (URI). Um serviço utilizando REST utiliza o protocolo HTTP
e seus métodos: PUT, POST, GET, DELETE. É importante salientar que o REST é um
paradigma arquitetônico para desenvolvimento que Web Services, enquanto que o RESTful
é a utilização desse paradigma.
As implementações de serviço RESTful utilizam o protocolo HTTP como protocolo
intrínseco (RICHARDSON; RUBY, 2008). Em geral, os serviços RESTful possuem as
seguintes características e propriedades:
• Representação: o foco dos serviços RESTful está nos recursos e em como prover
acesso a esses recursos. Usualmente o acesso é provido por meio de JSON ou XML;
• Mensagem: a comunicação entre clientes e servidores ocorrem por meio de mensagens.

O cliente realiza uma requisição e o servidor processa e retorna a resposta. Toda
essa comunicação ocorre com o suporte do protocolo HTTP;
• URIs: cada recurso deve ser identificável, portanto deve possuir uma URI como
identificador. As operações que podem ser realizadas nesses recursos são determinadas
pelos métodos HTTP;
• Stateless: os serviços RESTful não mantém estado da aplicação cliente. Com isso,
cada requisição é tratada de forma independente.
Existem muitas dúvidas em relação as vantagens e desvantagens da utilização

do REST em contraponto com o SOAP. Contudo, ambos os modelos possuem suas
características, e a escolha vai depender dos requisitos de cada situação específica. Segundo
Mumbaikar, Padiya et al. (2013), os Web Services RESTful produzem um menor tráfego
de rede, baixa latência e com tamanho de mensagens menor que o SOAP, além de ter
um melhor desempenho com na comunicação com rede sem fio, sendo leve, fácil, auto
descritivo, maior flexibilidade e menor sobrecarga.
1.4 HTML
As aplicações Web são sistemas que utilizam da arquitetura da Internet para troca
de informações e serviços. Muitas aplicações Web possuem como clientes navegadores Web,
que são os responsáveis por renderizar o conteúdo de uma página Web. Além disso, a
comunicação entre as aplicações (clientes e servidores) ocorre por meio do protocolo HTTP.
1.4. HTML 15
Em aplicações Web, cada página Web tem seu layout definido pela linguagem de marcação
HTML.
O HTML (HyperText Markup Language) é uma linguagem de marcação utilizada
para estruturar e representar conteúdo sob a forma de uma página Web (COOK; SCHULTZ,
2007). Neste caso em particular, o HTML5 é a interação mais recente da linguagem HTML,
que sofreu muitas das modificações necessárias para suprir às necessidades atuais do mundo
Web (HOY, 2011).
Para estruturar um layout com HTML é necessário a utilização de tags. As tags
são marcações que informam ao navegador sobre que tipo de informação se trata. Por
exemplo, existem tags para especificar um parágrafo, uma lista, um botão, etc. Tudo que
é enxergado em uma página Web é inserido por meio de tags. Na Figura 2 é apresentado
um exemplo da representação de uma tag no navegador.
Figura 2 – Representação da tag HTML no navegador.
O propósito do navegador Web é de interpretar o HTML recebido do servidor e

de renderizar a tela conforme as informações que esse documento HTML possui. Como
pode-se constatar na Figura 2, o navegador não exibe as tags HTML, mas utiliza-as
para interpretar e formatar o conteúdo da página. No exemplo da Figura 2, o navegador
identificou a tag ‘<b>’ e apresentou o conteúdo em negrito.
Existe algumas especificações para a tags HTML, em que algumas são exemplificadas
a seguir:
• As tags são compostas por palavras-chave entre os caracteres ‘<’ e ‘>’, como por
exemplo a tag <html>;
• As tags HTML estão normalmente presentes em pares (tag de abertura e tag de

fechamento), como <b> e </b>;
• A tag de fechamento é escrita praticamente da mesma forma que a tag de abertura,

com uma particularidade que é a barra lateral antes do inicio do nome da tag, como
</b>;
• As tags podem conter atributos, como por exemplo a tag <a> que é composta pelo
atributo href que contém uma hiperligação: <a href=”google.com”>Google</a>.
1.5 xPath
A linguagem HTML é composta por tags que são rótulos usados para informar ao
navegador como deve ser o layout da página Web. Cada objeto de uma página Web rotulada
por tags podem ser identificadas por meio da linguagem de consulta xPath (CLARK;
DEROSE et al., 1999). Esse identificador pode ser utilizado para navegar por elementos
e atributos em documentos XML e HTML (CAVALIERI; GUERRINI; MESITI, 2012).
Devido as páginas Web serem estruturadas como uma árvore hierárquica de objetos HTML,
representado por tags, torna-se possível utilizar o xPath como artifício para identificar
cada elemento de forma única (FURCHE et al., 2011).
Figura 3 – Exemplo de como é calculado o xPath de um elemento HTML.
Na Figura 3 é apresentado um exemplo de como é realizado o processo de iden-

tificação de um elemento HTML pelo seu xPath. É verificado a hierarquia de elementos,
e assim é possível, por meio da linguagem de consulta xPath, localizar um ponto es-
pecífico do documento HTML. No exemplo da Figura 3, o xPath do elemento da tag
‘<a>’ é composto pelos elementos ancestrais aninhados a ele, gerando o xPath: ‘hea-
der/nav/ul/li[2]/div/nav/div/ul/li/a’.
1.6. Selenium 17
1.6 Selenium
Selenium 1 é um framework composto de ferramentas usadas para testar aplicações
Web sendo utilizado por muitos projetos industriais (COLLINS; LUCENA, 2012; HAUG-
SET; HANSSEN, 2008). Dentre esse conjunto de ferramentas disponíveis pelo Selenium,
destaca-se a ferramenta Selenium Web Driver 2 . Essa ferramenta disponibiliza uma interface
de programação bastante abrangente para controlar um navegador. O Selenium Web Driver
foi desenvolvido para oferecer suporte a páginas da Web dinâmicas em que os elementos
de uma página podem ser alterados sem que a própria página seja recarregada.
O Selenium disponibiliza diversas formas para localizar um elemento em uma
página Web. Essa localização pode ser realizada pelo ID, Class name, Tag Name, Name,
Link Text, Partial Link Text, CSS e xPath. Entre todas essas alternativas disponibilizadas
para localização dos elementos, de acordo com o Selenium Web Driver Developers 3 , a
maneira mais eficiente é a utilizando o ID. Entretanto, em muitos casos o atributo ID não
é inserido nas tags HTML, e com isso, localizar o elemento utilizando xPath torna-se a
alternativa mais viável e eficaz.
Figura 4 – Formulário para realização do login no módulo acadêmico do SIGAA.
Figura 5 – Código HTML para renderização do layout para formulário de realização do

login no módulo acadêmico do SIGAA.
Nas Figuras 4, 5 e 6 são apresentadas, respectivamente, o formulário, o código-fonte

HTML e o script em python, para realizar a funcionalidade de login no módulo acadêmico
do SIGAA4 , que é o sistema de gestão acadêmica utilizado na UFPI. Uma vez que as tags
HTML utilizadas não possuem o atributo ID (Figura 5), fez-se necessário realizar a busca
pelo elementos por meio do seu xPath (Figura 6).
1
<http://seleniumhq.org/>
2
<http://seleniumhq.org/projects/webdriver/>
3
<https://www.seleniumhq.org/docs/03_webdriver.jsp>
4
<https://sigaa.ufpi.br/sigaa/public/home.jsf>
Figura 6 – Código em Python da utilização do Selenium Web Driver na realização do

login no módulo acadêmico do SIGAA.
1.7 Considerações Finais

Este capítulo apresentou os principais conceitos utilizados neste trabalho. Inicial-
mente foram apresentados os conceitos relacionados a parte teórica do trabalho, como
Sistemas Legados, Web Service e HTML. Posteriormente foram apresentadas as definições
e exemplos que são utilizadas na implementação da abordagem, como REST, xPath e
Selenium.
19
2 Trabalhos Relacionados
Neste capítulo são apresentados alguns trabalhos relacionados a pesquisa. Inici-

almente é apresentada uma revisão sistemática da literatura relacionada a migração de
sistemas legados para uma Arquitetura Orientada a Serviços. Além disso, é descrito um
estudo que propõe uma extração de tarefas para serviços Web análogo ao objetivo deste
trabalho.
2.1 Migração de Sistemas Legados

Existem alguns estudos na literatura que visam propor técnicas para migração de
sistemas para uma Arquitetura Orientada a Serviços, e assim possibilitar a integração e
facilitar a troca de informação entre sistemas. Por conta da necessidade de sistematizar e
identificar lacunas dessa área de pesquisa, foi realizado uma revisão sistemática de estudos
(ROCHIMAH; SANKOH, 2016). Foram buscados artigos entre os anos de 2005 e 2015 e
foram identificados 17 trabalhos. Essa revisão sistemática classificou os artigos de acordo
com a natureza de seus métodos, em 2 tipos. O primeiro tipo visa analisar passo a passo o
código-fonte de um sistema legado, para então reescreve-lo, porém, utilizando os princípios
da Arquitetura Orientada a Serviços. O segundo tipo consiste em realizar o processo
de wrapping, que pode ser caracterizado como um encapsulamento ou reaproveitamento
do código-fonte. Esse reaproveitamento consiste em encapsular as funções e instruções
existentes, porém reestruturando o software para adequar a uma nova arquitetura, que no
caso é a Arquitetura Orientada a Serviços.
Existem algumas vantagens e desvantagens associadas a cada um dos métodos
descritos. No primeiro método descrito anteriormente, a principal vantagem é que todo
o processo de migração é bem estruturado e sua desvantagem é o esforço necessário
para executar o processo e obter os melhores resultados. Já para o método wrapping, a
sua vantagem é obter resultados rápidos, se comparado com o primeiro método, e sua
desvantagem é que seus resultados são altamente dependentes dos seus algoritmos de
encapsulamento.
Nosso trabalho difere dos artigos identificados na revisão sistemática realizada
por Rochimah e Sankoh (2016), pelo fato de não necessitar de acesso ao código-fonte.
Os métodos identificados nos trabalhos relacionados realizam o processo de migração da
aplicação Web para uma nova arquitetura ou precisam reprojetar/reescrever o código-
fonte dos sistemas. Além disso, na abordagem proposta neste trabalho, consideramos o
funcionamento interno das aplicações Web como uma caixa-preta, apenas realizando a
intermediação entre os sistemas.
20 Capítulo 2. Trabalhos Relacionados
2.2 Integração de Sistemas

Em (UPADHYAYA; ZOU; KHOMH, 2015) os autores apresentam uma melhoria da
abordagem proposta em (UPADHYAYA; KHOMH; ZOU, 2012). O objetivo do trabalho é
identificar e extrair semi-automaticamente possíveis tarefas reutilizáveis e assim representar
tais tarefas como serviço. Nessa abordagem, as tarefas extraídas podem ser especificadas
em termo de serviços RESTful e implementadas por proxies que acessam os servidores
Web e analisam suas respostas.
Para avaliar a abordagem proposta, Upadhyaya, Zou e Khomh (2015) realizou uma
analise em 21 aplicações Web. O objetivo da avaliação consistiu em verificar a precisão e o
recall da abordagem na identificação de tarefas corretamente. Os resultados apontaram
que a abordagem atingiu uma precisão de 89% e um recall de mais de 90% em identificar
as tarefas corretamente. Para o objetivo de identificar as relações entre as tarefas, a
abordagem obteve uma precisão de 86% e um recall de 100%.
Diferentemente do trabalho proposto por Upadhyaya, Zou e Khomh (2015), nosso
trabalho realiza uma análise de performance para se observar o comportamento da aborda-
gem no contexto da eficiência, que consiste no tempo de resposta para acessos simultâneos,
na eficácia, que representa a corretude das requisições e respostas, e no esforço gasto para
o desenvolvimento.
Outra diferença relevante entre nossa pesquisa em relação ao trabalho do Upadhyaya,
Zou e Khomh (2015) é que estamos aplicando em um ambiente real, em que a integração
é parte do processo de trabalho da empresa. Isso, além de exigir um nível de maturidade
para a solução, exige a resolução de diversos problemas que somente são percebidos ao
se utilizar em um ambiente real de produção, com todas as suas singularidades. Isso
possibilitou uma evolução na ferramenta MiD, no qual apenas aplicando em uma ambiente
controlado ou no campo da teoria, não são possível de detectar. Além disso, os autores do
trabalho (UPADHYAYA; KHOMH; ZOU, 2012; UPADHYAYA; ZOU; KHOMH, 2015) não
disponibilizaram uma ferramenta para a comunidade científica, e com isso, impossibilitaram
a realização de testes comparativos.
2.3 Considerações Finais

Este capítulo apresentou alguns trabalhos relacionados ao tema desta pesquisa.
Inicialmente, foram apresentadas uma revisão sistemática da literatura relacionada a
migração de sistemas legados no qual foi possível identificar o estado da arte desse tema
e suas lacunas e oportunidades de pesquisa. Posteriormente, foram apresentados dois
trabalhos que descrevem uma abordagem para construção de Web Services a partir de
tarefas realizadas por aplicações Web e assim inspiraram em alguns escolhas para nossa
2.3. Considerações Finais 21
pesquisa.
Parte III
Proposta
25
3 Abordagem Proposta
Neste capítulo é apresentada a abordagem MiD. Na Figura 7 é descrita um resumo

da abordagem proposta. Nela são apresentadas as etapas, bem como seus relacionamentos.
A primeira etapa consiste em mapear e executar a tarefa que pretende-se integrar como
serviço. Concomitantemente com a etapa de execução da tarefa, ocorre a etapa de captura
dos logs de ação. Após a captura, é realizado o processamento dos metadados obtidos.
Por fim, ocorrem as etapas de automação da execução e disponibilização da tarefa como
serviço. Cada etapa será descrita detalhadamente nas próximas seções.
Figura 7 – Etapas da abordagem MiD.
3.1 Mapeamento e execução das tarefas

A primeira etapa da abordagem proposta neste trabalho consiste em mapear e
executar uma determinada tarefa que se pretende disponibilizar como serviço Web. É
importante salientar que essa tarefa deve ter como característica a reutilização, uma vez
que o objetivo do serviço Web é disponibilizar os recursos para outros sistemas usuários,
integrando-os por meio da internet.
Uma tarefa é um conjunto de interações de recursos agrupadas de maneira signifi-
cativa para atingir uma meta. A identificação de uma tarefa é essencialmente centrada na
pergunta: O que um usuário fará para alcançar a meta na funcionalidade de um sistema
web? Uma tarefa é um curso de ações que um usuário executa em um aplicativo da web.
Um exemplo prático de tarefa é a consulta do histórico de notas em um portal acadêmico,
ou a realização de uma compra em um site de e-commerce.
Inicialmente, deve ser realizado um levantamento que consiste em definir qual
tarefa de uma funcionalidade será mapeada, identificando os insumos (entradas e saídas)
necessários para sua realização, bem como a url inicial para o acesso da tarefa. Por
exemplo, dado uma tarefa de consultar saldo da conta bancária, as possíveis entradas
para a realização dessa tarefa são o número da agencia, número da conta e a senha, e
a url inicial para acessar essa tarefa é: www.meubanco.com/saldo. Essas são as possíveis
informações necessárias para a execução completa da tarefa de consultar saldo bancário.
26 Capítulo 3. Abordagem Proposta
Para dar inicio a execução, deve ser iniciado a etapa de captura dos logs de execução
no qual as ações realizadas pelo usuário durante a tarefa são capturadas. A execução
consiste em preencher campos de entrada de dados, manipular componentes na página
Web, clicar em botões, selecionar elementos dentre uma infinidade de outras ações que tem
como objetivo final a conclusão de uma determinada atividade.
3.2 Captura dos logs de execução

A etapa de captura dos logs de execução, que ocorre paralelamente com a execução
da tarefa, após o usuário iniciar o processo de captura, alguns metadados gerados durante
a execução da tarefa. Os metadados capturados são o xPath de cada elemento HTML
das páginas Web manipulados durante a execução e a ordem cronológica em que cada
elemento foi manipulado pelo usuário. É importante frisar que as informações inseridas
nos campos de formulários e inputs não são capturadas, uma vez que, dependendo do
campo de entrada, isso infringe a privacidade e a segurança dos dados, como por exemplo,
em locais para senha.
Figura 8 – Fluxo de ações capturadas na Etapa 2 do MiD.
No final do processo de captura, os identificadores dos elementos manipulados pelo

usuário (xPath) e a sequencia no qual esses elementos foram manipulados, são armazenados
para um posterior processamento. Além disso, todo processo de captura ocorre de maneira
não invasiva, que não necessita de mudanças nos sistemas alvos, bem como possibilita que
o todo o processo seja prático, intuitivo e pouco burocrático. Na Figura 8 é apresentado
um exemplo do fluxo de ações capturadas durante a execução de uma tarefa.
3.3 Processamento dos logs de ações

Após a captura dos logs de execução, que ocorre no momento da realização da
tarefa, os dados obtidos são processados para que seja realizada a classificação de cada
xPath, identificado na captura em um tipo específico. Cada xPath é analisado e então é
identificado a tag HTML que representa o elemento. No exemplo descrito na Seção 1.5,
o xPath de valor “header/nav/ul/li[2]/div/nav/div/ul/li/a” identifica o elemento da tag
“<a>”. Esse processo ocorre de maneira semi-automatizada, podendo ser realizado ajustes
manuais.
Na Tabela 1 são apresentados os componentes HTML, representados por tags, e
suas respectivas classificações. Nela podemos perceber que mais de uma tag HTML pode
3.3. Processamento dos logs de ações 27
Tabela 1 – Tags HTML e seus respectivos tipos.
Tag HTML Tipo

<a>, <button>, <map>, <track>, <select> Button
<input>, <textarea> Input
<table> TabelaOutput
<p>, <pre>, <label>, <i>, <h1>até <h6>,
<blockquote>, <dir>, <div>, <dl>, <dt>, Output
<hr>, <li>, <ol>, <ul>
ser classificada com um mesmo tipo. Isso ocorre porque tags distintas podem derivar da
mesma ação manual, como as tags “<button>” e “<a>”, que necessitam da ação de clicar,
ou as tags “<input>” e “<textarea>”, que necessitam da ação de preenchimento de texto.
Além disso, nessa etapa de processamento é possível associar um rótulo para cada
ação. Essa associação é opcional, uma vez que a abordagem associa automaticamente
um rótulo para cada ação. Entretanto, esse rótulo atribuído automaticamente pode ser
modificado pelo usuário, uma vez que, por exemplo, dado três ações de entrada de dados
para a consulta de saldo bancário, em que a ação 1 corresponde a preencher com o número
da agência, a ação 2 preencher com o número da conta, e a ação 3 preencher com a senha, o
sistema atribui os rótulos input_1, input_2 e input_3, respectivamente para cada entrada.
Entretanto, o usuário pode rotulá-los de acordo com sua preferência, com os valores para
as três ações, por exemplo, de num_agencia, num_conta e senha, respectivamente.
É relevante destacar que esses valores rotulados são de suma importância para o
tratamento de erros realizado pela abordagem, uma vez que, durante a execução do serviço,
caso o elemento HTML não esteja mais presente na página Web com aquele valor de xPath,
então é retornado para o sistema solicitante que houve erro naquele ponto específico do
fluxo, e seu valor rotulado é informado para que sejam tomadas as devidas providências.
Figura 9 – Fluxo processado na Etapa 3 do MiD.
Na Figura 9 é apresentado o fluxo de execução com os valores mensurados após

a etapa de processamento dos logs de ações. Note que é o mesmo exemplo mostrado na
Figura 8, entretanto, para cada xPath registrado nas ações, é inferido o seu valor de Tipo
e gerado um rótulo para valor. De acordo com as tags e tipos apresentados na Tabela 1, a
Ação 1 foi classificada como tipo Button, enquanto que a Ação 2 foi classificada como tipo
Input e Ação 3 foi classificada como tipo Output.
28 Capítulo 3. Abordagem Proposta
3.4 Automação da execução da tarefa

A etapa de automação da execução da tarefa consiste em, a partir de um conjunto
de ações capturadas e processadas nas etapas anteriores, reproduzir o fluxo de execução
correspondente ao conjunto de passos de uma determinada tarefa. Por exemplo, dada uma
ação do tipo Button, esse elemento é acionado com clique reproduzindo automaticamente
a ação realizada manualmente. Em suma, essa etapa tem o objetivo de utilizar atuadores
e Web Scraping (VARGIU; URRU, 2013) para interagir com telas HTML, para cada tipo
de ação possível de uma interface Web, conforme apresentada anteriormente na Tabela 1,
Seguindo com nosso exemplo de apoio, na tarefa de consultar saldo bancário, as
ações são preencher o input do número da agência, preencher input com o número da conta,
preencher o input com a senha, clicar no botão de entrar e identificar o componente que
exibe o valor do saldo. Sendo assim, essa tarefa deve ser realizada de forma automatizada,
no qual o sistema informa os 3 valores de input de dados, a abordagem realiza as todas
as ações, e realiza o processo de Web Scraping para retornar para o sistema solicitante o
valor do saldo.
Figura 10 – Fluxo processado na Etapa 3 do MiD.
Na Figura 10 é apresentada a continuidade do exemplo mostrado anteriormente na

Figuras 8 e 9. Como o tipo da Ação 1 representa um Button, durante a etapa de automação
da execução da tarefa esse componente é submetido a uma ação de click. De forma análoga,
a Ação 2 solicita a entrada de dados e na Ação 3 é extraída as informações contidas naquele
componente, uma vez que as ações são do tipo Input e Output, respectivamente.
3.5 Disponibilização da tarefa como serviço

Por fim, para possibilitar que os sistemas sejam integrados é necessário que haja
um meio em que eles possam se comunicar, e por isso que a ultima etapa da nossa
3.5. Disponibilização da tarefa como serviço 29
abordagem consiste em disponibilizar a tarefa como serviço Web. Para isso, disponibiliza-se
um endpoint de acesso.
Para a correta execução da tarefa como um serviço, deve ser possível receber
os parâmetros necessários para a realização da tarefa. Com isso, é possível executar a
tarefa, identificar os valores para saída, e retorná-los para o sistema solicitante. Isso tudo
funcionando por meio de Web Service.
31
4 A Ferramenta MiD
Desenvolveu-se a ferramenta MiD para suportar o uso da abordagem proposta neste

trabalho. A ferramenta possui os seguintes módulos: MiDWeb, MiDScraping, MiDWeb-
Service e MiDChrome. Cada módulo presente no MiD possui sua responsabilidade bem
definida. A troca entre os recursos de cada módulo é realizada pelo padrão RESTFul.
4.1 MiDWeb
O MiDWeb é o módulo central do MiD. Ele é responsável por orquestrar os outros
módulos. Sua principal função é disponibilizar uma interface de acesso para o usuário. Nele
é possível visualizar algumas informações sobre os Web Services criados pelo usuário. O
MiDWeb possui uma tela de monitoramento, em que é possível identificar quantos acessos
ocorreram no dia, quantas requisições não foram atendidas, dentre outras. As principais
funcionalidades do MiDWeb são:
Gerenciamento de usuário: para acessar todas as funcionalidades do MiDWeb, é

necessário realizar um cadastro prévio. Por conta disso, o MiDWeb possibilita o
cadastro/edição e login/logout de usuários na ferramenta.
Gerenciamento de sistemas: quando um usuário deseja integrar um sistema, ele deve

cadastrar esse sistema alvo no MiDWeb.
Gerenciamento de funcionalidades: consideramos em nossa abordagem que uma

tarefa que deseja integrar como uma funcionalidade. Por isso, a MiDWeb possui a
opção de cadastro de funcionalidades para um determinado sistema.
Gerenciamento de fluxos: para cada funcionalidade, é possível o cadastro de fluxos.

Por exemplo, para uma mesma funcionalidade, pode haver o fluxo principal e o fluxo
alternativo. Nesse caso, o usuário pode gerenciar os fluxos de uma funcionalidade.
Gerenciamento de ações: as ações compreendem cada atividade realizada pelo usuário

durante a execução de um fluxo de uma funcionalidade que representa uma tarefa.
Essas ações são capturadas pelo módulo MiDChrome. Mesmo assim, o módulo
MiDWeb possibilita gerenciar essas ações, modificando rótulos manualmente, ou
removendo falsos positivos.
32 Capítulo 4. A Ferramenta MiD
Figura 11 – Página inicial do módulo MiDWeb
Na Figura 11 é apresentada a página inicial do MiDWeb1 . O back-end do MiDWeb

foi desenvolvido utilizando a linguagem Python 2 , com auxilio do framework para aplicações
Web Django3 . No front-end foi utilizado o framework Bootstrap4 para a construção do
layout e Highcharts 5 para geração de gráficos.
4.2 MiDScraping
O MiDScraping realiza a Etapa 4 da abordagem MiD, que é a automação da
execução da tarefa. O funcionamento desse módulo ocorre da seguinte forma: dado um
conjunto de ações que representa um fluxo de uma funcionalidade, o MiDScraping reproduz
o passo a passo desse fluxo, executando cada ação sequencialmente. Esse módulo é acionado
pelo módulo MiDWebService, no momento que um sistema solicita a execução de uma
tarefa. Com isso, o MiDScraping recebe os parâmetros necessários para a realização da
tarefa (inputs) e retorna a informação definida para o MiDWebService.
Esse módulo foi desenvolvido utilizando como base o Selenium 6 e outros frameworks
1
<https://mid-integrations.herokuapp.com/>.
2
<https://www.python.org/>.
3
<https://www.djangoproject.com/>.
4
<https://getbootstrap.com/>.
5
<https://www.highcharts.com/>.
6
<https://www.seleniumhq.org/>.
4.3. MiDWebService 33
para processamento de conteúdo HTML, como o BeautifulSoup7 . O Selenium 8 foi desenvol-

vido para apoiar nas atividades de teste em aplicações Web, entretanto, devido sua robustez
e escalabilidade em automatizar execução de tarefas, foi utilizado na implementação desse
módulo.
4.3 MiDWebService
O MiDWebService é o módulo do ecossistema MiD que disponibiliza a interface de
acesso entre os sistemas. Esse módulo recebe uma requisição e informa ao MiDScraping os
dados necessários para a realização da requisição, bem como qual tarefa será realizada. No
fim do processo de scraping pelo MiDScraping, o MiDWebService recebe o retorno e envia
para o sistema solicitante a resposta da requisição.
Figura 12 – Modelo de requisição e resposta HTTP utilizadas para executar determinada

tarefa.
Na Figura 12 é apresentado o padrão de requisição e resposta suportado pelo

MiDWebService. Inicialmente, o identificador do fluxo é recebido na url da requisição,
juntamente com os valores para as entradas de dados. O nome da entrada e do retorno é
padronizado de acordo com o rótulo definido no momento da captura ou modificado no
MiDWeb. O MiDWebService funciona através de uma requisição do método POST com a
mensagem JSON9 para requisição e resposta. Esse módulo foi implementado utilizando o
framework Django REST 10 .
4.4 MiDChrome
Por fim, o módulo MiDChrome implementa o plugin para captura de dados no lado
cliente. Esse plugin foi desenvolvido como extensão e suporta capturar dados do navegador
7
<https://wiki.python.org.br/BeautifulSoup>.
8
<https://www.seleniumhq.org/>.
9
<https://www.json.org/>.
10
<https://www.django-rest-framework.org/>.
34 Capítulo 4. A Ferramenta MiD
Google Chrome 11 . Ele foi construído com a utilização de Java Script 12 e envia os dados
capturados para o MiDWeb por requisição AJAX 13 . Seu funcionamento consiste em inserir
um script que monitora todos os cliques do usuário durante a execução da tarefa. Na
Figura 13 é apresentado o formato de iteração entre o componente de captura e as páginas
Web. Um script é inserido, no lado cliente da aplicação (navegador), ao ser acionado pelo
plugin. Com isso, a captura inicia e os metadados são capturados.
Figura 13 – Sumarização do processo de captura dos logs de execução no lado cliente.
11
<https://developer.chrome.com/extensions>.
12
<https://www.javascript.com/>.
13
<https://api.jquery.com/jquery.ajax/>.
35
5 MiD em Ação
Nesta seção apresenta-se um exemplo do MiD em ação. Para isso, criaremos um

Web Service para a tarefa de listar as conferências que estão aceitando artigos para registro
e upload. Essa tarefa encontra-se no Journal and Event Management System (JEMS) 1 ,
que é o sistema da Sociedade Brasileira de Computação para controle de submissão/revisão
de artigos.
Figura 14 – Cadastro de sistemas na MiDWeb.
Inicialmente, o usuário deve acessar o MiDWeb e realizar o login (ou cadastro, caso
não tenha) e acessar a opção de cadastro de sistemas, localizado na barra esquerda da tela
inicial. Para o cadastro do sistema, o usuário informa o nome, que no caso é "JEMS ", e
uma descrição do sistema, que no nosso exemplo é "Sistema de gerenciamento de periódico
e eventos". Na Figura 14 é apresentado o detalhamento dessa etapa inicial.
Após o cadastro do sistema, o usuário deve realizar mais dois outros cadastros. O
primeiro é o cadastro da Funcionalidade. Em nosso exemplo, a funcionalidade cadastrada é
listar as conferências abertas para submissão e registro de artigos. O segundo é o cadastro
de Fluxo. Em nosso exemplo o usuário cadastra o Fluxo com nome "Fluxo Principal"e a url
do fluxo com "https://jems.sbc.org.br/ ". O objetivo do fluxo é possibilitar o cadastro de
vários fluxos para uma mesma funcionalidade. Com isso, é possível existir fluxo principal e
fluxos alternativos para uma funcionalidade.
Com o fim do cadastro do sistema, funcionalidade e fluxo, o usuário deve, com a
informação do identificador do fluxo gerado automaticamente pela MiDWeb, acessar o site
no qual deseja iniciar a captura dos dados. Em nosso exemplo, é acessado o JEMS, e a
1
<https://jems.sbc.org.br/>
36 Capítulo 5. MiD em Ação
partir de então, é acionado o MiDChrome, informado o identificador do fluxo, e iniciando

a captura.
O processo de captura é feito pelo MiDChrome. Nele o usuário realiza o passo a
passo para completar a tarefa, clicando inicialmente no input associado a label "Last name,
JEMS ID# or email address"e preenchendo o seu email, depois no input associado a label
"Password"e preenchendo com sua senha, e por fim, no botão "Login". Esse processo é
apresentado na Figura 18.
Figura 15 – Captura de dados no lado cliente no sistema JEMS no login.
Para finalizar a tarefa, o usuário clica em alguma região da tabela que exibe todos
os eventos que estão abertos para upload e registro de artigos e clica na opção de finalizar
captura na extensão. O usuário, opcionalmente, pode modificar os valores e tipos de
cada xPath capturado. Isso deve ser realizado antes do acionamento do botão de finalizar
captura ou posteriormente no MiDWeb. Na Figura 16 mostra o final da realização do
mapeamento da tarefa.
Figura 16 – Captura de dados no lado cliente no sistema JEMS na opção de listar todos
os eventos disponíveis.
37
A Figura 17 mostra o exemplo da utilização do serviço criado para a funcionalidade

do JEMS. Foi simulado uma requisição por meio da ferramenta POSTMAN 2 , onde foram
submetidos na requisição os valores de email e senha, e retornado a lista com todos as
conferências disponíveis para registro e submissão de artigos.
Figura 17 – Ferramenta POSTMAN para simulação de requisições.
2
<https://www.getpostman.com/>
Parte IV
Resultados e Discussões
41
6 Avaliação
Nesta seção é apresentada a avaliação preliminar realizada para avaliar a abordagem

MiD. A avaliação conduzida neste trabalho foi definida da seguinte forma:
• Analisar a abordagem proposta neste trabalho e uma abordagem manual baseada

em API,
• em relação a sua eficiência, eficácia e esforço gasto para o desenvolvimento,
• do ponto de vista do pesquisador,
• no contexto de um projeto real de médio porte de uma empresa de desenvolvimento

de software para gestão de planos de saúde.
6.1 Metodologia
Nesta avaliação comparamos a abordagem proposta neste trabalho com a abor-
dagem manual baseada em API no desenvolvimento de soluções para integração entre
sistemas. Uma abordagem manual baseada em API é a codificação de programas utili-
zando bibliotecas e frameworks disponíveis. Desta forma, o objetivo geral da avaliação foi
identificar a possibilidade de integrar sistemas legados sem a dependência da arquitetura
e tecnologia utilizada em tais sistemas. Para guiar nessa análise, utilizamos as seguintes
questões de pesquisa:
QP1 - A abordagem proposta neste trabalho é mais eficiente que uma abordagem manual
baseada em API? Para responder essa questão, avaliamos o tempo de resposta das
requisições para acessos simultâneos.
QP2 - A abordagem proposta neste trabalho é mais eficaz que uma abordagem manual
baseada em API? Para responder essa questão, checamos o percentual de erros
ocorridos em um determinado cenário de teste.
QP3 - A abordagem proposta neste trabalho necessita de menor esforço no desenvol-

vimento em relação a uma abordagem manual baseada em API? Para responder
essa questão, verificamos o esforço gasto no desenvolvimento de um mesmo serviço
utilizando duas abordagens diferentes: a proposta neste trabalho e uma abordagem
manual.
42 Capítulo 6. Avaliação
Foi realizada uma avaliação comparativa de performance entre dois Web Services
para integração desenvolvidos utilizando duas abordagens distintas: uma abordagem
manual baseada em API e a abordagem MiD proposta neste trabalho. Para cada Web
Service desenvolvido para integração de sistemas, foram analisados os seguintes pontos:
Eficiência: Mensurar o tempo em segundos para requisições simultâneas nos sistemas

alvos a integração.
Eficácia: Mensurar o percentual do número de requisições atendidas de forma correta

durante a comunicação de sistemas integrados. A Equação 6.1 apresenta a forma
como é calculada essa variável.
QntReqCorretas ∗ 100
Ef icacia = (6.1)
QntReqT otal
Onde:
• QntReqCorretas: é a quantidade de requisições que foram retornadas com

sucesso;
• QntReqTotal: é a quantidade de requisições que foram realizadas.
Esforço: Mensurar o esforço em minutos gasto no processo de desenvolvimento das

soluções para integração.
Para a condução dessa avaliação, analisamos o desenvolvimento de uma funci-

onalidade para exibir informação sobre a guia médica de um paciente em um sistema
desenvolvido por uma empresa de gestão de planos de saúde. O sistema utilizado como alvo
para integração é responsável por distribuir uma solicitação feita a um plano para uma
rede de médicos que a analisa e então emite uma resposta indicando se a solicitação deve
ou não ser autorizada. Tal sistema é utilizado na empresa de forma integrada com vários
outros sistemas, com tecnologias distintas. O sistema é o concentrador de solicitações da
empresa, sendo utilizado por seus médicos para decidir sobre solicitações em um único local,
independente de onde tenha vindo o pedido. Esse sistema foi desenvolvido em linguagem
Ruby 1 e utiliza do framework Ruby on Rails 2 para disponibilizar alguns Web Services para
integração com outros sistemas desenvolvidos utilizando outras linguagens e com diferentes
arquiteturas.
Inicialmente, realizamos uma análise de performance que consistiu em realizar uma
bateria de testes simulando o que acontece em um ambiente real, que é um conjunto de
acessos simultâneos. Primeiramente, para 1 acesso apenas, foram realizados 3 testes, e para
cada teste foram coletadas as médias e o desvio padrão (DP) de respostas das requisições.
1
<https://www.ruby-lang.org/pt/>
2
<https://rubyonrails.org/>
6.2. Resultados e Discussão 43
Por fim, foi calculado a média de cada teste. Esse mesmo ciclo de teste foi realizado
novamente, porém simulando 5, 10, 15, 50, 100 acessos simultâneos, respectivamente. Além
do tempo de resposta, foi verificado se alguma das requisições não eram respondidas de
forma correta, ou se acontecia algum problema que impedia de responder. Isso foi realizado
pela necessidade de verificar a ocorrência de erros durante os acessos simultâneos.
Além do teste de performance, foram coletadas informações relacionadas ao processo
de desenvolvimento dos Web Services para cada abordagem. As informações coletadas
foram sobre a estimativa da equipe do tempo necessário para o desenvolvimento e o
histórico de tarefas associadas aquela demanda de integração. O objetivo dessa extração e
analise de dados históricos foi mensurar o esforço gasto nessas atividades de integração.
6.2 Resultados e Discussão

A Tabela 2 apresenta os resultados do avaliação em relação a eficiência das aborda-
gens para o desenvolvimento de Web Services para integração. A eficiência foi calculada em
relação ao tempo médio das respostas para as requisições analisando acessos simultâneos.
Além da média, é apresentado o desvio padrão calculado para os testes.
Figura 18 – Tempo de resposta para acessos simultâneos.
Analisando os dados da Figura 18 e Tabela 2 podemos perceber que, para todas os

cenários, a abordagem manual baseada em API obteve um tempo médio de resposta bem
inferior a nossa abordagem proposta. Observando os valores obtidos, os tempos médios para
as requisições com 1, 5 e 10 acessos simultâneos são bem próximos. Entretanto, quando
ocorrem 50 e 100 acessos simultâneos, as médias crescem exponencialmente, diferentemente
da abordagem manual. Além disso, o alto valor de desvio padrão (DP) para os cenários 50
e 100 ocorrem porque as primeiras requisições são atendidas de maneira rápida, todavia,
à medida que o sistema alvo integrado não consegue processar simultaneamente muitas
requisições, o tempo de resposta tende a demorar.
44
entre sistemas.
Eficiência das Abordagens para Integração entre Sistemas medido em Segundos

Teste 1 Teste 2 Teste 3 Resultado final
Cenários Manual MiD Manual MiD Manual MiD Manual MiD
Média DP Média DP Média DP Média DP Média DP Média DP Média Média
1 0,67 0 11,57 0 0,91 0 10,92 0 0,77 0 10,38 0 0,783 10,95
5 0,61 0,05 10,87 0,09 0,9 0,07 11,01 0,12 0,56 0,02 11,38 0,18 0,69 11,08
10 0,81 0,06 12,83 0,24 0,6 0,06 12,97 0,3 0,64 0,06 12,71 0,21 0,683 12,83
50 1,86 0,66 32,38 13,21 1,24 0,32 31,17 12,8 1,18 0,41 32,59 13,82 1,426 32,04
100 2,33 1,22 58,38 30,1 2,03 0,82 60,02 30,99 1,99 0,88 55,51 28,92 2,116 57,97
Capítulo 6. Avaliação
Tabela 2 – Resultado do experimento quanto a eficiência das abordagens para integração

6.2. Resultados e Discussão 45
A diferença no tempo de resposta para as requisições pode ser justificada pelos

seguintes fatores: (i) o tempo para executar uma tarefa está totalmente associada ao tempo
necessário para o carregamento das paginas HTML e a velocidade da internet pode ser
uma variável que interfira nesse tempo; (ii) a configuração do servidor em que o sistema
alvo está hospedado, uma vez que ele pode não suportar, ou suportar, porém com um
comportamento mais demorado, vários acessos simultâneos; (iii) com uma abordagem
baseada em API, é possível construir sistemas que interagem diretamente com a base de
dados, removendo a camada Web em que a abordagem proposta interage para obtenção
das informações, e com isso, potencializam o acesso e reduzem significativamente o tempo
de resposta.
Portanto, analisando a abordagem manual e a nossa abordagem proposta, em
relação a tarefa definida como alvo para integração em nossa avaliação, a resposta para a
Questão de Pesquisa 1 (QP1) é: considerando o contexto deste experimento, a eficiência em
relação ao tempo de resposta para acessos simultâneos com a utilização de uma abordagem
baseada em API é maior do que com a utilização da abordagem proposta neste trabalho.
Na Tabela 3 é apresentada os valores para eficácia das duas abordagens para
o desenvolvimento de integrações entre sistemas. Como mencionado anteriormente, a
eficácia foi calculada em relação ao percentual de requisições atendidas corretamente. Ao
analisarmos a Tabela 3 podemos notar que ambas as abordagens tiveram uma percentual
bem próximo, porém obtiveram o mesmo numero de requisições não respondidas, com um
total de 1. Entretanto, devido ao cenário no qual a abordagem baseada em API possuir 50
requisições simultâneas, o valor de 1 para esse total representou 98% e para o MiD, como
eram 100 requisições, a porcentagem ficou 99%.
Tabela 3 – Resultado do experimento quanto a eficácia dos sistemas de integração.
Eficácia das Abordagens para Integração entre Sistemas

Teste 1 Teste 2 Teste 3
Cenários
Manual MiD Manual MiD Manual MiD
1 100% 100% 100% 100% 100% 100%
5 100% 100% 100% 100% 100% 100%
10 100% 100% 100% 100% 100% 100%
50 98% 100% 100% 100% 100% 100%
100 100% 100% 100% 99% 100% 100%
Nesse cenário, com os resultados obtidos em nosso estudo avaliativo, concluímos

que a resposta para a Questão de Pesquisa 2 (QP2) é: a eficácia da abordagem proposta
neste trabalho para o desenvolvimento de Web Services para integração de sistemas não é
maior que a eficácia dos sistemas construídos utilizando uma abordagem manual baseada
em API.
Por fim, a Tabela 4 apresenta os valores relacionado ao esforço necessário para o
46 Capítulo 6. Avaliação
Tabela 4 – Resultado do experimento quanto ao esforço despendido no desenvolvimento

de Web Service de Integração.
Esforço no desenvolvimento medido em minutos

Manual MiD
Estimado Real Estimado Real
4200 3360 5 3,5
desenvolvimento do Web Service de integração utilizando a abordagem manual baseada

em API e a abordagem proposta neste trabalho. Analisando os valores obtidos no esforço
podemos notar que para o desenvolvimento do Web Service de integração na tarefa de
exibir informações sobre a guia médica de um paciente, a abordagem MiD necessitou
de um menor esforço para ser realizado, em comparação com a abordagem baseada em
API. Isso porque o desenvolvimento da integração de forma manual custou 56 horas para
ser concluída, o que totaliza 3360 minutos. É importante destacar que o Web Service
desenvolvido de forma manual foi realizado por um desenvolvedor que possuía cargo de
Desenvolvedor Pleno, com uma boa experiência no desenvolvimento de Web Services, na
tecnologia utilizada e na regra de negócio do problema.
Em relação ao esforço gasto no desenvolvimento das soluções de integração para
a tarefa considerada na avaliação, a resposta para a Questão de Pesquisa 3 (QP3) é a
seguinte: considerando o contexto do desenvolvimento da tarefa analisada na avaliação
deste trabalho, podemos notar que o esforço utilizado no desenvolvimento do Web Service
com a abordagem proposta neste trabalho foi menor que o desenvolvimento de Web Services
com uma abordagem baseada em API.
Com isso, podemos considerar que, quando a temporalidade não é um requisito
primordial, ou seja, quando o tempo para a troca de informações entre os sistemas
integrados pelo MiD é aceitável no contexto utilizado, ou quando o cenário de vários
acessos simultâneos não irá ocorrer, a abordagem MiD pode ser uma solução viável, uma
vez que, é necessário um baixo esforço para sua utilização no desenvolvimento de Web
Services de integração. Outro ponto importante que devemos destacar é que sua utilização
não visa substituir o desenvolvimento manual baseado em API e sim disponibilizar uma
nova alternativa para a construção de serviços de integração, ainda mais em situações em
que não possui acesso ao código-fonte, as equipes estão com outras demandas, e há uma
necessidade de disponibilizar serviços com uma certa urgência.
6.3 Ameaças à validade

Em relação a avaliação conduzida para validar a abordagem MiD, existem algumas
ameaças à validade dos resultados obtidos (WHOLIN et al., 2012). A seguir são apresenta
os quatro tipos de ameaças e as medidas tomadas para contornar tais problemas.
6.3. Ameaças à validade 47
6.3.1 Validade Externa

Essa categoria de ameaça preocupa-se com o risco da generalização dos resultados
obtidos. Com isso, para o projeto e os cenários utilizados na avaliação, não é possível
generalizar os resultados. Entretanto, como forma de tornar os resultados mais próximos do
mundo real, e assim mitigar essa ameaça, buscamos analisar um projeto real em produção,
do tipo de sistema de informação transacional. Além disso, selecionamos participantes
profissionais no desenvolvimento de software, que utilizaram APIs adequadas para o
desenvolvimento manual de Web Services de integração.
6.3.2 Validade de Conclusão

Esse tipo de ameaça está relacionado a questões que afetam a capacidade de chegar
à conclusão correta sobre as relações entre os tratamentos e os resultados dos experimentos.
Para reduzir essa ameaça, utilizamos medidas objetivas (eficiência, esforço, eficácia) para
aumentar a confiabilidade das medidas, além disso, não interferimos no cotidiano das
atividades do ambiente corporativo, uma vez que a analise consistiu em verificar um projeto
real em produção. No entanto, como trata-se de uma avaliação realizada em ambiente de
produção, não é simples possuir vários contextos diferentes de avaliação para se tentar
generalizar os resultados por meio de testes estatísticos, uma vez que tais testes exigem
uma quantidade maior de amostras.
6.3.3 Validade Interna

Essa ameaça é preocupante quando as relações de causa-efeito são decorrentes de
outros fatores não relacionados ao fator em observação. Para evitar essa ameaça, utilizamos
um sistema real, em produção, que já possuía uma API desenvolvida por um desenvolvedor
nível pleno, para então desenvolve-la via nossa abordagem e assim realizar comparações.
No entanto, como não temos tantas alternativas de comparação, pode existir um viés nessa
escolha.
6.3.4 Validade de Construção

Dentro dessa categoria existem algumas ameaças relacionadas a estruturação da
metodologia utilizada na avaliação e a fatores sociais. Entretanto, para este estudo foi
identificada apenas uma ameaça a ser tratada: a expectativa dos pesquisadores. Essa
ameaça foi mitigada com a expressa proibição de qualquer ajuda por parte do pesquisador
responsável durante a execução da avaliação, que foi também minimizada pelo fato da
construção da API ter sido feita antes da construção da integração via MiD.
49
7 Considerações Finais
Neste trabalho foi apresentada a abordagem MiD que tem como objetivo principal
a criação de pontos de integração para sistemas. Com o MiD é possível integrar sistemas
sem a necessidade de ter acesso ao código-fonte, além de necessitar de um baixo esforço
para o processo de integração. Além disso, o MiD é prático ao ponto de que uma pessoa
sem conhecimento em programação consegue construir seu próprio Web Service.
Foi realizado uma avaliação preliminar em que foi comparada a abordagem pro-
posta neste trabalho com uma abordagem baseada em API. Foram verificadas algumas
características dessas abordagens, como: o tempo de resposta para acessos simultâneos, a
quantidade de erros nas requisições e o esforço gasto para o desenvolvimento dessas abor-
dagens. Os resultados preliminares indicam que, para os sistemas analisados na avaliação,
a abordagem manual baseada em API possui um tempo médio de resposta bem melhor
que a nossa abordagem, entretanto o esforço gasto para sua construção é bem maior que
com a utilização do MiD.
7.1 Desafios e Limitações
Atualmente a abordagem MiD possui algumas limitações em relação à sua utilização.

Nesse caso, a principal limitação está relacionada a variabilidade dos layouts das páginas
Web em que foram utilizadas para integração. Isso ocorre porque as mudanças nos elementos
HTML de uma página acarretam em possíveis modificações estruturais e consequentemente
a alteração nos xPaths utilizados para identificar os elementos. Com isso, é importante
destacar que após o processo de captura dos logs de execução (Etapa 2 da abordagem),
caso haja uma modificação estrutural na página Web, provavelmente deverá ser necessária
realizar novamente todo o processo descrito na abordagem. Uma alternativa implementada
por nossos módulos para facilitar essa identificação de que houve uma modificação é que
quando um determinado elemento não foi identificado pelo seu antigo xPath, no retorno
da requisição é informado o rótulo do elemento, seu tipo e o antigo xPath.
Além disso, outra limitação está relacionada ao funcionamento e disponibilidade os
Web Services de integração desenvolvidos com apoio do MiD, uma vez que o seu correto
funcionamento é dependente do funcionamento e disponibilidade do sistema alvo para a
integração. Fatores como a configuração do servidor em que o sistema alvo integrado está
hospedado, a velocidade da conexão de internet, a quantidade de páginas Web em uma
tarefa integrada, dentre outras coisas podem influenciar na performance das integrações.
50 Capítulo 7. Considerações Finais
7.2 Continuidade da Pesquisa

Considerando alguns desafios apresentados na Seção 7.1 e com base nos objeti-
vos deste trabalho, foi definido um cronograma de atividades a serem realizadas como
continuidade da pesquisa. Esse cronograma é apresentado na Tabela 5.
Tabela 5 – Cronograma de atividades para a continuidade da pesquisa.
2019 2020
Atividade Set Out Nov Dez Jan Fev Mar
Melhorias na ferramenta MiD X
Realização de um estudo experi- X X
mental
Escrita de artigos X X X X
Escrita da dissertação X X X
Defesa do mestrado X
Como continuidade do trabalho, durante o mês de setembro, irá ser realizada

melhorias na implementação da ferramenta MiD. Os objetivos dessa melhoria é tornar
o MiD mais eficiente. Uma possibilidade que pretendemos investigar é a substituição
da utilização do Selenium para a tecnologia request 1 . Também no mês de setembro,
provavelmente nossa ferramenta deixará de estar em processo de homologação e entrará em
produção em uma empresa de gestão de planos de saúde. Com isso, é provável que situações
que não identificamos em ambiente de testes possam acontecer, e assim, melhorias devem
ser realizadas para dar suporte ao novo ambiente desafiador no qual ele estará inserido.
Em paralelo com o mês de setembro, e também no mês de outubro, irá ser realizado
um estudo experimental utilizando as diretrizes proposta por (WHOLIN et al., 2012) para
que, com uma maior quantidade de sistemas e participantes envolvidos, consigamos obter
resultados estatísticos mais robustos.
Por fim, entre o mês de outubro e fevereiro, irá ser realizado a escrita de artigos e
da dissertação, respectivamente. Pretendemos escrever alguns artigos relatando os avanços
que nossa abordagem proporcionou para a comunidade científica e industrial. E para
finalizar essa pesquisa, pretendemos realizar a defesa do mestrado no mês de março.
7.3 Publicações
Recentemente, um artigo intitulado “MiD: Simplificando a Integração entre
Sistemas Legados”, no qual descreve nossa abordagem foi submetido ao Simpósio
Brasileiro de Qualidade de Software (SQBS). Até o presente dia da escrita desta
qualificação, o resultado da submissão ainda não foi disponibilizado.
1
<https://2.python-requests.org/en/master/>
51
Referências
ALMONAIES, A. A.; CORDY, J. R.; DEAN, T. R. Legacy system evolution towards

service-oriented architecture. In: International Workshop on SOA Migration and Evolution.
[S.l.: s.n.], 2010. p. 53–62. Citado na página 11.
BENNETT, K. Legacy systems: Coping with success. IEEE software, IEEE, v. 12, n. 1, p.
19–23, 1995. Citado 2 vezes nas páginas 5 e 11.
CAVALIERI, F.; GUERRINI, G.; MESITI, M. Xspath: Navigation on xml schemas made
easy. IEEE Transactions on Knowledge and Data Engineering, IEEE, v. 26, n. 2, p.
485–499, 2012. Citado na página 16.
CLARK, J.; DEROSE, S. et al. XML path language (XPath) version 1.0. 1999. Citado
na página 16.
COLLINS, E. F.; LUCENA, V. F. de. Software test automation practices in agile

development environment: An industry experience report. In: IEEE. 2012 7th International
Workshop on Automation of Software Test (AST). [S.l.], 2012. p. 57–63. Citado na página
17.
COMELLA-DORDA, S. et al. A survey of black-box modernization approaches for

information systems. In: icsm. [S.l.: s.n.], 2000. p. 173–183. Citado na página 12.
COOK, C.; SCHULTZ, D. Beginning HTML with CSS and XHTML: modern guide and
reference. [S.l.]: Apress, 2007. Citado na página 15.
CURBERA, F. et al. Unraveling the web services web: an introduction to soap, wsdl, and
uddi. IEEE Internet computing, IEEE, v. 6, n. 2, p. 86–93, 2002. Citado na página 13.
ERL, T. SOA Principles of Service Design (paperback). [S.l.]: Prentice Hall Press, 2016.
Citado na página 13.
ERRADI, A.; MAHESHWARI, P. A broker-based approach for improving web services

reliability. In: IEEE. IEEE International Conference on Web Services (ICWS’05). [S.l.],
2005. p. 355–362. Citado na página 12.
FIELDING, R. T.; TAYLOR, R. N. Architectural styles and the design of network-based

software architectures. [S.l.]: University of California, Irvine Doctoral dissertation, 2000.
v. 7. Citado 2 vezes nas páginas 13 e 14.
FOSTER, I. The physiology of the grid: An open grid services architecture for distributed
systems integration. Citeseer, 2002. Citado na página 3.
FREIRE, D. L.; FRANTZ, R. Z.; ROOS-FRANTZ, F. Ranking enterprise application

integration platforms from a performance perspective: An experience report. Software:
Practice and Experience, Wiley Online Library, v. 49, n. 5, p. 921–941, 2019. Citado na
página 3.
52 Referências
FURCHE, T. et al. Oxpath: A language for scalable, memory-efficient data extraction

from web applications. Proceedings of the VLDB Endowment, v. 4, n. 11, p. 1016–1027,
2011. Citado na página 16.
GROSSE-RHODE, M. Semantic Integration of Heterogeneous Software Specifications.
[S.l.]: Springer Science & Business Media, 2013. Citado na página 3.
GUSTAVO, A. et al. Web services: concepts, architectures and applications. [S.l.]: Springer
Heidelberg, 2004. Citado na página 4.
HAUGSET, B.; HANSSEN, G. K. Automated acceptance testing: A literature review and
an industrial case study. In: IEEE. Agile 2008 Conference. [S.l.], 2008. p. 27–38. Citado
na página 17.
HENNINGSSON, S.; KETTINGER, W. J. Understanding information systems integration
deficiencies in mergers and acquisitions: A configurational perspective. Journal of
Management Information Systems, Taylor & Francis, v. 33, n. 4, p. 942–977, 2016. Citado
2 vezes nas páginas 3 e 4.
HOY, M. B. Html5: a new standard for the web. Medical reference services quarterly,
Taylor & Francis, v. 30, n. 1, p. 50–55, 2011. Citado na página 15.
KHADKA, R. et al. How do professionals perceive legacy systems and software
modernization? In: ACM. Proceedings of the 36th International Conference on Software
Engineering. [S.l.], 2014. p. 36–47. Citado na página 12.
KHADKA, R. et al. Legacy to soa evolution: a systematic literature review. In: Migrating
Legacy Applications: Challenges in Service Oriented Architecture and Cloud Computing
Environments. [S.l.]: IGI Global, 2013. p. 40–70. Citado na página 11.
LINTHICUM, D. S. Enterprise application integration. [S.l.]: Addison-Wesley Professional,
LUCCA, G. A. D. et al. Ware: A tool for the reverse engineering of web applications.
In: IEEE. Proceedings of the Sixth European Conference on Software Maintenance and
Reengineering. [S.l.], 2002. p. 241–250. Citado na página 7.
MANIKAS, K. Revisiting software ecosystems research: A longitudinal literature study.
Journal of Systems and Software, Elsevier, v. 117, p. 84–103, 2016. Citado na página 3.
MENDICINO, V. L.; WODTKE, D. V. Heterogeneous software integration systems and
methods. [S.l.]: Google Patents, 2010. US Patent 7,802,230. Citado na página 3.
MENG, J.; MEI, S.; YAN, Z. Restful web services: A solution for distributed data
integration. In: IEEE. 2009 International Conference on Computational Intelligence and
Software Engineering. [S.l.], 2009. p. 1–4. Citado na página 4.
MENS, T. et al. Challenges in software evolution. In: IEEE. Eighth International
Workshop on Principles of Software Evolution (IWPSE’05). [S.l.], 2005. p. 13–22. Citado
na página 3.
MUMBAIKAR, S.; PADIYA, P. et al. Web services based on soap and rest principles.
International Journal of Scientific and Research Publications, v. 3, n. 5, p. 1–4, 2013.
Referências 53
NEWCOMER, E.; LOMOW, G. Understanding SOA with Web services. [S.l.]:

Addison-Wesley, 2005. Citado na página 12.
PENG, F.; LI, D. Design of a service-enabled dependable integration environment. World

Academy of Science, Engineering and Technology, International Journal of Computer,
Electrical, Automation, Control and Information Engineering, v. 10, n. 10, p. 1766–1770,
PRENCIPE, A.; DAVIES, A.; HOBDAY, M. The business of systems integration. [S.l.]:
OUP Oxford, 2003. Citado na página 3.
PRESSMAN ROGER S, M. Software engineering: a practitioner’s approach. [S.l.]:

Palgrave Macmillan, 2014. Citado 2 vezes nas páginas 5 e 11.
RICHARDSON, L.; RUBY, S. RESTful web services. [S.l.]: "O’Reilly Media, Inc.", 2008.
RICHTER, A. et al. Knowledge management goals revisited: A cross-sectional analysis of

social software adoption in corporate environments. Vine, Emerald Group Publishing
Limited, v. 43, n. 2, p. 132–148, 2013. Citado na página 3.
ROCHIMAH, S.; SANKOH, A. S. Migration of existing or legacy software systems into

web service-based architectures (reengineering process): A systematic literature review.
International Journal of Computer Applications, Foundation of Computer Science, v. 975,
p. 8887, 2016. Citado na página 19.
ROMAN, D. et al. Web service modeling ontology. Applied ontology, IOS Press, v. 1, n. 1,
p. 77–106, 2005. Citado na página 4.
SALVATIERRA, G. et al. Legacy system migration approaches. IEEE Latin America

Transactions, IEEE, v. 11, n. 2, p. 840–851, 2013. Citado na página 12.
SZEPIELAK, D. Rest-based service oriented architecture for dynamically integrated

information systems. In: PhD Symposium at ICSOC. [S.l.: s.n.], 2006. v. 6. Citado na
página 3.
UPADHYAYA, B.; KHOMH, F.; ZOU, Y. Extracting restful services from web
applications. In: IEEE. 2012 Fifth IEEE International Conference on Service-Oriented
Computing and Applications (SOCA). [S.l.], 2012. p. 1–4. Citado 2 vezes nas páginas 4
e 20.
UPADHYAYA, B.; ZOU, Y.; KHOMH, F. An approach to extract restful services from
web applications. International Journal of Business Process Integration and Management,
Inderscience Publishers (IEL), v. 7, n. 3, p. 213–227, 2015. Citado 2 vezes nas páginas 4
e 20.
VARGIU, E.; URRU, M. Exploiting web scraping in a collaborative filtering-based

approach to web advertising. Artif. Intell. Research, v. 2, n. 1, p. 44–54, 2013. Citado na
página 28.
VELD, T. K.; KROGSTIE, J. Information systems development and evolution: A

replication study on work distribution in norwegian organizations. arXiv preprint
arXiv:1901.01811, 2019. Citado na página 3.
54 Referências
VINOSKI, S. Integration with web services. IEEE internet computing, IEEE, v. 7, n. 6, p.

VOGEL-HEUSER, B. et al. Evolution of software in automated production systems:

Challenges and research directions. Journal of Systems and Software, Elsevier, v. 110, p.
W3C. Web Services Architecture. 2004. [Online; accessed 08-July-2019]. Disponível em:
<https://www.w3.org/TR/ws-arch/>. Citado 3 vezes nas páginas 9, 12 e 13.
WHOLIN, C. et al. B. e wesslén, a. Experimentation in Software Engineering. [S.l.]:

Springer Berlin Heidelberg, 2012. Citado 2 vezes nas páginas 46 e 50.

Qualificação UFPI Irva

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Qualificação UFPI Irva

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal do Piauí

Centro de Ciências da Natureza

MiD: Simplificando a Integração entre Sistemas

Irvayne Matheus de Sousa Ibiapina

Número de Ordem PPGCC: M001

MiD: Simplificando a Integração entre Sistemas

Dissertação de Mestrado apresentada ao

Universidade Federal do Piauí – UFPI

Orientador: Pedro de Alcântara dos Santos Neto

Orientador: Pedro de Alcântara dos Santos Neto

Dissertação (Mestrado) – Universidade Federal do Piauí – UFPI

MiD: Simplificando a Integração entre Sistemas

Dissertação de Mestrado apresentada ao

Trabalho aprovado. Teresina-PI, 30 de Agosto de 2019:

Pedro de Alcântara dos Santos Neto

Thiago Carvalho de Sousa

Guilherme Amaral Avelino

Palavras-chaves: Web Services. Integração de Sistemas. Sistemas Legados.

Keywords: Web services. Integrations Systems. Legacy Systems.

Figura 1 – Regras para comunicação por Web Services (W3C, 2004). . . . . . . . . 13

Tabela 1 – Tags HTML e seus respectivos tipos. . . . . . . . . . . . . . . . . . . . 27

API Application Programming Interface

SOA Service-Oriented Architecture

HTML Hypertext Markup Language

REST Representational State Transfer

WSDL Web Services Description Language

XML Extensible Markup Language

JSON JavaScript Object Notation

SOAP Simple Object Access Protocol

HTTP HyperText Transfer Protocol

URL Uniform Resource Locator

URI Uniform Resource Identifier

xPath XML Path Language

Os ambientes corporativos modernos possuem um conjunto de soluções tecnológicas

recursos, seja ele dados ou funcionalidades, entre softwares díspares (HENNINGSSON;

• Esforço gasto para desenvolvimento (d1): muitas organizações se deparam com

• Integração com sistemas legados (d2): normalmente as organizações possuem

organizações dando suporte a um conjunto de funcionalidades imprescindíveis no

• Riscos associados a modificação em softwares (d3): a integração tradicional

• Utilização de softwares desenvolvido por terceiros (d4): quando as organiza-

Essas dificuldades são encontradas em muitas empresas de software. Para exemplifi-

Visão Geral da Proposta

1. Especificar uma abordagem que possibilite o desenvolvimento de Web Services sem

2. Desenvolver uma ferramenta Web para implementar a abordagem proposta, bem

como disponibilizá-lo utilização em um ambiente real. A ferramenta encontra-se

• O desenvolvimento de uma ferramenta que implementa a abordagem especificada

• Uma avaliação preliminar utilizando o MiD em um projeto real. Essa avaliação

Este capítulo apresenta os principais conceitos relacionados ao trabalho. Primei-

1.1 Sistema Legado

• O software deve ser adaptado para atender às necessidades de novos ambientes ou

• O software deve ser aperfeiçoado para implementar novos requisitos de negócio;

1.2 Web Service

1. Entidades Requester e Provider se conhecem (ou ao menos um conhece o outro);

2. Ambos concordam com a descrição do serviço e a semântica que norteará a interação

Figura 1 – Regras para comunicação por Web Services (W3C, 2004).

3. A descrição do serviço e a semântica são compreendidas pelos agentes Requester e

4. Agentes Requester e Provider trocam mensagens, realizando assim tarefas em nome

Web Services facilitam a integração entre sistemas, além de padronizar a comunica-

• Mensagem: a comunicação entre clientes e servidores ocorrem por meio de mensagens.

Existem muitas dúvidas em relação as vantagens e desvantagens da utilização

Figura 2 – Representação da tag HTML no navegador.

O propósito do navegador Web é de interpretar o HTML recebido do servidor e

• As tags HTML estão normalmente presentes em pares (tag de abertura e tag de