A principal métrica a ser adotada neste trabalho está relacionada à complexidade. Ao medir a complexidade do software é possível prever e compreender os fatores que provocam a baixa produtividade (LAIRD & BRENNAN, 2006). A complexidade estrutural aborda o projeto e a estrutura do software em si. Há várias métricas de complexidade estrutural. Neste trabalho será adotada a métrica estrutural orientada a objetos, que mensura as diferentes estruturas de programas orientado a objetos. Pretende-se com essas métricas mensurar classes, modularidade, encapsulamento, herança e abstração.
As métricas em questão formam um conjunto conhecido como métricas Chidamber e Kemerer (CK) (LAIRD & BRENNAN, 2006). Esse conjunto consiste de seis métricas que são utilizadas para mensurar o tamanho e a complexidade de classes, o uso da herança, o acoplamento entre as classe, a coesão de classes e a colaboração entre as classes. As métricas adotadas são:
1. WMC (Weighted Methods per Class): foca o número e a complexidade de métodos dentro da classe. Valores altos sugere que a classe deve ser dividida (ou refatorada) em classes menores;
2. DIT (Depth of Inheritance Tree): mensura o grau hirárquico de uma dada classe. Valores altos implicam em maior complexidade de projeto;
3. NOC (Number of Children): mensura o número de sucessores imediatos (classes filha) de uma dada classe. Valores altos indicam que a abstração das classes pai estão diluídas e, portanto, deve ser considerado rever o projeto;
4. CBO (Coupling Between Object Classes): mensura quantas classes se relacionam com uma dada classe. Valores altos implicam em maior complexidade, manutenibilidade e reusabilidade reduzidas;
5. RFC (Response for Class): mensura o número total de métodos potenciais a serem executados em uma classe quando essa recebe uma mensagem e deve, por sua vez, responder. Valores altos indicam complexidade maior; e
6. LCOM (Lack of Cohesion on Methods): mensura o número total de métodos dentro de uma classe que referenciam uma dada variável de instância. A complexidade e dificuldade de projeto crescem quando essa métrica é incrementada.
A modelagem do estudo de caso baseado no paradigma seqüencial culminou na criação das classes descritas na tabela 3. As classes identificadas na modelagem baseada no paradigma paralelo constam na tabela 4. As métricas apresentadas anteriormente foram aplicadas sobre as classes identificadas a fim de mensurar sua complexidade baseado nos critérios que compõe aquelas métricas:
Tabela 4: Aplicação de métricas (paradigma seqüencial)
Classe WMC DIT NOC CBO RFC LCOM
Controladora 1 0 0 2 1 1 ProjetaGrafo 4 0 0 2 1 1 ProcessaRotas 4 0 0 2 1 2 Graph 4 0 0 4 0 3 Edge 2 0 0 2 0 0 Vertex 6 0 0 2 0 0 Total 21 0 0 14 3 7
Tabela 5: Aplicação de métricas (paradigma paralelo)
Classe WMC DIT NOC CBO RFC LCOM
Controladora 1 0 0 2 1 1 ProjetaGrafo 3 0 0 2 1 1 ProcessaRotas 5 0 0 3 1 2 Graph 6 0 0 5 0 6 Edge 2 0 0 2 0 0 Vertex 4 0 0 2 0 0 SharedVars 5 0 0 1 1 0 EdgeLocker 3 0 0 1 1 0 Task 4 1 0 4 2 4 Total 33 1 0 22 7 14
É importante observar que a aplicação das métricas e os resultados conseguidos são válidos exclusivamente para o estudo de caso deste trabalho. Portanto, os resultados devem ser avaliados sob a ótica discursiva e não conclusiva.
De posse desses índices, percebe-se que no paradigma paralelo:
• Houve aproximadamente um aumento de 33% do número de classes no sistema em relação ao paradigma seqüencial. Esse aumento é provocado pela inserção de classes responsáveis pelo paralelismo por meio de threads (classe Task) e de classes que implementam a lógica de monitores (classe SharedVars) e locks (classe EdgeLocker). Pode-se observar que essas classes implementam a estrutura básica para o paralelismo. Trabalhos futuros poderiam realizar testes em larga escala a fim de verificar que esse aumento tende a estabilizar quando o sistema atinge tamanho de aproximadamente 35% maior que o sistema baseado no paradigma seqüencial. Pra tal, seria necessário adotar métricas relacionadas ao tamanho do software.
• A métrica WMC avalia a complexidade em relação ao número de métodos em uma classe, indicando que valores altos sugerem que a classe deve ser dividida (ou refatorada) em classes menores. Verifica-se que em algumas classes a complexidade diminui enquanto que em outras, aumentam. Considerando a média entre as classes, conclui-se que no paradigma seqüencial há uma média de complexidade igual a 3,5 por classe. No paradigma paralelo há uma média de complexidade de 3,6 por classe. Assim, para este estudo de caso, o acréscimo de classes necessárias à paralelização não trouxe aumentos significativos dos índices de complexidade de acordo com a métrica WMC
• A métrica DIT refere-se ao grau hierárquica entre as classes e a complexidade agregada a essa hierarquia. O estudo de caso não propiciou alterações relevantes nesse item de forma que não é possível discutir essa métrica pela ausência de dados significativos. A métrica NOC é proporcional à DIT e, por esse motivo, também não propicia discussões.
• A métrica CBO está relacionada ao acoplamento entre as classes. Valores altos indicam alto acoplamento. Ao observar individualmente as classes que participam de ambos os paradigmas, percebe-se que não houve alterações significativas dos índices. O mesmo é válido ao avaliar as médias. Em ambos os paradigmas, a média foi igual a 2,4. Ou seja, a adição de classes necessárias ao paralelismo não aumentou significativamente o acoplamento em geral das classes.
• A métrica RFC indica o número total de métodos potenciais a serem executados em uma classe quando essa recebe uma mensagem e deve, por sua vez, responder. Valores altos indicam complexidade maior. Considerando as médias, verificou que não houve aumento significativo de complexidade do paradigma paralelo em relação ao seqüencial
• A métrica LCOM refere-se à coesão das classes e indica, em valores altos, o aumento da dificuldade de projeto e da complexidade. Essa métrica foi a que apresentou a maior variação entre os paradigmas não sendo, no entanto, suficiente para concluir que o paradigma paralelo acarreta em menor coesão das classes em geral. No paradigma seqüencial, a média foi de 1,1 e no paralelo foi de 1,5.
As métricas CK auxiliam na avaliação de alguns aspectos relacionados ao desenvolvimento de software, como a produtividade, o esforço dispensando no processo de reutilização e projeto de
classes, na dificuldade em implementar classes e manutenibilidade. Ao analisar os índices conseguidos por meio das métricas apresentadas, verifica-se exclusivamente para o estudo de caso deste trabalho que:
• A produtividade está relacionada não somente à complexidade do software; o esforço também deve ser considerado. Portanto, não é possível apenas com a complexidade concluir que a produtividade é afetada quando desenvolve-se software paralelo, mesmo não havendo diferenças significativas entre os paradigmas seqüencial e paralelo.
• As reutilização não pôde ser avaliada pois está diretamente associada à métrica DIT e NOC, não consideradas nessa avaliação devido à pouca disponibilidade de dados
• A dificuldade em implementar e projetar classes está associada diretamente com a métrica LCOM, que mensura principalmente a coesão das classes. Houve uma diferença entre os paradigmas, o que justifica a maior dificuldade em projetar software paralelo (uma vez que esse obteve índices de complexidade mais altos). No entanto, é necessário que trabalhos futuros apliquem essa métrica em larga escala a fim de verificar uma tendência na dificuldade em projetar software paralelo
• A manutenibilidade está relacionada principalmente com a métrica CBO, que indica o grau de acoplamento entre as classes. Não foram identificadas diferenças significativas entre os paradigmas seqüencial e paralelo, de forma que pode-se sugerir uma discussão a respeito dos reais impactos na manutenibilidade do sistema que programas paralelos possam ocasionar. No caso específico deste trabalho, verifica-se que a manutenibilidade não é atingida quando paraleliza-se o programa.
Apesar do estudo de caso não apresentar complexidade suficiente ao ponto de criar vários cenários de use cases, foi possível aplicar as principais técnicas de análise para o estudo de caso em questão, acarretando na produção do caso de uso “traça rotas”. As mesmas técnicas adotadas em sistemas seqüenciais foram aplicadas para a produção de software paralelo. As características específicas do paralelismo devem ser abordadas principalmente no levantamento de requisitos não funcionais, onde questões como desempenho e consistência de dados são críticos. A descrição de cenários geralmente são em nível alto de abstração. Os aspectos de mais baixo nível (paralelismo de dados, fluxos de execução, etc.) são abstraídos. Esses aspectos ficaram mais evidentes na fase de projeto e na implementação. Na fase de projeto, percebeu-se que as diferenças entre os aspectos
seqüenciais e paralelos ficam mais evidentes quando o nível de abstração é mais baixo. Essa sentença contextualiza-se na seguinte citação de Sommerville (2003):
“os projetistas devem evitar, se possível, tomar decisões prematuras sobre a simultaneidade (...). É melhor decompor o sistema em módulos e, então, decidir durante a implementação se eles devem ser executados em seqüência ou em paralelo”.
TRABALHOS FUTUROS
A adoção de métricas é crucial para avaliar as técnicas de engenharia de software. Essas métricas abordam o tamanho, a complexidade e o esforço para produzir software. Verificou-se que a avaliação deve ser abrangente a fim de generalizar alguns aspectos como a produtividade, por exemplo. Essa abrangência pode sugerir uma tendência que indique o grau de dificuldade em produzir software paralelo em relação ao seqüencial. A aplicação das métricas CK e a conseqüente avaliação apresentada neste trabalho é específica para o estudo de caso do caixeiro-viajante. Portanto, trabalhos futuros poderiam aplicar métricas de tamanho, complexidade e esforço em uma gama maior de problemas passíveis de paralelização a fim de obter índices gerais de produtividade de software paralelo.
REFERÊNCIAS BIBLIOGRÁFICAS
ADL-TABATAI, Ali-Reza; KOZYRAKIS, Christos; SAHA, Bratin. A transactional
programming in a multi-core environment. 2006. Disponível em:
< http://csl.stanford.edu/~christos/publications/2006.unlocking_concurrency.queue.pdf >. Acesso em: 29 out. 2007.
ADL-TABATABAI, Ali-Reza; KOZYRAKIS, Christos; SAHA, Bratin. Unlocking Concurrency. 2006. Disponível em:
< http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=444&page=4 > Acesso em: 15 nov. 2007.
AMDAHL, Gene. Validity of the Single Processor Approach to Achieving Large-Scale
Computing Capabilities. AFIPS Conference Proceedings, 1967.
BARNEY, Blaise. Introduction to Parallel Computing. 2007. Disponível em: <https://computing.llnl.gov/tutorials/parallel_comp/>. Acesso em: 16 jun. 2008.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. 2. ed. Rio de Janeiro: Campus, 2006.
CARDOSO, Bruno; ROSA, Sávio R.A.; FERNANDES, Tiago M. Multicore. Campinas, 2006. Disponível em: < http://www.ic.unicamp.br/~rodolfo/Cursos/mc722/2s2005/Trabalho/g07- multicore.pdf>. Acesso em: 15 set. 2007.
CHARÃO, Andréa S. Análise de desempenho de programas paralelos. Santa Maria, 2006. Disponível em:
< http://www-usr.inf.ufsm.br/~andrea/elc139/slides-analise-desempenho-2006b.pdf>. Acesso em: 12 out. 2007.
COLOURIS, George. Sistemas distribuídos: conceitos e projetos. 4. ed. Porto Alegre: Bookman, 2007.
COM CIÊNCIA. O futuro à computação pertence. Disponível em:
<http://www.comciencia.br/comciencia/handler.php?section=3¬icia=268> Acessado em: 08 set. 2007.
ERIKSSON, H.; PENKER, M.; LYONS B.; FADO, D.; UML 2 Toolkit. Indianapolis, US: Wiley
Publishing Inc., 2004.
FAZZIO, A. Alguns aspectos da nanoeletrônica molecular. São Paulo, 2004.
Disponível em: <http://www.cepa.if.usp.br/e-fisica/divulgacao/oqueefisica/fazzio.php>. Acesso em: 30 out. 2007
GRUNE, Dick et al. Projeto moderno de compiladores: implementação e aplicações. Rio de
Janeiro: Campus, 2001.
HERCKERT, Matheus G.H. Fluidodinâmica computacional e suas aplicações. Uberlândia, 2004. Disponível em: < http://br.monografias.com/trabalhos/fluidodinamica/fluidodinamica.shtml > Acesso em: 16 nov. 2007.
HENNESSY, John L. ; PATTERSON, David A. Arquitetura de computadores: uma abordagem quantitativa. 3. ed. Rio de Janeiro: Campus, 2003.
INTEL. Intel Multi-core Briefing. [S.I.], 2005. Disponível em:
< http://download.intel.com/pressroom/kits/pentiumee/20050418presentation.pdf >. Acesso em: 12 out. 200
INTEL. Mudança radical: processamento multi-core abre possibilidades de negócio inovadoras. Disponível em:
< http://developer.intel.com/portugues/technology/magazine/computing/multi-core-software- 1006.htm>. Acesso em: 21 out. 2007.
INTEL. Processadores Core 2 Duo. Disponível em:
< http://www.intel.com/portugues/products/processor/core2duo/index.htm >. Acesso em: 25 set. 2007.
LAIRD, Linda M., BRENNAN, M. Carol. Software measurement and estimation: a practical approach. New Jersy: Wiley-Interscience, 2006.
LOUDON, Kyle. Dominando algoritmos com C. Rio de Janeiro: Ciência Moderna Ltda., 2000. MA, Josué T.H. Multicore. Campinas, 2006. Disponível em:
< http://www.ic.unicamp.br/~rodolfo/Cursos/mo401/2s2005/Trabalho/049180-multicores.pdf>. Acesso em: 23 set. 2007.
MACHADO, F.B.; MAIA, L.P. Arquitetura de Sistemas Operacionais. 3.ed. Rio de Janeiro: Livros Técnicos e Científicos, 2002.
PATTERSON, David A.; HENNESSY, John L. Organização e projeto de computadores: a interface hardware/software. 2. ed., Rio de Janeiro: Livros Técnicos e Científicos, 2000. SILBERSCHATZ, Abraham. Fundamentos de Sistemas Operacionais. 6. ed. Rio de Janeiro:
Livros Técnicos e Científicos, 2004
SILVEIRA, J.F Porto. Problema do Caixeiro Viajante .2000. Disponível em: <http://www.mat.ufrgs.br/~portosil/caixeiro.html>. Acesso em: 09 maio 2008.
SEBESTA, Robert W. Conceitos de linguagens de programação. 4. ed. Porto Alegre: Bookman, 2000.
JavaWorld, 2006.
Disponível em: < http://www.javaworld.com/javaworld/jw-07-2006/jw-0710-multicore.html > Acesso em: 27 out. 2007
SOMMERVILLE, Ian. Engenharia de Software. 6. ed. São Paulo: Pearson Education do Brasil, 2003.
TANENBAUM, Andrew S. Sistemas Operacionais Modernos. 2. ed. São Paulo: Pearson Education do Brasil, 2003.
TANENBAUM, Andrew S. Organização Estruturada de Computadores. 4. ed. Rio de Janeiro:
Livros Técnicos e Científicos, 2001.
WIKIPEDIA. Parallel computing. Disponível em:
< http://en.wikipedia.org/wiki/Parallel_Computing#Parallel_programming_models > Acessado em: 01 nov. 2007
WIKIPEDIA. Amdahl's law. Disponível em: < http://en.wikipedia.org/wiki/Amdahl%27s_law > Acessado em: 04 nov. 2007.