UNIVERSIDADE FEDERAL DE SO CARLOS CENTRO DE CINCIAS EXATAS E DE TECNOLOGIA DEPARTAMENTO DE COMPUTAO

Reengenharia de um simulador de campo eltrico para melhorar aspectos de usabilidade/extensibilidade

AUTOR: DOUGLAS FERREIRA DE ALMEIDA MONOGRAFIA DE CONCLUSO DO CURSO BACHARELADO EM SISTEMAS DE INFORMAO ORIENTADOR: PROF. DR. DANIEL LUCRDIO SO CARLOS SP 2012

DOUGLAS FERREIRA DE ALMEIDA

Reengenharia de um simulador de campo eltrico para melhorar aspectos de usabilidade/extensibilidade

Trabalho de concluso de curso apresentado como parte das atividades para obteno do ttulo de Bacharel, do curso de Sistemas de Informao da Universidade Federal de So Carlos. Orientador: Prof. Dr. Daniel Lucrdio.

SO CARLOS SP 2012

Folha de aprovao

Dedico este trabalho, com amor, pessoa que mais me ajudou em sua realizao companheira fiel e me dos meus filhos Patrcia Ribeiro.

Agradecimentos
Agradeo 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 palpitaes mais intensas do corao, ao Prof. Dr. Daniel Lucrdio pelo apoio e orientao e ao doutorando Marcos Alexandre Rose Silva pelas preciosas sugestes.

A gravidade explica os movimentos dos planetas, mas no 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 Fsica e, em especial, de campo eltrico no nvel mdio brasileiro, enfrenta dificuldades por causa da complexidade do assunto e do uso de metodologias no satisfatrias. Simuladores que apresentem diferentes configuraes de cargas geradoras de campo eltrico interagindo com cargas de prova e modelos de representao de campo eltrico podem oferecer ajuda em busca da soluo do problema. Esta monografia apresenta a reengenharia do 3D Vector Fields Applet V 1.3 (PAUL FALSTADS HOME PAGE, 2011) cujo resultado um simulador mais adequado para dar suporte ao processo apontado. E os conceitos e tcnicas utilizados podem ser teis a outros projetos aos quais sejam necessrios. Palavras-chave: Reengenharia de software, Orientao a Objetos, Ensino de Fsica, Java, Campo Eltrico.

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

Sumrio
1. 2. 2.1 2.2 3. 3.1 3.2 3.3 4. 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.3 4.3.1 4.3.2 4.3.3 4.3.4 4.3.5 4.3.6 5. Introduo................................................................................................................ 10 Fsica no Ensino Mdio Brasileiro .......................................................................... 11 Ensino e Aprendizagem de Campo Eltrico ........................................................ 13 Laboratrios Virtuais ........................................................................................... 16 Conceitos Bsicos ................................................................................................... 17 Orientao a Objetos ........................................................................................... 18 Java ...................................................................................................................... 19 Reengenharia de Software ................................................................................... 20 Reengenharia do 3D Vector Fields Applet V 1.3................................................. 27 Levantamento de Requisitos................................................................................ 27 Engenharia Reversa ............................................................................................. 27 Anlise das Funcionalidades ............................................................................ 27 Anlise da Interface ......................................................................................... 34 Anlise da Estrutura ......................................................................................... 36 Resumo dos Resultados da Engenharia Reversa ............................................. 38 Engenharia Progressiva ....................................................................................... 38 1 ciclo Retirada dos Blocos de Pr-Processamento ..................................... 38 2 ciclo Modificao da Classe Vec3DemoFrame........................................ 39 3 ciclo Supresso de Vec3Demo ................................................................. 44 4 ciclo Modificao da Interface ................................................................. 44 5 ciclo Reviso............................................................................................. 48 Mtricas para o Simulador Modificado ........................................................... 49

Concluses .............................................................................................................. 52

Referncias Bibliogrficas .............................................................................................. 53

10

1.

Introduo

Algumas atitudes no recomendveis so praticadas no ensino de Fsica de nvel mdio, tais como: apresentao de contedos, leis e frmulas de modo desarticulado, distanciando o mundo vivido pelos estudantes daquele apresentado pelo professor; supervalorizao da teoria e da abstrao em detrimento dos aspectos prticos que levariam abstrao necessria; desvinculao entre o significado fsico de determinada situao e o ferramental matemtico; resoluo repetitiva de exerccios, buscando a memorizao e no a compreenso; apresentao do conhecimento como um produto acabado (GASPAR, 2001a). Entre os componentes curriculares, eletricidade merece destaque, devido a sua importncia e complexidade. O mundo contemporneo, como conhecido, seria impensvel se o seu uso tivesse que ser descartado. E para que melhor compresso deste assunto seja alcanada, necessrio entender o conceito de campo eltrico, que no trivial. (GASPAR, 2001b). Ento, por um lado, h mtodos com eficcia questionvel, e por outro, um assunto importante e de difcil compreenso. Deste modo, conveniente a busca por ferramentas alternativas que aumentem a eficincia do processo de ensinoaprendizagem de campo eltrico. Isto poderia ser feito com o uso exclusivo de laboratrios reais, com os quais os estudantes interagiriam com os fenmenos, facilitando a sua compreenso. Mas tal estratgia envolveria a aquisio dos materiais necessrios cujos custos dificultariam o acesso. Alm disto, a visualizao dos modelos que representam os processos envolvidos, embora facilitada, no seria possvel. 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, manuteno e ao reuso, e eficincia no apoio ao processo de ensino e aprendizagem. No captulo 2, discute-se o processo de ensino e aprendizagem de Fsica em nvel mdio no Brasil e, em particular, de campo eltrico e a maneira como recursos computacionais podem dar suporte a ele. No captulo 3, so apresentados conceitos de Orientao a Objetos, Java e Reengenharia de Software. No captulo 4, so mostrados os procedimentos adotados na reengenharia do 3D Vector Fields Applet V 1.3 e no captulo 5, a concluso. O CD anexado apresenta o cdigo fonte original e o modificado, assim como o novo simulador e o javadoc documentao gerada automaticamente pela ferramenta NetBeans 7.2. Assim, esta monografia permite que se extraiam elementos relacionados ao processo de ensino e aprendizagem de Fsica em nvel mdio no Brasil e, em particular, de campo eltrico, e elementos relacionados a tcnicas de reengenharia que podem ser aplicadas em outros projetos, alm de oferecer subsdios ao entendimento sobre algumas dificuldades na adaptao de projetos aos requisitos do paradigma de orientao a objetos quando tais projetos no tiverem design baseado neste paradigma.

2.

Fsica no Ensino Mdio Brasileiro

A Lei de Diretrizes e Bases que regula o ensino fundamental brasileiro apregoa que o ensino mdio deve ser visto como ltimo estgio do ensino fundamental dando condies 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 relao ao processo de ensino e aprendizagem de Fsica, algumas diretrizes so apresentadas abaixo (MEC, 2012):

12

(...) competncias e habilidades se desenvolvem por meio de aes concretas,

que se referem a conhecimentos, a temas de estudo. E h, certamente, certos assuntos ou tpicos com maior potencial do que outros para os objetivos pretendidos, o que impe escolhas criteriosas. Os temas de trabalho, na medida em que articulam conhecimentos e competncias, transformam-se em elementos estruturadores da ao pedaggica, 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 mdio, devem ganhar uma abrangncia maior, e tambm, ao mesmo tempo, certa especificidade disciplinar, uma vez que, para desenvolver competncias e habilidades em Fsica, preciso lidar com os objetos da Fsica. Devem estar relacionados, portanto, com a natureza e a relevncia contempornea dos processos e fenmenos fsicos, cobrindo diferentes campos de fenmenos e diferentes formas de abordagem, privilegiando as caractersticas mais essenciais que do consistncia ao saber da Fsica e permitem um olhar investigativo sobre o mundo real.

Deste modo, o estudo da Fsica deve capacitar o estudante a enxergar a relao entre os assuntos da disciplina e o ambiente em que est inserido, o qual passvel de interao, levando interpretao de seus aspectos e a aes modificadoras, exigindo para tal sua capacidade cognitiva no que diz respeito a concentrao, imaginao, estabelecimento de relaes, criao e interpretao de modelos, leitura e escrita de linguagem tcnica, entre outros. Quem estuda esta cincia no se depara apenas com frmulas que aparentemente so teis somente no mundo das ideias, mas com leis que regem o universo, assim como as bases das tecnologias modernas, que levam construo de computadores, celulares e tantos outros dispositivos (LIMA, 2012). Porm, a abordagem desta disciplina, muitas vezes, tem sido realizada como se os objetos de anlise no fizessem parte da realidade dos estudantes, alm de passar a impresso de que o conhecimento cientfico esttico, alienado de seu contexto histrico, absolutamente independente de carga subjetiva comum a qualquer atividade humana, incluindo a atividade cientfica.

13

A distncia entre o mundo do estudante e o mundo que apresentado como sendo prpria da Fsica, associada s dificuldades naturais dos estudantes, de modo geral, leva esta disciplina aos piores resultados comparados aos das demais disciplinas (ROSA; FILHO, 2012). Vrias pesquisas esto sendo realizadas no Brasil e no mundo buscando novas metodologias para melhorar estes resultados (MORAES, 2009).

2.1

Ensino e Aprendizagem de Campo Eltrico

comum materiais didticos brasileiros comearem a abordagem de campo eltrico, 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 prximos a sua superfcie. Ento, evocando este conhecimento emprico, aliado aos estudos anteriores do prprio campo gravitacional, j que o campo eltrico acaba sendo um dos ltimos assuntos abordados no ensino mdio, procura-se oferecer subsdios para compreenso do campo eltrico. Apesar disto, as dificuldades no so plenamente transpostas. A analogia citada pode ajudar o estudante aceitar como possvel, por exemplo, que uma carga puntiforme, atuando como fonte geradora de campo eltrico, atraia distncia outra carga puntiforme oposta. Mas o estudo do campo eltrico no ensino mdio requer abordagem mais profunda. preciso que o estudante conhea os modelos representativos e o movimento das cargas de prova originado pela interao entre elas e a fonte geradora de campo eltrico. A primeira representao a do vetor campo eltrico. O campo eltrico E em um ponto do espao definido como a fora eltrica F que age sobre uma carga de prova, colocada neste ponto, divida pela carga q da partcula (SERWAY; JR., 2004a). Sendo a fora uma grandeza vetorial e o campo eltrico definido como o produto entre ela e o inverso da carga eltrica da partcula, que uma grandeza escalar, o campo

14

eltrico, no ponto considerado, vetorial (E = F . 1/q). Da o termo vetor campo eltrico. Se a fonte geradora tiver carga negativa, este vetor vai ser convergente em relao a ela. Se for positiva, ele ser divergente. Este fato j diferencia o campo eltrico do gravitacional. O vetor campo gravitacional sempre convergente em relao massa geradora. O segundo modelo o das linhas de fora. Elas so uma representao pictrica especializada conveniente para visualizar padres de campo eltrico e atende s seguintes propriedades (SERWAY; JR., 2004a):
O vetor campo eltrico E tangente linha do campo eltrico em cada ponto.

O nmero de linhas do campo eltrico por unidade de rea atravs de uma superfcie, que perpendicular s linhas, proporcional magnitude do campo eltrico nesta regio.

A convenincia deste modelo torna possvel a avaliao qualitativa da intensidade do campo com base na densidade das linhas. Quando as linhas estiverem prximas uma das outras, o campo ser maior do que quando as linhas estiverem afastadas. A terceira representao a das superfcies equipotenciais. Elas so reas formadas por pontos que apresentam mesmo potencial eltrico, 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 diferena de potencial eltrico. Modelos desenhados em duas dimenses so suficientes para alguns propsitos. Por exemplo, pela Figura 1, pode-se concluir que o campo eltrico mais intenso prximo s cargas devido a maior concentrao de linhas de fora.

15

Figura 1. Linhas de Fora do Campo Eltrico de Cargas Puntiformes untiformes

Mas esta representao no possibilita a visualizao do carter tridimensional do do campo eltrico. O mesmo acontece em relao ao potencial eltrico. Na F ltrico. Figura 2, as linhas fechadas representam pontos de mesmo potencial mas, de modo errneo, s entam potencial, , so comumente apresentadas como superfcies e equipotenciais. Elas so seces de las superfcies equipotenciais. As superfc so tridimensionais, neste caso. . superfcies

Figura 2. Superfcies E ura Equipotenciais e Linhas de Fora

Os movimentos de cargas sob a ao do campo eltrico so outro problema. Na Figura 3, so representados os vetores campo eltrico nos pontos P para uma carga geradora puntiforme positiva e outra negativa, respectivamente. Caso uma carga de aso prova positiva seja colocada no primeiro ponto P, a fora que atuar nela ter direo , horizontal e sentido para a direita e a carga vai se afastar da fonte porque a fora ser de repulso. Mas o movimento ser retilneo ou curvilneo? Ser acelerado, retardado ou ?

16

uniforme? A concluso depende de conhecimento da matemtica do fenmeno Como a fenmeno. fora eltrica depende do quadrado da distncia, o aumento desta implica na desta, diminuio daquela. A acelerao proporcional fora, de acordo com a Segunda Lei fora, de Newton. Ento, ela tambm diminui, mas continua agindo na direo horizontal, da esquerda para a direita. Assim, o movimento ser retilneo e acelerado.

Figura 3. Campo Eltrico Criado por Cargas Puntiformes

Haveria, ento, uma ferramenta que pudesse suprir ambas as necessidades a a visualizao de modelos tridimensionais e dos movimentos de cargas de prova prova?

2.2

Laboratrios Virtuais

So evidentes as mudana provocada na sociedade pelo uso do computador A Internet provocadas computador. um dos principais exemplos. Ela alterou de maneira radical o modo como a pessoas as realizam compras, como fazem transaes comerciais e at como se relacionam. E estas mudanas se refletiram tambm na rea da educao. Hoje, possvel estudar e ensinar distncia. As instituies de ensino esto se inserindo cada vez mais nesta nova realidade, apoiando-se em recursos oriundos das novas tecnologias para compleme se complementar o processo de ensino e aprendizagem (AUDINO; NASCIMENTO, 2010) 2010). Durante dcadas, pesquisadores tm sido desafiados pela investigao do aprendizado de conceitos cientficos com auxlio de computadores. Os resultados, muitas vezes, tm se mostrado benficos especialmente em relao ao uso de benficos

17

simuladores por causa das representaes grficas animadas. Elas parecem ser internalizadas durante o processo de aprendizado (SERRANO; ENGEL, 2012). O ambiente de aprendizagem tem se tornado um espao ldico, enriquecedor e motivador com o uso da informtica educativa, ajudando o educando na construo de conhecimento cientfico e crtico (LIMA, 2012). Neste contexto, surgiram os objetos de aprendizagem. Eles so desenvolvidos com propsito educacional e elaborados em uma base tecnolgica, sendo dinmicos, interativos, reutilizveis e no dependendo de plataforma especfica para funcionar. (AUDINO; NASCIMENTO, 2010). Estas caractersticas se harmonizam com o paradigma de orientao a objetos, cujo propsito a produo de recursos computacionais baseados em objetos que se relacionam entre si, facilitando o reuso e a manuteno, e tambm com linguagens de programao que possibilitem a construo de sistemas multiplataforma, a exemplo de Java. Os laboratrios reais mostram de forma visual as interaes entre cargas eltricas. Mas eles no fazem isto para os modelos que auxiliam na explicao de tais interaes. Estas afirmaes no querem dizer que os simuladores sejam capazes de suprir todas as necessidades de suporte ao processo de ensino e aprendizagem de Fsica e, consequentemente, de campo eltrico, mas apontam para sua adequao.

3.

Conceitos Bsicos

18

3.1

Orientao a Objetos

Nos anos 70, utilizava-se o termo crise do software para expressar as dificuldades envolvidas no desenvolvimento de sistemas em comparao com a demanda cada vez maior. A forma de programar dificultava o reaproveitamento e a manuteno de cdigo. Suponhamos que um simulador para frmula 1 tivesse que ser desenvolvido. Uma das funes necessrias seria acelerar. Dentro desta funo, deveria ser determinado um valor de velocidade mxima. Suponhamos ainda que a equipe responsvel por este software tambm tivesse um projeto de desenvolvimento de um simulador para autoescolas. Naturalmente, haveria muitas diferenas entre ambos, mas tambm semelhanas, como o fato de que qualquer carro tem que acelerar. Assim, um cdigo mais genrico 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 so unidades responsveis pelo armazenamento de estado e desencadeador de aes focadas em um propsito especfico 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):
Abstrao: habilidade de modelar caractersticas do mundo real; Encapsulamento: habilidade da unidade de proteger os dados e permitir que apenas suas operaes internas tenham acesso a eles; Herana: mecanismo que permite: a) a criao de novos objetos atravs da modificao de algo que j existe e b) o vnculo do objeto criado com o objeto antigo. um conceito muito conhecido da natureza; Polimorfismo: capacidade de uma unidade ter vrias formas.

Assim como o hardware composto por vrios elementos, como placa me, processador, fonte, memria, entre outros, o programa desenvolvido com base neste paradigma composto por vrios mdulos, ou classes, que do origem aos objetos. O

19

ideal que as classes sejam elaboradas com objetivos bem especficos, levando a alta coeso, e cujos relacionamentos ocorram por intermdio de suas interfaces, levando a baixo acoplamento (BATES; SIERRA, 2006), j que alta coeso e baixo acoplamento cooperam para se obter melhor reaproveitamento de cdigo e facilitar sua manuteno. Alm disto, colocar as classes dentro de pacotes evita problemas, tais como coliso (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 escritrio 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 cafs importados (DEITEL. P.; 2010), (DEITEL. H.; 2010). O objetivo inicial da linguagem era dar suporte a pequenos dispositivos destinados ao consumidor final, tais como vdeo cassete, televiso e aparelhos de TV a cabo, mas a ideia no deu certo. Houve a tentativa do fechamento de contratos com grandes fabricantes como a Panasonic, porm conflitos de interesses e custos no permitiram que isto se concretizasse. Mas o advento da web e a necessidade de tornar suas pginas dinmicas abriu um campo de uso para o Java. A verso 1.0 foi lanada com o objetivo de dar capacidade ao browser de realizar operaes mais avanadas e no apenas renderizar um pgina HTML (CAELUM, 2012). Para que um cdigo fonte escrito em Java possa funcionar necessrio que ele seja compilado e transformado em bytecodes. Estes bytecodes so executados pela JVM mquina 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, alm da ampla documentao disponvel e da extensa gama de fruns sobre seus aspectos.

20

3.3

Reengenharia de Software

Os sistemas de informao so dinmicos. Eles entram em estados de contnuas mudanas a partir do momento em que comeam a funcionar (PIEKARSKI; QUINIA, 2000). As adaptaes pelos quais eles devem passar no esto relacionadas simplesmente correo de erros, mas tambm s mudanas necessrias decorrentes da identificao da necessidade de novas funcionalidades, adaptao a novas tecnologias, a busca por melhora de desempenho, entre outros, sendo assim, inevitveis (ESTEINMACHER et al., 2006). No caso de sistemas escritos em Java, alm da complexidade, um cdigo que no atende aos princpios bsicos da orientao a objetos, como a construo de classes pouco coesas e altamente acopladas, como j sugerido, dificulta o reaproveitamento (reusabilidade) e a manuteno (manutebilidade). Existem mtricas relacionadas a estes conceitos e ferramentas que as calculam, que ajudam na tarefa de avaliao da qualidade de um cdigo fonte. Duas destas ferramentas so o SourceMonitor e o Metrics e podem ser usadas de forma complementar. O SourceMonitor calcula mtricas de sistemas escritos em vrias linguagens, entre elas, Java. O conjunto de mtricas para esta linguagem apresentado na Tabela 1. MTRICA Lines DEFINIO Nmero de linhas de cdigo Statements Nmero de todas as declaraes terminadas com ponto e vrgula, AVALIAO DO VALOR Quanto maior seu valor, maior a complexidade do sistema. Quanto maior seu valor, maior a complexidade do sistema.

21

declaraes de mtodos e da classe, alm daquelas que apresentam if, for, while, try, catch e finally, entre outros. Percent Branch Statements (% Branches) o percentual de declaraes, em relao ao total, que provocam quebra na sequncia de execuo, 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 mtodos.

Valores grandes sugerem alta complexidade, porm o programa no leva em considerao a conveno JavaBeans, contando os getters e setters.

Percent Lines with Comments (% Comments)

Percentual de linhas com comentrios em relao ao total de linhas de cdigo.

De acordo com a ajuda do programa, o valor deve ficar entre 8 e 20 por cento. Quanto maior seu valor, maior a complexidade do sistema.

Classes and Interfaces (Classes)

Total de classes e interfaces.

Methods per Classes

Razo entre o total de mtodos pelo total de classes.

De acordo com a ajuda do programa, o valor deve ficar entre 4 a 16, porm o

22

programa no leva em considerao a conveno JavaBeans, contando os getters e setters. Average Statements per Methods (Avg Stmts/Method) Razo entre o total de declaraes dentro dos mtodos e o total de mtodos. De acordo com a ajuda do programa, o valor deve ficar entre 6 a 12. A ideia concatenar ao mtodo chamador mtodos com valor inferior a 6 e fragmentar mtodos com valor superior a 12. Maximum Complexity (Max Complexity) a maior complexidade entre os mtodos. A complexidade iniciada com valor 1 incrementada a cada if, else, for, foreach, while, operador ternrio, cada case em switch (duplamente se houver declaraes break, goto, return, throw, continue), cada catch ou except dentro do bloco try, mas no declaraes try ou finally. Maximum Block Depth (Max Depth) Profundidade mxima de uma declarao. A cada aninhamento, a De acordo com a ajuda do programa, o valor deve ficar entre 3 a 7. De acordo com a ajuda do programa, o valor deve ficar entre 2 a 8. A estratgia de melhoria a mesma da mtrica anterior.

23

profundidade acrescida de 1. Average Block Depth (Avg a mdia ponderada da Depth) profundidade de bloco de todas as declaraes no arquivo. Average Complexity (Avg Complexity) Razo entre a soma de todas as complexidades pelo total de mtodos. De acordo com a ajuda do programa, o valor deve ficar entre 2 a 4. De acordo com a ajuda do programa, o valor deve ficar entre 1 a 2.2.

Tabela 1. Mtricas Calculadas pelo SourceMonitor

O Metrics, que um plugin do IDE - ambiente integrado de desenvolvimento Eclipse, calcula o seguinte conjunto de mtricas, permitindo avaliao da complexidade do cdigo 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 cdigo), 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) nmero de mtodos estticos. Afferent Coupling (CA) - O acoplamento aferente representa o nmero de classes e interfaces de outros pacotes que dependem das classes do pacote em questo.

24

Normalized Distance (RMD) - uma medida que leva em considerao a abstrao (A) e a instabilidade (I). Ela pode ser calcula pela frmula (A + I 1) , variando, deste modo, entre 0 e 1. Projetos com melhores designs so aqueles cuja distncia mnima, prxima a zero, significando maior facilidade para reexame e reestruturao (MARTIN, 1994). Instability (RMI) - a razo 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 no depende de outros pacotes do sistema, mas outros pacotes dependem dele. Para evitar que mudanas nas classes deste pacote se propagem nas classes dos outros pacotes, usa-se o polimorfismo, para o qual so necessrias as classes abstratas e interfaces. Assim, menor instabilidade demanda maior abstrao e vice-versa. Specialization Index (SIX) definida como n de mtodos sobrescritos * profundidade na rvore de herana / n total de mtodos. Number of Attributes (NOF) nmero de atributos. Number of Packages (NOP) nmero de pacotes. Methods Lines of Code (MLOC) nmero total de linhas de cdigo dentro do corpo de mtodos, excluindo comentrios e linhas em branco. Weighted Methods per Class (WMC) soma das McCabe Cyclomatic Complexity de todos os mtodos. Number of Overridden Methods (NORM) nmero de mtodos sobrescritos. Number of Static Attributes (NSF) nmero de atributos estticos.

25

Nested Block Depth (NBD) profundidade de aninhamento do bloco dentro de um mtodo. Number of Methods (NOM) nmero de mtodos. Lack of Cohesion of Methods (LCOM) avalia a coeso de uma classe. A ferramenta usa o mtodo de Henderson-Sellers para fazer seu clculo. Um valor prximo a zero indica uma classe coesa e um valor prximo de 1 indica falta de coeso. McCabe Cyclomatic Complexity (VG) calculada apenas para mtodos, incrementada em 1 para cada clusula responsvel por um desvio de fluxo, como if, for, while, do, case, catch, operador ternrio, & & e | |, operadores de lgica condicionais em expresses. Number of Parameters (PAR) nmero de parmetros por mtodo. Abstractness (RMA) - calculada pela razo entre a quantidade de classes abstratas e interfaces do pacote por suas classes concretas. Seu valor varia entre 0 e 1. Como visto, sua importncia depende da instabilidade e ambos possibilitam o clculo da distncia. Number of Interfaces (NOI) nmero de interfaces. Efferent Coupling (CE) nmero de classes e interfaces dentro do pacote que dependem de classes e interfaces de outros pacotes. Number of Children (NSC) nmero de subclasses diretas de uma classe. Depth of Inheritance Tree (DIT) - distncia entre a classe em questo e a classe Object na hierarquia de herana.

26

Basicamente, o desenvolvimento de um software envolve a descrio dos requisitos que explicitam os objetivos que ele pretender atender, a construo de um modelo com nvel de abstrao alto, ou seja, um modelo genrico, e etapas subsequentes para diminuio do nvel de abstrao at que o sistema em funcionamento seja alcanado. Este fluxo de atividades, simplificadamente, conhecido como engenharia progressiva. Quando, por exemplo, um sistema precisa passar por manuteno, os responsveis por ela no sero, necessariamente, aqueles envolvidos em seu desenvolvimento e possvel que a documentao no seja suficiente para tornar claros seus mecanismos. Ser necessria, ento, uma estratgia 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 representaes subsequentes de nveis de abstrao cada vez mais altos, oferecendo ao responsvel, subsdios para entendimento mais fcil do programa (PRESSMAN, 2006). A reengenharia, deste modo, se baseia na desmontagem do sistema pelas tcnicas da engenharia reversa e na remontagem, visando atender s novas necessidades, pelas tcnicas da engenharia progressiva. Caso o cdigo fonte do sistema no esteja disponvel, a anlise das funcionalidades possibilita a criao de modelos genricos a partir dos quais o novo cdigo escrito. Com acesso ao cdigo, h a possibilidade de associao entre as funcionalidades e os respectivos trechos de cdigo e as mudanas daquelas so realizadas com a alterao destes. Ou ento, pode-se adotar uma estratgia que mescle as duas anteriores novos modelos de alto nvel de abstrao so criados e, na implementao, aproveitam-se trechos de cdigo prontos.

27

4.
4.1

Reengenharia do 3D Vector Fields Applet V 1.3

Levantamento de Requisitos

Como visto no captulo 2, simulaes computacionais podem dar suporte adequado ao processo de ensino e aprendizagem de campo eltrico em nvel mdio no Brasil. Para isto, o simulador precisa1: (a) ser gratuito, para torn-lo mais acessvel; (b) possuir interface atraente que facilite o seu uso; (c) fazer apresentaes tridimensionais, para melhorar a visualizao, dinmicas e interativas, a fim de que sejam estimulantes; (d) ter nvel de complexidade ajustado ao ensino mdio brasileiro, no qual est inserido o pblico alvo, (e) no ser dependente de plataforma especfica, permitindo que seu uso seja mais abrangente e (f) ser desenhado de tal maneira que facilite a manuteno e o reuso.

4.2

Engenharia Reversa

4.2.1 Anlise das Funcionalidades O objetivo da simulao apresentar interaes entre o campo eltrico gerado por diferentes fontes e um conjunto varivel de cargas de prova, e seus modelos representativos.

Os requisitos foram levantados pelo autor da monografia, fazendo papel de um cliente interessado em financiar o projeto, tal como a Sociedade Brasileira de Fsica.

28

Figura 4. Opes de Fontes Geradoras

Na Figura 4, uma carga geradora central (a) cria um campo eltrico que atrai cargas de prova (b) liberadas dentro do cubo. Nesta configurao, 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 no interagem umas com as outras. Algumas destas fontes geram interaes e modelos que esto alm do escopo do ensino mdio brasileiro, conforme os modelos apresentados em livros didticos e com base na experincia de 20 anos do autor desta monografia, na poca em que foi escrita, como professor de Fsica no ensino mdio e cursos preparatrios. Assim, o requisito (d) apresentado no item 4.1 no atendido.

29

Todas as interaes so apresentadas dentro de um cubo que pode ser rotacionado ou ter suas dimenses alteradas. Para um ou para outro, escolhe-se uma das opes apontadas pela Figura 5, respectivamente, e ento, posiciona-se o cursor do mouse com o boto esquerdo pressionado sobre o cubo, movimentando-o.

Figura 5. Ajuste do Cubo Rotao ou Alterao das Dimenses .

O menu display permite que a influncia das fontes sobre as cargas de prova seja verificada por meio das representaes apontadas pela Figura 6.

30

Figura 6. Representaes do Campo Eltrico e Tipos de Interao

Com a opo Particles (Vel), o movimento das cargas ocorre sobre as linhas de fora, como se elas no interagissem entre si. Com Particles (Force) o movimento ocorre levando-se em considerao a influncia das cargas de prova uma sobre as outras. Field Vectors possibilita a visualizao do conjunto de vetores campo eltrico ao redor das fontes geradoras, como mostra a Figura 7.

31

Figura 7. Vetores Campo Eltrico

Houve alterao nas barras de rolagem. A barra Number of Particles, que controla o nmero de partculas, foi substituda por Vector Density, responsvel pela alterao da quantidade de vetores campo eltrico apresentada. Na Figura 8, mostrado o resultado da opo Field Lines. Como anteriormente, a barra Field Strenght, que controla a intensidade do campo eltrico disponibilizada e a barra Vector Density alterada para Field Line Density, responsvel pela alterao da quantidade de linhas de fora apresentada.

32

Figura 8. Linhas de Fora

J a opo equipotentials, combinada com a nova barra potentials, possibilita a visualizao das superfcies equipotenciais ao redor da fonte geradora. Um exemplo mostrado na Figura 9.

33

Figura 9 Superfcies Equipotenciais

possvel que as visualizaes sejam feitasem duas dimenses, a exemplo do que mostra a Figura 10. Com esta opo, quando o curso do mouse colocado sobre um dos lados do plano de visualizao, tais lados adquirem cor amarela e o plano pode ser movido com o curso pressionado sobre qualquer um deles.

34

Figura 10. Visualizao 2D

A Figura 10 tambm permite a observao da opo Stopped, que estaciona a simulao, a opo Reverse, que muda o sinal das cargas que compe a fonte geradora e Reset, que reinicia o movimento das partculas. Kick fica disponvel para visualizao do movimento real das partculas. Quando acionado, as partculas so desordenadas.

4.2.2 Anlise da Interface Para o usurio, a interface um aspecto importante de um programa porque aquilo que ele v e por intermdio dela que ocorre a interao. Para ele, o sistema acaba sendo a prpria interface. (ANACLETO; VILLENA, 2009). Por isto, a m compreenso dos elementos da interface com usurio 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 anlise intuitiva da interface feita com a Figura 11. Assim, as modificaes propostas levam a resultados que precisam ser verificados, por exemplo, por testes de usurio. Tais testes se concentrariam na avaliao da facilidade de uso do sistema antes e depois das modificaes por estudantes e professores do ensino mdio 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 seleo de diferentes configuraes para fontes geradoras de campo eltrico, como j visto. Ele fica claro com o ttulo Field selection (seleo do campo, ou seja, seleo da fonte geradora do campo) mas qual seria o objetivo da segunda caixa de seleo? E das outras caixas? Assim, cada elemento de seleo pode apresentar um ttulo e/ou uma breve explicao com o posicionamento do cursor para que o usurio saiba exatamente o papel de cada um deles.

36

A disposio dos elementos tambm pode ser modificada. No h espao entre eles. H a possibilidade de que os crditos sejam acionados a partir de um novo boto e estes botes serem colocados um ao lado do outro. O menu ser escrito em Lngua Portuguesa e seus elementos terem seu aspecto visual modificado, para que as caixas tenham cantos arredondados, os botes tenham cones, entre outros.

4.2.3 Anlise da Estrutura O cdigo 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 extenso da classe Frame, dependendo, assim de cdigo nativo para definir os componentes da interface grfica e implementa as interfaces ComponentListener, ActionListener, AdjustmentListener, MouseMotionListener, MouseListener e ItemListener. Ela possui classes internas que podem ser classificadas em dois tipos um, para auxlio a tarefas como a disponibilizao de itens do menu conforme a opo escolhida e outro para a criao das fontes geradoras de campo eltrico. Vec3Demo um applet que implementa a interface ComponentListener. Na interface do applet so apresentadas informaes sobre o andamento da simulao e ele recebe uma referncia da classe Vec3DemoFrame para chamar o mtodo init a fim de que o simulador seja apresentado em uma janela separada. Vec3DemoCanvas uma extenso da classe Canvas. Ela cria a rea retangular onde desenhado o cubo dentro do qual acontecem as interaes. Ao ser instanciada, recebe referncia a um objeto Vec3DemoFrame. Nos mtodos sobrescritos paint e

Este cdigo, como comentado na introduo, est disponvel no CD anexado.

37

update, ela usa a referncia a este objeto para chamar o mtodo updateVec3Demo a updateVec3Demo, partir do qual os elementos da simulao so inseridos na rea citada. Vec3DemoLayout uma implementao da interface LayoutManager, possibilitando posicionamento e dimensionamento personalizado aos compo componentes do container, os quais so a rea de apresentao das simulaes e os elementos do menu apresentao menu. Isto realizado a partir da classe Vec3DemoFrame, que chama o mtodo setLayout, usando com argumento uma nova instncia de Vec3DemoLayout. As classes ExprState Expr e ExprParser combinam seus papis para auxiliarem ExprState, as classes internas a Vec3DemoFrame UserDefinedPotential e UserDefinedFunction na entrada de dados em campos de textos quando as fontes user defined potential e user user-defined userdefined function so escolhidas pelo usurio. O cdigo da classe Vec3DemoFrame cheira mal. Ela muito grande e desempenha muitas funes. Para tornar esta anlise mais precisa, foram usados o tornar SourceMonitor 3 e o Metrics A Figura 12 apresenta os valores para as mtricas Metrics. mtricas.

Figura 12. Mtricas (SourceMonitor) do Cdigo Original igura 12.

Estas mtricas mostram que a classe Vec3DemoFrame representa o ponto crtico do sistema. Ela possui a ordem de milhares de linhas de cdigo em contrapartida s outras classes que possuem ordem de dezenas, assim como o nmero de declaraes e
3

O Metrics poderia ter sido a nica ferramenta utilizada Porm, o SourceMonitor permite a visualizao utilizada. de algumas mtricas em grficos Kiviat o que apresentado no item 4.3.6. Kiviat,

38

chamadas a mtodos. a causa da mxima complexidade e tem 91 classes internas. Estas classes internas esto fortemente acopladas classe externa porque compartilham variveis no encapsuladas com ela. A coeso pode ser avaliada com a mtrica Lack of Cohesion of Methods. O plugin Metrics do Eclipse, como j comentado no item 3.3, faz isto, porm, para funcionar, necessrio que o projeto seja construdo, e os blocos de pr-processamento dificultam esta tarefa. Eles foram retirados no primeiro ciclo da engenharia progressiva. Antes, so sintetizados os resultados da engenharia reversa para definio 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 interaes e modelos requerem uma anlise com profundidade que est alm do escopo do ensino mdio devem ser retiradas e a interface pode ser modificada. Estes apontamentos determinaram, a princpio, os ciclos utilizados na engenharia progressiva, alm da retirada dos blocos de prprocessamento.

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 no gerao e propagao de erros e agilizar o processo de anlise do cdigo, uma ferramenta de gerao de cdigo 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 exceo de Vec3DemoLayout.java, no foram utilizados como ponto de partida da modificao do

39

cdigo porque a ferramenta, apesar de ter mantido a lgica original, gerou uma perda semntica das variveis de instncia, de classe e locais, na maioria dos casos. e Estes blocos afetam basicamente, a escolha do tipo de evento apresentado (por afetam, exemplo, Equipotentials) e a instanciao de algumas fontes. Estas funcionalidades stas foram testadas para certificao de que erros no foram criados. Neste ponto, h a possibilidade da anlise da perda de coeso dos mtodos das classes e, em especial, de Vec3DemoFrame. A Figura 13 mostra os resultados.

Figura 13. Perda de Coeso das Classes do Sistema Ori Original.

Analisando a coluna mais direita, conclu se que as classes Vec3DemoLayout, conclu-se Expr, Vec3DemoCanvas, ExprState so coesas pois o valor da mtrica 0 e que Vec3DemoFrame no , pois o valor prximo a 1 Esta mtrica, juntamente com as c3DemoFrame 1. calculadas pelo SourceMonitor, mostram que a classe difcil de ser mantida e SourceMonitor, reaproveitada.

4.3.2 2 ciclo Modificao da Classe Vec3DemoFrame A classe AuxBar no usa mtodos e nem variveis de Vec3DemosFrame. Ento, ela foi eliminada de sua classe externa, de maneira automtica, com a funo refatorar -> mover de interno para nvel externo do netbeans 7.2. O mesmo foi feito com as classes Particle, DrawData, EquipPoint e Complex. No caso desta ltima, ela utilizava dois ,

40

mtodos de Vec3DemoFrame que lhe eram exclusivos e, por este motivo, foram movidos para aquela. Antes das classes internas responsveis pelas fontes geradoras serem movidas, como vrias fontes levam a complexidade alm do escopo do ensino mdio, decidiu-se, primeiramente, pela retirada destas fontes, para atender ao requisito (d) do item 4.1. Todas as classes das fontes geradoras so subclasses da classe abstrata VecFunction. Esta estratgia tem o propsito de usar o polimorfismo, como mostra o trecho de cdigo abaixo:

functionList = new Vector(); VecFunction vf = new InverseSquaredRadial(); while (vf != null) { functionList.addElement(vf); vf = vf.createNext(); } InverseSquaredRadial instanciada. Seu mtodo createNext instancia a prxima classe e isto vai se repetindo at que o mtodo createNext da ltima classe retorna null e a iterao encerrada. As classes que geravam fontes no mais utilizadas foram excludas com o cuidado para no 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 responsvel pela criao de instncia da primeira classe aps a retirada. Esta excluso fez com que alguns mtodos deixassem de ser utilizados. Eles foram excludos. As novas fontes so apresentadas na Figura 14.

41

Figura 14. Novas Fontes Geradoras

Da maneira como a lgica original foi desenvolvida, todos os objetos destas classes so instanciados e armazenados no vetor functionList. Ento, percorrendo este vetor, seus nomes so recuperados para serem disponibilizados na caixa de seleo das fontes, como mostra o prximo trecho de cdigo.

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 mtodos relacionados s funcionalidades da fonte especfica so desencadeados. Esta no a melhor estratgia porque todos os objetos so instanciados para que, ento, serem usados. melhor instanciar o objeto quando necessrio Para que os nomes das fontes estejam disponveis antes da instanciao 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 seleo.

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 verificao da fonte selecionada para poder instanciar o objeto relativo a esta fonte no momento da escolha do usurio.

switch(functionChooser.getSelectedIndex()){ case 0: curfunc = (VecFunction) new InverseSquaredRadial(this);

Uniform Field, user-defined potential e user-defined field tambm 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 mtodos desta, a referncia this foi enviada na instanciao para poder chamar tais mtodos. Os seus construtores tiveram que ser modificados e, em alguns casos, criados para receber esta referncia e para atender hierarquia de herana. Alm disto, os mtodos createNext e getName foram eliminados. A classe Particle responsvel pela criao de partculas individuais. Dentro da classe Vec3DemoFrame, diversos mtodos usam instncias desta classe para criar e manipular um conjunto de partculas. So eles: moveParticles, drawParticles, positionParticle, resetParticles, kickParticles e moveParticle. Uma classe chamada Particles foi criada e estes mtodos, transferidos para ela, alm da criao do mtodo createParticles. Como tais mtodos usam variveis de Vec3DemoFrame, uma referncia desta foi passada para aquela. Semelhantemente, foi criada a classe Vectors, onde os mtodos drawVectors e drawVector foram colocados. Seguindo a mesma idia, tambm foram criadas as classes Line responsvel pelas linhas de fora, Cube responsvel pela criao do cubo onde as simulaes ocorrem, Constants onde foram definidas as

44

constantes usadas pelo sistema, EquiPoint e Equipotential responsveis pelas superfcies equipotenciais, AuxActions responsvel por variveis e mtodos comuns a vrias classes e Main, que passou a ser a responsvel por iniciar o simulador. Alguns mtodos tambm foram fragmentados para diminuio de sua complexidade, como por exemplo, init.

4.3.3 3 ciclo Supresso de Vec3Demo Durante os dois primeiros ciclos levantou-se um novo requisito. O objetivo no criar uma aplicao que tenha que ser embutida em uma pgina HTML. No h a necessidade que a aplicao seja um applet. A classe Vec3Demo foi eliminada. Como o desencadear dos eventos comeava no mtodo init do applet e ele deixou de existir, a classe Main passou a cham-lo, a partir de instncia de Vec3DemoFrame. Tambm foi necessria a alterao do mtodo handleEvent para no 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 substitudo por vec3DemoFrame.dispose();

4.3.4 4 ciclo Modificao da Interface No item 4.2.2, foi apontada a proposta de alterao de algumas caractersticas da interface. Estas alteraes so apresentadas a partir da Figura 15.

45

Figura 15. Interface em Modificao

Para que os botes fossem colocados um ao lado do outro, alterou-se Vec3DemoLayout. O mtodo LayoutContainer determina, primeiramente, o posicionamento da rea da simulao (Canvas) e, a partir disto, o posicionamento do menu. Ambas as larguras dependem da largura do maior elemento do menu. Uma iterao feita para se avaliar qual elemento do menu est sendo acrescentado e as alteraes de posio e largura so realizadas. Os elementos diferentes dos botes se posicionam com espaos verticais entre eles por causa dos labels sem string que so colocados entre eles em Vec3DemoFrame e que so verificados na iterao, determinando o acrscimo de uma varivel de controle. Nesta iterao, acrescentou-se

46

uma clusula if-else para verificar-se se o elemento era um boto. Em caso afirmativo, o seu tamanho determinado como 1/3 da rea do menu, j que so trs e o posicionamento vertical no alterado para ficarem alinhados. O resultado apresentado na Figura 16.

Figura 16. Interface em Modificao 2.

Outra modificao realizada na interface foi a traduo dos componentes textuais do Ingls para o Portugus, j que o pblico alvo ser composto, de modo geral, por estudantes e professores do ensino mdio brasileiro, como j sugerido. Esta modificao foi realizada na classe Vec3DemoFrame. A Figura 17 apresenta o resultado.

47

Figura 17. Interface em Modificao 3

Para

modificao

do

visual

dos

elementos

da

interface,

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 aparncia definida pela plataforma Nimbus. O mtodo handleEvent deixou de fazer sentido j que a janela passou a ser fechada por setDefaultCloseOperation (JFrame.EXIT_ON_CLOSE). A classe Canvas tambm um componente AWT. Ento, ela foi transformada, estendendo JComponent, e o mtodo paint foi substitudo 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 estratgico. A modificao da interface ocorreu em duas

48

etapas. Se estas etapas tivessem ocorrido na ordem inversa, no haveria necessidade da alterao de Vec3DemoLayout, poupando esforo.

4.3.5 5 ciclo Reviso

Com a reviso do cdigo e das funcionalidades, notou-se que o boto Reiniciar ficava ativado para opes como Linhas de Fora o que no faz sentido, j que ele est relacionado ao movimento das partculas. Isto foi corrigido. Opcionalmente, retirou-se a barra de rolagem responsvel pela alterao da intensidade do campo. O gradiente de cores dos vetores campo eltrico e das linhas de fora j sugere que o campo eltrico se modifica com a distncia e o movimento das partculas mostra o aumento de sua intensidade com a diminuio da distncia. Tambm passaram a serem usados alguns cones e textos explicativos ao invs de ttulos. A nova interface apresentada na Figura 18.

49

Figura 18. Nova Interface com Usurio

4.3.6 Mtricas para o Simulador Modificado A Figura 19 apresenta as mtricas obtidas pelo SourceMonitor para o simulador modificado.

50

Figura 19. Mtricas (SourceMonitor) para o Simulador Modificado .

Os nmeros mostram que a classe Vec3DemoFrame ponto crtico da aplicao - (chamada agora de Vec3DemoJFrame) foi simplificada. Comparando com a Figura 12 do item 4.2.3, o nmero de linhas de cdigo cerca de 24% da classe original; o nmero de declaraes, 20%; o nmero de chamadas a mtodos, 27%; a complexidade mxima, 5% e no h mais classes internas. A Figura 20 permite melhor visualizao a o respeito de outras mtricas.

51

Figura 20. Grfico Kiviat para Mtricas da Classe Vec3DemoJFrame .

Ela mostra a necessidade de mais comentrios. O alto nmero de mtodos por classe pode ser justificado pelo fato de que o programa conta o getters e setters presentes. Apesar disto, h indicao de quantidade excessiva de variveis de instncia e a mxima complexidade ainda est fora do intervalo desejado. A Figura 21 apresenta a perda de coeso dos mtodos calculada pelo Metrics.

Figura 21. Perda de Coeso de Mtodos do Sistema Modificado .

52

A coluna da direita mostra que algumas classes so coesas, como Vec3DemoJComponent, Cube, Main, entre outras, pois a mtrica tem valor 0. Mas Vec3DemoJFrame no, j que o valor da mtrica continua prximo a 1. Ela ainda divergente, sendo responsvel por vrias atividades difusas, ou seja, que no tem propsito especfico comum. Alm disto, a maioria das classes est acoplada a Vec3DemoJFrame, o que pode ser verificado no javadoc disponvel no CD anexado.

5.

Concluses

O Simulador de Campo Eltrico, resultado da reengenharia do 3D Vector Fields Applet V1.3, de cdigo fonte aberto e gratuito, apresenta interaes entre fontes geradoras de campo eltrico e cargas de prova, visualizadas dentro de um cubo que pode ser rotacionado, dando s simulaes carter tridimensional e dinmico, e dispe de modelos representativos vetores campo eltrico, linhas de fora e superfcies equipotenciais. A interface com usurio tem seus elementos textuais escritos em Lngua Portuguesa. Acredita-se que seus componentes estejam mais bem distribudos e seu aspecto visual seja mais atrativo que o aspecto do simulador original. Tais caractersticas apontam para o sucesso na melhoria da usabilidade, conforme definio do termo neste trabalho. A classe Vec3DemoFrame foi fragmentada em classes menores, assim como alguns de seus mtodos; o cdigo foi fatorado e recomentado, mtodos depreciados foram substitudos e fragmentos de cdigo no utilizados foram retirados. Algumas classes ainda apresentam baixa coeso, inclusive Vec3DemoJFrame, e a maioria daquelas est altamente acoplada a esta, j que no foram empreendidos esforos na melhoria do design de comunicao entre as classes. Assim, a melhoria na extensibilidade, como definida nesta monografia, foi parcialmente alcanada, indicando

53

a dificuldade em adaptar um sistema que no foi projetado adequadamente em termos de orientao a objetos, aos requisitos deste paradigma. Apesar das modificaes relativas usabilidade apontarem para sua melhoria, testes de usurio precisam ser realizados para verificao o que pode ser feito por trabalhos futuros. Com estes trabalhos podem ser criadas novas funcionalidades, como a apresentao da magnitude do campo eltrico nos pontos da regio onde as simulaes ocorrem e a opo de apresentao de linhas de fora junto com superfcies equipotenciais. E tambm a busca pela melhoria da extensibilidade, incluindo projeto de design de pacotes.

Referncias Bibliogrficas
AUDINO, D.F.; NASCIMENTO, R.S. Objetos de Aprendizagem Dilogos entre Conceitos e uma Nova Proposio Aplicada Educao. Revista Contempornea de Educao. V.5, N 10, jul/dez 2010. Disponvel 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. Introduo interao humano computador. In:______. Interao humano computador. So Carlos: Compacta, 2009. p. 17 42. BATES, B.; SIERRA, K. Acoplamento e Coeso. In: ______. Certificao Sun para programador Java 6: Guia de Estudo. Rio de Janeiro: Altabooks, 2006. p. 88 90.

BATES, B.; SIERRA, K. Lance seu cdigo. In: ______. Use a cabea! Java. Rio de Janeiro: Altabooks, 2010. p. 408 421.

54

BRASIL. Ministrio da Educao e Cultura. Lei de Diretrizes e Bases da Educao Nacional, Lei 9.394 de 20/12/1996. BRASIL. Ministrio da Educao e Cultura. Plano Curricular Nacional +Ensino Mdio - Orientaes Educacionais Complementares a o s Parmetros Curriculares Nacionais: Cincias da Natureza, Matemtica e suas Tecnologias. Disponvel em: < http://portal.mec.gov.br/seb/arquivos/pdf/CienciasNatureza.pdf>. Acesso em: 10 out. 2012. CAELUM. Apostila do curso FJ-11 Java e Orientao a Objetos. In:______. Uma Breve Histria do Java. Disponvel em: <http://www.caelum.com.br/apostila-javaorientacao-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:______. Introduo aos Computadores, Internet e World Wide Web. So Paulo: Pearson, 2010. p. 2 19. ESTEINMACHER, I. et al.; GeCA: Uma Ferramenta de Engenharia Reversa e Gerao Automtica de Cdigo. In: SIMPSIO BRASILEIRO DE SISTEMAS DE INFORMAO, 3, 2006, Curitiba. Anais... Disponvel 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 Falstads Home Page. Disponvel em: <

http://www.falstad.com/>. Acesso em: 29 nov. 2011. GASPAR, A. Os parmetros curriculares nacionais. In: ______. Fsica: Eletromagnetismo/ Fsica Moderna, Manual do professor. So Paulo: tica, 2001. p. 10 18.

55

GASPAR, A. Atividades interdisciplinares e de contextualizao. In: ______. Fsica: Eletromagnetismo/ Fsica Moderna, Manual do professor. So Paulo: tica, 2001. p. 29 34. LIMA, L.S. Um Estudo Investigativo sobre a Insero de Tecnologia Multimda no Ensino de Fsica de Nvel Mdio. 2012. 101 f. Dissertao (Mestrado em Ensino de Cincia e Matemtica). Departamento de Cincias, Universidade Federal do Cear, Fortaleza, 2012. Disponvel 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. Disponvel em: < http://www.cin.ufpe.br/~alt/mestrado/oodmetrc.pdf >. Acesso em: 11 out. 2012.

MORAES, J.U.P. A viso dos alunos sobre o ensino de fsica: um estudo de caso.
Scientia Plena, Sergipe, V5, N11, 2009. Disponvel em: Acesso <http://www.scientiaplena.org.br/ojs/index.php/sp/article/viewFile/736/392>. em: 11 out. 2012.
PIEKARSKI, A.E.T.; QUINIA, M.A. Reengenharia de software: o que, por qu e

como. Guarapuava: Departamento de Informtica UNICENTRO. 19 p. Artigo. Disponvel 12 out. 2012. PIZZOLATO, E. B.; Programao Orientada a Objetos. In:______. Orientao o Objetos com C++. So Carlos: Departamento de Produo Grfica UFSCar, 2008. p. 29 66. em: < http://revistas.unicentro.br/index.php/RECEN/article/download/528/697 >. Acesso em:

56

PRESSMAN, R.S. Engenharia de Software. In:______. Reengenharia. McGraw-Hill, 2006. p. 681-698.

ROSA, C. W.; FILHO, J.P.A. Evocao Espontnea do Pensamento Metacognitivo nas Aulas de Fsica: estabelecendo comparaes com as situaes cotidianas. Investigaes em Ensino de Cincias, Florianpolis, V17(1), pp. 7-19, 2012. Disponvel 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 Fsica: Um estudo da produo Gestual de Estudantes Universitrios. Novas Tecnologias na Educao, Rio Grande do Sul, V. 10 N 1, julho, 2012. Disponvel em: < http://seer.ufrgs.br/renote/article/view/30868/19224>. Acesso em: 11 out. 2012. SERWAY, A. R.; JR., J. W. J. Foras Eltricas e Campos Eltricos. In: ______. Princpios de Fsica: Eletromagnetismo. So Paulo: Pioneira Thomson Learning, 2004. p. 677-709. SERWAY, A. R.; JR., J. W. J. Potencial Eltrico e Capacitncia. In: ______. Princpios de Fsica: Eletromagnetismo. So Paulo: Pioneira Thomson Learning, 2004. p. 719754.