uma ferramenta colaborativa de edição de mapas...

Uma Ferramenta Colaborativa de Edição de Mapas Conceituais para a Especificação de Requisitos de Software

Pablo Dall'Oglio, João Pablo S. da Silva, Sérgio Crespo C. S. Pinto, João C. Gluz

Programa Interdiciplinar de Computação AplicadaUniversidade do Vale do Rio dos Sinos (UNISINOS) – São Leopoldo, RS - Brasil

{pablo.dalloglio, jpabloss}@gmail.com, {crespo,jcgluz}@unisinos.br

Resumo. Na fase de elicitação de requisitos de software, os conceitos são construídos pela troca de muitas informações entre analistas e usuários. Este processo intenso de comunicação torna essencial o uso de uma ferramenta que suporte o trabalho colaborativo, bem como a adoção de uma técnica de representação de conhecimento que seja de fácil compreensão, como são os mapas conceituais. Entretanto mapas conceituais não possuem semântica suficiente para serem utilizados como artefatos de design. Este artigo apresenta uma ferramenta colaborativa de edição de mapas conceituais para especificação de requisitos com suporte de agentes voltados a prover maior semântica aos conceitos, de forma que estes possam gerar artefatos de design.

1. IntroduçãoO sucesso de um software está diretamente relacionado a quanto ele atende os propósitos para os quais foi projetado [Nuseibeh 2000]. O papel da engenharia de requisitos é descobrir estes propósitos desde o reconhecimento do problema a ser resolvido até a sua especificação detalhada. Várias técnicas foram desenvolvidas para tal, como: cenários, casos de uso, brainstorming e prototipação [Paetsch 2003].

É de senso comum que a qualidade final de um software é diretamente afetada pela qualidade de seus requisitos. Entretanto, expressar estes requisitos de forma concisa, completa e consistente continua sendo um problema, cuja origem geralmente éde comunicação [Zaff 1991]. A complexidade da comunicação reforça a necessidade da utilização de ferramentas que conduzam este processo colaborativamente [Lang 2001]. Além disto, é de grande importância a adoção de técnicas de representação de conhecimento de fácil compreensão que possam ser utilizadas tanto por analistas quanto por usuários para expressar suas ideias. Dentre estas técnicas, destacam-se os mapas conceituais, que permitem organizar os conceitos de forma similar a maneira com a qual o ser humano organiza suas ideias. Entretanto sua notação simples é desprovida de maior semântica, o que dificulta a utilização do mesmo em etapas posteriores de projeto, como na fase de design, que exige um rigor maior na definição de conceitos.

Assim, este artigo apresenta uma ferramenta de edição de mapas conceituais para especificação de requisitos de software baseada em Web Services e suportada por agentes de software voltados a prover maior semântica aos conceitos, de forma que estes possam gerar artefatos de design. Para tal, a seção 2 apresentará um breve estudo sobre mapas conceituais, colaboração, Web Services e agentes, a seção 3 apresentará a proposta de trabalho, a seção 4 desenvolverá um modelo de análise e projeto, a seção 5 apresentará o protótipo funcional e a seção 6 realizará as conclusões.

��

��

2. Contextualização

2.1. Mapas conceituaisDe acordo com Zaff [Zaff 1991], a técnica de “Mapas Conceituais” foi desenvolvida por Joseph Novak em sua pesquisa na universidade de Cornell, nos anos 1970, como uma forma de facilitar a transferência de informações do professor para o aluno. Um mapa conceitual, como o demonstrado na figura 1, é um grafo formado por nodos que representam conceitos e arcos que representam relacionamentos, permitindo representar a estrutura do conhecimento graficamente.

Figura 1. Mapa conceitual

Para Zaff [Zaff 1991], os mapas conceituais oferecem ao analista uma ferramenta que representa o conhecimento com maior fidelidade do que outras ferramentas para aquisição de conhecimento, ao passo que se liberta das restrições de linearidade encontradas na linguagem falada e escrita, além de fornecer um formalismo muito próximo à forma como o ser humano organiza mentalmente as ideias.

Ferramentas gráficas como a UML são amplamente utilizadas como notação padrão em projetos de software. Entretanto existe uma transição muitas vezes empírica entre análise e projeto. Uma mesma análise pode ser interpretada de diferentes formas, gerando assim, diferentes projetos de software. Enquanto o usuário participa ativamente da etapa de análise, validando os requisitos por ele mesmo gerados, os formalismos gráficos das ferramentas de design são voltados geralmente ao analista, tornando difícil a interpretação e consequentemente a validação dos requisitos por parte do usuário.

Os mapas conceituais se constituem em uma técnica de representação do conhecimento que pode ser utilizada para a análise e que, devido à sua semântica simples, podem ser validados pelo próprio usuário. Entretanto, devido à liberdade de representação dos conceitos, para que os mapas conceituais possam ser utilizados para a etapa de design em projeto de software, é necessário adicionar certos formalismos ao mesmo, por meio de regras de classificação (taxonomia). Regras de classificação foram inicialmente sugeridas por Snyder [Snyder 1991], como se pode ver na tabela 1.

Tabela 1. Categorias de relacionamentos

Categoria Exemplo

Analogia é como

Casual causa, é causado, resulta de

Definição é um, é equivalente, definido por

Todo-Parte tem, contém inclui

��

��

2.2. ColaboraçãoO processo de especificação de requisitos de software envolve uma gama de colaboradores com os mais diversos papéis. Em decorrência da complexidade envolvida na comunicação, é fundamental que o seu gerenciamento seja um processo colaborativo suportado por uma ferramenta informatizada [Lang 2001].

Apesar da importância do trabalho colaborativo ser largamente reconhecida, poucas ferramentas para engenharia de requisitos suportam esta abordagem, sendo a maioria focada no trabalho individual. Mesmo entre aquelas ferramentas que oferecem suporte ao trabalho colaborativo, nem todas são adequadas para o uso em equipes multidisciplinares e distribuídas [Lang 2001].

Para [Lang 2001], há muitas ferramentas no mercado que supostamente suportam o processo de gerenciamento de requisitos. Entretanto, para que seja possível conduzir uma avaliação, é necessário identificar quais são os requisitos de uma ferramenta colaborativa para gerenciamento de requisitos. Conforme Lang, uma ferramenta colaborativa deve possuir as seguintes características:

● Suportar trabalho distribuído;● Manter repositório compartilhado de requisitos;● Suportar protocolos de comunicação com outras ferramentas;● Manter arquivo das versões de mudanças;● Permitir mecanismo para autenticação e aprovação de mudanças.

2.3. Web servicesPara construir a ferramenta proposta, será necessária a adoção de uma tecnologia que permita a troca de informações para implementação da colaboração. A tecnologia escolhida foi Web Services. Web Services são serviços disponibilizados pela internet que permitem interoperabilidade entre aplicações por meio da entrega de serviços e a comunicação entre aplicações [Vaughan 2002]. Estas aplicações podem ser descritas e invocadas pela internet para utilização imediata, ou composição de novos serviços [Hansen 2002] integrando tudo por meio de padrões abertos e conhecidos como XML, SOAP e WSDL [Chung 2003].

Na figura 2, tem-se uma visão geral do funcionamento de Web Services. O requerente é a aplicação que interage com o serviço [Hansen 2002], enviando uma requisição encapsulada conforme o protocolo SOAP para o servidor. A aplicação servidora processa esta requisição, de acordo com suas regras internas de negócio e retorna a resposta por meio de um pacote XML pelo protocolo SOAP [Chung 2003].

Figura 2. Arquitetura dos Web Services

��

��

2.4. AgentesA utilização de sistemas multi-agentes tem crescido e vem sendo considerado um novo paradigma de computação. Um agente é uma entidade de software autônoma, capaz de perceber o ambiente que o cerca e responder à mudanças, usando sua própria experiência ou conhecimento sobre este ambiente. O crescimento deste tipo de sistema contribuiu para o surgimento da Engenharia de Software Orientada a Agentes (ESOA). Um agente deve ser autônomo, podendo decidir o que fazer para atingir algum objetivo pré-determinado, e deve interagir socialmente com outros agentes, executando atividades de cooperação, coordenação e negociação [De Loach 2000].

3. PropostaO objetivo do presente trabalho é desenvolver uma ferramenta para edição colaborativa de mapas conceituais baseada em Web Services e suportada por agentes reativos, de forma a auxiliar o usuário na especificação de requisitos de software. Para tal, será necessário desenvolver uma arquitetura de agentes, que por sua vez irão auxiliar o usuário a classificar os conceitos e relacionamentos do mapa, provendo maior semântica ao mesmo, de maneira que se possa extrair a partir do mapa conceitual, estruturas de design. Desta forma, estes agentes terão como objetivos:

• Auxiliar o usuário na qualificação dos conceitos de mapa conceitual;• Auxiliar o usuário na qualificação dos relacionamentos do mapa conceitual;• Mapear os conceitos e relacionamentos do mapa para uma estrutura de design;• Sugerir ao usuário, classificações baseada em padrões já existentes.

Conforme pode ser visto na figura 3, a ferramenta será dividida entre um módulo cliente, responsável pela edição gráfica (à direita) e um módulo servidor (à esquerda), que armazenará os mapas conceituais. A arquitetura da aplicação será exposta na seção 4. Ambos módulos se comunicarão via Web Services, sendo que os agentes integrarão o módulo cliente. Como a ferramenta é colaborativa, diversas instâncias do módulo cliente poderão estar em execução ao mesmo tempo, editando o mesmo mapa conceitual. A atualização dos mapas será realizada por métodos dos Web Services.

Figura 3. Edição colaborativa de mapas conceituais

Conforme classificação sugerida por Kaiya [Kaiya 2006], os agentes irão auxiliar o usuário a qualificar os conceitos e relacionamentos, no sentido de dar maior caracterização aos mesmos. A qualificação será realizada por agentes reativos de interface que irão questionar o usuário sobre a natureza das entidades do mapa conceitual. Na tabela 2 podem ser vistos alguns resultados de qualificações que podem ser realizadas pelos agentes, por meio de questionamentos ao usuário.

��

��

Tabela 2. Qualificação de conceitos e relacionamentos

Qualificação de Conceitos Qualificação de Relacionamentos

Conceito Qualificação Relacionamento Qualificação

Livro Objeto Contém Composição

Membro Ator Tipo de Herança

A figura a seguir contém um mapa conceitual com alguns conceitos já classificados. Cada conceito possui um termo que o classifica localizado próximo a ele, como: <<actor>>, <<property>>, <<function>> ou <<object>>.

Figura 4. Mapa conceitual com conceitos classificados

Após a qualificação dos conceitos e relacionamentos, um outro agente será capaz de transformar o mapa conceitual em uma notação técnica de design, como um diagrama de classes UML representado por um arquivo XMI. Para tal, certos padrões de mapeamento terão de ser respeitados. Na tabela que segue, são exibidos alguns exemplos de mapeamento baseados em qualificações realizadas pelo usuário.

Tabela 3. Tabela de mapeamentos

Conceito Relacionamento Conceito Resultado

Objeto Tipo de Objeto Herança

Objeto Parte de Objeto Composição

Com base na classificação do usuário e dos padrões de mapeamento, será gerado um diagrama de classes UML representado pelo padrão XMI. Desta forma, o mapa conceitual será representado por meio de relacionamentos entre classes de projeto.

Figura 5. Diagrama UML a partir do mapa conceitual

��

��

4. MetodologiaA arquitetura proposta será desenvolvida na metodologia MaSE, criada por De Loach [De Loach 2000], que se caracteriza por ser independente de arquitetura, linguagem de programação e procura cobrir todo o ciclo de vida do desenvolvimento de um sistema multi-agente, desde a análise, projeto até o seu desenvolvimento. Na metodologia MaSE, os agentes são vistos como processos de software que interagem uns com os outros para atingir os objetivos do sistema. Além disto, a metodologia apresenta um conjunto de diagramas que permitem retratar com um grande grau de fidelidade os agentes reativos. Nesta seção será abordada a análise e o projeto da ferramenta proposta.

4.1. AnálisePara De Loach [De Loach 2000], a primeira fase da metodologia MaSE, trata da descoberta dos objetivos, baseada na especificação inicial do sistema. O resultado é um conjunto de metas estruturadas de forma hierárquica, como exibido na figura a seguir.

Figura 6. Objetivos do sistema

O principal objetivo do sistema é auxiliar o usuário no processo de análise e projeto do sistema. Este objetivo é então dividido em outros, que são: auxiliar na especificação de requisitos e permitir gerar um projeto de design.

Para auxiliar na especificação de requisitos, agentes irão trabalhar na qualificação dos conceitos e dos relacionamentos do modelo (conforme os padrões vistos anteriormente) questionando o usuário, e também sugerindo qualificações, conforme taxonomia sugerida por Kaiya [Kaiya 2006]. Para permitir gerar um projeto de design, agentes irão mapear os conceitos e relacionamentos classificados do mapa conceitual para uma especificação de design orientada a objetos, neste caso, o padrão XMI (XML Metadata Interchange).

Para De Loach [De Loach 2000], o próximo passo na metodologia é transformar a hierarquia de objetivos em papéis. Os papéis, que podem ser vistos na figura a seguir, representam os objetivos do sistema durante a etapa de projeto. No modelo, a representação do usuário é dada pelo papel User, enquanto que papel para controlar a interface com o usuário se chamará InterfaceController. Dois agentes foram criados para trabalhar os aspectos relativos à análise: ConceptHelper, que irá auxiliar o usuário na qualificação dos conceitos e LinkHelper, que irá auxiliar o usuário na qualificação dos relacionamentos. O agente DesignHelper irá representar o papel do projetista, e portanto deverá saber transformar o modelo do mapa conceitual em um modelo de design UML. Para tal, ele conversará com os agentes de análise e registrará os padrões de mapeamento em um outro agente, chamado PatternBase. Abaixo de cada papel constam os objetivos atendidos.

��

��

Figura 7. Papéis do sistema

Após a descoberta dos objetivos do sistema, pode-se definir os seus casos de uso. Para De Loach [De Loach 2000], os casos de uso de um sistema multi-agentes representam as conversações entre os agentes. Eles são narrativas descritivas de uma determinada sequência de eventos construídos com base nos requisitos iniciais. A seguir, é apresentado o caso de uso para criação de um novo conceito.

Tabela 4. Criação de novo conceito

1.Usuário (User) cria novo conceito (newConcept);2.InterfaceController notifica ConceptHelper sobre a criação (conceptCreation);3.ConceptHelper solicita InterfaceController pedir características (askFeatures) do conceito

ao usuário, para que se proceda com a sua qualificação;4.Usuário responde questionamento para InterfaceController (Answer);5.InterfaceController passa para ConceptHelper a qualificação do conceito (qualifyConcept);6.ConceptHelper aciona DesignHelper, solicitando que este classifique o conceito com base

em seus padrões (classifyConcept);7.DesignHelper registra o padrão de mapeamento na base de padrões (PatternBase).

O caso de uso descrito na tabela 4 é representado na forma de um diagrama de seqüência exibido na figura 8, que demonstra a interação entre os agentes por meio da seqüência de troca de mensagens entre os diferentes papéis.

Figura 8. Qualificação de um conceito

O próximo caso de uso procura demonstrar como o sistema se comporta quando do estabelecimento de um relacionamento entre dois conceitos do modelo. Neste caso, antes de questionar o usuário sobre as características que qualificam a relação, este agente vasculha a base de padrões perguntando ao agente PatternBase se já existem outros relacionamentos com o mesmo nome, a fim de dispensar o usuário da caracterização do mesmo. Caso a classificação não tenha sido encontrada, o usuário é questionado sobre suas características, para que sejam mapeadas na base de padrões.

��

��

Tabela 5. Estabelecer novo relacionamento

1.Usuário (User) cria uma ligação entre conceitos (newLink);2.InterfaceController notifica LinkHelper (linkConcepts);3.LinkHelper solicita à PatternBase, pela busca do relacionamento na base de padrões

(PatternBase) para verificar se já existe uma ocorrência (searchPattern);4.Caso o relacionamento tenha sido encontrado, LinkHelper aciona InterfaceController, para

que o mesmo exiba a sugestão de padrão para o usuário (suggestLink);5.Caso o relacionamento não tenha sido encontrado, LinkHelper notifica InterfaceController,

para que o mesmo solicite as características do relacionamento para o usuário (askFeatures);6.O usuário responde qualificando o relacionamento com suas características (Answer);7.InterfaceController passa para LinkHelper as informações necessárias para qualificar o

relacionamento (qualifyLinnk);8.LinkHelper aciona DesignHelper, solicitando que este classifique o relacionamento com base

em seus padrões (classifyLink);9.DesignHelper registra o padrão de mapeamento deste relacionamento na base de padrões

(registerPattern).

A figura 9 exibe o caso de uso descrito na tabela 5.

Figura 9. Qualificação de um relacionamento

Conforme a metodologia MaSE, com base na definição dos casos de uso, pode-se reescrever o modelo de papéis em um formato mais refinado, contendo as atividades realizadas e os agentes que participam de cada atividade. Neste modelo, que pode ser visto na figura 10, além de cada papel ser responsável pela implementação de um ou mais objetivos, eles são representados juntamente com as atividades que desempenham. Enquanto os papéis são representados por retângulos, as atividades são representadas por elipses. Desta forma, é possível ter uma percepção do fluxo de atividades do sistema, bem como quais agentes participam de quais atividades.

Figura 10. Diagrama refinado de papéis

��

��

4.2. ProjetoNesta seção, será apresentado o projeto da ferramenta, que é desenvolvida em linguagem PHP com a biblioteca gráfica Gtk. A ferramenta possui dois módulos: um servidor e outro cliente. O módulo servidor é constituído pela classe MapServer, que pode ser visualizada na figura 11, que é criada por um mecanismo de herança a partir da classe SoapServer, que é a classe nativa em PHP para implementar um servidor de Web Services utilizando o protocolo SOAP. A classe MapServer possui métodos como createMap, responsável por criar um mapa conceitual no servidor, registerAction para registrar uma ação (criar, mover e excluir conceito) em determinado mapa. O método isOnLine indica se o servidor está ativo, o método getAction retorna uma determinada ação realizada no mapa, o método getLastAction retorna a última ação desempenhada por um usuário no mapa conceitual e o método getScriptNames retorna todos mapas conceituais hospedados no servidor.

O módulo cliente da aplicação é formado pela classe Application, que pode ser vista na figura 11, criada pelo mecanismo de herança a partir da classe GtkWindow, que representa uma janela na biblioteca gráfica Gtk. A classe Application representa a janela principal da aplicação e tem como atributos o nome do mapa em edição ($mapScript) e uma instância da classe SoapCliente ($mapServer), classe nativa do PHP que disponibiliza uma interface para métodos localizados em um servidor SoapServer. Além disto, a classe Application possui os métodos connect, responsável por conectar em um servidor SoapServer, o método registerAction, responsável por registrar uma ação (criar, mover, excluir) do usuário sobre algum conceito do mapa conceitual e o método getMapServer que retorna para a aplicação a instância em uso do MapServer. Futuramente espera-se adicionar métodos que tratem da resolução de conflitos, como mais de um usuário tentando mover o mesmo objeto, o que ainda não é tratado.

Figura 11. Arquitetura de comunicação da aplicação

O módulo cliente da aplicação é formado pelo relacionamento entre três classes: Application, Panel e Node, que por sua vez, são criadas pelo mecanismo de herança a partir de classes nativas do Gtk (GtkWindow, GtkFixed e GtkEventBox). A classe Application, cujo funcionamento já foi parcialmente explicado anteriormente, disponibilizará uma janela para que o usuário da aplicação possa interagir com a mesma. Além dos métodos já definidos anteriormente, ela possuirá os métodos onNew, onOpen, onSave e onClose, que manipularão o arquivo do mapa conceitual.

A classe Panel, instância de GtkPanel, representa uma área da interface gráfica onde os objetos podem ser posicionados em coordenadas absolutas. O objeto Panel é contido pelo objeto Application. Além dos métodos nativos de posicionamento de objetos, possui os métodos: addNode, para adicionar um nodo (conceito) no painel, o método delNode, para excluir um nodo, o método movNode para movimentar um nodo, o método lnkNode para relacionar dois nodos (conceitos).

��

��

Figura 12. Diagrama de classes do módulo cliente

A classe Node representará um nodo (conceito). Ela é uma instância da classe GtkEventBox da biblioteca Gtk, que é sensível à eventos como movimentações do mouse. Um nodo possuirá coordenadas x e y ($x e $y), cor ($color), rótulo ($caption), imagem ($image) e identificador ($id). A classe irá prover métodos como onClick e onRelease, que tratam a interação do mouse, onDelclick para excluir, startMoving e stopMoving para a movimentação. Um objeto Panel irá conter vários objetos Node por meio da agregação representada na figura 12. Sempre que um nodo for criado ou relacionado à outro, os agentes ConceptHelper e LinkHelper serão acionados.

5. Protótipo

5.1. IntroduçãoNesta seção será demonstrado o protótipo desenvolvido, que faz parte de uma dissertação de mestrado na área de gestão de requisitos. Este protótipo está sendo utilizado de forma experimental no projeto de um sistema de gestão acadêmica em uma universidade privada no sul do país, onde um dos autores deste artigo integra uma equipe composta de três analistas e cinco usuários. A ferramenta é utilizada como apoio na definição de conceitos organizacionais e tem sido de grande valia, permitindo que analistas e usuários definam os conceitos de forma conjunta, além de gerar o modelo inicial de domínio, minimizando a possibilidade de erro por parte dos analistas por possuir internamente regras de mapeamento do conhecimento em modelos de design.

5.2. FuncionamentoA partir do momento em que a aplicação é acionada, o usuário poderá acessarremotamente um servidor de mapas conceituais. Nesta ocasião, deverão ser informados o endereço do servidor de mapas (host) e o nome do usuário que está acessando o servidor (login). Após a aplicação cliente conectar ao servidor, o usuário poderá criar um mapa novo ou abrir um dos mapas existentes, como visto na figura 13.

Figura 13. Tela de login do módulo cliente

��

��

A partir do momento em que o usuário carregar um mapa conceitual existente, o mesmo será renderizado na interface cliente, como pode ser visto na figura 14. Na parte superior, são exibidas as ações disponíveis: conectar ao servidor de mapas, criar um novo mapa, abrir um existente, exportar o mapa conceitual no formato XMI, adicionar um novo nodo, navegar no mapa conceitual e também relacionar (ligar) dois conceitos (nodos) já existentes. Ainda na figura 14, demonstra-se o agente ConceptHelper questionando o usuário sobre as características do conceito recém-criado “Aluno”.

Figura 14. Qualificação de conceito

Na parte central da aplicação, é exibido o painel (instância da classe Panel) que contém cada um dos conceitos (instâncias da classe Node). Na parte inferior da janela, são exibidas as ações do usuário atual, bem como de outros usuários editando o mesmo mapa conceitual. O usuário pode utilizar este espaço também para se comunicar com outros usuários. O mapa conceitual é atualizado à cada um segundo, por meio de uma requisição da classe Application para a classe MapServer, solicitando as últimas ações desempenhadas no mapa conceitual. Cada ação de usuário é transmitida no momento em que ocorre para o servidor. A partir do servidor, os demais usuários têm seus mapas atualizados automaticamente. Na figura 15 é demonstrada a qualificação do relacionamento entre “Aluno” e “Empréstimo” realizada pelo agente LinkHelper.

Figura 15. Exemplo de agente de qualificação de conceito

��

��

A partir do mapa conceitual construído e das qualificações realizadas, o agente DesignHelper possui informações suficientes para que possa gerar um artefato de design, com base nos padrões exibidos na seção 3. Desta forma, na figura 16 é demonstrada a versão do mapa conceitual em XMI, criada pelo agente DesignHelper a partir das qualificações realizadas e aberta pela ferramenta Umbrello. O agente DesignHelper é o responsável por criar modelos XMI contendo classes, atributos, métodos, associações, agregações, composições e heranças.

Figura 16. Representação do modelo em XMI

Na figura a seguir, é demonstrado como o agente DesignHelper transforma os conceitos e relacionamentos em um modelo de design. Inicialmente o agente DesignHelper consulta a base de padrões contendo os conceitos e relacionamentos já classificados. A partir desta leitura, o agente carrega em memória o template para geração do documento XMI no formato que o Umbrello aguarda. Com os conceitos e relacionamentos em memória, o agente traduz estes em tags conforme o formato XMI. Apesar de ser um padrão, o formato XMI possui pequenas diferenças em cada implementação. Está em desenvolvimento um template XMI para o software ArgoUML e em seguida serão adicionados templates para o Rational Rose e Star UML.

Figura 17. Conversão dos conceitos e relacionamentos para o modelo XMI

6. ConclusõesExpressar requisitos de forma concisa, completa e consistente entre usuários e analistas continua sendo um problema, cuja origem geralmente é de comunicação. Portanto, é essencial que este processo seja conduzido de maneira colaborativa e que utilize técnicas de representação do conhecimento de fácil compreensão, tais como os mapas conceituais, que permitem organizar os conceitos de forma similar a maneira com a qual o ser humano organiza suas ideias. Desta forma, o próprio usuário pode validar os

��

��

requisitos por ele definidos durante a análise. Entretanto, tais técnicas não possuem semântica suficiente para que possam ser reutilizadas em etapas posteriores de projeto.

O desenvolvimento da ferramenta abordada no presente trabalho, permite a utilização colaborativa de mapas conceituais para representar requisitos de software, de maneira que estes possam posteriormente gerar artefatos de design. Para que isto seja possível, o conhecimento representado no mapa conceitual é qualificado e classificado por meio de agentes de software que interagem com o usuário. A maior contribuição deste trabalho está em adaptar uma técnica de representação de conhecimento à realidade da engenharia de requisitos, aproximando usuários de analistas e permitindo que os mesmos utilizem uma notação única na expressão dos conceitos, diminuindo a ambiguidade, aumentando a concisão e diminuindo a distância entre análise e projeto. Espera-se ainda que sejam desenvolvidas novas aplicações de engenharia de requisitos baseadas em mapas conceituais a partir da arquitetura criada, uma vez que existem poucos trabalhos recentes que abordam a utilização de mapas conceituais e destes, praticamente nenhum aborda sua utilização para fins de engenharia de requisitos, o que reforça a unicidade do presente trabalho, ainda mais ao observar a utilização proposta.

Referências[1]Chung, J., Lin, K., Mathieu, R. "Guest Editors' Introduction: Web Services

Computing--Advancing Software Interoperability," Computer, vol. 36, no. 10, pp. 35-37, Oct. 2003, doi:10.1109/MC.2003.1236469

[2]De Loach. An Overview of the Multiagent Systems Engineering Methodology. Proceedings of the First International Workshop on Agent-Oriented Software Engineering, 10th June 2000, Limerick, Ireland.

[3]Hansen, Roseli P; Santos, C. T.; Pinto, S. Crespo C. S.; Lanius, G.; Massen, F.. Web Services: An Architetural Overview. In: First Seminar on Advanced Research in Electronic Business, 2002, Rio de Janeiro. v. 1. p. 44-57.

[4]Kaiya, Haruhiko., Saeki, Motoshi. Using Domain Ontology as Domain Knowledge for Requirements Elicitation. Proceedings of the 14th IEEE International Requirements Engineering Conference (RE'06), 2006 IEEE Computer Society.

[5]Lang, M.. and Duggan, J. 2001. A Tool to Support Collaborative Software Requirements Management. Requirements Engineering Journal. Vol. 6. No. 3.

[6]Nuseibeh, Bashar. EASTERBROOK, Steve. Requirements Engineering: A Roadmap. Proceedings of International Conference on Software Engineering (ICSE-2000), 4-11 June 2000, Limerick, Ireland.

[7]Paetsch, Frauke. EBERLEIN, Armin. MAURER, Frank. Requirements Engineering and Agile Software Development. Proceedings of the Twelfth IEEE International Workshops on Enabling Technologies: Infrastructure for Collaborative Enterprises (WETICE’03). 2003 IEEE.

[8]Snyder, Daniel., McNeese, Michael. Identifying Design Requirements Using Integrated Analysis Structures. 1991 IEEE Computer Society.

[9]Vaughan-Nichols, S. "Web Services: Beyond the Hype," Computer, vol. 35, no. 2, pp. 18-21, Feb. 2002, doi:10.1109/2.982908

[10]Zaff, Brian., McNeese, Michael. An Integrated Methodology for Knowledge and Design Acquisition. CH3007-2/91/0000-00779, 1991 IEEE Computer Society.

��

��

uma ferramenta colaborativa de edição de mapas...

Documents