INTEGRA: Uma solução para integração de sistemas de ... · UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE INSTITUTO METRÓPOLE DIGITAL PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA

UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE

INSTITUTO METRÓPOLE DIGITAL

PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA DE

SOFTWARE

INTEGRA: Uma solução para integração desistemas de HelpDesk com sistemas de Issue

Tracking em ambientes heterogêneos.

Eduardo Lima Ribeiro

Orientador: Prof. Dra. Idalmis Milian Sardina Martins

Co-orientador: Prof. Dr. Frederico Araujo Da Silva Lopes

Dissertação apresentada ao Programa dePós-Graduação em Engenharia de Softwareda UFRN para obtenção do título de Mestreem Engenharia de Software.

Área de concentração:Engenharia de Sistemas WEB

Natal-RN, 24 de Agosto de 2016

Catalogação da Publicação na Fonte

Universidade Federal do Rio Grande do Norte - Sistema de BibliotecasBiblioteca Central Zila Mamede / Setor de Informação e Referência

Ribeiro, Eduardo Lima.Integra: uma solução para integração de sistemas de HelpDesk com sistemas

de Issue Tracking em ambientes heterogêneos / Eduardo Lima Ribeiro. - 2016.61 f. : il.

Dissertação (Mestrado) - Universidade Federal do Rio Grande do Norte, Insti-tuto Metrópole Digital, Programa de Pós-Graduação em Engenharia de Software.Natal, RN, 2016

Orientadora: Profa. Dra. Idalmis Milian Sardina Martins.Co-orientador: Prof. Dr. Frederico Araújo da Silva Lopes

1. Sistemas distribuídos - Dissertação. 2. Interoperabilidade - Dissertação. 3.Arquitetura orientada a serviços - Dissertação. 4. Desenvolvimento de softwares- Dissertação. 5. Planejamento estratégico - Dissertação. I. Martins, IdalmisMilian Sardina. II. Lopes, Frederico Araújo da Silva. III. Título.

RN/UF/BCZM CDU 004.75

INTEGRA: Uma solução para integração desistemas de HelpDesk com sistemas de Issue

Tracking em ambientes heterogêneos.

Eduardo Lima Ribeiro

Dissertação de Mestrado aprovada em 24 de agosto de 2016 pela banca examinadoracomposta pelos seguintes membros:

Profa Dra. Idalmis Milian Sardina Martins (orientadora) . . . . . . . . . . . Presidente

Prof. Dr. Frederico Araújo Lopes (co-orientador) . . . . . . . . . . . . . . . Examinador

Prof. Dr. Uirá Kulesza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examinador

Prof. Dr. Cristiano Maciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Examinador

Dedico este trabalho a minhasobrinha especial Juju, que Deusilumine sua mente e cuide de sua

saúde mais que tudo neste mundo!Te amo Juju.

Agradecimentos

Primeiramente a Deus, o todo poderoso que me iluminou e me abençoou por toda minhatrajetória por onde eu tenho andado.

À minha grande família pelo apoio durante esta jornada, ao meu amado pai Eliésio, Mi-nha amada e idolatrada mãe Angela, meus grandes irmãos Diorgenis e Junior, A minhasobrinha mais que especial Juju e ao meu grande amor Jéssyca Ataliba por todo apoiodado nesta jornada.

Ao meu orientador e ao meu co-orientador, professores Idalmis e Frederico, sou muitograto pela orientação e dedicação por todo este tempo.

Ao professor e amigo Ricardo Valentim por sempre me apoiar nas minhas empreitadasacadêmicas.

Aos meus grandes amigos Júlio Silva e Pierre Freire pelas sugestões, ajudas e críticasdeste trabalho.

Resumo

As organizações públicas e privadas vêm se adaptando às mudanças tecnológicasconstantemente devido as necessidades de negócio independente de sua área de atuação,seja com a adaptação às melhores práticas de mercado ou com a atualização constantede suas tecnologias dado o ritmo das inovações. Essa evolução constante muitas vezesacaba criando um ambiente de sistemas, muito heterogêneo nas empresas. Este fato acon-tece quando temos um conjunto de sistemas desenvolvidos em diversas plataformas (porexemplo, linguagem de programação e/ou banco de dados) operando de maneira isolada.

As empresas que possuem alta heterogeneidade precisam adotar estratégias para pro-ver interoperabilidade em seus sistemas, disponibilizando assim uma melhor comunica-ção entre os softwares, visando propiciar o intercâmbio de informações entre os departa-mentos das empresas e mantendo suas regras de negócios integradas.

O objetivo central desse trabalho é desenvolver estratégias que permitam a integraçãode sistemas distintos entre si, garantindo a interoperabilidade entre eles independente daplataforma e linguagem de desenvolvimento dos mesmos. Em particular, a proposta foicriada e desenvolvida para a Secretaria de Ensino a Distância – SEDIS, pertencente aUniversidade Federal do Rio Grande do Norte - UFRN, mas pode ser estendida a qualquerinstituição pública de ensino superior.

Como resultado desse estudo foi produzido um middleware concebido em uma ar-quitetura orientada a serviços com o objetivo principal de resolver os problemas atuaisque existem de comunicação e performance entre os diferentes sistemas de informação daSEDIS na UFRN.

Palavras-chave: Integração de sistemas, interoperabilidade, ambientes heterogêneos.

Abstract

Public and private organizations is coming to adapting to technological changes cons-tantly because business needs independent of its expertise area, either with adaptationof best market practices or with the constant updating of its technologies given the paceof innovation. This constant evolution often creating a heterogeneous environment sys-tems. This environment happens when we have a set of systems developed on multipleplatforms (programming language, database) operating in isolation.

Companies with this heterogeneity needs to adopt strategies to provide interoperabilityinto their systems providing better communication between the softwares, these strategieswill promote the exchange of information between the departments of companies keepingtheir integrated business rules.

The main objective of this work is develop strategies to provide the integration ofdifferent systems with each other, ensuring interoperability between them, regardless ofplatform and development language thereof. In particular, the proposal was created anddeveloped for the Department of Distance Education - SEDIS, belonging to the FederalUniversity of Rio Grande do Norte - UFRN, but can be extended to any public institutionof higher education.

As result of this study it was produced a middleware that uses components of a service-oriented architecture with the main objective to solve the current problems that exist incommunication and performance between different SEDIS information systems at UFRN.

Keywords: System integration, interoperability, heterogeneous environments.

Sumário

Sumário i

Lista de Figuras iii

1 Introdução 11.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Desafios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5 Organização do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Lista de Símbolos e Abreviaturas 1

2 Fundamentação Teórica 62.1 Middleware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Padrões de projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Padrões de projetos de integração . . . . . . . . . . . . . . . . . 72.3 Ambiente virtual de aprendizagem - AVA . . . . . . . . . . . . . . . . . 92.4 Arquitetura de software . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.5 Arquitetura Orientada a Serviço - SOA . . . . . . . . . . . . . . . . . . . 10

2.5.1 Camadas de abstração SOA . . . . . . . . . . . . . . . . . . . . 102.6 Web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.7 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3 Sistemas Legados da SEDIS 143.1 SEDIS Solicitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.2 Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Moodle e o Módulo de Solicitação Externa - MSE . . . . . . . . . . . . . 23

4 Desenvolvimento da proposta de integração 274.1 Processo de funcionamento do setor de TI. . . . . . . . . . . . . . . . . . 274.2 Problemática . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.4 INTEGRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4.1 Protocolo de comunicação . . . . . . . . . . . . . . . . . . . . . 344.5 Comunicação entre o MSE e o SEDIS Solicitação . . . . . . . . . . . . . 36

i

4.5.1 Relatar problemas relacionados ao Moodle . . . . . . . . . . . . 364.6 Integrando o SEDIS Solicitação com o Redmine . . . . . . . . . . . . . . 39

4.6.1 Exportar Solicitação para o Redmine . . . . . . . . . . . . . . . 404.6.2 Listar Solicitação exportada no SEDIS Solicitação. . . . . . . . . 434.6.3 Finalizar atividade importada no Redmine. . . . . . . . . . . . . 44

5 Estudo de caso. 495.1 Cenário 1 – Antes do desenvolvimento do middleware. . . . . . . . . . . 495.2 Cenário 2 – Depois do desenvolvimento do middleware. . . . . . . . . . . 515.3 Conclusões do Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . . 54

6 Considerações Finais. 566.1 Principais contribuições. . . . . . . . . . . . . . . . . . . . . . . . . . . 566.2 Limitações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Referências bibliográficas 59

Lista de Figuras

2.1 Padrão Pipe and Filter. Fonte (HOHPE; WOOLF, 2004). . . . . . . . . . 72.2 Padrão Message Router. Fonte (HOHPE; WOOLF, 2004). . . . . . . . . 82.3 Padrão Message Translate. Fonte (HOHPE; WOOLF, 2004). . . . . . . . 82.4 Padrão Control Bus. Fonte (HOHPE; WOOLF, 2004). . . . . . . . . . . 92.5 Camadas abstração SOA. Fonte adaptado de (BIEBERSTEIN, 2006). . . 11

3.1 Relação entre SEDIS Solicitação e o Ambiente Virtual de Aprendizagem . 153.2 Atores do Sistema SEDIS Solicitação . . . . . . . . . . . . . . . . . . . 153.3 Atores do Sistema SEDIS Solicitação . . . . . . . . . . . . . . . . . . . 163.4 Modelo arquitetural do SEDIS Solicitação. . . . . . . . . . . . . . . . . . 183.5 Relação entre Redmine e o Ambiente Virtual de Aprendizagem . . . . . . 193.6 Atores do Sistema Redmine . . . . . . . . . . . . . . . . . . . . . . . . . 203.7 Permissões do usuário gerente . . . . . . . . . . . . . . . . . . . . . . . 203.8 Permissões do usuário desenvolvedor . . . . . . . . . . . . . . . . . . . 213.9 Permissões do usuário informante . . . . . . . . . . . . . . . . . . . . . 213.10 Permissões do usuário não membro . . . . . . . . . . . . . . . . . . . . 223.11 Permissões do usuário anônimo . . . . . . . . . . . . . . . . . . . . . . . 223.12 Atores do Moodle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.13 Módulo de solicitação externa. . . . . . . . . . . . . . . . . . . . . . . . 253.14 Arquitetura do Módulo de solicitação Externa. . . . . . . . . . . . . . . . 26

4.1 Diagrama de atividades: Criação e atendimento de uma solicitação. . . . . 294.2 Estrutura de funcionamento entre o SEDIS Solicitação e o Redmine. . . . 304.3 Arquitetura de integração. . . . . . . . . . . . . . . . . . . . . . . . . . 334.4 Novo modelo de comunicação proposto. . . . . . . . . . . . . . . . . . . 334.5 Diagrama de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.6 Casos de uso relacionados a integração do MSE com o SEDIS Solicitação. 374.7 MSE - Tela de captação dos problemas dos usuários externos. . . . . . . . 374.8 Diagrama de atividades do caso de uso: Relatar problemas relacionados

ao Moodle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.9 Diagrama de sequência: relatar problemas relacionado ao moodle . . . . 394.10 Diagrama de casos de uso relacionados a integração do SEDIS Solicitação

e o Redmine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.11 Diagrama de Atividades: Exportar uma solicitação do SEDIS Solicitação

para o Redmine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.12 Diagrama de sequência: Exportar uma solicitação do SEDIS Solicitação

para o Redmine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

iii

4.13 Exportar uma solicitação do SEDIS Solicitação para o Redmine. . . . . . 424.14 Confirmar a Exportação da solicitação. . . . . . . . . . . . . . . . . . . . 424.15 Atividades importadas no REDMINE. . . . . . . . . . . . . . . . . . . . 434.16 Listar solicitações exportadas. . . . . . . . . . . . . . . . . . . . . . . . 444.17 Histórico da solicitação exportada. . . . . . . . . . . . . . . . . . . . . . 444.18 Detalhes da solicitação exportada. . . . . . . . . . . . . . . . . . . . . . 454.19 Casos de uso relacionados a integração do Redmine com o SEDIS Solici-

tação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.20 Detalhamento de uma atividade importada no Redmine. . . . . . . . . . . 464.21 Diagrama de Atividade: Finalizar atividade importada no Redmine. . . . 474.22 Diagrama de sequência Finalizar atividade importada no Redmine. . . . . 48

5.1 Etapas do chamado cenário 1. . . . . . . . . . . . . . . . . . . . . . . . 505.2 Resolução do primeiro chamado . . . . . . . . . . . . . . . . . . . . . . 505.3 Chamados atendidos no primeiro semestre de 2015 . . . . . . . . . . . . 515.4 Etapas do chamado no cenário 2. . . . . . . . . . . . . . . . . . . . . . . 525.5 Resolução do segundo chamado . . . . . . . . . . . . . . . . . . . . . . 525.6 Chamados atendidos no primeiro semestre de 2016 . . . . . . . . . . . . 535.7 Total de chamados atendidos no primeiro semestre de 2016 . . . . . . . . 54

Capítulo 1

Introdução

Este capítulo descreve um breve panorama dos sistemas utilizados no setor de tecno-logia da informação da SEDIS situada na universidade federal do rio grande do norte -UFRN. Abordaremos alguns problemas enfrentados na interação entre os sistemas hete-rogêneos e a necessidade de integrar estes sistemas para eliminar as ilhas de informaçãosem perder os serviços fornecidos pelo setor. Desta forma o capítulo descreve tambéma motivação, os objetivos do trabalho assim como a ideia principal dos demais capítulosque compõem este trabalho.

1.1 ContextualizaçãoA rápida evolução das Tecnologias de Informação nos trouxe muitas facilidades para

a obtenção de informações e de conhecimento que acarretou avanços significativos paraa Educação a Distância nas ultimas décadas. Na Universidade Federal do Rio Grande doNorte – UFRN, este avanço ocorreu de maneira mais significativa na Secretaria de En-sino a Distância – SEDIS que teve que adequar-se a esta evolução passando por váriasmudanças em seu ambiente computacional e organizacional. No que refere-se ao am-biente computacional , a evolução está relacionada ao crescimento de alguns setores daSEDIS e o desenvolvimento de novos sistemas de informação para ajudar na gerência dasinformações de cada setor.

Assim surge um ambiente computacional atual da Tecnologia da Informação - TI daSEDIS composto por sistemas de informações autônomos, distribuídos e heterogêneospois a construção, manutenção e operação ocorrem de forma independente e sem a preo-cupação de integração com outros sistemas. Esta autonomia traz como conseqüência umambiente altamente heterogêneo, pois favorece a utilização de diferentes tecnologias dehardware e de software no desenvolvimento dos sistemas.

Esta heterogeneidade dificulta a comunicação entre os setores da instituição pois estessetores são geridos por sistemas de informações, tornando os dados dissociados e assimimpedindo que as informações sejam integradas de forma rápida e precisa criando umcenário de informações isoladas (ilhas de informação) o que dificulta as estatísticas paradar suporte as tomadas de decisões dos gestores da instituição.

Se por um lado o este avanço das tecnologias de informação e comunicação propor-cionam uma maior facilidade e diminuição das distâncias no que se refere à distribuição,

CAPÍTULO 1. INTRODUÇÃO 2

localização e acesso às informações, por outro lado estimulam uma crescente divulgaçãode novas informações e em diversas mídias, realimentando o problema da heterogenei-dade e distribuição.

Com tantos sistemas trabalhando de maneira isolada e tendo a necessidade de interliga-se com outros sistemas de outros setores foram surgindo problemas como trabalho ma-nual e cansativo uma vez que os usuários dos sistemas gerenciais precisam alimentar osmesmos dados entre diferentes sistemas com diferentes representações; inconsistência dedados, como o processo de alimentar o mesmo dado em sistemas diferentes está sendofeito de forma manual, muitas vezes este procedimento não é feito por conta das urgên-cias das demandas e os setores não tem como contabilizar os serviços e tarefas realizadaspelas equipes para atender os usuários da TI; dificuldade na rastreabilidade da informa-ção pois o gestor da TI não tem como fazer o cruzamento de atividades realizadas entreos setores da TI no atendimento ao usuário, este cruzamento é extremamente importante anível gerencial pois transforma dados brutos em informação qualitativa; Todos esses pro-blemas levantados vai impactar diretamente na qualidade dos serviços prestados na TI,um exemplo claro disso é o atendimento demorado ao usuário dos serviços da TI pois osfuncionários desperdiçam tempo em atividades manuais que poderiam ser automatizadase assim otimizar o tempo e esforços das equipes para as resolver as demandas do setor.

Estes problemas demandam a construção de pontes que integre as informações se-toriais incorporando dados de diversas fontes e assim prover de forma rápida e precisa,informações e estatísticas para dar suporte a decisões de negócio e agilidade na prestaçãode serviço da TI aos usuários.

1.2 DesafiosSegundo Hohpe e Wolf (2004), a integração de sistemas é uma das maiores barreiras

que surgem em ambientes coorporativos que estão em constante crescimento devido acrescente quantidade de fusões e aquisições de novas empresas, isto vem causando gran-des preocupações para os CEOs das empresas pois qualquer solução de integração queseja adotada pela empresa vai ter que lidar com os seguintes desafios:

• Redes não confiáveis. Soluções de integração precisam transportar dados de umcomputador para outro através das redes. Diferentemente de um processo em exe-cução em um único computador, na computação distribuída existe uma preparaçãoe preocupação maior para lidar com um conjunto maior de possíveis problemas quepossam ocorrer no transporte dos dados. Muitas vezes, dois sistemas para seremintegrados estão separados por continentes e os dados que irão trafegar entre elestem que viajar através de linhas telefónicas, segmentos LAN, roteadores, switches,redes públicas e links de satélite aumentando a possibilidade de perda de pacotes,pois cada uma dessas etapas pode causar atrasos e interrupções.• Ambientes heterogêneos: Soluções de integração precisa transmitir informações

entre sistemas que utilizam diferentes linguagens de programação, plataformas ope-racionais e formatos de dados. Uma solução de integração tem de ser capaz deinteragir com todas estas diferentes tecnologias.


• A mudança é inevitável: Sistemas mudam ao longo do tempo, Uma solução deintegração tem que prover mecanismos para lidar com o ritmo das mudanças nasaplicações que queiram conectar-se. Soluções de integração pode facilmente serafetada por várias mudanças causando o “efeito avalanche” - se um sistema muda,todos os outros sistemas podem ser afetados. Uma solução de integração deveminimizar as dependências de um sistema para outro, provendo acoplamento fracoentre as aplicações.

1.3 ProblemáticaA principal motivação para o desenvolvimento deste trabalho deve-se a falta de in-

teroperabilidade entre os sistemas heterogêneos que operam no setor de TI da SEDIS,inviabilizando a convergência das informações geradas entre os sistemas no ambiente co-orporativo da SEDIS causando ilhas de informações. O que se observou foi a crescentenecessidade de troca de informações entre diferentes sistemas trabalhando de maneiraisolada. Este isolamento vem causando problemas para o setor tais como trabalho ma-nual pois os usuários dos sistemas tem que ficar atualizando uma mesma informação emmais de um sistema, inconsistência de dados pois na correria do dia a dia nem sempre épossível para os funcionários da TI ficarem alimentando dados em mais de um sistema.Tudo isso são fatores que que impactam na qualidade dos serviços prestados pela TI paraos usuários finais.

Nesse contexto é que surge a necessidade de criar uma ferramenta capaz de fazera integração das informações entre os sistemas que operam no setor de TI da SEDISe com isto criar uma maneira de interligar as informações que permeiam os setores daTI da SEDIS agregando assim o conceito de interoperabilidade 1 entre os sistemas deinformação desta organização.

1.4 ObjetivosO trabalho proposto tem como objetivo principal desenvolver e avaliar um middleware2para

integrar sistemas de gerenciamento de help desk(central de ajuda) com sistemas de issuetracking (gerenciamento de projetos/tarefas). Este middleware foi concebido por um es-tilo arquitetural de integração baseado em barramento de controle (control bus), atravésdesse estilo será feito o controle do fluxo de mensagens de forma centralizada no mid-dleware agindo como um mediador capaz de receber dados de um sistema remetente,trabalha-los e repassar estas informações para o sistema destino. A comunicação entre os

1Interoperabilidade: Capacidade de diversos sistemas e organizações trabalharem em conjunto (inte-roperar) de modo a garantir que pessoas, organizações e sistemas computacionais interajam para trocarinformações de maneira eficaz e eficiente.

2middleware ou mediador: No campo da computação distribuída, é um programa de computador quefaz a mediação entre software e demais aplicações. É utilizado para mover ou transportar informações edados entre programas de diferentes protocolos de comunicação, plataformas e dependências do sistemaoperacional.


sistemas com o middleware será feita através da tecnologia de serviços web (Web servi-ces) servindo como pontes de comunicação. Com esta estratégia foi capaz de integrar ossistemas mantendo as regras de integridade. Para fins de conceituação, o nome que serádado a este middleware será INTEGRA.

Como estudo de caso, iremos aplicar este middleware no setor de TI da SEDIS ondetemos esses tipos de sistemas (help desk e issue tracking) operando nos setores de su-porte e desenvolvimento da TI-SEDIS. O primeiro sistema envolvido na integração é ummódulo de solicitação externa, uma variação de um sistema de helpdesk, este é um novomódulo que foi desenvolvido neste trabalho para que o usuário final(alunos, tutores e pro-fessores) do Ambiente Virtual de Aprendizagem - AVA3 possa entrar em contato com osetor de suporte(central de ajuda) da TI. Este canal de comunicação teve a necessidadede ser criado para prover ajuda aos possíveis problemas que os usuários possam enfrentarcom o uso do AVA.

O segundo sistema envolvido na integração é o SEDIS Solicitação, este software foidesenvolvido pelo setor de TI da SEDIS para gerenciar os atendimentos dos chamadostécnicos (help desk), ele é bastante utilizado no setor de suporte que é um subsetor daTI-SEDIS.

O terceiro sistema envolvido na integração é o Redmine (issue tracking), uma ferra-menta de gerenciamento de projetos utilizado no setor de desenvolvimento de sistemasque é um subsetor da TI-SEDIS.

Para possibilitar a interação temos que desenvolver as seguintes etapas:

1. Criar o módulo de Solicitações Externas para que os usuários dos AVAs que sãoutilizados na SEDIS possam criar chamados técnicos direcionados à equipe de su-porte de TI.

2. Definir a arquitetura da integração que o middleware será implementado, esta ar-quitetura deverá ser capaz de fazer o intercâmbio dos dados entre os sistemas en-volvidos sem alterar a estrutura e regras de negócios particulares de cada sistemapreservando suas integridades.

3. Analisar as características individuais dos sistemas envolvidos para identificar asprincipais funcionalidades de cada sistemas.

4. Analisar a arquitetura dos sistemas envolvidos neste estudo identificando onde se-rão construídas as funcionalidades necessárias para que cada sistema possa efetuara comunicação com o INTEGRA.

3Ambientes virtuais de aprendizagem (do inglês: Virtual learning environment) são softwares que auxi-liam na montagem de cursos acessíveis pela Internet.


1.5 Organização do trabalhoPara atingir tais objetivos, este trabalho foi dividido em seis capítulos.O primeiro capítulo apresenta uma breve introdução contextualizando o trabalho e

como se dará seu desenvolvimento.O segundo capítulo descreve alguns conceitos para um melhor entendimento desta

dissertação.O terceiro capítulo apresenta uma visão geral dos sistemas legados da SEDIS que

serão alvo da integração. Esta visão geral trará a definição, diagramas de caso de uso erequisitos dos sistemas estudados.

O quarto capítulo apresenta o desenvolvimento do middleware INTEGRA bem comosuas especificações.

O quinto capítulo possui um estudo de caso do uso do INTEGRA aplicado no setorde TI da SEDIS.

O sexto capítulo trás as considerações finas, apresentam-se as principais contribuiçõesdeste trabalho bem como as limitações. Também serão apresentadas algumas sugestõespara futuros trabalhos

Capítulo 2

Fundamentação Teórica

Neste capítulo iremos abordar todos os conceitos que serão relevantes para o enten-dimento e compreensão do estudo realizado através de pesquisas na literatura sobre ostemas inerentes ao trabalho.

2.1 MiddlewareDe acordo com Coulouris et al (2013), "Middleware é composto por um conjunto de

processos ou objetos, em um grupo de computadores, que interagem entre si de forma aimplementar comunicação e oferecer suporte para compartilhamento de recursos distri-buídos."

o middleware caracteriza uma camada de software que possibilita a comunicação entresistemas distribuídos, tendo por objetivo diminuir a complexidade e a heterogeneidade dosdiversos sistemas existentes, disponibilizando serviços que efetuam a comunicação entreesta categoria de sistemas de modo transparente (MACIEL; ASSIS, 2004).

Desse modo as plataformas de middleware formam uma cadeia de engrenagens desuma importância para o desenvolvimento de sistemas distribuídos, Essas plataformascriam camadas de abstração que ajudam na implementação de softwares de larga escalapois diminui a complexidade dos sistemas que o utilizam.

2.2 Padrões de projetosPadrões de projeto ou Design Patterns tiveram sua origem, segundo Gamma et al.

(2000), nos trabalhos do arquiteto Christopher Alexander (ALEXANDER, 1977 apudGAMMA et al., 2000) sobre padrões utilizados na construção civil mais especificamentena arquitetura das cidades.

Na área de computação, padrões de projeto são “descrições de objetos e classes re-lacionadas, que são personalizadas para resolver um problema geral de projeto, em umcontexto particular” (GAMMA et al., 2000, p.20), ou seja, capturam experiências bemsucedidas de estruturas de sistemas, que podem ser reutilizadas em outros projetos.

Analisando o cotidiano do desenvolvimento de software é possível identificar quea procura por uma solução de um problema específico possui características idênticas,

CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA 7

senão igual a encontrada em um projeto anteriormente desenvolvido, neste contexto queentra a figura dos padrões de projetos onde possui documentado o contexto do problema ea solução abordada para solução daquele problema possibilitando o reaproveitamento dasidéias e soluções. Desta forma, problemas idênticos que se repetem em outros contextossão reconhecidos como tal, consumindo menos tempo e recursos para serem resolvidos.

Desse modo, os padrões de projetos tornam mais fáceis reutilizar soluções e arquite-turas bem sucedidas para construir softwares de forma flexível e fácil de manter.

2.2.1 Padrões de projetos de integraçãoSegundo Hohpe e Wolf (2004), sistemas de informação que trabalham em ambien-

tes corporativos raramente operam de maneira isolada. Imagine um ambiente comercialfuncionando na prática onde temos o software de vendas precisando comunicar-se como software de estoque para dar baixa nos produtos vendidos. O aplicativo de aquisiçãodeve se conectar a um site de leilão ou até mesmo o vendedor da empresa com seu PDAque precisa sincronizar seus dados com o servidor da empresa. Olhando assim podemosenxergar facilmente que qualquer aplicativo corporativo pode ser tornar mais eficientequando se integra com outras aplicações. Todas as soluções de integração tem que lidarcom alguns desafios fundamentais que ao longo do tempo, os desenvolvedores e arquite-tos de softwares criaram alguns padrões de projeto de integração para superar estes essesdesafios (HOHPE; WOOLF, 2004) trazendo a problemática que estão inseridos e a solu-ção adequada para resolver o problema.

• Filtros e Canais (Pipers and Filters): Neste padrão os componentes computacio-nais são os filtros que agem como transdutores que recebem uma entrada, transfor-mam através de algoritmos, e então geram uma saída para um canal de comunica-ção. Esses condutores de entradas e saídas são chamados de pipes. Desta maneiratemos um estilo arquitetural linear, onde podemos dividir uma tarefa de proces-samento maior em uma sequência tarefas menores, com etapas de processamentoindependentes (filters) que são conectados por canais (pipes) (HOHPE; WOOLF,2004) como mostra a figura 2.1.

Figura 2.1: Padrão Pipe and Filter. Fonte (HOHPE; WOOLF, 2004).

• Roteamento de mensagens (Message Router): Padrão de decisão e desvio defluxo, onde a mensagem que é recebida pode ser enviada para determinado canal,através da satisfação de determinada condição (HOHPE; WOOLF, 2004), conformepodemos acompanhar na ilustração da figura 2.2. Este padrão resolve o problemade como uma informação pode ser direcionada a diferentes filtros dependendo de


condições específicas e traz como solução a implementação de um roteador queencapsula o critério de decisão para republicar uma mensagem em outro canal.

Figura 2.2: Padrão Message Router. Fonte (HOHPE; WOOLF, 2004).

Este padrão ataca o problema de como uma mensagem pode ser direcionada a di-ferentes filtros dependendo de condições específicas e traz como solução a imple-mentação de um roteador que encapsula o critério de decisão para republicar umamensagem em outro canal (HOHPE; WOOLF, 2004).• Tradutor de Mensagens (Message Translate): Esse padrão tem uma função bem

simples, transformar mensagens. Ou seja, a mensagem produzida é a mensagemque foi utilizada, mas em outro formato (HOHPE; WOOLF, 2004), conforme podeser observado na figura 2.3. Por exemplo, uma mensagem sai de um sistema X epassa em uma tradução para ser inserido em um outro sistema Y como uma outrarepresentação.

Figura 2.3: Padrão Message Translate. Fonte (HOHPE; WOOLF, 2004).

Este padrão é o equivalente ao padrão de projetos Adapter descrito em GoF (Gangof Four). Um adaptador que converte a interface de um componente para uma outrainterface para que ele possa ser usado num contexto diferente (HOHPE; WOOLF,2004).• Barramento de Controle (Control Bus): O Control Bus é um padrão muito impor-

tante dentro de uma solução de integração, pois o mesmo é responsável por proveruma administração de todo o fluxo em tempo de execução, conforme ilustrado nafigura 2.4. Este padrão fornece um ponto único de controle para gerenciar e mo-nitorar uma solução distribuída. Ele conecta vários componentes a uma central degerenciamento que pode exibir o status de cada componente e monitorar o tráfegode mensagens (HOHPE; WOOLF, 2004). Esta central também pode ser utilizadapara enviar comandos de controle para os componentes, por exemplo, para alteraro fluxo de mensagens.• Mediador (Mediator): Este padrão defini um objeto que encapsula a forma como

um conjunto de objetos interage. O Mediator promove o acoplamento fraco ao


Figura 2.4: Padrão Control Bus. Fonte (HOHPE; WOOLF, 2004).

evitar que os objetos se refiram uns aos outros explicitamente e permitir variar suasinterações independentemente (GAMMA, 2007). Pela intenção podemos perceberque o Mediator atua como um mediador entre relacionamentos muitos para muitos,ao evitar uma referência explicita aos objetos. Outra vantagem que podemos notaré também que ele concentra a maneira como os objetos interagem.

2.3 Ambiente virtual de aprendizagem - AVAAmbientes Virtuais de Aprendizagem - AVAs são sistemas de aprendizagem desen-

volvidos sobre uma metodologia pedagógica para auxiliar o professor na promoção doensino na modalidade virtual ou semipresencial promovendo a interação entre o aluno eo professor no processo de ensino e aprendizagem de forma que os alunos adquiram osmesmos conhecimentos que seriam obtidos no ensino presencial (NETO; BRASILEIRO,2002). Segundo Lopes (2001):

"Os ambientes virtuais de ensino possibilitam uma ótima oportunidadepara ampliação dos limites de uma sala de aula tradicional. No entanto, antesque se comece a planejá-lo é importante, em primeiro lugar, ocupar algumtempo, [...], para refletir por quais razões se está buscando construí-lo."

Dentro da modalidade dos AVAs, temos o software chamado Moodle que é utilizadona SEDIS por se tratar de uma ferramenta bastante consagrada com uma das maioresbases de usuários do mundo, com mais de 25 mil instalações, mais de 360 mil cursos emais de 4 milhões de alunos em 155 países, sendo que algumas universidades baseiamtoda sua estratégia de educação a distância na plataforma Moodle. (SABBATINI, 2007)

2.4 Arquitetura de softwareDe acordo com Perry e Wolf, "a arquitetura de software é um conjunto de elementos

arquiteturais (de dados, de processamento, de conexão) que possuem alguma organização.Estes elementos e sua organização são definidos por decisões tomadas para satisfazerobjetivos e restrições.(PERRY; WOLF, 1992)"Ou seja, arquitetura são modelos e padrõesque permitem documentar, facilitar o entendimento e direcionar as diversas dimensões daconstrução das aplicações, como exemplos, a localização e armazenamento dos dados,


os mecanismos com que os usuários interagem com os sistemas e como os programas seconversam.

Dessa forma, uma arquitetura de software, quando adequadamente documentada, faci-lita a compreensão da estrutura de um sistema, evitando a compreensão a partir do códigofonte e ajudando nas comunicações com a equipe de desenvolvimento e com clientes(SOMMERVILLE, 2007).

Além disso, a arquitetura de um software permite perceber, de forma rápida, deci-sões na construção do software que influenciam no sucesso de software. Assim, o de-senvolvimento da arquitetura de um sistema afeta fatores como reuso, manutenibilidade,extensibilidade e escalabilidade (SOMMERVILLE, 2007).

2.5 Arquitetura Orientada a Serviço - SOAA Arquitetura Orientada a Serviço, do inglês Service Oriented Architecture – SOA,

é um estilo de arquitetura de software que dá suporte para sistemas que tenham comofinalidade a integração com outros sistemas, através de uma rede usando um protocolopredefinido. Esta arquitetura permite a transformação das funcionalidades das aplicaçõesem serviços padronizados quem podem se inter-relacionarem (ERL, 2007).

Essa arquitetura vem se destacando como uma das mais utilizadas e notáveis na áreade integração de sistemas (LINTHICUM, 2003). Desse modo, cada aplicação que desejeenvolver-se com essa arquitetura deve expor uma interface de serviço que dá acesso aosseus dados. Dessa maneira, a arquitetura transforma a aplicação em pedaços de softwaresreutilizáveis, provendo assim a interoperabilidade entre diversas plataformas. De acordocom Coelho (COELHO et al., 2006) o serviço é um componente ou um elemento compu-tacional independente de plataforma que possibilita o acesso e uso da função do negócioa qual ele representa pra outros serviços da mesma ou de outras aplicações. Para issoo serviço possui uma interface padronizada definem suas características e maneiras deacesso.

Mackenzie (MACKENZIE et al., 2006) definem SOA como um paradigma para a or-questração de competências espalhadas em diversos domínios, que são utilizadas quandovisíveis e atendem às necessidades de outrem em um processo denominado interação.

2.5.1 Camadas de abstração SOAModelos de abstração facilitam o entendimento de conceitos, por organizarem ideias,

funcionalidades e documentações no nível de detalhe mais adequado para cada tipo denecessidade. SOA traz um modelo baseado em cinco camadas abstração, a figura 2.5demonstra estas camadas.

• Camada corporativa: Na camada corporativa são definidos os modelos de negó-cios da empresa (enterprise business model), como quais são seus principais proces-sos baseados em seu objetivo e mercado, os quais são essenciais para sua vantagemcompetitiva, e que, portanto devem ser controlados de perto.


Figura 2.5: Camadas abstração SOA. Fonte adaptado de (BIEBERSTEIN, 2006).

• Camada de processos: Na camada de processos, os processos de negócios sãoidentificados e caracterizados. Cada processo é único no atendimento de uma de-terminada área funcional (embora empresas que cresceram através de aquisiçãopossam ter processos duplicados), e pode ser composto de diversos sub processos.A camada de processos é muito importante dentro da arquitetura SOA, porque mui-tos processos podem ser modelados e executados como serviços. Como se podeconfundir os conceitos de serviço e de processo de negócio, considera-se que osprocessos são definidos uma única vez, e usados dentro de um contexto único, já osserviços podem ser reaproveitados em diversos contextos (diferentes processos denegócio, departamentos ou linhas de negócio).• Camada de serviços: A camada de serviços é caracterizada por um número de ser-

viços que realizam funções individuais de um negócio. Dentro da arquitetura SOA,esta camada fornece uma ponte entre as camadas de alto (camada corporativa e deprocessos) e baixo nível (camada de componentes e objetos). Usualmente, é nestacamada que as funções críticas necessárias para o negócio são identificadas, vistoque é nela que usualmente são identificadas e expostas as funções para suportar onegócio.

• Camada de componentes: Mapeia os componentes que tem potencial para setransformarem em serviços, normalmente através de técnicas bottom-up (análisedas aplicações e identificação de funções que devem ser promovidas a serviços,por terem o potencial de servirem a mais sistemas). Componentes são os blocosde construção de serviços na arquitetura SOA e embora vários sejam construídoscom esta finalidade, a maioria será reaproveitada a partir de aplicações já existentes,através de técnicas de encapsulamento.

• Camada de objetos: A camada de objetos, estão as classes, atributos e relaciona-mentos de um objeto. Na arquitetura SOA há um reaproveitamento dos conceitosde orientação a objeto, porem com o desacoplamento dos objetos, transformandoem serviços reutilizáveis.


2.6 Web serviceCorrespondem a um modelo que tem por objetivo a integração de diferentes sistemas

computacionais. De acordo com o W3C1 (Wordl Wide Web Consortium), um Web serviceé definido como "um sistema de software projetado para suportar a interoperabilidadeentre máquinas sobre rede". Através dele, é possível o estabelecimento de comunicaçãoentre duas aplicações por meio de troca de mensagens XML2. Tal modelo tem se mostradoaltamente viável para a extração e integração de dados, permitindo a interoperabilidadeem grande escala (HANSEN; MADNICK; SIEGEL, 2003).

Um Web Service é definido também como uma parte de uma funcionalidade locali-zado em algum sistema na rede, este fragmento pode ser uma associação ou composiçãode outros, formando processos de negócio autônomos e fracamente acoplados (CHAP-PELL; JEWELL, 2002). Os Web Services são partes de um software que não dependemde plataforma e suas competências podem ser publicadas, descritas e invocadas via rede(FOOTEN; FAUST, 2012). Assim esta tecnologia pode ser acessada por diferentes siste-mas através do uso de linguagens e protocolos pradronizados.

2.7 Trabalhos relacionadosO trabalho de Martins (MARTINS, 2010) propôs uma integração em ambientes he-

terogêneos, por meio da especificação de uma arquitetura aberta baseada em middlewareque prover o gerenciamento da informação no ambiente industrial integrado à gestão cor-porativa. O modelo proposto atua no monitoramento de rede e dos dispositivos da plantaindustrial, fornecendo parâmetros relacionados aos dispositivos de automação (CLP3,RTU4, switches5 industriais) e parâmetros de rede. O middleware integra informaçõesoriundas de hardwares e integra as informações através de um middleware com o uso decomputação distribuída através da linguagem Java com o uso de chamada remota de mé-todo RMI (Remote Method Invocation) que possibilita o middleware chame métodos deobjetos remotos como se estes fossem objetos locais.

Oliveira (OLIVEIRA, 2009) propõe a integração de ferramentas educacionais, foi de-senvolvido a implementação de um ambiente orientado a serviços para expor funcionali-

1W3C - World Wide Web Consortium é a principal organização de padronização da World Wide Web.Consiste em um consórcio internacional com quase 400 membros, agrega empresas, órgãos governamentaise organizações independentes com a finalidade de estabelecer padrões para a criação e a interpretação deconteúdos para a Web.

2XML, do inglês eXtensible Markup Language, é uma linguagem de marcação recomendada pela W3Cpara a criação de documentos com dados organizados hierarquicamente, tais como textos, banco de dadosou desenhos vetoriais.

3Controlador Lógico Programável (CLP) ou do inglês PLC (Programmable Logic Controller) é umequipamento projetado para comandar e monitorar máquinas ou processos industriais.

4Unidade Terminal Remota RTU ou do inglês Remote terminal unit, é um dispositivo baseado em mi-croprocessador, que permite sinais independentes processos e enviar as informações para um local remotoonde é processado

5switche é um equipamento que interliga os computadores em uma rede, os cabos de rede de cadacomputador se ligam a ele, que então direciona os dados enviados de um computador especificamente paraoutro


dades de um repositório de conteúdos pedagógicos digitais da Rede Federal de EducaçãoProfissional e Tecnológica conhecido como InterRed6. O modelo desenvolvido comunica-se com o Moodle através de um conjunto de clientes que consomem os recursos. Nestetrabalho Oliveira fez um grande levantamento sobre os modelos de arquitetura orientadaa serviço e suas especificidades.

O trabalho de Zheng (ZHENG BO DONG, 2008) propôs um modelo de integraçãoorientada a serviços para sistemas com foco em EaD. Segundo Zheng, atualmente ossoftwares educacionais são desenvolvidas de forma isolada e com baixa capacidade deintegração com outros sistemas e baseado nisso ele propõe um modelo de integração emuma ferramenta chamada SOELS. No desenvolvimento de seu trabalho, Zheng usou ummodelo baseado em Web Service dividido em camadas e utiliza um tipo de EnterpriseService Bus (ESB). A aplicação SOELS encapsula as funcionalidades sob a forma de WebServices e implementa os processos de negócios através da comunicação e colaboraçãoentre os serviços.

De acordo com os trabalhos apresentados anteriormente pode-se observar que todastecnologias apresentadas oferecem uma forma diferente de integração de acordo com seusníveis e complexidades mas nota-se uma grande tendência em desenvolver estratégiasque permitam a integração de sistemas heterogêneos à luz da computação distribuída,mais especificamente o uso de SOA com o uso de tecnologia Web Service. Porém, nemsempre os sistemas a ser integrado foram construídos tendo a orientação a serviços comoparadigma. Aliado ao uso de SOA percebe-se também o desenvolvimento de um softwaremediador (middleware) no processo de integração entre os sistemas e a utilização. A fimde solucionar a integração de sistemas de help desk e issue tracking, percebe-se que ouso de Web service diante da arquitetura orientada a serviços atende as necessidades docontexto deste trabalho, pois essa tecnologia propicia interoperabilidade entre as váriasaplicações, plataforma e frameworks de uma maneira que se mantém consistente coma arquitetura web. Esta abordagem, baseada em Web service, permite a exposição defuncionalidades, o que garante um bom nível de abstração entre as aplicações envolvidascom um nível de acoplamento considerado baixo.

6InterRed é um repositório de recursos digitais que foi desenvolvido por uma rede de 10 instituiçõesfederais de ensino tecnológico e que tem por objetivo ser uma ferramenta de gestão e organização da basede conteúdos educacionais

Capítulo 3

Sistemas Legados da SEDIS

Este capítulo apresenta uma visão geral dos sistemas legados da SEDIS que fazemparte do alvo da integração deste trabalho, é apresentado também a relação que eles têmentre si e a importância de cada um.

Este trabalho realiza a integração entre dois sistemas legados (SEDIS Solicitação e Red-mine) e um novo módulo de Solicitações externas incorporado pelo Moodle. Estes siste-mas são utilizados na SEDIS e possuem uma relação direta entre o atendimento ao usuáriofinal, gestão da equipe e qualidade de serviço oferecido.

O SEDIS Solicitação é um sistema de protocolo de atendimento ao usuário dos ser-viços prestados pela TI-SEDIS, o Redmine trata-se de um sistema de gerenciamento deprojetos/equipe e o Moodle é um ambiente virtual de aprendizagem - AVA que precisa dis-ponibilizar um meio de comunicação via sistema entre o setor de suporte com o usuáriofinal, nas próximas seções iremos detalhar cada sistema.

Quando referenciamos os sistemas deste estudo como sistemas legados, não estamosquerendo dizer que são sistemas bastante antigos, complexos e de difícil manutenção.Estamos fazendo referência como sistemas legados por estarem funcionando a um certotempo e que exercem papéis importantíssimos na instituição, mas que atualmente estãoisolados um do outro. Esse trabalho apresenta um estudo de caso que motiva a integraçãode tais sistemas.

3.1 SEDIS SolicitaçãoO SEDIS Solicitações 1 surgiu da necessidade de ter uma ferramenta de gerencia-

mento de chamados técnicos do setor de Tecnologia da Informação da SEDIS, este soft-ware foi desenvolvido na SEDIS pelo setor de desenvolvimento da TI. Suas principaisfuncionalidades são: Gerência dos chamados técnicos, histórico dos chamados técnicos,relatórios estatísticos e controle de usuários. Todas essas funcionalidades têm como fina-lidade prestar apoio técnico as pessoas que utilizam os serviços que a TI oferece, inclusiveusuários dos AVAs, e desta maneira este sistema atua prestando apoio a educação a dis-tância da UFRN conforme a figura 3.1.

1SEDIS Solicitação - http://www.solicitacao.sedis.ufrn.br/

CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS 15

Figura 3.1: Relação entre SEDIS Solicitação e o Ambiente Virtual de Aprendizagem

No quesito integração com outros sistemas, o software não tem a mínima capacidadede comunicar-se com outros sistemas pois foi originalmente projetado para trabalhar deforma isolada e independente dificultando a comunicação com outros sistemas. Ao de-senvolver um sistema de informação, questões de interoperabilidade devem ser pensadasantes de sua implementação na fase de planejamento o que na maioria das vezes nãoacontecem por falta de planejamento, falta de tempo e outros fatores o que dificulta a suaintegração.

Partindo desta realidade, é proposto neste trabalho ser desenvolvido uma camada me-diadora de serviços (web service) para que o SEDIS Solicitação possa integrar-se atravésde serviços web com o INTEGRA.

Atores

O Setor de TI possui três divisões: Desenvolvimento, Suporte Técnico e Coordenaçãode TI. Dentro dessas subdivisões o SEDIS Solicitações terá forte atuação no setor desuporte técnico pois é lá onde o atendimento ao usuário se inicia, tendo isto em menteveremos alguns papéis que são executados pelos atores abaixo:

Figura 3.2: Atores do Sistema SEDIS Solicitação

1. Usuário de TI: Todos os usuários dos serviços de TI da SEDIS, neste ator estão osalunos, professores, tutores, funcionários de outros setores da SEDIS.

2. Gestor do suporte de TI: Atua na coordenação do atendimento ao usuário articulando-se com a equipe técnica filtrando, acompanhando e delegando os chamados.


3. Equipe técnica: Uma equipe multidisciplinar (desenvolvimento e suporte técnico)de profissionais da área de tecnologia da informação que executam todos os proce-dimentos necessários para resolução das solicitações.

4. Administrador: Este usuário possui acesso a todas às configurações do sistemapara executar e controlar as atividades rotineiras e necessárias para o funcionamentoda ferramenta.

Além desses atores citados, é possível também criar novos atores e definir novas res-ponsabilidades no sistema através da configuração do perfil do usuário.

Diagrama de Caso de Uso

O diagrama de caso de uso descreve bem o cenário que retratando as funcionalidadesdo sistema do ponto de vista do usuário com as principais funcionalidades de seu sistema.

Figura 3.3: Atores do Sistema SEDIS Solicitação

Requisitos Funcionais

A seguir detalharemos os casos de uso do sistema em forma de requisitos funcionaisos quais devem permitir a execução de cada casos de uso com o funcionamento desejado.

• Abrir Solicitação: Permitir ao usuário abrir uma solicitação para informar algumtipo de serviço da TI. Este serviço pode ser algum problema no ambiente virtual


de aprendizagem, algum problema de infraestrutura da SEDIS ou até mesmo umadúvida de algum procedimento do Moodle.

• Acompanhar Solicitação: Permitir ao usuário acompanhar a resolução de seu pro-blema visualizando as etapas (aberta, em andamento ou finalizada) necessárias paraa resolução.

• Avaliar Atendimento: Permite que os usuários avaliem os serviços prestados pelaequipe de TI através do preenchimento de um breve formulário de perguntas nofinal do atendimento da solicitação.

• Delegar Solicitação: Permite que o coordenador abra uma solicitação e após analisa-la, delegue a solicitação para algum integrante da equipe para este membro possainiciar os trabalhos em busca de solucionar a tarefa.

• Finalizar Solicitação: Permitir ao usuário (Equipe Técnica) após a resolução dasolicitação encerre a solicitação finalizando o atendimento.• Visualizar Solicitação: Permite que os usuários (Gestor do suporte de TI, adminis-

trador e Equipe Técnica) visualize as solicitações que estão sob suas responsabilida-des para resolução, em cada perfil de usuário teremos uma maneira de visualização:

Gestor do suporte de TI e administrador: Visualiza as solicitações no in-tuito de acompanhar e delegar para um funcionário resolver.Equipe Técnica: Visualiza as solicitações de sua responsabilidade para resolução.

• Adicionar Informação a solicitação: Enquanto o funcionário solucionador queestá atendendo a solicitação, o sistema deve permitir mecanismos para adicionarinformações pertinentes a solicitação.

• Manter cadastros administrativos: Permite que o usuário (administrador) possaadicionar, alterar e remover todos os registros administrativos necessários para ofuncionamento do sistema.

• Gerar relatórios estatísticos: Permite que o usuário (administrador) possa gerarrelatórios com dados estatísticos sobre os atendimentos das solicitações que irãoauxiliar nas tomadas de decisões da gerência de TI.

Padrão arquitetural

Após efetuar análise em um nível mais aprofundado do SEDIS Solicitação, foi iden-tificado o padrão arquitetônico utilizado neste sistema, esta análise foi elaborada como intuito de detectar os componentes chaves que podem ser utilizados/modificados parainteragir com o INTEGRA. Primeiramente, foi realizado um estudo na maneira que o sis-tema foi desenvolvido a partir da análise da código, na organização dos elementos arqui-teturais e dialogando com os programadores que trabalharam no desenvolvimento deste


software. Neste estudo, foi concluído que o padrão arquitetural do SEDIS Solicitação éo padrão baseado em camadas, a seguir iremos explorar cada uma dessas camadas destemodelo proposto como mostra a Figura 3.4.

Figura 3.4: Modelo arquitetural do SEDIS Solicitação.

• Camada de visualização: Esta camada está subdividida em View e Form, é res-ponsável por manter os arquivos PHP que irá definir toda a interface que exibirá asinformações para os usuários.View: Arquivos de classes PHP’s genéricos que são utilizados para um pré-processamentoda página antes de ser exibida, assim que os dados são carregados na memória.Form:São arquivos de classes PHP’s que contém as tags HTML e informações quesão específicas para cada página a ser exibida ao usuário.Essa divisão entre ClassView e ClassForm acontece porque algumas páginas pos-suem elementos muito similares e diante disso utilizou-se alguns arquivos PHP deforma genéricas reaproveitando-as em outros arquivos.• Camada de controle: Possui classes do tipo controller que recebem as informações

fornecidas pelos usuários através dos formulários (Form) nos arquivos PHP’s e iráencaminhá-las às classes que irão realizar a comunicação com banco de dados parao armazenamento das informações.• Camada de persistência: Camada responsável por manter os arquivos de classes

PHP que possuem o controle das stored procedures que realizam as transações como banco de dados para armazenar as informações recebidas das classes controller’sou recuperar informações solicitadas pelos usuários para serem visualizadas nasinterfaces.

3.2 RedmineO Redmine é um software de gerenciamento de projetos desenvolvido na linguagem

Ruby on Rails, classificado como software livre distribuído sobre a licença GNU GeneralPublic License V2 (GPL) que tem atendido muitos projetos que precisam controlar tare-fas, atividades, recursos humanos, andamento das tarefas e a evolução dos artefatos desoftware.


Este sistema gerência a equipe de desenvolvimento da TI-SEDIS na resolução dasdemandas de trabalho que se dividem em demandas de suporte (oriundas do SEDIS Soli-citação) ou demandas de novos projetos.

De acordo com a figura 3.2, pode-se ver que semelhante ao SEDIS Solicitação, estesistema também enquadra-se como um sistema de apoio ao sistema de ensino (Moodle)uma vez que todos as atividades (geridas pelo Redmine) desenvolvidas pela equipe sãovoltadas para garantir que todos funcionalidades do AVA estejam em pleno funciona-mento.

Figura 3.5: Relação entre Redmine e o Ambiente Virtual de Aprendizagem

No quesito integração com outros sistemas, diferentemente do SEDIS Solicitação, oRedmine expõe alguns de seus dados por meio de uma API de Web services. Esta APIfornece operações de acesso e CRUD básico (criar, atualizar, excluir) para os recursos(problemas, projetos, membros, usuários, regras, versões dentre outros). A API suportatanto XML e JSON formatos o que ajudará no processo de integração.

Atores

Como dito anteriormente, o setor de TI da SEDIS possui as seguintes divisões: De-senvolvimento, Suporte Técnico e Coordenação de TI. Este sistema vai atuar fortementena equipe de desenvolvimento atuando na gestão e planejamento das atividades executa-das pelos desenvolvedores. Neste cenário, o Redmine possui por padrão alguns perfis deusuários cadastrados que são: Gerente, desenvolvedor, informante, não membro e anô-nimo. A ferramenta permite que sejam criados mais níveis de usuários e as permissõespodem variar de acordo com a necessidade de cada usuário. Vejamos logo abaixo osatores e suas possíveis permissões no sistema.

A figura 3.7 foi captada da configuração do Redmine referente ao perfil do gerente.Note que ele é possui um nível máximo de permissões voltadas para a administração daferramenta.


Figura 3.6: Atores do Sistema Redmine

Figura 3.7: Permissões do usuário gerente


A figura 3.8 também foi captada da configuração do Redmine mas esta é referente aoperfil do Desenvolvedor, perceba que este perfil possui uma gama de permissões voltadasmais para operar o sistema.

Figura 3.8: Permissões do usuário desenvolvedor

A figura 3.9 também foi tirada da configuração do Redmine mas esta é referente aoperfil do Informante, percebe-se que este perfil possui um nível de permissões bem res-trito ao projeto.

Figura 3.9: Permissões do usuário informante

A figura 3.10 também foi tirada da configuração do Redmine mas esta é referente aoperfil do usuário não membro. Geralmente este usuário , mas não pertence ao projetopodendo apenas visualizar alguns itens como a wiki, fórum, notícias, Gantt entre outros.


Figura 3.10: Permissões do usuário não membro

A figura 3.11 também foi tirada da configuração do Redmine mas esta é referente aoperfil do usuário anônimo. Este perfil é o que possui menos permissões no sistema.

Figura 3.11: Permissões do usuário anônimo

Requisitos Funcionais

De acordo com a documentação encontrada no site do Redmine, foi feito um levanta-mento das principais requisitos funcionais da ferramenta:

1. Permitir o cadastro de atividades e tarefas com os esforços necessários e estimativasde tempo e recursos previsto no projeto.

2. Permitir várias versões de um cronograma possibilitando a gravação das versõesantecedentes.

3. Permitir cálculo do esforço total previsto e do total realizado em um determinadoperíodo de tempo.

4. Informar ou destacar as atividades que estão programadas para serem feitas na se-mana corrente ou no dia corrente.

5. Informar as atividades que estiverem em atraso.

6. Ser multi-projetos, permitindo que a alocação de recursos seja controlada com basena alocação dos recursos em todos os projetos.


7. Gerar o caminho crítico do projeto.

8. Permitir a quebra de uma atividade em subatividades.

9. Permitir a comparação do cronograma previsto x realizado.

10. Exibir o cronograma dos projetos através de Gráficos de Gantt2.

11. Possibilidade de anexar documentos e adicionar notícias aos projetos.

12. Disponibilizar uma seção de WIKI3 e fóruns por projeto.

13. Disponibilizar Feeds e notificações via e-mail.

14. Permitir que cada usuário possa ter papéis diferentes em cada projeto.


Por se tratar de uma ferramenta open source, foram feitas diversas pesquisas em suadocumentação oficial sobre o seu padrão arquitetural mas nada foi encontrado, desta ma-neira foi elaborado um estudo a nível de código fonte investigando a organização dosprincipais elementos impactantes da arquitetura.

Neste estudo, foi concluído que o padrão arquitetural que consta no Redmine é opadrão Model View Controller - MVC, este padrão divide a aplicação em três componentesModel, View e Controller. Todas as requisições da aplicação são direcionadas para ocomponente Controller, que acessa a componente Model para processar a tal requisição,e por fim exibe o resultado da componente View.

3.3 Moodle e o Módulo de Solicitação Externa - MSEO Moodle (Modular Object Oriented Dynamic Learning Environment) é um software

livre distribuído pela GNU, foi desenvolvido para a gestão do ensino-aprendizagem tendocomo metodologia pedagógica o sócio construtivismo, no qual os participantes constroemconhecimentos colaborativamente interagindo com o ambiente, criado no ano de 1999por Martin Dougiamas e desde então vem sendo desenvolvido colaborativamente pelacomunidade de software livre que reúne milhares de profissionais de vários países (COLE;FOSTER, 2007).

Desenvolvido na linguagem de programação PHP, o Moodle é um sistema altamenteportável tendo a possibilidade de instala-lo em diversos sistemas operacionais (Linux,Unix, Windows, Mac OS X). Além disso também trabalha com diversos bancos de dadoscomo MySQL, PostgreSQL, Oracle entre outros. (FILHO, 2004). Concebido em uma

2Gráfico de Gantt é um gráfico usado para ilustrar o avanço das diferentes etapas de um projeto3Wiki é utilizado para identificar qualquer coleção de documentos, uma enciclopédia online.


arquitetura baseada em componentes que vem facilitando o seu aprimoramento contí-nuo possibilitando incorporar módulos com novas funcionalidades, o que favorece a fáciladaptação do sistema às necessidades de seus usuários (MOODLE, 2015).

Atores

De acordo com a documentação4 oficial do Moodle, é possível criar usuários commaiores ou menores atribuições, ou seja, são diferentes níveis que possibilitam um usuárioter mais áreas acessíveis do que outro. por Padrão temos os seguintes atores que operamo sistema: Visitante, aluno, tutor, autor de curso, administrador representados pela figura3.12.

Figura 3.12: Atores do Moodle.

1. Visitante: Têm a possibilidade de apenas visualizar o curso e seu conteúdo, ele nãopode participar das atividades, se comportando apenas como um observador.

2. Aluno: É quem faz o curso, ele é quem recebe o conteúdo do professor, interagecom os colegas, ele envia material, contribui no fórum, vê suas notas, o curso édado para ele.

3. Moderador: Geralmente é uma função dada à professores colaboradores, ou pro-fessores que apenas vão acompanhar o curso, ele não pode editar nenhum material.

4. Tutor: Quem produz o material e pode acrescentar os conteúdos no ambiente, elequem molda o ambiente, tem atribuições de criar atividades, recursos, inserir alunosno curso que já estejam cadastrados no Moodle, configurar notas e o formato decurso que ele pretende que tenha seu curso.

5. Autor de curso: Tem as mesmas funções do professor, ele quem cria o curso porisso o nome diferente. Em um curso a distância é importante os alunos saberem comquem estão lidando, por isso o status, possibilitando que ele saiba quem é professore quem é aluno.

6. Administrador: Quem tem as atribuições máximas no Moodle, ele pode configurartodo o ambiente, tanto a página inicial e as categorias de curso quanto os próprioscursos, ele tem possibilidade também de entrar como professores, alunos, o que émuito utilizado para testes. Geralmente sobre ele que cai a responsabilidade dosproblemas que o ambiente venha a ter, ele quem tem atribuição de instalar o Mo-odle, quem tem acesso a senhas de FTP, de banco de dados, e quem pode baixarplugins, temas. Ele tem acesso a todas as áreas do ambiente, pode excluir e inserirusuários e dar suas atribuições, pode alterar materiais e organizar o ambiente.

4<http://docs.moodle.org/29/en/main_page>


Além desses atores e atribuições é possível também criar novos atores e definir suas áreasde acesso e permissões no sistema.

Módulo de Solicitação Externa - MSE

Este novo módulo é semelhante a um formulário web que foi desenvolvido e incorpo-rado no Moodle, pode ser acessado através de um botão chamado "Suporte"que pode serrequisitado pelo usuário a qualquer momento, pois este botão está disposto no canto su-perior direito da tela do Moodle. A Figura 3.13 ilustra os dados captados pelo formuláriocomo nome, e-mail, telefone, assunto e detalhes.

Através deste formulário, os usuários do M oodle poderão comunicar-se diretamentecom o setor de suporte da TI servindo de canal de comunicação direta, este novo canal decomunicação teve a necessidade de ser criado para ajudar os usuários com os possíveisproblemas que eles venham enfrentar com o uso do moodle já que o SEDIS Solicitaçãonão está acessivel a estes usuários.

O MSE vai atuar na captação de problemas técnicos de um publico alvo externo aosfuncionários da SEDIS e injetar estas informações no SEDIS Solicitação através do IN-TEGRA para que elas sejam resolvidas pelos funcionários da TI.

O SEDIS Solicitação não atinge os usuários externos (alunos, professores e tutores)ficando limitado apenas aos funcionários internos da SEDIS, com a criação desse novomódulo, as informações captadas pelo MSE, serão injetadas no SEDIS Solicitações e tra-tadas como uma solicitação só que agora teremos esse novo status de solicitação externa.

Figura 3.13: Módulo de solicitação externa.


Aproveitando o padrão arquitetural desenvolvido pelos funcionários da TI, o MSE foielaborado seguindo este padrão que é baseado em camadas(visualização e controle) quecontém três componentes Form, View e Controller. O componente View é responsável


Figura 3.14: Arquitetura do Módulo de solicitação Externa.

por configurar algumas informações que serão úteis para identificar de onde a solicitaçãoexterna está sendo enviada e o usuário que a criou. Essa pré configuração é necessária poisa SEDIS possui diversos AVAs para cada tipo de cursos e treinamentos que ela oferece,o componente Form é responsável por montar os componentes HTML que compõem oformulário e o controlador executa as requisições da aplicação oriundas dos componentesView e Form.

A Figura 3.14 ilustra a relação das duas camadas e seus componentes, comparandoeste modelo arquitetônico com o do SEDIS Solicitação percebe-se a falta da camada depersistência, esta camada não será implementada no MSE pois os dados das solicitaçõesexternas serão exportados (persistidos) para o SEDIS Solicitação através do INTEGRA,no capítulo de desenvolvimento do middleware será detalhado com maiores informaçõesessa etapa.

Capítulo 4

Desenvolvimento da proposta deintegração

Este capítulo apresenta a proposta de integração dos sistemas da SEDIS e o processode negócio mostrando como os sistemas se correlacionam com os subsetores da TI (De-senvolvimento e Suporte) e as pessoas (papéis) das equipes. Logo depois é descrito aproposta do módulo de integração e como está sendo desenvolvida. Além disto, são apre-sentados a modelagem da aplicação por meio de diagramas da UML(Unified ModelingLanguage) e as estratégias de implementação envolvidas na solução do problema de inte-gração.

O departamento de Tecnologia da Informação - TI da SEDIS está dividido em três sub-setores: Desenvolvimento, Suporte e Coordenação de TI. O subsetor de desenvolvimentotem como objetivo analisar, projetar, implementar realizar manutenção e implementarsoluções de softwares no ramo do ensino, pesquisa e extensão da SEDIS. Este setor éconstituído por uma equipe multidisciplinar (programadores, analistas, web design, ad-ministrador de banco de dados e um coordenador) de profissionais da área de tecnologiada informação que executam todos os procedimentos necessários para o desenvolvimentoe manutenção das soluções de TI da SEDIS.

O subsetor de suporte realiza atendimento ao usuário, manutenção de equipamentosde informática, administra e gerencia a rede e laboratórios de informática da SEDIS, estesetor é constituído por uma equipe multidisciplinar (técnicos em manutenção de compu-tadores, técnicos de suporte ao usuário, técnicos de redes e um coordenador) de profissi-onais da área de tecnologia da informação.

O subsetor de coordenação de TI exerce um papel mais alto nível com a responsabili-dade de gerenciar projetos e os serviços de TI oferecidos pelo setor. Desse modo o gestorde TI atua na elaboração de projetos, implantação e gerenciamento.

4.1 Processo de funcionamento do setor de TI.Um chamado técnico é iniciado quando os usuários externos (professor, tutor ou

aluno) entra em contato com o subsetor de suporte por telefone ou e-mail. O atendenteanota todos os dados do problema do usuário e dirige-se até o sistema SEDIS-Solicitação

CAPÍTULO 4. DESENVOLVIMENTO DA PROPOSTA DE INTEGRAÇÃO 28

para abrir uma solicitação com esses dados.Caso o usuário seja algum funcionário (usuário interno) da SEDIS, ele terá acesso

direto ao sistema e não precisa entrar em contato com a atendente. Os dados de umasolicitação são formados por: Data da solicitação, telefone para contato, assunto da soli-citação e detalhes (descrição do problema).

O coordenador do Suporte TI analisa todas as solicitações submetidas para distribuí-las entre os funcionários de TI que detêm o conhecimento adequado para resolvê-las.Estes funcionários são orientados a resolver as solicitações no menor tempo possível ecaso não seja possível resolvê-las, é orientado a comentá-las para que o usuário de TIesteja sempre informado sobre o andamento da sua solicitação (OLIVEIRA et al., 2013).Vejamos o diagrama de atividades na Figura 4.1 que mostra o fluxo de controle desteprocesso.


Figura 4.1: Diagrama de atividades: Criação e atendimento de uma solicitação.

Quando uma solicitação de serviço de TI é resolvida apenas no setor de suporte, oSEDIS Solicitações por si só atende muito bem a necessidade do SETOR finalizando alimesmo o problema do solicitante. Mas nem sempre a resolução da solicitação acontecedesta maneira e a resolução da solicitação necessita de esforços do setor de desenvolvi-mento, gerando demandas de trabalho para o este setor e criando uma relação de trabalhoentre os setores. Ao se criar uma nova demanda para o setor de desenvolvimento, o


coordenador precisa criar uma tarefa no Redmine informando o tipo, título, descrição, si-tuação, prioridade, início, data prevista para término e para quem vai ser delegada a tarefa.A partir deste procedimento é que a solicitação pode começar a ser atendida pelo setorde desenvolvimento. Quando a tarefa for solucionada no Redmine, o coordenador do de-senvolvimento deve informar para o coordenador do suporte que a requisição do SEDISSolicitação já foi atendida e que o coordenador do suporte pode fechar a solicitação noSEDIS Solicitação. Vejamos o diagrama de atividades na Figura 4.2 que trata bem esteprocesso.

Figura 4.2: Estrutura de funcionamento entre o SEDIS Solicitação e o Redmine.

4.2 ProblemáticaO processo descrito anteriormente neste capítulo podem gerar falhas além de muita

ineficiência durante o atendimento ao usuário que serão descritos abaixo:

1. Trabalho manual, dispendioso e cansativo: Muitas vezes o coordenador do de-senvolvimento não tem tempo de abrir o SEDIS Solicitação para pegar os dados dasolicitação e criar a tarefa no Redmine. Assim este procedimento fica na respon-sabilidade dos desenvolvedores causando muito trabalho manual, cansativo e perdade tempo uma vez que poderiam estar gastando esse tempo resolvendo a solicitação.


2. Inconsistência de dados: Na correria do dia a dia nem sempre é possível para osdesenvolvedores ficarem utilizando os dois sistemas, coletando os dados da solici-tação e transformando em tarefas, seja por falta de tempo ou até mesmo esqueci-mento. Desse modo acabam gerando transtornos para a gerência de TI pois acabanão documentando as tarefas desenvolvidas e não contabilizando esses esforços daequipe.

3. Rastreabilidade de informação: Dificuldade para o gestor de TI em para fazero cruzamento de dados das atividades realizadas pelo setor de desenvolvimento xSolicitações atendidas.

4. Atendimento demorado, ineficiente: Demora no atendimento das solicitaçõespois para o funcionário do desenvolvimento começar a trabalhar no atendimentoda solicitação, leva-se muito tempo. Pois, como explicado anteriormente, o usuárioentra em contato com o setor do suporte pelo telefone ou e-mail para que a aten-dente registre o problema no sistema. No próximo passo o coordenador do suportedeve analisar a solicitação e caso não seja de responsabilidade do setor de suporte,ele entra em contato como coordenador do desenvolvimento via e-mail ou telefone.Quando o coordenador receber esta demanda, ele deve criar a tarefa no Redminee delega-la, interferindo na qualidade do atendimento da TI como um todo pois oprocesso de atendimento se torna lento.

Necessidade de integração

Nós últimos anos o setor de TI da SEDIS vem evoluindo e passando por muitas trans-formações que acarretam na aquisição de novos softwares, sejam eles desenvolvidos nosetor(SEDIS Solicitação) ou softwares prontos (Redmine) de acordo com as necessida-des. Por mais que estes softwares funcionem muito bem individualmente, acabam criandoilhas de informações produzindo, em alguns casos, informações redundantes além da ne-cessidade de trabalho manual que muitas vezes é considerado ineficiente e cansativo. Osresultados inconsistentes, a manutenção e repetição do mesmo dado em vários sistemas,os resultados inconsistentes, os problemas de isolamento dos dados, atendimento demo-rado, dificuldades na rastreabilidade e cruzamento dos dados foram os motivadores danecessidade da troca de informação e integração dos sistemas heterogêneos.

4.3 PropostaA proposta deste trabalho é o desenvolvimento de um middleware integrador de siste-

mas utilizados na SEDIS denominado de INTEGRA. Este middleware será implementadona linguagem Java e fará o uso de computação distribuída, através do uso de Web service,para realizar a comunicação dos dados oriundos dos Chamados técnicos dos ambientesvirtuais de aprendizagem, SEDIS Solicitações e REDMINE provendo uma solução de in-teroperabilidade entre sistemas em uma arquitetura que ofereça baixo acoplamento e forte


coesão com as responsabilidades bem definidas para que qualquer outro sistema possa serintegrado com essa ferramentas de maneira simples e padronizada.

4.4 INTEGRAO middleware INTEGRA possibilita a comunicação entre os sistemas de help desk

e issue tracking com o objetivo de diminuir a complexidade e heterogeneidade presen-tes nestes tipos de sistemas, provendo assim serviços que realizam a comunicação entreos software de forma transparente. Neste trabalho temos dois sistemas (SEDIS Solici-tação, MSE) como representantes de sistemas de Help desk e o Redmine como sistemade Issue tracking, a Figura 4.3 ilustra como os sistemas comunicam-se neste processode integração através do padrão SOA, nota-se que quando um sistema precisa enviar al-guma informação para outro sistema ele deve seguir o seguinte fluxo: Sistema Origem⇀↽ middleware ⇀↽ Sistema Destino. Vejamos o seguinte exemplo: O MSE pretende pass-sar uma informação para o SEDIS Solicitação, primeiramente O MSE comunica-se comINTEGRA passando as informações via serviços web. Quando o INTEGRA recebe asinformações, ele comunica-se com o sistema destino (SEDIS Solicitação) e repassa asinformações enviadas pelo sistema remetente. Este procedimento é seguindo sucessiva-mente pelos outros sistemas de acordo com as regras de negócios estabelecidas.


Figura 4.3: Arquitetura de integração.

Analisando a Figura 4.3 e a Figura 4.4 percebe-se que cada sistema tem uma camadade serviços implementados através de Web services, estes serviços não existiam nestessistemas pois os mesmos não foram planejados para futuras integrações, sendo assim, foinecessário a implementação destes web services para que o SEDIS Solicitação e o MSEpossa comunicar-se com o INTEGRA através dos serviços, esta camada de é composta deconsumidores e provedores de serviços que neste trabalho são chamados de service con-sumers e services providers que fazem a comunicação entre o middleware e os sistemas.

Figura 4.4: Novo modelo de comunicação proposto.

O padrão arquitetural aplicado na relação de comunicação entre os sistemas e o mid-dleware deste trabalho foi baseado no estilo arquitetural control bus. Este padrão provermaior desacoplamento entre consumidores e provedores de serviços, já que os consu-


midores não conhecem diretamente quem está provendo o serviço. Para que isso ocorratemos um ponto único de controle (o middleware) para gerenciar e monitorar a integração.

O INTEGRA funcionará como uma central de controle no qual temos sistemas conec-tados a esta central que detém todo o controle das informações percorridas na integraçãoentre os sistemas, desse modo é possível que o INTEGRA monitore o tráfego das infor-mações e altere seu fluxo agindo como um mediador entre o sistema remetente e o sistemadestinatário da informação(HOHPE; WOOLF, 2004). Com isto, às alterações feitas en-tre um sistema remetente não vai impactar na comunicação e funcionamento do sistemadestinatário.

4.4.1 Protocolo de comunicaçãoA seção anterior explicou como é feita a comunicação externa que compreende o

relacionamento entre o middleware e os sistemas. Nesta seção é discutida como é re-alizada a comunicação dos componentes internos do middleware que foi implementadoatravés das regras de negócio internas. O protocolo deve realizar a troca de informaçõesentre diferentes sistemas os quais possuem maneiras específicas de receber e enviar asinformações. Desse modo o protocolo desenvolvido é capaz de unificar e padronizar aforma que os sistemas se comunicam no processo de importação e exportação de dadosna comunicação entre os sistemas. Para isto foi definido que o processo de comunicaçãoobedeça a uma política de comunicação centralizada através de um agente mediador entrerelacionamentos entre os sistemas.

Este protocolo foi implementado utilizando os conceitos do padrão de projeto Me-diator no que tange ao roteamento e entrega de mensagens entre os sistemas, por tercaracterísticas bem semelhantes aos problemas que este padrão de projeto se propõe aresolver. No planejamento das classes e objetos, foi definido um objeto mediador que en-capsula a forma como os objetos, representantes dos sitemas, interagem no contexto dosdados transferidos na integração. Este padrão de projeto promove um baixo acoplamentoevitando que os objetos façam referência uns aos outros de forma explícita, permitindovariar o uso da interação de forma independente (GAMMA, 2007).

O protocolo consite em duas figuras principais: o mediator (mediador) e o colleague(colaborador), a Figura 4.5 possui o diagrama de classe com os principais componentes esuas funcionalidades que são:

• Mediator: uma interface para realizar a comunicação com os objetos das classesfilhas de Colleague (colaboradores).• IntegraMediator: Uma classe concreta que implementa a interface Mediator, esta

classe conhece todos os sistemas da integração que serão representados por classesfilhas da classe Colleague através de referência a coleção dos objetos da classeColleague. Além disso, esta classe implementa o envio dos dados na comunicaçãoentre os sistemas que é executado através do método send(SolicitacaoBase dados,Colleague receiver) que tem como parâmetros os dados que precisam ser enviadose o colaborador que receberá os dados;• MSEColleague, REDMineColleague, SEDISSolicitaçãoColleague: São classes

colaboradoras que representam os sistemas que fazem parte da integração. Elas


possuem como atributo um objeto da interface Mediator através da herança, dessemodo cada sistema conhece o middleware não precisando conhecer cada sistemada integração. Nestas classes serão desenvolvidos os métodos receive() pois cadasistema terá seu próprio jeito de receber os dados e encaminha-los para serem per-sistidos.

Figura 4.5: Diagrama de classe.

Analisando o diagrama de classes e os diagramas de sequência que constam nestecapitulo, percebe-se que o envio e a recepção das mensagens que o middleware faz entreos sistemas segue o mesmo padrão que é realizado através dos métodos send() e receive().

O método send() está implementado na classe IntegraMediator que é o responsávelpelo envio dos dados para os sistemas destinatários que de acordo com cada comunica-ção, este método vai variando os parâmetros que estão sendo enviados. Seu primeiroparâmetro é o dado que vai ser enviado para o sistema destino. Neste parâmetro temosuma variação de dados através da herança entre as classes de domínio que são Atividadee ChamadoTecnico ambas classes filhas de SolicitacaoBase.

O segundo parâmetro é referente o destinatário da informação que também sofre va-riação baseado no mesmo principio da herança onde temos as classes MSEColleague,SEDISSolicitacaoColleague, REDMINEColleague filhas da classe Colleague. Cada sis-tema colaborador que deseje entrar no circuito da integração deve ser criado uma classefilha da classe Colleague.

O método receive() é implementado em cada classe colaboradora (filhas de Collea-gue) e cada classe terá uma implementação diferenciada da outra pois cada sistema definecomo será a recepção destes dados internamente. Neste método são invocados os consu-midores de serviços para comunicar-se com os sistemas destinatários.


De acordo com a modelagem das classes e métodos desenvolvidos para atender esteprotocolo de comunicação internamente no middleware, podemos obter as seguintes van-tagens :

• Desacoplamento entre os diversos participantes da rede de comunicação pois par-ticipantes não se conhecem, eles precisam apenas conhecer o middleware e esteconhece todos os participantes.• Eliminação de relacionamentos muitos para muitos que são substituídos por relaci-

onamentos um para muitos.• Alta coesão com uma política de comunicações centralizada no mediador com clara

separação de responsabilidades das classes.

Com a utilização desta estratégia, o INTEGRA poderá proporcionar a disponibiliza-ção de serviços em um local único e centralizado, aumentar o reuso, diminuir o acopla-mento entre consumidores e provedores de serviços, assim acarretando a redução signifi-cativamente da dependência entre ambos, de forma que manutenções, que são inevitáveis,possam ser feitas com maior rapidez, facilidade e organização. Todos estes fatores contri-buem na redução de custos, seja pela manutenção facilitada (com baixo impacto) ou sejapelo reuso proporcionado.

4.5 Comunicação entre o MSE e o SEDIS SolicitaçãoA integração entre o MSE com o SEDIS Solicitação está representada pelos casos

de uso relatar problemas relacionados ao Moodle e transformar uma solicitação externaem uma solicitação interna no SEDIS Solicitação como mostra a Figura 4.6. Estes ca-sos de uso estão relacionados com a transformação de um problema técnico, detectadopelos usuários, nos ambientes virtuais de aprendizagem em uma solicitação no SEDISSolicitação.

4.5.1 Relatar problemas relacionados ao MoodleEste caso de uso substituirá a antiga maneira que o usuário tinha de comunicar-se com

o setor de suporte que era por telefone e e-mail. Com essa nova funcionalidade, o usuárioutiliza o novo canal de comunicação (MSE) que será acessado através da página inicialdo Moodle por um link na parte superior da tela chamado SUPORTE, para que o usuáriopossa informar ao setor de suporte algum possível problema através do sistema.


Figura 4.6: Casos de uso relacionados a integração do MSE com o SEDIS Solicitação.

De acordo com a Figura 4.7, o usuário informa seu nome, e-mail, telefone, assunto eos detalhes do problema que está ocorrendo. Quando o usuário clicar em enviar, o MSEvai validar os dados e encaminha-los para o INTEGRA, através de um service consumer,para que estes dados cheguem até o SEDIS Solicitação para que seja solucionado pelaequipe de TI da SEDIS.

Figura 4.7: MSE - Tela de captação dos problemas dos usuários externos.

Para entender melhor como o processo deste caso de uso, a Figura 4.8 possui o dia-grama de atividades que contém o fluxo das atividades por meio de uma série de açõesnecessárias para a execução destes casos de uso. Pelo diagrama percebemos como ossistemas Solicitações Externas, SEDIS Solicitação e INTEGRA estão interagindo no pro-cesso de integração.


Figura 4.8: Diagrama de atividades do caso de uso: Relatar problemas relacionados aoMoodle.

O diagrama de sequência ilustrado na Figura 4.12 mostra como acontecem as princi-pais trocas de mensagens internamente no middleware entre os sistemas MSE e SEDISSolicitação. No diagrama temos estes sistemas representados como atores por estareminteragindo com o middleware diretamente.

A classe IntegradorServerImp implementa uma interface de serviços que comunicam-se com os sistemas envolvidos na integração, ela faz o papel do service provider do INTE-GRA. Após os dados da solicitação externa chegar no middleware, eles serão transforma-dos em uma solicitação e entregues ao sistema destino, SEDIS Solicitação, em forma deum chamado técnico. A classe responsável pela comunicação com o SEDIS Solicitação éa SEDISSolicitaçãoWS que exerce opapel de service consumer para comunicar-se com oservice provider implementado no SEDISSolicitação.


Figura 4.9: Diagrama de sequência: relatar problemas relacionado ao moodle

4.6 Integrando o SEDIS Solicitação com o RedmineA integração entre o SEDIS Solicitação e o Redmine está representada pelos casos de

uso exportar Solicitação para o Redmine, listar solicitações exportadas e transformar umaSolicitação em uma atividade como mostra a Figura 4.10.

Figura 4.10: Diagrama de casos de uso relacionados a integração do SEDIS Solicitação eo Redmine.


4.6.1 Exportar Solicitação para o RedmineEste caso de uso é responsável pela transformação de uma solicitação, que não pode

ser resolvida pelo setor de suporte, do SEDIS Solicitações em uma tarefa no Redminepara que o setor de desenvolvimento atenda a solicitação feita pelo setor de suporte. Paraentender melhor este caso de uso, a Figura 4.11 possui o diagrama de atividades quecontém o fluxo de trabalho por meio de uma série de ações necessárias para a execuçãodeste caso de uso. Pelo diagrama percebemos que este caso de uso tem início no sistemaSEDIS Solicitação, passando pelo INTEGRA e finalizando no Redmine.

Figura 4.11: Diagrama de Atividades: Exportar uma solicitação do SEDIS Solicitaçãopara o Redmine.

Para que os dados da solicitação possam ser exportados para o Redmine pelo usuá-rio, eles precisam ser transferidos pelos serviços entre o SEDIS Solicitação e o INTE-GRA de acordo com a Figura 4.4 mencionada anteriormente. O INTEGRA por sua vezcomunicar-se com o Redmine através de serviços web para enviar os dados e criar umatarefa vinculada a um projeto para ser resolvida pelo setor de desenvolvimento.

O diagrama de sequência abaixo ilustra o comportamento dinâmico dos objetos destecaso de uso, nele temos as principais trocas de mensagens executadas internamente nomiddleware INTEGRA para transportar os dados do SEDIS Solicitação para o Redmine.

Este caso de uso está disponível no SEDIS Solicitação, pode ser encontrada na lista-gem das solicitações pelo caminho "home→ solicitações "e pode ser acessada através do


Figura 4.12: Diagrama de sequência: Exportar uma solicitação do SEDIS Solicitação parao Redmine.

botão "Exportar" como mostra a Figura 4.13.


Figura 4.13: Exportar uma solicitação do SEDIS Solicitação para o Redmine.

Ao clicar em exportar na primeira tela(Figura 4.13), o sistema mostra os dados dasolicitação em uma segunda tela (Figura 4.15)para o usuário escolher para qual projetodo Redmine ele gostaria de exportar a solicitação como uma atividade.

Figura 4.14: Confirmar a Exportação da solicitação.

Assim que o usuário selecionar o projeto e confirmar a exportação, o sistema enca-minha os dados para o Redmine. A partir deste momento, é criado um registro de umaatividade, referente a solicitação exportada, no sistema Redmine e pode ser visualizadana listagem de atividades que tenham o status de "importadas". A Figura 4.15 possui aimagem de duas telas do Redmine, a primeira mostra uma listagem mais abrangente detodos os tipos de ativides referentes ao projeto. A segunta tela mostra um detalhamentodas atividades que foram importadas do SEDIS Solicitação para o Redmine.


Figura 4.15: Atividades importadas no REDMINE.

4.6.2 Listar Solicitação exportada no SEDIS Solicitação.Este caso de uso é considerado um caso de uso auxiliar a integração pois ele foi imple-

mentado no SEDIS solicitação para dar suporte as operações necessárias para o usuáriovisualizar as solicitações que foram exportadas para o Redmine.

Quando o usuário entra no sistema, ele tem a opção de verificar as solicitações quechegaram para ele resolver. Nesta tela de minhas solicitações o sistema já possuía osseguintes estados para as solicitações: Novas, Andamento, Esperando sua aprovação eFechadas. Houve a necessidade de adicionar mais um estado que abrange as solicitaçõesexportadas para que o usuário tenha o controle de quais solicitações foram enviadas para oRedmine. Esta nova funcionalidade que foi adicionada pode ser acessada através do botão

que traz um conjunto de registros referentes as solicitações queestão neste estado.

A listagem em si já traz algumas informações da solicitação como quem solicitou,data de abertura, previsão, assunto e ultima atualização como mostra a Figura 4.16.

Caso o usuário queira obter mais informações, ele pode visualizar o histórico das


Figura 4.16: Listar solicitações exportadas.

transações que a solicitação teve através do botão "Histórico" que abrirá uma novapágina mostrando qual foi o usuário que fez a alteração, a data e os detalhes das alteraçõesque foram feitas como mostra a Figura 4.17.

Figura 4.17: Histórico da solicitação exportada.

Temos também a opção de visualizar o conteúdo na integra da solicitação clicando

no botão "Detalhes" que abrirá uma nova página com todos os dados da solicitaçãocomo mostra a figura 4.18.

4.6.3 Finalizar atividade importada no Redmine.Quando um usuário finalizar uma atividade importada no sistema Redmine, o mid-

dleware INTEGRA capta todo histórico das atualizações feitas na atividade pelos usuá-


Figura 4.18: Detalhes da solicitação exportada.

rios do Redmine, transforma uma solicitação (chamado técnico) referente a atividade eenvia para o SEDIS Solicitação para ser atualizado. Feito isso a solicitação é finalizadae o setor de suporte pode sinalizar para o usuário que o seu problema foi resolvido. AFigura 4.22 contém o diagrama de caso uso.

Figura 4.19: Casos de uso relacionados a integração do Redmine com o SEDIS Solicita-ção.

A Figura 4.20 possui a tela de visualizar atividades importadas no Redmine, a ativi-dade ilustrada foi transferida para o Redmine pelo INTEGRA, através desta tela pode-se ver todos os detalhes da tarefa como o forma de criação (oriunda da integração),a situação, o responsável, data de criação, previsão para finalização, histórico. Comofoi dito antes, a notificação no SEDIS Solicitação é disparada automaticamente pelafinalização da atividade mas também pode ser executada manualmente através do link

como mostra a imagem abaixo.A Figura 4.11 possui o diagrama de atividades que contém o fluxo das atividades

necessárias para a execução deste caso de uso. Pelo diagrama percebemos que este casode uso tem início no sistema Redmine, passando pelo INTEGRA e finalizando no SEDISSolicitação.


Figura 4.20: Detalhamento de uma atividade importada no Redmine.


Figura 4.21: Diagrama de Atividade: Finalizar atividade importada no Redmine.

O diagrama de sequência (Figura 4.22) deste caso de uso mostra os objetos e suasmensagens trocadas no processo de transformação de uma atividade finalizada no Red-mine em uma solicitação para ser finalizado no SEDIS solicitação. Este diagrama repre-senta a integração entre o Redmine e o SEDIS solicitação.


Figura 4.22: Diagrama de sequência Finalizar atividade importada no Redmine.

Capítulo 5

Estudo de caso.

Este capítulo discute, a partir de dois cenários, a abordagem do processo de funciona-mento do setor de TI-SEDIS com a utilização dos sistemas de help desk (SEDIS Solicita-ção e MSE – Módulo de Solicitação Externa) e issue traking (Redmine).

O primeiro estudo será um cenário onde não teremos a utilização do middleware IN-TEGRA. Assim temos os subsetores e sistemas operando de maneira isolada como asinformações sendo transmitidas entre os sistemas de maneira manual. Este cenário exis-tiu entre os anos de 2011 até 2015.

O segundo estudo mostra o mesmo setor de TI-SEDIS utilizando os mesmos sistemasde help desk (SEDIS Solicitação) e issue traking (Redmine) mas agora a diferença é queestes sistema estão funcionando e maneira integrada através do middleware INTEGRAdesenvolvido neste trabalho, assim o estudo abordará como o INTEGRA auxilia na trans-missão das informações de forma automatizada impactando positivamente na qualidadedos serviços prestados pelo setor de TI.

5.1 Cenário 1 – Antes do desenvolvimento do middleware.Para avaliar este estudo, temos a resolução de um chamado técnico realizada em um

ambiente monitorado e com o tempo de execução das atividades cronometrado. Estechamado exigiu esforços de trabalho das duas equipes (suporte e desenvolvimento) dosetor de TI da SEDIS. Assim dividimos a resolução em cinco etapas (E1, E2, E3, E4 eE5). Cada etapa possui a descrição das atividades executadas, os executores e o tempogasto em minutos para a realização de cada etapa. Todos estes dados estão ilustrados nafigura 5.1.

CAPÍTULO 5. ESTUDO DE CASO. 50

Figura 5.1: Etapas do chamado cenário 1.

O problema analisado neste cenário está detalhado na Figura 5.2 com a descrição,tempo de resolução e os atores que participaram deste estudo.

Figura 5.2: Resolução do primeiro chamado

Este problema foi resolvido de maneira isolada em um ambiente controlado e com


o tempo monitorado, devemos ter ciência que no cotidiano temos problemas de diversosgraus de complexidade e um grande número de solicitações de serviços requisitados pelosetor de TI.

O gráfico na Figura 5.3 possui um levantamento dos chamados técnicos atendidos pelosetor de TI no primeiro semestre do ano de 2015 para termos uma dimensão do trabalhoexecutado entre as equipes (suporte e desenvolvimento). Os chamados estão divididosem duas categorias que são chamados dos usuários externos provenientes do e-mail echamados dos usuários internos provenientes dos funcionários da SEDIS.

Figura 5.3: Chamados atendidos no primeiro semestre de 2015

5.2 Cenário 2 – Depois do desenvolvimento do middleware.Neste cenário temos a resolução do mesmo problema que também ocorreu no mesmo

ambiente virtual de aprendizagem (Moodle). O que muda entre os ambientes é que no pri-meiro cenário temos o Moodle NESC que é utilizado pelo Núcleo de Estudos em SaúdeColetiva (NESC) e no segundo cenário temos o Moodle UNASUS que é utilizado peloprograma MAIS MÉDICOS na promoção de Educação Permanente. Este novo cenáriosofre mudanças nas etapas (E1, E3 e E5) por causa da utilização do middleware IN-TEGRA, pois ele impacta diretamente nestas etapas, estas mudanças estão descritas naFigura 5.4.


Figura 5.4: Etapas do chamado no cenário 2.

O problema analisado neste segundo cenário está detalhado na tabela abaixo coma descrição, tempo de resolução e os atores que participaram deste estudo da mesmamaneira que foi detalhado no primeiro cenário.

Figura 5.5: Resolução do segundo chamado

Neste semestre uma parte da integração que o middleware executa (entre o MSE e o


SEDIS Solicitação) entrou em funcionamento em janeiro e foi através dela que foi pos-sível captar um novo tipo de chamados externos que são os chamados provenientes doMSE (incorporado pelos ambientes virtuais de aprendizagem da SEDIS). Com a utili-zação do middleware mesmo pela metade percebeu-se que muito trabalho que a equipeexecuta não era contabilizado como mostra o gráfico na Figura 5.6 com os números doschamados técnicos atendidos pelo setor no primeiro semestre do ano de 2016.

Figura 5.6: Chamados atendidos no primeiro semestre de 2016

De acordo com o gráfico acima, vemos que a quantidade dos chamados técnicos dosusuários externos (e-mail e MSE) é muito superior aos chamados técnicos dos usuários in-ternos, isto acontece pelo motivo de termos muito mais alunos (usuários finais) utilizandoos serviços de TI da SEDIS do que a quantidade de funcionários da TI(chamados internos). Percebe-se também que ouve uma diminuição drástica nos números de e-mails envia-dos com os problemas dos usuários externos pois estas demandas estão sendo captadaspela integração do MSE com o SEDIS Solicitação que no primeiro cenário não existia. Ográfico ilustrado na Figura 5.7 mostra a origem destes chamados e traz um detalhamentodos chamados captados pelo MSE originados do Moodle Acadêmico, NESC, Pós UAB,Extensão e AVASUS.


Figura 5.7: Total de chamados atendidos no primeiro semestre de 2016

5.3 Conclusões do Estudo de CasoComparando os resultados dos dois cenários estudados, percebe-se grandes mudan-

ças nas etapas 1, 3 e 5 que são exatamente as etapas que são afetadas diretamente pelaintegração dos sistemas.

A Etapa 1 do segundo cenário faz parte da integração entre o MSE e o SEDIS Solicita-ção. Esta integração é a porta de entrada de solicitações que antes não eram contabilizadaspor serem atendidas pelo e-mail ou pelo telefone. No segundo cenário, estas demandasde trabalho são documentadas no SEDIS Solicitação através do middleware que recebeos dados do MSE e transporta-os para o SEDIS Solicitação. O principal motivo peladiminuição de tempo desta etapa é devido a automatização do procedimento de capta-ção dos chamados, anteriormente realizado por meio manual pelo técnico de suporte, oqual acessava o correio eletrônico para obter os dados e criá-los no SEDIS Solicitação.Atualmente, o chamado técnico é criado pelo usuário através do MSE e transportado di-retamente para o SEDIS Solicitação. Comparando a etapa 1 com os cenários descritos,éfacil notar que desperdiçava-se tempo entre a checagem de um e-mail até a criação de umchamado no SEDIS Solicitação. Muitas vezes este procedimento não é feito por conta daalta demanda de trabalho da equipe haja vista a quantidade de chamados atendidos pelaTI como mostra o gráfico na Figura 5.7.

A Etapa 3 do segundo cenário é referente a integração entre o SEDIS Solicitação e oRedmine que trata da tramitação de um chamado técnico entre o setor de suporte e o setorde desenvolvimento, transformando um chamado técnico do SEDIS Solicitação em umaatividade vinculada a um projeto no Redmine. Nesta etapa, houve um ganho de tempo


pois existiam problemas de comunicação entre os coordenadores das equipes, o que retar-dava a resolução dos chamados técnicos que exigiam esforços dos dois setores (suportee desenvolvimento) para serem resolvidos. Esta falta de comunicação entre os coorde-nadores acontecia com frequência devido aos seguintes motivos: Viagens pela SEDIS,treinamento fora da SEDIS e reuniões externas a SEDIS. Dessa maneira, muitas vezesuma demanda não tinha como ser repassada de um setor para outro, por este motivo, oca-sionava lentidão no processo de atendimento ao usuário. Com este novo cenário, o setorganha com o fim do conflito de responsabilidades, pois a demanda vai ser delegada parao coordenador do setor de desenvolvimento, através do middleware automatizando esteprocedimento e resguardando ambas as partes.

A Etapa 5 é bem semelhante a Etapa 3, a diferença é que o fluxo que as informaçõespercorrem é em sentido contrário, o middleware recebe a informação que a atividadefoi finalizada no Redmine e notifica o SEDIS Solicitação sobre a resolução do chamadotécnico pela equipe de desenvolvimento. Os ganhos nesta etapa são os mesmos da etapa 3,pois o problema de comunicação entre os coordenadores dos setores aconteciam tambémnesta etapa.

Consoantes às informações descritas nos parágrafos anteriores, o INTEGRA propõe-se a diminuir o tempo de resolução de um chamado técnico, com um ganho considerávelde tempo, em torno de 50%, esse tempo ganho multiplicado pelo numero de chamadosatendidos em um dia, ganha elevada proporção, uma vez que, o setor possui uma médiade atendimento de 29 chamados diários, nos meses de maior movimento, e 12 chamadosdiários, nos meses de menor movimento (férias letivas), o que é um tempo considerávelpor dia a ser ganho, proporcionando fluidez às demandas do setor, tornando-o mais efici-ente e eficaz. Esta redução de tempo foi baseada em um atendimento de chamado técnicode complexidade moderada. Vale ressaltar que o setor possui chamados de vários níveisde complexidades que influenciam diretamente no tempo de resolução.

Para finalizar este capítulo, podemos dizer que este estudo de caso possibilitou com-provar que é possível integrar sistemas heterogêneos de help desk e issue traking atravésdo INTEGRA com as estratégias abordadas neste trabalho. Parte da integração deve-seao fato do INTEGRA utilizar-se de uma camada de serviços web que se utiliza de padrõespara efetuar a troca de dados, baseado em contratos (interfaces) e a outra parte da integra-ção deve-se ao fato de utilizar padrões consolidados de integração de sistemas para efetuaro envio e o recebimento dos dados entre os sistemas pelo middleware. Assim dessa formaos sistemas legados podem interagir entre si desde que respeitem as interfaces criadaspelo middleware.

Observou-se também uma otima interoperabilidade entre as aplicações, visto que foipossível integrar informações fornecidas por aplicações implementadas em PHP, Java eRuby on Rayls. Ou seja, linguagens de programação e plataformas distintas e por fimpode-se afirmar que o INTEGRA alcançou o objetivo de forma satisfatória, pois possibi-litou a comprovação da interoperabilidade entre os sistemas vistos neste capítulo.

Capítulo 6

Considerações Finais.

Neste capítulo é apresentado uma análise sobre as contribuições apresentadas nestadissertação, apontando os principais aspectos observados sobre o desenvolvimento domiddleware INTEGRA destinado a integração de sistemas de em ambientes heterogê-neos. Serão descritas também algumas sugestões para trabalhos futuros.

A área de integração de sistemas está em crescente evolução, novos aplicativos vêmsendo desenvolvidos a cada dia e uma prova disse é a grande quantidade de aplicativosdisponíveis no mercado para inúmeros contextos diferentes. Este crescimento vem au-mentando cada vez mais a necessidade de tornar aplicativos interoperáveis conduzindoo desenvolvimento de aplicativos para um modelo de computação distribuída. Os mode-los arquiteturais, encontrados nos sistemas distribuídos, proporcionam o surgimento demodelos de gestão empresariais dinâmicos que necessitam de softwares que se comuni-quem de maneira ágil e assim propicie subsídios aos processos de tomada de decisõescom rapidez e eficiência. Neste contexto a integração da informação dentro do ambientecorporativo torna-se fator de essencial importância no contexto estratégico e decisório dascorporações.

A elaboração deste trabalho, incluindo as etapas de pesquisa e estudos juntamentecom a implementação do middleware INTEGRA, possibilitou a validação e comprovaçãoda interoperabilidade proveniente dos sistemas distribuídos mais especificamente à utili-zação de Web services atrelado com os padrões de projetos para integração de sistemas.Desse modo foi constatado que a integração dos dados fornecidos pelos sistemas legadossem a preocupação de mudar as características (linguagem de programação, banco de da-dos, sistemas operacionais dentre outros) particulares de cada sistema. Esta validação ecomprovação foram elaboradas através de testes do middleware interagindo com os sis-temas de help desk (SEDIS Solicitação) e issue tracking (Gerenciamento de projetos) noambiente de testes do setor de tecnologia da informação da SEDIS.

6.1 Principais contribuições.A principal contribuição deste trabalho foi propor e implementar um software capaz

de integrar sistemas de help desk e issue tracking denominado INTEGRA, este softwareoferece às aplicações uma gama de serviços padronizados para as trocas de mensagens en-

CAPÍTULO 6. CONSIDERAÇÕES FINAIS. 57

tre os sistemas. O INTEGRA implementa um protocolo de comunicação para o rotear asmensagens baseados em padrões de projetos de integração consolidados e sugeridos pelaliteratura. Além disso, o INTEGRA foi desenvolvido sob uma arquitetura que qualqueroutro sistema pode ser adicionado no circuito de integração entre os sistemas sem sofrerfortes impactos no que tange a adaptações e mudanças garantindo a manutenibilidade dosoftware. Para isto ocorrer é necessário que as informações que precisem ser integradassejam modeladas de acordo com as classes de domínio do projeto que foram projetadasincorporando os conceitos de encapsulamento, herança e polimorfismo do paradigma dalinguagem de programação orientada a objetos.

Através destas estratégias conseguimos chegar a um equilíbrio entre o princípio dodesacoplamento e o princípio da distribuição de responsabilidade de maneira uniforme,garantindo assim um baixo acoplamento e uma alta coesão que são princípios desejáveisna engenharia de software e que muitas vezes são ignorados. Dentre as vantagens doINTEGRA utilizar serviços web para comunicar-se com as aplicações podemos destacara independência da plataforma que o sistema, que deseja ser integrado, foi desenvolvido eassim temos um ganho na facilidade de manutenção, pois a partir do momento que temosuma interface pré-estabelecida é possível modificar sua implementação sem ter impactosnos clientes consumidores daquele serviço.

6.2 Limitações.Uma das limitações deste trabalho é relacionada à adição de um novo sistema no cir-

cuito da integração. Isso porque não é um procedimento tão rápido e automatizado de sefazer. O sistema a ser integrado deve ter uma camada de Web service para comunicar-secom o middleware e caso o sistema não o tenha, o responsável pelo processo de integra-ção terá que desenvolver esta camada da mesma maneira que foi feito neste trabalho parao INTEGRA comunicar-se o SEDIS Solicitação e o MSE. Em alguns casos quando osistema a ser integrado mude muito do escopo do que foi modelado nas classes de domí-nio do INTEGRA, a pessoa responsável pela integração também terá que fazer algumasmudanças nestas classes sempre atento com o domínio, pois as mensagens trocadas pelosmétodos send() e receive() do INTEGRA transportam dados de acordo com as classes dedomínio.

Em casos que o sistema que deseje entrar no circuito da integração tenha uma camadade serviços, outro desafio seria de fazer um link entre as camadas de serviço do sistemacom o INTEGRA pois nem sempre os serviços serão totalmente compatíveis em relação asuas interfaces e pode ser que seja necessário desenvolver novos serviços e funções assimcomo foi realizado na camada de serviços do Redmine desenvolvido neste trabalho.

6.3 Trabalhos futurosEste trabalho propôs um software de integração de sistemas de issue tracking com

sistemas de help desk, como trabalhos futuros algumas extensões ao software podem sersugeridas, de modo a permitir novas contribuições ao estado da arte agregando novos

CAPÍTULO 6. CONSIDERAÇÕES FINAIS. 58

conhecimentos na área de computação distribuída. Neste sentido pode-se pensar em de-senvolver alguma extensão que facilite o processo de ligação de algum novo sistema quese deseja integrar na ferramenta através do uso de ontologias para mapear conceitos eserviços usados na comunicação entre o sistema e o middleware, pois até o presente mo-mento esta tarefa é feita de forma manual e pragmática.

Recomenda-se também avaliar a aplicabilidade do middleware INTEGRA não so-mente para o contexto de integração de softwares de issue tracking e help desk, mas tam-bém em outros contextos que se encaixe com a modelagem das classes de domínio que oINTEGRA foi projetado que provavelmente será encontrado nos setores de tecnologia dainformação da UFRN.

Referências Bibliográficas

BIEBERSTEIN, N. Service-oriented architecture compass: business value, planning,and enterprise roadmap. [S.l.]: FT Press, 2006.

CHAPPELL, D. A.; JEWELL, T. Java web services. [S.l.]: Tecniche Nuove, 2002.

COELHO, P. R. d. S. L. et al. Uma arquitetura orientada a serviços para laboratórios deacesso remoto. Campinas, SP, 2006.

COLE, J.; FOSTER, H. Using Moodle: Teaching with the popular open source coursemanagement system. [S.l.]: "O’Reilly Media, Inc.", 2007.

ERL, T. Service-oriented architecture (soa): concepts, technology, and design. PrenticeHall, 2007.

FILHO, A. R. P. Introdução ao moodle: ambiente de aprendizagem. Universidade deBrasília. Módulo, v. 1, 2004.

FOOTEN, J.; FAUST, J. The service-oriented media enterprise: SOA, BPM, and webservices in professional media systems. [S.l.]: CRC Press, 2012.

GAMMA, E. Padrões de Projetos: Soluções Reutilizáveis. [S.l.]: Bookman, 2007.

HANSEN, M.; MADNICK, S.; SIEGEL, M. Data integration using web services. MITSloan School of Management, 2003.

HOHPE, G.; WOOLF, B. Enterprise integration patterns: Designing, building, anddeploying messaging solutions. [S.l.]: Addison-Wesley Professional, 2004.

LINTHICUM, D. S. Next generation application integration: from simple information toWeb services. [S.l.]: Addison-Wesley Longman Publishing Co., Inc., 2003.

MACIEL, R.; ASSIS, S. Middleware: Uma solução para o desenvolvimento deaplicações distribuídas. CienteFico. Ano IV, v. 1, 2004.

MACKENZIE, C. M. et al. Reference model for service oriented architecture 1.0. OASISstandard, v. 12, 2006.

MARTINS, M. R. A. Integração sistêmica em middleware. Tese (Doutorado) —Universidade de São Paulo, 2010.

59

REFERÊNCIAS BIBLIOGRÁFICAS 60

MOODLE. Modular Object-Oriented Dynamic Learning Enviroment. [S.l.], 2015.Disponível em: <http://moodle.org>.

NETO, F. M. M.; BRASILEIRO, F. V. Uma taxonomia para ambientes de aprendizagemsuportados pela web. Anais do XXII CSBC, 2002.

OLIVEIRA, E. M. de. Cooperação Intersistêmica em Apoio à Educação Profissional eTecnológica. Dissertação (Mestrado) — Universidade Federal do Ceará, 2009.

OLIVEIRA, I. D. d. et al. Sistemas de apoio a educação a distância: uma experiência nasedis/ufrn. 2013.

PERRY, D. E.; WOLF, A. L. Foundations for the study of software architecture. ACMSIGSOFT Software Engineering Notes, ACM, v. 17, n. 4, p. 40–52, 1992.

SABBATINI, R. M. Ambiente de ensino e aprendizagem via internet a plataformamoodle. São Paulo: Instituto EduMed, 2007.

SOMMERVILLE, I. Engenharia de Software. [S.l.: s.n.], 2007. v. 8.

ZHENG BO DONG, F. T. W. C. Q. A service-oriented approach to integration ofe-learning information and resource management systems. p. 1047–1052, 2008.

Documents

INTEGRA: Uma solução para integração de sistemas de ... · UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE INSTITUTO METRÓPOLE DIGITAL PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA