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 ReqODE e PGDS-Req se comuniquem, é necessário que os elementos
compartilhados sejam traduzidos. Nesse sentido, a solução proposta consiste em desenvolver um mediador responsável por traduzir os dados compartilhados entre os sistemas, como é apresentado na Figura 24. Essa figura evidencia, ainda, o fluxo de comunicação entre os sistemas. Conforme exposto, o mediador faz acesso tanto ao banco de dados de ReqODE quanto ao sistema em si e não acessa diretamente o banco de dados de PGDS-Req.
O mediador também é responsável por disponibilizar algumas das funcionalidades nativas dos sistemas a serem integrados, a saber: Rastreamento de Requisitos, Geração de Matrizes de Rastreabilidade e Análise de Impacto de Alteração. Sendo assim, obtemos um novo sistema consumindo funcionalidades de ReqODE e da PGDS-Req, e alimentando o banco de dados de ReqODE. Como esperado, o modelo estrutural do mediador é fortemente baseado no modelo de integração, diferenciando-se dele em pequenos aspectos no módulo de requisitos, conforme apresentado na Figura 25.
50
Para explicitar se um projeto do mediador é uma referência para um projeto da PGDS- Req, de ReqODE ou de ambos, foi adicionado o relacionamento da classe Projeto com o tipo enumerado TipoProjeto. Os campos enderecoRepositorio e versaoRepositorio são usados para referenciar um projeto na PGDS-Req, enquanto o campo id é usado para referenciar um projeto em ReqODE. De acordo com o tipo do projeto, esses campos podem estar preenchidos ou não. Neste texto, o termo projeto vinculado será usado para designar um projeto que está disponível em ReqODE e na PGDS-Req.
No mediador podem ser selecionados, além dos projetos vinculados, projetos que estão somente em uma das ferramentas. Porém, para eles, são disponibilizadas apenas as funcionalidades do sistema ao qual pertencem. Por exemplo, se um projeto de ReqODE está selecionado no mediador, é possível acessar apenas a funcionalidade de rastreamento de requisitos.
Nota-se também que, enquanto no modelo de integração os conceitos de requisito funcional, requisito não-funcional e regra de negócio apareciam na forma de
especialização da classe Requisito, aqui esses conceitos são obtidos do relacionamento da classe Requisito com o tipo enumerado TipoRequisito. Esta solução de projeto foi adotada, uma vez que as subclasses (RequisitoFuncional, RequisitoNaoFuncional e RegraDeNegocio) não apresentavam nenhuma propriedade distinta da superclasse (Requisito).
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), Spring (injeção de dependência) e Selenium (acesso automatizado à interface). Para acessá-lo é feito um controle de usuário por meio de login e senha, considerando a base de dados de ReqODE, isto é, somente usuários cadastrados em ReqODE podem acessar o mediador.
A arquitetura de software do sistema baseia-se em uma combinação dos estilos em partições e camadas. Em geral, as partições estão organizadas em três camadas, a saber: Camada de Interface com o Usuário, Camada de Lógica de Negócio e Camada de Gerência de Dados. 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). 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. Conforme dito anteriormente, a persistência de objetos deste sistema é realizada em um banco de dados relacional (PostgreSQL), utilizando o
framework de persistência Hibernate e o padrão DAO, sendo que somente a classe
Projeto é persistente. Entretanto, projetos presentes em apenas uma das ferramentas não são persistidos. As outras classes são recuperadas a partir das bases de dados de ReqODE e PGDS-Req, não sendo replicadas no mediador. Para recuperar os dados de ReqODE, são feitas consultas SQL diretamente no banco de dados dessa ferramenta. Já para recuperar dados da PGDS-Req, são executadas consultas SPARQL em um grafo RDF que representa a versão mais recente de um repositório.
No mediador aparece também a funcionalidade de exportação de projeto, responsável por exportar um projeto da PGDS-Req para ReqODE e estabelecer um vínculo entre eles. A Figura 26 apresenta a interface da funcionalidade de exportação de projetos. É
52 importante ressaltar que essa transferência de dados ocorre somente no sentido da PGDS-Req para ReqODE. Além disso, um vínculo é definido somente no momento imediatamente posterior à exportação de um projeto, ou seja, não é possível vincular dois projetos já existentes em ambas ferramentas.
Na listagem de projetos, como mostra a Figura 27, há uma coluna evidenciando se o projeto em questão está apenas disponível em ReqODE, apenas na PGDS-Req ou em ambos. Com base nisso, o mediador controla quais funcionalidades podem ser acessadas. No contexto de um projeto, é possível acessar apenas as funcionalidades dos sistemas em que ele está disponível. Isto é, para projetos de ReqODE, não é possível acessar as funcionalidades de geração de matrizes de rastreabilidade e de análise de impacto de alteração em requisito e, para projetos da PGDS-Req, não é possível acessar a funcionalidade de rastreamento de requisitos. No caso de projetos vinculados, todas essas funcionalidades do mediador são disponibilizadas.
Figura 27 - Listagem de Projetos Figura 26 - Interface Exportar Projeto
Quando essa listagem de projetos é exibida, é verificado se algum projeto vinculado sofreu alguma alteração em PGDS-Req e, se houve alteração, uma mensagem é exibida e essa nova versão do projeto é exportada para ReqODE. Com isso, o projeto vinculado no mediador passa a referenciar o projeto que acaba de ser exportado para ReqODE, perdendo, assim, a informação de vínculo com a antiga versão, que passa a ser exibida no mediador como projeto disponível apenas em ReqODE. A Figura 28 apresenta a mensagem exibida.
Há também uma funcionalidade de consulta de informações básicas de requisitos, pacotes, casos de uso e classes, disponível para todos tipos de projeto (vinculados ou presentes em somente uma das ferramentas). No caso de projetos vinculados, o mediador recupera esses dados da PGDS-Req. A Figura 29 apresenta a interface da janela de visualização de requisitos. É importante ressaltar que o mediador não permite a alteração de dados. Sendo assim, quando alterações ocorrem nos documentos semânticos, uma nova versão do projeto é gerada na PGDS-Req e, posteriormente, pode ser exportado para ReqODE. Ainda que um projeto vinculado possa ser alterado em ReqODE, isso não é indicado, uma vez que o mediador não se compromete com o controle da consistência no sentido de ReqODE para a PGDS-Req.
Figura 28 - Mensagem de Alteração em Projeto Vinculado
54
Há ainda, as funcionalidades herdadas dos sistemas sendo integrados que, portanto, trabalham de maneira similar. Nativa da PGDS-Req, a geração de matrizes de rastreabilidade apresenta as matrizes de dependência de requisitos, conflito de requisitos, requisitos e casos de uso, requisitos e classes e, ainda, requisitos e casos de teste. Tendo em vista que, em geral, essas matrizes são grandes, o que dificulta sua visualização, foi implementado no mediador um recurso de filtragem da matriz, isto é, podemos apresentar a matriz considerando apenas um determinado tipo de requisito. A Figura 30, por exemplo, apresenta uma matriz de dependência de requisitos considerando apenas requisitos funcionais.
A funcionalidade de análise de impacto de alteração em requisito, assim como ocorre na PGDS-Req, ferramenta da qual deriva, apresenta duas árvores de rastreabilidade de impacto: vertical e horizontal. Na vertical, constam casos de uso, classes e casos de teste que se relacionam direta ou indiretamente com o requisito dado. Na horizontal, por sua vez, são apresentados os requisitos que dependem do requisito em análise e, também, os requisitos que com ele conflitam. A Figura 31 apresenta um exemplo de análise de impacto de alteração.
56
O mediador conta, ainda, com o rastreamento de requisitos, funcionalidade originária de ReqODE. Trata-se de uma funcionalidade que, dada uma classe ou caso de uso, retorna os requisitos associados a esses artefatos. A Figura 32 expõe a janela de rastreamento de requisitos por caso de uso.
Figura 32 - Rastreamento de Requisitos pelo Caso de Uso Cadastrar_Requisito
58