• Pacotes ou bibliotecas: são um conjunto de classes e métodos que estendem as funcionalidades básicas do programa. No desenvolvimento do CABEMT utilizaram-se os seguintes pacotes de terceiros: jBlas, jLapack, jogl, Jama, commons-math e vecmath. jBlas e jLapack são pacotes derivados das famosas bibliotecas Blas e Lapack escritas em Fortran e que fazem o tratamento de matrizes, solução de sistemas lineares e outras operações. Jogl é a biblioteca que permite o uso do OpenGL no Java. Jama é uma biblioteca de suporte para trabalho com matrizes e vetores. Commons-math é um pacote com diversas funções matemáticas e vecmath para trabalhos com vetores. Muitas funções matemáticas, no entanto, foram escritas especificamente para o CABEMT, de modo a serem o mais simples possível, tais como as funções abrigadas nas classes Calculator e Calculator2.
O código foi escrito na interface de desenvolvimento (IDE) NetBeans versão 7.2 e posteriormente na versão 10. O NetBeans é bastante completo e tem boas ferramentas de debug e perfilamento. Debug é o processo de avançar passo a passo ou por etapas no código e ler as variáveis, de modo a encontrar possíveis erros. O perfilamento consiste em estudar o uso de processamento e memória por cada função do programa de maneira a identificar gargalos no desempenho do código.
de engenharia. Ainda era necessário definir o método numérico para implementação.
Naturalmente, o método dos elementos finitos surgiu como primeira opção.
Contudo, percebida a dificuldade em gerar malhas tridimensionais de qualidade e especialmente criação de trincas nesse tipo de malha. Além disso, existe uma miríade de programas computacionais de MEF –, não seria interessante criar mais uma.
Sendo assim, alternativas foram procuradas.
O MEC se mostrou como uma opção bastante interessante, uma vez que necessitava de elementos somente na superfície do sólido. Isso iria poupar muito tempo na implementação do gerador de malha, além de ser conveniente para a modelagem de trincas porque afinal, são superfícies. Outras vantagens do MEC são a melhor precisão para o mesmo tamanho de malha se comparado ao MEF e também a capacidade de atribuição não-aproximada de condições de contorno em fronteiras infinitas (ALIABADI, 2002).
Terminada a implementação dos códigos de MCS, iniciou-se a programação do módulo elástico-linear, em seguida será implementada a capacidade de realizar simulações de problemas termoelásticos transientes, haja vista que ciclagens de tensões térmicas são comuns geradores/propagadores de defeitos. Por fim, será implementada a capacidade de tratar problemas elasto-plásticos.
Embora os objetivos foram se consolidando aos poucos, o desenvolvimento do CABEMT sempre teve como premissa de que o programa:
• Seria de simples utilização: por isso procurou-se limitar o número de comandos ao essencial, implementar dicas de uso em seus ícones (tooltips), fazer com que sua interface fosse semelhante a outros softwares;
• Permitiria a interação por mouse e por comandos: o programa deveria ser utilizado por meio do mouse e do uso de comandos. Isso agiliza a elaboração dos modelos;
• Todos os modelos sólidos seriam representados por poliedros: pois caso fossem adotadas as representações por NURBS ou quádricos, o tempo de implementação seria muito estendido. A representação por poliedros é adequada para a maioria dos problemas.
No que tange ao código em si, procurou-se utilizar o idioma inglês para nomear funções, objetos, classes e variáveis. Esse idioma, além de sua universalidade,
parece ter uma boa capacidade de condensação de ideias versus número de caracteres utilizado para expressá-las. Isso deixa o código mais limpo e de fácil leitura.
Os comentários, que são importantes para o entendimento dos algoritmos, foram elaborados em português. A partir daqui então, uma certa mistura dos idiomas ocorrerá, visto parecer razoável manter os mesmos nomes de classes na dissertação e no programa.
Quando se está programando, por vezes surge um conflito do tipo memória vs processamento. Peguemos um círculo, por exemplo. Podemos armazenar uma série de pontos subsequentes que o descrevem e no momento de desenhá-lo, basta invocar esses pontos de uma lista e passá-los como argumento para a função OpenGL apropriada35. Por outro lado, poderíamos armazenar somente o centro e o raio do círculo e toda vez que este precisasse ser desenhado, calcularíamos os pontos. Este método certamente consumirá menos espaço na memória, mas exigirá mais processamento.
Procurou-se um equilíbrio entre o consumo dos recursos de memória e processamento, uma vez que ambos são altamente exigidos no MEC. Entretanto, há um maior privilégio ao uso do processamento, já que ele pode ser interrompido em alguns setores do programa quando funções exigentes ao processador são invocadas. Isso em geral pode ser feito com a memória, a menos que se opte pelo lento processo de armazenar dados em disco.
É boa prática de programação atribuir nomes significativos às variáveis e atributos de classes ainda que para isso o nome acabe se tornando mais longo que a prudência estética permitiria. É também importante dividir as tarefas em objetivos simples e, portanto, mais facilmente conquistáveis. icar “preso” em partes do código não é incomum e tal divisão pode reduzir o efeito psicológico da frustração em não se avançar.
Ter soluções conhecidas para as quais se escreve um algoritmo é de suma importância para testar e, pelo menos reduzir, as chances de ocorrerem problemas quando uma parte maior do código entra em funcionamento. Erros podem ser difíceis de se encontrar, especialmente após troca de informações entre muitos algoritmos –
35 O OpenGL pode ser considerado uma linguagem de baixo nível. Não existe função para desenhar o círculo, deve ser informado o conjunto de segmentos.
situação na qual podem acumular mais de um tipo de erro, inclusive. Daí a importância do teste por etapas, algoritmos ou trechos de código. Utilizar uma IDE com boas capacidades de debug é crucial no tratamento de erros.
O tratamento de erros e exceções é uma tarefa importante na programação.
Geralmente os erros acontecem quando o usuário insere parâmetros incorretos ou não previstos na idealização do programa. Então condicionantes especiais devem ser dispostas no código, de modo a capturar essas impertinências e exibi-las ao usuário.
Isso não só ajuda o mesmo a contornar o problema, como também facilita o programador encontrar em qual parte do código o erro ou exceção está sendo gerada.
O CABEMT possui um sistema básico de tratamento de erros em algumas regiões críticas do código, porém, foi dada prioridade ao desenvolvimento de novas funções em vez de refinar o tratamento. De qualquer modo, a investigação de problemas nos algoritmos pode ser feita via debug, bastando possuir o estado e as condições geradoras de um determinado tipo de erro em mãos.
O CABEMT não tem como premissa fundamental ser à prova de erros, de tal sorte que o usuário pode gerar formas não realistas ao usar o modelador de maneira inapropriada. Essas anomalias geométricas, entretanto, devem ficar bastante explícitas e também causar erros em estágios mais avançados da modelagem. Cercar todas as possibilidades que levariam a irrealismos demandaria um tempo elevado e com pouco resultado em termos de confiabilidade do programa. Esse equilíbrio entre tempo de programação de um algoritmo e vantagens a serem obtidas com ele (custo benefício) foi sempre um norteador no desenvolvimento do CABEMT.