INTEGRAÇÃO SEMÂNTICA DE APLICAÇÕES DE APOIO À GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA LAYLLA DUARTE DE CERQUEIRA INTEGRAÇÃO SEMÂNTICA DE APLICAÇÕES DE APOIO À GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE VITÓRIA 2014

2 LAYLLA DUARTE DE CERQUEIRA INTEGRAÇÃO SEMÂNTICA DE APLICAÇÕES DE APOIO À GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE Monografia apresentada à Universidade Federal do Espírito Santo como requisito parcial para obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Ricardo de Almeida Falbo VITÓRIA 2014

3 LAYLLA DUARTE DE CERQUEIRA INTEGRAÇÃO SEMÂNTICA DE APLICAÇÕES DE APOIO À GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE COMISSÃO EXAMINADORA Prof. Dr. Ricardo de Almeida Falbo Departamento de Informática UFES Orientador Profª. Drª. Monalessa Perini Barcellos Prof. Msc. Julio Cesar Nardi Vitória, 13 de março de 2014.

4 Agradeço primeiramente a Deus por ter me guiado e sustentado durante toda a minha caminhada. À minha família, por toda a orientação, apoio e educação. Ao meu namorado pela paciência e amor. Ao professor Falbo pela excelente orientação, por sempre estar disposto a me ajudar. Aos meus amigos do NEMO que me ajudaram. À turma CComp2009, a qual tive a honra de fazer parte e desfrutar de grandes amizades. Ao meu amigo Filipe com quem tive o prazer de desenvolver parte da monografia. Ao meu amigo Thiago, que muito ajudou com a parte de serviços do ODE. Enfim, agradeço a todos que foram presentes nesses cinco anos de muitas lutas e vitórias.

5 RESUMO A Gerência de Configuração de Software é um processo complexo, envolvendo várias atividades e uma grande quantidade de informações a serem controladas. Para apoiar esse processo, normalmente as organizações fazem uso de diferentes ferramentas, dentre elas sistemas de controle de versão, sistemas de controles de alterações, sistemas de trilhas de problemas (issue (ou bug) trackers), dentre outras. Contudo, essas ferramentas padecem do mal da heterogeneidade, o que dificulta a integração das mesmas. Este trabalho apresenta uma iniciativa de integração semântica do sistema de trilhas de problemas (issue tracker) MantisBT à ferramenta de apoio ao controle de versões SVN-ODE do ambiente de desenvolvimento de software ODE (Ontology-based software Development Environment), considerando o domínio de Gerência de Configuração de Software no que se refere às atividades de identificação de Configuração, controle de versão e controle de alteração. Essa atividade foi realizada utilizando o método OBA-SI (Ontology-Based Approach for Semantic Integration), uma abordagem baseada em ontologias para integração semântica de aplicações. Tal abordagem promove acordo semântico entre os sistemas no nível conceitual. Neste trabalho, OBA-SI é aplicada considerando apenas a camada de dados. Palavras-chave: Gerência de Configuração de Software, Integração Semântica de Sistemas, Gerência de Questões, Interoperabilidade Semântica

6 ABSTRACT Software Configuration Management is a complex process involving several activities and a large amount of information to be controlled. To support this process, organizations often use different tools, such as version control systems, change control systems and issue (or bug) tracker systems. However, these tools suffer from the heterogeneity problem, which hampers their integration. This work presents a semantic integration initiative of the issue tracker system MantisBT to the version control tool SVN-ODE of the software development environment ODE (Ontology-based Software Development Environment). This initiative considers the Software Configuration Management domain, more especially the change control activities. This initiative was conducted following OBA-SI, an Ontology-Based Approach for Semantic Integration, promoting semantic agreement between the systems at the conceptual level. In this work OBA-SI is partially applied, considering only the data layer. Keywords: Software Configuration Management, Semantic Integration, Issue Management, Semantic Interoperability

7 LISTA DE FIGURAS Figura 1 - Diagrama OntoUML da Ontologia do Domínio da Gerência de Questões Figura 2 - Processo de Integração Semântica (CALHAU, 2011)...20 Figura 3 - Atividades da Fase de Análise de Integração (CALHAU, 2011)...21 Figura 4 - Diagrama OntoUML do fragmento alterado na Ontologia de Controle de Questões de Alteração de Software...26 Figura 5 - Diagrama de Classes de SVN-ODE referente ao controle de Alteração...27 Figura 6 - Diagrama de Classes de MantisBT...29 Figura 7 - Diagrama de Classes do Modelo de Integração...37 Figura 8 - Mediador: responsável pela comunicação entre SVN-ODE e MantisBT...39 Figura 9 - Arquitetura de software do mediador...41 Figura 10 - Descrição de uma questão na ferramenta MantisBT...42 Figura 11 - Janela do SVN-ODE de realização de um Checkout no ODE...42

8 LISTA DE TABELAS Tabela 1 - Cenário de Integração...25 Tabela 2 - Mapeamentos Verticais de Conceitos...30 Tabela 3 - Mapeamentos Verticais de Relacionamentos de MantisBT...31 Tabela 4 - Mapeamentos Verticais de Conceitos...32 Tabela 5 - Mapeamentos Verticais de Relacionamentos de MantisBT...35 Tabela 6 - Mapeamentos Verticais de Relacionamentos de SVN-ODE...36 Tabela 7 - Mapeamentos Horizontais entre Conceitos...38 Tabela 8 - Mapeamentos Horizontais de Relacionamentos de SVN-ODE...38

9 SUMÁRIO 1 INTRODUÇÃO Objetivos Histórico do Trabalho Organização do Texto GERÊNCIA DE QUESTÕES, GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE E INTEGRAÇÃO DE SISTEMAS Gerência de Questões Gerência de Configuração de Software(GCS) Integração Semântica de Sistemas OBA-SI: Ontology-Based Approach for Semantic Integration INTEGRAÇÃO SEMÂNTICA DE SISTEMAS DE APOIO À GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE Cenário de Integração Modelos Conceituais Relacionados ao Cenário de Integração Ontologia Issue Management Modelo Conceitual Estrutural de SVN-ODE Modelo Conceitual do MantisBT Mapeamentos Verticais Modelo de Integração Mapeamentos Horizontais Projeto e Implementação da Integração CONSIDERAÇÕES FINAIS Conclusões Limitações e Perspectivas Futuras Experiência Pessoal...44 REFERÊNCIAS BIBLIOGRÁFICAS...47

10 9 1 INTRODUÇÃO A integração de aplicações de software é atualmente um dos principais problemas para as organizações, pois cada vez mais é necessário que essas aplicações trabalhem em conjunto para apoiar processos de negócio complexos envolvendo diferentes áreas de negócio. A maior parte das aplicações utilizadas é geralmente desenvolvida por grupos distintos que, muitas vezes, não possuem uma preocupação com a integração. Como resultado, essas aplicações, em sua grande parte, são heterogêneas, autônomas e distribuídas (IZZA, 2009). Dentre os problemas de integração, a heterogeneidade tem sido considerada um dos mais desafiadores. Neste contexto, a semântica é muito importante. A interoperabilidade semântica, ou seja, baseada em significado, é mais fidedigna do que a interoperabilidade sintática que, ao contrário, é baseada apenas no processamento de cadeias de caracteres e casamento de esquemas (MUTHAIYAH; KERSCHBERG, 2008). Para lidar com a questão da integração semântica, ontologias podem ser utilizadas para estabelecer um entendimento comum sobre o universo de discurso de interesse, servindo como uma interlíngua para a comunicação entre as aplicações. Diversas áreas de aplicação podem se beneficiar das técnicas de interoperabilidade semântica, dentre elas a Gerência de Configuração de Software (GCS). O processo de GCS é um processo complexo que envolve diversas atividades, as quais podem ser agrupadas em três subprocessos principais, a saber (ISO 10007, 2003): Planejamento e Identificação de Configuração: identifica itens do produto a serem controlados, estabelece critérios de seleção de Itens de Configuração (ICs) e suas versões, e estabelece padrões de numeração, ferramentas e técnicas a serem usadas para controlar os itens. Controle de Versão: combina procedimentos e ferramentas para gerenciar as diferentes versões de um IC criadas durante seu desenvolvimento. Controle de Alteração: atua na gerência de alterações realizadas durante o ciclo de vida do produto e envolve: (i) solicitação de alterações, (ii) avaliação de alterações; (iii) checkout, (iv) realização de alteração, (v) revisão de alteração e (vi) checkin dos itens modificados. Para apoiar esse processo, várias ferramentas ferramentas podem ser usadas, tais como sistemas de controle de versão, sistemas de controle de alterações e sistemas de trilha de problemas (issue (ou bug) trackers). Entretanto, utilizar ferramentas isoladas

11 10 pode levar a inconsistências e retrabalho. SVN-ODE é uma ferramenta do ambiente de desenvolvimento de software ODE (Ontology-based Development Environment) (FALBO; RUY; MORO, 2005) e oferece funcionalidades de apoio à identificação de itens de configuração, controle de versões e controle de funções como checkout e checkin. Mantis Bug Tracker (MantisBT), por sua vez, é um sistema de apoio à Gerência de Questões (Issues), que possui um conjunto de funcionalidades e características que atendem a diversas necessidades do controle de questões, desde o momento que foi reportada uma questão até a finalização da mesma. Além disso, permite a customização de atividades e campos do sistema. Essas ferramentas, usadas de modo isolado, não conseguem oferecer uma solução completa para todo o processo de controle de alterações, uma vez que não apoiam todas as atividades realizadas no contexto deste processo, tornando a integração delas uma solução promissora. Elas, porém, foram construídas isoladamente, em diferentes contextos, e assim, não compartilham modelos de dados e de processos comuns. Existe uma heterogeneidade, que pode ocasionar conflitos semânticos. Neste contexto, a adoção de uma abordagem que ajude a diminuir a complexidade dessa tarefa é importante. Em (CALHAU, 2011) foi desenvolvida OBA-SI (Ontology-Based Approach for Semantic Integration), uma abordagem de integração semântica de sistemas que concentra esforços na modelagem conceitual e na análise dos requisitos de integração. Nessa abordagem, a integração semântica é realizada em um alto nível de abstração, promovendo acordo semântico entre os sistemas no nível conceitual. Para isso, ontologias são usadas para atribuir semântica aos itens compartilhados entre os sistemas, propondo um processo de integração independente de tecnologia e que abrange três camadas de integração: dados, serviços e processo. 1.1 Objetivos O objetivo geral deste trabalho é integrar semanticamente o sistema de trilha de problemas (issue tracker) MantisBT ao ambiente de desenvolvimento do software ODE. Para tal, será utilizada OBA-SI. Vale ressaltar que, apesar de OBA-SI tratar das camadas de dados, serviços e processos, neste trabalho, ela será utilizada apenas na integração da camada de dados.

12 11 Nesse contexto, são objetivos específicos deste trabalho: integrar os modelos conceituais de dados da ferramenta SVN-ODE (relativo ao controle de alteração) e do MantisBT. desenvolver uma aplicação mediadora, integrando MantisBT ao SVN-ODE para prover apoio ao controle de questões de alteração e utilizar a camada de serviços para provê funcionalidades, tanto do ODE para o MantisBT como o inverso; aplicar o método OBA-SI nessa iniciativa de integração e, nesse sentido, obter um feedback desse uso, de maneira a contribuir para melhorias dessa abordagem. 1.2 Histórico do Trabalho O trabalho foi iniciado com uma revisão da literatura sobre Gerência de Configuração de Software, ferramentas CASE, ambientes de desenvolvimento de software e integração semântica. Ainda como parte dessa etapa, foi feito um estudo sobre o ambiente ODE e as ferramentas de apoio à GCS existentes no mesmo. Com as atividades de estudo e investigação científica foi possível compreender a necessidade que se tem em integrar sistemas de software e os problemas que ocorrem ao tentar realizar esse trabalho. Com isso se verificou a importância do uso de ontologias para melhorar a qualidade da integração. Uma ferramenta que foi estudada e que ajudou na compreensão na área de GCS foi a GCS-ODE (CALHAU, 2009). Essa ferramenta possui funcionalidades de apoio ao planejamento e identificação de configuração, tendo sido desenvolvida na plataforma desktop. Por isso, ela foi usada como base para o desenvolvimento da ferramenta para a plataforma Web. Com o estudo da literatura na área de Gerência de Configuração de que existem ferramentas que proveem funcionalidades isoladas para essa área e que são bastante usadas, optou-se por implementar uma ferramenta utilizando o que já foi desenvolvido, antes isolado, e agora incorporado no ODE. Assim, esta etapa envolveu a realização da especificação de requisitos, os quais foram aperfeiçoados em relação à versão original de GCS-ODE, segundo o paradigma da orientação a objetos, usando a linguagem de modelagem unificada (UML) e a linguagem de programação Java em ambiente Web. A partir da compreensão da área de Gerência de Configuração e de que ela pode ser dividida em três subprocessos (Planejamento e Identificação de Configuração,

13 12 Controle de Versão e Controle de Alteração), decidiu-se construir três aplicações integradas, uma para cada subprocesso. Essa integração teve início durante um projeto de iniciação científica, onde desenvolveu-se a parte de planejamento e identificação de configuração, aplicação desenvolvida no ODE, a partir de GCS-ODE, e do controle de versão, tratada pela ferramenta Subversion. Após esse período, iniciou-se um estudo para o desenvolvimento de uma aplicação para apoiar o controle de alteração, no qual foi utilizada a ferramenta Mantis Bug Tracker (MantisBT). Diferente da integração com o Subversion, que foi facilitada com a utilização da biblioteca svnkit (SVNKIT, 2013), para prover a comunicação com o MantisBT, que foi desenvolvido em PHP, foi necessário o uso de uma camada de serviços no ODE. Além disso, como parte do processo é feito no MantisBT, foi feito um estudo dessa ferramenta e como o ODE seria avisado das modificações ocorridas nela. Para isso, parte do mediador que realiza a integração da ferramenta ao ODE foi desenvolvida como um plugin no MantisBT, com o objetivo de enviar, por meio de serviços disponíveis no ODE, as alterações realizadas no MantisBT. Por fim, trabalhou-se o cenário de integração dessas ferramentas para apoiar o processo de GCS. Para tal, foi usada parcialmente a abordagem de integração semântica OBA-SI (Ontology-Based Approach for Semantic Integration), proposta em (CALHAU, 2011). A parte de OBA-SI adotada foi aquela relativa à integração de dados e consistiu no levantamento de requisito da integração, mapeamentos verticais, construção do modelo de integração, mapeamentos horizontais, projeto, implementação e testes.

14 Organização do Texto Esta monografia é estruturada em quatro capítulos e contém, além da presente introdução, os seguintes capítulos: Capítulo 2 Gerência de Questões, Gerência de Configuração de Software e Integração Semântica de Aplicações: apresenta uma revisão da literatura acerca de temas relevantes ao contexto deste trabalho, a saber: Gerência de Questões, Gerência de Configuração de Software e Integração de Sistemas. Capítulo 3 Integração Semântica de Sistemas de Apoio à Gerência de Configuração de Software: apresenta a integração semântica do MantisBT com o SVN-ODE, utilizando OBA-SI. Capítulo 4 Considerações Finais: apresenta as conclusões do trabalho, dificuldades envolvidas, limitações e propostas de trabalhos futuros.

15 14 2 GERÊNCIA DE QUESTÕES, GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE E INTEGRAÇÃO DE SISTEMAS Este capítulo aborda, brevemente, temas relevantes ao contexto deste trabalho, a saber: Gerência de Questões, Gerência de Configuração de Software e Integração Semântica de Aplicações. 2.1 Gerência de Questões Gerenciamento de questão (Issue Management) é o processo de identificar e resolver questões. Problemas com funcionários ou fornecedores, falhas técnicas, falta de material, ou seja, tudo que pode gerar impacto negativo em um projeto. Se uma questão não é resolvida, corre-se o risco de criar conflitos desnecessários, atrasos ou até mesmo fracasso em produzir o produto final (MINDTOOlS, 2014). Com o intuito de explicitar esse processo, a seguir é apresentada uma ontologia de referência do domínio da Gerência de Questões. A Figura 1 mostra o modelo conceitual desta ontologia, o qual está escrito em OntoUML.

16 Figura 1 - Diagrama OntoUML da Ontologia do Domínio da Gerência de Questões. 15

17 Como mostra a Figura 1, uma questão (Issue) é produzida no contexto de um Projeto (Project). Uma pessoa desempenhando o papel de relator da questão (Issue Originator) realiza uma comunicação da questão (Issue Communication), dando origem a uma questão no estado comunicada (Communicated Issue). Uma vez comunicada uma questão, um gerente (Manager) deve atribuir um avaliador (Issue Appraiser) para analisar a pertinência da questão (Issue Assignment to Evaluation). A questão passa, então, para o estado atribuída para avaliação (Issue Assigned to Evaluation). Quando o avaliador (Issue Appraiser) realiza a avaliação da questão (Issue Evaluation), o estado da questão é alterado para avaliada (Evaluated Issue). Se a questão for considerada pertinente, o gerente de projeto (Manager) pode designar um desenvolvedor (Developer) para resolvê-la (Issue Assignment to Resolution), levando a questão para o estado atribuída para resolução (Issue Assigned to Resolution). O desenvolvedor (Developer) pode, então, tratar a questão (Issue Resolution), o que leva a questão para o estado tratada (Treated Issue). Neste momento, o gerente (Manager) deve designar um revisor (Reviewer) para avaliar se a questão foi resolvida satisfatoriamente ou não (Issue Assignment to Review), alterando o estado da questão para atribuída para revisão (Issue Assigned to Review). Quando o revisor (Reviewer) realiza a revisão da questão (Issue Review), o estado da mesma é alterado para revisada (Reviewed Issue). Se o resultado da revisão considerar a questão resolvida, o gerente (Manager) pode, então, fazer o encerramento da questão (Issue Closing), quando a questão é finalizada e seu estado é alterado para encerrada (Closed Issue).

18 2.2 Gerência de Configuração de Software(GCS) Gerência de Configuração de Software é um processo de suporte ao ciclo de vida do software que beneficia a gerência do projeto, desenvolvimento e atividades de manutenção, atividades de garantia de software, assim como os clientes e usuários do produto final (ABRAN; MOORE, 2011). Ela aplica técnicas e procedimentos administrativos para: (i) identificar e documentar características físicas e funcionais de itens de configuração (ICs); (ii) controlar alterações nessas características; (iii) armazenar e reportar as modificações realizadas e; (iv) verificar a compatibilidade de modificações realizadas com o requisitos especificados (IEEE, 2004). Esse gerência pode ser tratada sob diferentes perspectivas, em função do papel exercido pelo participante do processo de desenvolvimento de software. Tomando por base principalmente (ISO 10007, 2003), (MIL-HDBK-61A, 1997) e (ESTUBLIER, 2000), as principais atividades do processo de GCS podem ser resumidas da seguinte forma: Identificação de Configuração: identifica itens do produto a serem controlados, estabelece critérios de seleção de ICs e suas versões, e estabelece padrões de numeração, ferramentas e técnicas a serem usadas para controlar os itens; Controle de Versão: combina procedimentos e ferramentas para gerenciar as diferentes versões de um IC criadas durante seu desenvolvimento; Controle de Alteração: atua na gerência de alterações realizadas durante o ciclo de vida do produto e envolve: (i) solicitação de alterações, (ii) avaliação de alterações; (iii) checkout, (iv) realização de alteração, (v) revisão de alteração e (vi) checkin dos itens modificados. Além dessas atividades, a gerência de configuração possui atividades que envolvem o planejamento da GC, auditorias de configuração e também o relato do status da configuração.

19 2.3 Integração Semântica de Sistemas Para serem competitivas e encararem as mudanças nas condições econômicas, as empresas precisam ser flexíveis e dinâmicas, o que requer o uso de sistemas de informação que possam trabalhar juntos, apoiando os processos de negócio (VERNADAT, 2007). Diversas soluções para integração de sistemas estão sendo providas focando em aplicações heterogêneas, autônomas e distribuídas (HAD). Para se integrar sistemas autônomos, são necessárias soluções que lidem com comportamentos assíncronos, tais como middlewares assíncronos. Na integração de sistemas distribuídos, a maior dificuldade diz respeito ao controle de transações, com soluções sendo dadas principalmente pela computação distribuída. Com relação à heterogeneidade, esta é considerada o maior problema na hora de se integrar sistemas corporativos. Para solucionar essa questão devem ser providos meios para resolver conflitos sintáticos e semânticos (IZZA, 2009). Os níveis nos quais pode ocorrer a integração de sistemas vão desde os mais baixos e operacionais, como de hardware e de plataforma, até os níveis mais altos de integração, relacionados a aspectos linguísticos, como os níveis sintático, semântico e pragmático (CALHAU, 2011). Os níveis mais baixos estão relacionados com aspectos tecnológicos, enquanto níveis mais altos estão relacionados com aspectos estruturais, semânticos e comportamentais da integração (IZZA, 2009). No nível semântico, durante o processo de integração, é importante que seja explicitado de forma clara o significado dos componentes envolvidos. Sendo assim, uma ontologia de domínio pode ser usada como referência. Dentre as diversas abordagens de integração de sistemas que consideram a semântica para integrar sistemas, há a abordagem OBA-SI proposta em (CALHAU, 2011). Essa abordagem trata o problema de integração em três camadas: dados, serviços e processos. A camada de dados lida com a troca de dados entre diferentes repositórios. Neste ponto, uma aplicação manipula os dados de outra aplicação diretamente no banco de dados, através de sua interface nativa, ignorando a lógica da aplicação. A integração na camada de mensagens ou serviços ocorre quando duas ou mais aplicações trocam mensagens entre si. Por fim, a u ltima camada, a camada de processo, trata uma organização como uma série de processos relacionados e os sistemas responsáveis pela execução desses processos não podem ser vistos como ilhas de informações. Dessa forma a integração nessa

20 camada é responsável por tratar o fluxo de mensagens, regras de execução e definir o processo de execução global (IZZA, 2009) OBA-SI: Ontology-Based Approach for Semantic Integration A Abordagem baseada em Ontologias para a Integração Semântica (Ontology- Based Approach for Semantic Integration OBA-SI) (CALHAU, 2011) considera o processo de integração como um tipo de processo de desenvolvimento de software, composto de fases de levantamento de requisitos, análise, projeto, implementação, testes e implantação. Essa abordagem se concentra na fase de análise de integração, na qual a semântica deve ser definida. Para OBA-SI, é importante que se tenha concordância semântica antes do projeto e implementação de qualquer solução, de modo que a integração no nível conceitual seja independente de tecnologia e de uma solução de integração específica. Para isso, modelos conceituais dos sistemas são comparados à luz de ontologias, usadas para atribuir semântica aos itens compartilhados entre os sistemas. Uma relação entre cada modelo é obtida por meio de mapeamentos entre seus elementos. O processo de OBAS-SI é apresentado na Figura 2. Figura 2 - Processo de Integração Semântica (CALHAU, 2011)

21 O processo de integração de OBA-SI inicia-se com a etapa de levantamento de requisitos da integração, quando os requisitos e objetivos devem ser estabelecidos. Nessa etapa também é necessário indicar as atividades do processo de negócio que serão apoiadas, os sistemas a serem integrados para apoiá-las, os domínios envolvidos no cenário de integração e as tarefas genéricas relacionadas à integração. Com isso, define-se o cenário de integração. Em seguida, é realizada a etapa de análise da integração, que é responsável por analisar e modelar os requisitos da integração, especificar as funcionalidades que serão providas e os conceitos envolvidos, bem como estabelecer como será o comportamento geral do conjunto integrado de sistemas. Seu principal produto é o modelo da integração (CALHAU,2011). Esse modelo é utilizado para estabelecer as equivalências semânticas entre os sistemas. A Figura 3 apresenta as atividades envolvidas nessa etapa. Figura 3 - Atividades da Fase de Análise de Integração (CALHAU, 2011) Essa fase se inicia com a obtenção dos modelos conceituais estruturais e comportamentais dos sistemas listados no cenário de integração. Seleciona-se uma ontologia de referência sobre o domínio do cenário de integração que, caso não esteja disponível, deve ser desenvolvida. Posteriormente, ocorre a definição dos mapeamentos verticais entre os elementos dos modelos dos sistemas e elementos da ontologia selecionada, tendo como objetivo atribuir semântica aos modelos conceituais. Inicialmente mapeiam-se os conceitos e, em seguida, devem-se definir os mapeamentos entre as relações.

22 Uma vez estabelecidos os mapeamentos, o modelo de integração é construído baseado na ontologia e nos modelos das ferramentas, de maneira que cada elemento dos modelos conceituais dos sistemas que estejam sem mapeamento vertical seja considerado. Em seguida, cada elemento dos modelos conceituais dos sistemas deve ser mapeado para um elemento correspondente do modelo de integração. Todos elementos dos modelos conceituais dos sistemas devem ser mapeados. Geram-se, assim, os mapeamentos horizontais de conceitos e relações. Por fim, é realizada a atividade de projeto e implementação da integração. Há diversas maneiras de se obter uma solução de projeto e implementação de integração e, por isso, OBA-SI não se compromete com nenhuma solução específica de integração. Porém, OBAS-SI propõe algumas diretrizes para que a semântica estabelecida na fase de análise se mantenha. As ferramentas podem ser integradas sem que as mesmas sejam alteradas. Nesse contexto, é proposta a utilização de mediadores responsáveis por interligar as ferramentas, de forma a ter uma visão global dos sistemas as serem integrados. O modelo de integração é fundamental para o mediador, por fornecer as informações para projetá-lo, e os mapeamentos horizontais podem ser usados para projetar a comunicação entre as ferramentas e o mediador. A implementação desta comunicação pode ocorrer dentro do mediador ou fora dele, por meio de adaptadores que conectam as ferramentas ao mediador (BRINGUENTE, 2011). É importante ressaltar que esse processo de integração descrito acima, pode ser realizado de modo iterativo, principalmente nas atividades que envolvem o levantamento de requisitos e a análise da integração.

23 3 INTEGRAÇÃO SEMÂNTICA DE SISTEMAS DE APOIO À GERÊNCIA DE CONFIGURAÇÃO DE SOFTWARE A Gerência de Configuração de Software é um processo complexo que envolve diversas atividades, lidando com grande quantidade de informação. Dessa forma, é comum o uso de ferramentas computacionais para apoiar parte dessas atividades. Porém, é visto que muitas são usadas para apoiar o processo de GCS de maneira parcial e que, assim, para apoiar o processo como um todo, são necessárias várias ferramentas, ligadas a um processo maior, mas que realizam suas atividades isoladamente. Neste cenário, é comum a necessidade de repetição de esforços no sentido de manter consistentes as bases de dados das ferramentas adotadas. O ambiente ODE possui algumas funcionalidades de controle de versões de artefatos gerenciados nele a partir da ferramenta SVN-ODE. Contudo, não há um apoio à parte do processo de GCS referente ao controle de alteração. Sendo assim, para que o ambiente ODE disponibilizasse uma solução mais abrangente no apoio ao processo de GCS, visionou-se a possibilidade de integrar MantisBT à ferramenta SVN-ODE. Para realizar este projeto de integração, utilizou-se a abordagem OBA-SI. Este capítulo está organizado da seguinte forma: a Seção 3.1 descreve o cenário de integração, a Seção 3.2 apresenta os modelos conceituais da ontologia e dos sistemas considerados; a Seção 3.3 apresenta os mapeamentos dos modelos conceituais das ferramentas; e finalmente, na Seção 3.4 discute-se o projeto e a implementação da solução de integração. 3.1 Cenário de Integração O cenário de integração envolve os sistemas SVN-ODE e Mantis Bug Tracker (MantisBT). O MantisBT é um sistema de acompanhamento de trilha de problemas (bug tracker) (Mantis Bug Tracker, 2014). Ele permite o registro de necessidades de alteração (na forma de questões) e de solicitações de mudança correspondentes, bem como o acompanhamento de todas as etapas subsequentes da mudança. SVN-ODE é uma ferramenta de apoio à Gerência de Configuração de Software,

24 focada no controle de versões e de alterações dos artefatos de ODE (Ontology-based Software Development Environment). Ela visa fazer o controle de retirada e registro de versões de artefatos gerenciados no ODE, utilizando uma ferramenta livre (Subversion SVN) para esse propósito. O processo a ser apoiado pela integração dos sistemas acima mencionados é Controle de Questões de Alteração (Issue Tracking). Este processo envolve as seguintes atividades: Reportar Questão de Alteração: Esta atividade permite o registro de questões de alteração. Atribuir Questão de Alteração para Avaliação: Esta atividade permite designar um avaliador para avaliar a pertinência de uma questão de alteração. Avaliar Questão de Alteração: Esta atividade é responsável pela avaliação de uma questão de alteração pelo avaliador previamente designado. Atribuir Questão de Alteração para Resolução: Esta atividade permite designar um desenvolvedor para tratar uma questão de alteração. Retirar Itens para Alteração: Esta atividade é responsável por retirar do repositório os itens que sofrerão alteração. Implementar Alteração: Esta atividade é responsável por realizar a alteração em itens retirados do repositório. Registrar Itens Alterados: Esta atividade é responsável por inserir no repositório os itens que sofreram alteração. Atribuir Questão de Alteração para Revisão: Esta atividade permite designar um revisor para revisar as alterações feitas relativas a uma questão de alteração. Revisão: Esta atividade corresponde à revisão da resolução da Questão de Alteração feita pelo revisor. Encerrar Questão de Alteração: Esta atividade permite finalizar uma questão de alteração. A Tabela 1 apresenta um resumo do cenário de integração definido, listando os sistemas a serem integrados, o domínio da integração e as atividades do processo a ser apoiado.

25 Tabela 1 - Cenário de Integração CENÁRIO DE INTEGRAÇÃO SISTEMAS MantisBT e SVN-ODE DOMÍNIO Domínio de Gerência de Configuração de Software e Controle de Questões de Software ATIVIDADES Reportar Questão de Alteração. Atribuir Questão de Alteração para Avaliação. Avaliar Questão de Alteração. Atribuir Questão de Alteração para Resolução. Retirar Itens para Alteração. Implementar Alteração. Registrar Itens Alterados. Atribuir Questão de Alteração para Revisão. Revisar Questão de Alteração. Encerrar Questão de Alteração. 3.2 Modelos Conceituais Relacionados ao Cenário de Integração Uma vez definido o cenário de integração, os modelos conceituais requeridos devem ser recuperados (CALHAU, 2011). A seguir são apresentados os modelos conceituais da ontologia de domínio de referência adotada e das ferramentas a serem integradas (SVN-ODE e MantisBT) Ontologia de Gerência de Questões A ontologia utilizada como base para esta iniciativa de integração foi a Ontologia de Gerência de Questões apresentada na Seção 2.1. Como o cenário de integração considerado neste trabalho trata é relacionado a um tipo de questão específico (questão de alteração), foi realizada uma especialização da ontologia anteriormente descrita para o controle de alterações no contexto da Gerência de Configuração de Software, sendo denominada ontologia de Controle de Questões de Alteração de Software. A Figura 4 apresenta o fragmento do modelo conceitual da ontologia de Controle de Questões de Alteração de Software que especializa a

26 ontologia apresentada na Figura 1. Basicamente, esta especialização considera que a resolução de uma questão de alteração de software envolve dois passos: checkout dos itens de configuração a serem alterados e checkin dos itens alterados. Assim, o fragmento que trata da resolução (envolvendo o relator IssueResolution) foi substituído pelo fragmento da Figura 4. Figura 4 - Diagrama OntoUML do fragmento alterado na Ontologia de Controle de Questões de Alteração de Software. Como mostra a Figura 4, a ontologia de Gerência de Questões foi especializada para questões de alteração. Por ser um controle dentro do domínio da Gerência de Configuração de Software, fez-se necessário especificar como é realizada a resolução da questão. Assim, entre as fases Assigned to Resolution e Treated Issue da ontologia de Gerência de Questões foi inserida a fase Checked Out Issue. Da mesma forma, foi acrescentado o relator Checkout. Além disso, o

27 relator Issue Resolution substituído pelo relator Checkin Modelo Conceitual Estrutural de SVN-ODE A Figura 5 apresenta o diagrama de classes de SVN-ODE, relativo ao controle de alteração de software. Figura 5 - Diagrama de Classes de SVN-ODE referente ao controle de Alteração. Como está ilustrado na figura acima, Desenvolvedor é um tipo de Recurso Humano que herda de Pessoa. Checkout representa um registro da cópia de um conjunto de versões gerenciadas pelo ODE para uma pasta, que está relacionada a uma Alteração. Checkin representa o registro de uma Alteração no repositório. Uma Alteração é uma modificação, gerada por uma questão de alteração (Issue), e está relacionada a um Projeto no ODE.

28 3.2.3 Modelo Conceitual do MantisBT A Figura 6 apresenta o diagrama de classes da ferramenta MantisBT, considerando o cenário de integração definido. Este modelo conceitual apresenta parte do modelo produzido por Braga e Silva (2013), representando apenas as classes de interesse para a integração. Além disso, foi incluído o conceito CustomField a partir do esquema de banco de dados do MantisBT, pois é um conceito utilizado no domínio de integração considerado. Figura 6 - Diagrama de Classes de MantisBT. O conceito principal do MantisBT é o conceito de Bug. Apesar do termo Bug tipicamente se referir a defeito, em MantisBT, tal conceito é usado de maneira mais abrangente, representando questões que podem ser a cerca de documentos de requisitos, do desenvolvimento de métodos e classes, ou a cerca da elaboração e execução de casos de testes. A classe Bug possui diversos atributos. Neste trabalho, são modelados apenas aqueles considerados para o cenário de integração

29 em questão. Um Bug está relacionado a um projeto (Project) e tem um ou mais registros de histórico (History), os quais armazenam os eventos que ocorreram relacionados àquele bug. Cada registro de histórico (History) se refere a um usuário (User). Alguns projetos precisam registrar mais informações que outros sobre bugs e, por isso, existe a classe CustomField, que permite criar campos customizados para prover maiores informações sobre os bugs Mapeamentos Verticais Os mapeamentos verticais objetivam tornar explícitas as conceituações dos sistemas tomando como base a ontologia de referência definida. Assim, tais mapeamentos ocorrem entre os conceitos e relacionamentos descritos nos modelos conceituais estruturais dos sistemas e da ontologia definida para a integração. Por meio desses mapeamentos, é atribuída a semântica aos conceitos e relacionamentos dos sistemas a partir de uma mesma referência, o que permite uma comparação entre as conceituações dos sistemas envolvidos. A Tabela 2 apresenta os mapeamentos verticais dos conceitos de MantisBT e SVN-ODE com os conceitos da ontologia de Controle de Questões de Alteração de Software. Tabela 2 - Mapeamentos Verticais de Conceitos. Ontologia MantisBT SVN-ODE Issue Bug Issue Communicated Issue Bug, se Bug.status = New ---- Issue Originator User, se Bug.reporter=User -- Person ---- Pessoa Developer ---- Desenvolvedor Checkout - Checkout Treated Issue Bug, se Bug.status = Resolved ---- Checkin ---- Checkin Closed Issue Bug, se Bug,status = Closed -- Human Resource User Recurso Humano Project Project Projeto Alguns dos mapeamentos na Tabela 2 acontecem de forma direta, onde uma classe da ferramenta é mapeada diretamente para um conceito da ontologia de

30 referência, como por exemplo, a classe Bug da ferramenta MantisBT é mapeada para o conceito Issue da ontologia. O mesmo acontece com todos mapeamentos das classes da ferramenta SVN-ODE para os conceitos da ontologia. Um mapeamento em especial não é feito de forma direta, o mapeamento do conceito Issue Originator para a classe User, o qual somente ocorre quando o User reporta um Bug (User.reports!= null). A Tabela 3 apresenta os mapeamentos verticais dos relacionamentos entre os conceitos de MantisBT com as relações da ontologia de Controle de Questões de Alteração de Software. Tabela 3 - Mapeamentos Verticais de Relacionamentos de MantisBT Ontologia MantisBT Conceito Relacionamento Conceito Conceito Relacionamento Conceito Issue Originator performs Issue User reports Bug Communication Issue Communication communicates Communicated Issue Issue originated in Project Bug isrelatedto Project O mapeamento vertical do relacionamento entre Bug e Project (isrelatedto) é feito de forma direta. Entretanto, o relacionamento entre User e Bug (reports) se dá através de dois relacionamentos da ontologia de referência: o relacionamento entre Issue Originator e Issue Communication, e o relacionamento de Issue Communication e Communicated Issue (duas relações de mediação). Isso ocorre, pois a relação entre User e Bug é uma relação material, a qual deriva de um relator. Esse relator é explicitamente representado na ontologia (pelo conceito Issue Communication), mas não é representado no MantisBT. A Tabela 4 apresenta os mapeamentos verticais dos relacionamentos entre os conceitos de SVN-ODE com as relações da ontologia de Controle de Questões de Alteração de Software.

31 Tabela 4 - Mapeamentos Verticais de Relacionamentos de SVN-ODE Ontologia SVN-ODE Conceito Relacionamento Conceito Conceito Relacionamento Conceito Developer performs Checkout Desenvolvedor realiza Checkout Developer performs Checkin Desenvolvedor realiza Checkin Issue originated in Project Issue gera Alteração Alteração relacionada a Projeto É importante ressaltar que outros mapeamentos são possíveis, mas que é difícil estabelecer a semântica, pois eles requerem que se faça um uso específico de certas classes das ferramentas. Por exemplo, todos os relators mostrados na ontologia são derivados de eventos, os quais podem ser capturados por meio de History em MantisBT. Em princípio, com o MantisBT, não é possível apoiar a gerência de questões em sua totalidade, como descrito pela ontologia. Ainda que o MantisBT não tenha vários conceitos explicitamente declarados, eles podem ser representados, pois o MantisBT provê a capacidade para gerentes e administradores definirem campos personalizados como meio de estender o MantisBT para lidar com informação que é específica para um grupo ou projeto. Assim, foram definidos um novo conjunto de status, um novo fluxo de mudança dos mesmos e também novos campos a serem registrados durante as mudanças, a fim de atender à maior parte da ontologia de referência. Neste trabalho os valores admissíveis para o atributo status da classe Bug foram customizados para o seguinte conjunto, de modo a contemplar as mesmas fases de uma questão na ontologia de referência: {New, Assigned to Evaluation, Evaluated, Assigned to Resolution, Checked Out, Treated, Assigned to Review, Reviewed, Closed}. Tomando por base esta customização, a classe History pode ser usada para representar os diversos relators definidos na ontologia. A Tabela 5 complementa os mapeamentos verticais dos conceitos de MantisBT, agora customizado, com os conceitos da ontologia de Controle de Questões de Alteração de Software.

32 Tabela 5 - Mapeamentos Verticais de Conceitos Ontologia Issue Assigned to Evaluation Issue Assignment to Evaluation Issue Appraiser Evaluated Issue Issue Evaluation Issue Assigned to Resolution Issue Assignment to Resolution Developer Checked Out Issue Checkout Treated Issue Checkin Issue Assigned to Review Issue Assignment to Review Reviewer Reviewed Issue Issue Review Issue Closing MantisBT Bug, se Bug.status=Assigned to Evaluation History, se History.fieldName=Status, History.oldValue=New e History.newValue=Assigned to Evaluation User, quando Bug.handler = User e existe Bug.History tal que History.fieldName = Status, History.oldValue = New e History.newValue = Assigned to Evaluation Bug, se Bug.status=Evaluated History, se History.fieldName=Status, History.oldValue=Assigned to Evaluation e History.newValue=Evaluated Bug, se Bug.status=Assigned to Resolution History, se History.fieldName=Status, (History.oldValue=Evaluated ou History.oldValue=Reviewed) e History.newValue=Assigned to Resolution History, e o u ltimo Bug.History.fieldName=deadline User, quando Bug.handler = User e existe Bug.History tal que History.fieldName = Status, History.oldValue = Evaluated e History.newValue = Assigned to Resolution Bug, se Bug.status=Checked Out History, se History.fieldName=Status, History.oldValue=Assigned to Resolution e History.newValue=Checked Out Bug, se Bug.status=Treated History, se History.fieldName=Status, History.oldValue=Checked Out e History.newValue=Treated Bug, se Bug.status=Assigned to Review History, se History.fieldName=Status, History.oldValue=Treated e History.newValue=Assigned to Review User, quando Bug.handler = User e existe Bug.History tal que History.fieldName = Status, History.oldValue = Treated e History.newValue = Assigned to Review Bug, se Bug.status=Reviewed History, se History.fieldName=Status, History.oldValue=Assigned to Review e History.newValue=Reviewed History, se History.fieldName=Status, History.oldValue=Reviewed e History.newValue=Closed

33 Com a customização do MantisBT o estado Resolved foi substituído pelo estado Treated. E além disso, criamos um CustomField como nome deadline do tipo Date. Assim quando um deadline é passado ou atualizado, a classe History guarda esse evento como uma alteração do campo do Bug. As fases da Issue são mapeadas para um Bug dependendo do estado (status) que o Bug assume. Por exemplo, Communicated Issue é mapeado para Bug quando seu estado (status) é igual a New. Os vários relators da ontologia são mapeados para History, quando o History.fieldName = status e os atributos oldvalue e newvalue assumirem uma determinada atribuição. Por exemplo, Issue Evaluation é mapeado para History quando History.fieldName = status, e History.oldValue = Assigned to Evaluation e History.newValue = Evaluated. As propriedades deadline dos relators Issue Assignment to Evaluation, Issue Assignment to Resolution e Issue Assignment to Review são mapeadas também para instâncias de History, agora quando History.fieldName = deadline. Os papéis (roles) desempenhados por um Human Resource, exceto Manager, são mapeados para User, quando Bug.handler = User e existir um Bug.History tal que History.fieldName = status e os demais campos assumem uma determinada atribuição. Por exemplo, Issue Appraiser é mapeado para User quando Bug.handler = User e existir um Bug.History tal que History.fieldName = status, History.oldValue = New e History.newValue = Assigned to Evaluation. A Tabela 6 apresenta os mapeamentos verticais dos relacionamentos entre os conceitos de MantisBT customizado com as relações da ontologia de Controle de Questões de Alteração de Software Modelo de Integração O modelo de integração serve como referência para atribuição semântica em uma iniciativa de integração, levando em consideração características particulares da mesma. Para tal, uma classe sem equivalência na ontologia foi introduzida para tratar aspectos importantes do domínio da integração, a saber a classe Change. A Figura 7 apresenta o diagrama de classes relativo a esse modelo.

34 33 Tabela 6 - Mapeamentos Verticais de Relacionamentos de MantisBT Ontologia MantisBT Conceito Relacionamento Conceito Conceito Relacionamento Conceito Issue Assigned to relative to Issue Assignment to Bug ishandledby, se Bug = Issue Assigned to User Evaluation Issue Assignment to assigns issue to Evaluation Issue Appraiser Evaluation e User = Issue Appraiser, conforme definido na Tabela 4. Evaluation Evaluated Issue evaluates Issue Evaluation Bug ishandledby, se Bug = Evaluated Issue e User Issue Evaluation performs Issue Appraiser User = Issue Appraiser, conforme definido na Tabela 4. Issue Assigned to Relative to Issue Assignment to Bug ishandledby, se Bug = Issue Assigned to User Resolution Issue Assignment to Assigns issue to Resolution Developer Resolution e User = Developer, conforme definido na Tabela 4. Resolution Checked out Issue relative to Checkout Bug ishandledby, se Bug = Checked Out Issue User Checkout performs Developer e User = Developer, conforme definido na Tabela 4. Treated Issue relative to Checkin Bug ishandledby, se Bug = Treated e User = User Checkin performs Developer Developer, conforme definido na Tabela 4. Issue Assigned to Relative to Issue Assignment to Bug ishandledby, se Bug = Issue Assigned User Review Issue Assignment to Assigns issue to Review Reviewer to Review e User = Reviewer, conforme definido na Tabela 4. Review Reviewed Issue reviews Issue Review Bug ishandledby, se Bug = Reviewed Issue e User Issue Review performs Reviewer User = Reviewer, conforme definido na Tabela 4.

35 Figura 7 - Diagrama de Classes do Modelo de Integração. 34

36 3.2.6 Mapeamentos Horizontais Os mapeamentos horizontais visam tratar conceitos e relacionamentos não descritos pela ontologia e que consideram, portanto, os correspondentes elementos introduzidos no modelo de integração. Assim, são mostrados apenas os mapeamentos que não foram considerados na realização dos mapeamentos verticais. A Tabela 35 apresenta o mapeamento vertical do conceito Change, introduzido no modelo de integração. Este conceito corresponde ao conceito Alteração de SVN-ODE e foi introduzido por ser um conceito importante no domínio de controle de alteração. Tabela 7 - Mapeamentos Horizontais entre Conceitos Modelo de Integração MantisBT SVN-ODE Change ---- Alteração A Tabela 35 apresenta os mapeamentos horizontais dos relacionamentos de SVN-ODE com os relacionamentos do modelo de integração referentes à classe Change introduzida ao modelo. Tabela 8 - Mapeamentos Horizontais de Relacionamentos de SVN-ODE Modelo de Integração SVN-ODE Conceito Relacionamento Conceito Conceito Relacionamento Conceito Issue creates Change Issue gera Alteração Checkout relative to Change Alteração sofre Checkout Checkin relative to Change Alteração sofre checkin

37 3.3 Projeto e Implementação da Integração Uma vez desenvolvido o modelo de integração e realizados os mapeamentos horizontais, podem ser realizados o projeto e a implementação da solução de integração. Para que SVN-ODE e MantisBT se comuniquem, é necessário que os elementos compartilhados sejam traduzidos. Assim, a solução proposta consiste em desenvolver um mediador responsável por traduzir os dados compartilhados entre os sistemas, como apresentado na Figura 8. Essa figura evidencia, ainda, o fluxo de comunicação entre os sistemas. Conforme exposto, parte do mediador se encontra dentro do ODE, fazendo acesso direto ao banco de dados de ODE e permitindo que ferramentas do ambiente, como o SVN-ODE, acessem suas funcionalidades. Para fazer o acesso ao banco de dados de MantisBT, foi implementado um Plugin, chamado Observador, que é a parte do mediador da integração instalado no MantisBT. O nome deste mediador procura espelhar que o mesmo se comporta como um observador de eventos do MantisBT, já que é necessário um fluxo de comunicação do MantisBT para o ODE. Figura 8 - Mediador: responsável pela comunicação entre SVN-ODE e MantisBT

38 Pelo mediador, é possível controlar e obter as atualizações feitas nas Issues no MantisBT. É importante ressaltar que as Issues, tanto no MantisBT quanto no ODE, possuem equivalência, pois a integração foi implementada com as duas vias de comunicação, no sentido ODE MantisBT e MantisBT ODE. Além disso, maior parte da comunicação ocorre no sentido MantisBT ODE, pois a maior parte do processo alvo desta iniciativa de integração é realizada no MantisBT. Para permir essa comunicação foi necessário que o mediador oferecesse alguns serviços para serem utilizados pelo Observador no MantisBT. Para implementar o mediador foram utilizados a linguagem de programação Java, o banco de dados relacional PostgreSQL e os frameworks Hibernate (mapeamento objeto-relacional), Zkoss (interface com o usuário) e Spring (injeção de dependência). Por ele ser independente de ferramenta do ODE, caso sejam necessárias mudanças na comunicação entre o mediador e o MantisBT, as ferramentas que utilizam funcionalidades desse mediador não sofrerão alteração, porque as mesmas só fazem chamadas de funções e o modo como a comunicação é feita fica visível apenas para o mediador. Para implementar o Observador (Plugin) foram utilizados a linguagem Hypertext Preprocessor (PHP), linguagem na qual a ferramenta MantisBT foi desenvolvida e o banco de dados relacional MySQL. A arquitetura de software do mediador baseia-se no estilo em camadas. Elas encontram-se organizadas em quatro camadas, a saber: Camada de Interface com o Usuário, Camada de Serviços, Camada de Lógica de Negócio e Camada de Gerência de Dados, conforme apresentado na Figura 9. Na organização da camada de lógica de negócio, foi escolhido o padrão Camada de Serviço. Portanto, essa camada é dividida em Componente de Domínio do Problema e Componente de Gerência de Tarefas para tratar, respectivamente, a lógica do domínio do problema (classes advindas do modelo estrutural) e lógica de aplicação (classes com origem nos casos de uso). A camada de serviços oferece serviços que podem ser utilizados por ferramentas Web externas ao ODE. Para organizar a camada de interface com o usuário, optou-se por adotar o padrão Modelo-Visão-Controlador (MVC). Sendo assim, essa camada possui classes de visão e classes de controle de interação, que fazem a ligação entre as classes de visão e as classes gerenciadoras de tarefas.

39 Figura 9 - Arquitetura de software do mediador Para implementar a comunicação entre o mediador e MantisBT, inicialmente pesquisou-se por uma API de comunicação direta com o MantisBT. Durante as pesquisas, encontrou-se a API mantisconnect-client. Após alguns testes, verificou-se que nem todas as funcionalidades oferecidas pela API funcionavam dentro das configurações do ODE, isso porque essa API requer a instalação de elementos na configuração que não estão presentes no Ambiente ODE. No entanto, como as funcionalidades de interesse para o mediador podem ser feitas, optou-se por utilizar essa API. A Figura 10 apresenta uma tela do MantisBT, a qual mostra uma questão no estado atribuída para resolução (Assigned to Resolution).

40 Figura 10 - Descrição de uma questão na ferramenta MantisBT Na Figura 11, pode-se observar que essa questão é a mesma sobre a qual será feito o checkout para realizar a alteração, visualizado no ambiente ODE. Essa operação só é permitida quando, dentro do MantisBT a questão já foi atribuída para resolução. Figura 11 - Janela do SVN-ODE de realização de um Checkout no ODE