123456

123456
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
. . . . . . .a. .r.& i. .g. . o. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123456
.t .Tecnologia 1234
123456
1234
5 1234
123456
123456

Usando XML para criação de um padrão para

o intercâmbio de dados entre programas de
elementos finitos1

Marden C. Pinheiro2
Gray F. Moita3

Os programas de modelagem computacional através do Método dos Elementos Finitos possuem especializações
e metodologias de cálculo diferentes. Sendo assim, é comum a necessidade de se executar uma mesma
modelagem em programas distintos, objetivando a validação ou a complementação de resultados. Esta operação
é dificultada em função do volume dos dados e de uma ausência de padronização entre os programas, além da
pouca oferta de ferramentas para a importação e exportação de dados neste universo. Por outro lado, com a
estabilização e ampliação de uso da XML – Extensible Markup Language –, a criação de formatos neutros que
visem o intercâmbio de dados ficou bastante facilitada. Este trabalho detalha os esforços no sentido da proposição
de um Esquema XML capaz de descrever, de forma neutra e estruturada, os dados utilizados por programas de
modelagem através do Método dos Elementos Finitos, visando facilitar o intercâmbio de dados entre eles. A FEML,
ou Finite Element Markup Language, está em seus estágios iniciais e ainda circunscrita a um software específico
de análise estrutural. Serão necessários maiores aprofundamentos e novos estudos para sua ampliação e efetiva
aplicação no domínio do problema.

PALAVRAS-CHAVE: XML;
ESQUEMA XML;
ELEMENTOS FINITOS;
INTERCÂMBIO DE DADOS.

1 INTRODUÇÃO
Y

Z X

No universo de soluções automatizadas para

a modelagem de sistemas complexos, ou ainda nos
diversos sistemas de CAD, CAM, CAE e CIM, desta- FIGURA 1 – Exemplo de modelo discretizado em Elementos Finitos.

cam-se os programas que se utilizam do Método

dos Elementos Finitos (neste artigo identificados
O volume dos dados que descrevem os elementos
por programas MEF) para a análise de problemas
componentes de um modelo é potencialmente grande,
de engenharia regidos por equações diferenciais visto que é comum um objeto ser discretizado em cente-
ou sistemas de equações diferenciais. Estes progra- nas ou milhares de elementos.
mas tratam objetos, estruturas e fenômenos físicos, Além disso, as várias etapas de um projeto nem
expressos em modelos bastante complexos, que são sempre são executadas por um mesmo sistema de com-
discretizados em pequenos elementos, cujas carac- putação, dada sua complexidade. É comum, portanto, a
terísticas como topologia, geometria, materiais e utilização encadeada de vários programas MEF, sendo
esforços devem ser descritos para efeito da mode- que a saída de um determinado programa deve alimen-
lagem computacional. Um exemplo de um modelo tar a entrada do próximo na cadeia. Adicionalmente, pode
é mostrado na FIG. 1. ser necessária a verificação de um determinado modelo

1
Artigo apresentado no Congresso: XXIV CILAMCE - CONGRESSO ÍBERO LATINO-AMERICANO DE MÉTODOS COMPUTACIONAIS EM ENGENHARIA, 2003, Ouro Preto. Proceedings of the
XXIV Iberian Latin-American Congress on Computer Methods in Engineering. Ouro Preto - MG: UFOP, 2003. CD-Rom.
2
Núcleo de Informática e Computação – Faculdade de Engenharia e Arquitetura da FUMEC - Rua Cobre, 200 – 30310-190 – Belo Horizonte – MG, Brasil. marden@fea.fumec.br.
3
Departamento de Pesquisa e Pós-Graduação – CEFET-MG - Av. Amazonas, 7675 – 30510-000 – Belo Horizonte – MG, Brasil. gray@dppg.cefetmg.br.

Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004

 12345
12345
123412345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
123412345
6
12345
12345
em outro sistema que se utiliza de um algoritmo ou mé-
todo numérico distinto, exigindo a reentrada de dados
para a modelagem do objeto.
Fica patente a importância de um padrão de inter-
câmbio de dados, que pudesse minimizar os esforços
necessários para a entrada dos dados de um modelo que
exigisse a utilização de mais de um programa MEF. Isso
reduziria os erros decorrentes da redigitação, bem como
o tempo necessário para a finalização de um processo
de modelagem.
Este trabalho está centralizando esforços no senti-
do de se estabelecer um padrão de intercâmbio de da-
dos que possa facilitar este processo, como ilustrado na
FIG. 2. A base deste padrão é a XML (Extensible Markup
Language). Esta linguagem de marcação possui ferramen-
tas para a criação de aplicações que determinam a
estruturação e permitem a validação de um documento.
Uma destas ferramentas, chamada Esquema XML (XML
Schema), vem se tornando um padrão para a criação de
vocabulários e aplicações dentro do universo XML. A
FEML – Finite Element Markup Language –, objeto deste
estudo, está definida por um Esquema XML. A existência
de uma solução para este problema já teve sua impor-
tância determinada. Tratando especificamente da enge-
nharia de um sistema de acesso a dados por programas
de elementos finitos, PENG, LIU E LAW (2003) mostram
a necessidade de uma aplicação XML que permita uma
padronização, mas não propõem um esquema para este
fim. Em seu trabalho, os autores descrevem exatamente
o problema básico levantado por este estudo: a necessi-
dade de um seqüenciamento de programas para a reso-
lução de um problema, e a conseqüente dificuldade na
exportação de dados entre eles, por utilizarem formatos
proprietários na geração de saídas de dados.
FEML
EXPOR-
TAÇÃO
Formato
Neutro
IMPOR-
TAÇÃO
Programa MEF A
FIGURA 2 – A FEML: um formato neutro para o intercâmbio de dados
entre programas MEF.
2 ESFORÇOS NA BUSCA POR PADRONIZAÇÕES
Os padrões de intercâmbio de dados são bastante
conhecidos e difundidos. A indústria desenvolveu pa-
drões como o X12 (ASCX12, 2002) e o EDIFAT (UN/
Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004
. . . . . . . . . .&
. .Tecnologia
..................................................................
EDIFACT, 2003), objetivando a troca de informações entre
os componentes de uma cadeia produtiva. Embora se-
jam voltados para o intercâmbio de dados comerciais e
industriais, e não científicos, eles são importantes à me-
dida que ilustram a busca por ferramentas que permitam
sistemas distintos comunicarem entre si. É pertinente
observar que, mesmo antes da primeira publicação da
recomendação do W3C para a XML, em maio de 1998
(MARCHAL, 2000), BRYAN (1998) já apontava a impor-
tância da XML para o intercâmbio eletrônico de dados.
Mais especificamente no universo dos Elementos
Finitos, a ISO 10303 é um passo importante no sentido
de se criar um padrão para a modelagem de dados. Tra-
ta-se de uma padronização da International Organization
for Standardization, denominada Modelo de Dados STEP
– Standard for the Exchange of Product Model Data.
Dentro da especificação ISO 10303, existe um Protocolo
de Aplicação conhecido como AP209: Composite and
Metallic Structural Analysis and Related Design (Análise
Estrutural de Compostos, Estruturas Metálicas e Projetos
Correlatos). A AP209 provê padronização para intercâm-
bio de modelos quando em fase de análise estrutural
(ISO, 1999).
LEAL (2001) aponta as seguintes vantagens da
AP209: projeto e análise cooperativa, à medida em que
empresas e sistemas distintos possam compartilhar in-
formações; armazenamento de dados de projeto e análi-
se, utilizando um formato padronizado; e desenvolvi-
mento de sistemas integrados, que se utilizem da mesma
interface. A AP209 abrange pontos como dados de ele-
mentos finitos, configuração e gerenciamento de dados
(relação modelo/produto), geometria e compostos, cons-
tituindo-se, portanto, em um candidato a padrão para a
descrição de dados de Elementos Finitos. Entretanto,
devido à abrangência da proposta da AP209, suas
especificações são muito complexas, o que acarreta um
custo maior em sua implementação, configurando um
empecilho para a larga utilização.
Além das proposições originadas por entidades de
padronização, existem também alguns esforços no senti-
do de se estabelecerem padrões provenientes de insti-
tuições privadas. A empresa Autodesk, criadora do pro-
grama AutoCAD, vem investindo na criação e proposi-
Programa MEF B ção de padrões XML para a modelagem de objetos. Ex-
plicitamente, esta empresa apoia o desenvolvimento de
Esquemas XML com o propósito básico de facilitar a tro-
ca de dados nas áreas de Arquitetura, Engenharia e Cons-
trução (AUTODESK, 2002).
Há ainda algumas iniciativas isoladas de se gera-
rem interfaces entre programas MEF. O programa COS-
MOS/M possui aplicativos específicos para a geração de
interfaces para outros programas MEF como ANSYS,
NASTRAN e outros (Cosmos/M, 2003). Esta abordagem,
entretanto, não é interessante sob o ponto de vista efeti-
vo, pois exigiria potencialmente um número muito gran-
de de aplicativos para o estabelecimento de interfaces
entre cada um dos programas disponíveis.
 123456
123456
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
. . . . . . . . . .& . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123456
. .Tecnologia 1234
123456
1234
7 1234
123456
123456

3 O UNIVERSO XML uma estrutura em forma de árvore, de forma que um

documento XML possui um, e apenas um, elemento raiz
e, dentro deste, um número indefinido de outros ele-
mentos, que podem ser dispostos ou distribuídos em
A XML, segundo MARCHAL (2000), é uma lingua- níveis, em número também indefinido.
gem de marcação derivada da SGML – Standard Generalized As marcações que dão a estrutura a um documen-
Markup Language. Ao contrário da HTML (Hyper Text to XML não têm nomes predefinidos, mas possuem re-
Markup Language), cujo foco é a visualização de um do- gras de formação rígidas. Isso significa que podem ser
cumento e possui um conjunto limitado de marcações, a acrescidas marcações na medida da necessidade de cada
XML visa a sua estruturação. Desta forma, as marcações, ou aplicação, desde que elas sigam regras de formação bem
tags, em um documento XML possuem um significado definidas. Isso exige, por conseqüência, a necessidade
semântico. Como o próprio nome define, estas marcações de uma rigidez formal na XML que não está presente,
são extensíveis, ou seja, não há limites para a criação de por exemplo, na HTML (YOUNG, 2000).
novas marcações, o que amplia a gama de aplicação da Em um documento HTML, algumas tags não ne-
XML nas mais diversas áreas do conhecimento. cessitam ser fechadas. Na XML, isso acarretaria um erro
A XML nasceu como uma proposta para a disposi- de sintaxe. As marcações não apenas devem ser fechadas
ção de documentos na Internet. Mesmo antes de sua uma a uma, como também são case-sensitives, ou seja,
publicação como recomendação pelo W3C – World Wide sensíveis a caixa alta e caixa baixa na escrita.
Web Consortium – (BRAY et al., 2000), ela já era aponta- O conceito de Elemento. Um elemento, no uni-
da como uma solução para as várias restrições da HTML, verso XML, é cada um dos componentes de um docu-
como destacam CONNOLY, KHARE E RIFKIN (1997). mento. Além disso, um elemento deve ser delimitado
Seu potencial, entretanto, extrapola as aplicações por uma tag de início e outra de fim, e possui um con-
na Internet. A XML, desde a sua recomendação oficial, teúdo que pode ser:
vem ganhando espaço devido à sua expansibilidade, sen- a) nulo, ou seja, o elemento não possui conteúdo;
do utilizada em vários cenários e aplicações, não neces- b) atômico, ou seja, possuir um conteúdo simples;
sariamente ligadas à Web. Os próprios padrões de EDI já c) outro elemento, caso em que se define um ou-
estabelecidos, como citam FÜRST E SCHMIDT (2000), tro nível de marcação no documento, tornan-
tendem a migrar para aplicações XML, dadas suas difi- do o conceito de elemento recursivo.
culdades de expansão e regras de negócio fixas. No escopo deste estudo, eventualmente, será ne-
Dentre as grandes vantagens da utilização da XML, cessário distinguir um elemento, como definido acima,
destacam-se: de um Elemento Finito. Nestes casos, será utilizada a nota-
a) legibilidade: o fato de ser uma linguagem legí- ção Elemento XML e Elemento MEF, respectivamente.
vel, e até certo ponto compreensível pelo ser hu- No trecho de documento mostrado na FIG. 3 po-
mano (YOUNG, 2000), facilita a utilização da XML; dem ser vistos os conceitos sintáticos da XML. Note-se a
b) facilidade de validação: a XML é uma lingua- sintaxe de fechamento das tags e a presença de atributos
gem de fácil validação e leitura por programas, ou em alguns elementos.
seja, a construção de analisadores de dados XML,
geralmente denominados parsers, é relativamente
simples (TOLENTINO, 2002). Neste sentido, é im-
portante salientar a criação de Esquemas XML que
facilitam a criação de padrões e validações; <Topology>
c) simplicidade: a simplicidade sintática das mar- <Group Id="1">
cações e a forte carga semântica contida na estru- <ElementType>TPM6</ElementType>
tura hierárquica (MARCHAL, 2000) é outro fator </Group>
que contribui para a expansão do uso da XML. </Topology>
Diante deste cenário, a XML se apresenta como
candidata natural a um padrão de troca de dados entre FIGURA 3 – Exemplo de um trecho de documento XML.
programas MEF.

3.2 Ferramentas de validação de documentos XML

3.1 A sintaxe da XML

Um documento XML que atende as regras de sin-

A ênfase na estrutura da XML é talvez o seu con- taxe é considerado “bem-formado”. Entretanto, para a
ceito mais forte. Toda a sintaxe da XML gira em torno de grande maioria das aplicações, ele deve ser “válido”, ou

Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004

 12345
12345
123412345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
. . . . . . . . . .&
. .Tecnologia
..................................................................
123412345
8
12345
12345

melhor, passível de ser validado contra uma estrutura das características dos materiais, em um esforço que se
previamente definida, que constitui uma família de do- iniciou no NIST (National Institute of Standards and
cumentos. As especificações XML provêem alguns meca- Technology), em 1999.
nismos para se determinar a estrutura de validação de um A MatML pode ser utilizada dentro da aplicação
documento. Isso pode ser feito com uma DTD (Document da FEML para a descrição do material componente de
Type Definition) ou com um Esquema XML (XML Schema). um modelo. Em sua versão inicial, a FEML utiliza-se de
Ambos são objeto de recomendação do W3C. uma descrição sucinta das propriedades físicas de um
A DTD é ainda bastante utilizada, tendo sido a material, e o uso da MatML pode vir a ser de grande
primeira ferramenta de validação de documentos XML. importância quando da necessidade de descrição mais
Entretanto, o Esquema XML supera a DTD em vários precisa do material.
quesitos, como na especificação de tipos de dados, por Há um grande número de outras propostas de
exemplo (LEE e CHU, 2000). Além disso, o Esquema aplicações XML que podem ser importantes para a FEML,
XML é, por si, um documento XML, o que facilita seu como complemento ou extensão. Citam-se a XSIL
tratamento por parsers. O Esquema XML é, pois, uma (Extensible Scientific Interchange Language), a aecXML
aplicação XML capaz de definir estruturalmente uma clas- (Architecture, Engineering and Construction XML), a
se de documentos e, acima de tudo, validá-la. bcXML (Building Construction XML) e a ifcXML (Industry
Mais detalhadamente, um Esquema XML descreve Foundation Classes XML), dentre várias outras.
cada um dos elementos que compõem um documento
XML, explicitando exatamente o seu conteúdo e estrutu-
ra, informando quais elementos-filho podem aparecer
dentro de cada elemento-pai, e quantas vezes isso pode
ocorrer. Além disso, determina e tipifica cada atributo. 4 FEML: CRIAÇÃO DE UM ESQUEMA XML
Neste estudo, será proposto um Esquema XML,
dadas suas vantagens na caracterização e estruturação de
classes de documentos.
Existem várias ferramentas comerciais e de utiliza-
ção livre para a manipulação de documentos XML e para
a criação de Esquemas XML. Porém, é importante neste
3.3 Aplicações XML contexto citar a existência de esforços no sentido de se
criarem metodologias para o desenvolvimento de Esque-
mas XML. A utilização da UML (Unified Modeling
Language) se apresenta como uma abordagem potenci-
almente poderosa, como defende ROUTLEDGE et al.
O número de aplicações – ou vocabulários – XML (2001). Ali, é proposta uma metodologia que permite
tem crescido bastante. Algumas destas aplicações já se utilizar uma ferramenta de modelagem UML, partindo-
encontram estabilizadas e têm larga utilização. Geralmen- se de um modelo clássico de análise, com o desenvolvi-
te, estas aplicações são definidas por uma DTD ou por mento de um modelo conceitual de classes, posterior-
um Esquema XML, capazes de definir a estrutura dos mente transformado em um diagrama lógico de classes
documentos daquela aplicação, bem como os conteú- que, então, é mapeado em um Esquema XML. O passo
dos válidos. Estas aplicações mantêm o conceito da básico nesta abordagema é a transformação do modelo
expansibilidade da XML, mas o seu esquema de valida- conceitual em um diagrama lógico, para o que é sugerida
ção garante que todos os documentos daquela família a utilização da ORM – Object Role Modeling, cuja pro-
possuam o mesmo perfil. posta garante a criação de Esquemas XML normalizados,
A MathML – Mathematical Markup Language ou seja, sem redundâncias.
(CAPROTTI e CARLISLE, 1999) – é uma das aplicações A FEML, a bem da verdade, não foi criada a partir
XML mais conhecidas. Seu objetivo é descrever fórmu- de uma metodologia formal exatamente como propõe
las e equações matemáticas, destinadas a serem interpre- ROUTLEDGE et al. (2001). A criação de um Esquema
tadas e/ou visualizadas por programas de computador. XML passa pela determinação e compreensão de cada
Outra aplicação importante no contexto deste es- um dos elementos que compõem a família de documen-
tudo é a MatML – Materials Markup Language – cuja pro- tos, da estrutura deste e ainda do relacionamento entre
posta é a descrição precisa dos materiais que compõem elementos, bem como toda a descrição e tipificação dos
um objeto. É um esquema que visa o detalhamento da atributos e demais componentes.
composição química e das características físicas de um Nesta fase, a UML foi utilizada devido à sua facili-
determinado material. dade de hierarquização de classes. Alguns diagramas de
BEGLEY (2003) mostra a origem da MatML como classe UML foram desenvolvidos objetivando um mode-
fruto da necessidade de se trocarem dados a respeito lo que se apresentasse mais consistente. A partir do dia-

Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004

 123456
123456
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
. . . . . . . . . .& . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123456
. .Tecnologia 1234
123456
1234
9 1234
123456
123456

grama de classes mais consistente, desenvolveu-se um

<?xml version="1.0" encoding="UTF-8"?>
rascunho do documento, uma espécie de esqueleto da <xsd:schema xmlns:xsd=http://www.w3.org/2001/XMLSchema
estrutura proposta. elementFormDefault="qualified">
A FIG. 4 mostra um diagrama de classes UML <xsd:element name="Model">
<xsd:complexType>
que retrata o primeiro nível da FEML, bem como <xsd:sequence>
toda a hierarquia do elemento XML Topology. O <xsd:element ref="Identification"/>
rascunho do documento foi desenvolvido a par- <xsd:element ref="Options" minOccurs="0"/>
<xsd:element ref="Units"/>
tir deste diagrama. <xsd:element ref="Topology"/>
Depois de criado o Esquema XML a partir do <xsd:element ref="Geometry" minOccurs="0"/>
diagrama de classes, partiu-se para o desenvolvimen- <xsd:element ref="Material"/>
<xsd:element ref="SupportNodes"/>
to de programas que pudessem determinar a <xsd:element ref="LoadCases"/>
exeqüibilidade da proposta. A idéia central destes </xsd:sequence>
programas é simular as operações de exportação e </xsd:complexType>
</xsd:element>
importação de dados por um programa MEF. O Es-
quema XML inicialmente proposto para a FEML foi FIGURA 5 – Primeiro nível do Esquema XML da FEML.
alterado, a partir de modificações práticas necessárias
determinadas pelo desenvolvimento dos programas
de simulação de interfaces.
5 DESENVOLVIMENTO DE PROGRAMAS
SIMULADORES DE INTERFACE

Neste trabalho, foi muito impor-

tante a validação da proposta, ou seja,
a verificação de sua exeqüibilidade.
Para isso, foram desenvolvidos progra-
mas que simularam as operações de
exportação e importação de dados por
um programa MEF, de forma que se
pudesse avaliar o desempenho do for-
mato neutro proposto face a operações
de intercâmbio de dados.
A partir de modelagens do pro-
grama MEF LUSAS, e dos arquivos em
formato texto plano gerado para ex-
portação por este programa, desen-
volveu-se um programa que transfor-
ma este formato texto proprietário em
um formato neutro dentro da propos-
ta da FEML. De forma simétrica, outro
FIGURA 4 – UML de primeiro nível da FEML, com desenvolvimento do elemento Topology. programa parte do documento
estruturado em FEML e gera o forma-
to texto plano original.
Finalmente, utilizando programas disponíveis Não é objetivo deste estudo o desenvolvimento
no mercado, a FEML foi trabalhada no sentido de se de programas com o foco na tradução de formatos. Essa
abordagem exigiria a construção de um número muito
melhorar as descrições de tipos de dados, de forma a
grande de programas que fizessem as devidas traduções
utilizar mais profundamente um dos pontos fortes do
entre cada formato proprietário. Pelo contrário, propõe-
Esquema XML. se um formato que possa ser utilizado, ou incorporado,
O resultado deste desenvolvimento, ou seja, o como opção de formato de exportação e importação em
Esquema XML que descreve e estrutura a FEML, é ex- programas MEF de mercado.
tenso para o escopo deste artigo. A FIG. 5 mostra um Durante o desenvolvimento destes programas, não
trecho do Esquema XML que descreve o primeiro ní- apenas se verificou a exeqüibilidade da proposta da
vel da FEML, a título de exemplificação. FEML, como também se refinou a proposição inicial da

Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004

 12345
12345
123412345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
123412345
10
12345
12345
FEML. Mais ainda, foram encontradas algumas dificulda-
des que deverão ser transpostas para a efetiva adoção de
uma abordagem como a proposta neste estudo. Estas difi-
culdades estão detalhadas mais adiante neste documento.
Para este estágio inicial da FEML, foram escolhidos mo-
delos do espaço contínuo bidimensional no programa LUSAS.
5.1 Os programas de exportação e importação
A idéia central de simular a geração de um arquivo em
formato FEML, e posteriormente recriar o arquivo de dados
original exigiu, obviamente, a criação de dois programas.
No primeiro deles, um parser que consome dados dis-
postos no formato proprietário do LUSAS monta uma estrutu-
ra de dados interna que posteriormente é descarregada em
disco no formato FEML. É importante observar que a maior
dificuldade neste programa foi a criação do parser, pois,
uma vez que as estruturas de dados internas estão preen-
chidas, a geração do formato XML é bastante simples.
De forma análoga, o programa que tinha por fina-
lidade simular uma operação de importação de dados
deveria consumir dados FEML e gerar em sua saída um
formato texto plano proprietário. Um parser XML foi
desenvolvido, que lê os dados FEML e povoa estruturas
de dados internas. Depois de consumidos todos os da-
dos, passa-se para a geração do arquivo proprietário,
dentro do formato original.
A primeira constatação deste processo de desen-
volvimento foi a facilidade de se trabalhar com os dados
quando em formato XML. Nos dois programas desenvol-
vidos, as dificuldades de programação residem no trata-
mento dos dados proprietários, visto que eles não pos-
suem nenhuma preocupação estrutural.
Isso leva à conclusão que a implementação de
interfaces de geração e consumo de dados em formato
XML não deve ser de grande dificuldade para os
desenvolvedores dos programas MEF. Afinal, eles devem
apenas – na operação de exportação – descarregar suas
estruturas de dados internas em um formato que possui
uma estrutura lógica definida. Na operação inversa, im-
portação, os programas farão a leitura de um formato
estruturado e voltado para o escopo do problema, e pre-
encherão suas estruturas de dados internas.
Há, entretanto, alguns problemas que deverão ser
equacionados.
5.2 Problemas na criação do formato neutro
Como mencionado, utilizou-se nestes desenvol-
vimentos sempre arquivos do programa MEF LUSAS. As-
Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004
. . . . . . . . . .&
. .Tecnologia
..................................................................
sim, não houve problemas na determinação do elemen-
to finito a que se referia determinada estrutura.
Há que se enfatizar, porém, que os diversos pro-
gramas MEF utilizam-se de nomenclaturas próprias para
a determinação dos elementos componentes de um
modelo. Sendo assim, em operações de intercâmbio de
dados entre programas distintos, deve-se preocupar com
a determinação do elemento. Fica claro que a simples
referência ao nome utilizado no sistema de origem não
pode ser suficiente para a determinação exata no siste-
ma de destino. Isso exigiria um conhecimento prévio
de todos os elementos de todos os programas MEF por
cada sistema que se utilizasse desta ferramenta, subver-
tendo os preceitos aqui defendidos.
É sabido, no entanto, que existe a possibilidade
de se efetuar um mapeamento entre os elementos de
programas MEF distintos, pois a base teórica matemática
é a mesma nos vários sistemas.
Tome-se, a título ilustrativo, um elemento do es-
paço contínuo bidimensional, estático, em estado plano
de tensão, triangular, e de interpolação quadrática (seis
nós), é denominado TPM6 no LUSAS. Certamente os
outros programas MEF possuem tal elemento em suas
bibliotecas de tipos básicos, mas a simples menção do
nome TPM6 não deve ser suficiente para que o sistema
de destino determine o elemento a que se refere, a não
ser que possua a mesma biblioteca.
PINHEIRO (2003) aponta a necessidade de
equacionamento deste problema como condição prévia para
a proposição de um formato neutro. A solução proposta é
a definição de uma estrutura hierárquica que possa deter-
minar os elementos a partir de suas características básicas.
Esta tipificação dos elementos é possível com a
determinação de uma árvore de tipos básicos, em que
cada nível hierárquico seja uma especialização do nível
superior. A partir das características exportadas, o pro-
grama destino pode determinar o elemento correspon-
dente em sua biblioteca de elementos.
Para a família dos elementos do espaço contínuo
bidimensional, devem ser necessários cinco níveis hie-
rárquicos, a saber: Família (Family), Formato (Shape),
Aplicação (Application), Ordem (Order) e Tipo do Ele-
mento (Element-Type). A FIG. 6 mostra esta árvore hie-
rárquica. Note-se que cada nível foi implementado como
uma especialização de classes em um diagrama UML.
Há ainda algumas ponderações a serem feitas nes-
ta proposição. Existem tipos com uma especialização
muito forte nos programas MEF. Como foi mencionado
anteriormente, os programas MEF possuem determina-
das especializações ou abordagens que, eventualmente,
podem exigir um elemento que não exista no sistema
de destino. Pelo fato de, inicialmente, este estudo res-
tringir-se ao programa LUSAS, a árvore de especializações
sugerida pode não contemplar todas as possibilidades
de classificação dos elementos.
Entretanto, isso pode ser contornado com a deter-
minação de um elemento mais próximo, menos especializa-
do, no programa MEF destino, sendo sua caracterização
final objeto de especificação manual numa etapa posterior.
 123456
123456
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
. . . . . . . . . .& . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123456
. .Tecnologia 1234
123456
1234
11 1234
123456
123456

OCKERBLOOM (1998) sugere o TOM – Typed dados de um modelo típico, costuma ser uma fonte poten-
Object Model – para a solução de problemas como este. cial de erros, à medida que o fornecimento dos dados é
O TOM descreve uma estrutura abstrata de dados, sua semi-automático e, por vezes, manual. Assim, a adoção de
representação concreta e ainda os relacionamentos entre um formato neutro, que possa ser implementado nos pro-
os diversos tipos. Assim, ele provê uma forma de se pro- gramas MEF para o intercâmbio de dados de um modelo, é
ceder a conversão ou a determinação de um novo tipo muito importante neste contexto.
(casting), a partir do modelo hierárquico conhecido. É importante ressalvar que ainda há muito o que se de-
Outros problemas dizem respeito a característi- senvolver na FEML. A seguir, listam-se alguns itens que são de
cas únicas de cada programa MEF. Por exemplo, o grande importância para a sua estabilização e concretização como
LUSAS possui várias opções de processamento que proposta efetiva para implementação nos programas MEF. Pro-
eventualmente necessitam ser exportadas, mas que curou-se manter uma ordem de complexidade a partir do pon-
podem não ser implementadas ou não fazer sentido to em que este trabalho se encontra.
no universo para o qual os dados serão exportados. a) aplicabilidade em outras famílias de elementos.
Todos os testes feitos até o momento se restringi-
ram à família de elementos do espaço contínuo
bidimensional. O envolvimento de outras famílias
de elementos será fundamental para encorpar a pro-
posta da FEML. Com a incorporação de outras famí-
lias, serão propostas novas estruturas hierárquicas.
Particularmente, espera-se uma dificuldade maior
ao se trabalhar com elementos tridimensionais, haja
vista a diversidade de elementos nesta família;
b) aplicabilidade em outros programas. Como os
testes foram feitos, até o momento, em um único
programa MEF, é muito importante que sejam es-
tendidos a outros programas, como forma de va-
lidação. Mesmo que a estrutura hierárquica pro-
posta para a tipificação dos elementos pretenda
ser de certa forma universal, é fundamental que
se executem testes de exportação e importação
entre programas distintos;
c) aplicabilidade em outro escopo de problemas.
Os testes até então se restringiram a modelagens
estruturais. Como o universo dos Elementos
Finitos se presta a modelagens de vários proble-
mas de engenharia, é interessante o estudo de
sua aplicação em programas MEF que permitam
outras modelagens e aplicações;
d) desenvolvimento de uma camada de visualização.
É patente que os programas MEF atualmente pos-
suem boas interfaces visuais, permitindo a
visualização de um modelo de forma bastante de-
FIGURA 6 – Árvore de elementos da família do espaço bidimensional talhada. Entretanto, devido à complexidade e à
representada em UML.
FONTE - PINHEIRO (2003).
pequena disponibilidade destes programas, nem
sempre se tem uma cópia disponível para a
visualização de um modelo. O desenvolvimento
6 CONCLUSÕES E DESENVOLVIMENTOS FUTUROS de uma interface visual que permita a visualização
do modelo em um programa trivial – um browser,
por exemplo –, pode resolver este problema.

Fica claro que não se pretende obter, com a FEML,

uma linguagem única, um “esperanto” para os programas
de modelagem pelo Método dos Elementos Finitos. En- 7 ABSTRACT
tretanto, pretende-se que seja um passo importante em
direção à minimização dos esforços e do tempo necessári-
os para se empreender uma modelagem que envolva vári-
os programas seqüenciados. A etapa de entrada de dados, Different finite element programs use different
além de ser bastante demorada por causa do volume de element types and formulations. Hence, sometimes it is

Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004

 12345
12345
123412345
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Educação
. . . . . . . . . .&
. .Tecnologia
..................................................................
123412345
12
12345
12345

necessary to apply distinct finite element codes to run 7 CONNOLLY, D., KHARE, R. and RIFKIN, A., 1997. The
the same model in order to complement or validate the evolution of web documents: the ascent of XML.
obtained results. However this is not easy to accomplish Disponível em: <http://www.xml.com/pub/a/w3j/
due to the fact that there is not a standard file format for s3.connolly.html>. Acesso: 31 mar. 2003.
the exchange of data amongst the variety of finite element
packages currently in the market. A standard format could 8 COSMOS/M, 2003. Analysis translators. Disponível
improve the analysis process since a data output file could em: <http://www.cosmosm.com/translators.htm>.
be used as a data input for a different system, regardless Acesso: 25 fev. 2003.
of the source and the target, consequently minimising 9 FÜRST, K. & SCHMIDT, T., 2000. Proceedings of
errors while exporting data between different systems. internet electronic data interchange with
The XML – Extensible Markup Language – proposal XML and java. In: XML EUROPE, jun, Paris, France.
focuses not only on data structure, but also on its
validation through the creation of vocabularies known as 10 ISO – International Organization for Standardization,
XML Schemas. This work suggests the establishment of a 1999. Recommended practices for AP209.
XML vocabulary for the exchange of data in finite element ISO10303 Specification, jun. Disponível em: <http://
analyses, namely FEML. The use of the FEML, in pdesinc.aticorp.org/whatsnew/recprac209v1a.pdf>.
conjunction with easy implementations of input and Acesso: 20 mar. 2003.
output interfaces for the different systems, will guarantee 11 LEAL, D., 2001, Open systems for engineering
a faster and reliable data exchange between different finite
analysis – made possible by a standard.
element software. The present development is on its
NAFEMS Benchmark Article. Disponível em: <http://
initial stage, and is still restricted to a specific structural
pdesinc.aticorp.org/whatsnew/
analyses finite element program. Therefore, it will be
nafems_ap209_article.doc>. Acesso: 20 mar. 2003.
necessary further research in order to accomplish a com-
plete application in the domain of the problem. 12 LEE, D. & CHU, W., 2000. Comparative Analysis of Six
Schema Languages. ACM SIGMOD Record, v. 29, n. 3, set.
13 MARCHAL, B., 2000. XML by example. 1st ed.,
Que, Indianapolis, Indiana, USA.
8 REFERÊNCIAS BIBLIOGRÁFICAS
14 OCKERBLOOM, J., 1998. Mediating among diverse
data formats. PhD Thesis – Carnegie Mellon
Computer Science Department. Pittsburg, PA, USA.
15 PENG, J., LIU, D. and LAW, K., 2003. An
1 ASCX12 – Accredited standard committee,
engineering data access system for a finite
2002. Disponível em: <http://www/x12.org>.
element program. Advances in Engineering
Acesso: 13 abr. 2003.
Software, v. 34, pp. 163-181.
2 AUTODESK, 2002. The XML revolution.
16 PINHEIRO, M., 2003. Proposta de um esquema
Whitepaper. Disponível em: <http://
XML para o intercâmbio de dados entre
www3.autodesk.com/latin_am_main/files/
programas de análise por elementos finitos.
622576_617079_AutoCAD2002_The_XML_Revolution.pdf>.
Dissertação (Mestrado em Tecnologia) – DPPG/
Acesso: 16 mar. 2003.
CEFET-MG, Belo Horizonte.
3 BEGLEY, E. F., 2003. NISTIR6939 – MatML version 3.0 17 ROUTLEDGE, N., BIRD, L. and GOODCHILD, A.,
XML schema. Disponível em: <http://www.matml.org/ 2002. UML and XML schema. Proceedings of 30th
downloads/MatMLv30.pdf> Acesso: 20 mar. 2003. Autralasian Conference on Database Technologies,
4 BRAY, T., PAOLI, J., SPERBERG-MCQUEEN, C. and Melbourne, Austrália.
MALER, E. (Ed.), 2000. Extensible markup language 18 TOLENTINO, R., 2002. Aplicações web em XML:
2nd. ed. W3C recomendation. Disponível em: estágio atual e tendências futuras. Dissertação (Mestrado
<http://www.w3.org/TR/REC-xml>. Acesso: 25 fev. 2003. em Tecnologia) – DPPG/CEFET-MG, Belo Horizonte.
5 BRYAN, M.(Ed.), 1998. Guidelines for using XML 19 UN/EDIFACT – United Nations Directories for
for eletronic data interchange. Disponível em: Electronic Data Interchange for Administration,
<http://www.xmledi-group.org/xmledigroup/ Commerce and Transport, 2003. UN/EDIFACT
guide.htm>. Acesso: 08 mar. 2003. Standard Directory. Disponível em: <http://
6 CAPROTTI, O. & CARLISLE, D., 1999. OpenMath www.unece.org/trade/untdid/welcome.htm>.
and MathML: semantical markup for Mathematics. Acesso: 13 abr 2003.
ACM Crossroads, vol. 6 issue 2. 20 YOUNG, M., 2000. XML step by step. 1st ed.
Microsoft Press, Redmond, Washington, USA.

Educ. Tecnol., Belo Horizonte, v.9, n.1, p.05-12, jan./jun. 2004