Utilização de Mapas Conceituais em Engenharia de Software: Projetando uma ferramenta case

Utilização de Mapas Conceituais em Engenharia de Software: Projetando uma ferramenta case Luiz Henrique Martins Lins Rolim Instituto Tecnológico de Aeronaútica ITA- São José dos Campos SP (Times New Roman, size 9) Bolsista PIBIC-CNPq luizhenrique.rolim@gmail.com Professor orientador : José Maria Parente de Oliveira instituto Tecnológico de Aeronaútica ITA- São José dos Campos SP (Times New Roman, size 9) parente@ita.br Resumo: Esse artigo propõe a utilização de mapas conceituais (CMAP) como elemento integrante do processo de engenharia de software, mais especificamente na fase de levantamento de requisitos do sistema, por possibilitar um excelente canal de comunicação entre os conceitos que compõe o domínio do sistema e os elementos que irão compor a solução no nível operacional. Como estudo de caso, foi selecionado, devido ao acesso irrestrito à documentação, e a complexidade relativamente simples, o software em desenvolvimento na disciplina de graduação CES-31. Esse software, a metodologia CRC/WB+, utilizada no processo de modelagem, e os resultados que demonstram a viabilidade da utilização dos CMAPS serão detalhados ao longo do artigo. 1-Introdução: O levantamento de requisitos constitui uma etapa imprescindível da engenharia de software e muitos problemas decorrem da imprecisão na especificação de requisitos[sommerville-2005]. Esse levantamento deve ser realizado reuniões com os o(s) cliente(s), e com todos aqueles que possuírem conhecimento sobre o domínio; a esse conjunto de usuários denomina-se genericamente stakeholders. Os requisitos do software devem ser especificados de modo a atender o desejo dos usuários finais, que podem possuir diferentes pontos de vista em relação à utilização do sistema [Sommerville-2005]. Os stakeholders tendem a descrever requisitos segundo objetivos pessoais ou políticos, ou seja o que eles gostariam que o software realizasse para proveito pessoal e esses tendem a não representarem o que o sistema deveria fazer na realidade, não são passíveis de implementação, ou contém fatores políticos ou organizacionais[sommerville-2005]. Seria ideal, portanto que o engenheiro de requisitos possuísse total conhecimento sobre o domínio do sistema uma vez que isso geraria maiores possibilidades de comunicação com os stakeholders na fase de levantamento de requisitos, o que implicaria em requisitos melhores especificados e conseqüente ganho de produtividade no processo de engenharia de software como um todo. Na prática, contudo é impossível que o engenheiro de software chegue ao menos perto de conhecer tudo acerca dos domínios em que ele trabalha, por mais que ele possua anos de experiência.obviamente, alguns sistemas possuem boa parte de seu sistema como de conhecimento público e isso pode contribuir com o aumento de produtividade do processo. Como exemplo, considere um sistema de controle de vendas em um supermercado. Um engenheiro de requisitos irá desconfiar se um caixa desejar que o sistema lhe dê condições de alterar o montante da venda num determinado dia; entretanto, esse mesmo engenheiro provavelmente não teria condições de inferir se em um sistema de perfuração de petróleo o operador deveria ter ou não acesso ao montante retirado de um poço de petróleo em um determinado período de tempo. Além de um melhor levantamento de requisitos, uma maior compreensão do domínio do sistema poderá auxiliar o engenheiro de software, em sistemas OO, a realizar mais facilmente a transição entre a perspectiva conceitual do sistema para a perspectiva de software, etapa que é conhecida segundo a metodologia CRC/WB+ como FEI (Fase Exploratória Inicial). Ferramentas CASE podem ser utilizadas, nesse contexto, a fim de possibilitar ao engenheiro de software aumentar sua compreensão sobre o domínio do sistema. A utilização de diagramas de classe a nível conceitual, como modo de auxiliar o conhecimento do domínio do aplicativo, já é defendida por alguns autores na fase de especificação de requisitos [COCKBURN 2000] [Fowler 2003]. Entretanto, ao utilizar notações em UML no nível conceitual o engenheiro corre o risco de contaminar o vocabulário do domínio com termos técnicos o que dificultaria o diálogo com os stakeholders [Inaldo 2005].

Uma alternativa seria adotar notações externas a UML nesta fase conceitual. A vantagem desta outra abordagem é poder optar por representações próximas a maneira de pensar dos usuários. O problema que poderia advir com esta abordagem é tornar difícil a transição entre a Perspectiva Conceitual e a Perspectiva de Software [Costa 2005]. Assim, faz-se necessária à utilização de uma ferramenta que possibilite um bom diálogo com os stakeholders e que facilite a transição para a perspectiva de software. Esse artigo defende a utilização de mapas conceituais (do inglês CMAPs) como sendo uma ferramenta que atende as expectativas expostas acima e terá suas conclusões baseadas em um estudo de caso simples que foi desenvolvido no curso de graduação de CES-31 do ITA. O texto é composto de uma parte mais teórica, a seção 2, onde será definido o que é um Mapa Conceitual, a seção 3 onde será feita uma pequena introdução dos conceitos OO, a seção 4 que irá introduzir os conceitos necessários referentes à metodologia CRC/WB+, e uma parte mais prática, composta pela seção 5, onde será apresentado o Estudo de Caso e a seção 6 com as respectivas conclusões. 2-Mapas Conceituais : Mapa conceitual é uma ferramenta de representação de conhecimento[novak,1998]. O aspecto principal de um mapa conceitual é a representação de relações entre conceitos de um corpo de conhecimento. Embora normalmente incluam uma organização hierárquica e, muitas vezes, incluam setas, tais diagramas não devem ser confundidos com organogramas ou diagramas de fluxo, pois não implicam seqüência, temporalidade ou direcionalidade nem hierarquias organizacionais ou de poder. Mapas conceituais são diagramas de significados, de relações significativas, de hierarquias conceituais, se for o caso [Moreira 1997]. Um mapa conceitual deve servir para capturar o maior número possível de informações sobre um determinado domínio. Considere o mapa conceitual abaixo construído para representar o domínio dos números primos: Figura 1: Mapa conceitual números primos. Observe que neste mapa, diferentemente dos diagramas UML convencionais o objetivo é ter uma idéia sobre o domínio do problema a ser resolvido o que possibilita uma linguagem simples que pode ser compreendida mesmo por usuários que não possuam quaisquer familiaridades com programação. Desta

forma, um mapa conceitual pode servir como uma transição, em termos de documentação, para diagramas de classe UML padrão, possibilitando ao engenheiro de software aproximar-se ao máximo da visão do usuário sem, contudo dificultar suas tarefas posteriores. Na construção do mapa, devem ser levantada a maior quantidade possível de informação sobre o sistema, independente se essas serão ou não utilizadas. Em uma etapa posterior à construção, será realizada análise de quais dos conceitos são ou não pertinentes aquele sistema específico. Os conceitos devem ser escritos de forma a possibilitar uma fácil comunicação com o cliente. Eles não devem conter, portanto, quaisquer terminologias especificas de engenharia de software. 2.1-Recomendações de construção: As recomendações abaixo visam padronizar os mapas conceituais de modo a facilitar a construção e execução do algoritmo apresentado em 5.3. Evitar a utilização de verbos como conceitos dos mapas. Eles devem ser preferencialmente substantivos não flexionados. Evitar a utilização de substantivos nas relações entre conceitos. Elas devem ser preferencialmente verbos no infinitivo. Evitar a utilização de conceitos sinônimos. Atentar quanto à representação de relações condicionais. É desejável estabelecer relações utilizando o menor número de conceitos possíveis. Utilizar o menor número de verbos nas relações entre conceitos. 3-Conceituação fundamental sobre Linguagens OO : Com intuito de facilitar o entendimento dos itens subseqüentes deste relatório será apresentada uma conceituação à cerca de alguns dos principais conceitos pertinentes as linguagens OO. 3.1-Abstração: O termo abstração diz respeito à capacidade de extrair de um objeto do mundo real os principais valores ou ações que ele desempenha ou, mais especificamente, aqueles valores ou ações que devem ser levados em conta no domínio da aplicação e é fundamental no processo de aprendizado e de modelagem de linguagens OO bem como nas demais cadeiras de computação. O primeiro passo na construção de um algoritmo é a abstração do problema real nas entidades que compõe a linguagem OO. Um aluno iniciante terá dificuldades em delimitar quais os objetos reais que devem ou não ser representados computacionalmente em termos das entidades OO e quais são as ações e propriedades que essas necessitam para funcionar corretamente. Um mesmo objeto real pode ser representado de inúmeras maneiras dependendo do problema em que ele está inserido. As representações de um carro, por exemplo, serão, com certeza, diferentes em um software que simula as forças que estão aplicadas à estrutura do chassi e em um jogo de corrida. Essas diferenças devem ser levadas em conta pelo engenheiro de software na hora de modelar o seu sistema. 3.2-Classes: As classes são a estrutura básica de qualquer linguagem OO. Uma classe será definida a partir do processo de abstração de um objeto real e nela estarão descritas todas as ações e propriedades desse que interessam ao contexto do sistema. Compete ao engenheiro de software ou programador decidir quais objetos reais necessitam ser representados em classes. Apesar de poder haver algumas interseções nos objetivos de diferentes classes, essas possuirão, em geral, diferentes propriedades (atributos) e responsabilidades (métodos) no domínio do sistema. Um método comum a todas as classes é o construtor sendo esse utilizado para criar um objeto daquela classe. Para exemplificação consideremos um software de jogo xadrez. Possíveis classes seriam o tabuleiro, as peças, a tela, os jogadores e talvez uma classe de controle. A classe de peças pode possuir propriedades como cor, posição atual no tabuleiro, tipo e métodos como movimento, captura, etc. 3.3-Objetos:

Conforme visto acima as classes formam um protótipo de um objeto do mundo real, definindo todas as características desse que interessam ao domínio da aplicação. Um objeto, por sua vez, é uma ocorrência (instância) ou exemplo específico de uma classe. Os objetos serão os responsáveis por, de fato, utilizar as propriedades das classes. Um objeto é instanciado quando da chamada do método (obrigatório) construtor da classe. Vários objetos da mesma classe podem ser necessários em um determinado domínio. No exemplo do jogo de xadrez, teríamos dezesseis objetos da classe peão, (oito para cada jogador); na modelagem de um carro, dependendo do objetivo do software, talvez fossem necessários 4 objetos da classe roda; em um jogo de videogame vários objetos da classe monstro poderiam ser necessários, etc. 3.4-Herança: Herança em OO é uma característica que permite um relacionamento entre classes de modo que uma classe, denominada classe base, tenha seus métodos e atributos aproveitados (herdados) por outras classes, denominados classes derivadas. Essa hierarquia é fundamental por permitir um reaproveitamento de código, tornando-o mais organizado além facilitar o processo de abstração, já que no mundo real, muitos objetos podem ser relacionados hierarquicamente. Para um exemplo de herança, considere a classe cão. Possíveis classes derivadas seriam poodle, viralatas, etc. Como exemplo de herança pertinente ao mundo da programação, mais especificamente na linguagem C#, podemos citar os formulários do Windows (Windows Forms) como Caixas de Texto ou Botões que são herdadas a partir de uma classe comum chamada Form. 4-Rápida Introdução à metodologia CRC\WB+ A metodologia CRC\WB+ é uma metodologia de engenharia de software que objetiva documentar o software através de um processo interativo e incremental. Ela foi desenvolvida pelo professor doutor Clóvis Torres Fernandes e é lecionada no curso de graduação de CES-31 (Engenharia de Software) no instituto tecnológico de aeronáutica ITA. A metodologia é constituída de diversas fases mas apenas duas são relevantes no contexto do artigo, a LPR (levantamento preliminar de requisitos) e a FEI (fase exploratória inicial). 4.1-Levantamento Preliminar de Requisitos (LPR) Na fase LPR são levantados os requisitos do sistema. Ela é constituída, basicamente, pelas seguintes etapas: Descrição Textual do Software: Nessa etapa o software é descrito sob linguagem natural do ponto de vista dos usuários do sistema. O texto deve ser livre de ambigüidades e omissões de modo a introduzir suas principais funcionalidades. Levantamento de Requisitos: Nessa fase serão levantados tanto os requisitos funcionais quanto os não funcionais. Os requisitos principais já foram destacados a partir da descrição textual mas, requisitos adicionais podem ser acrescentados. Todos os requisitos que forem levantados são ordenados, quanto ao grau de importância (essencial ou secundário) e de necessidade (necessário, desejável, opicional) Confecção do Manual Preliminar do Usuário Trata-se de um protótipo do sistema que irá detalhar ao usuário as funcionalidades das telas do sistema. Determinação do Diagrama de Arquitetura Distribuída (DAD) Nesta etapa será construído o diagrama de arquitetura distribuída que indica quem são os atores e os sistemas presentes no software. O software pode ser divido em subsistemas que denominam-se, genericamente, visões focais. Levantamento dos casos de Uso Com base nas funcionalidades que foram levantadas na etapa Levantamento de Requisitos serão levantados os casos de uso do sistema. Estes devem ser descritos sobre a forma de templates que fornecem um grande número de detalhes a cerca de sua estrutura e de seu curso de eventos típicos. 4.2- Fase Exploratória Inicial (FEI) :

Na fase FEI o software será dividido em quatro camadas e será descrito, mediante a utilização de cartões CRC, em classes para cada uma de suas camadas. Ela é constituída, basicamente, pelas seguintes etapas: Identificação de Classes de Regras de Negócio (RN) A camada de regras de negócio é responsável por realizar o interfaceamento entre a camada de interface do usuário (IU) e as camadas de persistência (IP) ou do sistema operacional (SO). Ela contém a maior parte da lógica por trás do aplicativo. Segundo a metodologia CRC/WB+ essas classes serão levantadas a partir da análise dos casos de uso levantados na LPR. Identificação de Classes de Interface de Usuário (IU) As classes de interface de usuário são as telas presentes nos sistemas que compõe o software. Nessa etapa da FEI, devem ser especificadas a finalidade, as responsabilidades e as colaborações de cada classe e possivelmente as estruturas de dados que elas utilizarão. Definição de Classe da Interface de Persistência Essas classes são as responsáveis por estabelecer um protocolo de armazenamento e recuperação de informações. Nesta fase serão definidas como será realizada essa comunicação. Definição de Classes de Interface com o Sistema Operacional Essas classes possibilitam a comunicação do software com recursos do sistema operacional, como drivers, portas, formas de comunicação, etc. Nesta fase estas classes devem ser descritas em termos de responsabilidades e atributos. Definição da lógica das Responsabilidades Nesta fase será descrita a lógica existente nas responsabilidades de cada uma das classes identificadas nas etapas anteriores. A partir dessa decrição será possível a identificação de novas classes e colaborações. 5-Estudo de Caso: Jogo de Xadrez à Australiana 5.1 Descrição Narrativa: O projeto consiste em uma variante do jogo de xadrez adaptado para dois times de duas pessoas cada, que jogarão em modo cooperativo, e é popularmente conhecida como Australiana. Inicialmente, duas duplas são formadas. Dentro de cada dupla há um sorteio de forma que em cada time haja uma pessoa jogando com as peças pretas e outro com as brancas. Feito isso, haverá um cruzamento das duplas de modo que o membro de brancas de uma dupla jogará, simultaneamente, e em dois tabuleiros distintos, com o de pretas da outra e vice-versa. Cada tabuleiro terá seu relógio próprio, e cada jogador seu próprio tempo. O jogo acaba quando um jogador levar um xeque-mate ou acabar seu tempo, ocasionando a derrota de sua dupla. A cooperação entre os jogadores da mesma dupla dá-se de modo que todas as peças que são capturadas por um jogador poderão ser usadas pelo outro jogador da dupla. Um jogador em seu turno pode optar por colocar em seu tabuleiro qualquer uma das peças fornecidas, ou realizar uma jogada convencional. Não há, portanto, necessidade de se colocar as peças em jogo, nem qualquer tipo de ordem que precisa ser seguida para inserir as peças no tabuleiro. Existem, entretanto, as seguintes restrições para a entrada de uma peça: - Peões não podem entrar nem na primeira, nem sétima, nem oitava fileiras; - Peças não podem entrar colocando o rei do adversário em xeque. - Peças devem entrar em casas vazias. O jogo deve usar relógios para prevenir que os jogadores esperem indefinidamente por uma peça (esperar por uma peça é considerado perfeitamente aceitável). Há diversas opiniões, mas geralmente é aceitável diálogo entre companheiros de time. Um jogador pode pedir peças específicas para colocar em seu tabuleiro, de forma a evitar ou conseguir um mate. (essa é uma das características mais legais desse jogo, a dinâmica). Será armazenado em um banco de dados, o perfil de cada usuário com o número de vitórias, empates, derrotas, além da cor utilizada para jogar e seu ranking.

5.2- Perspectiva do usuário: Mapa conceitual do Jogo de Xadrez à Australiana figura 1 : Mapa conceitual. 5.3- Extraindo Classes e Responsabilidades a Partir do CMAP Construído o mapa conceitual, é possível inferir prováveis classes e responsabilidades do sistema. Para essa identificação, proponho as etapas: 1. Tabelar todos os conceitos do mapa, retirando-lhes os numerais, artigos e declinações de número e grau quando substantivos. Os verbos serão marcados como métodos. 2. Definir nesta tabela os conceitos pai. Conceitos que não possuírem conceito pai, serão marcados como entidades representativas do sistema e não precisarão ser analisados em 3 e 4.

3. Definir nesta tabela o tipo dos verbos que dos conectores de entrada e de saída do conceito segundo regra abaixo: Verbos de ação(definir,tornar,utilizar,poder,etc...) representam responsabilidades do sistema Verbos de composição (possuir, compor,ter,etc...) representam relações de pertinência entre conceitos Verbos de ligação (ser,estar) representam estados que um determinado conceito pode alcançar no programa. Conectivos relacionais (conforme,segundo,) representam relações entre conceitos que não podem ser inferidas. No caso, de um conceito possuir conectivos relacionais de entrada, devemos subir um nível no mapa em relação ao seu conceito pai. Outros tipos serão marcados como entidade. 4. Para cada um dos conceitos tabelados em 1, identificar os tipos de verbo de saída, segundo critério abaixo. Marcar conceitos que possuírem verbos de ação entre os seus conectivos como prováveis classes, uma vez que possuem responsabilidades atribuídas. Marcar conceitos que não possuírem verbos de ação, mas possuírem verbos de ligação entre os seus conectivos como atributos Marcar conceitos que possuírem verbos de composição como classes. 5. Para cada um dos conceitos tabelados em 1, identificar os tipos de verbo de entrada, segundo critério abaixo: Marcar os conceitos definidos como classe em 3 e que possuírem verbo de composição no conectivo chegando nele, como subclasse do conceito pai. Marcar os conceitos definidos como atributos em 3 e que possuírem verbo de verbo de composição em algum conectivo, como atributo do conceito pai. Marcar os conceitos que possuírem verbo de ligação em algum conectivo de entrada como possíveis valores, ou constantes. 6. Se dois conceitos tiverem o mesmo nome diferenciá-los com índice. 7. Redefinir conceitos que possuírem verbos de entrada de ligação e de saída de ação como condição. 8. Conceitos filhos de conceitos condição, serão referenciados ao pai da condição. 9. Atribuir cada conceito que possuir conceitos filhos do tipo condição como classe. 10. Repetir passo 5 para conceitos definidos como atributos de um conceito que não está definido como classe, redefinindo o pai, como o sendo o pai do pai (subir um nível de hierarquia no mapa). 5.4- Aplicação da Metodologia no Estudo de Caso: Aplicando os passos de 1 a 8 chegaremos a seguinte tabela: Conceito Conceitos Pai Tipos de Verbo Tipos de Verbo Definição (entrada) (saída) Partida de Xadrez Nulo Não importa Não importa Entidade Australiana Usuário do Sistema Nulo Não importa Não importa Entidade Movimentar peça Ativo Ação Ação Método de Turno de Jogo Conversar Sala de Bate-papo, Ação Nulo Método ativo, inativo Repositório de peças inativas Ação Nulo Atributo de

Movimento específico Regras do Jogo de Xadrez Original Mesas de jogo Tipos,movimentar peça Partida de Xadrez Australiana, Movimento específico Partida de Xadrez Australiana, mesa de jogo peças Composição relacional Atributo de tipo. Composição, relacional Nulo Atributo de partida de xadrez australiana. Composição composição Sub-Classe de Partida de Xadrez Australiana. Tipo Peças composição Composição,ligação Sub-Classe de tipo Nome Tipo Composição Nulo Atributo de tipo Peça Mesas de jogo Composição Composição, Sub-classe de ligação, ação mesas Cor Peças Composição Ligação Atributo de peças Jogador Em mesas de jogo Outros Composição Entidade Tempo inicial Relógios, Composição, Nulo Atributo de administrador ação Jogador, Mesa de Jogo Tempo atual Relógios, ativos Composição,ação Nulo Atributo de Mesa de Jogo Sala de Bate-Papo Mesas de jogo Composição Ação Sub-classe de mesas Brancas Cor Ligação Nulo Valor de cor, constante Negras Cor Ligação Nulo Valor de cor, constante Brancas 2 Casas Ligação Nulo Valor de casa, constante Negras 2 Casas Ligação Nulo Valor de casa, constante Tabuleiro Mesas de jogo Composição Ação, composição Sub-Classe de mesas Casas Tabuleiro Composição Ligação Atributo de tabuleiro Ativas Peças Ligação Composição, ação Valor ou constante de Peças; condição Inativas Peças Ligação Composição, ação Valor ou constante de Peças, condição Turno de Jogo Jogador Composição Ligação Sub-Classe de Jogador Ativo Turno de Jogo Ligação Composição, ação Condição Inativo Turno de Jogo Ligação Composição, ação Valor ou constante de Turno de Jogo Mesa de jogo 2 Usuário do Sistema Ligação Relacional Atributo de usuário Relógios Mesa de jogo, Composição Composição, Sub-Classe de jogador Ligação, jogador Apelido Jogador Composição Nulo Atributo de jogador Senha Jogador Composição Nulo Atributo de

jogador Pontuação Jogador Composição Nulo Atributo de jogador Ativos Relógios Ligação Ação Condição de Relógio Inativos Relógios Ligação Nulo Valor de Relógio Em nenhuma mesa de Jogador Ligação Ação Condição de jogo Usuário do Sistema Criar mesa Em nenhuma mesa Ação Nulo Método de de jogo Jogador Entrar em mesa Em nenhuma mesa Ação Nulo Método de Conversar 2 5.5- Resultados da análise: de jogo Em nenhuma mesa de jogo Jogador Ação nulo Método de Jogador A partir da execução do método foi possível obter o seguinte diagrama de classes. figura 2: Diagrama de classe a partir do CMAP A metodologia CRC/WB+ adotada como modelo de referência, forneceu o seguinte diagrama de classes:

figura 3: diagrama de classes obtidas a partir de CRC/WB+ 6-Conclusão: Quando comparado com o diagrama obtido na metodologia CRC/WB+ existem 5 classes em comum que o diagrama obtido através da metodologia é representativo. Além dos cartões CRC de cada classe, também já é possível estabelecer relacionamentos de hierarquia entre as classes, o que constitui uma vantagem em relação ao processo já existente. Para o bom funcionamento da metodologia é importante que o mapa conceitual seja construído de maneira adequada seguindo as recomendações da seção 2. Já existem softwares no mercado, capazes de realizar a criação de mapas conceituais a partir de descrições textuais. Utilizando a metodologia acima, podemos construir um software que realize a conversão dos mapas conceituais para os elementos de perspectiva de software, fechando o ciclo.os mapas conceituais podem ser comunicados com o software via linguagem XML, e o algoritmo que pode ser implementado computacionalmente, utilizando ferramentas relativas e teoria dos grafos. A construção de uma ferramenta CASE baseada na metodologia de análise descrita pode vir a facilitar a tarefa de construir programas OO através de engenharia de software. Essa metodologia proposta é passível de revisão; são necessários alguns estudos adicionais, com outros casos de uso para corroborar o seu funcionamento. Ainda assim, foi alcançado o objetivo de estabelecer uma relação entre os mapas conceituais que representam a perspectiva do cliente e os elementos de perspectiva de software. 7-Agradecimentos: Agradeço aos professores José Maria Parente de Oliveira por me orientar na construção desse artigo. Agradeço também ao professor Clóvis Torres Fernandes por me despertar o interesse pela disciplina de engenharia de software, e ao Inaldo Capistriano Costa, por me fornecer material de apoio. Ao professor Paulo Marcelo Tasinaffo, pela compreensão e, especialmente, ao CNPQ por viabilizar essa pesquisa. 8-Referências: Cockburn, A. (2000). Writing Effective Use Cases. Addison Wesley. Costa, I.C,Oliveira J.M.P, Fernandes C.T (2005), Utilização de Mapa Conceitual na modelagem de um sistema simples (não-publicado). Departamento de Ciências da Computação Instituto Tecnológico de Aeronáutica (ITA) São José dos Campos SP Brasil Fowler, M. (2003). UML Distilled. Addison-Wesley, 3th edition. Moreira, M. A. (1997). Mapas conceituais e aprendizagem significativa. Technical report,

Instituto de F ısica - UFRGS. Novak, J. D. (1998). Learning, Creating, and Using Knowledge: Concept Map as Facilitative Tools in Schools and Corporations. Lawrence Erlbaum Associates, Publishers. Sommerville, I. (2005). Engenharia de Software - 6a Edição. Addison Wesley.