Universidade do MinhoEscola de Engenharia

João Nuno Félix Abrunhosa de Brito

Geração de interfaces Web a partir de uma aplicação existente

Dissertação de MestradoMestrado Integrado em Engenharia e Gestão de Sistemas de Informação

Trabalho realizado sob a orientação de:Prof. Doutor José Luís Mota PereiraDr. José Miguel Pimenta Marques

Janeiro de 2018

2

iii

Declaração para o RepositoriUM: Dissertação de Mestrado

Nome: João Nuno Félix Abrunhosa de BritoN.º Cartão Cidadão: 14907573Telemóvel: 913964866Correio eletrónico: jnabrito@gmail.com

Curso: Mestrado Integrado em Engenharia e Gestão de Sistemas de InformaçãoAno de conclusão da dissertação: 2018

Título em PT: Geração automática de interfaces Web a partir de uma aplicação existenteTítulo em EN: Automatic generation of Web interfaces based on an already existing applicationOrientador: Prof. Doutor José Luís Mota PereiraCoorientador: Dr. José Miguel Pimenta Marques

Declaro que concedo à Universidade do Minho e aos seus agentes uma licença não-exclusiva para arquivar e tornar acessível, nomeadamente através do seu repositório institucional, nas condições abaixo indicadas, a minha dissertação, em suporte digital.

Concordo que a minha dissertação seja colocada no repositório da Universidade do Minho com o seguinte estatuto:

1. Disponibilização imediata do trabalho para acesso universal;2. Disponibilização do trabalho para acesso exclusivo na Universidade do Minho

durante o período de 1 ano, 2 anos ou 3 anos, sendo que após o tempo assinalado autorizo o acesso universal.

3. Disponibilização do trabalho de acordo com o Despacho RT-98/2010 c) (embargo______ anos)

iv

Guimarães, _____ /_____ /_______Assinatura: ___________________________________________________________________

v

ResumoO mundo reconhece hoje, cada vez mais, a importância de aplicações híbridas que consigam conjugar um ambiente desktop com partes de funcionalidades na Web e dispositivos móveis. Este documento apresenta o projeto de dissertação (pré-dissertação), que tem como objetivo a investigação, desenvolvimento e implementação de uma interface entre uma aplicação desktop do cliente e a Web. É necessário ter em conta uma série de características específicas tais como escalabilidade, alta performance e segurança. Para atingir este objetivo serão implementados serviços Web para suportar a ligação entre as duas partes. Devido à complexidade e tamanho da aplicação em questão, será necessária a geração automática de todo o código da interface. A sua criação manual seria um uso ineficiente de recursos e não iria suportar futuras evoluções da aplicação.

Atualmente existem duas grandes arquiteturas para o desenvolvimento de serviços Web: uma baseada em Simple Object Access Protocol (SOAP) e outra em Representational State Transfer (REST). Neste documento de projeto de dissertação (pré-dissertação), além do estado da arte e do plano de trabalho da dissertação, também são discutidas as vantagens e desvantagens de cada uma das arquiteturas, ponderando-as de acordo com o tipo de aplicação e o contexto existente. Esse estudo permitiu tirar conclusões sobre o tipo de serviço Web mais indicado para ser usado, desenvolvido e aplicado durante o trabalho da dissertação.

Palavras-chave: Serviços web, Web API, SOAP, REST, SOAP vs REST.

vi

AbstractNowadays, hybrid applications that can manage the interactions between a desktop environment with Web functionalities and mobile devices are steadily gaining more and more importance. The purpose of this dissertation is to investigate, develop and implement an interface between the client’s desktop application and the Web. It is necessary to have in mind certain characteristics such as scalability, high performance and security. To achieve this goal, web services were chosen to establish the connection between these two parts. Due to the complexity and size of the application in question, the generation of all the code regarding the interface must be automatic, considering that creating it manually would not be feasible and would not support the guaranteed changes in the application which will occur in the near future.

At this time, two big architectures exist for developing web services, specifically Simple Object Access Protocol (SOAP) and Representational state transfer (REST). In this document, besides doing the state of the art and planning the work throughout the dissertation, the advantages and disadvantages of each architecture are discussed, considering the type of application and the its scope. This study lead to conclusions as to which Web service is the best to used, developed and implemented during the following work of the dissertation.

Keywords: Web services, Web API, SOAP, REST, SOAP vs REST.

vii

ÍndiceResumo.......................................................................................................iv

Abstract.......................................................................................................v

Lista de figuras.........................................................................................viii

Lista de Abreviaturas, Siglas e Acrónimos..................................................ix

1. Introdução.............................................................................................1

1.1. Enquadramento...............................................................................1

1.2. Problema e motivação.....................................................................1

1.3. Objetivos e resultados esperados....................................................2

1.4. Estrutura do documento..................................................................3

2. Revisão de literatura.............................................................................4

2.1. Serviços web SOAP..........................................................................6

2.2. Serviços web REST...........................................................................8

2.3. REST versus SOAP.........................................................................10

3. Abordagem metodológica...................................................................14

3.1. Design Science Research...............................................................15

3.2. Scrum solo.....................................................................................20

4. Plano de atividades.............................................................................23

5. Conclusões..........................................................................................26

Referências...............................................................................................28

viii

ix

Lista de figurasFigura 1- Tempo de resposta REST e SOAP (Tihomirovs & Grabis, 2016). 12Figura 2- Evolução das pesquisas relacionadas com SOAP e REST...........13Figura 3- Ciclos de Design Science Research (Hevner, 2007)...................15Figura 4- O ciclo de geração/teste. Adaptado de (Henver, Ram, & March, 2004).........................................................................................................19Figura 5- Fluxo do processo Scrum Solo. (Adaptada de Pagotto et al., 2016).........................................................................................................20Figura 6- Plano de atividades....................................................................23

x

Lista de Abreviaturas, Siglas e Acrónimos ERP - Enterprise Resource Planning; SOAP - Simple Object Access Protocol; REST - Representational state transfer; API - Application Programming Interface; WSDL - Web Services Description Language; HTTP - Hypertext Transfer Protocol; SMTP - Simple Mail Transfer Protocol; JMS - Java Message Service; XML- Extensible Markup Language; DSR - Design Science Research; TI - Tecnologias de Informação; SI - Sistemas de Informação;

xi

1.IntroduçãoEste capítulo tem como objetivo fazer o enquadramento do projeto, explicar o problema e a sua motivação, os objetivos e resultados esperados e, por fim, explicar o modo como o documento se encontra estruturado.

1.1. Enquadramento

O mundo reconhece, hoje cada vez mais, a importância de aplicações híbridas que consigam conjugar um ambiente desktop com partes de funcionalidades na Web e dispositivos móveis.

A Web está a sofrer uma transformação do que originalmente, era um conjunto de páginas, apresentando-se cada vez mais como um conjunto de serviços que interagem pela Internet. (Paolucci, Kawamura, Payne, &Sycara, 2002)

A utilização de Serviços web tem aumentado e, consequentemente, é importante que o tipo de Serviço web correto seja escolhido na fase de design do projeto. As implementações mais comuns são baseadas em SOAP (Simple Object Access Protocol) e REST (Representational state transfer protocol). (Tihomirovs & Grabis, 2016)

1.2. Problema e motivação

Os processos de negócio são o núcleo do mundo empresarial. Embora o número de serviços web esteja a crescer rapidamente, serviços web básicos com funcionalidades limitadas não estão a satisfazer os processos de negócio complexos. Para tal é necessário um conjunto diversificado de participantes para a composição de serviços web que descrevam estes processos de negócio complexos. Para o desenvolvimento de um composite web service, seria necessário codificar um cliente ou páginas da web para cada um dos processos, algo que iria requerer um grande acréscimo de trabalho e que teria pouca flexibilidade. (Ge & Wang, 2010)

1

Foi então considerada a geração automática deste código, para minimizar de maneira significante a carga de trabalho necessária.

No contexto específico do cliente, as principais motivações deste projeto foram:

Dar a aos seus clientes a possibilidade de aceder ao seu ERP (aplicação) através de qualquer dispositivo móvel, sem ter de o fazer a partir de uma máquina fixa, previamente preparada, com uma grande quantidade de dados armazenada;

Manter-se a par com os seus concorrentes; Permitir rapidamente criar interfaces com a web automaticamente,

de modo a que mudanças futuras na aplicação possam ser refletidas facilmente na interface.

1.3. Objetivos e resultados esperados

Neste capítulo são descritos os objetivos e resultados esperados das duas partes do trabalho que irá ser efetuado, a pré-dissertação e a dissertação.

O objetivo principal do presente documento de pré-dissertação é apresentar a revisão de literatura, a abordagem metodológica e o planeamento do trabalho. É entendido que:

Na secção da revisão de literatura seja demonstrado conhecimento acerca dos temas elacionados com o título do projeto (Serviços web SOAP, Serviços web REST e REST versus SOAP);

Na secção da abordagem metodológica seja explicada e justificada a utilização de abordagens de desenvolvimento (Scrum solo) e de investigação (DSR – Design Science Research);

Na secção do planeamento do trabalho sejam indicadas as tarefas principais que vão ser cumpridas ao longo do projeto, que visando organizar e fornecer métricas indicativas do estado de desenvolvimento do projeto.

Os objetivos da dissertação são:

2

Garantir a existência de uma camada que permita a ligação entre a Web e a aplicação desktop (ERP da PrimaveraBSS), que esteja dotada de um conjunto de atributos que permitam esta ligação. Desde logo é necessário que esta camada permita a ligação com um nível grande de segurança, que permita ligações sem estado (stateless), que não aceda a ficheiros físicos e registro do computador. Aliado a estes atributos deve ser capaz de responder aos pedidos com um elevado nível de performance e de capacidade (número de pedidos em simultâneo).

Disponibilizar UI capazes de se ligar a esta camada e de realizar provas que a apresentam como fiável e que que está de acordo com os requisitos. Para este trabalho é necessário um estudo sobre a forma de gerar as interfaces de forma automática a partir dos modelos já existentes (Winforms e c#). É necessário apontar um caminho para esta geração de interfaces com o maior automatismo possível.

Implementar com sucesso a ligação entre a aplicação desktop e a Web, que terá um grande impacto positivo no produto, adicionando um aumento da flexibilidade na utilização do mesmo.

Neste contexto de dissertação, complementarmente à descrição do trabalho, será também utilizada uma abordagem mais científica que contextualize e justifique as opções tomadas.

1.4. Estrutura do documentoA estrutura do presente documento é descrita nesta secção, de maneira sintetizada, oferecendo uma maior compreensão dos pontos essenciais referidos após o capítulo de introdução.

No segundo capítulo, revisão de literatura, é feito um levantamento de informação relevante ao tema abordado, descrevendo os métodos e recursos utilizados para cumprir esse objetivo.

No terceiro capítulo apresenta-se a abordagem metodológica, dividida em duas partes que têm como objetivo descrever as metodologias escolhidas,

3

uma para a investigação dos temas incluídos no âmbito do projeto, e outra, para o desenvolvimento da parte prática do projeto.

O quarto capítulo contém o plano de atividades, elaborado com a ajuda da ferramenta “Microsoft Project”, que descreve de maneira geral os objetivos a cumprir, as suas interdependências, uma estimativa de quanto tempo irão demorar e, consequentemente, uma data de conclusão. É também disponibilizada uma tabela que descreve a maior parte das tarefas presentes no plano.

Finalmente, no quinto capítulo, são apontadas as conclusões acerca do trabalho efetuado e descrito neste documento.

4

2.Revisão de literaturaPara que exista uma compreensão do tema foi necessária uma revisão de literatura, a partir da pesquisa de palavras chave “Web Api”, “Web services”, “REST”, “SOAP” e “REST vs SOAP”, na sua maior parte, feita no motor de busca Google Scholar e no IEEE Explorer.

Serviços web são uma nova geração de aplicações Web. Estas componentes de aplicações independentes são publicadas na Web de tal maneira que outras aplicações da Web as possam procurar e usar. Estão a levar a Web para o seu próximo estado de evolução, na qual componentes de software podem descobrir outros componentes de software e realizar operações de negócio. Exemplos de Serviços web incluem serviços de cartões de crédito que processam as transações para um determinado número de conta. (Roy & Ramanujan, 2001)

Um Serviço web consiste num serviço e descrição do mesmo onde o serviço é um módulo de software fornecido por um prestador de serviços, disponível através da Web. A descrição do serviço contém detalhes acerca da interface do serviço e implementações, incluindo tipos de dados, metadados, informação acerca da categorização e a localização de onde o serviço está exposto. (Tihomirovs & Grabis, 2016)

Segundo Gonçalves (Goncalves, 2009), Os serviços web requerem várias tecnologias e protocolos para transportar e transformar dados de um consumidor para um serviço numa maneira padrão. As mais aparentes são as seguintes:

Universal Description Discovery, and Integration (UDDI) é um mecanismo de registo e descoberta, semelhante às páginas amarelas, usado para armazenar e categorizar interfaces de Serviços web.

Web Services Description Language (WSDL) define interfaces com o Serviço web, dados e tipos de mensagem, interações e protocolos.

5

Simple Object Access Protocol (SOAP) é um protocolo de cifra de mensagens baseadas em XML, definindo uma espécie de envelope para a comunicação de Serviços web.

Mensagens são trocadas utilizando um protocolo de transporte. Embora Hypertext Transfer Protocol (HTTP) seja o protocolo de transporte mais adotado, outros, tais como Simple Mail Transfer Protocol (SMTP) ou Java Message Service (JMS) podem também ser usados.

Extensible Markup Language (XML) é a fundação básica na qual os Serviços web estão construídos e definidos.

As características de dispositivos móveis e plataformas desktop podem ser muito diversificadas. Devido a este aspeto, a interface do utilizador com o Serviço web precisa de ter flexibilidade e adaptabilidade para suportar as interações do utilizador. (He & Yen, 2007)

Nos próximos subcapítulos encontram-se os três temas principais que vão ser abordados na revisão de literatura:

Serviços web SOAP; Serviços web REST; SOAP versus REST.

Foi ponderada a inclusão de revisão de literatura acerca da geração do código, mas não foi incluída devido ao facto da sua simplicidade. Hoje em dia existem diversas ferramentas capazes de gerar um documento e os seus conteúdos.

6

2.1. Serviços web SOAP

Enquanto que existam dois computadores, existe uma dificuldade em fazer a comunicação entre si. Dezenas, possivelmente centenas, de estratégias emergiram, cada uma com as suas vantagens e desvantagens. No entanto, o resultado final é que no final de contas continua a haver dificuldade no acordo entre computadores para uma estratégia de comunicação. Toda a gente quer que o resto do mundo mude para a estratégia que satisfaz as suas necessidades. Consequentemente, acabamos com “Communication wars”, “COBRA vs. DCOM”, “DCOM vs. RMI”, “messaging vs. RPC”, etc... Para esta confusão de estratégias de comunicação vem o SOAP. SOAP não vem tentar resolver todos os problemas de comunicação; apenas define um formato simples baseado em XML de comunicação. Contudo, com este simples objetivo, e um poderoso mecanismo de extensibilidade, SOAP passar por ser uma verdadeira linguagem “cross-everything communication protocol-cross-programming” promissora, “cross-operating system” e “cross-platform”. Enquanto que o computador, sistema operativo ou linguagem de programação pudesse gerar e processar XML, pode fazer uso de SOAP. Desde a publicação inicial, quase todos os vendedores de software grandes produziram, anunciaram ou implementaram SOAP. Já foi constatado SOAP para Web servers, servidores de aplicações, ferramentas de comunicação, e middleware de comunicação. No futuro, SOAP será ainda mais predominante, à medida que empresas e organizações como a Microsoft, IBM, APACHE e Sun adicionarem cada vez mais suporte para as suas aplicações, sistemas operativos e linguagens de programação. (Seely& Sharkey, 2001)

Serviços web baseados em SOAP são desenhados com um protocolo baseado em XML. O objetivo é disponibilizar documentos legíveis à máquina com o intuito de passarem por qualquer tipo e vários protocolos de conexão para criar um sistema distribuído descentralizado. (Suda,2003)

7

Devido á natureza heterogénea dos Serviços web, que é originada da definição de vários “XML-based standards” para superar a sua dependência de plataforma e linguagem, os Serviços web tornaram-se numa tecnologia emergente e promissora para o design e construção de aplicações complexas de negócios, com origem em componentes únicos de software com base na Web. (Dustdar & Schreiner, 2005)

SOAP é fundamentalmente um paradigma de troca unilateral de mensagens stateless (sem estado), mas certas aplicações podem criar padrões de interação mais complexos (como por exemplo: request/response, request/multiple responses, etc.) combinando estas trocas de mensagens com características providenciadas por certos protocolos e/ou informação específica de aplicações. (Mitra & Lafon, 2007)

SOAP é um protocolo independente de plataforma, transporte e sistema operativo, tudo devido a ser construído utilizando sistemas de teste temporais tais como o protocolo HTTP e “text mark-up” em XML. (Suda,2003)

Segundo Ferris e Farrel (Ferris & Farrel, 2003), existem vantagens e desvantagens relacionadas com a utilização dos Serviços web.

Vantagens: o Os Serviços web tornam possível aos prestadores de serviços

e fornecedores a venda de serviços através da sua publicação da sua disponibilidade através da World Wide Web.

o A dissociação (“decoupling”) de interfaces de serviços de implementações e plataforma, a possibilidade de executar “dynamic service binding” e um passo para interoperabilidade de “cross-platform” e “cross-language”. Estes benefícios são originados pela interface standard XML e acesso a descrições dadas pela WSDL.

o Os Serviços web podem servir de ponte para aplicações que estão a ser executadas em plataformas diferentes, disponibilizar troca de informação de bases de dados e

8

permitem a distribuição de aplicações que foram desenhadas inicialmente para uso interno. Serviços web também encontraram um bom mercado quando são desenvolvidos como utilidades ou como componentes de programas “pay-per-use”.

Desvantagens:o A framework dos Serviços web estão dependentes nas

agências que anunciam a sua presença. Uma fraca implementação do mecanismo de descoberta pode resultar num enorme retrocesso para no alcance dos clientes e mercados.

o As especificações de interoperabilidade ainda não foram preparadas completamente. É necessário que a organização de interoperabilidade de Serviços web produza padrões para a interoperabilidade relativamente rápido. Estes ainda se encontram em desenvolvimento e precisam de ser completos e lançados para que outras camadas e componentes possam ir construindo a sua framework em cima deles.

9

2.2. Serviços web REST

REST é de diversas formas uma abstração retrospetiva dos princípios que fazem a “World Wide Web” escalável. (Muehlen, Nickerson, & Swenson,2005)

REST disponibiliza os seus serviços por meio de uma URL (Uniform Resource Location - Localização Uniforme de Recursos) inicial, a partir da qual a navegação é guiada conforme a lógica de negócios proposta, dotando orientações dinâmicas quanto à forma de construção e endereçamento dos requisitos, adotando um formato de comunicação maximizado que atenda às necessidades de cada aplicação. (Ribeiro &Francisco)

Segundo Fielding (Fielding, 2000), para que um Serviço web seja considerado REST são necessárias várias condições (arquitetura cliente-servidor, “Statless” (sem estado), “cache”, interface uniforme, sistema de camadas, código “on-demand” (a pedido)):

Arquitetura cliente-servidor: esta é a mais comum quando se trata de comunicação de dados em rede hoje em dia, e a sua popularidade pode ser percecionada através do fenómeno que é a expansão da World Wide Web. Uma definição de dicionário para cliente é um sistema ou programa que faz pedidos a uma ou mais atividades a outros sistemas ou programas, chamados servidores para executar certas tarefas; um servidor é um sistema ou programa que recebe um pedido por parte do cliente e consequentemente desempenha uma tarefa para suportar o cliente nas suas tarefas. (Hanson, 2000)

“Statless” (sem estado): é uma restrição à arquitetura cliente-servidor. Para que a comunicação entre as duas partes seja “stateless”, é necessário que cada pedido do cliente ao servidor contenha toda a informação necessária para que o servidor consiga entender e processar o pedido, não tirando partido de qualquer tipo de contexto armazenado no servidor. Desse modo o estado da sessão estará sempre guardado do lado do cliente. (Fielding, 2000)

10

Cache: é uma restrição de adoção facultativa, que tem como objetivo melhorar a eficiência da comunicação em rede. Ao adicionar a cache a um Serviço web passa a existir a possibilidade da reutilização de dados guardados na cache do cliente, caso os dados que o cliente pediu já estejam armazenados em cache, não é perdido tempo com o reenvio dos mesmos pelo servidor. Existe, porém, uma desvantagem na utilização da cache, a redução da confiabilidade dos dados, já que os dados armazenados em cache, por vezes podem não corresponder aos dados existentes do lado do servidor.

Interface uniforme: é, de todas as condições, a que distingue a arquitetura REST de outras. Através da aplicação do princípio da generalização de engenharia de software ao componente da interface, a arquitetura do sistema é simplificada e a visibilidade das interações disponíveis é melhorada. No entanto esta vantagem vem com uma desvantagem: a perda de eficiência. Este aspeto resulta na característica de interfaces REST serem desenhadas de maneira eficiente para contextos de grande escala, estando otimizadas para os casos gerais, mas não para casos específicos. Para atingir uma interface uniforme são necessárias quarto condições:

o Identificação de recursos;o Manipulação de recursos através de representações;o Mensagens que se descrevam a si próprias;o Hipermédia como motor do estado da aplicação.

Sistema em camadas: para obter melhorias operacionais, Fielding (2000) propôs a divisão do sistema em camadas, possibilitando a existência de uma hierarquia, restringindo o acesso de partes diferentes, a menos que seja necessário. Este aspeto vem melhorar a segurança, organização, escalabilidade e desempenho em geral do Serviço web.

Código “on-demand” (a pedido): é a funcionalidade optativa que permite estender as funcionalidades por parte do cliente através de downloads e/ou execução de código provenientes de

11

applets ou scripts. Isto cria uma certa flexibilidade na parte do cliente, na medida em que quando é feito, não necessita ter todas as funcionalidades implementadas à partida, possibilitando assim, a sua extensibilidade.

12

2.3. REST versus SOAP

As abordagens SOAP e REST lidam com interações de serviços de maneiras bastante diferentes. SOAP é uma framework padrão para a construção e processamento de mensagens independentes das capacidades tecnológicas do recipiente e pode funcionar sobre uma vasta variedade de camadas de protocolos de aplicações tais como RPC (Rate Control Protocol), HTTP (Hypertext Transfer Protocol) ou SMTP (Simple Mail Transfer Protocol), enquanto que REST é um conjunto de princípios para o design de aplicações Web (usando HTTP como protocolo de comunicação). (Potti, Ahuja, Umapathy, & Prodanoff, 2012)

Segundo Muehlen, Nickerson e Swenson (Muehlen, Nickerson, & Swenson,2005), as vantagens e desvantagens de abordagens baseadas em REST ou SOAP podem ser sumarizadas na seguinte tabela:

Tabela 1- Características de REST e SOAP (Adaptado de Muehlen, Nickerson, & Swenson (2005))

REST SOAPCaracterísticas Operações são definidas

nas mensagensOperações são definidas como “WSDL ports”

Cada instância de processo tem um endereçamento único

Cada operação tem um endereçamento único

Cada objeto suporta as operações (padrão) definidas

Múltiplas instâncias de processos partilham a mesma operação

Acoplamento folgado de componentes

Acoplamento justo de componentes

Vantagens reclamadas pelos autores

É possível fazer “late binding”

É possível fazer debug

Instâncias de processos são criadas explicitamente

Operações complexas podem ser escondidas por detrás de uma máscara

O cliente não necessita de informação de routing para além do URI inicial

Wrapping de APIs existentes é claro e direto.

O cliente tem uma “interface listener“

Há mais privacidade

13

genérica para notificações Possíveis desvantagens

Número grande de objetos O cliente necessita de saber as operações e as suas semânticas previamente

Gerir o namespace do URI pode-se tornar trabalhoso

O cliente precisa de portas diferentes para diferentes tipos de notificaçãoInstâncias de processos são criadas implicitamente

Outra tabela proposta por Wagh e Thool (Wagh & Thool, 2012) está a seguir representada. Tem como objetivo fazer a comparação geral entre REST e SOAP.

SOAP RESTÉ uma tecnologia tradicional bem conhecida.

É uma tecnologia nova, comparando a SOAP.

No contexto empresarial e B2B (Business to Business), SOAP continua a ser bastante atrativo

Isto não implica que REST não esteja preparado para empresas. Pelo contrário, são conhecidas implementações de sucesso em áreas tal como a banca.

Em SOAP, as interações Cliente-Servidor são “tightly coupled”

Em REST, as interações Cliente-Servidor são “loosely coupled”.

No caso de implementação, SOAP tem a vantagem da existência de kits de desenvolvimento.

Mas os desenvolvedores de REST argumentam que esses kits levam a uma inflexibilidade de interface.

Mudar os serviços em “SOAP web provisioning” significa frequentemente uma mudança de código complicada no lado do cliente.

Mudar os serviços em “REST web provisioning” não requer qualquer mudança do lado do cliente.

SOAP tem uma carga mais pesada comparado com REST

REST é definitivamente leve na transferência de dados.

Requer “binary attachment parsing” Suporta todos os tipos de dados diretamente

SOAP não favorece uma infraestrutura wireless

REST favorece uma infraestrutura wireless

Serviços web SOAP retornam sempre XML

Serviços web são flexíveis no que toca a dados devolvidos.

Consome mais largura de banda Consome menos largura de banda devido à sua natureza

14

leve.Pedidos SOAP usam POST e necessitam um pedido complexo XML para ser criado, o que leva a uma difícil captura de respostas

APIs RESTful podem ser consumidas usando um simples pedido GET, servidores intermédios de proxy podem facilmente colocar as suas respostas em cache.

Concebido para lidar com ambientes de computação distribuída

Assume um modelo de comunicação ponto-a-ponto - não para ambientes de computação distribuída onde as mensagens podem passar por múltiplos intermediários.

Mais difícil desenvolver, necessita ferramentas

Muito mais simples para desenvolver Serviços web.

Pressuposto falso: SOAP é mais seguro. SOAP utiliza WS-security. WS-security foi criado porque devido a SOAP ser “transport-independant”, pressupostos não podiam ser feitos acerca da segurança disponível na camada de transporte.

REST assume que o transporte será feito em HTTP (ou HTTPS) e que os mecanismos de segurança que estão embebidos no protocolo estarão disponíveis.

É o padrão para Serviços web e, por isso, tem mais suporte de outros padrões (WSDL, WS) e vendedores.

Falta suporte padrão para segurança, política, envio de mensagens confiável, etc., consequentemente os serviços precisam de ter requisitos mais sofisticados.

Segundo Tihomirovs e Grabis (Tihomirovs & Grabis, 2016), REST é mais aconselhado se o projeto necessitar de grande escalabilidade, compatibilidade e performance. A complexidade de implementação, velocidade de execução, memória consumida e performance são melhores que o protocolo SOAP. Conclui-se assim que, se o projeto requirir uma integração simples de ponto a ponto ou uma disponibilidade de grande escala para dispositivos móveis, REST é a escolha mais adequada. No entanto, SOAP é uma escolha melhor, caso o projeto necessite de segurança e confiança, manutenção mais fácil do lado do cliente tal como menor possiblidade de erros. Para além disso, vários projetos de integração de sistemas de negócio necessitam pedidos de processamento de dados assíncronos, a vantagem de SOAP. Em conclusão, SOAP é mais adequado para integrações de sistemas com

15

grandes quantidades de informação, tal como projetos de integração de sistemas de informação no ambiente bancário. Adicionalmente foram efetuados testes ao tempo de resposta de ambos SOAP e REST nas quatro mais relevantes funcionalidades de um Serviço web, apresentados na figura seguinte (figura 1).

16

Foi efetuada uma pesquisa no “Google Trends” para se apurar o desenvolvimento das pesquisas a nível mundial entre REST e SOAP, observando-se claramente o protocolo REST a ultrapassar o protocolo SOAP em termos de popularidade no ano 2011. Estes dados ilustram a descoberta de uma nova abordagem aos Serviços web.

Em conclusão, após a investigação decorrida durante a revisão de literatura, existe uma forte inclinação para a seleção da abordagem REST devido maioritariamente à facilidade de escalabilidade (um aspeto importante tendo em conta o tamanho e complexidade da aplicação em questão), à maior rapidez de resposta (representado na figura 1), por ser mais recente e pelo facto de o cliente do lado da interface não ter de fazer alterações caso exista uma mudança da interface (algo que inevitável no decorrer do ciclo de vida da aplicação).

17

3.Abordagem metodológicaTendo em conta a natureza da proposta feita, serão necessárias duas abordagens metodológicas, uma para a investigação dos temas incluídos no âmbito do projeto, e outra, para o desenvolvimento da parte prática do projeto.

Para a parte de investigação será utilizada a metodologia “Design Science Research” por ser tipicamente aplicada em engenharia e ciências computacionais, em várias categorias, tais como a interface de pessoas com computadores e, adicionalmente, por fornecer diretrizes para avaliação e iteração de projetos de investigação.

O cliente deste projeto é a PrimaveraBSS, uma empresa de desenvolvimento de software em que todas as equipas de desenvolvimento de software fazem uso da framework ágil “Scrum”. À partida, faria sentido a utilização desta mesma abordagem metodológica no decorrer deste projeto, já que o trabalho será feito nas instalações da empresa, no entanto, o “Scrum” foi desenhado para equipas de duas ou mais pessoas. Face a esta limitação e a existência de uma necessidade, um grupo de quatro autores brasileiros idealizaram uma metodologia semelhante, o “Scrum solo”, a escolhida para desenvolver a parte prática do projeto.

18

3.1. Design Science Research

Investigação no campo das tecnologias de informação necessita abordar as tarefas de design por parte dos investigadores. Os problemas precisam ser conceitualizados e representados, é preciso utilizar técnicas apropriadas para a sua solução, e as soluções precisam ser implementadas e avaliadas utilizando critérios e métricas apropriadas. No caso da previsão da existência de um grande progresso, a investigação no campo das tecnologias de informação necessita também desenvolver uma compreensão do como e do porquê do facto de um sistema de tecnologia de informação funcionar ou não. (March & Smith, 1995)

Segundo Hevner (Hevner, 2007), existem três ciclos de Design Science Research (DSR) (ilustrados na figura seguinte):

19

Figura 3- Ciclos de Design Science Research (Hevner, 2007)

Ciclo da relevância: O âmbito de aplicação de DSR consiste nas pessoas, sistemas organizacionais e sistemas técnicos que interagem para chegarem a um objetivo. Bons exemplos de DSR começam tipicamente, pela identificação e representação de oportunidades e problemas no âmbito de aplicação.

Ciclo do rigor: A fundação de uma Design Science Research rigorosa tem origem na vasta base de teorias científicas e métodos de engenharia. O rigor da Design Science Research é dependente da boa seleção da aplicação das teorias e métodos para construção e validação de artefactos corretos por parte do investigador. Também com grande importância, a base de conhecimento tem dois tipos de conhecimento adicionais:

o As experiências e conhecimentos que definem o estado da arte nodomínio de aplicação da pesquisa.

o A existência de processos e artefactos encontrados no domínio da aplicação.

Ciclo do design: O cerne de qualquer projeto de Design Science Research é o ciclo interno de design. Este ciclo de atividades de investigação itera mais rapidamente entre a construção de um artefacto, a sua avaliação e consequente feedback para refinar cada vez mais o design. Durante o desenvolvimento do ciclo de design é importante manter o balanço entre os esforços gastos em construção e validação do artefacto em evolução. Ambas as atividades devem ser baseadas na relevância e rigor.

Segundo Henver (Henver, Ram, & March, 2004), existem sete diretrizes que devem ser abordadas na DSR, sintetizadas na tabela seguinte e algumas com mais detalhe na próxima secção.

Tabela 2- Diretrizes de DSR. Adaptado de (Henver, Ram, & March, 2004)

Diretriz DescriçãoDesign do artefacto Para DSR é necessária a produção de um

artefacto viável na forma de um conceito, modelo, método ou instanciação.

20

Relevância do problema

O objetivo da DRS é o desenvolvimento de soluções baseadas em tecnologia para problemas de negócios importantes e relevantes.

Avaliação de design A utilidade, qualidade e eficácia do design de um artefacto necessita ser demonstrado rigorosamente através de bons métodos de avaliação.

Contributos da investigação

Uma DSR eficaz exige a estabelecer uma lista de contribuições clara e comprovável nas áreas do design do artefacto, das fundações e/ou das metodologias.

Rigor da investigação DSR recorre à aplicação de diversos métodos em ambas a construção e avaliação do design do artefacto.

Design como um processo de pesquisa

A procura de um artefacto eficaz requer a utilização de meios disponíveis para atingir a sua finalidade enquanto satisfazendo as regras no ambiente do problema.

Comunicação de investigação

DSR precisa ser apresentada efetivamente tanto como para audiências com orientação tecnológica e de gestão.

3.1.1. Relevância do problemaO objetivo da investigação na área de sistemas de informação é a aquisição de conhecimento e compreensão que permite o desenvolvimento e implementação de soluções baseadas em tecnologia, que até à data não tinham solução, e problemas de negócio importantes.

A relevância de qualquer esforço de DSR diz respeito à comunidade a que se aplica. Para investigadores de sistemas informáticos, essa comunidade é constituída pelos praticantes que planeiam, gerem, desenham, implementam, operam e avaliam sistemas de informação e os quais planeiam, gerem, desenham, implementam, operam e avaliam as tecnologias que permitem o seu desenvolvimento e implementação. Para ser relevante para esta comunidade, os investigadores necessitam abordar os problemas que encontram e as oportunidades proporcionadas pela interação de pessoas, organizações e tecnologias da informação. (Keil, 1995)

21

3.1.2. Avaliação de designA utilidade, qualidade e eficácia de um artefacto requer uma demonstração rigorosa tendo em vista a boa execução de métodos de avaliação.

O design é uma atividade inerentemente iterativa e incremental. A fase de avaliação providencia feedback essencial para a fase de construção tal como para a qualidade do processo de design e do produto em desenvolvimento. O design de um artefacto é completo e efetivo quando satisfaz os requisitos e restrições do problema que pretende resolver. Os esforços de DSR podem começar com conceitualizações simplificadas e representações de problemas. À medida que os ambientes tecnológicos e de negócio mudem, os pressupostos feitos anteriormente podem tornar-se inválidos. (Johansson, 2000)

A avaliação do design de artefactos, tipicamente, utiliza metodologias disponíveis. Estas estão descritas na tabela seguinte. Na seleção de métodos de avaliação, devem ser devidamente emparelhados os artefactos desenhados e as métricas de avaliação. Por exemplo, métodos descritivos de avaliação devem ser apenas utilizados para artefactos inovadores para os quais outras formas de avaliação podem não ser viáveis. A boa qualidade e a eficácia de um artefacto podem ser rigorosamente demonstradas visando a boa seleção de métodos de avaliação. (Basili, 1996)

Tabela 3- Métodos de avaliação de design. Adaptado de (Henver, Ram, & March, 2004)

Observativo Caso de estudo: Estudo do artefacto em profundidade no âmbito do negócioCaso prático: Monitorização do uso do artefacto em diversos projetos.

Analítico Análise estática: Exame da estrutura do artefacto para qualidades estáticas (por exemplo: complexidade)Análise da arquitetura: Enquadramento de estudo do artefacto em arquiteturas técnicas de sistemas de informação.Análise da dinâmica: Estudo do artefacto em uso para qualidades dinâmicas (por exemplo:

22

performance)Experimental Experiências controladas: Estudo das qualidades do

artefacto em ambientes controlados. (por exemplo: usabilidade)Simulação: Execução do artefacto com data artificial.

Teste Teste funcional (“Black Box”): Execução das interfaces do artefacto com intenção de descobrir falhas e identificar defeitos.Teste estrutural (“White Box”): Testar a abrangência de certas métricas (por exemplo: “execution paths”) na implementação do artefacto.

Descritivo Argumentação sustentada: Uso da informação disponível (por exemplo: estudos relevantes) para a construção de um argumento convincente para a utilidade do artefacto.Cenários: Construção de cenários detalhados relacionados com o artefacto para demonstrar a sua utilidade.

3.1.3. Rigor da investigação DSR recorre à aplicação de diversos métodos tanto na construção como na avaliação do design do artefacto.

O destaque excessivo no rigor da investigação em comportamento de sistemas de informação tem resultado frequentemente na correspondente redução da relevância (Lee, 1999).

A DSR apoia-se, normalmente, num formalismo matemático para descrever o artefacto especificado e construído. No entanto, os ambientes nos quais os artefactos de TI necessitam desempenhar as suas funcionalidades e mesmo os próprios artefactos podem resistir ao excessivo formalismo. Ou, numa tentativa de ser matematicamente rigoroso, partes importantes do problema podem ser abstraídas. Em particular, no que faz respeito à atividade de construção, é imperativo que o rigor seja avaliado com respeito à aplicabilidade e generalização do artefacto. (Applegate, 1999)

3.1.4. Design como um processo de pesquisa

O design é essencialmente o processo de procura de uma solução efetiva para o problema. Resolução de problemas pode ser visto como a

23

utilização de meios disponíveis para atingir um fim enquanto satisfazendo as regras do ambiente. (Simon, 1996)

Na figura seguinte por (Henver, Ram, & March, 2004) a natureza do processo de design é descrita como um ciclo de geração/teste.

O

conjunto de possíveis soluções de design para qualquer problema é indicado como todos os meios possíveis para satisfazer todas as condições finais consistentes com as leis existentes. Quando estes podem ser formulados apropriadamente e representados matematicamente, técnicas de investigação padrão podem ser usadas para determinar uma solução ótima para as condições finais. Dada a estranha natureza de diversos problemas de design de sistemas de informação, pode não ser possível determinar nem descrever explicitamente os meios, fins ou regras relevantes. (Vessey & Glass, 1998) Mesmo quando é possível fazê-lo, a complexidade e tamanho da solução fará com que o problema não seja viável. Por exemplo, contruir uma “infraestrutura de sistemas de informação que seja segura, responsiva e fiável”, é um dos problemas mais frequentes com que os gestores de SI se deparam. (Barcheau, Brian,& Wetherbe, 1996)

24

Figura 4- O ciclo de geração/teste. Adaptado de (Henver, Ram, & March,2004)

25

3.2. Scrum solo

Este trabalho foi originado pela necessidade da existência de uma metodologia para desenvolvimento de software para indivíduos a solo e para um grande mercado no Brasil, sendo que, em 2012, cerca de 60% das empresas de software no mercado Brasileiro iniciavam as suas atividades com apenas um developer.

“… o Scrum Solo surge como uma personalização do processo Scrum voltada para o desenvolvimento individual de software.” (Nunes, 2016)

Como esperado, ambos os fluxos do processo são semelhantes, no entanto existem algumas diferenças que irão ser evidenciadas seguidamente na descrição das atividades, atores e artefactos existentes no Scrum solo. Em todas as tarefas serão gerados artefactos, logo é aconselhada a utilização de um repositório do processo que tem como função o armazenamento na cloud de todos os artefactos.

A. Atividades Requirements: tem como objetivo definir o âmbito do

produto, o product backlog e, se possível, um protótipo de software. Estes objetivos serão atingidos com a ajuda do input

26

Figura 5- Fluxo do processo Scrum Solo. (Adaptada de Pagotto et al., 2016)

do cliente e orientador que irão auxiliar o developer a atingir a sua meta.

Sprint: tem como objetivo desenvolver um conjunto de tarefas provenientes do product backlog (no espaço de uma semana). Baseado nestas tarefas e no protótipo de software, o developer, com a possível ajuda do orientador, irá executá-las, originando numa parte do produto, no sprint backlog e numa ata.

Deployment: tem como objetivo entregar a parte do produto desenvolvida no sprint anterior ao cliente.

Management: tem como objetivo gerir o estado do produto. Utilizando o product backlog como base, o developer, o cliente e o orientador terão a tarefa de discutir como se deverá proceder. Esta atividade tem como output a estrutura analítica do projeto (EAP), um cronograma e uma tabela de custos.

B. Atores Product owner: trata-se do proprietário do produto. Pode ser

constituído por um ou muitos indivíduos que irão interagir com o produto como por exemplo: gestores, contabilistas ou, simplesmente, pessoas que entram em contacto com o produto.

Solo developer: trata-se da pessoa responsável por gerar o produto, seguindo o processo de desenvolvimento de software.

Orientador: trata-se do indivíduo que irá ajudar a guiar o developer no processo de desenvolvimento.

Grupo de validação: trata-se dos utilizadores finais do produto que têm como objetivo avaliar o produto e dar feedback.

C. Artefactos Scope: serve para caracterizar o âmbito do processo e os

aspetos inerentes ao mapeamento dos problemas do produto

27

owner, descrevendo onde o produto irá atuar, o perfil do cliente e os requisitos funcionais.

Protótipo de software: consiste em imagens da interface do utilizador com o produto. É aconselhada a utilização do formato “.png” e apontar o nome do item do product backlog que representa a imagem.

Product backlog: é uma lista de funcionalidades que devem ser implementadas no software. Cada linha desta lista deve conter um código de funcionalidade, descrição, data de inserção e data de seleção para o sprint backlog.

Repositório do processo: serve para armazenar todos os documentos relativos a todo o processo de desenvolvimento do produto na cloud. É importante que o developer organize bem as pastas do repositório e siga um conjunto de regras para o efeito.

Sprint backlog: é uma lista de todas as funcionalidades que devem ser implementadas num determinado sprint. O sprint backlog deve também armazenar o código das funcionalidades.

Produto ou parte em funcionamento: uma versão do produto que dê ao cliente a possibilidade de obter um retorno pelo investimento previamente feito no momento que pediu o seu desenvolvimento.

Ata: serve para registar os momentos em que uma funcionalidade é implementada. Utilizada no sprint e na entrega: no sprint, a funcionalidade é validada pelo orientador; na entrega é validada pelo cliente.

Planta de desenvolvimento: tem como objetivo juntar os artefactos usados na especificação das funcionalidades. O Scrum solo sugere o uso de diagramas de casos de uso, sequência, classes e entidade e relacionamento, existindo sempre a possibilidade de serem usados outros, caso seja necessário para o caso.

28

Estrutura analítica do projeto: uma estrutura hierárquica que subdivide o trabalho de um projeto em componentes menores e mais facilmente legíveis.

Cronograma: tem como objetivo organizar sequencialmente os pacotes de trabalho dentro de um determinado espaço de tempo. Pode-se apontar o responsável pela execução de cada atividade. É sugerido a utilização do cronograma no formato de diagrama de Gantt.

Tabela de custos: tem como objetivo mapear o custo efetivo gerado durante a execução do projeto para poder ser comparada com o orçamento realizado previamente.

(Pagotto, Fabrti, Lerario, & Gonçalves, 2016)

29

4.Plano de atividadesDe modo a garantir que os objetivos desta dissertação são atingidos, foi elaborado um plano de atividades. Este pretende representar o fluxo de trabalho ao longo do tempo, tendo em conta as datas de entrega, para que facilmente sejam identificados atrasos ou adiantos no desenvolvimento do trabalho.

Este plano (representado na seguinte figura) foi elaborado na ferramenta “Microsoft Project” e é dotado de atividades, com datas de começo e fim, tendo em conta a estimativa da duração das tarefas (em dias) e as suas dependências.

30

Figura 6- Plano de atividades

A figura é dotada de uma tabela, com as seguintes colunas:

Task Name: descreve o nome da tarefa. Duration: duração desde o início da tarefa, até ao fim da mesma

(Finish - Start). Start: data de começo da tarefa. Finish: data de fim da tarefa. Preferences: as precedências indicam quais as tarefas anteriores

precisam de estar completas para que uma tarefa seja iniciada. Duration2: duração efetiva estimada necessária para completar a

tarefa.

A tabela seguinte foi elaborada com o propósito de esclarecer os detalhes de algumas das tarefas a ser efetuadas. Durante todas as atividades está implícita a participação/validação dos orientadores e durante todas as atividades relacionadas com o desenvolvimento de software, está incluído no tempo disponível para a sua execução tempo para testar a funcionalidade e o seu registo para que a escrita do relatório seja facilitada e eficiente.

31

Tabela 4- Descrição de tarefas do planeamento

Atividade DescriçãoPré dissertação Trabalho realizado no primeiro semestre.Elaboração do relatório de pré dissertação

Primeira iteração da elaboração do relatório de pré dissertação.

Formação Entrar em contacto com a empresa para obter informação acerca dos requisitos, ferramentas e horários de trabalho. Durante esta atividade o relatório de pré dissertação deve ser atualizado.

Dissertação Trabalho realizado no segundo semestreGerar código da interface Criar um programa que consiga gerar o

código necessário para fazer a interface entre a aplicação e a Web.

Desenvolver exemplos genéricos

Para compreender o que vai ser gerado, é preciso criar exemplos funcionais para um caso específico.

Explorar estratégias de geração de código

Encontrar uma maneira específica de gerar código que sirva para o efeito.

Criar projeto para gerar código da interface

Tarefa que representa o desenvolvimento de um programa que gere interfaces, todas as suas sub-tarefas são funcionalidades do mesmo.

Ler todos os métodos da aplicação

Existem milhares de métodos na aplicação (ERP da PrimaveraBSS), é preciso percorrer todos os métodos para os converter.

Converter métodos Ao iterar por cada método, desenvolver o código que gera a respetiva interface.

Gerar código Correr o programa de geração de código, identificar erros específicos e corrigi-los.

Adicionar Funcionalidades Adicionar funcionalidades (representadas como sub-tarefas) ao projeto da interface para onde o código foi gerado previamente.

32

5.ConclusõesO trabalho de dissertação tem como finalidade a implementação de uma ferramenta de geração automática de interfaces entre aplicações Web e uma dada aplicação desktop. Para atingir esse objetivo foi necessário fazer um estudo sobre os temas subjacentes de modo a garantir a melhor solução no desenvolvimento dessa camada de interface. Conforme definido nos objetivos enunciados na introdução deste documento, foi efetuada a revisão do estado da arte e feito um estudo comparativo entre as duas principais arquiteturas de interface entre aplicações web e aplicações desktop. Além disso foi apresentado o planeamento do trabalho de dissertação em curso.

Para a revisão de literatura mencionada na introdução, foram pesquisados artigos relacionados com os tópicos “Serviços web”, “Web API”, “REST”, “SOAP”, “REST versus SOAP” e “Geração de interfaces”. O estudo dos artigos considerados relevantes constituiu a revisão do estado da arte que contextualiza o trabalho.

Da investigação decorrida durante a revisão de literatura, resultou uma forte inclinação para a seleção da abordagem REST devido principalmente à facilidade de escalabilidade (um aspeto importante tendo em conta o tamanho e complexidade da aplicação em questão), à maior rapidez de resposta (representado na figura 1), por ser mais recente e pelo facto de o cliente não ter de fazer alterações caso exista uma alteração da interface (algo que irá ser frequente no decorrer do ciclo de vida da aplicação).

Este projeto tem uma forte componente prática de desenvolvimento de software, pelo que na secção reservada à metodologia de trabalho, foram apresentadas tanto a metodologia de investigação como a metodologia de desenvolvimento de software.

O planeamento do trabalho foi elaborado com o intuito de estruturar, organizar e dividir a carga de trabalho disponível de maneira uniforme ao

33

longo do tempo de projeto, de modo a que este seja concluído dentro do prazo previsto para a entrega do documento final de dissertação do Mestrado Integrado em Engenharia e Gestão de Sistemas de Informação da Universidade do Minho. Para a representação das tarefas foi utilizada a ferramenta Microsoft Project e foi criado um diagrama de Gantt, para promover a fácil visualização do decorrer das tarefas. É também apresentada uma tabela que visa descrever as atividades previstas.

Até este momento o plano está a ser integralmente cumprido e já foram efetuados com sucesso protótipos de geração automática dos serviços web, o que aumenta drasticamente grau de confiança no plano efetuado.

34

ReferênciasApplegate, L. M. (1999). Rigor and Relevance in MIS Research -

Introduction. MIS Quarterly.

Barcheau, J. C., Brian, J. D., & Wetherbe, J. C. (1996). Key issues in information systems management: 1994-95 SIM Delphi results. MIS quarterly.

Basili, V. (1996). Basili, Victor R. "The role of experimentation in software engineering: past, current, and future. IEEE Computer Society.

Dustdar, S., & Schreiner, W. (2005). A survey on web services composition.

Ferris, C., & Farrel, J. (2003). What are web services? ACM.

Fielding, R. T. (2000). Architectural Styles and the Design of Network-based Software Architectures.

Ge, Z., & Wang, X. (2010). A framework for automatic generation of composite web service user interface. Kunming, China: IEEE.

Goncalves, A. (2009). "SOAP Web Services." Beginning Java™ EE 6 Platform with GlassFish™ 3: From Novice to Professional.

Hanson, M. D. (2000). The Client/Server Architecture.

He, J., & Yen, I.-L. (2007). Adaptive User Interface Generation for Web Services. Hong Kong, China: IEEE.

Henver, A. R., Ram, S., & March, S. T. (2004). Design Science in Information. MIS Quarterly.

Hevner, A. R. (2007). A three cycle view of design science research.

Johansson, J. (2000). Johansson, Jesper M. "On the impact of network latency on distributed systems design.

Keil, M. (1995). Pulling the plug: Software project management and the problem of project escalation.

35

Lee, A. (1999). Inaugural Editor's Comment. Mis Quarterly.

Management, K. I. (1987). James C. Brancheau; James C. Wetherbe. MIS Quarterly.

March, S. T., & Smith, G. F. (1995). Design and natural science research on information technology.

Mitra, N., & Lafon, Y. (2007). SOAP Version 1.2 Part 0: Primer.

Muehlen, M. z., Nickerson, J. V., & Swenson, K. D. (2005). Developing web services choreography standards—the case of REST vs. SOAP.

Nunes, L. M. (2016). Sistemas de gerenciamento de heurística de usabilidade.

Pagotto, T., Fabrti, J. A., Lerario, A., & Gonçalves, J. A. (2016). Scrum solo: Software process for individual development. Las Palmas, Spain: IEEE.

Paolucci, M., Kawamura, T., Payne, T. R., & Sycara, K. (2002). Semantic matching of web services capabilities.

Potti, P. K., Ahuja, S., Umapathy, K., & Prodanoff, Z. (2012). Comparing Performance of Web Service .

Ribeiro, M. F., & Francisco, R. E. (s.d.). Web Services REST.

Roy, J., & Ramanujan, A. (2001). Understanding Web Services.

Seely, S., & Sharkey, K. (2001). SOAP: Cross Platform Web Service Development Using XML. Prentice Hall PTR.

Simon, H. (1996). The sciences of the artificial. MIT press.

Suda, B. (2003). SOAP Web Services.

Tihomirovs, J., & Grabis, J. (2016). Comparison of SOAP and REST based Web services using software evaluation metrics.

Vessey, I., & Glass, R. (1998). Vessey, Iris, and Robert Glass. "Strong vs. weak approaches to systems development. New York, NY, USA :

36

ACM.

Wagh, K., & Thool, R. (2012). A Comparative Study of SOAP Vs REST Web Services Provisioning Techniques for mobile Host.

37