Reengenharia Simulador Campo Eletrico
-
Upload
profdouglas-almeida -
Category
Documents
-
view
75 -
download
9
Transcript of Reengenharia Simulador Campo Eletrico
UNIVERSIDADE FEDERAL DE SÃO CARLOS
CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
DEPARTAMENTO DE COMPUTAÇÃO
Reengenharia de um simulador de campo elétrico para
melhorar aspectos de usabilidade/extensibilidade
AUTOR: DOUGLAS FERREIRA DE ALMEIDA
MONOGRAFIA DE CONCLUSÃO DO CURSO
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
ORIENTADOR: PROF. DR. DANIEL LUCRÉDIO
SÃO CARLOS – SP
2012
DOUGLAS FERREIRA DE ALMEIDA
Reengenharia de um simulador de campo elétrico para
melhorar aspectos de usabilidade/extensibilidade
Trabalho de conclusão de curso apresentado
como parte das atividades para obtenção do
título de Bacharel, do curso de Sistemas de
Informação da Universidade Federal de São
Carlos.
Orientador: Prof. Dr. Daniel Lucrédio.
SÃO CARLOS – SP
2012
Folha de aprovação
Dedico este trabalho, com
amor, à pessoa que mais me
ajudou em sua realização – à
companheira fiel e mãe dos
meus filhos – Patrícia
Ribeiro.
Agradecimentos
Agradeço ao Pai Celestial pela vida, pelo viver e pela promessa de plenitude, aos meus
pais pelo apoio durante toda a vida, aos meus filhos por serem o ar mais puro que
respiro e as palpitações mais intensas do coração, ao Prof. Dr. Daniel Lucrédio pelo
apoio e orientação e ao doutorando Marcos Alexandre Rose Silva pelas preciosas
sugestões.
“A gravidade explica os
movimentos dos planetas,
mas não pode explicar quem
colocou os planetas em
movimento. Deus governa
todas as coisas e sabe tudo
que é ou que pode ser feito”.
(Isaac Newton)
Resumo
O processo de ensino e aprendizagem de Física e, em especial, de campo elétrico no
nível médio brasileiro, enfrenta dificuldades por causa da complexidade do assunto e do
uso de metodologias não satisfatórias. Simuladores que apresentem diferentes
configurações de cargas geradoras de campo elétrico interagindo com cargas de prova e
modelos de representação de campo elétrico podem oferecer ajuda em busca da solução
do problema.
Esta monografia apresenta a reengenharia do 3D – Vector Fields Applet V 1.3
(PAUL FALSTAD’S HOME PAGE, 2011) cujo resultado é um simulador mais
adequado para dar suporte ao processo apontado. E os conceitos e técnicas utilizados
podem ser úteis a outros projetos aos quais sejam necessários.
Palavras-chave: Reengenharia de software, Orientação a Objetos, Ensino de Física,
Java, Campo Elétrico.
Abstract
The teaching and learning process of physics and, in particular, of the electric field at
the Brazilian average level, is facing difficulties because of the complexity of the
subject and the use of non-satisfactory methodologies. Simulators that have different
charge configurations generating of electric field interacting with charges of proof and
models representation of the electric field can offer help in search for the solution of the
problem raised.
This monograph presents the reengineering of 3D - Vector Fields Applet V 1.3
(PAUL FALSTAD’S HOME PAGE, 2011) whose result is a more suitable simulator to
support the process pointed. The concepts and techniques used may be useful to other
projects which are necessary.
Keywords: Software Reengineering, Object Orientation, Physics Teaching, Java,
Electric Field.
Sumário
1. Introdução................................................................................................................ 10
2. Física no Ensino Médio Brasileiro .......................................................................... 11
2.1 Ensino e Aprendizagem de Campo Elétrico ........................................................ 13
2.2 Laboratórios Virtuais ........................................................................................... 16
3. Conceitos Básicos ................................................................................................... 17
3.1 Orientação a Objetos ........................................................................................... 18
3.2 Java ...................................................................................................................... 19
3.3 Reengenharia de Software ................................................................................... 20
4. Reengenharia do 3D – Vector Fields Applet V 1.3................................................. 27
4.1 Levantamento de Requisitos ................................................................................ 27
4.2 Engenharia Reversa ............................................................................................. 27
4.2.1 Análise das Funcionalidades ............................................................................ 27
4.2.2 Análise da Interface ......................................................................................... 34
4.2.3 Análise da Estrutura ......................................................................................... 36
4.2.4 Resumo dos Resultados da Engenharia Reversa ............................................. 38
4.3 Engenharia Progressiva ....................................................................................... 38
4.3.1 1º ciclo – Retirada dos Blocos de Pré-Processamento ..................................... 38
4.3.2 2º ciclo – Modificação da Classe Vec3DemoFrame ........................................ 39
4.3.3 3º ciclo – Supressão de Vec3Demo ................................................................. 44
4.3.4 4º ciclo – Modificação da Interface ................................................................. 44
4.3.5 5º ciclo – Revisão ............................................................................................. 48
4.3.6 Métricas para o Simulador Modificado ........................................................... 49
5. Conclusões .............................................................................................................. 52
Referências Bibliográficas .............................................................................................. 53
10
1. Introdução
Algumas atitudes não recomendáveis são praticadas no ensino de Física de nível médio,
tais como: apresentação de conteúdos, leis e fórmulas de modo desarticulado,
distanciando o mundo vivido pelos estudantes daquele apresentado pelo professor;
supervalorização da teoria e da abstração em detrimento dos aspectos práticos que
levariam à abstração necessária; desvinculação entre o significado físico de determinada
situação e o ferramental matemático; resolução repetitiva de exercícios, buscando a
memorização e não a compreensão; apresentação do conhecimento como um produto
acabado (GASPAR, 2001a).
Entre os componentes curriculares, eletricidade merece destaque, devido a sua
importância e complexidade. O mundo contemporâneo, como é conhecido, seria
impensável se o seu uso tivesse que ser descartado. E para que melhor compressão deste
assunto seja alcançada, é necessário entender o conceito de campo elétrico, que não é
trivial. (GASPAR, 2001b).
Então, por um lado, há métodos com eficácia questionável, e por outro, um
assunto importante e de difícil compreensão. Deste modo, é conveniente a busca por
ferramentas alternativas que aumentem a eficiência do processo de ensino-
aprendizagem de campo elétrico.
Isto poderia ser feito com o uso exclusivo de laboratórios reais, com os quais os
estudantes interagiriam com os fenômenos, facilitando a sua compreensão. Mas tal
estratégia envolveria a aquisição dos materiais necessários cujos custos dificultariam o
acesso. Além disto, a visualização dos modelos que representam os processos
envolvidos, embora facilitada, não seria possível.
Esta monografia apresenta o processo de reengenharia ao qual o 3D – Vector
Fields Applet V 1.3 foi submetido visando melhorias na sua extensibilidade e
11
usabilidade – termos, que neste trabalho, referem-se, respectivamente, à manutenção e
ao reuso, e à eficiência no apoio ao processo de ensino e aprendizagem.
No capítulo 2, discute-se o processo de ensino e aprendizagem de Física em
nível médio no Brasil e, em particular, de campo elétrico e a maneira como recursos
computacionais podem dar suporte a ele. No capítulo 3, são apresentados conceitos de
Orientação a Objetos, Java e Reengenharia de Software. No capítulo 4, são mostrados
os procedimentos adotados na reengenharia do 3D – Vector Fields Applet V 1.3 e no
capítulo 5, a conclusão. O CD anexado apresenta o código fonte original e o
modificado, assim como o novo simulador e o javadoc – documentação gerada
automaticamente pela ferramenta NetBeans 7.2.
Assim, esta monografia permite que se extraiam elementos relacionados ao
processo de ensino e aprendizagem de Física em nível médio no Brasil e, em particular,
de campo elétrico, e elementos relacionados a técnicas de reengenharia que podem ser
aplicadas em outros projetos, além de oferecer subsídios ao entendimento sobre
algumas dificuldades na adaptação de projetos aos requisitos do paradigma de
orientação a objetos quando tais projetos não tiverem design baseado neste paradigma.
2. Física no Ensino Médio Brasileiro
A Lei de Diretrizes e Bases que regula o ensino fundamental brasileiro apregoa que o
ensino médio deve ser visto como último estágio do ensino fundamental dando
condições ao estudante de exercer sua cidadania no que condiz ao seu direito a atividade
profissional e/ou a prosseguir em seus estudos (MEC, 1996).
Em relação ao processo de ensino e aprendizagem de Física, algumas diretrizes
são apresentadas abaixo (MEC, 2012):
12
(...) competências e habilidades se desenvolvem por meio de ações concretas,
que se referem a conhecimentos, a temas de estudo. E há, certamente, certos
assuntos ou tópicos com maior potencial do que outros para os objetivos
pretendidos, o que impõe escolhas criteriosas. Os temas de trabalho, na medida
em que articulam conhecimentos e competências, transformam-se em
elementos estruturadores da ação pedagógica, ou seja, em temas estruturadores.
No ensino fundamental, esses temas dizem respeito ao mundo vivencial mais
imediato, tratando do ambiente, da vida, da tecnologia, da Terra, e assim por
diante.
Já no ensino médio, devem ganhar uma abrangência maior, e também, ao
mesmo tempo, certa especificidade disciplinar, uma vez que, para desenvolver
competências e habilidades em Física, é preciso lidar com os objetos da Física.
Devem estar relacionados, portanto, com a natureza e a relevância
contemporânea dos processos e fenômenos físicos, cobrindo diferentes campos
de fenômenos e diferentes formas de abordagem, privilegiando as
características mais essenciais que dão consistência ao saber da Física e
permitem um olhar investigativo sobre o mundo real.
Deste modo, o estudo da Física deve capacitar o estudante a enxergar a relação
entre os assuntos da disciplina e o ambiente em que está inserido, o qual é passível de
interação, levando à interpretação de seus aspectos e a ações modificadoras, exigindo
para tal sua capacidade cognitiva no que diz respeito a concentração, imaginação,
estabelecimento de relações, criação e interpretação de modelos, leitura e escrita de
linguagem técnica, entre outros.
Quem estuda esta ciência não se depara apenas com fórmulas que aparentemente
são úteis somente no mundo das ideias, mas com leis que regem o universo, assim como
as bases das tecnologias modernas, que levam à construção de computadores, celulares
e tantos outros dispositivos (LIMA, 2012).
Porém, a abordagem desta disciplina, muitas vezes, tem sido realizada como se
os objetos de análise não fizessem parte da realidade dos estudantes, além de passar a
impressão de que o conhecimento científico é estático, alienado de seu contexto
histórico, absolutamente independente de carga subjetiva comum a qualquer atividade
humana, incluindo a atividade científica.
13
A distância entre o mundo do estudante e o mundo que é apresentado como
sendo própria da Física, associada às dificuldades naturais dos estudantes, de modo
geral, leva esta disciplina aos piores resultados comparados aos das demais disciplinas
(ROSA; FILHO, 2012).
Várias pesquisas estão sendo realizadas no Brasil e no mundo buscando novas
metodologias para melhorar estes resultados (MORAES, 2009).
2.1 Ensino e Aprendizagem de Campo Elétrico
É comum materiais didáticos brasileiros começarem a abordagem de campo elétrico,
estabelecendo analogia entre este conceito e o de campo gravitacional. Talvez isto se
relacione ao fato de que, desde muito cedo, mesmo que de modo simplificado, a Terra é
apresentada como sendo capaz de atrair os corpos próximos a sua superfície. Então,
evocando este conhecimento empírico, aliado aos estudos anteriores do próprio campo
gravitacional, já que o campo elétrico acaba sendo um dos últimos assuntos abordados
no ensino médio, procura-se oferecer subsídios para compreensão do campo elétrico.
Apesar disto, as dificuldades não são plenamente transpostas. A analogia citada
pode ajudar o estudante aceitar como é possível, por exemplo, que uma carga
puntiforme, atuando como fonte geradora de campo elétrico, atraia à distância outra
carga puntiforme oposta. Mas o estudo do campo elétrico no ensino médio requer
abordagem mais profunda. É preciso que o estudante conheça os modelos
representativos e o movimento das cargas de prova originado pela interação entre elas e
a fonte geradora de campo elétrico.
A primeira representação é a do vetor campo elétrico. “O campo elétrico E em
um ponto do espaço é definido como a força elétrica F que age sobre uma carga de
prova, colocada neste ponto, divida pela carga q da partícula” (SERWAY; JR., 2004a).
Sendo a força uma grandeza vetorial e o campo elétrico definido como o produto entre
ela e o inverso da carga elétrica da partícula, que é uma grandeza escalar, o campo
14
elétrico, no ponto considerado, é vetorial (E = F . 1/q). Daí o termo vetor campo
elétrico. Se a fonte geradora tiver carga negativa, este vetor vai ser convergente em
relação a ela. Se for positiva, ele será divergente. Este fato já diferencia o campo
elétrico do gravitacional. O vetor campo gravitacional é sempre convergente em relação
à massa geradora.
O segundo modelo é o das linhas de força. “Elas são uma representação pictórica
especializada conveniente para visualizar padrões de campo elétrico” e atende às
seguintes propriedades (SERWAY; JR., 2004a):
• O vetor campo elétrico E é tangente à linha do campo elétrico em
cada ponto.
• O número de linhas do campo elétrico por unidade de área através de
uma superfície, que é perpendicular às linhas, é proporcional à
magnitude do campo elétrico nesta região.
A conveniência deste modelo torna possível a avaliação qualitativa da
intensidade do campo com base na densidade das linhas. Quando as linhas estiverem
próximas uma das outras, o campo será maior do que quando as linhas estiverem
afastadas.
A terceira representação é a das superfícies equipotenciais. Elas são áreas
formadas por pontos que apresentam mesmo potencial elétrico, que é “a energia
potencial U do sistema por unidade de carga” (SERWAY; JR., 2004b). O movimento
das cargas de prova pode ser avaliado com base na diferença de potencial elétrico.
Modelos desenhados em duas dimensões são suficientes para alguns propósitos.
Por exemplo, pela Figura 1, pode-se concluir que o campo elétrico é mais intenso
próximo às cargas devido a maior concentração de linhas de força.
Figura 1. Linhas de
Mas esta representação não possibilita a visualização d
do campo elétrico. O mesmo
linhas fechadas representam pontos de mesmo potencial
comumente apresentadas como superfícies e
superfícies equipotenciais. As superfíc
Figura 2. Superfícies E
Os movimentos de cargas sob a ação do
Figura 3, são representados
geradora puntiforme positiva e
prova positiva seja colocada
horizontal e sentido para a direita e
repulsão. Mas o movimento
Figura 1. Linhas de Força do Campo Elétrico de Cargas Puntiformes
Mas esta representação não possibilita a visualização do caráter tridimensional
O mesmo acontece em relação ao potencial elétrico. Na F
entam pontos de mesmo potencial, mas, de modo errôneo, s
apresentadas como superfícies equipotenciais. Elas são secções de
. As superfícies são tridimensionais, neste caso.
ura 2. Superfícies Equipotenciais e Linhas de Força
Os movimentos de cargas sob a ação do campo elétrico são outro problema.
são representados os vetores campo elétrico nos pontos P para uma carga
positiva e outra negativa, respectivamente. Caso uma carga de
seja colocada no primeiro ponto P, a força que atuará nela terá direção
horizontal e sentido para a direita e a carga vai se afastar da fonte porque a força será de
o movimento será retilíneo ou curvilíneo? Será acelerado, retardado ou
15
untiformes
o caráter tridimensional
létrico. Na Figura 2, as
, de modo errôneo, são
las são secções de
são tridimensionais, neste caso.
são outro problema. Na
P para uma carga
aso uma carga de
, a força que atuará nela terá direção
porque a força será de
? Será acelerado, retardado ou
uniforme? A conclusão depende de conhecimento da matemática do fenômeno
força elétrica depende do quadrado da distância, o aumento desta
diminuição daquela. A aceleração é proporcional à força
de Newton. Então, ela também diminui, mas continua agindo na direção horizontal, da
esquerda para a direita. Assim, o movimento
Figura 3. Campo Elétrico Criado por
Haveria, então, uma
visualização de modelos tridimensionais
2.2 Laboratórios Virtuais
São evidentes as mudança provocada
é um dos principais exemplos. Ela
realizam compras, como fazem transações comerciais
mudanças se refletiram também na área da educação. Hoje, é possível estudar e ensinar
à distância. As instituições de ensino estão se inserindo cada vez mais nesta nova
realidade, apoiando-se em recursos oriundos das novas tecnologias para compleme
o processo de ensino e aprendizagem
Durante décadas, pesquisadores têm sido desafiados pela investigação do
aprendizado de conceitos científicos com auxílio de computadores. Os resultados,
muitas vezes, têm se mostrado be
uniforme? A conclusão depende de conhecimento da matemática do fenômeno
força elétrica depende do quadrado da distância, o aumento desta
diminuição daquela. A aceleração é proporcional à força, de acordo com a Segunda Lei
ela também diminui, mas continua agindo na direção horizontal, da
esquerda para a direita. Assim, o movimento será retilíneo e acelerado.
Figura 3. Campo Elétrico Criado por Cargas Puntiformes
a ferramenta que pudesse suprir ambas as necessidades
tridimensionais e dos movimentos de cargas de prova
Laboratórios Virtuais
mudança provocadas na sociedade pelo uso do computador
é um dos principais exemplos. Ela alterou de maneira radical o modo como a
realizam compras, como fazem transações comerciais e até como se relacionam.
mudanças se refletiram também na área da educação. Hoje, é possível estudar e ensinar
As instituições de ensino estão se inserindo cada vez mais nesta nova
se em recursos oriundos das novas tecnologias para compleme
o processo de ensino e aprendizagem (AUDINO; NASCIMENTO, 2010)
Durante décadas, pesquisadores têm sido desafiados pela investigação do
aprendizado de conceitos científicos com auxílio de computadores. Os resultados,
muitas vezes, têm se mostrado benéficos especialmente em relação ao uso de
16
uniforme? A conclusão depende de conhecimento da matemática do fenômeno. Como a
força elétrica depende do quadrado da distância, o aumento desta, implica na
, de acordo com a Segunda Lei
ela também diminui, mas continua agindo na direção horizontal, da
Puntiformes
necessidades – a
de prova?
pelo uso do computador. A Internet
como as pessoas
e até como se relacionam. E estas
mudanças se refletiram também na área da educação. Hoje, é possível estudar e ensinar
As instituições de ensino estão se inserindo cada vez mais nesta nova
se em recursos oriundos das novas tecnologias para complementar
(AUDINO; NASCIMENTO, 2010).
Durante décadas, pesquisadores têm sido desafiados pela investigação do
aprendizado de conceitos científicos com auxílio de computadores. Os resultados,
néficos especialmente em relação ao uso de
17
simuladores por causa das representações gráficas animadas. Elas parecem ser
internalizadas durante o processo de aprendizado (SERRANO; ENGEL, 2012).
O ambiente de aprendizagem tem se tornado um espaço lúdico, enriquecedor e
motivador com o uso da informática educativa, ajudando o educando na construção de
conhecimento científico e crítico (LIMA, 2012).
Neste contexto, surgiram os objetos de aprendizagem. Eles são desenvolvidos
com propósito educacional e elaborados em uma base tecnológica, sendo dinâmicos,
interativos, reutilizáveis e não dependendo de plataforma específica para funcionar.
(AUDINO; NASCIMENTO, 2010).
Estas características se harmonizam com o paradigma de orientação a objetos,
cujo propósito é a produção de recursos computacionais baseados em objetos que se
relacionam entre si, facilitando o reuso e a manutenção, e também com linguagens de
programação que possibilitem a construção de sistemas multiplataforma, a exemplo de
Java.
Os laboratórios reais mostram de forma visual as interações entre cargas
elétricas. Mas eles não fazem isto para os modelos que auxiliam na explicação de tais
interações.
Estas afirmações não querem dizer que os simuladores sejam capazes de suprir
todas as necessidades de suporte ao processo de ensino e aprendizagem de Física e,
consequentemente, de campo elétrico, mas apontam para sua adequação.
3. Conceitos Básicos
18
3.1 Orientação a Objetos
Nos anos 70, utilizava-se o termo crise do software para expressar as dificuldades
envolvidas no desenvolvimento de sistemas em comparação com a demanda cada vez
maior. A forma de programar dificultava o reaproveitamento e a manutenção de código.
Suponhamos que um simulador para fórmula 1 tivesse que ser desenvolvido.
Uma das funções necessárias seria acelerar. Dentro desta função, deveria ser
determinado um valor de velocidade máxima. Suponhamos ainda que a equipe
responsável por este software também tivesse um projeto de desenvolvimento de um
simulador para autoescolas. Naturalmente, haveria muitas diferenças entre ambos, mas
também semelhanças, como o fato de que qualquer carro tem que acelerar. Assim, um
código mais genérico seria aproveitado por ambos os programas e por todos outros que
precisassem de tal funcionalidade. Daí surgiu a ideia do desenvolvimento de programas
com base em objetos, que são unidades responsáveis pelo armazenamento de estado e
desencadeador de ações focadas em um propósito específico e que se relacionam entre
si para formar o sistema.
Para que uma linguagem seja considerada orientada a objetos, precisa
implementar quatro conceitos elementares (PIZZOLATO, 2008):
• Abstração: habilidade de modelar características do mundo real;
• Encapsulamento: habilidade da unidade de proteger os dados e
permitir que apenas suas operações internas tenham acesso a eles;
• Herança: mecanismo que permite: a) a criação de novos objetos
através da modificação de algo que já existe e b) o vínculo do objeto
criado com o objeto antigo. É um conceito muito conhecido da
natureza;
• Polimorfismo: capacidade de uma unidade ter várias formas.
Assim como o hardware é composto por vários elementos, como placa mãe,
processador, fonte, memória, entre outros, o programa desenvolvido com base neste
paradigma é composto por vários módulos, ou classes, que dão origem aos objetos. O
19
ideal é que as classes sejam elaboradas com objetivos bem específicos, levando a alta
coesão, e cujos relacionamentos ocorram por intermédio de suas interfaces, levando a
baixo acoplamento (BATES; SIERRA, 2006), já que alta coesão e baixo acoplamento
cooperam para se obter melhor reaproveitamento de código e facilitar sua manutenção.
Além disto, colocar as classes dentro de pacotes evita problemas, tais como colisão
(BATES; SIERRA, 2010).
3.2 Java
Em 1991, a Sun financiou um projeto de pesquisa desenvolvido por uma equipe
liderada por James Gosling que resultou em uma linguagem baseada em C++ que ele
chamou de Oak, homenageando um carvalho que podia ser visto de seu escritório na
Sun. Este nome teve que ser modificado, porque ele já estava sendo utilizado por outra
linguagem. O nome Java surgiu em uma cafeteria, emprestado da cidade de origem de
um dos cafés importados (DEITEL. P.; 2010), (DEITEL. H.; 2010).
O objetivo inicial da linguagem era dar suporte a pequenos dispositivos
destinados ao consumidor final, tais como vídeo cassete, televisão e aparelhos de TV a
cabo, mas a ideia não deu certo. Houve a tentativa do fechamento de contratos com
grandes fabricantes como a Panasonic, porém conflitos de interesses e custos não
permitiram que isto se concretizasse. Mas o advento da web e a necessidade de tornar
suas páginas dinâmicas abriu um campo de uso para o Java. A versão 1.0 foi lançada
com o objetivo de dar capacidade ao browser de realizar operações mais avançadas e
não apenas renderizar um página HTML (CAELUM, 2012).
Para que um código fonte escrito em Java possa funcionar é necessário que ele
seja compilado e transformado em bytecodes. Estes bytecodes são executados pela JVM
– máquina virtual. Há uma JVM para cada plataforma, tornando Java uma linguagem
multiplataforma e este é um dos motivos do seu sucesso, até a época da escrita desta
monografia, além da ampla documentação disponível e da extensa gama de fóruns sobre
seus aspectos.
20
3.3 Reengenharia de Software
Os sistemas de informação são dinâmicos. Eles entram em estados de contínuas
mudanças a partir do momento em que começam a funcionar (PIEKARSKI; QUINÁIA,
2000).
As adaptações pelos quais eles devem passar não estão relacionadas
simplesmente à correção de erros, mas também às mudanças necessárias decorrentes da
identificação da necessidade de novas funcionalidades, adaptação a novas tecnologias, a
busca por melhora de desempenho, entre outros, sendo assim, inevitáveis
(ESTEINMACHER et al., 2006).
No caso de sistemas escritos em Java, além da complexidade, um código que
não atende aos princípios básicos da orientação a objetos, como a construção de classes
pouco coesas e altamente acopladas, como já sugerido, dificulta o reaproveitamento
(reusabilidade) e a manutenção (manutebilidade).
Existem métricas relacionadas a estes conceitos e ferramentas que as calculam,
que ajudam na tarefa de avaliação da qualidade de um código fonte. Duas destas
ferramentas são o SourceMonitor e o Metrics e podem ser usadas de forma
complementar.
O SourceMonitor calcula métricas de sistemas escritos em várias linguagens,
entre elas, Java. O conjunto de métricas para esta linguagem é apresentado na Tabela 1.
MÉTRICA DEFINIÇÃO AVALIAÇÃO DO
VALOR
Lines Número de linhas de
código
Quanto maior seu valor,
maior a complexidade do
sistema.
Statements Número de todas as
declarações terminadas
com ponto e vírgula,
Quanto maior seu valor,
maior a complexidade do
sistema.
21
declarações de métodos e
da classe, além daquelas
que apresentam if, for,
while, try, catch e finally,
entre outros.
Percent Branch Statements
(% Branches)
É o percentual de
declarações, em relação ao
total, que provocam quebra
na sequência de execução,
como if, else, for, do,
while, break, continue,
switch, case, default, try,
catch, finally e throw.
Quanto maior seu valor,
maior a complexidade do
sistema.
Method Call Statements
(Calls)
É o total de chamadas a
métodos.
Valores grandes sugerem
alta complexidade, porém o
programa não leva em
consideração a convenção
JavaBeans, contando os
getters e setters.
Percent Lines with
Comments (% Comments)
Percentual de linhas com
comentários em relação ao
total de linhas de código.
De acordo com a ajuda do
programa, o valor deve
ficar entre 8 e 20 por cento.
Classes and Interfaces
(Classes)
Total de classes e
interfaces.
Quanto maior seu valor,
maior a complexidade do
sistema.
Methods per Classes Razão entre o total de
métodos pelo total de
classes.
De acordo com a ajuda do
programa, o valor deve
ficar entre 4 a 16, porém o
22
programa não leva em
consideração a convenção
JavaBeans, contando os
getters e setters.
Average Statements per
Methods (Avg
Stmts/Method)
Razão entre o total de
declarações dentro dos
métodos e o total de
métodos.
De acordo com a ajuda do
programa, o valor deve
ficar entre 6 a 12. A ideia é
concatenar ao método
chamador métodos com
valor inferior a 6 e
fragmentar métodos com
valor superior a 12.
Maximum Complexity
(Max Complexity)
É a maior complexidade
entre os métodos. A
complexidade é iniciada
com valor 1 é
incrementada a cada if,
else, for, foreach, while,
operador ternário, cada
case em switch
(duplamente se houver
declarações break, goto,
return, throw, continue),
cada catch ou except
dentro do bloco try, mas
não declarações try ou
finally.
De acordo com a ajuda do
programa, o valor deve
ficar entre 2 a 8. A
estratégia de melhoria é a
mesma da métrica anterior.
Maximum Block Depth
(Max Depth)
Profundidade máxima de
uma declaração. A cada
aninhamento, a
De acordo com a ajuda do
programa, o valor deve
ficar entre 3 a 7.
23
profundidade é acrescida
de 1.
Average Block Depth (Avg
Depth)
É a média ponderada da
profundidade de bloco de
todas as declarações no
arquivo.
De acordo com a ajuda do
programa, o valor deve
ficar entre 1 a 2.2.
Average Complexity (Avg
Complexity)
Razão entre a soma de
todas as complexidades
pelo total de métodos.
De acordo com a ajuda do
programa, o valor deve
ficar entre 2 a 4.
Tabela 1. Métricas Calculadas pelo SourceMonitor
O Metrics, que é um plugin do IDE - ambiente integrado de desenvolvimento –
Eclipse, calcula o seguinte conjunto de métricas, permitindo avaliação da complexidade
do código e do design de pacotes: Total Lines of Code (LOC), Number of Static
Methods (NSM), Number of Classes (NOC), Specialization Index (SIX), Number of
Attributes (NOF), Number of Packages (NOP), Method Lines of Code (MLOC),
Weighted Methods per Class (WMC), Number of Overridden Methods (NORM),
Number of Static Attributes (NSF), Nested Block Depth (NBD), Number of Methods
(NOM), McCabe Cyclomatic Complexity (VG), Number of Parameters (PAR), Number
of Interfaces (NOI), Number of Children (NSC), Depth of Inheritance Tree (DIT), Lack
of Cohesion of Methods (LCOM) (relacionadas a complexidade do código), Afferent
Coupling (CA), Normalized Distance (RMD), Abstractness (RMA), Efferent Coupling
(CE) e Instability (RMI) (relacionadas ao design de pacotes). Dentre elas, LOC e NOC
já foram apresentadas. As restantes significam o seguinte:
• Number of Static Methods (NSM) – número de métodos estáticos.
• Afferent Coupling (CA) - O acoplamento aferente representa o número de
classes e interfaces de outros pacotes que dependem das classes do pacote em
questão.
24
• Normalized Distance (RMD) - é uma medida que leva em consideração a
abstração (A) e a instabilidade (I). Ela pode ser calcula pela fórmula │(A + I –
1)│, variando, deste modo, entre 0 e 1. Projetos com melhores designs são
aqueles cuja distância é mínima, próxima a zero, significando maior facilidade
para reexame e reestruturação (MARTIN, 1994).
• Instability (RMI) - É a razão entre o acoplamento eferente e a sua soma com o
acoplamento aferente. Se acoplamento aferente e eferente tiverem valor 0 a
instabilidade será indeterminada. Como alternativa, pode-se atribuir o valor 1,
como realizado pela ferramenta. Este valor indica a maior instabilidade e 0, a
menor. Instabilidade 0 quer dizer que o pacote não depende de outros pacotes do
sistema, mas outros pacotes dependem dele. Para evitar que mudanças nas
classes deste pacote se propagem nas classes dos outros pacotes, usa-se o
polimorfismo, para o qual são necessárias as classes abstratas e interfaces.
Assim, menor instabilidade demanda maior abstração e vice-versa.
• Specialization Index (SIX) – é definida como nº de métodos sobrescritos *
profundidade na árvore de herança / nº total de métodos.
• Number of Attributes (NOF) – número de atributos.
• Number of Packages (NOP) – número de pacotes.
• Methods Lines of Code (MLOC) – número total de linhas de código dentro do
corpo de métodos, excluindo comentários e linhas em branco.
• Weighted Methods per Class (WMC) – soma das McCabe Cyclomatic
Complexity de todos os métodos.
• Number of Overridden Methods (NORM) – número de métodos sobrescritos.
• Number of Static Attributes (NSF) – número de atributos estáticos.
25
• Nested Block Depth (NBD) – profundidade de aninhamento do bloco dentro de
um método.
• Number of Methods (NOM) – número de métodos.
• Lack of Cohesion of Methods (LCOM) – avalia a coesão de uma classe. A
ferramenta usa o método de Henderson-Sellers para fazer seu cálculo. Um valor
próximo a zero indica uma classe coesa e um valor próximo de 1 indica falta de
coesão.
• McCabe Cyclomatic Complexity (VG) – calculada apenas para métodos, é
incrementada em 1 para cada cláusula responsável por um desvio de fluxo, como
if, for, while, do, case, catch, operador ternário, & & e | |, operadores de lógica
condicionais em expressões.
• Number of Parameters (PAR) – número de parâmetros por método.
• Abstractness (RMA) - é calculada pela razão entre a quantidade de classes
abstratas e interfaces do pacote por suas classes concretas. Seu valor varia entre
0 e 1. Como visto, sua importância depende da instabilidade e ambos
possibilitam o cálculo da distância.
• Number of Interfaces (NOI) – número de interfaces.
• Efferent Coupling (CE) – número de classes e interfaces dentro do pacote que
dependem de classes e interfaces de outros pacotes.
• Number of Children (NSC) – número de subclasses diretas de uma classe.
• Depth of Inheritance Tree (DIT) - distância entre a classe em questão e a
classe Object na hierarquia de herança.
26
Basicamente, o desenvolvimento de um software envolve a descrição dos
requisitos que explicitam os objetivos que ele pretender atender, a construção de um
modelo com nível de abstração alto, ou seja, um modelo genérico, e etapas subsequentes
para diminuição do nível de abstração até que o sistema em funcionamento seja
alcançado. Este fluxo de atividades, simplificadamente, é conhecido como engenharia
progressiva.
Quando, por exemplo, um sistema precisa passar por manutenção, os
responsáveis por ela não serão, necessariamente, aqueles envolvidos em seu
desenvolvimento e é possível que a documentação não seja suficiente para tornar claros
seus mecanismos. Será necessária, então, uma estratégia diferente que leve ao
entendimento do sistema. Esta é uma das necessidades que dá lugar à engenharia
reversa.
Generalizando, a engenharia reversa deve ser capaz de originar representações
subsequentes de níveis de abstração cada vez mais altos, oferecendo ao responsável,
subsídios para entendimento mais fácil do programa (PRESSMAN, 2006).
A reengenharia, deste modo, se baseia na “desmontagem” do sistema pelas
técnicas da engenharia reversa e na “remontagem”, visando atender às novas
necessidades, pelas técnicas da engenharia progressiva.
Caso o código fonte do sistema não esteja disponível, a análise das
funcionalidades possibilita a criação de modelos genéricos a partir dos quais o novo
código é escrito. Com acesso ao código, há a possibilidade de associação entre as
funcionalidades e os respectivos trechos de código e as mudanças daquelas são
realizadas com a alteração destes. Ou então, pode-se adotar uma estratégia que mescle
as duas anteriores – novos modelos de alto nível de abstração são criados e, na
implementação, aproveitam-se trechos de código prontos.
27
4. Reengenharia do 3D – Vector Fields Applet V 1.3
4.1 Levantamento de Requisitos
Como visto no capítulo 2, simulações computacionais podem dar suporte adequado ao
processo de ensino e aprendizagem de campo elétrico em nível médio no Brasil. Para
isto, o simulador precisa1: (a) ser gratuito, para torná-lo mais acessível; (b) possuir
interface atraente que facilite o seu uso; (c) fazer apresentações tridimensionais, para
melhorar a visualização, dinâmicas e interativas, a fim de que sejam estimulantes; (d)
ter nível de complexidade ajustado ao ensino médio brasileiro, no qual está inserido o
público alvo, (e) não ser dependente de plataforma específica, permitindo que seu uso
seja mais abrangente e (f) ser desenhado de tal maneira que facilite a manutenção e o
reuso.
4.2 Engenharia Reversa
4.2.1 Análise das Funcionalidades
O objetivo da simulação é apresentar interações entre o campo elétrico gerado por
diferentes fontes e um conjunto variável de cargas de prova, e seus modelos
representativos.
1 Os requisitos foram levantados pelo autor da monografia, fazendo papel de um cliente interessado em
financiar o projeto, tal como a Sociedade Brasileira de Física.
28
Figura 4. Opções de Fontes Geradoras
Na Figura 4, uma carga geradora central (a) cria um campo elétrico que atrai
cargas de prova (b) liberadas dentro do cubo. Nesta configuração, as cargas de prova
adquirem movimento acelerado, aproximando-se da carga geradora, de modo
semelhante ao que ocorreria em um experimento real, admitindo-se que as cargas de
prova não interagem umas com as outras.
Algumas destas fontes geram interações e modelos que estão além do escopo do
ensino médio brasileiro, conforme os modelos apresentados em livros didáticos e com
base na experiência de 20 anos do autor desta monografia, na época em que foi escrita,
como professor de Física no ensino médio e cursos preparatórios. Assim, o requisito (d)
apresentado no item 4.1 não é atendido.
b
a
29
Todas as interações são apresentadas dentro de um cubo que pode ser
rotacionado ou ter suas dimensões alteradas. Para um ou para outro, escolhe-se uma das
opções apontadas pela Figura 5, respectivamente, e então, posiciona-se o cursor do
mouse com o botão esquerdo pressionado sobre o cubo, movimentando-o.
Figura 5. Ajuste do Cubo – Rotação ou Alteração das Dimensões
.
O menu display permite que a influência das fontes sobre as cargas de prova seja
verificada por meio das representações apontadas pela Figura 6.
30
Figura 6. Representações do Campo Elétrico e Tipos de Interação
Com a opção Particles (Vel), o movimento das cargas ocorre sobre as linhas de
força, como se elas não interagissem entre si. Com Particles (Force) o movimento
ocorre levando-se em consideração a influência das cargas de prova uma sobre as
outras. Field Vectors possibilita a visualização do conjunto de vetores campo elétrico ao
redor das fontes geradoras, como mostra a Figura 7.
31
Figura 7. Vetores Campo Elétrico
Houve alteração nas barras de rolagem. A barra Number of Particles, que
controla o número de partículas, foi substituída por Vector Density, responsável pela
alteração da quantidade de vetores campo elétrico apresentada.
Na Figura 8, é mostrado o resultado da opção Field Lines. Como anteriormente,
a barra Field Strenght, que controla a intensidade do campo elétrico é disponibilizada e
a barra Vector Density é alterada para Field Line Density, responsável pela alteração da
quantidade de linhas de força apresentada.
32
Figura 8. Linhas de Força
Já a opção equipotentials, combinada com a nova barra potentials, possibilita a
visualização das superfícies equipotenciais ao redor da fonte geradora. Um exemplo é
mostrado na Figura 9.
33
Figura 9 – Superfícies Equipotenciais
É possível que as visualizações sejam feitasem duas dimensões, a exemplo do
que mostra a Figura 10. Com esta opção, quando o curso do mouse é colocado sobre um
dos lados do plano de visualização, tais lados adquirem cor amarela e o plano pode ser
movido com o curso pressionado sobre qualquer um deles.
34
Figura 10. Visualização 2D
A Figura 10 também permite a observação da opção Stopped, que estaciona a
simulação, a opção Reverse, que muda o sinal das cargas que compõe a fonte geradora e
Reset, que reinicia o movimento das partículas. Kick fica disponível para visualização
do movimento real das partículas. Quando acionado, as partículas são desordenadas.
4.2.2 Análise da Interface
Para o usuário, a interface é um aspecto importante de um programa porque é aquilo que
ele vê e é por intermédio dela que ocorre a interação. Para ele, o sistema acaba sendo a
própria interface. (ANACLETO; VILLENA, 2009).
Por isto, a má compreensão dos elementos da interface com usuário prejudica o
uso do sistema, mesmo que ele opere de modo correto. E o aspecto visual pode torná-lo
mais ou menos atrativo.
35
A análise intuitiva da interface é feita com a Figura 11. Assim, as modificações
propostas levam a resultados que precisam ser verificados, por exemplo, por testes de
usuário. Tais testes se concentrariam na avaliação da facilidade de uso do sistema antes
e depois das modificações por estudantes e professores do ensino médio brasileiro e na
escolha do sistema com “melhor visual”.
Figura 11. Interface Original
O menu encontra-se ao lado direito da figura. O objetivo da primeira caixa é a
seleção de diferentes configurações para fontes geradoras de campo elétrico, como já
visto. Ele fica claro com o título – Field selection (seleção do campo, ou seja, seleção da
fonte geradora do campo) – mas qual seria o objetivo da segunda caixa de seleção? E
das outras caixas? Assim, cada elemento de seleção pode apresentar um título e/ou uma
breve explicação com o posicionamento do cursor para que o usuário saiba exatamente
o papel de cada um deles.
36
A disposição dos elementos também pode ser modificada. Não há espaço entre
eles. Há a possibilidade de que os créditos sejam acionados a partir de um novo botão e
estes botões serem colocados um ao lado do outro. O menu ser escrito em Língua
Portuguesa e seus elementos terem seu aspecto visual modificado, para que as caixas
tenham cantos arredondados, os botões tenham ícones, entre outros.
4.2.3 Análise da Estrutura
O código original2 é escrito em Java e se encontra em apenas um arquivo chamado
base.java. Nele, há sete classes: Vec3DemoCanvas, Vec3DemoLayout, Vec3Demo,
Vec3DemoFrame, ExprState, Expr e ExprParser.
A classe Vec3DemoFrame usa blocos de pré-processamento, é uma extensão da
classe Frame, dependendo, assim de código nativo para definir os componentes da
interface gráfica e implementa as interfaces ComponentListener, ActionListener,
AdjustmentListener, MouseMotionListener, MouseListener e ItemListener. Ela possui
classes internas que podem ser classificadas em dois tipos – um, para auxílio a tarefas
como a disponibilização de itens do menu conforme a opção escolhida e outro para a
criação das fontes geradoras de campo elétrico.
Vec3Demo é um applet que implementa a interface ComponentListener. Na
interface do applet são apresentadas informações sobre o andamento da simulação e ele
recebe uma referência da classe Vec3DemoFrame para chamar o método init a fim de
que o simulador seja apresentado em uma janela separada.
Vec3DemoCanvas é uma extensão da classe Canvas. Ela cria a área retangular
onde é desenhado o cubo dentro do qual acontecem as interações. Ao ser instanciada,
recebe referência a um objeto Vec3DemoFrame. Nos métodos sobrescritos paint e
2 Este código, como comentado na introdução, está disponível no CD anexado.
update, ela usa a referência a este objeto para chamar o método
partir do qual os elementos da simulação são inseridos na área citada.
Vec3DemoLayout é uma implementação da interface LayoutManager,
possibilitando posicionamento e dimensionamento
container, os quais são a área de apre
Isto é realizado a partir da classe Vec3DemoFrame, que chama o método setLayout,
usando com argumento uma nova instância de
As classes ExprState
as classes internas a Vec3DemoFrame
entrada de dados em campos de textos quando as fontes user
defined function são escolhidas pelo usuário.
O código da classe Vec3DemoFrame “cheira mal”. Ela é muito grande e
desempenha muitas funções. Para torna
SourceMonitor 3 e o Metrics
Figura 12
Estas métricas mostram que a
do sistema. Ela possui a ordem de milhares de linhas de código em contrapartida às
outras classes que possuem ordem de dezenas, assim como o número de declarações e
3 O Metrics poderia ter sido a única ferramenta utilizada
de algumas métricas em gráficos Kiviat
referência a este objeto para chamar o método updateVec3Demo
partir do qual os elementos da simulação são inseridos na área citada.
Vec3DemoLayout é uma implementação da interface LayoutManager,
possibilitando posicionamento e dimensionamento personalizado aos compo
os quais são a área de apresentação das simulações e os elementos do menu
Isto é realizado a partir da classe Vec3DemoFrame, que chama o método setLayout,
usando com argumento uma nova instância de Vec3DemoLayout.
ExprState, Expr e ExprParser combinam seus papéis para auxiliarem
as classes internas a Vec3DemoFrame UserDefinedPotential e UserDefinedFunction
entrada de dados em campos de textos quando as fontes user-defined potential e user
function são escolhidas pelo usuário.
O código da classe Vec3DemoFrame “cheira mal”. Ela é muito grande e
desempenha muitas funções. Para tornar esta análise mais precisa, foram
e o Metrics. A Figura 12 apresenta os valores para as métricas
igura 12. Métricas (SourceMonitor) do Código Original
Estas métricas mostram que a classe Vec3DemoFrame representa
possui a ordem de milhares de linhas de código em contrapartida às
outras classes que possuem ordem de dezenas, assim como o número de declarações e
a única ferramenta utilizada. Porém, o SourceMonitor permite em gráficos Kiviat, o que é apresentado no item 4.3.6.
37
updateVec3Demo, a
Vec3DemoLayout é uma implementação da interface LayoutManager,
personalizado aos componentes do
sentação das simulações e os elementos do menu.
Isto é realizado a partir da classe Vec3DemoFrame, que chama o método setLayout,
combinam seus papéis para auxiliarem
UserDefinedFunction na
defined potential e user-
O código da classe Vec3DemoFrame “cheira mal”. Ela é muito grande e
r esta análise mais precisa, foram usados o
métricas.
. Métricas (SourceMonitor) do Código Original
representa o ponto crítico
possui a ordem de milhares de linhas de código em contrapartida às
outras classes que possuem ordem de dezenas, assim como o número de declarações e
permite a visualização
38
chamadas a métodos. É a causa da máxima complexidade e tem 91 classes internas.
Estas classes internas estão fortemente acopladas à classe externa porque compartilham
variáveis não encapsuladas com ela.
A coesão pode ser avaliada com a métrica Lack of Cohesion of Methods. O
plugin Metrics do Eclipse, como já comentado no item 3.3, faz isto, porém, para
funcionar, é necessário que o projeto seja construído, e os blocos de pré-processamento
dificultam esta tarefa. Eles foram retirados no primeiro ciclo da engenharia progressiva.
Antes, são sintetizados os resultados da engenharia reversa para definição inicial dos
outros ciclos da engenharia progressiva.
4.2.4 Resumo dos Resultados da Engenharia Reversa
A engenharia reversa do sistema mostra, inicialmente, que a classe Vec3DemoFrame
precisa ser fragmentada, as fontes geradoras cujas interações e modelos requerem uma
análise com profundidade que está além do escopo do ensino médio devem ser retiradas
e a interface pode ser modificada. Estes apontamentos determinaram, a princípio, os
ciclos utilizados na engenharia progressiva, além da retirada dos blocos de pré-
processamento.
4.3 Engenharia Progressiva
4.3.1 1º ciclo – Retirada dos Blocos de Pré-Processamento
Estes blocos foram retirados para que Vec3DemoFrame pudesse ser fragmentada e para
o uso do Metrics, como já citado. Para garantir a não geração e propagação de erros e
agilizar o processo de análise do código, uma ferramenta de geração de código a partir
dos arquivos .class chamada DJ Java Decompiler 3.11 foi usada. Os .java obtidos foram
comparados com as classes do programa original. Estes .java, com exceção de
Vec3DemoLayout.java, não foram utilizados como ponto de partida da modificação do
código porque a ferramenta, apesar de ter mantido a lógica original, gerou uma perda
semântica das variáveis de instância, de classe e locais, na maioria dos casos.
Estes blocos afetam
exemplo, Equipotentials) e a instanciação de
foram testadas para certificação de que erros
Neste ponto, há a possibilidade da análise da perda de coesão
classes e, em especial, de Vec3DemoFrame. A Figura 13 mostra os resultados.
Figura 13. Perda de Coesão das Classes do Sistema Ori
Analisando a coluna mais à direita, concluí
Expr, Vec3DemoCanvas, ExprState são coesas
Vec3DemoFrame não é, pois o valor é próximo a 1
calculadas pelo SourceMonitor
reaproveitada.
4.3.2 2º ciclo – Modificação
A classe AuxBar não usa métodos
eliminada de sua classe externa, de maneira automática,
mover de interno para nível externo
Particle, DrawData, EquipPoint
porque a ferramenta, apesar de ter mantido a lógica original, gerou uma perda
e instância, de classe e locais, na maioria dos casos.
Estes blocos afetam, basicamente, a escolha do tipo de evento apresentado (por
exemplo, Equipotentials) e a instanciação de algumas fontes. Estas funcionalidades
certificação de que erros não foram criados.
Neste ponto, há a possibilidade da análise da perda de coesão dos métodos
Vec3DemoFrame. A Figura 13 mostra os resultados.
Figura 13. Perda de Coesão das Classes do Sistema Ori
Analisando a coluna mais à direita, concluí-se que as classes Vec3DemoLayout,
Expr, Vec3DemoCanvas, ExprState são coesas pois o valor da métrica é 0
c3DemoFrame não é, pois o valor é próximo a 1. Esta métrica, juntamente com as
pelo SourceMonitor, mostram que a classe é difícil de ser mantida e
Modificação da Classe Vec3DemoFrame
A classe AuxBar não usa métodos e nem variáveis de Vec3DemosFrame. Então,
eliminada de sua classe externa, de maneira automática, com a função refatorar
mover de interno para nível externo do netbeans 7.2. O mesmo foi feito
, EquipPoint e Complex. No caso desta última, ela utilizava
39
porque a ferramenta, apesar de ter mantido a lógica original, gerou uma perda
e instância, de classe e locais, na maioria dos casos.
a escolha do tipo de evento apresentado (por
stas funcionalidades
dos métodos das
Vec3DemoFrame. A Figura 13 mostra os resultados.
Figura 13. Perda de Coesão das Classes do Sistema Original.
se que as classes Vec3DemoLayout,
pois o valor da métrica é 0 e que
métrica, juntamente com as
, mostram que a classe é difícil de ser mantida e
de Vec3DemosFrame. Então, ela foi
com a função refatorar ->
O mesmo foi feito com as classes
e Complex. No caso desta última, ela utilizava dois
40
métodos de Vec3DemoFrame que lhe eram exclusivos e, por este motivo, foram
movidos para aquela.
Antes das classes internas responsáveis pelas fontes geradoras serem movidas,
como várias fontes levam a complexidade além do escopo do ensino médio, decidiu-se,
primeiramente, pela retirada destas fontes, para atender ao requisito (d) do item 4.1.
Todas as classes das fontes geradoras são subclasses da classe abstrata
VecFunction. Esta estratégia tem o propósito de usar o polimorfismo, como mostra o
trecho de código abaixo:
functionList = new Vector();
VecFunction vf = new InverseSquaredRadial();
while (vf != null) {
functionList.addElement(vf);
vf = vf.createNext();
}
InverseSquaredRadial é instanciada. Seu método createNext instancia a próxima
classe e isto vai se repetindo até que o método createNext da última classe retorna null e
a iteração é encerrada. As classes que geravam fontes não mais utilizadas foram
excluídas com o cuidado para não se excluir membros usados por subclasses que
permaneceriam. Por isto, os elementos que eram herdados passaram a fazer parte
diretamente das classes mantidas. A classe anterior à retirada se tornou responsável pela
criação de instância da primeira classe após a retirada.
Esta exclusão fez com que alguns métodos deixassem de ser utilizados. Eles
foram excluídos. As novas fontes são apresentadas na Figura 14.
41
Figura 14. Novas Fontes Geradoras
Da maneira como a lógica original foi desenvolvida, todos os objetos destas
classes são instanciados e armazenados no vetor functionList. Então, percorrendo este
vetor, seus nomes são recuperados para serem disponibilizados na caixa de seleção das
fontes, como mostra o próximo trecho de código.
functionChooser = new Choice();
for (i = 0; i != functionList.size(); i++) {
functionChooser.add(
((VecFunction) functionList.elementAt(i)).getName());
}
Quando selecionado, o objeto é referenciado.
curfunc = (VecFunction)
functionList.elementAt(functionChooser.getSelectedIndex());
42
E os métodos relacionados às funcionalidades da fonte específica são
desencadeados. Esta não é a melhor estratégia porque todos os objetos são instanciados
para que, então, serem usados. É melhor instanciar o objeto quando necessário
Para que os nomes das fontes estejam disponíveis antes da instanciação dos
objetos, um vetor de strings foi criado, inicializando-o com os nomes das fontes
mantidas,
functionName = new String[]{"point charge", "double charge", "dipole",
"finite line", "finite line pair", "finite line dipole", "conducting plate",
"charged plate", "charged plate pair","infinite plane", "conducting sphere in
field", "dieletric sphere in field E", "charged ring", "charged ring pair",
"charged ring dipole"}4;
adicionando-se cada nome na caixa de seleção.
add(new Label("Field selection:"));
functionChooser = new Choice();
for (i = 0; i != functionName.length; i++) {
functionChooser.add(functionName[i].toString());
}
add(functionChooser);
functionChooser.addItemListener(this);
Um bloco switch passou a fazer a verificação da fonte selecionada para poder instanciar
o objeto relativo a esta fonte no momento da escolha do usuário.
switch(functionChooser.getSelectedIndex()){
case 0:
curfunc = (VecFunction) new InverseSquaredRadial(this);
4 Uniform Field, user-defined potential e user-defined field também foram retiradas.
43
break;
case 1:
curfunc = (VecFunction) new
InverseSquaredRadialDouble(this);
break;
case 2:
curfunc = (VecFunction) new
InverseSquaredRadialDipole(this);
break;
case 3:
curfunc = (VecFunction) new FiniteChargedLine(this);
break;
.
.
.
Cada uma das classes foi separada de Vec3DemoFrame. Como elas usavam
métodos desta, a referência this foi enviada na instanciação para poder chamar tais
métodos. Os seus construtores tiveram que ser modificados e, em alguns casos, criados
para receber esta referência e para atender à hierarquia de herança. Além disto, os
métodos createNext e getName foram eliminados.
A classe Particle é responsável pela criação de partículas individuais. Dentro da
classe Vec3DemoFrame, diversos métodos usam instâncias desta classe para criar e
manipular um conjunto de partículas. São eles: moveParticles, drawParticles,
positionParticle, resetParticles, kickParticles e moveParticle. Uma classe chamada
Particles foi criada e estes métodos, transferidos para ela, além da criação do método
createParticles. Como tais métodos usam variáveis de Vec3DemoFrame, uma referência
desta foi passada para aquela. Semelhantemente, foi criada a classe Vectors, onde os
métodos drawVectors e drawVector foram colocados. Seguindo a mesma idéia, também
foram criadas as classes Line – responsável pelas linhas de força, Cube – responsável
pela criação do cubo onde as simulações ocorrem, Constants – onde foram definidas as
44
constantes usadas pelo sistema, EquiPoint e Equipotential – responsáveis pelas
superfícies equipotenciais, AuxActions – responsável por variáveis e métodos comuns a
várias classes e Main, que passou a ser a responsável por iniciar o simulador. Alguns
métodos também foram fragmentados para diminuição de sua complexidade, como por
exemplo, init.
4.3.3 3º ciclo – Supressão de Vec3Demo
Durante os dois primeiros ciclos levantou-se um novo requisito. O objetivo não é criar
uma aplicação que tenha que ser embutida em uma página HTML. Não há a
necessidade que a aplicação seja um applet. A classe Vec3Demo foi eliminada. Como o
desencadear dos eventos começava no método init do applet e ele deixou de existir, a
classe Main passou a chamá-lo, a partir de instância de Vec3DemoFrame. Também foi
necessária a alteração do método handleEvent para não dificultar o fechamento da
janela.
public boolean handleEvent(Event ev) {
if (ev.id == Event.WINDOW_DESTROY) {
applet.destroyFrame();
return true;
}
return super.handleEvent(ev);
}
O trecho em destaque foi substituído por
vec3DemoFrame.dispose();
4.3.4 4º ciclo – Modificação da Interface
No item 4.2.2, foi apontada a proposta de alteração de algumas características da
interface. Estas alterações são apresentadas a partir da Figura 15.
45
Figura 15. Interface em Modificação
Para que os botões fossem colocados um ao lado do outro, alterou-se
Vec3DemoLayout. O método LayoutContainer determina, primeiramente, o
posicionamento da área da simulação (Canvas) e, a partir disto, o posicionamento do
menu. Ambas as larguras dependem da largura do maior elemento do menu. Uma
iteração é feita para se avaliar qual elemento do menu está sendo acrescentado e as
alterações de posição e largura são realizadas. Os elementos diferentes dos botões se
posicionam com espaços verticais entre eles por causa dos labels sem string que são
colocados entre eles em Vec3DemoFrame e que são verificados na iteração,
determinando o acréscimo de uma variável de controle. Nesta iteração, acrescentou-se
46
uma cláusula if-else para verificar-se se o elemento era um botão. Em caso afirmativo, o
seu tamanho é determinado como 1/3 da área do menu, já que são três e o
posicionamento vertical não é alterado para ficarem alinhados. O resultado é
apresentado na Figura 16.
Figura 16. Interface em Modificação 2.
Outra modificação realizada na interface foi a tradução dos componentes
textuais do Inglês para o Português, já que o público alvo será composto, de modo geral,
por estudantes e professores do ensino médio brasileiro, como já sugerido. Esta
modificação foi realizada na classe Vec3DemoFrame. A Figura 17 apresenta o
resultado.
47
Figura 17. Interface em Modificação 3
Para modificação do visual dos elementos da interface, a classe
Vec3DemoFrame deixou de estender Frame para estender JFrame e passou a ser
chamada de Vec3DemoJFrame. Isto possibilitou a troca dos componentes AWT -
Abstract Window Toolkit - para componentes Swing, permitindo adquirirem aparência
definida pela plataforma Nimbus. O método handleEvent deixou de fazer sentido já que
a janela passou a ser fechada por setDefaultCloseOperation
(JFrame.EXIT_ON_CLOSE). A classe Canvas também é um componente AWT. Então,
ela foi transformada, estendendo JComponent, e o método paint foi substituído por
paintComponent. Os itens do menu foram colocados sob um JPanel e seu layout deixou
de ser controlado por Vec3DemoLayout, para ser controlado pela classe BoxLayout.
Aqui, percebe-se um erro estratégico. A modificação da interface ocorreu em duas
48
etapas. Se estas etapas tivessem ocorrido na ordem inversa, não haveria necessidade da
alteração de Vec3DemoLayout, poupando esforço.
4.3.5 5º ciclo – Revisão
Com a revisão do código e das funcionalidades, notou-se que o botão Reiniciar ficava
ativado para opções como Linhas de Força – o que não faz sentido, já que ele está
relacionado ao movimento das partículas. Isto foi corrigido. Opcionalmente, retirou-se a
barra de rolagem responsável pela alteração da intensidade do campo. O gradiente de
cores dos vetores campo elétrico e das linhas de força já sugere que o campo elétrico se
modifica com a distância e o movimento das partículas mostra o aumento de sua
intensidade com a diminuição da distância. Também passaram a serem usados alguns
ícones e textos explicativos ao invés de títulos. A nova interface é apresentada na Figura
18.
49
Figura 18. Nova Interface com Usuário
4.3.6 Métricas para o Simulador Modificado
A Figura 19 apresenta as métricas obtidas pelo SourceMonitor para o simulador
modificado.
Figura 19. Métricas (SourceMonitor) para o Simulador Modificado
Os números mostram que
- (chamada agora de Vec3DemoJFrame)
do item 4.2.3, o número de linhas de código é cerca de 24% da classe original; o
número de declarações, 20%;
máxima, 5% e não há mais classes internas.
respeito de outras métricas.
. Métricas (SourceMonitor) para o Simulador Modificado
Os números mostram que a classe Vec3DemoFrame – ponto crítico da aplicação
(chamada agora de Vec3DemoJFrame) foi simplificada. Comparando com
o número de linhas de código é cerca de 24% da classe original; o
número de declarações, 20%; o número de chamadas a métodos, 27%; a complexidade
o há mais classes internas. A Figura 20 permite melhor visualização a
outras métricas.
50
. Métricas (SourceMonitor) para o Simulador Modificado
ponto crítico da aplicação
Comparando com a Figura 12
o número de linhas de código é cerca de 24% da classe original; o
o número de chamadas a métodos, 27%; a complexidade
permite melhor visualização a
Figura 20. Gráfico Kiviat para Métricas da Classe Vec3DemoJFrame
Ela mostra a necessidade de
classe pode ser justificado pelo fato de que o programa conta o getters e setters
presentes. Apesar disto, há indicação de
a máxima complexidade ainda está fora do
A Figura 21 apresenta
Figura 21. Perda de Coesão de Métodos do Sistema Modificado
. Gráfico Kiviat para Métricas da Classe Vec3DemoJFrame
Ela mostra a necessidade de mais comentários. O alto número de métodos por
classe pode ser justificado pelo fato de que o programa conta o getters e setters
há indicação de quantidade excessiva de variáveis de instância
a máxima complexidade ainda está fora do intervalo desejado.
apresenta a perda de coesão dos métodos calculada pelo Metrics.
. Perda de Coesão de Métodos do Sistema Modificado
51
. Gráfico Kiviat para Métricas da Classe Vec3DemoJFrame
comentários. O alto número de métodos por
classe pode ser justificado pelo fato de que o programa conta o getters e setters
quantidade excessiva de variáveis de instância e
pelo Metrics.
. Perda de Coesão de Métodos do Sistema Modificado
52
A coluna da direita mostra que algumas classes são coesas, como
Vec3DemoJComponent, Cube, Main, entre outras, pois a métrica tem valor 0. Mas
Vec3DemoJFrame não, já que o valor da métrica continua próximo a 1. Ela ainda é
divergente, sendo responsável por várias atividades difusas, ou seja, que não tem
propósito específico comum.
Além disto, a maioria das classes está acoplada a Vec3DemoJFrame, o que pode
ser verificado no javadoc disponível no CD anexado.
5. Conclusões
O Simulador de Campo Elétrico, resultado da reengenharia do 3D – Vector Fields
Applet V1.3, é de código fonte aberto e gratuito, apresenta interações entre fontes
geradoras de campo elétrico e cargas de prova, visualizadas dentro de um cubo que
pode ser rotacionado, dando às simulações caráter tridimensional e dinâmico, e dispõe
de modelos representativos – vetores campo elétrico, linhas de força e superfícies
equipotenciais. A interface com usuário tem seus elementos textuais escritos em Língua
Portuguesa. Acredita-se que seus componentes estejam mais bem distribuídos e seu
aspecto visual seja mais atrativo que o aspecto do simulador original. Tais
características apontam para o sucesso na melhoria da usabilidade, conforme definição
do termo neste trabalho.
A classe Vec3DemoFrame foi fragmentada em classes menores, assim como
alguns de seus métodos; o código foi fatorado e recomentado, métodos depreciados
foram substituídos e fragmentos de código não utilizados foram retirados. Algumas
classes ainda apresentam baixa coesão, inclusive Vec3DemoJFrame, e a maioria
daquelas está altamente acoplada a esta, já que não foram empreendidos esforços na
melhoria do design de comunicação entre as classes. Assim, a melhoria na
extensibilidade, como definida nesta monografia, foi parcialmente alcançada, indicando
53
a dificuldade em adaptar um sistema que não foi projetado adequadamente em termos
de orientação a objetos, aos requisitos deste paradigma.
Apesar das modificações relativas à usabilidade apontarem para sua melhoria,
testes de usuário precisam ser realizados para verificação – o que pode ser feito por
trabalhos futuros. Com estes trabalhos podem ser criadas novas funcionalidades, como a
apresentação da magnitude do campo elétrico nos pontos da região onde as simulações
ocorrem e a opção de apresentação de linhas de força junto com superfícies
equipotenciais. E também a busca pela melhoria da extensibilidade, incluindo projeto
de design de pacotes.
Referências Bibliográficas
AUDINO, D.F.; NASCIMENTO, R.S. Objetos de Aprendizagem – Diálogos entre
Conceitos e uma Nova Proposição Aplicada à Educação. Revista Contemporânea de
Educação. V.5, Nº 10, jul/dez 2010. Disponível em:
<http://www.revistacontemporanea.fe.ufrj.br/index.php/contemporanea/article/view/122
>. Acesso em: 12 out. 2012.
ANACLETO, J. C.; VILLENA, J. M. R. Introdução à interação humano computador.
In:______. Interação humano computador. São Carlos: Compacta, 2009. p. 17 – 42.
BATES, B.; SIERRA, K. Acoplamento e Coesão. In: ______. Certificação Sun para
programador Java 6: Guia de Estudo. Rio de Janeiro: Altabooks, 2006. p. 88 – 90.
BATES, B.; SIERRA, K. Lance seu código. In: ______. Use a cabeça! Java. Rio de
Janeiro: Altabooks, 2010. p. 408 – 421.
54
BRASIL. Ministério da Educação e Cultura. Lei de Diretrizes e Bases da Educação
Nacional, Lei 9.394 de 20/12/1996.
BRASIL. Ministério da Educação e Cultura. Plano Curricular Nacional +Ensino
Médio - Orientações Educacionais Complementares a o s Parâmetros
Curriculares Nacionais: Ciências da Natureza, Matemática e suas Tecnologias.
Disponível em:
< http://portal.mec.gov.br/seb/arquivos/pdf/CienciasNatureza.pdf>. Acesso em: 10 out.
2012.
CAELUM. Apostila do curso FJ-11 – Java e Orientação a Objetos. In:______. Uma
Breve História do Java. Disponível em: <http://www.caelum.com.br/apostila-java-
orientacao-objetos/o-que-e-java/#2-2-uma-breve-historia-do-java>. Acesso em: 14 out.
2012.
DEITEL, H.; DEITEL, P. Java – Como Programar. In:______. Introdução aos
Computadores, à Internet e à World Wide Web. São Paulo: Pearson, 2010. p. 2 – 19.
ESTEINMACHER, I. et al.; GeCA: Uma Ferramenta de Engenharia Reversa e Geração
Automática de Código. In: SIMPÓSIO BRASILEIRO DE SISTEMAS DE
INFORMAÇÃO, 3, 2006, Curitiba. Anais... Disponível em: <
http://www.academia.edu/955448/GeCA_Uma_Ferramenta_de_Engenharia_Reversa_e
_Geracao_Automatica_de_Codigo>. Acesso em: 14 out. 2012
FALSTAD, P. Paul Falstad’s Home Page. Disponível em: <
http://www.falstad.com/>. Acesso em: 29 nov. 2011.
GASPAR, A. Os parâmetros curriculares nacionais. In: ______. Física:
Eletromagnetismo/ Física Moderna, Manual do professor. São Paulo: Ática, 2001. p.
10 – 18.
55
GASPAR, A. Atividades interdisciplinares e de contextualização. In: ______. Física:
Eletromagnetismo/ Física Moderna, Manual do professor. São Paulo: Ática, 2001. p.
29 – 34.
LIMA, L.S. Um Estudo Investigativo sobre a Inserção de Tecnologia Multimídía no
Ensino de Física de Nível Médio. 2012. 101 f. Dissertação (Mestrado em Ensino de
Ciência e Matemática). Departamento de Ciências, Universidade Federal do Ceará,
Fortaleza, 2012. Disponível em:
< http://www.repositorio.ufc.br:8080/ri/handle/123456789/2547 >. Acesso em: 11 out.
2012.
MARTIN, R. OO Design Quality Metrics - An Analysis of Dependencies. Green
Oaks, 1994. 8p. Artigo. Disponível em: <
http://www.cin.ufpe.br/~alt/mestrado/oodmetrc.pdf >. Acesso em: 11 out. 2012.
MORAES, J.U.P. A visão dos alunos sobre o ensino de física: um estudo de caso.
Scientia Plena, Sergipe, V5, Nº11, 2009. Disponível em:
<http://www.scientiaplena.org.br/ojs/index.php/sp/article/viewFile/736/392>. Acesso
em: 11 out. 2012.
PIEKARSKI, A.E.T.; QUINÁIA, M.A. Reengenharia de software: o que, por quê e
como. Guarapuava: Departamento de Informática – UNICENTRO. 19 p. Artigo.
Disponível em: <
http://revistas.unicentro.br/index.php/RECEN/article/download/528/697 >. Acesso em:
12 out. 2012.
PIZZOLATO, E. B.; Programação Orientada a Objetos. In:______. Orientação o
Objetos com C++. São Carlos: Departamento de Produção Gráfica – UFSCar, 2008. p.
29 – 66.
56
PRESSMAN, R.S. Engenharia de Software. In:______. Reengenharia. McGraw-Hill,
2006. p. 681-698.
ROSA, C. W.; FILHO, J.P.A. Evocação Espontânea do Pensamento Metacognitivo nas
Aulas de Física: estabelecendo comparações com as situações cotidianas. Investigações
em Ensino de Ciências, Florianópolis, V17(1), pp. 7-19, 2012. Disponível em:
<http://www.if.ufrgs.br/public/ienci/artigos/Artigo_ID276/v17_n1_a2012.pdf >. Acesso
em: 10 out. 2012.
SERRANO, A.; ENGEL, V. Uso de Simuladores no Ensino de Física: Um estudo da
produção Gestual de Estudantes Universitários. Novas Tecnologias na Educação, Rio
Grande do Sul, V. 10 Nº 1, julho, 2012. Disponível em: <
http://seer.ufrgs.br/renote/article/view/30868/19224>. Acesso em: 11 out. 2012.
SERWAY, A. R.; JR., J. W. J. Forças Elétricas e Campos Elétricos. In: ______.
Princípios de Física: Eletromagnetismo. São Paulo: Pioneira Thomson Learning, 2004.
p. 677-709.
SERWAY, A. R.; JR., J. W. J. Potencial Elétrico e Capacitância. In: ______. Princípios
de Física: Eletromagnetismo. São Paulo: Pioneira Thomson Learning, 2004. p. 719-
754.