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.


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)



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


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).



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,



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.



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.



sistema.

Methods per Classes Razão entre o total de

métodos pelo total de

classes.



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.



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.



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



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.



ficar entre 1 a 2.2.

Average Complexity (Avg

Complexity)

Razão entre a soma de

todas as complexidades

pelo total de métodos.



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.


possibilitando posicionamento e dimensionamento personalizado aos compo

os quais são a área de apresentação das simulações e os elementos do menu


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.


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


a única ferramenta utilizada. Porém, o SourceMonitor permite em gráficos Kiviat, o que é apresentado no item 4.3.6.

37

updateVec3Demo, a


personalizado aos componentes do

sentação das simulações e os elementos do menu.


combinam seus papéis para auxiliarem

UserDefinedFunction na

defined potential e user-


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


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


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


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.

reengenharia simulador campo eletrico

Documents