Integra: uma solução para integração de sistemas de HelpDesk com sistemas de Issue Tracking em ambientes heterogêneos

Texto

(1)U NIVERSIDADE F EDERAL DO R IO G RANDE DO N ORTE I NSTITUTO M ETRÓPOLE D IGITAL P ROGRAMA DE P ÓS -G RADUAÇÃO EM E NGENHARIA DE S OFTWARE. INTEGRA: Uma solução para integração de sistemas 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 de Pós-Graduação em Engenharia de Software da UFRN para obtenção do título de Mestre em Engenharia de Software. Área de concentração: Engenharia de Sistemas WEB. Natal-RN, 24 de Agosto de 2016.

(2) Catalogação da Publicação na Fonte Universidade Federal do Rio Grande do Norte - Sistema de Bibliotecas Biblioteca 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, Instituto 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, Idalmis Milian Sardina. II. Lopes, Frederico Araújo da Silva. III. Título. RN/UF/BCZM. CDU 004.75.

(3) INTEGRA: Uma solução para integração de sistemas 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 examinadora composta 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.

(4) Dedico este trabalho a minha sobrinha especial Juju, que Deus ilumine sua mente e cuide de sua saúde mais que tudo neste mundo! Te amo Juju..

(5) Agradecimentos. Primeiramente a Deus, o todo poderoso que me iluminou e me abençoou por toda minha trajetória por onde eu tenho andado. À minha grande família pelo apoio durante esta jornada, ao meu amado pai Eliésio, Minha amada e idolatrada mãe Angela, meus grandes irmãos Diorgenis e Junior, A minha sobrinha mais que especial Juju e ao meu grande amor Jéssyca Ataliba por todo apoio dado nesta jornada. Ao meu orientador e ao meu co-orientador, professores Idalmis e Frederico, sou muito grato pela orientação e dedicação por todo este tempo. Ao professor e amigo Ricardo Valentim por sempre me apoiar nas minhas empreitadas acadêmicas. Aos meus grandes amigos Júlio Silva e Pierre Freire pelas sugestões, ajudas e críticas deste trabalho..

(6) Resumo. As organizações públicas e privadas vêm se adaptando às mudanças tecnológicas constantemente 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 constante de suas tecnologias dado o ritmo das inovações. Essa evolução constante muitas vezes acaba criando um ambiente de sistemas, muito heterogêneo nas empresas. Este fato acontece quando temos um conjunto de sistemas desenvolvidos em diversas plataformas (por exemplo, linguagem de programação e/ou banco de dados) operando de maneira isolada. As empresas que possuem alta heterogeneidade precisam adotar estratégias para prover interoperabilidade em seus sistemas, disponibilizando assim uma melhor comunicação entre os softwares, visando propiciar o intercâmbio de informações entre os departamentos das empresas e mantendo suas regras de negócios integradas. O objetivo central desse trabalho é desenvolver estratégias que permitam a integração de sistemas distintos entre si, garantindo a interoperabilidade entre eles independente da plataforma e linguagem de desenvolvimento dos mesmos. Em particular, a proposta foi criada e desenvolvida para a Secretaria de Ensino a Distância – SEDIS, pertencente a Universidade Federal do Rio Grande do Norte - UFRN, mas pode ser estendida a qualquer instituição pública de ensino superior. Como resultado desse estudo foi produzido um middleware concebido em uma arquitetura orientada a serviços com o objetivo principal de resolver os problemas atuais que existem de comunicação e performance entre os diferentes sistemas de informação da SEDIS na UFRN. Palavras-chave: Integração de sistemas, interoperabilidade, ambientes heterogêneos..

(7) Abstract. Public and private organizations is coming to adapting to technological changes constantly because business needs independent of its expertise area, either with adaptation of best market practices or with the constant updating of its technologies given the pace of innovation. This constant evolution often creating a heterogeneous environment systems. This environment happens when we have a set of systems developed on multiple platforms (programming language, database) operating in isolation. Companies with this heterogeneity needs to adopt strategies to provide interoperability into their systems providing better communication between the softwares, these strategies will promote the exchange of information between the departments of companies keeping their integrated business rules. The main objective of this work is develop strategies to provide the integration of different systems with each other, ensuring interoperability between them, regardless of platform and development language thereof. In particular, the proposal was created and developed for the Department of Distance Education - SEDIS, belonging to the Federal University of Rio Grande do Norte - UFRN, but can be extended to any public institution of higher education. As result of this study it was produced a middleware that uses components of a serviceoriented architecture with the main objective to solve the current problems that exist in communication and performance between different SEDIS information systems at UFRN. Keywords: System integration, interoperability, heterogeneous environments..

(8) Sumário. Sumário. i. Lista de Figuras 1. Introdução 1.1 Contextualização . . . . 1.2 Desafios . . . . . . . . . 1.3 Problemática . . . . . . 1.4 Objetivos . . . . . . . . 1.5 Organização do trabalho. iii. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. Lista de Símbolos e Abreviaturas 2. 1 1 2 3 3 5 1. Fundamentação Teórica 2.1 Middleware . . . . . . . . . . . . . . . . 2.2 Padrões de projetos . . . . . . . . . . . . 2.2.1 Padrões de projetos de integração 2.3 Ambiente virtual de aprendizagem - AVA 2.4 Arquitetura de software . . . . . . . . . . 2.5 Arquitetura Orientada a Serviço - SOA . . 2.5.1 Camadas de abstração SOA . . . 2.6 Web service . . . . . . . . . . . . . . . . 2.7 Trabalhos relacionados . . . . . . . . . .. . . . . . . . . .. 6 6 6 7 9 9 10 10 12 12. 3. Sistemas Legados da SEDIS 3.1 SEDIS Solicitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Redmine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Moodle e o Módulo de Solicitação Externa - MSE . . . . . . . . . . . . .. 14 14 18 23. 4. Desenvolvimento da proposta de integração 4.1 Processo de funcionamento do setor de TI. . . . . 4.2 Problemática . . . . . . . . . . . . . . . . . . . 4.3 Proposta . . . . . . . . . . . . . . . . . . . . . . 4.4 INTEGRA . . . . . . . . . . . . . . . . . . . . . 4.4.1 Protocolo de comunicação . . . . . . . . 4.5 Comunicação entre o MSE e o SEDIS Solicitação. 27 27 30 31 32 34 36. i. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . . . . .. . . . . . .. . . . . . ..

(9) . . . . .. 36 39 40 43 44. 5. Estudo de caso. 5.1 Cenário 1 – Antes do desenvolvimento do middleware. . . . . . . . . . . 5.2 Cenário 2 – Depois do desenvolvimento do middleware. . . . . . . . . . . 5.3 Conclusões do Estudo de Caso . . . . . . . . . . . . . . . . . . . . . . .. 49 49 51 54. 6. Considerações Finais. 6.1 Principais contribuições. . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Limitações. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 56 56 57 57. 4.6. 4.5.1 Relatar problemas relacionados ao Moodle . . . . Integrando o SEDIS Solicitação com o Redmine . . . . . . 4.6.1 Exportar Solicitação para o Redmine . . . . . . . 4.6.2 Listar Solicitação exportada no SEDIS Solicitação. 4.6.3 Finalizar atividade importada no Redmine. . . . .. Referências bibliográficas. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. . . . . .. 59.

(10) Lista de Figuras. 2.1 2.2 2.3 2.4 2.5. Padrão Pipe and Filter. Fonte (HOHPE; WOOLF, 2004). . . . . . . . Padrão Message Router. Fonte (HOHPE; WOOLF, 2004). . . . . . . Padrão Message Translate. Fonte (HOHPE; WOOLF, 2004). . . . . . Padrão Control Bus. Fonte (HOHPE; WOOLF, 2004). . . . . . . . . Camadas abstração SOA. Fonte adaptado de (BIEBERSTEIN, 2006).. . . . . .. 7 8 8 9 11. 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14. Relação entre SEDIS Solicitação e o Ambiente Virtual de Aprendizagem . Atores do Sistema SEDIS Solicitação . . . . . . . . . . . . . . . . . . . Atores do Sistema SEDIS Solicitação . . . . . . . . . . . . . . . . . . . Modelo arquitetural do SEDIS Solicitação. . . . . . . . . . . . . . . . . . Relação entre Redmine e o Ambiente Virtual de Aprendizagem . . . . . . Atores do Sistema Redmine . . . . . . . . . . . . . . . . . . . . . . . . . Permissões do usuário gerente . . . . . . . . . . . . . . . . . . . . . . . Permissões do usuário desenvolvedor . . . . . . . . . . . . . . . . . . . Permissões do usuário informante . . . . . . . . . . . . . . . . . . . . . Permissões do usuário não membro . . . . . . . . . . . . . . . . . . . . Permissões do usuário anônimo . . . . . . . . . . . . . . . . . . . . . . . Atores do Moodle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Módulo de solicitação externa. . . . . . . . . . . . . . . . . . . . . . . . Arquitetura do Módulo de solicitação Externa. . . . . . . . . . . . . . . .. 15 15 16 18 19 20 20 21 21 22 22 24 25 26. Diagrama de atividades: Criação e atendimento de uma solicitação. . . . . Estrutura de funcionamento entre o SEDIS Solicitação e o Redmine. . . . Arquitetura de integração. . . . . . . . . . . . . . . . . . . . . . . . . . Novo modelo de comunicação proposto. . . . . . . . . . . . . . . . . . . Diagrama de classe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Casos de uso relacionados a integração do MSE com o SEDIS Solicitação. MSE - Tela de captação dos problemas dos usuários externos. . . . . . . . Diagrama de atividades do caso de uso: Relatar problemas relacionados ao Moodle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Diagrama de sequência: relatar problemas relacionado ao moodle . . . . 4.10 Diagrama de casos de uso relacionados a integração do SEDIS Solicitação e o Redmine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 Diagrama de Atividades: Exportar uma solicitação do SEDIS Solicitação para o Redmine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Diagrama de sequência: Exportar uma solicitação do SEDIS Solicitação para o Redmine. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29 30 33 33 35 37 37. 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8. iii. . . . . .. 38 39 39 40 41.

(11) 4.13 4.14 4.15 4.16 4.17 4.18 4.19. Exportar uma solicitação do SEDIS Solicitação para o Redmine. . . . . . Confirmar a Exportação da solicitação. . . . . . . . . . . . . . . . . . . . Atividades importadas no REDMINE. . . . . . . . . . . . . . . . . . . . Listar solicitações exportadas. . . . . . . . . . . . . . . . . . . . . . . . Histórico da solicitação exportada. . . . . . . . . . . . . . . . . . . . . . Detalhes da solicitação exportada. . . . . . . . . . . . . . . . . . . . . . Casos de uso relacionados a integração do Redmine com o SEDIS Solicitação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.20 Detalhamento de uma atividade importada no Redmine. . . . . . . . . . . 4.21 Diagrama de Atividade: Finalizar atividade importada no Redmine. . . . 4.22 Diagrama de sequência Finalizar atividade importada no Redmine. . . . .. 42 42 43 44 44 45. 5.1 5.2 5.3 5.4 5.5 5.6 5.7. 50 50 51 52 52 53 54. Etapas do chamado cenário 1. . . . . . . . . . . . . . . . Resolução do primeiro chamado . . . . . . . . . . . . . . Chamados atendidos no primeiro semestre de 2015 . . . . Etapas do chamado no cenário 2. . . . . . . . . . . . . . . Resolução do segundo chamado . . . . . . . . . . . . . . Chamados atendidos no primeiro semestre de 2016 . . . . Total de chamados atendidos no primeiro semestre de 2016. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 45 46 47 48.

(12) Capítulo 1 Introdução. Este capítulo descreve um breve panorama dos sistemas utilizados no setor de tecnologia 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 heterogêneos e a necessidade de integrar estes sistemas para eliminar as ilhas de informação sem perder os serviços fornecidos pelo setor. Desta forma o capítulo descreve também a motivação, os objetivos do trabalho assim como a ideia principal dos demais capítulos que compõem este trabalho.. 1.1. Contextualização. A 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 para a Educação a Distância nas ultimas décadas. Na Universidade Federal do Rio Grande do Norte – UFRN, este avanço ocorreu de maneira mais significativa na Secretaria de Ensino a Distância – SEDIS que teve que adequar-se a esta evolução passando por várias mudanças em seu ambiente computacional e organizacional. No que refere-se ao ambiente computacional , a evolução está relacionada ao crescimento de alguns setores da SEDIS e o desenvolvimento de novos sistemas de informação para ajudar na gerência das informações de cada setor. Assim surge um ambiente computacional atual da Tecnologia da Informação - TI da SEDIS composto por sistemas de informações autônomos, distribuídos e heterogêneos pois a construção, manutenção e operação ocorrem de forma independente e sem a preocupação de integração com outros sistemas. Esta autonomia traz como conseqüência um ambiente altamente heterogêneo, pois favorece a utilização de diferentes tecnologias de hardware e de software no desenvolvimento dos sistemas. Esta heterogeneidade dificulta a comunicação entre os setores da instituição pois estes setores são geridos por sistemas de informações, tornando os dados dissociados e assim impedindo que as informações sejam integradas de forma rápida e precisa criando um cenário de informações isoladas (ilhas de informação) o que dificulta as estatísticas para dar 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 proporcionam uma maior facilidade e diminuição das distâncias no que se refere à distribuição,.

(13) CAPÍTULO 1. INTRODUÇÃO. 2. localização e acesso às informações, por outro lado estimulam uma crescente divulgação de novas informações e em diversas mídias, realimentando o problema da heterogeneidade e distribuição. Com tantos sistemas trabalhando de maneira isolada e tendo a necessidade de interligase com outros sistemas de outros setores foram surgindo problemas como trabalho manual e cansativo uma vez que os usuários dos sistemas gerenciais precisam alimentar os mesmos dados entre diferentes sistemas com diferentes representações; inconsistência de dados, como o processo de alimentar o mesmo dado em sistemas diferentes está sendo feito de forma manual, muitas vezes este procedimento não é feito por conta das urgências das demandas e os setores não tem como contabilizar os serviços e tarefas realizadas pelas 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 entre os setores da TI no atendimento ao usuário, este cruzamento é extremamente importante a nível gerencial pois transforma dados brutos em informação qualitativa; Todos esses problemas 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 os funcionários desperdiçam tempo em atividades manuais que poderiam ser automatizadas e 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 setoriais 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ção de serviço da TI aos usuários.. 1.2. Desafios. Segundo 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 a crescente quantidade de fusões e aquisições de novas empresas, isto vem causando grandes preocupações para os CEOs das empresas pois qualquer solução de integração que seja 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 um computador para outro através das redes. Diferentemente de um processo em execução em um único computador, na computação distribuída existe uma preparação e preocupação maior para lidar com um conjunto maior de possíveis problemas que possam ocorrer no transporte dos dados. Muitas vezes, dois sistemas para serem integrados estão separados por continentes e os dados que irão trafegar entre eles tem 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 operacionais e formatos de dados. Uma solução de integração tem de ser capaz de interagir com todas estas diferentes tecnologias..

(14) CAPÍTULO 1. INTRODUÇÃO. 3. • A mudança é inevitável: Sistemas mudam ao longo do tempo, Uma solução de integração tem que prover mecanismos para lidar com o ritmo das mudanças nas aplicações que queiram conectar-se. Soluções de integração pode facilmente ser afetada 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 deve minimizar as dependências de um sistema para outro, provendo acoplamento fraco entre as aplicações.. 1.3. Problemática. A principal motivação para o desenvolvimento deste trabalho deve-se a falta de interoperabilidade 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 coorporativo da SEDIS causando ilhas de informações. O que se observou foi a crescente necessidade de troca de informações entre diferentes sistemas trabalhando de maneira isolada. Este isolamento vem causando problemas para o setor tais como trabalho manual pois os usuários dos sistemas tem que ficar atualizando uma mesma informação em mais 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 para os usuários finais. Nesse contexto é que surge a necessidade de criar uma ferramenta capaz de fazer a integração das informações entre os sistemas que operam no setor de TI da SEDIS e com isto criar uma maneira de interligar as informações que permeiam os setores da TI da SEDIS agregando assim o conceito de interoperabilidade 1 entre os sistemas de informação desta organização.. 1.4. Objetivos. O trabalho proposto tem como objetivo principal desenvolver e avaliar um middleware2 para integrar sistemas de gerenciamento de help desk(central de ajuda) com sistemas de issue tracking (gerenciamento de projetos/tarefas). Este middleware foi concebido por um estilo arquitetural de integração baseado em barramento de controle (control bus), através desse estilo será feito o controle do fluxo de mensagens de forma centralizada no middleware 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 1 Interoperabilidade:. Capacidade de diversos sistemas e organizações trabalharem em conjunto (interoperar) de modo a garantir que pessoas, organizações e sistemas computacionais interajam para trocar informações de maneira eficaz e eficiente. 2 middleware ou mediador: No campo da computação distribuída, é um programa de computador que faz a mediação entre software e demais aplicações. É utilizado para mover ou transportar informações e dados entre programas de diferentes protocolos de comunicação, plataformas e dependências do sistema operacional..

(15) CAPÍTULO 1. INTRODUÇÃO. 4. sistemas com o middleware será feita através da tecnologia de serviços web (Web services) servindo como pontes de comunicação. Com esta estratégia foi capaz de integrar os sistemas 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 onde temos esses tipos de sistemas (help desk e issue tracking) operando nos setores de suporte e desenvolvimento da TI-SEDIS. O primeiro sistema envolvido na integração é um módulo de solicitação externa, uma variação de um sistema de helpdesk, este é um novo módulo que foi desenvolvido neste trabalho para que o usuário final(alunos, tutores e professores) do Ambiente Virtual de Aprendizagem - AVA3 possa entrar em contato com o setor de suporte(central de ajuda) da TI. Este canal de comunicação teve a necessidade de ser criado para prover ajuda aos possíveis problemas que os usuários possam enfrentar com o uso do AVA. O segundo sistema envolvido na integração é o SEDIS Solicitação, este software foi desenvolvido pelo setor de TI da SEDIS para gerenciar os atendimentos dos chamados técnicos (help desk), ele é bastante utilizado no setor de suporte que é um subsetor da TI-SEDIS. O terceiro sistema envolvido na integração é o Redmine (issue tracking), uma ferramenta de gerenciamento de projetos utilizado no setor de desenvolvimento de sistemas que é 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ão utilizados na SEDIS possam criar chamados técnicos direcionados à equipe de suporte de TI. 2. Definir a arquitetura da integração que o middleware será implementado, esta arquitetura deverá ser capaz de fazer o intercâmbio dos dados entre os sistemas envolvidos sem alterar a estrutura e regras de negócios particulares de cada sistema preservando suas integridades. 3. Analisar as características individuais dos sistemas envolvidos para identificar as principais funcionalidades de cada sistemas. 4. Analisar a arquitetura dos sistemas envolvidos neste estudo identificando onde serão construídas as funcionalidades necessárias para que cada sistema possa efetuar a comunicação com o INTEGRA.. 3 Ambientes. virtuais de aprendizagem (do inglês: Virtual learning environment) são softwares que auxiliam na montagem de cursos acessíveis pela Internet..

(16) CAPÍTULO 1. INTRODUÇÃO. 1.5. 5. Organização do trabalho. Para 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 e requisitos dos sistemas estudados. O quarto capítulo apresenta o desenvolvimento do middleware INTEGRA bem como suas especificações. O quinto capítulo possui um estudo de caso do uso do INTEGRA aplicado no setor de TI da SEDIS. O sexto capítulo trás as considerações finas, apresentam-se as principais contribuições deste trabalho bem como as limitações. Também serão apresentadas algumas sugestões para futuros trabalhos.

(17) Capítulo 2 Fundamentação Teórica. Neste capítulo iremos abordar todos os conceitos que serão relevantes para o entendimento e compreensão do estudo realizado através de pesquisas na literatura sobre os temas inerentes ao trabalho.. 2.1 Middleware De 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 a implementar comunicação e oferecer suporte para compartilhamento de recursos distribuídos." o middleware caracteriza uma camada de software que possibilita a comunicação entre sistemas distribuídos, tendo por objetivo diminuir a complexidade e a heterogeneidade dos diversos sistemas existentes, disponibilizando serviços que efetuam a comunicação entre esta categoria de sistemas de modo transparente (MACIEL; ASSIS, 2004). Desse modo as plataformas de middleware formam uma cadeia de engrenagens de suma importância para o desenvolvimento de sistemas distribuídos, Essas plataformas criam camadas de abstração que ajudam na implementação de softwares de larga escala pois diminui a complexidade dos sistemas que o utilizam.. 2.2. Padrões de projetos. Padrões de projeto ou Design Patterns tiveram sua origem, segundo Gamma et al. (2000), nos trabalhos do arquiteto Christopher Alexander (ALEXANDER, 1977 apud GAMMA et al., 2000) sobre padrões utilizados na construção civil mais especificamente na arquitetura das cidades. Na área de computação, padrões de projeto são “descrições de objetos e classes relacionadas, que são personalizadas para resolver um problema geral de projeto, em um contexto particular” (GAMMA et al., 2000, p.20), ou seja, capturam experiências bem sucedidas de estruturas de sistemas, que podem ser reutilizadas em outros projetos. Analisando o cotidiano do desenvolvimento de software é possível identificar que a procura por uma solução de um problema específico possui características idênticas,.

(18) CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA. 7. senão igual a encontrada em um projeto anteriormente desenvolvido, neste contexto que entra a figura dos padrões de projetos onde possui documentado o contexto do problema e a solução abordada para solução daquele problema possibilitando o reaproveitamento das idéias e soluções. Desta forma, problemas idênticos que se repetem em outros contextos sã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 arquiteturas bem sucedidas para construir softwares de forma flexível e fácil de manter.. 2.2.1. Padrões de projetos de integração. Segundo Hohpe e Wolf (2004), sistemas de informação que trabalham em ambientes corporativos raramente operam de maneira isolada. Imagine um ambiente comercial funcionando na prática onde temos o software de vendas precisando comunicar-se com o software de estoque para dar baixa nos produtos vendidos. O aplicativo de aquisição deve se conectar a um site de leilão ou até mesmo o vendedor da empresa com seu PDA que precisa sincronizar seus dados com o servidor da empresa. Olhando assim podemos enxergar facilmente que qualquer aplicativo corporativo pode ser tornar mais eficiente quando se integra com outras aplicações. Todas as soluções de integração tem que lidar com alguns desafios fundamentais que ao longo do tempo, os desenvolvedores e arquitetos de softwares criaram alguns padrões de projeto de integração para superar estes esses desafios (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 computacionais são os filtros que agem como transdutores que recebem uma entrada, transformam 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 maneira temos um estilo arquitetural linear, onde podemos dividir uma tarefa de processamento maior em uma sequência tarefas menores, com etapas de processamento independentes (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 de fluxo, onde a mensagem que é recebida pode ser enviada para determinado canal, através da satisfação de determinada condição (HOHPE; WOOLF, 2004), conforme podemos acompanhar na ilustração da figura 2.2. Este padrão resolve o problema de como uma informação pode ser direcionada a diferentes filtros dependendo de.

(19) CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA. 8. condições específicas e traz como solução a implementação de um roteador que encapsula 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 diferentes filtros dependendo de condições específicas e traz como solução a implementação de um roteador que encapsula o critério de decisão para republicar uma mensagem 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 mensagem que foi utilizada, mas em outro formato (HOHPE; WOOLF, 2004), conforme pode ser observado na figura 2.3. Por exemplo, uma mensagem sai de um sistema X e passa em uma tradução para ser inserido em um outro sistema Y como uma outra representaçã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 (Gang of Four). Um adaptador que converte a interface de um componente para uma outra interface para que ele possa ser usado num contexto diferente (HOHPE; WOOLF, 2004). • Barramento de Controle (Control Bus): O Control Bus é um padrão muito importante dentro de uma solução de integração, pois o mesmo é responsável por prover uma administração de todo o fluxo em tempo de execução, conforme ilustrado na figura 2.4. Este padrão fornece um ponto único de controle para gerenciar e monitorar uma solução distribuída. Ele conecta vários componentes a uma central de gerenciamento que pode exibir o status de cada componente e monitorar o tráfego de mensagens (HOHPE; WOOLF, 2004). Esta central também pode ser utilizada para enviar comandos de controle para os componentes, por exemplo, para alterar o 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.

(20) CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA. 9. Figura 2.4: Padrão Control Bus. Fonte (HOHPE; WOOLF, 2004). evitar que os objetos se refiram uns aos outros explicitamente e permitir variar suas interações independentemente (GAMMA, 2007). Pela intenção podemos perceber que 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 - AVA. Ambientes Virtuais de Aprendizagem - AVAs são sistemas de aprendizagem desenvolvidos sobre uma metodologia pedagógica para auxiliar o professor na promoção do ensino na modalidade virtual ou semipresencial promovendo a interação entre o aluno e o professor no processo de ensino e aprendizagem de forma que os alunos adquiram os mesmos conhecimentos que seriam obtidos no ensino presencial (NETO; BRASILEIRO, 2002). Segundo Lopes (2001): "Os ambientes virtuais de ensino possibilitam uma ótima oportunidade para ampliação dos limites de uma sala de aula tradicional. No entanto, antes que se comece a planejá-lo é importante, em primeiro lugar, ocupar algum tempo, [...], para refletir por quais razões se está buscando construí-lo." Dentro da modalidade dos AVAs, temos o software chamado Moodle que é utilizado na SEDIS por se tratar de uma ferramenta bastante consagrada com uma das maiores bases de usuários do mundo, com mais de 25 mil instalações, mais de 360 mil cursos e mais de 4 milhões de alunos em 155 países, sendo que algumas universidades baseiam toda sua estratégia de educação a distância na plataforma Moodle. (SABBATINI, 2007). 2.4. Arquitetura de software. De 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 satisfazer objetivos e restrições.(PERRY; WOLF, 1992)"Ou seja, arquitetura são modelos e padrões que permitem documentar, facilitar o entendimento e direcionar as diversas dimensões da construção das aplicações, como exemplos, a localização e armazenamento dos dados,.

(21) CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA. 10. os mecanismos com que os usuários interagem com os sistemas e como os programas se conversam. Dessa forma, uma arquitetura de software, quando adequadamente documentada, facilita a compreensão da estrutura de um sistema, evitando a compreensão a partir do código fonte 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, decisões na construção do software que influenciam no sucesso de software. Assim, o desenvolvimento da arquitetura de um sistema afeta fatores como reuso, manutenibilidade, extensibilidade e escalabilidade (SOMMERVILLE, 2007).. 2.5. Arquitetura Orientada a Serviço - SOA. A 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 como finalidade a integração com outros sistemas, através de uma rede usando um protocolo predefinido. Esta arquitetura permite a transformação das funcionalidades das aplicações em serviços padronizados quem podem se inter-relacionarem (ERL, 2007). Essa arquitetura vem se destacando como uma das mais utilizadas e notáveis na área de integração de sistemas (LINTHICUM, 2003). Desse modo, cada aplicação que deseje envolver-se com essa arquitetura deve expor uma interface de serviço que dá acesso aos seus dados. Dessa maneira, a arquitetura transforma a aplicação em pedaços de softwares reutilizáveis, provendo assim a interoperabilidade entre diversas plataformas. De acordo com Coelho (COELHO et al., 2006) o serviço é um componente ou um elemento computacional independente de plataforma que possibilita o acesso e uso da função do negócio a qual ele representa pra outros serviços da mesma ou de outras aplicações. Para isso o serviço possui uma interface padronizada definem suas características e maneiras de acesso. Mackenzie (MACKENZIE et al., 2006) definem SOA como um paradigma para a orquestração de competências espalhadas em diversos domínios, que são utilizadas quando visíveis e atendem às necessidades de outrem em um processo denominado interação.. 2.5.1. Camadas de abstração SOA. Modelos 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 de necessidade. SOA traz um modelo baseado em cinco camadas abstração, a figura 2.5 demonstra 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 processos baseados em seu objetivo e mercado, os quais são essenciais para sua vantagem competitiva, e que, portanto devem ser controlados de perto..

(22) CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA. 11. 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ão identificados e caracterizados. Cada processo é único no atendimento de uma determinada área funcional (embora empresas que cresceram através de aquisição possam ter processos duplicados), e pode ser composto de diversos sub processos. A camada de processos é muito importante dentro da arquitetura SOA, porque muitos processos podem ser modelados e executados como serviços. Como se pode confundir os conceitos de serviço e de processo de negócio, considera-se que os processos são definidos uma única vez, e usados dentro de um contexto único, já os serviços podem ser reaproveitados em diversos contextos (diferentes processos de negócio, departamentos ou linhas de negócio). • Camada de serviços: A camada de serviços é caracterizada por um número de serviç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 de processos) e baixo nível (camada de componentes e objetos). Usualmente, é nesta camada que as funções críticas necessárias para o negócio são identificadas, visto que é nela que usualmente são identificadas e expostas as funções para suportar o negócio. • Camada de componentes: Mapeia os componentes que tem potencial para se transformarem em serviços, normalmente através de técnicas bottom-up (análise das 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 blocos de construção de serviços na arquitetura SOA e embora vários sejam construídos com 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 relacionamentos de um objeto. Na arquitetura SOA há um reaproveitamento dos conceitos de orientação a objeto, porem com o desacoplamento dos objetos, transformando em serviços reutilizáveis..

(23) CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA. 12. 2.6 Web service Correspondem 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 interoperabilidade entre máquinas sobre rede". Através dele, é possível o estabelecimento de comunicação entre duas aplicações por meio de troca de mensagens XML2 . Tal modelo tem se mostrado altamente viável para a extração e integração de dados, permitindo a interoperabilidade em grande escala (HANSEN; MADNICK; SIEGEL, 2003). Um Web Service é definido também como uma parte de uma funcionalidade localizado em algum sistema na rede, este fragmento pode ser uma associação ou composição de outros, formando processos de negócio autônomos e fracamente acoplados (CHAPPELL; JEWELL, 2002). Os Web Services são partes de um software que não dependem de plataforma e suas competências podem ser publicadas, descritas e invocadas via rede (FOOTEN; FAUST, 2012). Assim esta tecnologia pode ser acessada por diferentes sistemas através do uso de linguagens e protocolos pradronizados.. 2.7. Trabalhos relacionados. O trabalho de Martins (MARTINS, 2010) propôs uma integração em ambientes heterogêneos, por meio da especificação de uma arquitetura aberta baseada em middleware que prover o gerenciamento da informação no ambiente industrial integrado à gestão corporativa. O modelo proposto atua no monitoramento de rede e dos dispositivos da planta industrial, fornecendo parâmetros relacionados aos dispositivos de automação (CLP3 , RTU4 , switches5 industriais) e parâmetros de rede. O middleware integra informações oriundas de hardwares e integra as informações através de um middleware com o uso de computaçã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 de objetos remotos como se estes fossem objetos locais. Oliveira (OLIVEIRA, 2009) propõe a integração de ferramentas educacionais, foi desenvolvido a implementação de um ambiente orientado a serviços para expor funcionali1 W3C. - 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 governamentais e organizações independentes com a finalidade de estabelecer padrões para a criação e a interpretação de conteúdos para a Web. 2 XML, do inglês eXtensible Markup Language, é uma linguagem de marcação recomendada pela W3C para a criação de documentos com dados organizados hierarquicamente, tais como textos, banco de dados ou desenhos vetoriais. 3 Controlador Lógico Programável (CLP) ou do inglês PLC (Programmable Logic Controller) é um equipamento projetado para comandar e monitorar máquinas ou processos industriais. 4 Unidade Terminal Remota RTU ou do inglês Remote terminal unit, é um dispositivo baseado em microprocessador, que permite sinais independentes processos e enviar as informações para um local remoto onde é processado 5 switche é um equipamento que interliga os computadores em uma rede, os cabos de rede de cada computador se ligam a ele, que então direciona os dados enviados de um computador especificamente para outro.

(24) CAPÍTULO 2. FUNDAMENTAÇÃO TEÓRICA. 13. dades de um repositório de conteúdos pedagógicos digitais da Rede Federal de Educação Profissional e Tecnológica conhecido como InterRed6 . O modelo desenvolvido comunicase com o Moodle através de um conjunto de clientes que consomem os recursos. Neste trabalho Oliveira fez um grande levantamento sobre os modelos de arquitetura orientada a serviço e suas especificidades. O trabalho de Zheng (ZHENG BO DONG, 2008) propôs um modelo de integração orientada a serviços para sistemas com foco em EaD. Segundo Zheng, atualmente os softwares educacionais são desenvolvidas de forma isolada e com baixa capacidade de integração com outros sistemas e baseado nisso ele propõe um modelo de integração em uma ferramenta chamada SOELS. No desenvolvimento de seu trabalho, Zheng usou um modelo baseado em Web Service dividido em camadas e utiliza um tipo de Enterprise Service Bus (ESB). A aplicação SOELS encapsula as funcionalidades sob a forma de Web Services e implementa os processos de negócios através da comunicação e colaboração entre os serviços. De acordo com os trabalhos apresentados anteriormente pode-se observar que todas tecnologias apresentadas oferecem uma forma diferente de integração de acordo com seus níveis e complexidades mas nota-se uma grande tendência em desenvolver estratégias que 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, nem sempre os sistemas a ser integrado foram construídos tendo a orientação a serviços como paradigma. Aliado ao uso de SOA percebe-se também o desenvolvimento de um software mediador (middleware) no processo de integração entre os sistemas e a utilização. A fim de solucionar a integração de sistemas de help desk e issue tracking, percebe-se que o uso de Web service diante da arquitetura orientada a serviços atende as necessidades do contexto deste trabalho, pois essa tecnologia propicia interoperabilidade entre as várias aplicações, plataforma e frameworks de uma maneira que se mantém consistente com a arquitetura web. Esta abordagem, baseada em Web service, permite a exposição de funcionalidades, o que garante um bom nível de abstração entre as aplicações envolvidas com um nível de acoplamento considerado baixo.. 6 InterRed. é um repositório de recursos digitais que foi desenvolvido por uma rede de 10 instituições federais de ensino tecnológico e que tem por objetivo ser uma ferramenta de gestão e organização da base de conteúdos educacionais.

(25) Capítulo 3 Sistemas Legados da SEDIS. Este capítulo apresenta uma visão geral dos sistemas legados da SEDIS que fazem parte do alvo da integração deste trabalho, é apresentado também a relação que eles têm entre si e a importância de cada um. Este trabalho realiza a integração entre dois sistemas legados (SEDIS Solicitação e Redmine) e um novo módulo de Solicitações externas incorporado pelo Moodle. Estes sistemas são utilizados na SEDIS e possuem uma relação direta entre o atendimento ao usuário final, gestão da equipe e qualidade de serviço oferecido. O SEDIS Solicitação é um sistema de protocolo de atendimento ao usuário dos serviços prestados pela TI-SEDIS, o Redmine trata-se de um sistema de gerenciamento de projetos/equipe e o Moodle é um ambiente virtual de aprendizagem - AVA que precisa disponibilizar um meio de comunicação via sistema entre o setor de suporte com o usuário final, nas próximas seções iremos detalhar cada sistema. Quando referenciamos os sistemas deste estudo como sistemas legados, não estamos querendo 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 certo tempo e que exercem papéis importantíssimos na instituição, mas que atualmente estão isolados um do outro. Esse trabalho apresenta um estudo de caso que motiva a integração de tais sistemas.. 3.1. SEDIS Solicitação. O SEDIS Solicitações 1 surgiu da necessidade de ter uma ferramenta de gerenciamento de chamados técnicos do setor de Tecnologia da Informação da SEDIS, este software foi desenvolvido na SEDIS pelo setor de desenvolvimento da TI. Suas principais funcionalidades 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 finalidade prestar apoio técnico as pessoas que utilizam os serviços que a TI oferece, inclusive usuários dos AVAs, e desta maneira este sistema atua prestando apoio a educação a distância da UFRN conforme a figura 3.1. 1 SEDIS. Solicitação - http://www.solicitacao.sedis.ufrn.br/.

(26) 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 capacidade de comunicar-se com outros sistemas pois foi originalmente projetado para trabalhar de forma isolada e independente dificultando a comunicação com outros sistemas. Ao desenvolver um sistema de informação, questões de interoperabilidade devem ser pensadas antes de sua implementação na fase de planejamento o que na maioria das vezes não acontecem por falta de planejamento, falta de tempo e outros fatores o que dificulta a sua integração. Partindo desta realidade, é proposto neste trabalho ser desenvolvido uma camada mediadora de serviços (web service) para que o SEDIS Solicitação possa integrar-se através de serviços web com o INTEGRA. Atores O Setor de TI possui três divisões: Desenvolvimento, Suporte Técnico e Coordenação de TI. Dentro dessas subdivisões o SEDIS Solicitações terá forte atuação no setor de suporte técnico pois é lá onde o atendimento ao usuário se inicia, tendo isto em mente veremos 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 os alunos, professores, tutores, funcionários de outros setores da SEDIS. 2. Gestor do suporte de TI: Atua na coordenação do atendimento ao usuário articulandose com a equipe técnica filtrando, acompanhando e delegando os chamados..

(27) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 16. 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 procedimentos necessários para resolução das solicitações. 4. Administrador: Este usuário possui acesso a todas às configurações do sistema para executar e controlar as atividades rotineiras e necessárias para o funcionamento da ferramenta. Além desses atores citados, é possível também criar novos atores e definir novas responsabilidades 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 funcionalidades do 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 funcionais os 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 algum tipo de serviço da TI. Este serviço pode ser algum problema no ambiente virtual.

(28) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 17. de aprendizagem, algum problema de infraestrutura da SEDIS ou até mesmo uma dúvida de algum procedimento do Moodle. • Acompanhar Solicitação: Permitir ao usuário acompanhar a resolução de seu problema visualizando as etapas (aberta, em andamento ou finalizada) necessárias para a resolução. • Avaliar Atendimento: Permite que os usuários avaliem os serviços prestados pela equipe de TI através do preenchimento de um breve formulário de perguntas no final do atendimento da solicitação. • Delegar Solicitação: Permite que o coordenador abra uma solicitação e após analisala, delegue a solicitação para algum integrante da equipe para este membro possa iniciar os trabalhos em busca de solucionar a tarefa. • Finalizar Solicitação: Permitir ao usuário (Equipe Técnica) após a resolução da solicitação encerre a solicitação finalizando o atendimento. • Visualizar Solicitação: Permite que os usuários (Gestor do suporte de TI, administrador e Equipe Técnica) visualize as solicitações que estão sob suas responsabilidades 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 intuito 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 que está atendendo a solicitação, o sistema deve permitir mecanismos para adicionar informações pertinentes a solicitação. • Manter cadastros administrativos: Permite que o usuário (administrador) possa adicionar, alterar e remover todos os registros administrativos necessários para o funcionamento do sistema. • Gerar relatórios estatísticos: Permite que o usuário (administrador) possa gerar relatórios com dados estatísticos sobre os atendimentos das solicitações que irão auxiliar 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 identificado o padrão arquitetônico utilizado neste sistema, esta análise foi elaborada com o intuito de detectar os componentes chaves que podem ser utilizados/modificados para interagir com o INTEGRA. Primeiramente, foi realizado um estudo na maneira que o sistema foi desenvolvido a partir da análise da código, na organização dos elementos arquiteturais e dialogando com os programadores que trabalharam no desenvolvimento deste.

(29) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 18. 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 deste modelo 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, é responsável por manter os arquivos PHP que irá definir toda a interface que exibirá as informações para os usuários. View: Arquivos de classes PHP’s genéricos que são utilizados para um pré-processamento da 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 que sã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 possuem elementos muito similares e diante disso utilizou-se alguns arquivos PHP de forma 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 para o 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 com o banco de dados para armazenar as informações recebidas das classes controller’s ou recuperar informações solicitadas pelos usuários para serem visualizadas nas interfaces.. 3.2. Redmine. O Redmine é um software de gerenciamento de projetos desenvolvido na linguagem Ruby on Rails, classificado como software livre distribuído sobre a licença GNU General Public License V2 (GPL) que tem atendido muitos projetos que precisam controlar tarefas, atividades, recursos humanos, andamento das tarefas e a evolução dos artefatos de software..

(30) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 19. Este sistema gerência a equipe de desenvolvimento da TI-SEDIS na resolução das demandas de trabalho que se dividem em demandas de suporte (oriundas do SEDIS Solicitação) ou demandas de novos projetos. De acordo com a figura 3.2, pode-se ver que semelhante ao SEDIS Solicitação, este sistema 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ão voltadas para garantir que todos funcionalidades do AVA estejam em pleno funcionamento.. 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, o Redmine expõe alguns de seus dados por meio de uma API de Web services. Esta API fornece 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 suporta tanto 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: Desenvolvimento, Suporte Técnico e Coordenação de TI. Este sistema vai atuar fortemente na equipe de desenvolvimento atuando na gestão e planejamento das atividades executadas pelos desenvolvedores. Neste cenário, o Redmine possui por padrão alguns perfis de usuá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ões podem variar de acordo com a necessidade de cada usuário. Vejamos logo abaixo os atores 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 da ferramenta..

(31) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. Figura 3.6: Atores do Sistema Redmine. Figura 3.7: Permissões do usuário gerente. 20.

(32) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 21. A figura 3.8 também foi captada da configuração do Redmine mas esta é referente ao perfil do Desenvolvedor, perceba que este perfil possui uma gama de permissões voltadas mais 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 ao perfil do Informante, percebe-se que este perfil possui um nível de permissões bem restrito 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 ao perfil do usuário não membro. Geralmente este usuário , mas não pertence ao projeto podendo apenas visualizar alguns itens como a wiki, fórum, notícias, Gantt entre outros..

(33) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 22. 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 ao perfil 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 levantamento das principais requisitos funcionais da ferramenta: 1. Permitir o cadastro de atividades e tarefas com os esforços necessários e estimativas de tempo e recursos previsto no projeto. 2. Permitir várias versões de um cronograma possibilitando a gravação das versões antecedentes. 3. Permitir cálculo do esforço total previsto e do total realizado em um determinado período de tempo. 4. Informar ou destacar as atividades que estão programadas para serem feitas na semana 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 base na alocação dos recursos em todos os projetos..

(34) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 23. 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. Padrão arquitetural Por se tratar de uma ferramenta open source, foram feitas diversas pesquisas em sua documentação oficial sobre o seu padrão arquitetural mas nada foi encontrado, desta maneira foi elaborado um estudo a nível de código fonte investigando a organização dos principais elementos impactantes da arquitetura. Neste estudo, foi concluído que o padrão arquitetural que consta no Redmine é o padrão Model View Controller - MVC, este padrão divide a aplicação em três componentes Model, View e Controller. Todas as requisições da aplicação são direcionadas para o componente 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 - MSE. O Moodle (Modular Object Oriented Dynamic Learning Environment) é um software livre distribuído pela GNU, foi desenvolvido para a gestão do ensino-aprendizagem tendo como metodologia pedagógica o sócio construtivismo, no qual os participantes constroem conhecimentos colaborativamente interagindo com o ambiente, criado no ano de 1999 por Martin Dougiamas e desde então vem sendo desenvolvido colaborativamente pela comunidade 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 altamente portá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 dados como MySQL, PostgreSQL, Oracle entre outros. (FILHO, 2004). Concebido em uma 2 Gráfico 3 Wiki. de Gantt é um gráfico usado para ilustrar o avanço das diferentes etapas de um projeto é utilizado para identificar qualquer coleção de documentos, uma enciclopédia online..

(35) CAPÍTULO 3. SISTEMAS LEGADOS DA SEDIS. 24. arquitetura baseada em componentes que vem facilitando o seu aprimoramento contínuo possibilitando incorporar módulos com novas funcionalidades, o que favorece a fácil adaptaçã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 com maiores ou menores atribuições, ou seja, são diferentes níveis que possibilitam um usuário ter mais áreas acessíveis do que outro. por Padrão temos os seguintes atores que operam o sistema: Visitante, aluno, tutor, autor de curso, administrador representados pela figura 3.12.. Figura 3.12: Atores do Moodle.. 1. Visitante: Têm a possibilidade de apenas visualizar o curso e seu conteúdo, ele não pode participar das atividades, se comportando apenas como um observador. 2. Aluno: É quem faz o curso, ele é quem recebe o conteúdo do professor, interage com 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 professores 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, ele quem molda o ambiente, tem atribuições de criar atividades, recursos, inserir alunos no curso que já estejam cadastrados no Moodle, configurar notas e o formato de curso que ele pretende que tenha seu curso. 5. Autor de curso: Tem as mesmas funções do professor, ele quem cria o curso por isso o nome diferente. Em um curso a distância é importante os alunos saberem com quem estão lidando, por isso o status, possibilitando que ele saiba quem é professor e quem é aluno. 6. Administrador: Quem tem as atribuições máximas no Moodle, ele pode configurar todo o ambiente, tanto a página inicial e as categorias de curso quanto os próprios cursos, ele tem possibilidade também de entrar como professores, alunos, o que é muito utilizado para testes. Geralmente sobre ele que cai a responsabilidade dos problemas que o ambiente venha a ter, ele quem tem atribuição de instalar o Moodle, quem tem acesso a senhas de FTP, de banco de dados, e quem pode baixar plugins, temas. Ele tem acesso a todas as áreas do ambiente, pode excluir e inserir usuários e dar suas atribuições, pode alterar materiais e organizar o ambiente. 4 <http://docs.moodle.org/29/en/main_page>.