Utilização de Mapas Conceituais em Engenharia de Software

Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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
[email protected]
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)
[email protected]
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] .
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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:
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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) :
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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.
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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.
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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
Partida de Xadrez
Australiana
Usuário do Sistema
Movimentar peça
Conversar
Repositório de peças
Tipos de Verbo
(saída)
Não importa
Definição
Nulo
Tipos de Verbo
(entrada)
Não importa
Nulo
Ativo
Não importa
Ação
Não importa
Ação
Sala de Bate-papo,
ativo, inativo
inativas
Ação
Nulo
Entidade
Método de Turno
de Jogo
Método
Ação
Nulo
Atributo
Entidade
de
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
Movimento específico
peças
Atributo de tipo.
Tipos,movimentar
peça
Partida de Xadrez
Australiana,
Movimento
específico
Partida de Xadrez
Australiana, mesa de
jogo
Composição
relacional
Composição,
relacional
Nulo
Atributo
de
partida de xadrez
australiana.
Composição
composição
Tipo
Peças
composição
Composição,ligação
Nome
Peça
Tipo
Mesas de jogo
Composição
Composição
Cor
Peças
Composição
Nulo
Composição,
ligação, ação
Ligação
Jogador
Tempo inicial
Em mesas de jogo
Relógios,
administrador
Outros
Composição,
ação
Composição
Nulo
Tempo atual
Relógios, ativos
Composição,ação
Nulo
Sala de Bate-Papo
Mesas de jogo
Composição
Ação
Brancas
Cor
Ligação
Nulo
Negras
Cor
Ligação
Nulo
Brancas 2
Casas
Ligação
Nulo
Negras 2
Casas
Ligação
Nulo
Tabuleiro
Mesas de jogo
Composição
Ação, composição
Casas
Tabuleiro
Composição
Ligação
Ativas
Peças
Ligação
Composição, ação
Inativas
Peças
Ligação
Composição, ação
Turno de Jogo
Jogador
Composição
Ligação
Ativo
Inativo
Turno de Jogo
Turno de Jogo
Ligação
Ligação
Composição, ação
Composição, ação
Mesa de jogo 2
Usuário do Sistema
Ligação
Relacional
Relógios
Composição
Apelido
Mesa
de
jogador
Jogador
Composição
Composição,
Ligação,
Nulo
Senha
Jogador
Composição
Nulo
Sub-Classe
de
Partida
de
Xadrez
Australiana.
Sub-Classe
de
tipo
Atributo de tipo
Sub-classe
de
mesas
Atributo
de
peças
Entidade
Atributo
de
Jogador, Mesa
de Jogo
Atributo de Mesa
de Jogo
Sub-classe
de
mesas
Valor de cor,
constante
Valor de cor,
constante
Valor de casa,
constante
Valor de casa,
constante
Sub-Classe
de
mesas
Atributo
de
tabuleiro
Valor
ou
constante
de
Peças; condição
Valor
ou
constante
de
Peças, condição
Sub-Classe
de
Jogador
Condição
Valor
ou
constante
de
Turno de Jogo
Atributo
de
usuário
Sub-Classe
de
jogador
Atributo
de
jogador
Atributo
de
Regras do Jogo de
Xadrez Original
Mesas de jogo
jogo,
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
Pontuação
Jogador
Composição
Nulo
Ativos
Relógios
Ligação
Ação
Inativos
Em nenhuma mesa de
jogo
Relógios
Jogador
Ligação
Ligação
Nulo
Ação
Criar mesa
Em nenhuma mesa
de jogo
Em nenhuma mesa
de jogo
Em nenhuma mesa
de jogo
Ação
Nulo
Ação
Nulo
Ação
nulo
Entrar em mesa
Conversar 2
jogador
Atributo
de
jogador
Condição
de
Relógio
Valor de Relógio
Condição
de
Usuário
do
Sistema
Método
de
Jogador
Método
de
Jogador
Método
de
Jogador
5.5- Resultados da análise:
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:
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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,
Anais do 12O Encontro de Iniciação Científica e Pós-Graduação do ITA – XII ENCITA / 2006
Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, Outubro, 16 a 19, 2006
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.