INTEGRANDO FERRAMENTAS DE APOIO À ENGENHARIA DE REQUISITOS

Transcrição

1 UNIVERSIDADE FEDERAL DO ESPÍRITO SANTO CENTRO TECNOLÓGICO DEPARTAMENTO DE INFORMÁTICA CARLOS EDUARDO CORREA BRAGA INTEGRANDO FERRAMENTAS DE APOIO À ENGENHARIA DE REQUISITOS VITÓRIA 2012

2 CARLOS EDUARDO CORREA BRAGA INTEGRANDO FERRAMENTAS DE APOIO À ENGENHARIA DE REQUISITOS 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 2012

3 CARLOS EDUARDO CORREA BRAGA INTEGRANDO FERRAMENTAS DE APOIO À ENGENHARIA DE REQUISITOS COMISSÃO EXAMINADORA Prof. Dr. Ricardo de Almeida Falbo Departamento de Informática UFES Orientador Prof. Prof. Vitória, 24 de outubro de 2012.

4 RESUMO O processo de Engenharia de s é complexo, envolvendo várias atividades e uma grande quantidade de informações. Porém, de maneira geral, existem diversas ferramentas oferecendo apenas soluções parciais para esse domínio, sendo que essas ferramentas geralmente são construídas em contextos diferentes, por grupos distintos de desenvolvedores, sem que seja vislumbrada a possibilidade futura de integração. Assim, é comum que elas apresentem problemas de heterogeneidade, isto é, os modelos não são compartilhados, abrindo espaço para diversos tipos de conflitos. Este trabalho apresenta uma iniciativa de integração de duas ferramentas do domínio de Engenharia de s (ReqODE e PGDSReq), realizada seguindo OBASI (OntologyBased Approach for Semantic Integration), uma abordagem baseada em ontologias na qual a integração semântica é realizada em um alto nível de abstração, provendo acordo semântico entre os sistemas no nível conceitual. Neste trabalho OBASI é aplicada parcialmente, considerando apenas a camada de dados. Palavraschave: Engenharia de s, Integração Semântica de Sistemas, Interoperabilidade Semântica

5 ABSTRACT Requirements Engineering is a complex process, involving several activities and a large quantity of information. In general, there are several tools offering partial solutions to this process. However, these tools are usually constructed in different contexts by different groups of developers, without glimpsing the possibility of future integration. So, it is common that they have problems of heterogeneity, that is, the models are not shared, making room for different types of conflicts. This paper presents an integration initiative of two tools supporting the Requirements Engineering process (ReqODE and PGDsReq). This initiative was conducted following OBASI, an OntologyBased Approach for Semantic Integration, in which semantic integration is performed at a high level of abstraction, providing semantic agreement between the systems at the conceptual level. In this work OBASI is partially applied, considering only the data layer. Keywords: Requirements Engineering, Semantic System Integration, Semantic Interoperability

6 LISTA DE FIGURAS Figura 1 Interface do Formulário de Cadastro de s...16 Figura 2 Interface de Definição de Relações de Rastreabilidade...17 Figura 3 Interface de Rastreamento de s...18 Figura 4 Visão Geral da PGDS...21 Figura 5 Sugestão de Priorização...23 Figura 6 Análise de Impacto de Mudança no RF Figura 7 Relatório de Mudanças em Documento de s...25 Figura 8 Processo de Integração Semântica (CALHAU, 2011)...27 Figura 9 Atividades da Fase de Análise de Integração (CALHAU, 2011)...28 Figura 10 Ontologia de s: Módulo Principal (MACHADO, 2012)...34 Figura 11 Ontologia de s: Módulo Casos de Uso (MACHADO, 2012)...35 Figura 12 Ontologia de s: Módulo Casos de Teste (MACHADO, 2012)...36 Figura 13 Modelo de Casos de Uso da PGDSReq...37 Figura 14 Modelo Estrutural do pacote Conhecimento:...38 Figura 15 Diagrama de Caso de Uso do pacote Conhecimento::...39 Figura 16 Modelo Conceitual referente ao Pacote UML...39 Figura 17 Diagrama de Caso de Uso referente ao pacote UML...40 Figura 18 Modelo Estrutural referente ao pacote Gerência s...41 Figura 19 Diagrama de Caso de Uso do Pacote Gerência de s...41 Figura 20 Modelo de Integração: Módulo de s...45 Figura 21 Modelo de Integração: Módulo de Equipe...46 Figura 22 Modelo de Integração: Módulo de Caso de Uso...46 Figura 23 Modelo de Integração: Módulo de Caso de Teste...47 Figura 24 Mediador: responsável pela comunicação entre ReqODE e PGDSReq 51 Figura 25 Modelo Estrutural do Mediador...52 Figura 26 Interface Exportar Projeto...54 Figura 27 Listagem de Projetos...54 Figura 28 Mensagem de Alteração em Projeto Vinculado...55 Figura 29 Janela de Visualização de...56 Figura 30 Matriz de Rastreabilidade de Dependência de s...57 Figura 31 Análise de Impacto de Alteração em RF Figura 32 Rastreamento de s pelo Caso de Uso Cadastrar_...59

7 LISTA DE TABELAS Tabela 1 Cenário de Integração...31 Tabela 2 Mapeamentos Verticais de ReqODE...42 Tabela 3 Mapeamentos Verticais de Relacionamentos em ReqODE...43 Tabela 4 Mapeamentos Horizontais entre Conceitos...47 Tabela 5 Mapeamentos Horizontais de Relacionamentos em ReqODE...48 Tabela 6 Mapeamentos Horizontais de Relacionamentos em PGDSReq...49

8 SUMÁRIO 1 INTRODUÇÃO Objetivos Histórico do Trabalho Organização do Texto ENGENHARIA DE REQUISITOS, DOCUMENTAÇÃO SEMÂNTICA E INTEGRAÇÃO DE SISTEMAS Engenharia de s ReqODE: Uma Ferramenta de Apoio à Engenharia de s Documentação Semântica PGDS Plataforma de Gerenciamento de Documentos Semânticos PGDSReq: Uma Especialização da PGDS para o Domínio de Engenharia de s Integração de Sistemas OBASI: OntologyBased Approach for Semantic Integration INTEGRAÇÃO DE SISTEMAS DE APOIO À ENGENHARIA DE REQUISITOS Cenário de Integração Modelos Utilizados na Iniciativa de Integração Ontologia de Domínio Modelos Conceituais de PGDSReq Modelos Conceituais de ReqODE Integrando ReqODE e PGDSReq 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...60 REFERÊNCIAS BIBLIOGRÁFICAS...62

9 9 1 INTRODUÇÃO Tipicamente, um processo de Engenharia de s envolve as seguintes atividades (KOTONYA; SOMMERVILLE, 1998): levantamento de requisitos, análise e negociação de requisitos, documentação de requisitos, verificação e validação de requisitos e, ainda, gerência de requisitos. Sendo assim, é possível perceber que a Engenharia de s é um processo complexo, envolvendo diversas atividades relacionadas, e, nesse sentido, tratase de um fator determinante para o sucesso ou fracasso de um projeto. Para apoiar esse processo, são necessárias várias ferramentas, tais como ferramentas de gerência de requisitos, ferramentas de modelagem e ferramentas de elaboração de documentos. Entretanto, ferramentas isoladas oferecem apenas soluções parciais e, constantemente, introduzem consistências e necessidade de repetição de esforços. ReqODE (MARTINS; NARDI; FALBO, 2006) e especialização da Plataforma de Gerência de Documentos Semânticos para o domínio s PGDSReq (MACHADO, 2012) são exemplos dessas ferramentas. ReqODE, uma ferramenta de apoio à Engenharia de s do ambiente de desenvolvimento de software ODE (Ontologybased Development Environment) (FALBO; RUY; MORO, 2005), possui funcionalidades de registro de requisitos e suas propriedades, definição de relações de rastreabilidades com outros artefatos de projeto (dentre eles, pacotes, casos de uso e classes), rastreamento de requisitos a partir desses artefatos e, ainda, a geração de um relatório customizável de rastreabilidade de um projeto, no qual figuram seus requisitos e informações acerca deles. PGDSReq, por sua vez, apresenta funcionalidades de priorização de requisitos, geração de matrizes de rastreabilidade horizontal e vertical, análise de impacto de alteração em requisitos, avaliação daqualidade de documentos relativos a requisitos por meio de checklists, notificação de alterações em documentos de requisitos e, por fim, consulta de indivíduos do domínio (requisitos, casos de uso, classes, entre outros). Portanto, percebese que essas ferramentas compõem um cenário do tipo descrito anteriormente, isto é, ferramentas isoladas oferecendo soluções parciais. Essa necessidade de aplicações trabalharem em conjunto de forma a apoiar complexos processos de negócio é crescente e não fica restrita ao domínio de Engenharia de s. Sendo assim, a integração de sistemas tornase um grande problema para as organizações. De maneira geral, as aplicações utilizadas são desenvolvidas por grupos

10 10 distintos e, constantemente, ignorando esse importante fator que é a integração. Dessa forma, essas aplicações são, em geral, heterogêneas, autônomas e distribuídas (IZZA, 2009). A heterogeneidade é, dentre os problemas de integração, um dos mais desafiadores. Aplicações, em sua maioria, não compartilham os mesmos modelos de dados e de comportamento, o que dificulta a integração (IZZA, 2009). Neste contexto, há abordagens que propõem processos de integração no sentido de minimizar, ou até mesmo resolver, esses problemas. Uma delas é OBASI (OntologyBased Approach for Semantic Integration) (CALHAU, 2011), uma abordagem de integração semântica baseada em ontologias 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, provendo acordo semântico entre os sistemas no nível conceitual. Para isso, modelos conceituais dos sistemas são comparados à luz de ontologias, usadas para atribuir semântica aos itens compartilhados entre os sistemas. 1.1 Objetivos O objetivo geral deste trabalho é integrar a especialização da Plataforma de Gerência de Documentos Semânticos para o domínio s PGDSReq (MACHADO, 2012), e ReqODE (MARTINS; NARDI; FALBO, 2006), a ferramenta CASE de apoio à Gerência de s do ambiente ODE, utilizando a abordagem de integração semântica OBASI (CALHAU, 2011). Nesse contexto, são objetivos específicos deste trabalho: integrar os modelos conceituais de dados de ReqODE e da PGDSReq, usando a Ontologia de s proposta em (MACHADO, 2012). desenvolver uma aplicação mediadora, integrando a PGDSReq e ReqODE para prover apoio, ainda que parcial, a um processo de Engenharia de s utilizado por uma Instituição Implementadora do MPS.BR (SOFTEX, 2012); aplicar o método OBASI nessa iniciativa de integração e, nesse sentido, obter um feedback desse uso, de maneira a contribuir para melhorias dessa abordagem.

11 Histórico do Trabalho Inicialmente, no programa 2010/2011 de Iniciação Científica, foi feita uma reengenharia de ReqODE (em sua versão desktop) (MARTINS; NARDI; FALBO, 2006), redimensionando seu escopo e fazendo a sua migração para a plataforma Web. Após isso, já no programa 2011/2012 de Iniciação Científica, foi desenvolvida uma nova interface para a Plataforma de Gerência de Documentos Semânticos (PGDS) (ARANTES, 2010) que impactou positivamente em aspectos como usabilidade, facilidade de aprendizado e de operação. Além disso, foram despendidos esforços no sentido de especializar a PGDS para o domínio da Engenharia de s, obtendose a PGDSReq (MACHADO, 2012). Tendo em vista que essas ferramentas apoiam apenas parcialmente o processo de Engenharia de s, visionouse a possibilidade de integrálas de maneira a atingir um estado de sinergia. Entretanto, a integração de sistemas não é uma tarefa trivial e, por isso, a utilização de uma abordagem bem definida tem o potencial de facilitar os trabalhos, evitando problemas que poderiam aparecer caso essa atividade fosse realizada de maneira adhoc. Sendo assim, optouse pela utilização de OBASI (OntologyBased Approach for Semantic Integration) (CALHAU, 2011), uma abordagem de integração semântica de sistemas na qual a integração é realizada em um alto nível de abstração, provendo acordo semântico entre os sistemas no nível conceitual. Portanto, conforme OBASI prega, inicialmente foram estabelecidos os requisitos, objetivos, cenário e escopo da iniciativa de integração. Em seguida, foi realizada a atividade de análise de integração, na qual foram recuperados os modelos dos sistemas envolvidos e estabelecidos os mapeamentos de acordo com a ontologia de referência selecionada nessa mesma fase. A partir disso, foi elaborado o modelo de integração e, portanto, finalizouse a etapa de análise de integração semântica. Posteriormente, considerando o modelo de integração obtido e seus mapeamentos com os modelos de ReqODE e PGDSReq, foram realizadas as etapas de projeto e implementação da integração.

12 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 Engenharia de s, Documentação Semântica e Integração de Sistemas: apresenta uma revisão da literatura acerca de temas relevantes ao contexto deste trabalho, a saber: Documentação Semântica, Engenharia de s e Integração de Sistemas. Capítulo 3 Integração Semântica de Sistemas de Apoio à Engenharia de s: apresenta a iniciativa de integração semântica da PGDSReq e ReqODE, utilizando OBASI (CALHAU, 2011). Capítulo 4 Considerações Finais: apresenta as conclusões do trabalho, dificuldades envolvidas, limitações e propostas de trabalhos futuros.

13 13 2 ENGENHARIA DE REQUISITOS, DOCUMENTAÇÃO SEMÂNTICA E INTEGRAÇÃO DE SISTEMAS Este trabalho trata da integração de ferramentas de apoio ao processo de Engenharia de s por meio da abordagem OBASI (CALHAU, 2011) e, portanto, para sua boa compreensão, este capítulo aborda brevemente temas relevantes a esse contexto, a saber: Engenharia de s, Documentação Semântica e Integração de Sistemas Engenharia de s s desempenham um papel fundamental no processo de software, tanto que são um fator determinante para o sucesso ou fracasso de um projeto de software (HOFMANN; LEHNER, 2001). Na literatura podemos encontrar diversas definições de requisito de software, dentre elas: s de um sistema são descrições dos serviços que devem ser fornecidos por esse sistema e as suas restrições operacionais (SOMMERVILLE, 2007). Um requisito de um sistema é uma característica do sistema ou a descrição de algo que o sistema é capaz de realizar para atingir seus objetivos (PFLEEGER, 2004). Um requisito é alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006). A partir dessas, e de outras definições, podese concluir que os requisitos de um sistema incorporam especificações de serviços que ele deve oferecer, restrições sob as quais deve operar e, ainda, propriedades gerais do sistema. O processo que envolve o levantamento, análise, documentação, verificação e validação e gerência dessas especificações, restrições e propriedades é chamado de Engenharia de s (KOTONYA; SOMMERVILLE, 1998).O Levantamento de s é a fase inicial do processo de Engenharia de s. Nessa etapa, é necessário um esforço conjunto de clientes, usuários e especialistas de domínio com o objetivo de entender a organização, seus processos, necessidades, deficiências dos sistemas de software atuais, possibilidades de melhorias e, ainda, restrições existentes (SOMMERVILLE, 2007).

14 14 Posteriormente, há a etapa de Análise de s, que é essencialmente uma atividade de modelagem. Modelos de análise são elaborados para se obter uma compreensão maior acerca do sistema a ser desenvolvido e para especificálo (SOMMERVILLE, 2007). Os requisitos e modelos capturados nas fases anteriores devem ser descritos e apresentados em documentos. A documentação é, portanto, uma atividade de registro e oficialização dos resultados da Engenharia de s (KOTONYA; SOMMERVILLE, 1998). Como resultado, um ou mais documentos devem ser produzidos. Muitos benefícios são alcançados com uma boa documentação, tais como (IEEE, 1998; NUSEIBEH; EASTERBROOK, 2000): facilita a comunicação dos requisitos; reduz o esforço de desenvolvimento, pois sua preparação força usuários e clientes a considerar os requisitos atentamente, evitando retrabalho nas fases posteriores; fornece uma base realista para estimativas; fornece uma base para verificação e validação; facilita a transferência do software para novos usuários e/ou máquinas e serve como base para futuras manutenções ou incremente de novas funcionalidades. A documentação de requisitos tem um número amplo de interessados e, nesse sentido, pode ser útil a existência de mais de um documento para registrar os resultados da Engenharia de s. Pfleeger (2004) prega a elaboração de dois tipos de documentos de requisitos: um Documento de Definição de s e um Documento de Especificação de s. O primeiro deve conter uma descrição do propósito do sistema, uma breve descrição do domínio do problema tratado pelo sistema e listas de requisitos funcionais, não funcionais e regras de negócio, descritos em linguagem natural. Já o Documento de Especificação de s deve conter os requisitos escritos a partir da perspectiva do desenvolvedor, devendo existir uma correspondência direta com os requisitos do Documento de Definição de s. Nesse documento devem ser apresentados os diversos modelos produzidos na fase de análise, bem como glossários dos termos utilizados e outras informações julgadas relevantes. Tendo em vista que requisitos são a base para o desenvolvimento, é fundamental que eles sejam cuidadosamente avaliados o quanto antes. Essa avaliação ocorre nas atividades de Verificação e Validação. A verificação objetiva assegurar que o software esteja sendo construído de maneira correta, isto é, devese verificar se os artefatos produzidos atendem aos requisitos estabelecidos e se os padrões organizacionais foram consistentemente aplicados. Por outro lado, o objetivo da validação é assegurar que o software que está sendo desenvolvido é o software correto, ou seja, assegurar que os

15 15 requisitos, e o software deles derivado, atendem ao uso proposto (ROCHA; MALDONADO; WEBER, 2011). Mudanças nos requisitos são comuns e podem ocorrer ao longo de todo o processo de software, desde o levantamento e análise de requisitos até durante a operação do sistema. Elas são o resultado de diversos fatores, tais como descoberta de erros, omissões, conflitos e inconsistências nos requisitos, melhor entendimento por parte dos usuários de suas necessidades e mudanças no negócio. Para minimizar as dificuldades impostas por essas mudanças, é necessário gerenciar requisitos (TOGNERI, 2002). A atividade de gerência de requisitos objetiva gerenciar alterações nos requisitos acordados, gerenciar relacionamentos entre requisitos, e gerenciar dependências entre requisitos e documentos produzidos durante o processo de software (KOTONYA; SOMMERVILLE, 1998). Para isso, essa atividade deve englobar subatividades relativas a controle de mudanças, controle de versão, acompanhamento do estado dos requisitos e reastreamento dos requisitos. Portanto, é possível notar que o processo de Engenharia de s é bastante complexo e, por isso, a utilização de ferramentas de apoio às suas atividades é fundamental para sua efetiva execução. Neste trabalho, são consideradas as ferramentas ReqODE e PGDSReq ReqODE: Uma Ferramenta de Apoio à Engenharia de s Em ODE (Ontologybased Development Environment) (FALBO; RUY; MORO, 2005), um ambiente de desenvolvimento de software concebido tomando como base ontologias, existe uma ferramenta de apoio à Engenharia de s chamada ReqODE. Essa ferramenta permite registrar requisitos e algumas de suas propriedades, bem como rastreálos. Ao cadastrar um requisito, devese informar a sua descrição, prioridade (alta, média ou baixa), tipo (funcional, não funcional ou regra de negócio) e categoria. Podese, ainda, definir os responsáveis e interessados no requisito, visando à facilitação da gerência de requisitos. Nesse momento, é criado um identificador para o requisito, a hora de criação é armazenada e, além disso, é realizada a sua associação com o projeto aberto no momento. A Figura 1 apresenta detalhes da interface do formulário responsável por essa entrada de dados.

16 16 Figura 1 Interface do Formulário de Cadastro de s Além disso, conforme mostra a Figura 2, é possível definir relações de rastreabilidade entre requisitos e demais produtos, a saber, outros requisitos (dependência e conflito), classe, pacotes, casos de uso e, ainda, outros artefatos.

17 17 Figura 2 Interface de Definição de Relações de Rastreabilidade ReqODE suporta, ainda, o rastreamento de requisitos por meio de filtro. Ou seja, podese verificar quem são os requisitos associados a determinado pacote, caso de uso, interessado ou responsável. A Figura 3 apresenta um exemplo de pesquisa de requisitos filtrada pelo seu responsável. Vale mencionar que é possível a visualização completa dos requisitos mostrados no resultado.

18 18 Figura 3 Interface de Rastreamento de s Por fim, é possível gerar uma espécie de relatório customizável de rastreabilidade de um projeto, no qual figuram seus requisitos e informações acerca deles que podem ser exibidas ou omitidas, de acordo com a necessidade. 2.2 Documentação Semântica Atualmente, documentos figuram como importantes artefatos de armazenamento do conhecimento organizacional. Estimase que, em uma companhia, mais do que 80% desse conhecimento esteja na forma de documentos. Sendo assim, documentos vêm desempenhando um papel central na disseminação do conhecimento humano e continuam a ter importância na era da comunicação digital e da Internet, na qual documentos textuais armazenam grande parte do conhecimento (UREN et al., 2006; ERIKSSON, 2006). Nesse sentido, de maneira geral, o centro da memória organizacional é formado por

19 19 grandes conjuntos de documentos internos que descrevem eventos passados, resultados de pesquisas, métodos, soluções de projeto, políticas de segurança, procedimentos para operações, entre outros. Portanto, dada a constante complexidade desses repositórios de documentos, tornase importante a existência de técnicas eficientes de busca, atualização e recuperação de informações, tornandose, inclusive, um fator decisivo na estratégia de gerência de conhecimento de uma organização (ERIKSSON, 2007). Especificamente no contexto de um projeto de software, a existência de documentação é vital, podendo até mesmo implicar no sucesso ou fracasso de um projeto. Porém, apesar dos benefícios evidentes na documentação de software, esse processo é questionado por alguns desenvolvedores, pois é comum que ele seja tratado apenas como algo burocrático que impacta negativamente no andamento do projeto. Além disso, manter documentos atualizados e consistentes é uma tarefa penosa. De acordo com uma pesquisa feita por Lethbridge et al. (2003), a maior parte da documentação de software de uma companhia não é atualizada de maneira adequada, isto é, modificações realizadas em um dado instante do ciclo de vida de um projeto não são refletidas em todos documentos afetados. Sintetizando, dados de reconhecida relevância estão dispersos em um conjunto de documentos de uma organização, o que dificulta a seleção de conteúdo relevante para o apoio à tomada de decisões. Portanto, é clara a necessidade de se documentar permitindo o relacionamento e a integração dos dados encontrados em vários documentos. Além disso, tornar a interpretação de documentos passível de ser realizada por sistemas computacionais (e não somente por humanos) tem o potencial de resolver alguns dos problemas supracitados. Metadados, comumente interpretados como dados sobre dados, podem ser usados como um mecanismo para expressar semântica de um dado objetivando a facilitação da busca, recuperação, entendimento e utilização do mesmo (SICILIA, 2006). No ambiente da Internet e da Web Semântica, é comum a adição de metadados ao conteúdo exposto em páginas web, permitindo, assim, que o conteúdo disponível esteja acessível para sistemas computacionais. Nesse contexto, surge o conceito de anotação semântica que, para Kiryakov et al. (2003), tratase da utilização e geração de metadados específicos com o objetivo de permitir novos métodos de acesso à informação, estendendo os já existentes. Por ter sido cunhado em meio à visão da web semântica, geralmente o termo anotação semântica é visto como algo relacionado somente ao ato de anotar recursos encontrados na Web com metadados, mas esse contexto é mais amplo e pode ser

20 20 aplicado a documentos gerados a partir de ferramentas desktop, como o Microsoft Word ou Open Office Writer (ARANTES, 2010). Ao se adicionar anotações semânticas a um documento, se obtém uma nova categoria de documentos, referenciados como Documentos Semânticos isto é, um documento que contém informações acerca de seu próprio conteúdo e, assim, permite que processos automatizados manipulem esse conteúdo de maneira apropriada (UREN et al., 2006). Dadas as diversas fontes de dados heterogêneas existentes na Web, o grande desafio para a Web Semântica é prover uma linguagem capaz de descrever dados em diferentes sistemas de representação de conhecimento existentes na Web (BENERSLEE et al., 2001). Considerando o fato de que ontologias proveem um arcabouço para a conceituação e modelagem de conhecimento compartilhado para diversas áreas (GRUBER, 1993), muitos autores apostam em ontologias como um recurso para viabilização da Web Semântica (KIRYAKOV, 2004; BENERSLEE et al., 2001; VARGASVERA et al., 2000; UREN et al., 2006; FENSEL, 2003). Recentes pesquisas no campo da utilização de semântica no contexto de aplicações desktop têm mostrado que um número de características de tecnologias da Web Semântica são também aplicáveis para o problema da gerência de informações em documentos desktop, seja na habilidade de representar dados em um formato genérico e independente de aplicação, como na maneira de descrever os recursos com um vocabulário formalizado e de maneira flexível (CHANDL; HASLOHOFER, 2009). Sendo assim, ontologias podem exercer um papel essencial na anotação semântica em documentos em formato desktop (MACHADO, 2012) PGDS Plataforma de Gerenciamento de Documentos Semânticos A Plataforma de Gerenciamento de Documentos Semânticos (ARANTES, 2010), referenciada neste texto como PGDS, foi construída para apoiar a construção de modelos de documentos (templates) com anotações semânticas, utilizando também o sistema de controle de versão Subversion (COLLINSSUSSMAN et al., 2008), objetivando manter o histórico de alterações, não somente dos documentos semânticos gerados a partir dos modelos anotados, mas, especialmente, do conteúdo semântico extraído de cada versão de documento encontrado no repositório. De acordo com a arquitetura proposta, o conteúdo de um documento ou de sua versão é o conjunto de indivíduos que têm um mapeamento direto para conceitos e propriedades

21 21 de uma ontologia de domínio e passível de extração. Elementos sem esse mapeamento são desconsiderados. Esses indivíduos e os valores de suas propriedades estão descritos no documento na forma de trechos de texto e células de tabelas. Para cada conjunto coeso de documentos, é criada uma instância de um repositório subversion. No contexto de uma empresa de desenvolvimento de software, por exemplo, cada projeto seria um grupo coeso de documentos e teria uma instância de repositório separada. Além do repositório, a plataforma possui três módulos principais: Módulo de Anotação em Modelos de Documento (MAMD), Módulo de Extração, Versionamento e Integração de Dados (MEVID) e Módulo de Busca e Rastreabilidade (MBR), apresentados na Figura 4 e descritos a seguir. Figura 4 Visão Geral da PGDS Módulo de Anotação em Modelos de Documento (MAMD): esse módulo provê um ferramental para efetuar anotações semânticas em modelos de documentos de texto (templates) no formato ODF, baseadas em ontologias de domínio; Módulo de Extração, Versionamento e Integração de Dados (MEVID): no momento em que uma nova versão de um documento é gerada no repositório Subversion associado à PGDS, esse módulo é acionado para realizar a extração do conteúdo semântico dessa nova versão. Isso permite que sejam realizados comparativos entre os dados de cada versão de documento. Além disso, ao final do

22 22 processamento, é gerado um modelo semântico global representando a união dos conteúdos semânticos de todos os documentos existentes no repositório da plataforma; Módulo de Busca e Rastreabilidade (MBR): esse módulo provê uma gama de serviços, a saber: execução de consultas SPARQL em um repositório; visualização da evolução de um indivíduo no repositório; visualização da evolução de um indivíduo em um dado documento do repositório; visualização do histórico de alterações em um determinado documento semântico; assinatura para notificação de alteração sobre um dado indivíduo no repositório. Entretanto, percebeuse que, por ser uma plataforma geral, suas funcionalidades não exploram particularidades de um dado domínio. Nesse sentido, em (MACHADO, 2012), a PGDS foi especializada para o domínio de Engenharia de s. Na seguinte subseção são apresentadas algumas das funcionalidades providas por essa especialização PGDSReq: Uma Especialização da PGDS para o Domínio de Engenharia de s Muitas vezes, para prover um apoio mais efetivo ao domínio, é necessário explorar de modo específico a conceituação definida na ontologia, ou seja, é preciso conhecer elementos da ontologia (seus conceitos, relações e propriedades) e explorálos em funcionalidades específicas de domínio, de modo a apoiar tarefas do domínio (MACHADO, 2012). Sendo assim, em (MACHADO, 2012), a PGDS foi especializada para o domínio de Engenharia de s dando origem à PGDSReq. A seguir, são apresentadas algumas funcionalidades dessa especialização. Priorização de s: levando em consideração as dependências e os conflitos de um requisito, a PGDSReq sugere uma prioridade para o mesmo. s com prioridades não satisfatórias aparecem com uma lupa na frente do seu valor atual e, ainda, outras opções de prioridade que também não são satisfatórias aparecem em vermelho, conforme apresentado na Figura 5.

23 23 Figura 5 Sugestão de Priorização Rastreabilidade Horizontal e Vertical: são geradas matrizes de rastreabilidade considerando os relacionamentos entre requisitos e requisitos dependentes, requisitos e requisitos conflitantes, requisitos e casos de uso, requisitos e classes e, finalmente, requisitos e casos de teste. Análise de Impacto de Alteração em s: de posse do repositório e do identificador do requisito, o resultado da análise é apresentado no formato de duas árvores de rastreabilidade de impacto de alteração: vertical e horizontal. Na vertical, são apresentados os impactos nos itens que possuem relacionamento direto com o requisito, a saber: casos de uso e casos de teste para requisito. Casos de uso, por sua vez, influenciam diretamente as classes que são utilizadas para implementálos e os casos de teste definidos para testálos. Por fim, as classes ainda influenciam os casos de teste de classe. Todos esses níveis são apresentados, pois acabam sendo indiretamente influenciados pela alteração no requisito. Já na horizontal, são apresentados os requisitos relacionados, mais especificamente os requisitos que dependem do requisito em análise. Além disso, é importante também verificar os requisitos que conflitam, visto que uma alteração em um requisito pode impactar nessa relação. Na Figura 6 é apresentado o resultado de análise de impacto de mudança em um dado requisito.

24 24 Figura 6 Análise de Impacto de Mudança no RF03 Garantia da Qualidade de s: aplica a funcionalidade geral de criação de checklists ao domínio de Engenharia de s. Em outras palavras, foi definido um checklist default para esse domínio cujos itens são: Todos os requisitos possuem descrição? Todos os requisitos possuem prioridade definida? Todos os requisitos possuem algum caso de teste associado? Todos os requisitos foram alocados para algum caso de uso? Todos os casos de uso possuem descrição? Todos os casos de uso possuem ao menos um curso de enventos básico? Todos os casos de uso possuem précondição? Todos os casos de uso têm casos de teste específicos? Todos os casos de uso são implementados por alguma classe?

25 25 Notificação de Alterações no Documento de s: essa funcionalidade é responsável pelo envio de um com o resumo das alterações que ocorreram em um documento de requisitos. O corpo do possui as seguintes informações: quantidade total de requisitos no documento, requisitos adicionados e requisitos removidos. Em relação às modificações dos requisitos, elas são discriminadas por tipo: modificações nas dependências, modificações nas descrições e modificações nas descrições. Para essa última, as mesmas são agrupadas pelas mudanças de valores (baixa para alta, baixa para média, etc). Por fim, é apresentada a lista de responsáveis pelo documento. Além dessa maneira, essas informações podem ser acessadas a qualquer momento diretamente na plataforma conforme é mostrado na Figura 7. Figura 7 Relatório de Mudanças em Documento de s

26 26 Consulta de Indivíduos do Domínio: permite a consulta aos indivíduos do domínio de requisitos por tipo (, Caso de Uso, Classe e Caso de Teste), sendo apresentada a listagem de indivíduos com o link para seu estado global em seu respectivo repositório. Podese notar que a PGDSReq e ReqODE são ferramentas com funcionalidades complementares e que, se combinadas, poderiam prover um apoio mais efetivo à Engenharia de s. Assim, passouse a estudar formas de integrálas, o que levou ao estudo da área de Integração de Sistemas, foco da próxima seção. 2.3 Integração de Sistemas A integração de sistemas visa combinar aplicações de modo a formar um novo sistema que represente um todo, melhorando a sinergia e fazendo com que os objetivos da organização sejam atingidos de modo mais eficiente e produtivo (IZZA, 2009). Nessa linha, surge o conceito de interoperabilidade que envolve múltiplas entidades, se relaciona com a habilidade de interagir e, principalmente, requer pouco ou nenhum conhecimento das características específicas das entidades de interação (POKRAEV, 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). Níveis mais baixos estão relacionados com aspectos tecnológicos, enquanto níveis mas altos estão relacionados com aspectos estruturais, semânticos e comportamentais da integração (IZZA, 2009). Diversas abordagens de integração de sistemas já foram propostas, sendo em sua maioria focada principalmente em aspectos tecnológicos e estruturais. Porém, já existem algumas abordagens que consideram a semântica para integrar sistemas, como (CALHAU, 2011), (IZZA, 2009), (POKRAEV, 2009), (BOURAS, 2006), (TEKTONIDIS, 2005) e (PARK; RAM, 2004). Dentre essas, destacase a abordagem OBASI proposta em (CALHAU, 2011) por tratar o problema de integração em três camadas: dados, serviços e processos. A camada de dados referese à transferência de dados das aplicações (IZZA, 2009). A camada de serviço é responsável pela troca de mensagens entre as aplicações objetivando a garantia de uma combinação flexível de serviços entre os sistemas. Por fim,

27 27 a camada de processo busca relacionar os sistemas de modo a definir a execução de processos de negócio da organização. Seu objetivo é garantir que os sistemas interajam eficientemente a fim de apoiar o processo definido (THOMAS et. al, 1992) OBASI: OntologyBased Approach for Semantic Integration OBASI 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, provendo acordo semântico entre os sistemas no nível conceitual. Além disso, como já dito anteriormente, ela lida com as três camadas de integração: dados, serviços e processos. Para isso, modelos conceituais dos sistemas são comparados à luz de ontologias, usadas para atribuir semântica aos itens compartilhados entre os sistemas. Os modelos são compatibilizados por meio de mapeamentos entre seus elementos. Todo esse processo é independente da solução da integração. De acordo com (CALHAU, 2011), OBASI pode ser vista como um tipo de processo de desenvolvimento de software, composto de fases de levantamento de requisitos, análise, projeto, implementação, teste e implantação, conforme é apresentado na Figura 8. Figura 8 Processo de Integração Semântica (CALHAU, 2011) O processo de integração começa com a etapa de levantamento de requisitos da integração, quando os requisitos e objetivos são estabelecidos. Essa atividade é responsável por definir o cenário de integração, indicando as atividades do processo de

28 28 negócio que serão apoiadas, os sistemas a serem integrados para apoiálas e os domínios envolvidos no cenário de integração. Posteriormente, é realizada a análise da integração, que objetiva efetuar a integração semântica no nível conceitual, ou seja, estabelecer as equivalências semânticas entre sistemas e processo. A Figura 9 apresenta as atividades envolvidas nessa etapa. Figura 9 Atividades da Fase de Análise de Integração (CALHAU, 2011) Inicialmente, devese recuperar os modelos conceituais dos sistemas listados no cenário de integração, bem como do processo de negócio e, além disso, selecionar e, se necessário, integrar as ontologias de referência a serem adotadas na iniciativa de integração. Após essa fase, ocorre a realização de mapeamentos verticais entre os elementos dos modelos dos sistemas e elementos da ontologia selecionada objetivando a atribuição de semântica a esses modelos dos sistemas com base na ontologia. A seguir, devese elaborar o modelo de integração, que deve ser construído de maneira que cada elemento dos modelos conceituais dos sistemas e processo que estejam sem mapeamento vertical receba um significado. Além disso, caso seja necessária uma distinção semântica maior, esse modelo pode refinar alguns conceitos da ontologia. Por fim, é necessária a realização de mapeamentos horizontais. Nessa etapa, cada elemento dos modelos conceituais dos sistemas e do modelo de processo deve ser mapeado para um elemento correspondente do modelo de integração. Todos elementos dos modelos conceituais dos sistemas e processo devem ser mapeados. Finalmente, é realizada a atividade de projeto e implementação da integração. Porém,

29 29 OBASI não se compromete com nenhuma solução específica de integração e, nesse sentido, ela pode ser projetada e implementada de diversas formas. Em (CALHAU, 2011), é proposta a utilização de mediadores responsáveis por interligar os sistemas, já que tipicamente esses sistemas não podem ser modificados e, por isso, a integração deve ocorrer fora deles. Nesse contexto, o modelo de integração é uma importante fonte para o projeto de um mediador, pois ele captura a visão geral dos sistemas a serem integrados com base na semântica geral da integração.

30 30 3 INTEGRAÇÃO DE SISTEMAS DE APOIO À ENGENHARIA DE REQUISITOS Conforme exposto anteriormente, a Engenharia de s é um processo complexo que envolve diversas atividades, lidando com grande quantidade de informação. Portanto, o uso de ferramentas computacionais para apoiar essas atividades tende a impactar positivamente no desenvolvimento de software. Porém, percebese que, de maneira geral, há diversas ferramentas isoladas oferecendo apenas soluções parciais. Neste cenário, é comum a necessidade de repetição de esforços no sentido de manter consistentes as bases de dados dessas ferramentas. Sendo assim, visionouse a possibilidade de integrar ReqODE e PGDSReq utilizando a abordagem OBASI. 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; finalmente, na Seção 3.4 discutese o projeto e a implementação da integração. 3.1 Cenário de Integração O cenário de integração envolve os sistemas PGDSReq e ReqODE. Conforme discutido no capítulo anterior, a PGDS (Plataforma de Gerenciamento de Documentos Semânticos) apoia a construção de modelos de documentos (templates) com anotações semânticas, utilizando em adição o sistema de controle de versão Subversion (COLLINSSUSSMAN et al., 2008) com o objetivo de manter atualizado o conteúdo semântico dos documentos presentes no seu repositório. Sua especialização, a PGDSReq, adiciona funcionalidades específicas do domínio de Engenharia de s, dentre elas a geração de matrizes de rastreabilidade, a priorização de requisitos e a análise de impacto de mudanças em requisitos. ReqODE, por sua vez, encontrase dentro do ambiente de desenvolvimento de software ODE (Ontologybased Development Environment) e oferece funcionalidades de apoio à Engenharia de s, dentre elas: controle de requisitos, estabelecimento de relações de rastreabilidade e geração de relatórios. O principal objetivo da integração desses sistemas é facilitar a manutenção da

31 31 consistência das informações relativas aos requisitos de um projeto presentes em documentos vinculados à PGDSReq e na base de dados de ReqODE. Além disso, objetivase prover um apoio, ainda que parcial, a um processo de Engenharia de s utilizado por uma Instituição Implementadora do MPS.BR (SOFTEX, 2012). Esse processo é composto pelas seguintes atividades: Identificar Fornecedores de s: nessa atividade, a ser realizada no início do projeto (tipicamente no planejamento), são identificados os fornecedores de requisitos observando critérios estabelecidos previamente e envolve clientes, patrocinador do projeto e analista sendo esse último o responsável pela condução da atividade. Essa atividade deve ter como produto a lista dos fornecedores de requisitos devidamente aprovada pelo patrocinador. Obter s: após a identificação dos fornecedores de requisitos, é necessária a obtenção dos requisitos junto a eles para o projeto em questão. Sendo assim, estão envolvidos patrocinador e fornecedores de requisitos previamente identificados sob responsabilidade do analista. É de suma importância que os requisitos identificados sejam documentados na forma de Documento de s, já que esse é um mecanismo de comprovação do entendimento dos requisitos. Sendo assim, esse documento e, de acordo com a maturidade da organização, o Documento de Especificação de s devem ser produtos dessa atividade. Avaliar s: tendo em mãos os requisitos especificados, devese checar com os fornecedores de requisitos se eles estão atendendo as necessidades e expectativas e, nesse sentido, devem ser aprovados pelas partes interessadas, isto é, patrocinador e fornecedores de requisitos. Dessa maneira, esperase que após essa atividade, que ocorre sob responsabilidade do analista e do gerente de projeto, o Documento de s esteja devidamente aprovado. Definir Mecanismos de Rastreamento entre s e demais Produtos de Trabalho: em geral, mudanças em requisitos podem impactar em diversos artefatos. Portanto, para facilitar a avaliação do impacto dessas mudanças, é necessária a definição de mecanismos que permitam rastrear, tanto vertical quanto horizontalmente e, em ambos casos, de forma bidirecional, a dependência entre requisitos e demais produtos de trabalho do projeto. Essa atividade, da qual participam desenvolvedores em geral e está sob responsabilidade do gerente de

32 32 projeto, é constituída das seguintes subatividades: definição dos relacionamentos de dependência entre artefatos produzidos no projeto, definição de matrizes de rastreabilidade de requisitos, preenchimento das matrizes de rastreabilidade com as informaçõs disponíveis e a devida atualização conforme o progresso do projeto. Gerenciar Mudanças nos s: após essas atividades, é comum a necessidade de mudanças nos requisitos e, por isso, elas devem ser controladas de maneira a manter um histórico das decisões tomadas. Uma solicitação de mudança deve ser avaliada e, se aprovada, os requisitos devem ser alterados e atualizados, observando o impacto causado em outros produtos do projeto e cuidando para que não sejam inseridas inconsistências. Sendo assim, devese ter como produto documentos de s e de Especificação de s atualizados e registro de mudanças. O analista é responsável por essa tarefa que envolve desenvolvedores, patrocinador, fornecedores de requisitos e gerente de projeto. A Tabela 1 apresenta um resumo do cenário de integração definido, listando os sistemas a serem integrados, o domínio, as atividades envolvidas e os requisitos da integração. Tabela 1 Cenário de Integração SISTEMAS CENÁRIO DE INTEGRAÇÃO ReqODE e PGDSReq DOMÍNIO Domínio de s ATIVIDADES Identificar fornecedores de requisitos; Obter requisitos; Avaliar requisitos; Definir mecanismos de rastreamento entre requisitos e demais produtos de trabalho; REQUISITOS Gerenciar mudanças nos requisitos. A integração deve ocorrer por meio de um sistema mediador externo a ReqODE e PGDSReq. O sistema mediador deve prover uma funcionalidade de exportação de um projeto da PGDSReq para ReqODE e vincular seus dados. Para um projeto vinculado, o mediador deve prover as funcionalidades de ReqODE e de PGDSReq, a saber, rastreamento de requisitos, geração de matrizes de rastreabilidade e análise de impacto de alteração em requisito.

33 Modelos Utilizados na Iniciativa 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 requisitos de software (MACHADO, 2012), ontologia de domínio de referência adotada, e os modelos conceituais estruturais e comportamentais das ferramentas a serem integradas (ReqODE e PGDSReq). Para a integração de modelos comportamentais, optouse por utilizar diagramas de casos de uso ao invés de diagramas de atividades, por estes já estarem disponíveis para ReqODE Ontologia de Domínio A ontologia de domínio selecionada para essa essa iniciativa de integração foi a Ontologia de s proposta em (MACHADO, 2012). Essa ontologia foi desenvolvida em três módulos, a saber: módulo principal, que trata de requisitos, tipos de requisitos e relações entre requisitos; módulo de casos de uso, que introduz os conceitos de casos de uso, tipos de entidades e módulos e os relaciona com requisitos; e finalmente o módulo de testes, que trata de casos de testes e suas relações com os conceitos dos demais módulos da ontologia. A Figura 10 apresenta o modelo conceitual do módulo principal da ontologia. Como mostra esse modelo, um Artefato é produzido no contexto de um Projeto. é um tipo de Artefato que é ainda especializado nos subtipos Funcional, Não Funcional e Regra de Negócio. Um pode conflitar com ou depender de outros s.

34 34 Figura 10 Ontologia de s: Módulo Principal (MACHADO, 2012) A Figura 11 apresenta o modelo conceitual do módulo de casos de uso da ontologia. Como mostra essa figura, um Caso de Uso que também é um tipo de Artefato atende a um ou mais s, está alocado para um Módulo e, além disso, tem sua lógica tratada por um Tipo de Entidade. Uma Classe é um subtipo de Tipo de Entidade. Um Caso de Uso possui, ainda, um ou mais Cursos Básicos e pode possuir Cursos Alternativos. Ambos, Cursos Básicos e Alternativos são subclasses de Curso de Eventos, que, por sua vez, possui PréCondição e PósCondição (que são subclasses de Condição).

35 35 Figura 11 Ontologia de s: Módulo de Casos de Uso (MACHADO, 2012) A Figura 12 apresenta o modelo conceitual do módulo de testes da ontologia. Como mostra essa figura, um Caso de Teste é um tipo de Artefato que pode desempenhar papéis de Caso de Teste de, Caso de Teste de Caso de Uso e Caso de Teste de Classe, que são definidos para testar, Caso de Uso e Classe, respectivamente.

36 36 Figura 12 Ontologia de s: Módulo de Casos de Teste (MACHADO, 2012) Modelos Conceituais da PGDSReq O modelo conceitual estrutural da PGDSReq consiste em uma implementação da ontologia apresentada na seção anterior. Por isso, podemos considerar a ontologia de referência como o modelo dessa ferramenta. A Figura 13 apresenta o modelo de casos de uso da PGDSReq, contendo as funcionalidades de apoio à Engenharia de s e omitindo as funcionalidades de propósito geral da PGDS.

37 37 Figura 13 Modelo de Casos de Uso da PGDSReq A seguir, os casos de uso da Figura 13 são descritos sucintamente. Analisar Impacto de Alteração em : ao selecionar um requisito, são apresentados os requisitos que dele dependem e, ainda, os que com ele conflitam. Além disso, são apresentados artefatos que se relacionam direta ou indiretamente com o requisito selecionado. Preencher Checklist: tratase da execução de um checklist default para o domínio de Engenharia de s. Priorizar s: com base nos relacionamentos de dependência de um requisito, são identificados os que possuem prioridade potencialmente problemática e, para esses, são sugeridas novas prioridades. Consultar Indivíduos: consulta aos indivíduos específicos do domínio de Engenharia de s (, Caso de Uso, Classe e Caso de Teste), apresentando suas propriedades. Gerar Matrizes de Rastreabilidade: de acordo com a seleção, são apresentadas matrizes de rastreabilidade entre requisitos (dependência e conflito), requisitos e casos de uso, requisitos e classes e, ainda, requisitos e casos de teste.

38 Modelos Conceituais de ReqODE ReqODE é organizado em três pacotes principais: Conhecimento:, que trata de categorias de requisitos; UML, que trata de alguns elementos da UML; e Gerência s, que é o pacote principal da ferramenta, responsável pelas funcionalidades envolvendo requisitos e, também, o relacionamento desses com componentes dos outros pacotes. A Figura 14 apresenta o modelo de classes do pacote Conhecimento: de ReqODE, na qual Categoria tratase de uma categorização mais detalhada de um Tipo ( Funcional, Não Funcional ou Regra de Negócio). Uma categoria de requisito pode possuir uma supercategoria e várias subcategorias. A Figura 15 mostra o diagrama de casos de uso deste mesmo pacote, o qual possui um único caso de uso que permite o cadastro (abrangendo inclusão, alteração, consulta e exclusão) de categorias de requisitos. Figura 14 Modelo Estrutural do pacote Conhecimento: Figura 15 Diagrama de Caso de Uso do pacote Conhecimento::

39 39 A Figura 16 apresenta o diagrama de classes do pacote UML. Como mostra essa figura, um Pacote pertence a um Projeto e pode possuir Casos de Uso e Classes associados. Além disso, uma Classe trata a lógica de um Caso de Uso. Figura 16 Modelo Conceitual referente ao Pacote UML A Figura 17 mostra o diagrama de casos de uso do pacote UML, o qual envolve apenas as operações CRUD (Create, Read, Update, Delete) de pacotes, casos de uso e classes. Figura 17 Diagrama de Caso de Uso referente ao pacote UML A Figura 18 mostra o diagrama de classes do pacote Gerência s. Como mostra esse diagrama, um pertence a um Projeto e pode conflitar ou depender de outros requisitos. Ele pode ser tratado por Casos de Uso e ser alocado a Pacotes. Além disso, um possui Recursos Humanos responsáveis e interessados e é tratado em diferentes Artefatos.

40 40 Figura 18 Modelo Estrutural referente ao pacote Gerência s A Figura 19 mostra o diagrama de casos de uso do pacote Gerência s. Figura 19 Diagrama de Caso de Uso do Pacote Gerência de s

41 41 A seguir, temos uma descrição sucinta dos casos de uso expostos no diagrama. Cadastrar : caso de uso cadastral que permite inclusão, alteração, consulta e exclusão de requisitos de um projeto. Definir Relações de Rastreabilidade: trata da definição de relações entre requisitos, casos de uso, classes e artefatos. Rastrear s: consulta de requisitos mais abrangente que permite a filtragem por casos de uso, classes, pacotes, artefatos, responsáveis ou interessados; Gerar Relatórios de Rastreabilidade: trata da geração de relatórios que possuem informações acerca de cada requisito de um projeto. Após ter em mãos os modelos conceituais estruturais dos sistemas a serem integrados, passase à etapa de mapeamentos verticais Mapeamentos Verticais Os mapeamentos verticais objetivam tornar explícitas as conceituações dos sistemas tomando como base as ontologias de referência escolhidas. Logo, tais relações ocorrem entre os modelos conceituais dos sistemas e as ontologias selecionadas para a integração. Por meio deles, é atribuída a semântica aos conceitos 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 ReqODE e da PGDSReq com os conceitos da ontologia de referência selecionada (nesse sentido, é possível perceber que, já que o modelo conceitual da PGDSReq e a ontologia selecionada são equivalentes, temos duas colunas com correspondência direta). Cada linha da tabela é composta por um conceito da ontologia, o conceito de ReqODE relacionado e o conceito da PGDSReq relacionado.

42 42 Tabela 2 Mapeamentos Verticais ONTOLOGIA ReqODE PGDSReq Projeto Projeto Projeto Artefato Artefato Artefato Funcional.tipo == Funcional Funcional NãoFuncional.tipo == NãoFuncional NãoFuncional Regra de Negócio.tipo == Regra Regra de Negócio de Negócio Módulo Pacote Módulo Caso de Uso CasoUso Caso de Uso Tipo de Entidade Classe Tipo de Entidade Classe Classe Condição Condição PréCondição PréCondição PósCondição PósCondição Curso de Eventos Curso de Eventos Curso Básico Curso Básico Curso Alternativo Curso Alternativo Caso de Teste Caso de Teste Caso Teste Caso Teste Caso Teste Caso de Uso Caso Teste Caso de Uso Caso Teste Classe Caso Teste Classe Por meio dos mapeamentos verticais, obtemos relações mais gerais entre os conceitos dos sistemas. De acordo com a Tabela 2, Projeto (ReqODE) foi mapeado para Projeto (Ontologia), afinal, ambos conceitos representam um esforço temporário para produzir um resultado exclusivo. Artefato (ReqODE) foi mapeado para Artefato (Ontologia), porém é importante ressaltar que, no contexto de ReqODE, CasoUso, Classe e não são consideradas subclasses de Artefato diferentemente do que acontece na Ontologia de s e, por conseguinte na PGDSReq. (ReqODE) foi mapeado para (Ontologia), já que ambos os conceitos representam a descrição dos serviços que devem ser fornecidos por um sistema e suas restrições operacionais (SOMMERVILLE, 2007). CasoUso (ReqODE), por sua vez, foi mapeado para Caso de Uso (Ontologia), pois ambos são abstrações de funcionalidades do sistema. Classe

43 43 (ReqODE) foi mapeado para Classe (Ontologia), já que ambas tratam de um conjunto de objetos que apresentam características semelhantes. Pacote (ReqODE) foi mapeado para Módulo (Ontologia), pois representam um grupo de elementos relacionados. Após a realização dos mapeamentos verticais dos conceitos dos sistemas com a ontologia, foram realizados os mapeamentos verticais das relações entre conceitos. Ou seja, associamos os relacionamentos correspondentes da ontologia de referência e do modelo conceitual de ReqODE. Naturalmente, como o modelo conceitual de PGDSReq equivale à ontologia selecionada para essa iniciativa de integração, tornase desnecessária a realização do mapeamento vertical entre seus relacionamentos. Esses mapeamentos são apresentados na Tabela 3. Tabela 3 Mapeamentos Verticais de Relacionamentos em ReqODE ONTOLOGIA ReqODE CONCEITO RELAÇÃO CONCEITO Caso de Uso¹ produzido em Projeto Classe¹ produzido em Projeto Módulo¹ produzido em ¹ CONCEITO RELAÇÃO CONCEITO CasoUso pertence a² Pacote Pacote pertence a² Projeto Classe pertence a² Pacote Pacote pertence a² Projeto Projeto Pacote Pertence a Projeto produzido em Projeto Pertence a Projeto conflita com conflita com depende de depende de Caso de Uso atende CasoUso trata Caso de Uso alocado para Módulo CasoUso pertence a Pacote Tipo de trata a lógica Caso de Uso Classe trata CasoUso Entidade descrita em Curso relativo a Curso Básico CasoTeste definido para testar Caso de Uso Classe Alternativo CasoTeste Caso definido para de Uso testar CasoTeste definido para Classe testar ¹ O relacionamento produzido em está explícito no modelo na classe Artefato, porém, Caso de Uso, Classe, Módulo e são suas subclasses. ² Em ReqODE, CasoUso e Classe não estão associados diretamente a Projeto, entretanto, eles se relacionam com Pacote, que, por sua vez, relacionase com Projeto.

44 Modelo de Integração Após a realização dos mapeamentos verticais, fazse necessário o desenvolvimento de um modelo de integração. Tal modelo serve como referência para atribuição semântica em uma iniciativa de integração, levando em consideração características particulares da mesma. Tendo em vista a grande quantidade de classes, o modelo foi dividido em quatro módulos, a saber: módulo de requisitos, módulo de equipe, módulo de casos de uso e módulo de casos de teste. O módulo de requisitos, apresentado na Figura 20, trata basicamente da estrutura que há em torno de. Figura 20 Modelo de Integração: Módulo de s A Figura 21 apresenta o módulo de equipe, que diz respeito aos conceitos de equipe e alocação de equipe vindos de ReqODE. Figura 21 Modelo de Integração: Módulo de Equipe O módulo de caso de uso é apresentado na Figura 22 e é altamente compatível com o módulo de caso de uso da ontologia de referência selecionada.

45 45 Figura 22 Modelo de Integração: Módulo de Caso de Uso Finalmente, temos o módulo de caso de teste que apresenta as classes e relacionamentos pertinentes a este contexto, mostrados na Figura 23. Figura 23 Modelo de Integração: Módulo de Caso de Teste

46 Mapeamentos Horizontais Após a criação do modelo de integração, realizamos a etapa de mapeamentos horizontais entre conceitos, da forma como é mostrada na Tabela 4. Tabela 4 Mapeamentos Horizontais entre Conceitos MODELO DE INTEGRAÇÃO ReqODE PGDSReq Projeto Projeto Projeto Artefato Artefato Artefato Funcional.tipo == Funcional Funcional NaoFuncional.tipo == NãoFuncional NãoFuncional RegraDeNegocio.tipo == Regra Regra de Negócio de Negócio Modulo Pacote Módulo CasoDeUso CasoUso Caso de Uso TipoEntidade Classe Classe Tipo de Entidade Classe Condição Condição PreCondição PréCondição PosCondição PósCondição CursoEventos Curso de Eventos CursoBasico Curso Básico CursoAlternativo Curso Alternativo CasoTeste Caso de Teste CasoTeste CasoTeste CasoTesteCasoUso CasoTeste Caso de Uso CasoTesteClasse CasoTeste Classe Categoria Categoria RecursoHumano RecursoHumano AlocacaoEquipe AlocacaoEquipe Equipe Equipe Esses mapeamentos são responsáveis por tratar aspectos particulares da iniciativa de integração, baseiamse nos mapeamentos verticais e tendem a mantêlos. Nesse sentido, as linhas que contém mapeamentos fundamentados em mapeamentos verticais apresentam fundo cinza. Após feito o mapeamento horizontal entre conceitos, devese mapear os relacionamentos. As Tabelas 5 e 6 apresentam os mapeamentos horizontais de relacionamentos.

47 47 Tabela 5 Mapeamentos Horizontais de Relacionamentos em ReqODE MODELO DE INTEGRAÇÃO CONCEITO RELAÇÃO ReqODE CONCEITO CONCEITO RELAÇÃO CONCEITO conflita com conflita com depende de depende de Categoria classifica Categoria de classifica Artefato trata Artefato trata Recurso responsável por Recurso responsável por Humano Recurso Humano interessado em Recurso Humano interessado em trata Humano Caso de Uso atende CasoUso CasoTeste testa possui Alocação de Recurso Recurso Humano Alocação de referese a Equipe Humano Equipe Alocação Equipe possui Alocação Equipe de referese a Equipe pertence a Projeto Equipe Equipe pertence a Projeto Artefato UML produzido em Projeto Caso de Uso Classe a lógica CasoUso CasoTeste Caso testa Equipe de Uso CasoTeste testa Classe Tipo de trata a lógica Caso de Uso Entidade descrita em Caso de Uso alocado para Módulo Caso de Uso possui Curso *Classe trata descrita em CasoUso de pertence a Pacote Eventos Curso de possui PréCondição de possui PósCondição Curso Básico Eventos Curso Eventos Curso Alternativo relativo a de

48 48 Tabela 6 Mapeamentos Horizontais de Relacionamentos em PGDSReq MODELO DE INTEGRAÇÃO CONCEITO RELAÇÃO PGDSReq CONCEITO CONCEITO RELAÇÃO CONCEITO conflita com conflita com depende de depende de de classifica Artefato trata Recurso Humano responsável por Recurso Humano interessado em Caso de Uso atende Caso de Uso atende CasoTeste testa CasoTeste testa Recurso Humano possui Alocação Equipe Alocação Equipe de referese a Equipe Categoria Equipe pertence a Projeto Artefato UML produzido em Projeto Artefato produzido em Projeto CasoTeste Caso de Uso testa Caso de Uso CasoTeste Caso de Uso testa Caso de Uso CasoTeste Classe testa Classe CasoTeste Classe testa Classe Tipo Entidade de trata a lógica Caso de Uso descrita em Caso de Uso alocado para Módulo Caso de Uso possui Curso Eventos de Tipo Entidade Caso de Uso de Caso de Uso de trata a lógica Caso de Uso descrita em alocado para Módulo possui Curso Eventos Curso Eventos de possui PréCondição Curso Eventos de possui PréCondição Curso Eventos de possui PósCondição Curso Eventos de possui PósCondição Curso Básico Curso Alternativo Curso Alternativo relativo a relativo a de Curso Básico 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 ReqODE e PGDSReq se comuniquem, é necessário que os elementos

49 49 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 PGDSReq. Figura 24 Mediador: responsável pela comunicação entre ReqODE e PGDSReq O mediador também é responsável por disponibilizar algumas das funcionalidades nativas dos sistemas a serem integrados, a saber: Rastreamento de s, 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 PGDSReq, e alimentando o banco de dados de ReqODE. Como esperado, o modelo estrutural do mediador é fortemente baseado no modelo de integração, diferenciandose dele em pequenos aspectos no módulo de requisitos, conforme apresentado na Figura 25.

50 50 Figura 25 Modelo Estrutural do Mediador Para explicitar se um projeto do mediador é uma referência para um projeto da PGDSReq, 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 PGDSReq, 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 PGDSReq. 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. Notase também que, enquanto no modelo de integração os conceitos de requisito funcional, requisito nãofuncional e regra de negócio apareciam na forma de

51 51 especialização da classe, aqui esses conceitos são obtidos do relacionamento da classe com o tipo enumerado Tipo. Esta solução de projeto foi adotada, uma vez que as subclasses (Funcional, NaoFuncional e RegraDeNegocio) não apresentavam nenhuma propriedade distinta da superclasse (). Para implementar o mediador foram utilizados a linguagem de programação Java, o banco de dados relacional PostgreSQL e os frameworks Hibernate (mapeamento objetorelacional), 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 baseiase 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, optouse por adotar o padrão ModeloVisãoControlador (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 PGDSReq, 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 PGDSReq, 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 PGDSReq para ReqODE e estabelecer um vínculo entre eles. A Figura 26 apresenta a interface da funcionalidade de exportação de projetos. É

52 52 importante ressaltar que essa transferência de dados ocorre somente no sentido da PGDSReq 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. Figura 26 Interface Exportar Projeto 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 PGDSReq 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 PGDSReq, 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

53 53 Quando essa listagem de projetos é exibida, é verificado se algum projeto vinculado sofreu alguma alteração em PGDSReq 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. Figura 28 Mensagem de Alteração em Projeto Vinculado 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 PGDSReq. 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 PGDSReq 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 PGDSReq.

54 54 Figura 29 Janela de Visualização de Há ainda, as funcionalidades herdadas dos sistemas sendo integrados que, portanto, trabalham de maneira similar. Nativa da PGDSReq, 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.

55 55 Figura 30 Matriz de Rastreabilidade de Dependência de s A funcionalidade de análise de impacto de alteração em requisito, assim como ocorre na PGDSReq, 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 56 Figura 31 Análise de Impacto de Alteração em RF01 O mediador conta, ainda, com o rastreamento de requisitos, funcionalidade originária de ReqODE. Tratase 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.

57 57 Figura 32 Rastreamento de s pelo Caso de Uso Cadastrar_