ESTUDO E DESENVOLVIMENTO DE M T D CAD/CAMgraco.unb.br/alvares/DOUTORADO/papers_omega/ricardo/... ·...

UNIVERSIDADE FEDERAL DE SANTA CATARINA � UFSC DEPARTAMENTO DE ENGENHARIA MECÂNICA

COORDENAÇÃO DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA

ESTUDO E DESENVOLVIMENTO DE METODOLOGIAS NA TROCA DE DADOS EM

CAD/CAM

Aluno: Raimundo Ricardo Matos da Cunha Curso: Doutorado em Engenharia Mecânica Área de concentração: Projeto de Sistemas Mecânicos

com ênfase em Sistemas CAD/CAE/CAM

Disciplina EMC 6601 � Tópicos Especiais em Projeto de Sistemas Mecânicos Prof. Altamir Dias, Dr. Eng.

Florianópolis � SC Abril/2000

II

SSuummáárriioo

CAPÍTULO 1 � INTRODUÇÃO.......................................................................... 1 1.1. OBJETIVOS ..................................................................................................................1

1.2. TÓPICOS ABORDADOS....................................................................................................2

CAPÍTULO 2 � MODELAGEM DE DADOS GEOMÉTRICOS EM CAD/CAM....... 3 2.1. INTRODUÇÃO................................................................................................................3

2.2. A REPRESENTAÇÃO DE DESENHOS E DIAGRAMAS ...............................................................4

2.3. REPRESENTAÇÃO TRIDIMENSIONAL...................................................................................7

2.3.1. Representação Wireframe.....................................................................................8

2.3.2. Representação de Superfície ..............................................................................11

Representação de Curvas 11

2.3.3. Representação de Sólido ....................................................................................18

Esquemas de Modelagem de Sólidos 19

Modelos CSG 20

Modelos B-Rep 22

CAPÍTULO 3 � PADRÕES DE TROCA DE DADOS EM CAD/CAM................... 24 3.1. INTRODUÇÃO..............................................................................................................24

3.2. EVOLUÇÃO DA TROCA DE DADOS EM CAD/CAM .............................................................26

3.3. TIPOS DE PADRÕES PARA TROCA DE DADOS.....................................................................29

3.3.1. IGES (Initial Graphics Exchange Specification) ...................................................29

Formato do Arquivo IGES 31

3.3.2. DXF (Data Interchange Format) .........................................................................32

Formato do Arquivo DXF 33

3.3.3. STEP (Standard for the Exchange of Product Data) .............................................34

Protocolo AP203 37

Outras Partes do STEP 38

Linguagem EXPRESS 38

Formato do Arquivo STEP 39

3.3.4. ACIS..................................................................................................................41

Conceitos e Características do ACIS 42

3.3.5. PARASOLID.......................................................................................................46

CAPÍTULO 4 � CONCEITOS E APLICAÇÃO DE BANCO DE DADOS ............... 47 4.1. INTRODUÇÃO..............................................................................................................47

4.2. DEFINIÇÕES E CONCEITOS............................................................................................49

4.3. A ESTRUTURA DE UM BANCO DE DADOS .........................................................................50

III

4.4. CLASSIFICAÇÃO DOS SISTEMAS DE BANCO DE DADOS........................................................52

4.4.1. O Modelo Relacional ..........................................................................................53

Operações da Álgebra Relacional 54

4.4.2. O Modelo Hierárquico ........................................................................................55

4.4.3. O Modelo em Rede .............................................................................................56

4.5. BANCO DE DADOS ORIENTADOS A OBJETOS ....................................................................57

4.6. APLICAÇÕES DE BANCO DE DADOS EM CAD ....................................................................59

4.6.1. Banco de Dados Orientados a Objeto em CAD ....................................................59

CAPÍTULO 5 � GERENCIAMENTO DA INFORMAÇÃO EM CAD/CAM ............. 61 5.1. INTRODUÇÃO..............................................................................................................61

5.1.1. O que é PDM?....................................................................................................62

5.2. CLASSIFICAÇÃO DE SISTEMAS PDM................................................................................64

5.2.1. Critérios Funcionais ..........................................................................................65

Origens dos Sistemas PDM 65

Campos Funcionais 66

Escopo de Aplicação 66

5.2.2. Critérios Técnicos ..............................................................................................66

Flexibilidade 66

Arquitetura e Plataforma Computacionais 67

Tipo de Base de Dados 67

Dados Gerenciados 67

5.3. OS BENEFÍCIOS DOS SISTEMAS PDM .............................................................................68

5.4. CARACTERÍSTICAS E FUNÇÕES DE UM SISTEMA PDM.........................................................70

5.4.1. As Funções do Usuário ......................................................................................72

Cofre de Dados e Gerenciamento de Documentos 72

Gerenciamento do Processo e do Fluxo de Dados 73

Gerenciamento da Estrutura do Produto 74

Classificação 75

Gerenciamento da Programação 77

5.4.2. As Funções Utilitárias........................................................................................77

Recursos de comunicação e notificação 77

Transporte de Dados 78

Conversão e Tradução de Dados 78

Serviços de Imagem 78

Administração do Sistema. 79

CAPÍTULO 6 � TÉCNICAS E METODOLOGIAS MODERNAS PARA TROCA DE

DADOS EM CAD/CAM.................................................................................. 80 6.1. INTRODUÇÃO..............................................................................................................80

6.2. QUADRO ATUAL DOS SISTEMAS CAD/CAM.....................................................................82

6.3. MODELAGEM E REPRESENTAÇÃO DO CONHECIMENTO........................................................83

6.4. TÉCNICAS DE MODELAGEM E REPRESENTAÇÃO ................................................................85

IV

6.4.1. Linguagens........................................................................................................85

6.4.2. Modelos Geométricos .........................................................................................86

6.4.3. Projeto Baseado em Features .............................................................................87

6.4.4. Imagens ............................................................................................................88

6.4.5. Grafos ...............................................................................................................89

6.4.6. Inteligência Artificial Aplicada ao Projeto ............................................................89

Tríade Função-Estrutura-Comportamento 90

Sistemas Especialistas 92

6.4.7. Orientação a Objeto em CAD..............................................................................93

Necessidade de uma Nova Modelagem de Objetos em CAD 94

6.4.8. Modelagem do Produto.......................................................................................96

A Programação Genética na Modelagem do Produto 97

6.5. CONSIDERAÇÕES FINAIS...............................................................................................99

REFERÊNCIAS BIBLIOGRÁFICAS............................................................... 101

BIBLIOGRAFIAS ......................................................................................... 104 APÊNDICE A � EXEMPLO DE ARQUIVO IGE ......................................................................... 106

APÊNDICE B � EXEMPLO DE ARQUIVO DXF ......................................................................... 107

APÊNDICE C � EXEMPLO DE ARQUIVO STEP........................................................................ 116

APÊNDICE D � EXEMPLO DE ARQUIVO ACIS ........................................................................ 119

APÊNDICE E � EXEMPLO DE ARQUIVO PARASOLID.............................................................. 120

APÊNDICE F � PROGRAMAÇÃO ORIENTADA A OBJETOS........................................................... 121

INTRODUÇÃO ................................................................................................................. 121

O Que é OOP? .......................................................................................................... 121

O Que é um Objeto?.................................................................................................. 121

Método ..................................................................................................................... 122

Dados do Objeto ....................................................................................................... 123

Mecanismo Seqüencial de Mensagens ....................................................................... 124

OS PRINCÍPIOS DA ORIENTAÇÃO A OBJETO .......................................................................... 125

Abstração de Dados .................................................................................................. 125

Encapsulamento de Dados........................................................................................ 126

Polimorfismo............................................................................................................. 127

Herança.................................................................................................................... 128

Reusabilidade ........................................................................................................... 129

SOLUÇÃO DE PROBLEMAS ORIENTADOS A OBJETOS............................................................... 129

V

LLiissttaa ddee FFiigguurraass

Figura 1. Vistas principais de um objeto. ................................................................................5

Figura 2. Simbologia usada em diagramas ..............................................................................6

Figura 3. Níveis de abstração em diagramas. ..........................................................................7

Figura 4. Interpretações de um modelo wireframe. ................................................................10

Figura 5. Visualização confusa .............................................................................................10

Figura 6. Linhas do contorno e da parede do furo .................................................................10

Figura 7. Superfície a partir de pontos. .................................................................................15

Figura 8. Superfície a partir de outras curvas. ......................................................................16

Figura 9. Superfície a partir de outras superfícies. ................................................................16

Figura 10. Superfícies three/four/five-sided. .........................................................................17

Figura 11. Primitivas e operações booleanas .........................................................................21

Figura 12. Estrutura de dados em árvore CSG. .....................................................................21

Figura 13. Estrutura de dados para modelos B-Rep. .............................................................22

Figura 14. Esquema da estrutura de dados asa de aresta......................................................23

Figura 15. Arquiteturas computacionais de troca e compartilhamento de dados. ...................26

Figura 16. Formas de tradução de arquivos. .........................................................................28

Figura 17. Exemplo de desenho de algumas entidades geométricas simples...........................31

Figura 18. Exemplo de arquivo IGES. ...................................................................................32

Figura 19. Arquitetura de camadas do STEP. ........................................................................35

Figura 20. Hierarquia de classes do ACIS..............................................................................43

Figura 21. Hierarquia topológica da representação B-Rep do ACIS.........................................44

Figura 22. Níveis de abstração de um banco de dados...........................................................51

Figura 23. Objeto-base e sua estrutura de dados: vértices, arestas, e faces............................54

Figura 24. Exemplo de banco de dados relacional. ................................................................54

Figura 25. Exemplo de banco de dados hierárquico...............................................................56

Figura 26. Exemplo de banco de dados em rede. ...................................................................57

Figura 27. Utilização do sistema PDM numa organização empresarial ...................................63

Figura 28. Visão funcional dos sistemas PDM.......................................................................70

Figura 29. Classificação hierárquica de peças padronizadas ..................................................76

Figura 30. Relacionamento entre modelos do ciclo de vida do produto ...................................81

Figura 31. Espectro das representações de modelagem em projeto ........................................85

Figura 32. Os elementos de um sistema especialista. ............................................................92

Figura 33. Combinações de produto simples. ........................................................................99

VI

Figura 34. Interface de comunicação entre os objetos.......................................................... 121

Figura 35. Mecanismo de mensagem entre dois objetos....................................................... 122

Figura 36. Passagem de parâmetro para um objeto. ............................................................ 122

Figura 37. Métodos de um objeto. ....................................................................................... 123

Figura 38. Acesso aos dados de um objeto. ......................................................................... 124

Figura 39. Encadeamento seqüencial de mensagens. .......................................................... 125

Figura 40. Abstração e representação de dados em OOP. .................................................... 125

Figura 41. Encapsulamento de dados em OOP.................................................................... 126

Figura 42. Exemplo de polimorfismo em OOP. .................................................................... 127

Figura 43. Exemplo de herança em OOP. ............................................................................ 128

VII

LLiissttaa ddee TTaabbeellaass

Tabela 1. Eixos de coordenadas para modelos tridimensionais. ...............................................8

Tabela 2. Exemplo de representação explícita e implícita de curvas. ......................................11

Tabela 3. Tipos de dados trocados ou compartilhados. ..........................................................25

Tabela 4. Tradução direta versus arquivo neutro na troca de dados.......................................27

Tabela 5. Entidades suportadas pelo IGES............................................................................29

Tabela 6. Protocolos STEP para projeto mecânico e análise estrutural. ..................................36

Tabela 7. Tipos de produtos gerenciados por sistemas PDM. .................................................64

Tabela 8. Indústrias que se beneficiam com os sistemas PDM. ..............................................64

Tabela 9. Tipos de dados gerenciados por sistemas PDM. ......................................................68

Tabela 10. Evolução das estratégias de modelagem com objetos ............................................94

Tabela 11. Classificação dos vários atributos de um objeto....................................................96

VIII

LLiissttaa ddee SSiiggllaass

AAM � Application Activity Model ................................................................... 36

ABNT � Associação Brasileira de Normas Técnicas........................................... 4

ADT � Abstract Data Types ........................................................................... 57

AI � Artificial Intelligence ............................................................................... 90

AIM � Application Interpreted Model............................................................... 36

ANSI � American National Standards Institute ............................................... 51

AP � Application Protocol................................................................................ 35

API � Application Programming Interface ........................................................ 42

ARM � Application Reference Model ............................................................... 36

BOM � Bill of Materials.................................................................................. 74

B-Rep � Boundary Representation ................................................................. 20

CAD � Computer-Aided Design......................................................................... 1

CAE � Computer-Aided Engineering ............................................................... 28

CAFD � Computer-Aided Fixture Design ......................................................... 84

CAM � Computer-Aided Manufacturing............................................................. 1

CAPP � Computer-Aided Process Planning ...................................................... 38

CAX � Computer-Aided "X"............................................................................. 25

CGI � Computer Graphics Interface ................................................................ 32

CGM � Computer Graphics Metafile................................................................ 32

CIM � Computer Integrated Manufacturing ..................................................... 61

CODASYL � Conference on Data Systems Languages .................................... 56

CR � Carriage-Return .................................................................................... 33

CSG � Constructive Solid Geometric ............................................................... 20

DBMS � Data Base Management System ....................................................... 49

DDL � Data Definition Language.................................................................... 52

DI � Direct Interface ...................................................................................... 42

DMU� Digital Mock-Up................................................................................... 62

DXF � Drawing Interchange File..................................................................... 28

IX

E/R � Entidade/Relacionamento ................................................................... 59

ECO � Engineering Change Orders ................................................................ 79

ECR � Engineering Change Requests ............................................................. 79

EDM � Engineering Data Management; Electronic Data Management .............. 63

EDMS � Electronic Data Management Systems .............................................. 61

ERP � Enterprise Requirements Planning ....................................................... 80

FGM � Functionally Graded Material.............................................................. 96

FMS � Flexible Manufacturing System............................................................ 99

GIF � Graphics Interchange File ..................................................................... 32

GP � Genetic Programming............................................................................. 99

GUI � Graphical User Interface ...................................................................... 80

IGES � Initial Graphics Exchange Specification .............................................. 27

IR � Integrated Resources.............................................................................. 36

ISO � International Organizational for Standardization ................................... 34

LF � Line-Feed .............................................................................................. 33

LM � Layered Manufacturing ......................................................................... 96

MRP � Materials Requirements Planning ........................................................ 62

NURBS � Non-Uniform Rational B-Spline........................................................ 14

OCR � Optical Character Recognition.............................................................. 72

OODB � Object-Oriented Data Base ............................................................... 57

OOP � Object-Oriented Programming ............................................................ 122

PDM � Product Data Management.................................................................... 1

PIM � Product Information Management ......................................................... 63

SAB � save as binary .................................................................................... 41

SAT � save as text ........................................................................................ 41

SFF � Solid Freeform Fabrication ................................................................... 95

STEP � Standard for the Exchange of Product Data........................................ 34

TDM � Technical Data Management............................................................... 63

TIFF � Tagged Image File Format .................................................................. 32

TIM � Technical Information Management ...................................................... 63

WBS � Work Breakdown Structures ............................................................... 77

CCaappííttuulloo 11

IInnttrroodduuççããoo

11..11.. OOBBJJEETTIIVVOOSS

Este estudo dirigido se baseou nos seguintes objetivos:

• Estudar as principais metodologias empregadas na troca de dados e

informações em CAD/CAM;

• Entender a integração de trocas de dados em sistemas CAD/CAM;

• Enfocar uma proposta de generalização do compartilhamento de dados

entre as fases de detalhamento de projeto e a preparação para a

fabricação de produtos e sistemas;

Além desses objetivos principais, pode-se citar outros objetivos

relacionados que também serviram de estímulo à pesquisa e à escrita desse

estudo dirigido:

• Revisar e atualizar diversos conceitos de tecnologias de CAD/CAM, tais

como: modelagem de sólidos;

• Estudar novas tecnologias integradas ao CAD/CAM na atualidade, tais

como: sistemas de banco de dados, sistemas PDM;

CAP. 1 � INTRODUÇÃO 2

• Ampliar as pesquisas de bibliografias mais atualizadas sobre os tópicos

tratados nesse estudo dirigido;

• Embasamento teórico e revisão bibliográfica para iniciar a elaboração

de uma proposta de exame de qualificação ao Doutorado.

11..22.. TTÓÓPPIICCOOSS AABBOORRDDAADDOOSS

O texto apresentado nesse estudo dirigido, baseou-se inicialmente nos

tópicos assinalados na elaboração. À medida que as pesquisas e a escrita foi se

desenvolvendo, houve uma reordenação dos tópicos, ou mesmo uma melhor

consistência da estrutura do texto.

A seguir, tem-se uma breve descrição dos assuntos discutidos em cada

capítulo desse estudo dirigido:

No Capítulo 2, tem-se a descrição dos modelos utilizados para

representação dos projetos de Engenharia, e uma discussão sobre as principais

técnicas de modelagem geométrica em sistemas CAD/CAM.

No Capítulo 3, tem-se uma discussão sobre os principais padrões de

arquivos e tecnologias utilizados para troca e o compartilhamento de dados.

No Capítulo 4, descreve-se os sistemas de gerenciamento de banco de

dados, sua estrutura e os principais tipos.

No Capítulo 5, discute-se os sistemas PDM, suas origens, classificação,

características, benefícios, e aplicações.

No Capítulo 6, tem-se uma abordagem do conjunto de técnicas utilizadas

e aplicadas para a troca e o compartilhamento de dados, a descrição de novas

tecnologias em sistemas CAD/CAM, e algumas considerações finais sobre a

pesquisa realizada.

E para finalizar o estudo dirigido, no APÊNDICE F tem-se uma discussão

sobre os conceitos básicos e princípios da programação orientada a objetos.


MMooddeellaaggeemm ddee DDaaddooss GGeeoommééttrriiccooss eemm CCAADD//CCAAMM

22..11.. IINNTTRROODDUUÇÇÃÃOO

Os modelos de projeto utilizados na Engenharia resumem-se a dois tipos:

• Modelos do processo de projeto: descrevem a maneira e os padrões de

procedimentos seguidos pelo projetista durante o desenvolvimento do

projeto. Estes modelos são abstratos, ou seja, o projeto ainda não

existe fisicamente. Como exemplo, pode-se citar as várias metodologias

de projeto descritas na literatura científica.

• Modelos do produto: descrevem o projeto em si, de tal forma que o

projetista possa avaliá-lo, manipulá-lo, e otimizá-lo. O modelo do

projeto é uma representação física do projeto, que pode assumir formas

diferenciadas dependendo do enfoque ou contexto. Estes modelos

abrangem todas as representações utilizadas na modelagem do projeto.

De todas as propriedades (função, estrutura, forma, material, condições

superficiais, e dimensões) modeladas pelos modelos de produto, duas delas têm

CAP. 2 � MODELAGEM DE DADOS GEOMÉTRICOS EM CAD/CAM 4

particular importância na Engenharia: a forma dos componentes e peças, e a

estrutura de como as partes do projeto se agrupam.

Os modelos mais comumente usados para representar tais propriedades

são: os desenhos, que representam melhor a forma dos componentes ou peças

do projeto; e os diagramas, que melhor representam a estrutura do projeto.

Essas duas formas de representação são melhor descritas, e exemplificadas na

seção que segue.

22..22.. AA RREEPPRREESSEENNTTAAÇÇÃÃOO DDEE DDEESSEENNHHOOSS EE DDIIAAGGRRAAMMAASS

A representação de desenhos � no papel, ou no computador � é

formalmente conhecida como geometria descritiva. Ela é uma técnica que

representa o objeto através de desenhos técnicos, a partir da imagem do objeto

no espaço tridimensional para o espaço bidimensional.

Essa forma de descrição geométrica que remonta a antigüidade, foi

formalizada pelo engenheiro militar francês Gaspard Monge (1746-1818), e

atualmente ainda é empregada. Ela consiste em mapear para o espaço

bidimensional, todos os pontos do objeto tridimensional. Para tanto, diferentes

planos de projeção mutuamente ortogonais, são utilizados para mostrar vários

ângulos ou vistas do objeto, quando visualizados de um ponto situado no

infinito. Na Figura 1, conforme a norma americana, tem-se uma representação

de desenho num sistema de ângulo de projeção do terceiro quadrante. Aqui no

Brasil, a ABNT (Associação Brasileira de Normas Técnicas) recomenda o

sistema de ângulo de projeção no primeiro quadrante.

Através de um esquema formal da disposição dos diferentes planos de

projeção das principais vistas do objeto, pode-se identificar os seus vértices,

dos quais permitem obter as arestas, e estas permitem obter as faces que

envolvem o objeto, e assim reconstruí-lo.

Os desenhos de engenharia são formais e seguem padrões de escritórios

de normalização e padronização nacionais e internacionais. Tais normas

tratam basicamente sobre diferença de estilos de linhas (do contorno visível ou

invisível do objeto), vistas auxiliares para realçar detalhes, planos de corte,


tipos de projeção (isométrica, perspectiva ou cônica, cavaleira), relacionamento

entre o posicionamento das vistas no desenho (primeiro ou terceiro ângulo de

projeção), formas de cotagem e representação das dimensões e tolerâncias, etc..

Essas regras formais dos desenhos técnicos podem ser pesquisadas nas

normas específicas sobre o assunto, ou em diversas bibliografias, tais como

(JENSEN et al., 1989) e (BERTOLINE et al., 1997).

Figura 1. Vistas principais de um objeto (MCMAHON e BROWNE, 1998).

Na Engenharia, também são utilizados diagramas para representar a

lógica ou a estrutura física de sistemas, tais como: circuitos eletro-eletrônicos,

hidro-pneumáticos, sistemas de distribuição de água e esgoto, etc..

A representação é feita por convenções de símbolos, os quais podem ser

ligados por conexões, para evidenciar o relacionamento e componentes que

estão presentes, como mostra a Figura 2. Assim como nos desenhos, as regras

para padronização desses símbolos também são ditadas por escritórios de

normalização e padronização nacionais e internacionais.

É importante enfatizar o papel fundamental que os desenhos e diagramas

assumem no processo de projeto. De acordo com (ULLMAN et al., 1990), a

partir de experimentos realizados com uma equipe de engenheiros, ele

observou diferentes aplicações do desenho no processo de projeto:


• São usados para arquivar a forma do projeto;

• Para comunicar idéias entre projetistas, engenheiros, e todos os outros

envolvidos com o projeto;

• Servem como uma ferramenta de análise;

• Freqüentemente, dimensões e tolerâncias são calculadas sobre o

desenho, quando o mesmo está sendo desenvolvido.

• Servem para simular o projeto;

• Servem como um elemento para planejar tarefas;

• Atuam como uma extensão da memória do projetista. Servem como

meio de documentar e registrar idéias e detalhes que facilmente podem

ser esquecidos.

Figura 2. Simbologia usada em diagramas (MCMAHON e BROWNE, 1998).

Tem-se constatado também que, os desenhos e diagramas podem ser

utilizados para decompor o problema, e capturar diferentes visões dos estágios

do processo de projeto. O aspecto de facilitar a abordagem de problema é

conseguido através da técnica conhecida como �Divida e Conquiste� (Divide &

Conquer), a qual faz uma subdivisão do problema em partes menores. E através

de uma hierarquia de níveis de abstração; sendo que em cada nível tem-se um

refinamento do problema até alcançar o nível dos componentes básicos ou

elementares; faz-se a análise do problema. Esse aspecto de visualização do

problema, caracteriza a filosofia de projeto conhecida como Top-Down.

Este tipo de filosofia de projeto fica evidente devido uma característica

própria da representação diagramática. Num determinado nível de abstração,

Bomba decombustível

SensorLambda

Anemômetro

Sensor detemperatura

Sensor detemperatura

Unidade decontrole

Filtro decombustível

Injetor

Injetor

Injetor

Injetor

Regulador depressão docombustível

Par

a os

cili

ndro

s

Combustíveldo tanque

Exaustor deoxigênio

Entrada do fluxode massa

Temperaturado ar

Temperaturado bloco


ela permite que alguns símbolos representem estruturas mais complexas, as

quais só serão detalhadas a posteriori (Ver Figura 3).

Figura 3. Níveis de abstração em diagramas (MCMAHON e BROWNE, 1998).

22..33.. RREEPPRREESSEENNTTAAÇÇÃÃOO TTRRIIDDIIMMEENNSSIIOONNAALL

A representação de desenhos e diagramas utilizando o sistema de

projeções no plano exige habilidades de construção, leitura e interpretação dos

usuários. A difícil construção de certos objetos complexos impossibilita a

representação por desenhos, ou exige a construção de muitos desenhos de

detalhes. A má leitura ou a interpretação diferenciada do desenho conduz à

uma probabilidade maior de ocorrerem modelos conflitantes ou apresentarem

erros diversos. Essas limitações da representação imposta pelo sistema de

projeções no plano, conduziram à necessidade de criar novos modelos de

representação, baseados numa visualização tridimensional e mais realista dos

objetos.

Os métodos desenvolvidos para modelagem tridimensional englobam a

representação da geometria como uma coleção de linhas, curvas, superfícies,

ou sólidos no espaço tridimensional.

Os modelos tridimensionais, estão referenciados por dois sistemas de

coordenadas, que são convencionalmente orientados segundo a regra da mão

direita, dada pelo eixo x orientado no sentido do dedo polegar, eixo y orientado


no sentido do dedo indicador, e eixo z orientado no sentido do dedo mediano

normal à palma da mão. A Tabela 1 mostra as características, funcionalidades

e a aplicabilidade desses dois sistemas.

Tabela 1. Eixos de coordenadas para modelos tridimensionais.

SISTEMA DE COORDENADAS CARACTERÍSTICAS FUNÇÃO E APLICAÇÃO

Global ou principal Fixo e �absoluto� Armazenar os dados geométricos das entidades

Local ou de trabalho Móvel e relativo Facilitar a construção dos elementos ou entidades

geométricas dispostos no espaço tridimensional

2.3.1. REPRESENTAÇÃO WIREFRAME Na representação estrutura de arame ou wireframe, os modelos

geométricos são definidos por uma série de linhas e curvas que representam as

arestas ou contornos físicos do objeto.

Conforme colocado por (ZEID, 1991) e (MCMAHON e BROWNE, 1998), a

representação wireframe é uma extensão da representação por projeções no

plano, adicionando-se para isso uma nova coordenada. Para trabalhar com

esses modelos, deve-se considerar a profundidade e plano de trabalho ao

desenho. Na construção dos modelos wireframe, o plano de trabalho

(geralmente o plano xy) indica o plano onde se está posicionando as entidades;

e a profundidade (geralmente o valor da coordenada z) indica o valor da

coordenada em que a entidade está.

Cada sistema CAD (Computer-Aided Design) possui os seus próprios

métodos e recursos de interface do usuário para definição da orientação de

planos de trabalho e dos sistemas de coordenadas de locais, de forma a

facilitar a construção das entidades no modelo. Geralmente, eles se baseiam

em entidades previamente desenhadas (pontos, retas, centros e vértices de

entidades planas, combinação dessas entidades, etc.) para posicionar o plano

de trabalho e orientar o sistema de coordenadas local.

(ZEID, 1991) e (MCMAHON e BROWNE, 1998), exemplificam alguns

métodos e representações utilizadas por modelos wireframe para definir os

sistemas de coordenadas locais e planos de trabalho, e também algumas

entidades geométricas básicas ou primitivas normalmente utilizadas.

Sobre as vantagens da representação wireframe, pode-se ressaltar:


• A simplicidade de construção. É uma representação que requer

poucos recursos computacionais de processamento e tempo de

execução quando comparado com outras técnicas de modelagem

tridimensional (superfície, sólidos). Por ser considerada uma extensão

natural das técnicas convencionais de representação por projeção de

vistas do objeto, pode-se dizer que esta representação serve como uma

migração e iniciação mais natural para as técnicas de modelagem

tridimensional, consideradas mais complexas.

• Associatividade dos pontos do objeto. A estrutura de dados permite

alguma associatividade e conectividade espacial da malha de pontos

que compõe o objeto, e a geração automática das vistas principais

através de operações de projeção numa transformação tridimensional.

• Modelos básicos. Eles servem de base para modelos mais

representativos, tais como os modelos de superfície, que às vezes

requerem entidades primitivas wireframe para gerar as superfícies.

• Facilitam a manipulação dinâmica de entidades. Eles são úteis para

manipulação dinâmica � por exemplo, a animação dos movimentos de

mecanismos � devido à sua estrutura de dados simplificada, que

também favorece a realização rápida de operações de manipulação,

edição, inserção, modificação, e deleção de elementos do modelo.

• Captação de idéias. Eles servem para capturar os rascunhos ou

esboços das primeiras idéias nos estágios iniciais do processo de

projeto.

Assim como qualquer proposta que se faça, os modelos de representação

wireframe, também possuem suas desvantagens. A principal delas reside na

interpretação visual dos objetos representados.

Nas figuras que seguem, são mostrados alguns exemplos sobre essas

desvantagens.

• São modelos ambíguos, ou mesmo sem um significado lógico (Ver

Figura 4);

• Desenhos complexos ou cheios de detalhes, como a visualização da

trajetória de ferramentas, ou de paisagens mostrando um conjunto de


edifícios, ficam demasiadamente cheios de linhas. Isso torna a

interpretação muito confusa, conforme pode ser visto na Figura 5.

• O perfil ou a silhueta dos objetos podem ficar, normalmente, sem uma

representação adequada ou realmente verdadeira, priorizando apenas

efeitos de aparência, conforme é evidenciado na Figura 6.

• A geração de estruturas de dados que permitam a reconstrução do

objeto representado, normalmente ficam muito grandes.

Figura 4. Interpretações de um modelo wireframe (SHAH e MÄNTYLÄ, 1995).

Figura 5. Visualização confusa (MCMAHON e BROWNE, 1998).

Figura 6. Linhas do contorno e da parede do furo (ZEID, 1991).


2.3.2. REPRESENTAÇÃO DE SUPERFÍCIE A representação e modelagem de curvas exercem um papel importante na

representação das entidades primitivas utilizadas em modelos wireframe e

modelos de superfície. Portanto, antes de entrar nos detalhes da representação

de superfícies, será abordado alguns conceitos e técnicas sobre modelagem de

curvas.

REPRESENTAÇÃO DE CURVAS Matematicamente, as curvas podem ter duas formas de representação: a

forma analítica, e a forma paramétrica.

A forma analítica de uma curva pode ser explícita (y = f(x)), ou implícita

(f(x, y) = 0), conforme exemplificado na Tabela 2:

Tabela 2. Exemplo de representação explícita e implícita de curvas.

CURVA EXPLÍCITA IMPLÍCITA Reta y = a.x + b a.x + b.y + c = 0

Circunferência (x � a)2 + (y � b)2 = r 2

Elipse x2/a2 + y2/b2 = 1

Parábola y = a.x2 + b

Hipérbole x2/a2 � y2/b2 = 1, ou x.y = k

Cônica a.x2 + b.y2 + 2f .xy + 2g.x + 2h.y + c = 0

Já na representação paramétrica, cada coordenada de ponto da curva

depende de uma variável adicional ou parâmetro u, e estão desacopladas ou

linearmente independentes.

Desta forma, a posição de um ponto qualquer no espaço tridimensional é

dada pela expressão p = p(u), e significa que as coordenadas cartesianas são

dadas por:

x = x(u), y = y(u), z = z(u) ; (2.1)

ou também numa forma matricial:

p(x, y, z) = p(x(u), y(u), z(u)) = p(u) = ��

�

�

��

�

�

(u)(u)(u)

zyx

, onde umin ≤ u ≤ umáx ; (2.2)


Os valores de cada coordenada x, y, e z são dados como função de um

parâmetro u, o qual pode variar num certo intervalo. Se o intervalo for

normalizado, o parâmetro pode variar de 0 a 1.

Embora a representação analítica de curvas possa ser utilizada em certos

casos, ela apresenta uma série de inconvenientes que a torna inadequada ou

limitada para utilização em sistemas gráficos.

Essas limitações são comentadas a seguir:

• A equação da curva, quando modelada por expressão analítica, é

dependente do sistemas de coordenadas escolhido como referência. A

influência do sistema de referência na forma analítica é expressa pela

necessidade de adicionar valores na equação original da curva.

A forma dos objetos é intrinsecamente independente do sistema de

coordenadas. O que determina a forma de um objeto é a relação entre os seus

pontos de dados, e não entre os pontos e o sistema de referência. Por exemplo,

uma circunferência é caracterizada pelos seus pontos eqüidistantes do centro.

• As expressões analíticas representam intervalos infinitos de valores

para as suas variáveis.

Isso dificulta a representação de retas, segmentos de elipse, ou arcos de

circunferência, os quais têm seus valores restritos num certo intervalo. Além

disso, a visualização gráfica das curvas fica impossibilitada dentro de um

domínio discreto de visualização, como a tela do computador. Por isso a

necessidade de limitar as equações analíticas através de restrições.

Outra dificuldade, de cunho computacional ou de programação, ocorre

quando se tem retas horizontais (de inclinação zero, ou muito próximo de zero),

e retas verticais (inclinação de 90º, ou quase vertical). A dificuldade é devido ao

fato de uma das coordenadas alcançar um valor �infinito� ou muito grande,

podendo extrapolar a capacidade de representação numérica do computador.

Além dessa, podem existir outras condições matemáticas mal definidas pela

representação analítica de curvas.

• Algumas curvas são fechadas e/ou multi-valoradas.

Para um determinado valor de uma variável, existem mais de um valor

possível para a outra variável. É o caso, por exemplo, das cônicas (parábola,

hipérbole, elipse, etc.).


• A forma analítica implícita é inconveniente para se obter pontos sobre a

curva.

Pode acontecer de um valor x qualquer escolhido, não esteja sobre a

curva, e portanto não se obtém uma solução para y.

• A forma analítica torna complicado a realização de transformações

geométricas (translação, rotação, escalonamento, reflexão, cisalhamento)

sobre a curva.

A dificuldade deve-se à necessidade de processar todos os pontos

pertencentes a curva durante a realização das transformações. Isso torna

muito custoso e demorado qualquer algoritmo computacional implementado

para realizar esta operação.

Neste ponto, cabe fazer duas observações importantes acerca do que foi

exposto no texto acima:

• As dificuldades de representação de curvas na forma analítica, que são

basicamente de cunho numérico e de visualização, podem ser

contornadas. Ou seja, elas não inviabilizam por completo a

representação. Apenas dificultam os cálculos e a exibição na tela,

exigindo um pouco mais de esforço para implementar apropriadamente

a operação desejada no sistema gráfico do sistema CAD.

• As limitações impostas pela representação de curvas na forma analítica

ficam mais evidentes, claras e compreendidas, à medida que você

adquire conhecimento sobre as técnicas de representação de curvas. O

conhecimento aliado à experiência permite fazer comparações,

inferências e conclusões acerca de vantagens e desvantagens do uso de

uma ou outra técnica de modelagem. Portanto, alguns tópicos que por

ventura tenham ficado mal entendidos, ou sem uma real visualização

das limitações, aos poucos serão resolvidos com a aquisição de mais

conhecimento e experiência de implementação.

É comum a necessidade de modelar curvas suaves, tais como a seção

transversal da asa de um avião, de um aerofólio de carro, um perfil da

carroceria de um carro esportivo, ou mesmo curvas geradas na interseção


entre sólidos e/ou superfícies, normalmente são difíceis de serem tratadas com

entidades geométricas convencionais.

Portanto, urge definir uma representação que contorne as limitações da

forma analítica, e também permita a modelagem de formas suaves. Para tanto,

a solução adotada na modelagem de curvas em sistemas gráficos e programas

CAD é descrever as entidades geométricas usando uma forma de representação

paramétrica, com interpolação e ajuste de pontos em entidades compostas por

vários segmentos discretos. A forma paramétrica também traz o benefício de

permitir um tratamento vetorial das equações de curvas mais usuais,

possibilitando uma base e notação consistentes para a modelagem unificada de

curvas bidimensionais e tridimensionais, além de uma representação concisa e

de fácil manipulação pelos algoritmos computacionais.

As formas mas comuns de modelagem paramétrica de curvas sintéticas ou

de forma-livre (free-form curves) são obtidas por técnicas de interpolação ou

aproximação dos seus pontos de dados. As pesquisas em representação e

modelagem de curvas originaram diversas técnicas para geração de curvas de

formas livre: curvas cúbicas de Hermite, curvas de Bézier e B-spline. Tais

técnicas foram sendo aprimoradas, e evoluíram até chegarem às curvas

conhecidas como NURBS (Non-Uniform Rational B-Spline), e cuja teoria pode

ser estendida e generalizada também para representação de superfícies, além

de unificar a representação das curvas de forma livre e as curvas analíticas

(círculos, arcos, cilindros, cones, planos, etc.) numa mesma base de coordenadas

homogêneas.

Para mais detalhes e aprofundamentos na modelagem de curvas,

recomenda-se consulta na extensa bibliografia que trata sobre o assunto, tais

como: (FARIN, 1997) e (ROGERS e ADAMS, 1990).

Os modelos de superfície são uma representação muito mais completa e

menos ambígua que os modelos wireframe. A informação geométrica entre as

entidades é muito mais relacionada e rica, tornando-os mais adequados para

aplicações de projeto e fabricação. Os modelos de superfície conduzem à

modelagem de objetos um passo adiante da modelagem wireframe, pois eles

fornecem a conectividade entre as arestas.


Conforme já observado na seção anterior, geralmente os modelos de

superfície são obtidos com base em entidades primitivas representadas por

modelos wireframe. Isto é, os modelos de superfície são uma extensão dos

modelos wireframe. A estrutura de dados de um modelo de superfície é

centralizada e associada. Isto significa que quaisquer alterações numa vista,

reflete diretamente nas demais.

Os modelos de superfície possibilitam uma visualização menos ambígua. A

conectividade entre as arestas do objeto, permite a implementação de

algoritmos para escondimento de linhas, e sombreamento. Eles também podem

ser utilizados para cálculo de propriedades físicas do objeto (massa, volume,

modelagem de análise por elementos finitos, geração de trajetórias de

ferramentas, seccionamento em camadas, detecção de interferências, etc.).

Os modelos de superfície podem ser agrupados em três tipos:

• Superfícies geradas a partir de matrizes de pontos de controle, onde a

superfície é obtida por técnicas de interpolação/aproximação (Ver

Figura 7).

Figura 7. Superfície a partir de pontos (MCMAHON e BROWNE, 1998).

• Superfícies geradas a partir de outras curvas, semelhante a uma capa

que reveste uma estrutura de arame (wireframe) (Ver Figura 8).

• Superfícies geradas a partir de interpolações entre duas ou mais outras

superfícies, tais como arredondamentos de canto e chanfros (Ver

Figura 9)).


Figura 8. Superfície a partir de outras curvas (MCMAHON e BROWNE, 1998).

Figura 9. Superfície a partir de outras superfícies (MCMAHON e BROWNE, 1998).

Os modelos de superfície exigem um pouco mais de conhecimento por

parte do usuário, e as operações realizadas também requerem mais recursos

computacionais e tempo de processamento comparados aos modelos

wireframe.

Assim como os modelos wireframe, os modelos de superfície também são

às vezes ambíguos ou podem levar a uma interpretação errônea do objeto

representado. Eles também sofrem de certas dificuldades para representar


superfícies complexas, tais como as geradas por interseção entre outras

superfícies � um exemplo clássico, são as superfícies de um arredondamento

de canto ou quina de um objeto, ou ajustes de superfícies de raios diferentes.

Tem-se também as superfícies limitadas ou recortadas por curvas; estas

superfícies são conhecidas como three/four/five-sided patches (Ver Figura 10).

Figura 10. Superfícies three/four/five-sided (MCMAHON e BROWNE, 1998).

A representação de superfícies complexas não é uma tarefa trivial.

Existem diversos sistemas CAD comerciais, especialmente desenvolvidos para

modelagem de superfícies.

Abaixo, listam-se alguns desses programas:

• ICEM Technologies Inc., subsidiária da Parametric Technology Corp.,

fornece ICEM Surf, um modelador de superfície largamente usado na

indústria automotiva.

• MultiSurf captura o relacionamento entre elementos geométricos para

facilitar a atualizações e alterações. A empresa também desenvolve o

SurfaceWorks.

• A Alias|Wavefront oferece o SurfaceStudio, seu novo programa para

superfícies. O pacote permite uma integração sem perdas de

informação com modeladores sólidos populares.

• A Imageware, agora administrada pela SDRC, fornece o Surfacer e o

Surface Wizard para criação e edição de curvas complexas, nuvens ou

malhas de pontos de controle, e aplicações de engenharia reversa.


2.3.3. REPRESENTAÇÃO DE SÓLIDO Dentre as representações estudadas até aqui, os modelos sólidos são os

que possuem a representação mais completa dos objetos. Na representação dos

objetos, eles consideram a geometria e a topologia; diferentemente dos modelos

wireframe e de superfície que consideram somente a geometria. Pelo fato de

possuírem uma representação mais completa e não ambígua, os modelos

sólidos podem ser gerados de maneira mais automatizada. Isso liberta o

usuário de ter que verificar visualmente e interativamente a validade do objeto.

A formalização matemática da teoria de modelagem sólida já está bem

estabelecida por diversos autores. (ZEID, 1991) destaca a contribuição de

Requicha e Voelcker para este fato. Ele adverte que o sucesso da representação

de um modelo sólido em computadores e a sua utilização na engenharia

depende das propriedades matemáticas do modelo e dos esquemas utilizados

para representá-los. Abaixo, são listadas essas propriedades.

As propriedades matemáticas importantes de um modelo sólido são:

• Rigidez: Isto implica que a forma de um modelo sólido é invariante, e

não depende da localização ou orientação do modelo no espaço.

• Homogeneidade tridimensional: as superfícies do sólido devem estar

em contato com o seu interior. Não é permitida a existência de arestas

ou faces isoladas.

• Tamanho finito (Finitude) e descrição/representação finita: o sólido

deve possuir um tamanho finito, o que caracteriza a propriedade de

finitude. A descrição finita refere-se ao fato do sólido poder ser

representado no espaço de armazenamento limitado dos computadores.

• Integridade: esta propriedade garante que a manipulação de sólidos

através de movimentos rígidos no espaço, ou alterações por meio de

operações booleanas regularizadas, resultam em outros sólidos válidos.

• Determinismo do contorno: o contorno de um sólido deve contê-lo, e

deve determinar distintamente o interior do sólido.

O esquema de representação é definido como a relação que mapeia um

conjunto de pontos válidos num modelo também válido.


A utilidade de um esquema de representação é função das suas

propriedades, as quais são listadas a seguir:

• Domínio ou cobertura geométrica: o domínio de um esquema de

representação refere-se à diversidade de objetos que ele pode

representar.

• Validade: a validade de um esquema de representação é determinada

pelo seu conjunto válido de representações que ele pode produzir. Se

um esquema produz um modelo inválido, o sistema CAD/CAM

(Computer-Aided Manufacturing) pode abortar ou o banco de dados

pode ser corrompido por um algoritmo que o manipule. Os testes de

validade podem ser de três formas: teste do banco de dados resultante,

teste de verificação dentro do próprio esquema de geração do sólido, ou

por definição de padrões esquemáticos de elementos básicos

(primitivas), que podem ser manipulados através de uma sintaxe.

• Completitude ou não ambigüidade: a completitude ou não

ambigüidade de um esquema determina que para toda representação

válida, existe apenas um sólido; ou seja, o esquema não deve ser dúbio.

• Unicidade: propriedade do sólido possuir somente uma representação

possível.

ESQUEMAS DE MODELAGEM DE SÓLIDOS Embora muitos esquemas de representação tenham sido propostos,

poucos realmente se popularizaram e foram aplicados nos sistemas CAD.

Pela classificação segundo (MÄNTYLÄ, 1988), os esquemas ou modelos de

representação dos sólidos podem ser agrupados em três tipos:

• Modelos de decomposição: representam um conjunto de pontos como

uma coleção de objetos simples, baseados numa coleção fixa de tipos

distintos de objetos, combinados através de uma simples operação de

colagem. A instanciação de primitivas pode ser considerada um caso

especial deste modelo.

• Modelos construtivos: representam um conjunto de pontos formados

a partir de uma combinação de conjunto de pontos primitivos. Cada

uma das primitivas é representada como uma instância de um tipo


sólido primitivo. Os modelos construtivos incluem operações de

construção mais gerais, além da operação de colagem. A teoria desses

modelos é baseada na formulação de solidez de conjunto de pontos,

que está descrita em (MÄNTYLÄ, 1988).

• Modelos de contorno: representam um conjunto de pontos em termos

de seu contorno. O contorno de um conjunto de pontos sólidos

tridimensionais é uma superfície bidimensional que é normalmente

representada como uma coleção de faces. As faces, por sua vez, são

representadas em termos de suas arestas ou limites através de uma

curva unidimensional. Portanto, os modelos de contorno podem ser

visualizados como um modelo hierárquico. Os modelos de superfície

são baseados na formulação de superfície orientada, também descrita

em (MÄNTYLÄ, 1988).

Dentre os modelos mais utilizados nos sistemas CAD, pode-se citar os

modelos CSG (Constructive Solid Geometric), um exemplo de modelo

construtivo; os modelos B-Rep (Boundary Representation), um exemplo de

modelo de contorno; ou uma combinação desses formando modelos híbridos.

Estes modelos estão brevemente comentados no texto que segue.

MODELOS CSG O modelo CSG é baseado na idéia de que os objetos físicos são

constituídos por um conjunto de primitivas (que são elementos ou formas

geométricas básicas), as quais são combinadas para formar os objetos através

de operações booleanas (união, interseção, diferença) e transformações

geométricas (rotação, translação, escalamento).

A Figura 11 exemplifica alguns tipos de primitivas mais comumente

encontradas em sistemas CAD, e as operações booleanas definidas, utilizando

um bloco e um cilindro.

Os modelos CSG são normalmente representados por estruturas de dados

em árvore binária. Nesta estrutura, as primitivas correspondem às folhas e os

nodos interiores correspondem às operações booleanas ou transformações

geométricas (Ver Figura 12).


Os modelos CSG têm a vantagem de serem compactos e não ambíguos, e

sempre geram sólidos válidos. Eles também permitem um nível de interface

superior e de conceitos menos abstratos que os modelos de semi-espaços não

limitados (SHAH e MÄNTYLÄ, 1995).

Figura 11. Primitivas e operações booleanas (MCMAHON e BROWNE, 1998).

Figura 12. Estrutura de dados em árvore CSG (Baseado em MÄNTYLÄ, 1988).

Como desvantagem, eles apresentam um domínio limitado pela

diversidade da biblioteca de primitivas. Uma questão importante de ser

ressaltada é o fato da estrutura de dados não armazenar arestas e superfícies

CUBO CILINDRO

CUNHA TORUS

diferença

cilindrounião

bloco2bloco1


resultantes das operações entre primitivas. Estas operações precisam ser

calculadas em tempo de execução, tornando mais lento os algoritmos de

exibição. Tais modelos não são únicos, ou seja, na representação de alguns

sólidos, pode existir mais de uma árvore CSG possível e correta.

MODELOS B-REP Os modelos B-Rep representam um objeto sólido dividindo-o em faces

convenientemente relacionadas, compostas por superfícies fechadas e

orientadas, e que possuam uma representação matemática computacional

compacta (normalmente são superfícies planas, quadráticas, toroidais, ou

paramétricas). Em seguida à fragmentação do objeto em faces, estas são

quebradas em curvas que representam as arestas de cada face constituinte do

objeto. As arestas, por sua vez são quebradas em vértices.

A estrutura de dados dos modelos de superfície segue uma organização

hierárquica, formada por faces, arestas, ciclos, e vértices; de acordo com a

Figura 13. Esta estrutura de dados considera a geometria, como também a

topologia dos dados do objeto.

Figura 13. Estrutura de dados para modelos B-Rep.

As operações de criação, manipulação e edição de faces, arestas e vértices

é realizada através de operadores de Euler. Esses operadores realizam

operações booleanas em primitivas CSG, o que se constitui numa maneira de

v6

v3

v4

v2

e9

v5

v8

v7

v1

e10

e7

e2

e6

e8

e5

e12

e11

e4

e1

e3

f6

Vértices Facesv1 x1 y1 z1 f1 v1 v2 v3 v4

v2 x2 y2 z2 f2 v6 v2 v1 v5

v3 x3 y3 z3 f3 v7 v3 v2 v6

v4 x4 y4 z4 f4 v8 v4 v3 v7

v5 x5 y5 z5 f5 v5 v1 v4 v8

v6 x6 y6 z6 f6 v8 v7 v6 v5

v7 x7 y7 z7f3

f2


checar a validade de modelos B-Rep. Mais detalhes sobre os operadores de

Euler podem ser obtidos em (MÄNTYLÄ, 1988) e (ZEID, 1991).

Uma estrutura de dados bastante conhecida para representação de

sólidos B-Rep é a asa de aresta (winged-edge data structure). O nome deve-se

ao fato do esquema dessa estrutura assemelhar-se ao de um par de asas,

conforme mostra a Figura 14.

Figura 14. Esquema da estrutura de dados asa de aresta.

A estrutura asa de aresta se baseia no fato de que toda aresta do objeto

tem exatamente duas arestas adjacentes-anteriores e duas arestas adjacentes-

posteriores, que correspondem as suas asas. Além disso, devido à consistente

orientação das faces, uma aresta é percorrida exatamente uma só vez em cada

orientação positiva e negativa da face. Com base nesta informação adicional de

vizinhança, cada face precisa armazenar apenas uma das suas arestas, pois o

resto do ciclo pode ser traçado seguindo o ciclo da asa. Isso torna mais

compacta a estrutura de dados de modelos B-Rep.

Ao contrário dos modelos CSG, os modelos B-Rep armazenam informação

sobre faces e arestas dentro da estrutura de dados, isso torna a estrutura

muito mais adequada na recuperação de dados para outras aplicações, tais

como a visualização do modelo ou o cálculo de área superficial. Uma

desvantagem do modelo é a maior quantidade de dados quando comparado a

outras técnicas de modelagem de sólidos (MCMAHON e BROWNE, 1998).

vértice finalvértice inicial

próxima face(sentido horário)

próximovértice

(sentidohorário)

vérticeanterior(sentidohorário)

aresta

próximovértice

(sentido anti-horário)

vérticeanterior

(sentido anti-horário)

próxima face(sentido anti-horário)


PPaaddrrõõeess ddee TTrrooccaa ddee DDaaddooss eemm CCAADD//CCAAMM


Cada vez mais, os bancos de dados computacionais estão substituindo as

folhas de desenho impressas como meio de armazenar dados geométricos ou

não geométricos, em todas as fases do projeto do produto e da fabricação.

Disso, surge a necessidade de trocar e/ou compartilhar eficientemente dados

ou informações entre diferentes sistemas.

Entretanto, ainda hoje, permanecem algumas incompatibilidades entre

definições de entidades geométricas ou estruturas de dados utilizadas pelos

diversos sistemas CAD/CAM. Os principais fatores que contribuem para essas

incompatibilidades, são citados por (DIAS, 1998):

• A complexidade da arquitetura computacional dos sistemas CAD/CAM;

• As várias necessidades de utilização e aplicação pelas indústrias;

• As restrições de acesso a bancos de dados particulares;

• O ritmo acelerado das mudanças tecnológicas.

CAP. 3 � PADRÕES DE TROCA DE DADOS EM CAD/CAM 25

A troca de dados entre diferentes usuários de uma mesma informação

torna-se fácil e direta quando todos utilizam os mesmos programas aplicativos

e rodam as mesmas versões. Todavia, há de convir que esta é uma situação

muito restritiva para os usuários de sistemas CAD/CAM, ou de outros

sistemas CAX�s (Computer-Aided �X�), que necessitam trocar ou compartilhar

dados e informações armazenados em formatos de arquivos ou base de dados

computacionais.

Uma troca de dados ideal deve abranger a descrição completa do produto

em seu banco de dados. Os principais tipos de dados ou informações que

formam essa descrição são: dados geométricos (forma), dados não geométricos

em geral, dados de projeto, dados de fabricação, e dados adicionais das

atividades subseqüentes do ciclo de vida do produto (Ver Tabela 3).

Tabela 3. Tipos de dados trocados ou compartilhados.

TIPO DE DADO OU

INFORMAÇÃO EXEMPLOS

Geométrico (forma)

Valores das coordenadas de um ponto (geometria); Número de furos e

disposição (topologia)

Não geométrico

Informações sobre a imagem (sombreamento, unidades de medida, resolução,

etc.) Atributos ou parâmetros considerados como parte da informação

geométrica (fonte, cor, nível ou camada, anotações de texto, etc.)

Features Furo, flange, seção transversal de perfis (alma), cavidade, protusão, chanfro,

arredondamento, etc.

Dados de projeto

A informação passada pelo projetista para propósitos de análise (material,

propriedades de massa, volume, malhas de elementos finitos, etc.)

Dados de fabricação

Tipos e trajetórias de ferramentas, tolerâncias, planejamento do processo,

lista de materiais, etc.

Existem arquiteturas computacionais distintas para realizar a troca e o

compartilhamento de dados e informações. A tradução de dados significa que

dados de entrada ou saída locais de uma aplicação específica, são

interpretados direta ou explicitamente para um outro formato de dados

específico; ou ainda para um formato de arquivo neutro. Por sua vez, o

compartilhamento de dados significa que todas as aplicações podem acessar

um banco de dados neutro através de algum tipo de interface de acesso de


dados, e deste então gerar os dados locais específicos para a aplicação

desejada. A Figura 15 ilustra os dois tipos de arquiteturas computacionais

descritos acima.

Figura 15. Arquiteturas computacionais de troca e compartilhamento de dados (Baseado em LIANG et al., 1999).

Na seção seguinte, faz-se um histórico das soluções usadas para efetivar a

troca de dados e informações entre sistemas de CAD/CAM.

33..22.. EEVVOOLLUUÇÇÃÃOO DDAA TTRROOCCAA DDEE DDAADDOOSS EEMM CCAADD//CCAAMM

Inicialmente, as alternativas de solução eram baseadas em programas

tradutores que realizavam uma tradução de arquivos através de algoritmos

específicos para cada formato. Estes programas convertiam os dados

geométricos de um aplicativo específico para um formato de arquivo aceitável

pelo outro aplicativo. O inconveniente dessa solução é que cada aplicativo

existente precisa de (N�1) algoritmos tradutores � onde N é o número de

programas aplicativos existentes � para converter os dados em formatos de

arquivos de outros aplicativos.

Banco de Dadoscomum

compartilhado

Dados doproduto

Dados doproduto

AplicaçãoA

Interface paraAcesso de Dados

AplicaçãoB

Interface paraAcesso de Dados

Arquitetura de compartilhamento de dados

Dados emformatoneutro

AplicaçãoA

Pós-processador

Dados doproduto

Dados doproduto

AplicaçãoB

Pré-processador

Arquitetura de tradução de dados


Dessa dificuldade, surgiram os formatos de arquivos neutros ou formatos

de dados em arquivo, tais como IGES (Initial Graphics Exchange Specification),

como forma de reduzir o número de algoritmos tradutores. A aplicação de

formatos de arquivos neutros, limita para dois o número de algoritmos

tradutores necessários na troca de dados � um que escreve/salva no formato

genérico, e outro que lê nesse formato. Nesta solução, a tradução é realizada

primeiro para um formato de arquivo genérico, e depois para o formato de

arquivo do aplicativo final. Inicialmente, as traduções ficaram concentradas

somente entre sistemas CAD. Em seguida, foi necessário também atender as

traduções entre sistemas CAD e CAM, estendo as capacidades do formato de

arquivo neutro.

Uma comparação entre essas duas formas de troca de dados � tradução

direta, e tradução por arquivo neutro � mostra que a tradução direta tende a

ser mais fácil de implementar, todavia é mais custosa para manter. Por

exemplo, uma nova versão de um programa CAD, exige que todos os tradutores

relacionados com ele tenham que ser atualizados também. Já os arquivos

neutros, exigem muito mais tempo para desenvolver, e correm o risco de serem

ambíguos ou não considerar certas características de alguns programas

existentes.

Mesmo assim, o arquivo neutro é o método mais adequado, e que conduz

a uma possível padronização muito mais facilmente. A Tabela 4 resume as

principais questões relacionadas com a aplicação dos dois tipos de solução.

Tabela 4. Tradução direta versus arquivo neutro na troca de dados.

CRITÉRIO DE COMPARAÇÃO TRADUÇÃO DIRETA ARQUIVO NEUTRO Direito de uso do formato Arquivo privado Domínio público

Número de tradutores ��

��

�⋅

22

N = N⋅⋅⋅⋅(N�1) 2⋅⋅⋅⋅N

Número de traduções Apenas uma tradução Duas traduções

Atualização do sistema Todos os tradutores relacionados

devem ser atualizados

Um tradutor de leitura e um

de escrita deve ser

implementado

Custo Mais custosa de manter

OBS.: onde )!2(!2

!2 −⋅

=��

��

�

NNN


A Figura 16 esquematiza como se processa a troca de dados entre

diferentes sistemas CAD/CAM, utilizando as formas de tradução comentadas.

Figura 16. Formas de tradução de arquivos.

Com os avanços da tecnologia de CAD e sua ampla aplicação no meio

industrial, alguns programas comerciais de CAD se tornaram bastante

utilizados. A grande utilização de arquivos oriundos de tais programas, fez com

que surgissem os chamados �padrões de facto�. Um �padrão de facto� é um

formato de arquivo de dados geométricos que se popularizou, e atingiu um

número tão considerável de usuários, que o fez tornar-se um padrão não

oficial, mas de fato. O exemplo mais clássico disso, é o formato de arquivo DXF

(Drawing Interchange File) criado pela Autodesk. Diversos desenvolvedores de

programas CAD/CAM/CAE (Computer-Aided Engineering), além de gerarem

arquivos num formato próprio, adicionaram também saídas em formato DXF,

como forma até de aceitação dos seus produtos pelo mercado.

Outra solução, que teve origens no meio comercial e acabou sendo

utilizada como forma de trocar dados geométricos entre sistemas CAD, foram

os chamados núcleos (kernels) de modelagem geométrica de sólidos. Diversos

programas de CAD adotam e embutem essas bibliotecas de funções de

modelagem sólida na sua arquitetura computacional, para geração de sólidos a

partir de operações típicas de modelagem sólida. A grande adoção de certas

bibliotecas, por parte dos desenvolvedores de programas CAD, fez com que elas

A

E

B

D

C A

E

B

D

C

ArquivoNeutro

Tradução direta Formato de arquivo neutro

Troca de dados entresistemas CAD/CAM


tornassem um meio de trocar dados entre diferentes sistemas CAD. Alguns

exemplos dessa tecnologia serão brevemente descritos neste capítulo.

As soluções comerciais, embora adotadas pelo mercado, não podem ser

consideradas como oficiais e aceitas de consenso pela comunidade mundial.

Essa comunidade é formada por centros de pesquisa, escritórios de

normalização e padronização nacionais e internacionais, indústrias de

tecnologia (aeronáutica, automobilística), grandes desenvolvedores de

programas, órgãos militares, e outros que influenciam. Os interesses desses

grupos são diversos e a luta de poder também faz parte das decisões. O passo

seguinte então, foi empenhar-se em desenvolver padrões de formatos de

arquivos para troca de dados geométricos e não geométricos entre sistemas de

CAD. Exemplos desse tipo serão mencionados também neste capítulo.

33..33.. TTIIPPOOSS DDEE PPAADDRRÕÕEESS PPAARRAA TTRROOCCAA DDEE DDAADDOOSS

3.3.1. IGES (INITIAL GRAPHICS EXCHANGE SPECIFICATION) O IGES é uma proposta de especificação e sintaxe de formato de arquivo

neutro. O modelo do arquivo IGES é baseado na definição de entidade, a qual é

a fonte de informação básica. As entidades suportadas pelo IGES são de três

tipos: entidades geométricas, entidades de anotação, e entidades de estrutura.

Elas são resumidas na Tabela 5.

Tabela 5. Entidades suportadas pelo IGES (MCMAHON e BROWNE, 1998).

NÚMERO ID NOME ENTIDADES GEOMÉTRICAS

100 Arco circular 102 Curva composta 104 Arco cônico 106 Dado para cópia 108 Plano 110 Linha 112 Curva spline paramétrica 114 Superfície spline paramétrica 116 Ponto 118 Superfície "ruled" 120 Superfície de revolução 122 Cilindro tabulado 124 Matriz de transformação


125 "Flash" 126 Curva racional b-spline 128 Superfície racional b-spline 130 Curva "offset" 132 Ponto de conexão 134 Nodo 136 Elemento finito 138 Deslocamento nodal e rotação 140 Superfície "offset" 142 Curva sobre uma superfície paramétrica 144 Superfície paramétrica "trimmed"

ENTIDADES DE ANOTAÇÃO 202 Dimensão angular 206 Diâmetro angular 208 Nota sinalizada 210 Rótulo geral 212 Nota geral 214 "Leader" (seta) 216 Dimensão linear 218 Dimensão ordinária 220 Dimensão pontual 222 Dimensão radial 228 Símbolo geral 230 Área seccionada

ENTIDADES DE ESTRUTURAS 302 Definição de associatividade 304 Definição da fonte da linha 306 Definição de macro 308 Definição de sub-figura 310 Definição da fonte do texto 312 Modelo de exibição do texto 314 Definição de cor 320 Definição da sub-figura da rede 402 Instância de associatividade 406 Propriedade 408 Instância de sub-figura simples 410 Vista 412 Instância de sub-figura de array retangular 414 Instância de sub-figura de array circular 416 Referência externa 418 Carga/restrição de nodo 420 Instância de sub-figura de rede 600 - 699 Instância de macro para desenvolvedores

Todos os dados de definição do produto são expressos como uma lista de

entidades predefinidas. Cada entidade possui dois tipos de dados principais:

• Dado de diretório: é número da entidade, pelo qual ela é referida no

arquivo IGES;

• Dado de parâmetro: dados requeridos para definir a entidade de forma

única e completa.


FORMATO DO ARQUIVO IGES O arquivo IGES segue um formato de 80 caracteres por linha, chamado de

registro. Cada registro possui um identificador entre as colunas 73-80, é

limitado por ponto-e-vírgula, e subdividido em campos por vírgulas. O primeiro

caracter do identificador de cada linha indica a seção do arquivo. Os demais

números, indicam a numeração das linhas que compõem a respectiva seção.

Estes números são utilizados pelo IGES como ponteiros para referenciar as

seções.

Ao todo, cinco seções compõem um arquivo de formato IGES. São elas:

• Seção Inicial (S): contém informações gerais que podem auxiliar o

usuário com a operação de geração do arquivo IGES.

• Seção Global (G): contém 24 campos, onde são informados parâmetros

necessários à geração, identificação e configuração do arquivo IGES.

• Seção Diretório (D): é gerada pelo pré-processador IGES e constitui-se

de códigos que representam os tipos e sub-tipos de entidades dispostas

em duas linhas de oito caracteres cada.

• Seção Dados de Parâmetro (P): constitui-se de dados específicos para

cada entidade listada na seção anterior. Tais dados são: valores das

coordenadas de pontos, texto de anotação, número de pontos de dados

em spline, etc.

• Seção Finalização (T): marca o final do arquivo de dados, e contém o

subtotal de registros verificados na transmissão de dados.

Figura 17. Exemplo de desenho de algumas entidades geométricas simples.

Ponto emx = 100y = -100

R 50

Linha 100 mm, a 45o


Na Figura 18, tem-se um exemplo de arquivo IGES gerado pelo

processador MicroStation IGES, da Bentley. Este mesmo arquivo IGES, obtido

do desenho mostrado na Figura 17, pode também ser visto no APÊNDICE A.

Figura 18. Exemplo de arquivo IGES.

Pode-se observar na margem direita, a inicial de cada uma das seções que

compõem o arquivo. Na seção de dados, observa-se a definição das entidades

geométricas presentes no desenho da Figura 17: o arco circular (100), a linha

(110), e o ponto (116).

3.3.2. DXF (DATA INTERCHANGE FORMAT) É o formato de dados disponibilizado pela Autodesk, empresa que

desenvolve o programa de CAD chamado de AutoCAD. O padrão DXF é

considerado um �padrão de facto�, devido a grande utilização do sistema

AutoCAD pela comunidade industrial e científica.

O DXF é muito mais uma linguagem ou um meta-arquivo gráfico

(exemplos de metafile graphics1: CGM � Computer Graphics Metafile, CGI �

Computer Graphics Interface) do que um simples formato de imagem (exemplos

de bitmap: GIF � Graphics Interchange Format, TIFF � Tagged Image File

Format). Assim como num formato de imagem, a exata localização ou a ordem

em que os dados gráficos aparecem no arquivo não é importante. Entretanto,

1 Um graphics metafile é um arquivo formatado contendo dados e comandos gráficos. Eles são independentes do equipamento de exibição; ou seja, podem ser exibidos em diferentes tamanhos e resoluções. Mais detalhes sobre padrões gráficos de imagem podem ser consultados em (MCMAHON e BROWNE, 1998).


como linguagem, o contexto no qual os comandos aparecem podem ter um

significado diferenciado, dependendo de qual tipo de informação é repassada.

FORMATO DO ARQUIVO DXF Tudo num arquivo DXF é composto de pares chamados de grupos. Cada

grupo tem um código, seguido por um número ou string de caracteres,

chamado de valor do grupo. O código do grupo é um inteiro que indica o tipo

de valor que o segue. Alguns intervalos de códigos são reservados a certos tipos

de dados. Os códigos e valores de grupos são delimitados por um par

caracteres especiais de retorno de carro/avanço de linha (CR � Carriage-Return

/ LF � Line-Feed).

Os dados num arquivo DXF são organizados em quatro seções. A saber:

• Seção Cabeçalho: geralmente contém informações de pouco valor para

as aplicações. Ela armazena valores para variáveis do sistema

AutoCAD, tais como: estilo da interface, camadas default, estilos de

dimensionamento, etc.. Algumas vezes, esta seção é eliminada

completamente do arquivo.

• Seção Tabelas: armazena certas constantes universais, tais como

camadas do desenho, ângulos e distâncias das vistas, sistemas de

coordenadas, e estilos de dimensionamento. Da mesma forma que a

seção cabeçalho, esta seção também pode ser omitida do arquivo.

• Seção Blocos: armazena grupos de entidades pelo nome, e pode

também conter entidades. É esta seção que armazena as definições de

bloco instanciados no modelo.

• Seção Entidades: armazena as entidades geométricas bidimensionais e

tridimensionais do desenho, e inclui dados de ligação da entidade a

camadas e/ou blocos. Esta é a principal seção do arquivo DXF.

Um exemplo da estrutura de seções de um arquivo DXF é dado a seguir.

Um exemplo de arquivo DXF para o desenho mostrado na Figura 17, pode ser

visto no APÊNDICE B.

HEADER section TABLES section

linetype, layer, style, view BLOCK section


ENTITIES section drawing entities

Uma característica dos arquivos DXF é que eles são muito longos. Isso

deve-se ao fato de que para cada dado, escreve-se no mínimo duas linhas no

arquivo: uma linha diz o que é o dado, e a outra traz o valor do dado.

3.3.3. STEP (STANDARD FOR THE EXCHANGE OF PRODUCT DATA) Todos os esforços para padronização da troca de dados de produtos tem

convergido para o STEP. O STEP é a proposta da ISO � International

Organization for Standardization para definição de um padrão de modelo

computadorizado para troca de dados e informações do produto, em todo o seu

ciclo de vida.

De acordo com (EASTMAN, 1994), os objetivos do STEP são:

• Armazenar todos os dados usados para a descrição do produto;

• Armazenar todo o ciclo de vida do produto;

• Armazenar formas diversas de utilização dos dados do produto;

• Compartilhar dados de forma precisa e não ambígua;

• Compartilhar dados entre aplicações específicas;

• Compartilhar dados sem restringir a forma como uma indústria possa

utilizar esses dados. Assim, a indústria pode adotar processos

otimizados e mais ajustados às necessidades específicas.

De acordo com (OWEN, 1993), citado por (MCMAHON e BROWNE, 1998),

o padrão STEP melhora várias deficiências apresentadas pelo IGES. A seguir

discute-se sobre essas melhorias.

• O STEP usa um modelo formal para a troca de dados, o qual é descrito

usando um modelo de modelagem de informação chamado EXPRESS,

desenvolvido especialmente para o STEP. O modelo EXPRESS é legível

tanto pelo usuário como processável pelo computador. No STEP, os

dados são descritos pela linguagem EXPRESS, a qual então mapeia o

modelo para um arquivo físico. Neste caso, o arquivo físico fica livre de

definir como cada entidade em particular deve ser representada, que é

o que acontece com o padrão IGES.


• O STEP possui uma arquitetura de camadas em três níveis, conforme

mostra a Figura 19. Essas camadas habilitam a visão múltipla de

aplicação e implementação a serem definidas.

Figura 19. Arquitetura de camadas do STEP (MCMAHON e BROWNE, 1998).

A primeira camada compreende as técnicas para a implementação do

STEP, tais como a forma como os modelos estão relacionados à linguagem

EXPRESS, e desta para o arquivo físico.

A segunda camada compreende os modelos de informação de recursos, os

quais fornecem a informação independente de contexto, tais como: a descrição

geométrica e a topologia do produto.

A terceira camada compreende os protocolos de aplicação (AP � Application

Protocol), os quais contêm a informação relacionada ao domínio particular da

aplicação.

• Os AP�s descrevem os subconjuntos restritos do padrão STEP, os quais

garantem que a implementação de diferentes vendedores sejam mais

compatíveis que as implementações do IGES. Para garantir adicionais

conformidades, o STEP inclui uma metodologia para testes de

conformidade e um conjunto de testes gerais.

O conceito fundamental por trás do padrão STEP é a definição de

protocolos de aplicação (AP). Esses protocolos atuam como mecanismo de

Camada 3: Protocolos de Aplicação - AP

Camada 2: Modelos de Informação deRecursos

Camada 1: Métodos de Implementação(EXPRESS, mapeamento para o arquivo físico)

Arquivo físico

Test

es d

e Co

nfor

mid

ade

eco

njun

to d

e te

stes


especificação dos requerimentos da informação, e garantem a comunicação

entre os sistemas CAD/CAM. Um AP inclui os requerimentos de informação, o

escopo e o contexto de uma aplicação, e especifica os recursos construtores do

STEP para satisfazer estes requerimentos. Cada AP emprega três tipos de

modelos:

• AAM (Application Activity Model): descreve as atividades e os processos

que usam e produzem os dados dos produtos num contexto específico

de aplicação.

• ARM (Application Reference Model): especifica estruturas conceituais e

restrições usadas para descrever os requerimentos de informação de

uma aplicação.

• AIM (Application Interpreted Model): é um conjunto de recursos

integrados (IR � Integrated Resources) restritos, especializados e

completos, usados para satisfazer os requerimentos de informação do

ARM. O AIM é definido usando a linguagem EXPRESS ou EXPRESS-G.

O STEP está sendo implementado através do uso de uma série de AP�s. Os

três modelos acima são dependentes do contexto da aplicação. O escopo de um

AP é definido pelo tipo de produto, os estágios suportados dentro do ciclo de

vida do produto, os tipos requeridos de dados do produto, os usos dos dados

do produto, e as áreas que usam os dados do produto.

Os AP�s do STEP, listados na Tabela 6, abordam vários aspectos do projeto

mecânico e da análise estrutural.

Tabela 6. Protocolos STEP para projeto mecânico e análise estrutural.

NÚMERO E NOME DESCRIÇÃO AP203 � Configuração Controlada de Projeto de Peças Mecânicas e Montagens 3D

Inclui vários modelos sólidos B-Rep, wireframe, e de superfície; além da configuração do produto (estrutura de montagem, e versões do produto).

AP209 � Projeto através de Análise de Estruturas Compostas e Metálicas

Inclui estruturas compostas, poliméricas, e metálicas, projeto geométrico, modelagem de elementos finitos incluindo malhas, controles de análise, e resultados de análises de tensões estáticas. Este AP contém entidades relacionadas a: geometria (ponto, linha, curva, e superfície), malhas de elementos finitos, cargas, condições de contorno, etc..


AP214 � Núcleos de Dados para Processo de Projeto Automotivo

Este AP suporta dados de produto para peças automotivas, como chapas metálicas da carroceria do carro, peças mecânicas do motor, e componentes de vidro. O AP214 inclui: controle de configuração, projeto geométrico, tolerâncias, propriedades de materiais, features de usinagem, chapas metálicas, e ferramentas.

AP224 � Definição de Peças Mecânicas para o Planejamento de Processo usando Feature de Usinagem

Especifica os dados necessários para fabricação de peças mecânicas simples. Contém definições de features de forma, peças usinadas, e processos de usinagem

PROTOCOLO AP203 O AP203, endereçado pela versão inicial de STEP, é um dos mais

importantes do STEP, pois representa o nascimento de uma nova era na troca

digital de dados de produto, e como modelos sólidos devem ser comunicados.

Utilizando este protocolo, sistemas CAD podem trocar modelos sólidos

diretamente sob o controle de configuração de um formato padronizado entre

diferentes sistemas CAD. O modelo de representação de informação de

produtos do AP203 é chamado de �Configuration Control Design�. Este AP é

composto pelos recursos integrados das seguintes partes do padrão ISO 10303:

Part 41: Fundamentos de Descrição e Suporte de Produtos;

Part 42: Representação Geométrica e Topológica;

Part 43: Estruturas de Representação;

Part 44: Estrutura e Configuração de Produto.

A principal entidade deste modelo é o produto. Associada a esta entidade,

estão muitas outras que capturam várias informações: versão e definição do

produto, aprovações, ações, eventos (data e hora), contratos, classificação de

segurança, pessoas e organizações, representação geométrica, etc..

As informações capturadas pelo modelo permitem que produto seja

especificado, e também descrevem como ele foi desenvolvido, contando a sua

história através de versões, definições, desenhos e outras informações

relevantes.

O AP203 desta forma irá definir quase toda a estrutura de informação

presente no banco de dados. Informações que não são capturadas pelo modelo,

como por exemplo nome e senha de acesso, serão modeladas com entidades

adicionais, a fim de completar o modelo de informação do ambiente.


OUTRAS PARTES DO STEP Para o interesse de troca e compartilhamento de dados utilizando a

tecnologia de features, o padrão STEP reserva dois módulos: a Parte 48, e a

Parte 224.

A Parte 48 é um recurso genérico que fornece um modelo de dados para

features de forma. No caso da Parte 224, ela é um protocolo de aplicação

específica para o CAPP (Computer-Aided Process Planning).

LINGUAGEM EXPRESS O EXPRESS é uma linguagem formal para especificação de requisitos de

informação. Ela é uma das partes do padrão de dados STEP da ISO 10303 �

Part 11 � Métodos de Descrição: O manual de referência da linguagem

EXPRESS; e Part 12 � Métodos de Descrição: O manual de referência da

linguagem EXPRESS-I.

O elemento básico da linguagem EXPRESS é a entidade. Um exemplo de

entidade é dado a seguir:

ENTITY automobile ; make :STRING; serial_number :INTEGER; engine_size :REAL; colour :colourtype; owner :person; previous_owner: :LIST[0 : ?] OF person; UNIQUE serial_number; WHERE engine_size>0.0; END_ENTITY;

Como pode ser visto, a entidade é um conjunto de dados ou restrições

e/ou operações realizadas sobre os dados. Ela é expressa como uma coleção de

atributos, que podem ser de vários tipos de dados (string, real, inteiro, valor

lógico ou booleano, array, lista, conjunto, etc.). Os atributos também podem ser

referências a outras entidades, ou outros arrays, listas ou conjuntos. No

exemplo da entidade automobile acima, os atributos make, serial_number,

engine_size, são tipos de dados simples � STRING, INTEGER, e REAL,

respectivamente. Já os atributos person, e colourtype, são tipos de dados

especiais: person é uma outra entidade, e colourtype é um tipo ENUMERATION,

definido como:

ESQUEMA


TYPE colourtype = ENUMERATION OF (red, black, blue, white);

END_TYPE;

A estrutura com o conjunto de entidades, os tipos de dados e restrições

associados às entidades, é conhecido como esquema.

Existem quatro aspectos adicionais ao EXPRESS que são utilizados no

STEP: a EXPRESS-G, o EXPRESS-I, o EXPRESS-M, e EXPRESS-C.

A EXPRESS-G trata da notação gráfica que refere-se à simbologia utilizada

para representação das entidades, dos atributos, e dos relacionamentos.

A EXPRESS-I é uma linguagem de instanciação que habilita as instâncias

do esquema e modelos serem exibidos.

A EXPRESS-M trata do mapeamento entre os esquemas.

A EXPRESS-C amplia a capacidade do EXPRESS por meio de modelagem

estática e propriedades de comportamento dinâmico.

FORMATO DO ARQUIVO STEP O STEP define várias implementações de métodos para manipulação e

troca de informações descritas pelos protocolos de aplicação. O formato de

arquivo para troca de dados é definido pela Part 21 � Decodificação do texto da

estrutura de troca. No APÊNDICE C, pode ser visto um exemplo de arquivo

STEP, gerado pelo ST-DEVELOPER AP203 no MicroStation J, da Bentley; para

o desenho mostrado na Figura 17.

O arquivo de troca do STEP possui uma seção de cabeçalho � com

informações de identificação; e uma seção de dados � que contém a informação

a ser transferida.

Um exemplo de arquivo STEP é mostrado a seguir:

ISO-10303-21; /* opening keyword */ HEADER; /* header section */

[ ... header information ... ] ENDSEC; DATA; /* data section */

[ ... entity instances ... ] ENDSEC; END-ISO-10303-21; /* closing keyword */


A seção de cabeçalho de um arquivo STEP descreve a informação de

identificação a respeito do arquivo. Um exemplo de cabeçalho é mostrado a

seguir:

HEADER; FILE_DESCRIPTION (

('Sample NURBS geometry for a Boeing 707' /* description */ 'for the Common STEP Tasks Tutorial'), '1'); /* implementation level */

FILE_NAME ( 'ap203_database', /* name */ '1995-05-18T14:18:59-04:00', /* timestamp */ ('Blair Downie'), ('STEP Tools Inc.', 'Rensselaer Technology Park', 'Troy, New York 12180', '[email protected]', 'ST-DEVELOPER v1.4', /* preprocessor */ '', /* originating system */ ''); /* authorization */

FILE_SCHEMA (('CONFIG_CONTROL_DESIGN')); /* schema */ ENDSEC;

A seção de dados do arquivo contém as instâncias das entidades. Cada

instância tem um identificador inteiro. Os números #nnn são usados para se

referir aos objetos dentro do arquivo. Os números são únicos dentro de um

arquivo, mas não necessitam ser preservados. Cada instância de entidade é

normalmente escrita usando um mapeamento interno, onde o nome do tipo

da entidade é seguido por uma lista de atributos na ordem da super-classe

para a sub-classe. A seguir, tem-se alguns exemplos de entidades definidas

usando este mapeamento interno:

#57=DATE_AND_TIME(#58, #59); #58=CALENDAR_DATE(1993, 17, 7); #59=LOCAL_TIME(13, 47, 28.0, #29);

Instâncias de entidades complexas e/ou EXPRESS têm mais que um tipo,

assim eles são escritos para um arquivo STEP usando uma codificação

diferente, chamada de mapeamento externo. Este mapeamento codifica um

objeto como uma lista de tipos individuais, onde cada tipo contém somente os

atributos definidos para aquele tipo.

Um exemplo é mostrado para uma entidade que é ao mesmo tempo, uma

superfície B-spline com nós, e uma superfície racional B-spline:

#10 = ( BOUNDED_SURFACE ()


B_SPLINE_SURFACE (3, 3, ((#20, #60, #100, #140), (#30, #70, #110, #150), (#40, #80, #120, #160), (#50, #90, #130, #170)), $, .F., .F., .F.)

B_SPLINE_SURFACE_WITH_KNOTS ($, $, (0., 0., 0., 0., 1., 1., 1., 1.), (0., 0., 0., 0., 1., 1., 1., 1.), $)

GEOMETRIC_REPRESENTATION_ITEM () RATIONAL_B_SPLINE_SURFACE (((1., 1., 1., 1.), (1., 1., 1., 1.),

(1., 1., 1., 1.), (1., 1., 1., 1.))) REPRESENTATION_ITEM () SURFACE () );

O formato de um arquivo STEP está estreitamente ligado ao esquema

ESPRESS, no qual ele foi escrito. A ordem dos valores dos atributos são

determinadas a partir do esquema EXPRESS.

3.3.4. ACIS ACIS é uma biblioteca de funções (kernel) para modelagem geométrica de

objetos tridimensionais. Ele é um modelador geométrico de sólidos, que adota

um esquema de representação de contorno (B-Rep).

Ele é constituído por conjunto de classes de funções escritas em C++,

implementadas de acordo com o paradigma da programação orientada a objeto.

O ACIS foi desenvolvido pela Spatial Technology, Inc.. Atualmente, ele está

licenciado para mais de duzentos desenvolvedores comerciais, centros de

pesquisa e universidades.

Utilizando as classes do ACIS, os desenvolvedores de programas podem

criar aplicações 3D mais facilmente, pois grande parte dos algoritmos para

modelagem geométrica já estão implementados e otimizados. Além disso, os

programas CAD podem transferir e compartilhar arquivos gerados entre as

demais aplicações que também empregam a tecnologia ACIS.

Embora seja um modelador de sólidos, a biblioteca de funções do ACIS

permite integrar modelos wireframe, de superfície, e sólidos numa mesma

estrutura de dados. As formas lineares e quadráticas são representadas

analiticamente, e curvas NURBS são utilizadas para representar as geometrias

de forma-livre.

Os ACIS armazena e recupera as informações dos modelos a partir de dois

tipos de arquivos: arquivo SAT (save as text), e arquivo SAB (save as binary).


Os arquivos do tipo SAT são salvos em formato texto ASCII, e os arquivos do

tipo SAB são salvos em formato binário.

No APÊNDICE D, tem-se um exemplo de arquivo ACIS. Ele foi gerado a

partir do desenho mostrado na Figura 17.

CONCEITOS E CARACTERÍSTICAS DO ACIS • A integração entre ACIS e C++ O C++ não possui as classes matemáticas básicas necessárias para

descrever a geometria. O ACIS então fornece essas classes de baixo nível para

estabelecer esta base, e o usuário pode então estendê-las com as

potencialidades do C++, definindo as suas próprias classes.

As aplicações C++ podem se comunicar com o ACIS por três formas:

API's (Application Programming Interface). Um API é uma função que uma

aplicação chama para criar, alterar, ou armazenar um dado. Uma função API

combina a funcionalidade de modelagem e características de suporte à

aplicação, tais como verificação de erros de parâmetros e consistência do

modelo. Quando um erro ocorre numa função API, o ACIS automaticamente

retorna ao estado do modelo anterior à chamada da função. Esse mecanismo

de retorno, conhecido como "roll back", garante a consistência do modelo

gerado. As funções do tipo API são garantidas quanto a compatibilidade com

novas versões do ACIS.

Classes C++. São usadas para definir o modelo geométrico, topológico, ou

outras características. As classes podem ser usadas por uma aplicação para

interagir diretamente com o ACIS, através dos seus dados e métodos públicos

ou protegidos. Desenvolvedores também podem derivar classes específicas a

partir do ACIS, para uma aplicação desejada. Esta interface de classe pode

mudar de uma versão para outra. A classe ENTITY é a classe abstrata, a partir

da qual todas as demais são derivadas. Na Figura 20, tem-se a hierarquia de

classe definida pelo ACIS.

DI (Direct Interface). É um tipo de função que permite acesso às

funcionalidades do ACIS sem oferecer suporte verificação de erros ou

consistência do modelo gerado. Diferentemente das API's, estas funções não

são garantidas quanto à manutenção da compatibilidade com novas versões do


ACIS. As funções DI são utilizadas para realizar operações que não alteram o

modelo, tais como operações de pesquisa.

Figura 20. Hierarquia de classes do ACIS (SPATIAL, 1999).

• A Geometria no ACIS A geometria refere-se aos itens físicos representados pelo modelo,

independentes do seu relacionamento espacial ou topológico. O ACIS

implementa a geometria em duas formas distintas:

• Geometria de construção: refere-se às classes C++ que suportam as

definições matemáticas dos objetos geométricos.

• Geometria do modelo: refere-se às classes C++ que adicionam a

funcionalidade de gerenciamento do modelo para a geometria de

construção. Elas incluem os ponteiros para as classes da geometria de

construção, como parte da sua estrutura de dados. A geometria do

modelo é salva no modelo.

ENTITY

TRANSFORMAPOINTCURVEPCURVE

SURFACE

BODYLUMPSHELLSUBSHELLFACEWIRELOOPCOEDGEEDGEVERTEX

ATTRIB

STRAIGHTELLIPSEINTCURVECOMPCURVEPLANECONESPHERETORUSSPLINEMESHSURF

ATRIBUTOS DEFINIDOS PELO USUÁRIOATRIBUTOS DO SISTEMA

ModeloGeométrico

Topologia

Atributos


Figura 21. Hierarquia topológica da representação B-Rep do ACIS.

• A Topologia no ACIS

A topologia refere-se ao relacionamento espacial entre os vários objetos do

modelo. Ela descreve como os objetos estão conectados. A representação B-Rep

do ACIS, segue a decomposição hierárquica mostrada na Figura 21.

Body: é uma coleção de objetos lump, que têm uma transformação

comum.

Lump: é um conjunto de pontos 1D, 2D, e 3D conectados no espaço, que

estão disjuntos de todos os outros objetos lumps. Ele é limitado por objetos

shell.

Shells: é um conjunto de objetos faces e/ou wires conectados. Ele pode

limitar o exterior de um sólido, ou vazio interno (oco).

Subshells: forma uma decomposição adicional do objeto shell, para

propósito de eficiência interna.

Body

Lumps

Shells

Subshells

Faces Wires

Loops

Coedges

Edges

Vertices


Face: uma região conectada de superfícies limitadas por um ou mais

loops de arestas. Uma face pode ter dois lados, em neste caso ela é

infinitamente fina. Ela também pode se de um só lado, e neste caso a face

normal aponta para fora, e o material sólido está presente sobre o outro lado

da face.

Loop: uma região conectada de um contorno de face, o qual é constituído

de uma série de coedges. Geralmente, os loops são fechados, sem um ponto de

início ou fim. Mas, eles também podem ser abertos.

Wire: é uma série conectada de coedges, os quais não estão ligados à face.

Coedge: representa o uso de um edge por uma face ou por um wire.

Edge: a topologia associada com uma curva. Objetos edges são limitados

por objetos vertices.

Vertices: um vértice limita um objeto edge. Ele geralmente é o canto de

um objeto face ou wire. Um objeto vertex contém uma referência para um

ponto geométrico no espaço, e um objeto edge que o limita.

• Entidade e Modelo de Objeto

A entidade (ENTITY) é o objeto mais básico do ACIS, conforme pode-se ver

na Figura 20. Todas as entidades têm um conjunto comum de funcionalidades,

tais como a habilidade de poderem ser armazenadas (objetos persistentes) e

recuperadas a partir de um arquivo, de serem copiadas, e depuradas. Todos os

níveis mais elevados da hierarquia de objetos do ACIS são derivados da classe

ENTITY.

O modelo de objeto é qualquer objeto que pode ser salvo ou restaurado a

partir de um arquivo SAT. Os modelos de objetos do ACIS são implementados

em C++, a partir da hierarquia de classes.

• Atributos

Os atributos são usados para ligar os dados às entidades. A classe

ATTRIB, a qual é derivada diretamente de ENTITY, fornece os dados e a

funcionalidade que todos os atributos compartilham. Os atributos podem

suportar dados simples (inteiro, real, string, etc.), ponteiros para outras

entidades ou links para aplicações específicas, e dados de tamanhos variados.


As informações sobre o ACIS podem ser pesquisadas na referência

(SPATIAL, 1999), ou na página da Internet da Spatial Technology, Inc.

(http://www.spatial.com).

3.3.5. PARASOLID Outra alternativa para arquivo de troca de dados, é o Parasolid

desenvolvido pela Unigraphics Solutions Inc.. Ele é um conjunto de funções

para modelagem de sólidos que pode ser embutido noutros programas

aplicativos.

Muitos dos sistemas CAD/CAM/CAE, considerados de alto nível ou de

aplicação final (high-end applications), possuem o seu próprio modelador

geométrico embutido dentro do sistema. O Parasolid, assim como o ACIS,

também é um núcleo de funções de modelagem geométrica, que pode ser usado

em muitos sistemas de alto nível ou de aplicação média (mid-range application).

Portanto, ele é portátil entre diferentes sistemas.

Atualmente, o Parasolid é usado como componente integrante de vários

sistemas de CAD/CAM/CAE desenvolvidos pelos principais fornecedores de

programas para engenharia. Os principais desenvolvedores de sistemas que já

aderiram ao Parasolid são: Parametric Technology, SolidWorks Corporation (uma

subsidiária da Dassault Systemes SA), ANSYS, Mechanical Dynamics, MacNeal-

Schwendler, Bentley Systems. etc.. Além disso, o Parasolid é usado

internamente em grandes companhias, como uma ferramenta de

desenvolvimento de aplicações, como por exemplo: General Motors, Mitsubishi

Motors, Boeing, etc.

Para dar uma breve olhada num exemplo de arquivo Parasolid, pode ser

consultado o APÊNDICE E. O arquivo também foi gerado com base no desenho

mostrado na Figura 17.

OBSERVAÇÃO: Muito pouco pode ser encontrado na Internet sobre o

Parasolid. O principal endereço para consulta é: http://www.parasolid.com.


CCoonncceeiittooss ee AApplliiccaaççããoo ddee BBaannccoo ddee DDaaddooss


Uma análise da evolução das aplicações de sistemas de informação

baseados em computador evidencia uma tendência natural e indicativa de que

esses sistemas evoluem para uma abrangência cada vez maior, e

conseqüentemente, para um aumento do grau de complexidade de seu

desenvolvimento e manutenção.

As primeiras aplicações eram basicamente dirigidas a um determinado

setor da empresa; e por isso, seu desenvolvimento baseava-se nos processos,

dados e arquivos específicos desse setor. Nesse mesmo enfoque, outros setores

da empresa eram gradativamente atingidos por tal processo, e assim, o sistema

de informação da empresa como um todo, era constituído por diversos

sistemas, os quais possuíam processos e arquivos próprios e independentes. A

comunicação de dados entre tais sistemas, quando necessária, fazia-se por

arquivos especificamente destinados à finalidade desejada.

CAP. 4 � CONCEITOS E APLICAÇÃO DE BANCO DE DADOS 48

As conseqüências mais diretas desse modo de desenvolvimento de

sistemas dizem respeito à duplicação de dados e tarefas entre os sistemas

feitos para cada aplicação.

Essa duplicação provoca sérios problemas na evolução do sistema como

um todo, tais como: incoerência de uma mesma informação armazenada por

dados duplicados, os quais são passíveis de serem alterados individualmente, o

que acarretaria uma inconsistência entre os mesmos; e o custo de

manutenção, que fica aumentado devido ao fato de uma mesma tarefa ser

realizada em dois ou mais processos distintos.

Da identificação desses problemas, a evolução natural impôs aos sistemas

de informação uma eliminação da duplicação, implicando numa integração

entre dados que antes eram armazenados com redundância não controlada.

Esse novo estado resolvia o problema da duplicação de dados, todavia

introduzia um novo problema. Devido à integração, dois ou mais processos

passam a compartilhar do mesmo dado, mas sua utilização é completamente

dependente da forma de representação física, e conseqüentemente, sempre que

um determinado processo necessita que essa representação física seja alterada,

todas as demais aplicações que compartilham desses dados são atingidas, e

portanto, precisam ser alteradas de forma a poderem continuar utilizando-os.

Outro problema dessa integração deve-se ao fato de um mesmo dado

poder ter diferentes estruturações físicas com tipos e tamanhos diferentes, e

por conseguinte, dois processos distintos poderem necessitar de

representações diferentes de um mesmo dado de acordo com a utilização que

façam deste.

Nesse ponto da evolução dos sistemas de informação, para manter a

integração entre os dados, faz-se necessária uma independência entre dados e

processos, de forma a permitir que cada processo possa evoluir naturalmente

sem causar impacto aos demais que utilizem dados em comum com ele.

Paralelamente a essa evolução na área do software, existe outra na área

de hardware, pela qual o custo por byte armazenado em dispositivos de

armazenamento secundário vem decrescendo, e a capacidade de tais

dispositivos, vem aumentando. Isso favorece o armazenamento e a


manipulação de dados que antes não podiam ser utilizados devido ao alto

custo de armazenamento.

Com isso, as possíveis aplicações para sistemas de informação baseados

em computador, tornam-se cada vez mais diversificadas e abrangentes,

passando a existir aplicações que necessitam de estruturas de armazenamento

complexas e que requerem técnicas mais sofisticadas para sua manutenção.

Vale ressaltar que essas técnicas, normalmente não são do domínio dos

analistas, os quais estão mais preocupados com problemas específicos de suas

aplicações.

Esse estado de coisas evidencia a necessidade de um novo enfoque para o

desenvolvimento de sistemas de informação. Esse novo enfoque pode ser

caracterizado por uma necessidade de separação entre os problemas

específicos de cada aplicação, e os de armazenamento e recuperação de dados

que normalmente são comuns a todas as aplicações.

Neste ponto surgem os "Sistemas de Gerenciamento de Banco de Dados"

(DBMS � Data Base Management System), tendo como finalidade básica tirar

dos programas de aplicação, a responsabilidade de resolver os problemas

mencionados anteriormente.

44..22.. DDEEFFIINNIIÇÇÕÕEESS EE CCOONNCCEEIITTOOSS

Um sistema de banco de dados, também conhecido pela sigla DBMS é um

programa computacional para gerenciamento de um repositório de dados

permanentes e auto-descritivos. Este repositório de dados é chamado de banco

de dados e está armazenado em um ou mais arquivos.

As diferentes informações armazenadas nos arquivos de banco de dados

são tipicamente formadas por itens, que constituem a unidade de informação.

Um conjunto de itens específicos para um tipo de problema forma um registro,

sendo que o conjunto de registros daquele problema forma o arquivo de dados

correspondente.

Outro conceito importante é o de esquema, o qual corresponde à definição

da estrutura de dados, ou seja, é a concepção global de banco de dados. O


esquema raramente é alterado, pois isso implica em mudar a estrutura do

banco de dados. Para um dado esquema, é possível usá-lo para diferentes

aplicações, ou seja, uma mesma estrutura de dados contemplando diferentes

conjuntos de dados. Cada uma destas aplicações é o que corresponde a uma

instância do banco de dados, correspondendo ao estado do banco de dados

num certo instante.

Existem muitas razões pelas quais utilizam-se banco de dados:

• Recuperação de dados: o banco de dados é protegido contra problemas

de hardware, falhas de mídias, e alguns erros de usuários.

• Compartilhamento entre usuários: múltiplos usuários podem acessar o

banco de dados ao mesmo tempo.

• Compartilhamento entre aplicações: múltiplos programas aplicativos

podem ler ou escrever dados no mesmo banco de dados. Um banco de

dados é um meio neutro que facilita a comunicação entre programas

aplicativos.

• Segurança: os dados podem ser protegidos contra acessos de leitura ou

escrita não autorizados.

• Integridade: pode-se especificar regras que os dados devem satisfazer.

Um DBMS pode controlar a qualidade de seus dados.

• Extensibilidade: os dados podem ser adicionados para banco de dados

sem desorganizar programas aplicativos existentes. Os dados podem ser

reorganizados para uma performance mais rápida.

• Distribuição de dados: o banco de dados pode ser particionado entre

vários lugares, arquiteturas computacionais ou plataformas de

hardware.

44..33.. AA EESSTTRRUUTTUURRAA DDEE UUMM BBAANNCCOO DDEE DDAADDOOSS

A preocupação com eficiência faz com que sejam usadas estruturas de

dados complexas para fazer o armazenamento dos dados no banco de dados.

Esta complexidade deve ser transparente ao usuário, sendo totalmente


manipulada pelo DBMS. Para implementar esta transparência, diferentes

níveis de abstração do banco de dados devem ser usados.

• Nível Físico: é o nível onde se estabelece como os dados serão

armazenados nos arquivos, sendo muito dependente de características

do hardware.

• Nível Conceitual: neste nível é estabelecido o projeto de um banco de

dados, com a especificação de quais dados devem ser armazenados,

bem como qual o relacionamento que existe entre dados. O nível

conceitual é usado pelos responsáveis da manutenção do banco de

dados, os quais vão definir a sua estrutura.

• Nível de Visão: é o nível de abstração mais alto, onde o usuário

trabalha com as informações armazenadas, de acordo com o seu

interesse específico. Apenas uma parte das informações são colocadas

para o usuário, em função das suas necessidades e da sua permissão

de acesso. Para um mesmo banco de dados, podem ser definidas

inúmeras visões, cada qual contemplando uma necessidade específica,

onde apenas as informações relevantes são apresentadas, bem como os

programas aplicativos.

Figura 22. Níveis de abstração de um banco de dados (Baseado em RUMBAUGH et al., 1991).

Um padrão de arquitetura de DBMS é o proposto pelo comitê de banco de

dados da ANSI (American National Standards Institute)/SPARC.

Essa arquitetura é ilustrada na Figura 22.

EsquemaExterno 1

EsquemaExterno 2

EsquemaExterno n

Aplicação 1 Aplicação 2 Aplicação n

Esquema Conceitual

Esquemainterno 1

Esquemainterno m

Nível do esquemaexterno

Nível do esquemaconceitual

Nível do esquemainterno


A idéia básica é de que um projeto de um banco de dados deve

compreender três níveis ou camadas: um nível de esquema externo, um nível

de esquema conceitual, e um nível de esquema interno. Cada esquema externo

é um projeto de banco de dados sob a perspectiva de uma aplicação específica.

O esquema externo é uma visão ou abstração do esquema conceitual global. O

esquema externo isola as aplicações de quaisquer alterações no esquema

conceitual. O esquema conceitual é um projeto de banco de dados sob a

perspectiva da empresa ou organização. O esquema conceitual integra as

aplicações relacionadas e esconde as peculiaridades do DBMS. O esquema

interno trata com as limitações e características de um DBMS específico. O

nível de esquema interno consiste de códigos DBMS necessários para

implementar o esquema conceitual.

Todo sistema de gerenciamento de banco de dados tem como tarefas

básicas, definir estruturas de dados e manipular estes dados. Para permitir

estas ações, sem necessidade de recorrer a linguagens de programação que

acessam diretamente os arquivos em disco, todo DBMS possui linguagens

próprias para tal tarefa. Assim, tem-se a chamada �Linguagem de Definição de

Dados� (DDL � Data Definition Language), a qual fornece meios para o

administrador do banco de dados trabalhar sobre o nível conceitual, definindo

novas estruturas de dados, ou alterando as existentes. Esta linguagem

trabalha diretamente sobre o esquema do banco de dados. O resultado de uma

compilação de instruções DDL é um conjunto de tabelas armazenadas num

arquivo especial do banco de dados, denominado de dicionário de dados. Os

detalhes que especificam a forma de implementação dos esquemas do banco de

dados são o resultado desta compilação, e ficam inacessíveis para o usuário.

44..44.. CCLLAASSSSIIFFIICCAAÇÇÃÃOO DDOOSS SSIISSTTEEMMAASS DDEE BBAANNCCOO DDEE DDAADDOOSS

Nos modelos lógicos, a descrição recai sobre os níveis conceituais e de

visão. Vários modelos têm sido propostos nesta linha, sendo atualmente uma

grande área de pesquisa e desenvolvimento, tanto nas ciências da computação

quanto nas áreas de aplicação, como Engenharia.


Os modelos lógicos podem ser baseados em objetos, e em registros. O

conceito de registro depende do modelo de dados que se está tratando. Os

principais modelos baseados em registros são: o modelo relacional, o modelo

em rede, e o modelo hierárquico.

Já os modelos de dados físicos, atuam no nível físico do banco de dados,

capturando aspectos relacionados diretamente com a implementação do banco

de dados.

Os bancos de dados em CAD/CAM, devem ser capazes de armazenar

dados geométricos, textuais, e alfanuméricos. Na seqüência, tem-se uma

descrição dos principais tipos de banco de dados.

4.4.1. O MODELO RELACIONAL No modelo relacional de banco de dados, todos os elos de ligação são

implícitos, sendo que os dados � na terminologia do modelo relacional � são

definidos em domínios da entidade como também para seus atributos. Estes

domínios representam uma classificação quanto ao tipo de dado. O banco de

dados trabalha sobre um conjunto de domínios, cada qual representando um

tipo de dado.

O termo relacional vem do conceito de relação, que corresponde a um

subconjunto do produto cartesiano dos domínios definidos. Os elementos de

uma relação são suas n-uplas, ou tuplas.

O modelo relacional procura descrever o banco de dados pelo uso de

conceitos matemáticos, evitando misturar a estrutura lógica dos dados com

detalhes de implementação. No nível do usuário, visualiza-se o banco de dados

relacional como sendo um conjunto de tabelas, sendo que cada tabela

representa uma relação.

A representação das relações por meio de tabelas, torna bastante

facilitado o trabalho de entendimento e de montagem do banco de dados, pois

uma relação só contém os elementos do produto cartesiano que são relevantes,

ou que existem e estão definidos. Quanto à nomenclatura, existe uma

correspondência direta entre relação e arquivo, e entre tupla e registro.


Figura 23. Objeto-base e sua estrutura de dados: vértices, arestas, e faces.

Considerando o objeto mostrado na Figura 23 como base, tem-se um

exemplo de banco de dados relacional, mostrado na Figura 24.

PONTO X Y LINHA PONTO INICIAL

PONTO FINAL SUPERFÍCIE LINHA/

CURVA TIPO

1 x1 y1 A 1 4 1

A B C D

Linha Linha Linha Linha

2 x2 y2 B 1 2 2

E F G D

Linha Linha Linha Linha

3 x3 y3 C 2 3 RELAÇÃO SUPERFÍCIE 4 x4 y4 D 3 4 5 x5 y5 E 5 6 6 x6 y6 F 6 7 7 x7 y7 G 7 8 8 x8 y8

RELAÇÃO PONTO

RELAÇÃO LINHA/CURVA

Figura 24. Exemplo de banco de dados relacional (Baseado em ZEID, 1991).

OPERAÇÕES DA ÁLGEBRA RELACIONAL Um ponto importante no modelo relacional diz respeito à possibilidade de

manipulação dos dados pelo uso da chamada álgebra relacional, que opera

sobre as relações, criando novas relações. Antes de detalhar a álgebra

relacional, é necessário definir o conceito de relação �união-compatível�. Uma

dada relação T, é dita união-compatível com relação a S quando ambas

possuem os mesmos domínios, ou seja, são subconjuntos do mesmo produto

cartesiano. A rigor, bastaria que T tivesse o mesmo número de domínios que S,

e que estes domínios fossem do mesmo tipo. O resultado de uma operação da

álgebra relacional é uma terceira relação. As operações da álgebra relacional

são descritas a seguir.

• UNIÃO: R ← S ∪ T

A relação contém os registros de S e de T, sem repetições.

B1 B2B

A

G

E

F

C

D

1

2

5

8

4

3

7

6


• INTERSECÇÃO: R ← S ∩ T

A relação R contém apenas os registros comuns a S e T. É lógico que S e T

devem ser união-compatíveis.

• DIFERENÇA: R ← S − T

A relação contém os registros de S que não estão presentes em T. Neste

caso ocorre que (S � T) é diferente de (T � S).

• PRODUTO CARTESIANO: R ← S × T

A relação R contém todos os registros de S concatenados com todos os

registros de T.

• PROJEÇÃO: R ← S [Di, Dj, Dk]

A relação R contém os registros de S, porém truncados para apenas os

domínios indicados.

• RESTRIÇÃO: R ← S [Di = C]

A relação R contém apenas os registros de S que satisfazem a condição, no

caso o valor do domínio ser igual a C. Na operação de restrição é possível usar

os comparadores =, ≠, <, ≤, ≥, >.

• JUNÇÃO: R ← S [Di = Dk] T

A relação R contém os registros definidos pela junção dos domínios de S

com os domínios de T, apenas para as relações onde a comparação é válida. No

caso o valor do domínio Di da relação S deve ser igual ao valor do domínio Dk

da relação T.

• DIVISÃO: R ← S [Di : Dk] T

A relação R contém alguns registros de S, projetados sobre os domínios de

S, exceto Di, como o conjunto de registros onde Di contém todos os valores da

projeção T[Dk].

4.4.2. O MODELO HIERÁRQUICO O modelo hierárquico de banco de dados possui uma estrutura lógica na

qual os dados estão na forma de um conjunto de árvores que definem a

hierarquia. Desta forma, os registros são relacionados entre níveis hierárquicos

distintos, onde de um nível superior derivam N registros do nível inferior. Desta

forma, um modelo hierárquico possui sempre um relacionamento do tipo 1:N,

ou seja, de um registro derivam N registros. O registro inicial de uma árvore é a


chamada raiz, que corresponde ao nível hierárquico mais alto. Os elos de

ligação de hierarquia são elos explícitos, criados e gerenciados pelo DBMS.

Quando um novo registro é inserido no banco de dados, deve ser indicado qual

é o seu ascendente, ou seja, o registro do qual deriva. De um modo geral, pode-

se dizer que cada nível da hierarquia corresponde a um tipo de registro, ou

seja, a um conteúdo de informações.

A Figura 25 esquematiza uma estrutura típica de um banco de dados do

tipo hierárquico para dados geométricos, com base no objeto da Figura 23.

Figura 25. Exemplo de banco de dados hierárquico (Baseado em ZEID, 1991).

4.4.3. O MODELO EM REDE O modelo lógico de dados em rede pode ser pensado como uma

generalização de um banco de dados hierárquico, pois é permitida uma relação

do tipo M:N, ou seja, pode-se ter M registros de um tipo se relacionando com N

registros de outro tipo, como no caso exemplificado de fornecedores e peças. No

modelo em rede é possível definir diferentes tipos de elos, que podem assim

estabelecer relacionamentos distintos, entre os mesmos tipos de registros.

Uma estrutura particular de modelo em rede foi o chamado CODASYL

(Conference on Data Systems Languages), que foi uma tentativa de

padronização de banco de dados em rede, e permitiu relacionamentos menos

restritivos entre elementos de dados comparado ao modelo hierárquico.

Objeto (raiz)

S2

E F G D

5 6 3 4

y5x5 x4 y4

S1

A B C D

1 4 3 4

y1x1 x4 y4

Nível dassuperfícies

Nível dasarestas

Nível dosvértices

Nível dascoordenadas


Um exemplo de banco de dados em rede é mostrado na Figura 26.

Figura 26. Exemplo de banco de dados em rede (Baseado em ZEID, 1991).

44..55.. BBAANNCCOO DDEE DDAADDOOSS OORRIIEENNTTAADDOOSS AA OOBBJJEETTOOSS

O rumo atual das técnicas de modelagem da informação apontam para os

sistemas de gerenciamento de banco de dados orientados a objeto (OODB �

Object-Oriented Data Base). Um modelo de informação orientado a objeto

permite que o usuário modele entidades conceituais através de um poderoso

conceito de modelagem � o objeto. O conceito de objeto e os seus princípios de

programação, estão discutidos com mais detalhes no APÊNDICE F, no final

deste estudo.

Em banco de dados, o objeto corresponde a tipos de dados abstratos (ADT

� Abstract Data Types), que especificam o comportamento do objeto, mas

escondem a estrutura de dados e a implementação (encapsulamento de dados).

A implementação de um ADT consiste de sua estrutura de dados (atributos), e

dos operadores (métodos) que são suficientes para manipular e derivar dados a

partir deles. Devido ao encapsulamento de dados internos ao objeto � dos seus

atributos � não é permitida a manipulação externa desses atributos. Todas as

manipulações de dados devem ocorrer através de chamadas aos operadores

(métodos).

Os OODB�s também incorporam conceitos de especialização de atributos e

de métodos, através da implementação do conceito de herança. A herança

S1 S2

21 43 76 85

BA DC GFE

Superfícies

Arestas

Vértices


permite que objetos simples possam ser refinados ou combinados para definir

outros objetos mais complexos. Além de que ela fornece uma ferramenta

poderosa para organizar a estrutura de dados e reusar o código. A

especialização de métodos pode ocasionar problemas, em que um método pode

se tornar inadequado após novas variáveis serem adicionadas à definição do

objeto (EASTMAN e FERESHETIAN, 1994).

Existem muitas variantes de OODB�s, conforme comentado a seguir:

• Muitos sistemas fazem distinção entre instâncias e objetos de classe, e

aplicam herança somente para classes. Neste caso, a hierarquia de

objetos é definida estaticamente, antes que o banco de dados seja

usado. Outros sistemas não fazem esta distinção, e permitem que

qualquer objeto seja especializado. Assim, a hierarquia de objetos é

dinâmica, e pode ser modificada com o banco de dados em execução.

• Alguns sistemas também permitem que qualquer objeto tenha apenas

uma especialização (herança simples), enquanto outros permitem

várias especializações (múltipla herança).

• Alguns OODB�s encaram todas as variáveis como objetos, e são

chamados de �fortemente orientados a objeto�. Enquanto que outros

sistemas consideram também os tipos tradicionais de variáveis (inteiro,

real, string, etc.), além dos objetos. Esses são conhecidos como

�fracamente orientados a objeto�.

Os sistemas OODB�s são altamente recomendados para as necessidades

de desenvolvimento de projeto, pois eles possuem a estrutura adequada para

tanto. O conceito de especialização permite a herança, que é o conceito

importantíssimo para modelagem do produto. A modelagem do comportamento

do objeto possibilita definir muitas relações que não são facilmente modeladas

através de regras ou restrições. Os modelos tradicionais, tais como o modelo

relacional, permite apenas uma definição parcial da semântica do

comportamento do objeto.

(EASTMAN e FERESHETIAN, 1994) informam que novas tecnologias foram

pesquisadas com o objetivo de possibilitar a modificação dos modelos de

informação para adicionar, por exemplo, novas tecnologias ou novos métodos


de análise emergentes. Todavia, eles advertem que para isso, deve-se

considerar a evolução dinâmica de modelos, incluindo as seguintes habilidades

aos sistemas:

• A especialização dinâmica de novos objetos em outros objetos;

• A adição de relações de objeto e de composição em objetos já definidos;

• A herança múltipla.

Estas características não estão presentes em muitas implementações de

OODB�s.

44..66.. AAPPLLIICCAAÇÇÕÕEESS DDEE BBAANNCCOO DDEE DDAADDOOSS EEMM CCAADD

4.6.1. BANCO DE DADOS ORIENTADOS A OBJETO EM CAD Diferente do processamento de outros banco de dados convencionais, as

aplicações de CAD requerem acesso e manipulação de bancos de dados

orientados a objeto. Isso se deve ao fato de que os sistemas de CAD manipulam

e acessam objetos de projeto, e não arquivos ou registros de dados individuais.

Estes objetos de projeto também são a base para garantir a integridade

sobre os componentes de um objeto durante as operações de inserção, deleção

ou modificação.

Os modelos de banco de dados orientados a objetos incluem o modelo E/R

� Entidade/Relacionamento, a representação de objetos complexos, a

representação de objetos moleculares ou compostos, e o modelo de dados

abstratos. O modelo de dados abstratos se assemelha ao banco de dados

modelagem de sólidos. Ele emprega objetos abstratos como primitivas no

projeto do banco de dados. As primitivas são formadas a partir de dados de

entrada, e formam o nível mais baixo de armazenagem do banco de dados.

Banco de dados orientados a objetos são ideais para aplicações e sistemas

CAD. Os modelos hierárquicos também podem ser úteis para sistemas CAD.

Abaixo, tem-se listado alguns requisitos funcionais e especificações que

um banco de dados para sistemas CAD deve suportar:


• Deve ser portátil e útil a várias aplicações de engenharia, englobando

todo o ciclo de vida do produto.

• Deve permitir modificações dinâmicas e ampliação do banco de dados e

de sua associatividade.

• Deve suportar a natureza iterativa, heurística e evolutiva do processo

de projeto.

• Deve gerenciar versões diferentes do projeto e níveis de detalhes e

abstração. O banco de dados deve armazenar e gerenciar múltiplas

alternativas de solução que podem existir para um projeto específico.

• Armazenar dados temporários de projeto, até que ele seja finalizado.

• Permitir uma seqüência livre de operação, orientando o projetista para

uma solução mais otimizada.

• Facilidade de acesso, permitindo que os dados possam ser fácil e

rapidamente recuperados, sem a necessidade de um aprofundamento

ou experiência prévia em tecnologias de banco de dados. Isto é

importante para personalização de procedimentos específicos de projeto

e fabricação.


GGeerreenncciiaammeennttoo ddaa IInnffoorrmmaaççããoo eemm CCAADD//CCAAMM


No início da década de noventa surgiram os primeiros sistemas PDM

(Product Data Management). Estes incorporavam ao recurso de gerenciamento

de documentos eletrônicos dos EDMS (Electronic Data Management System), a

possibilidade de gerenciar dados de produto. Isto significava atuar em rede com

os sistemas CAD, compartilhando-os através de bancos de dados. Essa pode

ser considerada a 1a. geração dos sistemas PDM.

Os sistemas CAD/CAM/CAE e CIM (Computer-Integrated Manufacturing),

com a facilidade de rapidamente gerar e alterar dados do produto, têm exigido

que, com muito esforço, os sistemas convencionais gerenciem dados, e também

auxiliem no processo de criação e utilização dos dados numa forma ordenada e

eficiente. Dessa forma, os usuários podem facilmente criar quantidades

consideráveis de informação relacionada ao produto. E para complicar ainda

mais a questão, esta informação está freqüentemente armazenada em

diferentes formatos dentro de uma variedade de sistemas, e se encontra em

CAP. 5 � GERENCIAMENTO DA INFORMAÇÃO EM CAD/CAM 62

diferentes e dispersos computadores. Esses podem estar armazenados em

diferentes tipos de mídia, por exemplo: arquivos de computadores, cópia

impressa em papel, cartões perfurados, microfilmes.

A utilização de sistemas PDM auxilia a implementação da Engenharia

Simultânea, pois estes sistemas fornecem meios para integração e para o

gerenciamento das informações do produto e do processo de desenvolvimento

de produtos conforme as necessidades da empresa (CIMdata, 1999).

Atualmente, o desenvolvimento de produto deve estar integrado com todas

as atividades, áreas e informações da empresa. Para essa necessidade,

surgiram os sistemas PDM ditos de 2a. geração. Tais sistemas atendem grande

parte das necessidades de engenharia, gerenciando os modelos CAD e

aplicando o conceito DMU � Digital Mock-Up, os recursos de coordenação dos

fluxos de atividades de decisão, aprovação e ordenamento de tarefas, e

modificações realizadas sobre os modelos. Além disso, permitem uma

integração com os sistemas computacionais de MRP � Materials Requirements

Planning através de relacionamentos com listas de materiais, atendendo as

áreas de planejamento, fabricação, suprimentos e financeiras.

A utilização e aplicação desses sistemas nas atividades de suporte ao

gerenciamento de projetos nas indústrias é promissora. (GUERRERO et al.,

1999), baseado em fontes do CIMdata, informa que o mercado de sistemas

PDM movimentou em 1997 cerca de U$1,1 bilhões, e a expectativa de

crescimento é de 18% por ano, até o ano 2000. Além disso, observa-se que o

mercado de PDM possui uma grande segmentação, que tende a aumentar no

futuro, com uma grande variedade de empresas e sistemas. As 10 maiores

empresas fornecedoras de sistemas PDM dominam aproximadamente 50% do

mercado, e o restante é dividido entre dezenas de outras empresas.

5.1.1. O QUE É PDM? PDM é um acrônimo das palavras, em inglês, Product Data Management,

que quer dizer "Gerenciamento de Dados do Produto". Numa organização

empresarial, os sistemas PDM atuam nos diversos departamentos e setores,

conforme mostra a Figura 27.


PDM é uma ferramenta que ajuda a gerenciar os dados e o processo de

desenvolvimento do produto. Os sistemas PDM guardam a trilha de dados e

informação requeridos para projetar, fabricar ou construir, e então suportar e

manter o produto.

Figura 27. Utilização do sistema PDM numa organização empresarial (CIMDATA, 1999).

PDM é uma extensão geral de técnicas, as quais comumente recebem

diversas denominações representadas por outros acrônimos de palavras em

inglês, tais como:

• EDM � Engineering Data Management; Electronic Data Management

• Document Management

• PIM � Product Information Management

• TDM � Technical Data Management

• TIM � Technical Information Management

• Image Management; e outros.

Em suma, PDM é aceito como uma terminologia comum, que engloba

todos os sistemas que são usados para gerenciar a informação do produto.

Os sistemas PDM integram e gerenciam processos, aplicações, e

informação que definem o produto por meio de diversos sistemas e mídias. A

qualidade de um produto é função de um desenvolvimento, uma fabricação e

uma distribuição eficiente e bem administrada. Os sistemas PDM ajudam

atingir esses objetivos.

Projeto Fabricação

Produção

Processos da fábrica

Gerenciamento e Controle

Compra e Finanças

PublicidadeVenda

Atendimento ao cliente

Sistemas PDM

Infra-estrutura einstalações de informação


Os sistemas PDM gerenciam toda a informação relacionada ao produto,

incluindo documentos eletrônicos, arquivos digitais, e registros de banco de

dados. A Tabela 7 cita alguns produtos gerenciados por sistemas PDM.

Tabela 7. Tipos de produtos gerenciados por sistemas PDM.

Produtos manufaturados � automóveis, computadores, refrigeradores, telefones celulares Grandes projetos de construção civil � prédios, pontes Plantas industriais � refinarias, plataformas de petróleo, indústrias farmacêuticas e alimentícias Instalações de infra-estrutura � aeroportos, portos, sistemas ferroviários, depósitos estratégicos para armazenamento Serviços � redes de distribuição para eletricidade, telecomunicações, água, gás, TV a cabo, instalações de fontes energia, e outros...

Exemplos de pessoas que se beneficiam do uso de PDM, incluem:

executivos seniores, administradores, diretores técnicos e industriais,

engenheiros-chefes, engenheiros-supervisores, gerentes (das áreas de projeto,

de produção, de CAD/CAM/CAE, de tecnologias de informação, serviços de

informação, de manutenção e operação, de marketing e de venda), funcionários

de estoque e compra, e diversos outros profissionais que manipulam grandes

quantidades de dados e informação.

Companhias de vários segmentos industriais que projetam e produzem

produtos, podem se beneficiar do uso de sistemas PDM (Ver Tabela 8).

Tabela 8. Indústrias que se beneficiam com os sistemas PDM.

Indústria aeroespacial Indústria de bebidas e alimentos Indústria automotiva: montadoras, fabricantes automotivos, fornecedores

Órgãos governamentais estaduais e federais; e outros...

Indústria de fabricação mecânica em geral Indústria de geração de energia Indústria de produtos elétricos e eletrônicos, ou ambos

Indústria de serviços: eletricidade, água, telecomunicações

Indústria de computadores Indústria de transportes Indústria de defesa e guerra Indústria de construção civil Indústria de exploração e produção de óleo e gás Escritórios de projeto e gerenciamento Indústria de processos de engenharia e química Indústria farmacêutica

55..22.. CCLLAASSSSIIFFIICCAAÇÇÃÃOO DDEE SSIISSTTEEMMAASS PPDDMM

A diversidade de opções, explica o porquê da dificuldade que é fazer um

processo de seleção e escolha de um sistema PDM. Além da funcionalidade

direta de um sistema PDM, fatores ambientais afetam a utilização e a


importância de tais sistemas. Tópicos relacionados à redes distribuídas,

arquiteturas cliente-servidor, à interface do usuário, ao gerenciamento de

banco de dados são importantes na determinação do tamanho e da

constituição de um produtivo sistema PDM.

De acordo com o artigo de (GUERRERO, 1999), os sistemas PDM podem

ser classificados por critérios funcionais e técnicos. Os critérios funcionais

dizem respeito às necessidades de informação ou processos da empresa; por

exemplo: origem do sistema, campos funcionais, e escopo de aplicação. Já os

critérios técnicos definem características computacionais do sistema, tais

como: flexibilidade, arquitetura e plataforma computacionais, tipo de base de

dados utilizada, e dados gerenciados. Na seqüência, cada um desses critérios

são brevemente comentados.

5.2.1. CRITÉRIOS FUNCIONAIS

ORIGENS DOS SISTEMAS PDM Os sistemas PDM são uma tecnologia relativamente nova, embora o

conceito tenha recebido vários disfarces, ou se modificado com várias

roupagens por um longo tempo. Os primeiros sistemas computadorizados

disponíveis foram introduzidos no início da década de 80. O surgimento de tais

sistemas é justificada pela necessidade e a oportunidade vislumbrada pelas

empresas implementadoras de sistemas CAD em desenvolver sistemas que

gerenciassem o grande volume de informações gerado. Por outro lado,

empresas que comercializavam sistemas de gerenciamento de documentos e

imagens, também identificaram esta necessidade ao verificar que seus

aplicativos não atendiam todas as necessidades do processo de

desenvolvimento de produtos.

Por conta disso, surgiu a primeira geração de sistemas PDM, os quais

eram em parte proveniente dos sistemas CAD, e outra parte proveniente dos

sistemas gerenciadores de documentos. Algumas características dos sistemas

derivados do CAD possuem como ponto forte uma estreita integração com o

aplicativo de origem, podendo dispor de funcionalidades especiais como a

geração de um protótipo ou modelo eletrônico. Em contrapartida, estes

sistemas apresentam limitações para gerenciar informações que não sejam do


CAD de origem. Já os sistemas provenientes de aplicativos EDM apresentam

vantagens relativas às funcionalidades de gerenciamento de documentos (como

cofre de dados e visualização), porém podem ser limitados quanto às

funcionalidades específicas de gerenciamento do produto. Quanto aos sistemas

originariamente PDM, estão no meio termo entre os outros dois tipos citados

anteriormente. Eles possuem características mais flexíveis, pois não enfatizam

demasiadamente, nem o gerenciamento de documentos, nem o processo de

desenvolvimento de produto.

CAMPOS FUNCIONAIS Além da funcionalidade básica, que é gerenciar documentos, alguns

sistemas possuem funcionalidades específicas para suportar o produto, a

manufatura, ou o projeto.

As funcionalidades de produto são relacionadas com as informações de

controle do processo de criação e aprovação de desenhos e componentes,

especificações do produto, sobre os processos e a qualidade do produto.

As funcionalidades de manufatura tratam com informações que dizem

respeito à produção do produto e processos de fabricação.

As funcionalidades de projeto referem-se ao gerenciamento, como controle

de prazos, controle de versões e estado do projeto.

ESCOPO DE APLICAÇÃO Uma outra classificação possível refere-se ao escopo, ou abrangência de

aplicação do sistema dentro da empresa. Um sistema PDM pode ser aplicado

numa empresa com vários departamentos, ou simplesmente executando

operações específicas num determinado setor. Estas diferentes abordagens são

reflexos das necessidades da empresa e das características do sistema.

5.2.2. CRITÉRIOS TÉCNICOS

FLEXIBILIDADE • Sistemas de alta flexibilidade: são apresentados na forma de

ferramentas de desenvolvimento que podem ser totalmente moldadas

conforme a necessidade da empresa.


• Sistemas de baixa flexibilidade: na maioria dos casos, estes sistemas

são fornecidos na forma de soluções pré-desenvolvidas e possuem

como grande vantagem a agilidade no processo de implantação.

• Sistemas de média flexibilidade: são sistemas que permitem um amplo

espectro de personalização e adaptação às necessidades da empresa,

porém restrito a alguns limites.

ARQUITETURA E PLATAFORMA COMPUTACIONAIS A arquitetura cliente-servidor é a mais usada. A arquitetura baseada na

Internet ainda é pouco utilizada, porém existe uma motivação em utilizá-la

cada vez mais.

Quanto à plataforma, a mais utilizada é a UNIX. Atualmente, as soluções

baseadas em PC e Windows NT vêm ganhando espaço no mercado. Mais

raramente, existem sistemas também operando em plataforma Macintosh.

TIPO DE BASE DE DADOS A maioria dos sistemas PDM, atualmente utilizam uma base de dados

relacional como padrão de funcionamento. Isto ocorre devido à popularização

deste conceito, e a disponibilidade de vários gerenciadores de base de dados

relacional no mercado e devido às vantagens oferecidas por esta tecnologia

como a segurança e a capacidade de organização dos dados. Além da base de

dados relacional existem alguns sistemas que utilizam base proprietária e base

de dados orientada a objetos.

A tendência atual está no crescimento do uso de bases orientadas a

objetos devido à evolução desta tecnologia e às vantagens que ela oferece em

relação à base relacional. As bases proprietárias são aquelas específicas de um

determinado produto e possuem uso restrito.

DADOS GERENCIADOS O mais comum, é que sistemas PDM gerenciam apenas arquivos. Alguns

sistemas trabalham somente com um tipo de arquivo (este é o caso da maioria

dos sistemas PDM provenientes de fornecedores de CAD), porém grande parte é

capaz de gerenciar diversos tipos de arquivos.


Alguns sistemas mais sofisticados gerenciam outros tipos de dados, tais

como: base de dados e características geométricas do produto. O

gerenciamento de informações de produto na forma de base de dados é o caso

mais raro, porém está se tornando uma necessidade cada vez maior. Por outro

lado, existem vários sistemas que trabalham com características geométricas,

especialmente aqueles que suportam protótipos eletrônicos, ou seja, a análise

eletrônica de interferência entre peças e conjuntos e subconjuntos mecânicos.

55..33.. OOSS BBEENNEEFFÍÍCCIIOOSS DDOOSS SSIISSTTEEMMAASS PPDDMM

Os sistemas PDM fornecem uma estrutura na qual todos os tipos de

informação usadas para definir, fabricar, e suportar os produtos, são

armazenados, gerenciados, e controlados. Normalmente, os sistemas PDM são

usados para trabalhar com documentos eletrônicos, arquivos digitais, e

registros de banco de dados. Conforme a Tabela 9, esses dados podem incluir:

Tabela 9. Tipos de dados gerenciados por sistemas PDM.

Diferentes configurações e versões do produto Especificações Definições de peças e outros dados de projeto Desenhos de CAD Modelos geométricos Planos de projeto; e outros... Modelos de análise e resultados Anotações de vídeo e áudio Programas de peças NC Cópias impressas e microfilmes (slides) Planos e programação de processos de fabricação

Documentos armazenados eletronicamente, notas, e correspondência;

Componentes de programas computacionais de produtos

Imagens (desenhos escaneados, fotografia, etc.)

Em suma, qualquer informação necessária em toda parte do ciclo de vida

do produto pode ser gerenciado por um sistema PDM, deixando os dados

corretos acessíveis a todas as pessoas e sistemas que tenham necessidade de

usá-los. Um sistema PDM não está limitado a gerenciar somente os ciclos de

projeto mas, de acordo com as necessidades do usuário, pode gerenciar a

concepção do produto, o projeto detalhado, prototipagem e testes, fabricação,

operação, e manutenção. O processo de desenvolvimento do produto é

gerenciado, assim como os dados. Os sistemas PDM controlam a informação do

produto, os estados, os processos de aprovação, autorização, e outras


atividades que interagem nos dados do produto. Proporcionando o

gerenciamento dos dados e a segurança, os sistemas PDM garantem que

usuários sempre acessem e compartilhem a informação atualizada e aprovada.

Os sistemas PDM proporcionam um significativo ganho de produtividade

quando eles são usados por um grupo ou equipe de trabalho. Todavia, um

impacto muito maior é sentido, ou fica mais evidente, quando eles são

aplicados a uma organização empresarial e industrial de grande porte.

Os sistemas PDM proporcionam benefícios em todas as disciplinas e áreas

do projeto e desenvolvimento do produto. Quase todas as pessoas numa

organização podem se beneficiar do uso desta tecnologia.

A conexão entre os dados do produto e um banco de dados é o principal

fator da garantia de sua integridade. Conhecendo e gerenciando quem está

usando os dados, e como; fornece a base necessária para manter a integridade

da informação. A inconsistência dos dados pode ser evitada, e o

relacionamento entre os dados é mantido.

Devido à sua aplicação num amplo conjunto de usuários e áreas, e à sua

facilidade para controlar o fluxo de informações, os sistemas PDM servem como

instrumentos para implementar as práticas da Engenharia Simultânea. Os

benefícios advindos da implementação da Engenharia Simultânea vão além da

engenharia de projeto, propagando-se para economia de custos de fabricação,

redução do tempo de lançamento de novos produtos no mercado e aumento da

qualidade do produto, além dos benefícios de redução do tempo de projeto de

engenharia.

As mudanças nos produtos são inevitáveis, mas elas podem tornar-se

excessivamente caras e descontínuas se ocorrem muito tarde dentro do ciclo de

vida do produto, tais como na produção ou fabricação, ou mais tarde ainda.

As mudanças poderiam ocorrer bem mais cedo no ciclo de vida do produto

se as equipes de projeto fossem encorajadas a compartilhar dados e

documentos num ambiente suportado por um sistema PDM. Este é o caminho

para melhores produtos, custos reduzidos, economia de tempo, menos sobras e

menos reprojetos.


55..44.. CCAARRAACCTTEERRÍÍSSTTIICCAASS EE FFUUNNÇÇÕÕEESS DDEE UUMM SSIISSTTEEMMAA PPDDMM

Para sistema PDM suportar qualquer tipo particular de desenvolvimento

do produto, ele necessita de um conjunto básico de funções. Estas funções

servem todas as áreas que se beneficiam dos PDM�s. Uma visão funcional de

um sistema PDM é mostrada na Figura 28.

Figura 28. Visão funcional dos sistemas PDM (CIMDATA, 1999).

Os sistemas PDM são constituídos por:

• Um repositório de dados

Um cofre eletrônico de dados é usado como um repositório para controlar

todos os tipos de informação do produto. O cofre é um armazém de dados que

contém alguns dados dentro deles mesmos, e controla outros dados gerados

externamente pelo gerenciamento do acesso a eles. Dois tipos de dados estão

armazenados:

• Dados de produto gerados em várias aplicações: especificações,

modelos de CAD/CAE/CAM, registros de manutenção, e manuais de

operação.

• Meta-dados: são os dados a respeito da informação armazenada pelo

sistema PDM. Meta-dados estão armazenados em bancos de dados

PDM, e suportam as funções realizadas pelo sistema PDM.

• Um conjunto de funções para o usuário A funcionalidade de um sistema PDM se resume a duas grandes

categorias: funções do usuário e funções utilitárias. As funções do usuário

Usuários de AplicaçãoCAD/CAM, NC, Compra,

Documentação, etc.

Usuários PDMMúltiplas aplicações

Sistema PDMBanco de meta-dados Arquivos gerenciados

dados dados

controle

dados

Arquivos particulares


fornecem a interface do usuário para os recursos do sistema PDM, incluindo o

armazenamento, a recuperação, e o gerenciamento de dados. Diferentes tipos

de usuários usam diferentes subconjuntos das funções do usuário. Estas

funções são divididas em cinco categorias:

• Cofre de dados e gerenciamento de documentos;

• Gerenciamento do processo e do fluxo de dados;

• Gerenciamento da estrutura do produto;

• Classificação;

• Gerenciamento da programação.

• Um conjunto de funções utilitárias As funções utilitárias fornecem suporte que facilitam o uso de sistemas e

fornecem suporte às funções do usuário mencionadas acima. As funções

utilitárias fazem a interface com o ambiente operacional e isolam as suas

funções do usuário. A personalização permite ao sistema operar de acordo com

o ambiente do usuário. As funções utilitárias incluem:

• Recursos de comunicação e notificação;

• Transporte de dados;

• Conversão e tradução de dados;

• Serviços de imagem;

• Administração do sistema.

Dados de outras aplicações computacionais são controlados pelas regras

de acesso e salvamento de arquivos no sistema PDM. Isto é conseguido de

duas maneiras:

• Adicionando comandos PDM noutras aplicações que criam dados, tais

como CAD, processadores de texto, planilhas de cálculo, programas de

editoração, ou outras aplicações especializadas;

• Adicionando comandos de outras aplicações em sistemas PDM.

Alguns documentos, tais como desenhos em papel, cartões perfurados,

películas de microfilmes, ou outros tipos de cópias físicas, podem ser

capturados, como imagens dentro de repositórios eletrônicos, através de


escaneamento. Alguns usuários preferem converter imagens de documentos

textuais através de reconhecimento óptico de caracteres (OCR � Optical

Character Recognition) em textos legíveis pelo computador. É possível converter

algumas imagens de desenhos rasterizados em dados vetoriais, via um

software; embora outros usuários prefiram capturar dados vetoriais através de

técnicas de digitalização.

5.4.1. AS FUNÇÕES DO USUÁRIO

COFRE DE DADOS E GERENCIAMENTO DE DOCUMENTOS A principal preocupação de muitas companhias é a garantia de que o dado

do produto seja atualizado corretamente, e esteja protegido contra acidentais e

eventuais danos e inconsistências. O cofre de dados e o gerenciamento de

documentos fornece um armazenamento seguro e a recuperação das

informações de definição do produto. As funções de verificação de entradas e

saídas (check-in e check-out, respectivamente) trabalham com dados

armazenados num cofre eletrônico para fornecer um armazenamento seguro e

controle de acesso aos dados. Níveis de versões dos dados de projeto são

definidos, e para os usuários são definidas autorizações de acesso.

O cofre de dados contêm ou os dados ou a informação que aponta para a

localização dos dados. Dados controlados por sistemas PDM não podem ser

acessados sem passar pelos procedimentos de controle do sistema. A

localização exata dos dados é escondida dos usuários, das aplicações, e do

sistema operacional.

O gerenciamento das versões assegura que os dados atinjam os status de

versões somente após a passagem de processos de aprovação predefinidos.

Vários cenários de aprovação podem ser definidos. O acesso de usuários à

informações atende a critérios de controle definidos pelo usuário, os quais

estão baseados no projeto, na senha, etc..

Os meta-dados armazenam informações a respeito dos dados do produto,

de forma que alterações, níveis de versões, autorizações de aprovação, e outros

controles de dados possam ser trilhados e auditados. Os meta-dados também

são usados para criar relacionamentos entre dados do produto, de forma que a

informação possa ser agrupada e relacionada pelo tipo de aplicação ou uso do


produto, e entre tipos de produtos. Dados de definição do produto podem estar

associados com diferentes configurações do produto, bem como, com peças que

compõem o produto.

Alguns dados que estejam armazenados em desenhos impressos,

documentos armazenados sob sistemas remotos, podem ser controlados por

referência. É lógico, que desta forma, o nível de segurança é inferior ao de

quando os arquivos estão armazenados no cofre de dados. Mesmo assim, este

nível de segurança ainda é melhor que o verificado em sistemas não

automatizados, e a trilha dos dados é facilitada.

GERENCIAMENTO DO PROCESSO E DO FLUXO DE DADOS Usando cofre de dados e gerenciamento do produto sozinhos, um sistema

PDM pode reagir a demandas posteriores. Com gerenciamento do processo e

fluxo de dados, um sistema PDM pode interagir com pessoas, trabalhando de

acordo com processos predefinidos de uma organização, e dados e documentos,

para atingir objetivos corporativos. Processos repetitivos podem ser

programados dentro do sistema PDM, e ele pode mapear um modelo da

organização. O gerenciamento do processo e do fluxo de dados fornece uma

rota para dirigir um negócio com informação.

O gerenciamento do processo e do fluxo de dados pode definir e controlar

mudanças da configuração do produto, de definições de peças, de outros dados

do produto, de relacionamentos de dados, de versões de dados, e de variações.

O gerenciamento do processo e do fluxo de dados pode definir e controlar os

processos de revisão e aprovação de mudanças nos dados do produto. Os

fluxos de trabalho e processos são definidos em termos de seqüências de

eventos que devem ocorrer antes que dados modificados do produto sejam

considerados como uma nova versão.

Pessoas que estão autorizadas a aprovar mudanças em informações

particulares do projeto são identificadas dentro do sistema PDM. O sistema

trilha e gerencia o processo de aprovação.

Quando mudanças nos dados do produto são conduzidas a uma

aprovação, um fluxo de trabalho ou um processo específicos podem ser

automaticamente disparados. Os aprovadores para a informação específica,


são notificados automaticamente pelo sistema PDM de que mudanças foram

feitas, e que estão esperando por uma aprovação.

Quando a mudança é processada, a aprovação ou reprovação é indicada

eletronicamente. Depois de todos os passos no processo de aprovação terem

sido completados com sucesso, os dados do produto aprovado são colocados

num nível seguinte de uma nova versão, e armazenados no cofre de dados. Os

dados do produto seguem com sucesso pelo processo de fluxo de trabalho

definido. Outros usuários são notificados de que a versão dos dados foi

incrementada.

Os fluxos de trabalho podem automaticamente enviar, pastas de dados

eletrônicos ou pacotes de trabalho, para revisores. Isto pode se dar de forma

serial ou simultânea. O fluxo de trabalho pode monitorar processos, assegurar

que processos acabem antes que outros comecem, e podem fornecer relatórios

de gerenciamento.

Os sistemas PDM registram cada passo dentro de um processo. Usuários

e gerentes podem revisar toda a histórias das mudanças a qualquer hora,

quando assim desejarem.

GERENCIAMENTO DA ESTRUTURA DO PRODUTO O Gerenciamento da estrutura do produto facilita a criação e o

gerenciamento de configurações do produto e de listas de materiais (BOM �

Bills of Material). Estruturas típicas de produtos podem conter atributos,

instâncias, e informação da localização em adição a dados de listas de

materiais. Estes dados melhoram o valor da estrutura para atividades externas

ao planejamento da fabricação. Listas de materiais padronizadas podem ser

geradas automaticamente a partir da estrutura do produto.

Sistemas PDM permitem que usuários e aplicações relacionem ou

associem dados de definição de produtos, tais como desenhos, documentos, e

planejamentos de processos à estruturas de peças e produtos. Isto permite que

usuários facilmente determinem qual informação deverá ser afetada em

eventuais alterações.

É possível percorrer toda a estrutura do produto, e isto facilita o projeto,

construção, operação, e manutenção. O gerenciamento da estrutura do


produto vasculha componentes físicos e conexões, ou objetos virtuais tais como

sistemas de resfriamento ou um procedimento de emergência.

Diferentes setores exigem visões especializadas sobre as informações do

produto. Os sistemas PDM permitem mostrar o relacionamento estrutural, de

processos de fabricação, da documentação, das finanças, do suporte e

assistência técnica, e outros relacionamentos embutidos nos dados de

definição do produto.

Os dados para processos e planejamento da fabricação estão disponíveis

em ambientes PDM, e podem ser transferidos para sistemas MRP. Os sistemas

PDM possibilitam o controle e o acompanhamento destes dados, exatamente

como faz para outros dados do produto. Os sistemas MRP mantêm e controlam

informações vitais sobre a produção do produto. Esta informação pode ser

transferida em sistemas PDM, fornecendo importantes dados para o ciclo de

desenvolvimento do produto.

CLASSIFICAÇÃO A classificação permite que peças similares ou padronizadas, processos, e

outras informações de projeto possam ser agrupadas por atributos comuns e

recuperadas para uso em produtos. Isto conduz a uma maior padronização,

reprojeto reduzido, economia em compras e fabricação, e estoques reduzidos.

As funções de classificação dos sistemas PDM fornecem recursos muito

mais eficientes de procura de peças similares ou padronizadas, do que os

recursos encontrados em catálogos e outros sistemas manuais. Quando

engenheiros e projetistas são capazes de encontrar peças similares ou

padronizadas facilmente, eles provavelmente as reusam ao invés de projetar

partindo do nada ou de rascunhos.

As peças podem ser agrupadas e encontradas por vários atributos, tais

como: códigos funcionais da peça; classificação da forma, material, data de

possíveis versões da peça, revisão, projetista, nome do projeto, proprietário,

data de criação, etc. Estes e outros atributos podem estar associados a dados

do produto que têm relação com as peças.

Peças e projetos que correspondem a atributos específicos, faixas de

valores, e combinações lógicas de atributos, podem ser recuperados. Isto


permite que os usuários facilmente obtenham dados de produtos, que sejam

idênticos ou similares ao do projeto requerido.

Figura 29. Classificação hierárquica de peças padronizadas

A classificação e recuperação de peças e outros objetos, pode ser facilitada

pelo desenvolvimento e gerenciamento de estruturas de classificação. Para

peças, estas podem ser hierarquias de famílias de peças. Um exemplo, é

mostrado na Figura 29, onde diferentes parafusos são peças de uma família de

parafusos, a qual é parte de uma família de prendedores ou fixadores. Pelo

desenvolvimento e gerenciamento desta hierarquia de famílias de peças, com

características definindo cada classe de família, os usuários encontram peças

apropriadas realizando pesquisas de acordo com as características desejadas.

Para fazer uso das potencialidades de gerenciamento de famílias de peças,

uma companhia deve ter uma definição da hierarquia de famílias de peças que

melhor se encaixe nas necessidades da companhia e nas suas operações.

Algumas normas de padronização, tais como ISO e DIN, auxiliam a definir

famílias de peças e os seus relacionamentos.

Bibliotecas de peças, tais como fixadores, componentes eletrônicos,

componente tubulares, ou materiais de construção estão disponíveis, e podem

ser acessados via mecanismos similares, através de sistemas PDM.

� Fixadores/Prendedores

� Parafusos

� Parafuso de cabeça arredondada com fenda

� Parafuso de cabeça plana com fenda

� Parafuso de cabeça sextavada com fenda

� Parafuso �Allen�

� Parafuso �Phillips�

� Rebites

� Arruelas

� Porcas


GERENCIAMENTO DA PROGRAMAÇÃO O gerenciamento da programação fornecem estruturas WBS � Work

Breakdown Structures, as quais são usadas para controlar o andamento dos

projetos. Estas estruturas permitem particionar as atividades para com isso

fazer a alocação de recursos, financiamentos, programação, etc. Recursos e

dados gerenciados estão associados para proporcionar um nível melhorado de

planejamento e acompanhamento do projeto. Estas potencialidades são

freqüentemente conseguidas através de uma ligação com outros sistemas de

gerenciamento de projeto de outros fornecedores. A vantagem principal surge

da habilidade em relacionar as WBS aos ciclos de procedimentos de aprovação

e configurações de produtos de sistemas PDM.

As tarefas requeridas para completar a programação do produto estão

ordenadas dentro da estrutura WBS tal que os recursos e o projeto podem ser

monitorados. Quando o projeto progride tarefa a tarefa, os recursos gastos são

registrados. A finalização dos dados requeridos de cada atividade é registrada

por processos de aprovação.

5.4.2. AS FUNÇÕES UTILITÁRIAS

RECURSOS DE COMUNICAÇÃO E NOTIFICAÇÃO Projetistas e outros participantes do projeto são informados sobre o estado

atual, através de notificações e alertas automáticos, e podem com isso ser

informados de quando uma certa informação está ou não disponível para dar

continuidade às atividades. Além do mais, com a certeza de ter a informação

mais atualizada.

O mecanismo de notificação pode utilizar recursos de correios eletrônicos

para informar sobre eventos importantes ou ações requeridas. Os atrasos e

comunicação erradas são minimizadas. Este mecanismo pode também ser

usado para delegar atividades quando um usuário está impossibilitado de

completar uma determinada tarefa.

Um mecanismo de software, conhecido como �gatilho�, é usado para

espalhar as notificações e outras ações automaticamente. Quase todo evento

num processo de desenvolvimento de produto pode provocar uma mensagem a

ser enviada ou causar um outro evento. Estes gatilhos são usados para


ordenar o cofre de dados e o gerenciamento de documentos, o fluxo de

trabalho, e os procedimentos de gerenciamento dos processos.

TRANSPORTE DE DADOS Todos os dados são armazenados e acessados sob o controle de sistemas

PDM, assim um usuário não necessita saber onde os dados estão armazenados

dentro de uma rede de computadores. O sistema mantém a trilha da

localização dos dados, e permite usuários acessá-los somente sabendo o nome

dos dados. O nome dos dados não são limitados pelas convenções de nomes

dos sistemas operacionais, assim eles podem receber nomes sugestivos e

significativos sobre os dados armazenados. O usuário também fica livre de

saber utilizar comandos específicos do sistema operacional para poder

manipular os arquivos.

A movimentação dos dados de uma localização para outra, ou de uma

aplicação para outra, é uma operação que os sistemas PDM realizam, e mais

uma vez os usuários não necessitam se preocupar com comandos específicos

do sistema operacional ou outros comandos de rede.

CONVERSÃO E TRADUÇÃO DE DADOS O administrador do sistema pode predefinir alguns tradutores de dados a

serem usados para converter dados entre pares de aplicações, e formatá-los

para vários dispositivos de exibição ou impressão. Isto reforça a forma de

padronização dos dados. Embora os tradutores não sejam parte integral dos

sistemas PDM, eles podem ser aplicados porque o sistema conhece o formato

dos dados de cada arquivo controlado, e qual tradutor é apropriado.

Os �gatilhos� podem disparar a tradução de dados automaticamente de

uma aplicação para outra, quantas vezes forem necessárias. Assim, tem-se a

garantia de utilização dos dados corretos em qualquer situação controlada pelo

sistema PDM.

SERVIÇOS DE IMAGEM Imagens de vídeo, �raster�, ou vetorial, são tratadas da mesma forma que

os dados pelos sistemas PDM. O acesso em rede permite uma distribuição da

informação do produto numa maneira estruturada para muitos usuários.


A visualização de imagens permitem que usuários, tais como gerentes e

trabalhadores de chão-de-fábrica, visualizar desenhos e outros dados de

projeto em PC�s ou terminais, fornecendo acesso a uma ampla audiência. Os

recursos de marcação e anotação permite que verificadores, revisores, e

aprovadores adicionem comentários e anotações para imagens �raster�.

Os serviços de imagens aceleram processos, tais como ECR (Engineering

Change Requests) e ECO (Engineering Change Orders), facilitando a troca de

informação e comentários entre os usuários.

ADMINISTRAÇÃO DO SISTEMA. O administrador ajusta os parâmetros do sistema PDM e monitora sua

performance. As funções de administração incluem:

• Permissões de acesso e de

alterações;

• Autorizações;

• Procedimentos de aprovação;

• Cópia de dados e segurança;

• Arquivos de dados.

A personalização do sistema permite que pessoas trabalhem conforme

procedimentos normativos, e melhorem a eficiência das operações de usuários.

A interface do usuário e algumas características operacionais do sistema PDM

também podem ser personalizadas. Por exemplo, um processo de aprovação

pode exigir uma seqüência de aprovação de várias pessoas, ou exigir uma

maioria de aprovação em outros. Os sistemas podem ser personalizados de

várias formas, incluindo:

• Leiaute da interface do

usuário;

• Integração com aplicações;

• Modificação de mensagens do

sistema e a terminologia;

• Adição de novas funcionalidades.

Muitos sistemas fornecem padrões, interfaces para aplicações populares

tais como CAD, CAM, MRP/ERP (Enterprise Requirements Planning), publicação

técnica, e automação de escritórios. Além disso, muitos sistemas oferecem

pacotes de interface, bibliotecas de interfaces do tipo GUI (Graphical User

Interface).


TTééccnniiccaass ee MMeettooddoollooggiiaass MMooddeerrnnaass ppaarraa TTrrooccaa ddee

DDaaddooss eemm CCAADD//CCAAMM


Não apenas a metodologia de trabalho, mas sobretudo as ferramentas

utilizadas, influenciam a concepção e o resultado final de um produto. Na

sociedade moderna, a utilização dos computadores como meio de expressão,

geração e manipulação da informação, é imprescindível. No contexto do

CAD/CAM, surge a necessidade pela troca de dados e compartilhamento de

informação nas atividades de desenvolvimento do produto. Outro fato que

evidencia esta necessidade é o modelo de trabalho atual caracterizado como

sendo: corporativo, integrado, simultâneo, e globalizado. Portanto, o modelo de

representação e a arquitetura computacional dos sistemas deve considerar

todos os aspectos da indústria e da equipe envolvida com as atividades do

processo de desenvolvimento do produto. Os recursos disponíveis devem

favorecer o fluxo de atividades para que transcorra de forma integrada e

CAP.6 � TÉCNICAS E METODOLOGIAS MODERNAS PARA TROCA DE DADOS EM CAD/CAM 81

simultânea; além de estar adaptado ao mercado globalizado, com recursos de

redes computacionais (Internet, Intranet). Os meios para atingir este objetivo,

são fornecidos pela aplicação de técnicas de Inteligência Artificial, sistemas de

informação, por métodos mais avançados de modelagem do produto e também

pela adoção de formatos de arquivo padrão para troca de dados.

Os sistemas baseados em modelos do produto, adotam diversas

arquiteturas computacionais, que fornecem diferentes métodos e tecnologias

integradas para assistir o projeto, permitindo modelar tanto o produto, como

também os processos de produção e fabricação e o domínio da aplicação em si.

(KRAUSE et al., 1993) e (MCMAHON e BROWNE, 1998) discutem o

relacionamento entre os diversos modelos aplicados ao produto mostrados na

Figura 30, e que constituem o seu ciclo de vida.

Figura 30. Relacionamento entre modelos do ciclo de vida do produto (Baseado em MCMAHON e BROWNE, 1998).

Conforme mostra a figura, os modelos do ciclo de vida do produto podem

ser agrupados em quatro categorias:

Modelo deFábrica

Modelo deAplicação

Modelo deProcesso

Modelo deProduto

Modelode

Estoque

Modelo deLeiaute da

FábricaModelo de

Planejamento

Modelo deEquipamento

Modelo deCálculos

ModeloOperacional

Modelo deTrajetórias

daFerramenta

Experiência eConhecimentoda Aplicação

ModeloFuncional

ModeloSólido


• Modelos do Produto: constituído pelos sub-modelos funcional, sólido, e

de cálculo;

• Modelos de Processo: constituído pelos sub-modelos de trajetórias da

ferramenta, e operacional;

• Modelos de Aplicação: constituído pelos sub-modelos de conhecimento

da aplicação, e outros;

• Modelos de Fábrica: constituído pelos sub-modelos de estoque, leiaute

de fábrica, planejamento, e equipamento.

Cada modelo preocupa-se em representar informações próprias do seu

escopo. Por exemplo, o Modelo de Fábrica se preocupa como a fábrica e os

processos envolvidos vão se modificando à medida que o produto toma forma

dentro da produção. Modelos baseados em features de fabricação exercem um

papel importante para o Modelo de Fábrica do produto, pois refletem o

compromisso da fábrica em produzir certas formas especificadas na definição

da feature.

Neste trabalho, algumas propostas serão comentadas e discutidas, dando

especial atenção em aplicações relacionadas à troca e ao compartilhamento de

dados e informações úteis às atividades de desenvolvimento do produto. Os

pontos principais serão os novos avanços na modelagem do produto e no

suporte computacional para o trabalho cooperativo.

66..22.. QQUUAADDRROO AATTUUAALL DDOOSS SSIISSTTEEMMAASS CCAADD//CCAAMM

Atualmente, os sistemas CAD/CAM estão amplamente difundidos no meio

industrial como um todo e suas aplicações são abrangentes quanto ao domínio

de atuação.

É sabido que as técnicas e metodologias de modelagem geométrica estão

bem avançadas. Com um certo grau de satisfação, elas auxiliam na criação de

formas e manipulação de dimensões. Todavia, existem várias limitações nos

sistemas CAD/CAM quando aplicados na modelagem de um produto. Por

exemplo, algumas propriedades de importância significativa para a modelagem

de aspectos tecnológicos, tais como: tolerâncias, lista de materiais, condições


superficiais e funcionais; carecem de representações mais adequadas. Estas

propriedades, ainda não estão colocadas numa representação computacional

otimizada para auxiliar o projetista. Percebe-se que os sistemas CAD/CAM em

geral, concentram-se demasiadamente em representar e capturar somente

atributos e relações geométricas (MCMAHON e BROWNE, 1998).

Portanto, a despeito do sucesso, é também consenso que os sistemas

CAD, em geral, ainda não são uma ferramenta totalmente acabada e perfeita

para suporte ao projetista durante a fase de ideação do projeto. Essa afirmação

também pode ser estendida para todas as fases do desenvolvimento de

produto, no que se refere aos demais sistemas (CAM, CAPP, CAFD �Computer-

Aided Fixture Design, CAX�s) de auxílio aos projetistas. Atualmente, exige-se de

tais sistemas, uma abrangência corporativa e integrada, a qual não fique

apenas centrada e isolada num setor específico, mas que englobe todo o

desenvolvimento de um produto.

O desafio da nova geração de sistemas CAD é representar no computador,

uma variedade maior de propriedades e atributos de projeto, que sejam

familiares aos projetistas e que manipule aspectos da prática da engenharia,

da organização de empresas e gerenciamento de equipamentos e recursos, os

quais influenciam em decisões tomadas na fase de projeto. Os pesquisadores

têm focado a atenção e esforço no desenvolvimento de ferramentas e técnicas

que são hábeis a suportar as várias fases de projeto. Inicialmente, o esforço

concentrou-se em fornecer suporte para o projeto detalhado; e mais

recentemente, a atenção tem se voltado para o projeto conceitual.

Neste trabalho, algumas das novas propostas serão comentadas, dando

especial atenção na aplicação voltada à troca e compartilhamento de dados e

informações úteis às atividades de desenvolvimento do produto. Os pontos

principais serão os novos avanços na modelagem do produto, e no suporte

computacional para o trabalho cooperativo.

66..33.. MMOODDEELLAAGGEEMM EE RREEPPRREESSEENNTTAAÇÇÃÃOO DDOO CCOONNHHEECCIIMMEENNTTOO

Devido à complexidade natural da atividade de projeto e à variedade de

produtos mecânicos, as novas propostas de metodologias, técnicas e


ferramentas para tratar a questão do projeto são apenas variações de

melhoramentos de outras técnicas já existentes. As mudanças são sutis e se

concentram basicamente em melhorar as representações do pensamento

através de novas estruturas de dados mais adequadas à captura das intenções

do projetista, ou através da mudança de estratégias e forma de aplicação de

conceitos2.

Na descrição de um produto mecânico, é necessário representar diferentes

aspectos da função, do comportamento, e da estrutura do produto. A função

representa a utilização do produto pelo usuário. O comportamento é a

seqüência dos estados pelos quais o produto passa para conseguir realizar sua

função. A estrutura refere-se aos componentes físicos ou formas utilizadas

para obter o comportamento do produto. Tendo representado os vários

aspectos do produto mecânico, é necessário ser capaz de entender as

interações entre estes aspectos, de forma que seja possível gerar e selecionar

algumas soluções de projeto.

A necessidade de modelagem do produto foi estimulada pela demanda

crescente por produtos de alta qualidade e baixos custos, e pela diminuição do

tempo de lançamento (lead-time) do produto no mercado. Por conta dessa

demanda, surgiram diversas estratégias para suportar o desenvolvimento do

produto: "Fabricação Integrada por Computador" (CIM), Produção Enxuta (Lean

Production), Engenharia Simultânea, Fábrica Fractal e Fabricação Virtual.

Embora cada uma dessas estratégias tenham o seu particular interesse, um

foco comum é a necessidade por informações tecnológicas avançadas, a fim de

aplicá-las na integração e coordenação das questões referentes ao ciclo de vida

do produto nas fases do seu desenvolvimento.

De acordo com (HSU e WOON, 1998), para suportar as atividades de

projeto num nível conceitual, é necessário resolver duas dificuldades inerentes:

i. A modelagem do problema, referindo-se à modelagem da complexidade

de interações entre os diferentes contextos e aspectos do produto;

ii. A representação do raciocínio, ou da intenção do projetista a respeito

da geração e seleção de soluções viáveis para o problema.

2 "Si non nova, saltem nove" � "Se não forem coisas novas, que sejam de uma nova forma." Adágio Popular


No texto que segue, comenta-se sobre vantagens e desvantagens de

algumas técnicas aplicadas à representação e à modelagem da troca e do

compartilhamento de dados e informações dentro do processo de projeto com

aplicação de sistemas computacionais, em especial os sistemas CAD/CAM.

66..44.. TTÉÉCCNNIICCAASS DDEE MMOODDEELLAAGGEEMM EE RREEPPRREESSEENNTTAAÇÇÃÃOO

As representações para modelagem variam desde as que são orientadas ao

computador, até aquelas orientadas ao usuário, conforme é mostrado na

Figura 31.

Figura 31. Espectro das representações de modelagem em projeto (Baseado em HSU e WOON, 1998)

As técnicas orientadas ao computador são aquelas cujo objetivo é garantir

que o raciocínio computacional possa ser suportado eficientemente. Por outro

lado, as técnicas orientadas ao usuário concentram-se em fornecer ambientes

de modelagem que auxiliem a criatividade do projetista.

6.4.1. LINGUAGENS As linguagens representam uma alternativa de formalização do projeto,

representando-o de forma única, sem ambigüidades. Devido à representação

compacta, as linguagens gramaticais são um meio eficiente de estruturação do

conhecimento de projeto. Elas têm sido usadas para descrever os aspectos

funcionais, comportamentais, e estruturais do produto.

Uma outra estratégia tem sido o desenvolvimento de uma ontologia de

projeto compartilhada. Uma ontologia é um conjunto útil de termos e conceitos

LinguagensModelos Geométricos

Grafos

�

�

Objetos

Modelos de Conhecimento

Imagens

Técnicas orientadasao computador

Técnicas orientadasao usuário


gerais o suficiente para descrever diferentes tipos de conhecimento em

diferentes domínios, mas que também são detalhados o suficiente para serem

aplicados a problemas específicos.

A análise ontológica é um processo de descoberta que conduz ao melhor

entendimento de um domínio. As idéias da análise ontológica são úteis para:

identificação de problemas (diagnóstico); identificação das causas do problema

(análise causal); identificação de soluções alternativas (criatividade e projeto);

consenso e formação de equipes de trabalho; e compartilhamento e reutilização

de informação.

Os benefícios derivados da definição de uma ontologia são: fornecer uma

base para o desenvolvimento de sistemas de informação mais inteligentes e

integrados; poder ser usada como modelos de referência para o planejamento,

coordenação, e controle de atividades de desenvolvimento de produto/processo

complexos; fornecer indícios para identificação de áreas que necessitam de

uma reestruturação organizacional, e sugerir potenciais meios para realizar

mudanças de alto impacto.

A análise e o desenvolvimento de uma ontologia tem se mostrado útil

para: formação de um consenso; projeto e programação orientada a objeto;

programação baseada em componente; projeto de interface para usuários;

modelagem de informação para ; reengenharia de processos comerciais; e

projeto de esquemas conceituais.

A definição de uma ontologia consistente nos processos de troca e

compartilhamento de dados e informações dentro dos sistemas CAD/CAM,

serviria para compartilhar e reusar o conhecimento, e favoreceria uma melhor

integração entre as diferentes fases do ciclo de vida do produto.

6.4.2. MODELOS GEOMÉTRICOS A modelagem geométrica por sólidos concentra-se na representação dos

aspectos estruturais do produto. As representações mais comuns da geometria

das formas são: B-Rep, CSG, geometria paramétrica e/ou variacional, e

features. Estas técnicas são brevemente descritas abaixo.

A B-Rep representa a geometria em termos das relações topológicas do

sólido, tais como vértices, arestas, ciclos e faces. Por ser uma proposta de


modelagem de sólidos, ela já captura bem mais informações do que os modelos

de padrões gráficos e estruturas de arame (wireframe). Essa técnica quando

aplicada sozinha, é insuficiente para fazer reconhecimento de features, que é

um recurso computacional de suporte à atividade de projeto e demais

atividades do ciclo de vida do produto. Outra técnica de modelagem de sólidos,

a CSG, representa a geometria a partir de operações booleanas e de

transformações geométricas realizadas sobre um conjunto de sólidos básicos,

denominados de primitivas.

As técnicas de modelagem paramétrica e variacional, são duas outras

alternativas para modelos baseados na geometria. Do ponto-de-vista do

usuário final, ambas as técnicas possibilitam descrever atributos geométricos

utilizando-se de valores dimensionais, como de relações entre os valores de

dimensões parametrizadas do modelo. As diferenças na aplicação de uma ou

de outra destas propostas é sutil, e às vezes elas assumem configurações

híbridas. Portanto, faz-se necessário um estudo mais minucioso para

identificar num modelo geométrico particular, qual técnica está sendo adotada.

Mais detalhes sobre fundamentos e diretrizes gerais destas duas propostas

podem ser consultados no livros de (MCMAHON e BROWNE, 1998) e (SHAH e

MÄNTYLÄ, 1995).

O importante aqui é enfatizar que estas técnicas dão mais um passo na

melhoria dos modelos geométricos aplicados nos sistemas CAD/CAM

modernos, de forma a capturar mais informação da intenção do projetista

durante o processo de concepção ou ideação. E atualmente, todas elas estão

sendo usadas juntas para tentar enriquecer a estrutura de dados com base em

features, usando o que cada uma tem de mais vantajoso.

6.4.3. PROJETO BASEADO EM FEATURES A metodologia de projeto baseado em features tenta solucionar essas

deficiências dos sistemas CAD atuais. Os novos sistemas CAD, utilizam o

conceito de feature para encapsular dados geométricos ou não, dentro das

especificidades da aplicação. Isso deve ser tal que, uma mesma peça possa

enfatizar somente atributos que forem relevantes, quando ela for aplicada a

diferentes aplicações.


Vista como na Equação (6.1), a geometria representa a parcela física,

independente, exata e quantitativa do modelo de dados, enquanto a semântica

representa a parcela abstrata, dependente de contexto e qualitativa.

SemânticaGeometriaFeature ∪⇔ (6.1)

Segundo (SHAH e MÄNTYLA, 1995), pode-se tirar duas conclusões:

• Features são estruturas de conhecimento estereotipadas embutidas em

processos cognitivos de projeto, análise, planejamento, e todas as

outras atividades de Engenharia.

• Features são dependentes do ponto de vista e da aplicação.

Sabe-se que a integração CAD/CAM exige que as características do projeto

e da fabricação do produto devem ser extraídas e interpretadas

automaticamente de um modelo de CAD, sem a intervenção humana (FUH et

al., 1996). Portanto, um ambiente de multi-modelagem partindo do projeto de

produtos e sistemas, exige que diferentes visões destes sejam recuperadas ao

longo do processo de criação e produção. Ao mesmo tempo, deve prover que a

troca de informações ocorra facilmente ao longo de todo o desenvolvimento.

6.4.4. IMAGENS Talvez, o mais próximo da forma de pensamento e raciocínio do humano

seja os modelos visuais. Recursos de rascunho à mão livre são uma boa forma

para aceleração de discussões e para comparação com diferentes soluções.

Desenhos à mão livre são uma bons para permitir diferentes visões de uma

idéia, e obter uma boa imagem espacial da solução de projeto.

Alguns pesquisadores citados por (HSU e WOON, 1998), contribuíram com

trabalhos nesta área: Em 1990, Radcliffe e Lee propuseram um modelo para o

processo de pensamento visual que evita a barreira entre a definição dos

processos cognitivos e o domínio físico; e em 1991, Sittas pesquisou sobre o

desenho à mão livre de formas tridimensionais durante as atividades de projeto

conceitual.

(NARDELLI, 1999), relata que em 1991, Laseau afirmou que o potencial da

criatividade no projeto está no contínuo fluxo de informação que flui do


desenho no papel para os olhos, para o cérebro, para as mãos e, novamente

para o desenho. Para Laseau, quanto mais vezes a informação passar por esse

ciclo, maiores serão as chances de iteração criativa. De acordo com Piaget, a

percepção é essencial no processo de conhecimento, mas também depende da

ação como um todo. Desse modo, certos mecanismos perceptivos que poderiam

ser supostos como inatos, na realidade só se materializam a partir de um dado

nível da construção dos objetos.

O reconhecimento de padrões de geometria nos sistemas CAD atuais é

muito restrito. Normalmente, os recursos se limitam à formas bidimensionais e

regulares. Além disso, os elementos geométricos reconhecidos são primitivos,

tais como pontos, linhas. O reconhecimento de curvas NURBS, ou de

convenções simbólicas que possuem uma semântica própria, (por exemplo,

acabamento superficial), ainda não estão de todo resolvidos, sendo que existem

apenas soluções particulares e dedicadas de alguns desenvolvedores de

programas CAD.

6.4.5. GRAFOS Grafos e árvores são representações populares no estágio de projeto

conceitual. Eles têm sido usados para modelar todos os aspectos do produto:

função, comportamento, e estrutura. Alem desses aspectos, os grafos também

podem ser usados para modelagem de restrições e requisitos.

Uma das principais vantagens dos grafos é que a teoria sobre este tipo de

estrutura está bem fundamentada na Matemática, e já existem muitos

trabalhos desenvolvidos com implementações de algoritmos otimizados para

manipulação dessas estruturas de dados.

6.4.6. INTELIGÊNCIA ARTIFICIAL APLICADA AO PROJETO A inteligência artificial (AI � Artificial Intelligence) é o campo que tenta

fazer com que computadores realizem tarefas que normalmente exigiriam a

inteligência humana. Alguns pesquisadores de AI, atualmente estão

interessados em modelar o processo de projeto. Os modelos da atividade de

projeto são propostos com base em estudos de Psicologia Cognitiva,

Lingüística, bem como em AI. Em resumo, estes modelos tendem a apresentar


a atividade de projeto como uma série de transformações governadas por

regras e relacionamentos das soluções com os requisitos de projeto.

Técnicas de AI buscam capturar o conhecimento de um certo domínio, e

utilizá-lo na solução de problemas. De forma a automatizar o processo de

projeto, um sistema computacional deve ser capaz de diferenciar as várias

opções e determinar o melhor caminho.

Brachman e Levesque, citados por (MCMAHON e BROWNE, 1998),

resumem que a principal aplicação da AI se concentra na descrição de regras

para o mundo real, tal que uma máquina inteligente possa tirar novas

conclusões a respeito de seu contexto de conhecimento, manipulando as

descrições originais definidas previamente.

A aplicação da AI no projeto está normalmente interessada em tornar os

computadores mais inteligentes, capacitando-os a representar e a manipular o

conhecimento do mundo real de duas formas: ou com o estudo de como os

projetistas aplicam a inteligência humana ao projeto, ou com a tentativa de

fornecer suporte computacional mais esperto durante o projeto.

A dificuldade real da AI em projeto, está na determinação de uma forma

que torne o computador também processe soluções criativas, e não apenas

soluções difíceis do tipo NP. Se um programa gera todas as soluções possíveis,

a quantidade de tempo de geração e verificação das soluções pode ser infinita.

Um programa de projeto deve ser capaz de gerar um pequeno número de

soluções possíveis de projeto, e selecioná-las para uma decisão final de qual é a

melhor. Um projetista é capaz de fazer isto com uma relativa facilidade, mas

existem fatores estranhos.

O enfoque de estudo da AI em projeto concentra-se na modelagem da

tríade formada por Função-Estrutura-Comportamento de um equipamento e

suas interconexões.

TRÍADE FUNÇÃO-ESTRUTURA-COMPORTAMENTO Normalmente, as pessoas referem-se a objetos como se eles fossem

máquinas, e citam as funções realizadas por este objeto. De acordo com citação

de (KUMARA et al., 1989), Freeman e Newell afirmam que os homens pensam

em termos de uma descrição funcional das coisas. Fundamentados nesta


confirmação, eles apresentam um método baseado em raciocínio funcional,

onde o modelo básico de um ambiente de atividade de projeto consiste de um

conjunto de estruturas e um conjunto de funções. O método assume que

estruturas existentes devem ser combinadas em novas estruturas, para

poderem atingir as funções desejadas. Isto poderia ser feito através de uma

estratégia bottom-up (iniciando pelas estruturas disponíveis) ou estratégia top-

down (iniciando com as funções desejadas).

(KUMARA et al., 1989) cita trabalhos de Bobrow e Davis, para conceituar

função e estrutura. Bobrow definiu função como as relações entre um objetivo

do usuário e o comportamento do sistema. Ele ressalta a distinção entre

funcionalidade e comportamento como sendo um diferente nível de descrição;

isto é, a função de uma peça do sistema descreve o comportamento daquela

peça com relação ao sistema como um todo. Davis definiu estrutura como a

informação sobre a interconexão de módulos organizados, ou em termos de

funcionalidade, como os módulos interagem; ou fisicamente, como eles estão

integrados.

Em resumo, o problema com o estudo de projeto está no entendimento do

relacionamento do comportamento e da estrutura. O comportamento pode ser

definido como o relacionamento entre as variáveis de entrada a partir do

ambiente, e as variáveis de saída ou efeitos nos componentes que realmente

interagem com o ambiente. Nesta definição, nenhuma menção é feita a real

estrutura interior ou ao comportamento do componente. Isto conduz à

definição de componente, como sendo uma entidade, a qual exibe um

comportamento através de uma estrutura predefinida com o ambiente externo.

Como o componente alcança o comportamento não é questão de interesse, haja

vista que ele pode ser subdividido em sub-componentes, os quais estão

definidos como acima.

O processo de projeto é a combinação de comportamentos e estruturas

para produzir um comportamento final predefinido. O processo pelo qual as

estruturas são combinadas para formar uma estrutura final, deve ser

considerado uma arte. Portanto a arte da engenharia está em combinar

estruturas no projeto, embora o propósito de engenharia é produzir uma

entidade que exiba um comportamento benéfico ao homem no seu hábitat.


SISTEMAS ESPECIALISTAS Um sistema especialista é capaz de usar regras e casos previamente

definidos para escolher a melhor solução e resolver um novo problema. Isto

possibilitaria que um sistema especialista utilizasse estruturas de projeto e

comportamentos, e os combinassem para gerar especificações de projeto.

Todavia, quando colocado em situações de projeto inéditas, ou seja, sem regras

previamente definidas, um sistema especialista é incapaz de criatividades

originais. Disso, conclui-se que um sistema especialista é capaz de auxiliar no

processo de projeto, mas é incapaz de gerar soluções inéditas de forma a

automatizar o processo de projeto.

Através de representações computacionais de heurísticas de projeto, as

quais são mais fáceis de expressar do que utilizar métodos matemáticos

clássicos, a AI vem desenvolvendo os chamados �sistemas especialistas� ou

�sistemas baseados no conhecimento�.

Figura 32. Os elementos de um sistema especialista (MCMAHON e BROWNE, 1998).

Os componentes de um sistema especialista estão ilustrados na Figura 32.

A base de conhecimento armazena o conhecimento de uma área

específica. Nesta base, o conhecimento é representado por uma simbologia

baseada numa linguagem ou notação semântica de significados, a qual possui

uma sintaxe de instruções computacionais bem definida.

O motor de inferência interage com o usuário e realiza operações de

procura e comparação entre o assunto da pesquisa e o conhecimento

armazenado na base. O propósito desse processo é encontrar um objetivo

satisfatório para a procura realizada pelo usuário.

Segundo Buchanan e Shortiffe, citados por (MCMAHON e BROWNE,

1998), a aquisição de conhecimento é caracterizada como: �A transferência ou

Motor deinferência

Base deconhecimento

Aquisição deconhecimento

USUÁRIO

ESPECIALISTA


transformação do conhecimento ou da experiência com um problema específico,

para um programa computacional�. Essa aquisição de conhecimento se dá pela

interação do especialista com o motor de inferência � que pode ser através de

técnicas de entrevista, ou pela observação do comportamento do especialista

em resolver um problema particular.

6.4.7. ORIENTAÇÃO A OBJETO EM CAD Não há uma única definição original de Orientação a Objeto em CAD.

Entretanto, pode-se defini-la como sendo: �O CAD que emprega objetos

"inteligentes" (que sabem o que são), os quais podem avaliar mensagens e

respondê-las�. A "Orientação a Objeto em CAD" usa os objetos como uma

unidade da representação para armazenar as intenções do projetista no

projeto.

Um objeto é uma entidade que combina sua estrutura de dados e seu

comportamento numa estrutura de dados única (HSU e WOON, 1998). As

características do objeto são:

• Abstração: o foco sobre o qual ele deseja representar;

• Encapsulação: separação de aspectos externos do objeto dos detalhes

de implementação;

• Polimorfismo: permitir várias implementações diferentes de uma

mesma operação;

• Herança: permitir compartilhar atributos e métodos sem a necessidade

de redundância.

Atualmente, as técnicas de modelagem e programação orientadas a objeto

são amplamente empregadas no desenvolvimento de sistemas CAD. Entidades

do sistema são divididas em hierarquias de classe. As mensagens instruem aos

objetos como eles podem se desenhar, caracterizando um polimorfismo

dinâmico. Novas entidades podem ser adicionadas, e podem herdar

características ou comportamentos encapsulados por classes de objetos. Outra

característica da orientação a objeto em CAD, é que o mecanismo de passagem

de mensagens entre objetos reforça os relacionamentos existentes entre


modelos sólidos de montagens de conjuntos de peças. Esta modelagem facilita

os relacionamentos entre partes do produto.

As técnicas orientadas a objeto fornecem a flexibilidade necessária para o

projeto conceitual. Os elementos físicos do projeto, seus parâmetros,

propriedades, restrições e relacionamentos podem ser representados como

objetos, com seus atributos e métodos. A Tabela 10 mostra a evolução das

estratégias de modelagem com objetos.

Tabela 10. Evolução das estratégias de modelagem com objetos (Baseado em KUMAR et al., 1999).

ANO APLICAÇÕES ATRIBUTOS DOS OBJETOSREPRESENTAÇÃO COMPUTACIONAL

1950's Computação Gráfica Usinagem por controle numérico (CNC)

Geometria Desenho eletrônico e wireframe

1960's Modelos poligonais e de superfície

1970's/1980's CAD/CAM Geometria e topologia Modelos sólidos

1990's Objetos heterogêneos Geometria, topologia, e material

Modelos sólidos heterogêneos

Futuro Objetos heterogêneos e Modelagem Física

Geometria, topologia, e material, propriedades físicas, atributos gerais, etc. ...

Modelos de objetos

NECESSIDADE DE UMA NOVA MODELAGEM DE OBJETOS EM CAD Nos modelos tradicionais do produto em sistemas CAD, as características

de superfície podem variar somente sobre a superfície da peça, mas as

características volumétricas são consideradas constantes em todo o interior.

Já existem métodos de projeto e fabricação de materiais e estruturas que

são capazes de gerar componentes mecânicos e estruturais otimizados,

fabricados com materiais heterogêneos. São novas tecnologias de fabricação,

tais como: "Fabricação de Sólidos de Forma Livre" (SFF � Solid Freeform

Fabrication), ou "Fabricação em Camadas" (LM � Layered Manufacturing). Os

materiais compostos ou "objetos heterogêneos", fabricados com essas novas

tecnologias, são constituídos por diferentes materiais, e devem exibir uma

variação contínua de composição e microestrutura. A variação causa uma

gradação contínua nos valores das propriedades desse tipo de material. Esse

tipo de material é amplamente utilizado na indústria aeroespacial (projeto e


fabricação em lâminas de turbinas, em difusores, e na fuselagem das

aeronaves).

Surge então a necessidade de representar peças com distribuição de

material não-uniforme no seu interior. A distribuição de material torna-se um

dos vários atributos, associados com o domínio volumétrico definido pela sua

forma material da peça. Para propósitos de projeto, análise e fabricação, os

materiais heterogêneos impõem que o modelo dos objetos em sistemas CAD

capture não somente os dados geométricos, mas também a informação sobre o

material, suas propriedades, etc., em cada ponto do domínio volumétrico.

Um exemplo dessa necessidade está no projeto e fabricação de lâminas de

turbinas de aeronaves, descrito por (KUMAR et al., 1999). Este produto

enfrenta condições adversas em regime de trabalho � altas temperaturas e

oxidação de um lado, e resiliência e baixas temperaturas no outro lado. As

primeiras soluções para resistir a essas adversidades combinavam um lado de

metal e outro de cerâmica. Todavia, na interface dessa combinação, geram-se

altas concentrações de tensão; ocasionando trincas, deformações plásticas, e

descolamento. Recentemente, este problema foi resolvido usando uma mistura

de metal e cerâmica com variação das proporções desses materiais ao longo do

volume da peça. Isso ficou conhecido como "Material com Gradiente Funcional"

(FGM � Functionally Graded Material). Neste tipo de material, as propriedades

podem ser ajustadas controlando as razões de composição, microestrutura, e

porosidade desde o metal até a cerâmica, em cada ponto do volume da peça.

O modelo de CAD desse tipo de material deve representar não somente a

geometria das várias regiões, mas também a informação de material em cada

região. A representação dessas variações nas propriedades é essencial para a

fabricação e análise desses materiais.

Nos modelos sólidos de CAD atuais, os esquemas de representação não

consideram a variação das propriedades no interior dos materiais. Portanto,

exige-se a formulação de um novo esquema de representação que faça isto. A

disponibilidade de tal esquema, permitirá um grande avanço nas técnicas de

modelagem sólida, e terá grande aplicação no projeto, fabricação e análise de

produtos tecnologicamente avançados.


Uma outra aplicação de um modelo de CAD com as características já

mencionadas acima, também citado por (KUMAR et al., 1999), é na modelagem

física. A modelagem física tem por objetivo fornecer modelos computacionais

consistentes e uniformes, os quais fazem a ligação entre a forma e a função. Os

ingredientes-chave para se conseguir esse intento é através do modelo de

objetos, os quais capturam toda a informação relacionada a um objeto numa

forma rigorosamente matemática.

Tabela 11. Classificação dos vários atributos de um objeto (Baseado em KUMAR et al., 1999).

ATRIBUTOS DESCRIÇÃO Geometria Geometria e topologia relacionada

Composição Microestrutura Parâmetros de forma

Inclusões Vazios Orientação/Rotação Transição de fase Estrutura cristalina Discordâncias Densidade

Material

Propriedades Módulo (elástico, volumétrico, cisalhamento) Coeficiente de expansão térmica Condutividade térmica

Parâmetros físicos Temperatura Deslocamento Velocidade Tensão

No artigo de (KUMAR et al., 1999), eles propõem um modelo de objeto que

fornece uma estrutura consistente, para matematicamente integrar os vários

atributos de um objeto, conforme exigido pelas aplicações e exemplos citados

anteriormente.

A Tabela 11 mostra um exemplo de atributos para um objeto de um

material heterogêneo.

6.4.8. MODELAGEM DO PRODUTO A necessidade de modelagem do produto foi estimulada pela demanda

crescente por produtos de alta qualidade e baixos custos, e pela diminuição do

tempo de lançamento (lead-time) do produto no mercado. Por conta dessa

demanda, surgiram diversas estratégias para suportar o desenvolvimento do

produto. Algumas delas estão brevemente descritas a seguir:


• CIM: enfatiza a interconexão entre diferentes funções técnicas e de

gerenciamento dentro de uma companhia, utilizando sistemas

computacionais desde o projeto até a fabricação.

• Produção Enxuta/Limpa (Lean Production): esforça-se para minimizar

os custos de desenvolvimento, realizando mudanças culturais e

organizacionais com um maior envolvimento dos empregados, e

exploração racional do conhecimento adquirido.

• Engenharia Simultânea: focaliza a integração de experiências e

conhecimentos complementares de engenharia, cooperação entre

objetivos conflitantes ou competitivos, comunicação entre fluxos de

informação de estágios mais básicos (downstream) e mais avançados

(upstream) do ciclo de vida do produto, e a coordenação/sincronização

entre atividades relacionadas à solução do problema.

• Fábrica Fractal e Fabricação Virtual: são tentativas de resolver

questões críticas de produtividade no desenvolvimento do produto de

forma a melhorar a competitividade industrial.

Embora cada uma das estratégias acima tenham o seu particular

interesse, o foco comum é a necessidade por informações tecnológicas

avançadas, com o objetivo de aplicá-las na integração e coordenação das

questões referentes ao ciclo de vida do produto nas fases do seu

desenvolvimento.

A modelagem do produto é o fator-chave na determinação do sucesso das

estratégias de desenvolvimento do produto e da competitividade industrial na

atualidade e para o futuro.

A PROGRAMAÇÃO GENÉTICA NA MODELAGEM DO PRODUTO Desde quando foi introduzida � na primeira metade dos anos 90, por J. R.

Koza � a GP se caracterizou como um dos métodos computacionais mais gerais

em termos de aplicações. A novas idéias lançadas pela "Programação Genética"

(GP � Genetic Programming), estão sendo empregadas também na modelagem

do produto. A GP é aplicada na modelagem das mudanças dinâmicas que

ocorrem nos desejos e preferências dos consumidores.


O mercado consumidor moderno exige que os chamados "Sistemas de

Fabricação Flexível" (FMS � Flexible Manufacturing System), sejam cada vez

mais flexíveis, inteligentes, baratos e rápidos em atender e adaptar-se às

mudanças.

No artigo de (BALIC et al., 2000), tem-se a proposta de aplicação de GP na

geração automática de famílias de peças ou produtos. Este exemplo de

aplicação da GP se baseia no conceito de montagem auto-organizadas (self-

organizing assembly), proposto inicialmente por Brezocnik, e depois

desenvolvido juntamente com Balic.

A montagem auto-organizada é uma analogia da maneira de se organizar e

se juntar das células humanas, as quais formam os tecidos, órgãos, e

organismos. Os elementos que comandam as associações e composições são de

dois tipos:

• A informação ou conteúdo genético (DNA) dos componentes básicos

(células). A informação genética pode ser: geométrica, material,

topológica, tecnológica, econômica, ecológica, etc.;

• E as leis (comportamento) e propriedades do ambiente no qual estes

componentes básicos crescem.

O mecanismo de evolução do modelo consiste em: os componentes básicos

possuem sensores que verificam o estado do ambiente e o compara com a

informação genética. Dessa comparação, o ambiente pode ou não se alterar.

Conforme os componentes básicos encontrem outros componentes e combinem

sua informação genética, eles podem evoluir para tecidos, órgãos, ou

organismos. Essa evolução caracteriza um tipo de modelo hierárquico, o qual

se torna cada vez mais complexo.

A Figura 33 mostra algumas combinações possíveis de um produto

simples (uma cadeira) geradas por GP. Algumas configurações são esperadas

(tais como a, b, e c), entretanto, outras são inesperadas (configuração d).

(BALIC et al., 2000) advertem que este tipo de modelo genético pode

claramente representar um processo de geração de configurações possíveis

para um determinado produto constituído por centenas de peças. A analogia

com a genética celular, embutida no modelo, encaixa perfeitamente com o


processo evolutivo de alternativas de solução para o desenvolvimento de

produtos.

Figura 33. Combinações de produto simples (BALIC et al., 2000).

66..55.. CCOONNSSIIDDEERRAAÇÇÕÕEESS FFIINNAAIISS

As funções de projeto do produto e engenharia da produção devem tornar-

se inteiramente integradas com a fabricação, e todos os gargalos do fluxo de

informação do produto e da engenharia, a partir dessas funções até às funções

de fabricação, devem ser eliminados.

A estreita ligação entre as funções de projeto, planejamento, e fabricação

requer a informação suficientemente completa e precisa de todos os aspectos

do produto, dos processos de produção, e das operações factíveis e disponíveis.

Portanto, os sistemas de planejamento e projeto do futuro, deverão estar

estreitamente alinhados com a tecnologia de fabricação, e os sistemas de

fabricação precisarão de informação mais completa e precisa do que os

sistemas atuais.


Idealmente, esta integração deverá conduzir à �Engenharia Simultânea�

do ciclo de vida do produto, onde projeto, fabricação, manutenção, eventual

descarte ou desmonte, e questões de reutilização do produto podem ser

consideradas simultaneamente durante o seu projeto (SHAH e MÄNTYLA,

1995). As tecnologias desenvolvidas em termos de novas ferramentas

computacionais, precisam estar direcionadas ao atendimento destes requisitos;

e nos sistemas CAD/CAM, isso não seria diferente.

Acredito que a reutilização da informação que constitui o ciclo de vida do

produto, dentro de diferentes contextos funcionais, geográficos e temporais, é

uma questão não alcançável por completo com as técnicas e modelos

apresentados nesse estudo.

Uma estrutura de dados universal (Se é que é possível uma!), que

contemple e atenda todos os requisitos exigidos pelo processo de projeto, ainda

é um problema sem solução.

As pesquisas nessa área são muitas, mas ainda muito incipientes e com

soluções muito específicas e limitadas.

RReeffeerrêênncciiaass BBiibblliiooggrrááffiiccaass

BALIC, J.; BREZOCNIK, M.; CUS, F.. Modeling of Mechanical Parts Compositions using Genetic Programming. Trabalho aceito no FAIM � Flexible Automation And Intelligent Manufacturing, Maryland-USA, a ser realizado de 26-28/06/2000. URL: http://www.faim2000.isr.umd.edu/, ABRIL-2000.

BERTOLINE, G. R.; WIEBE, E. N.; MILLER, C. L.; MOHLER, J. L.. Technical Graphics Communication. Irwin Graphics Series, 2a. edição, p. 1128, 1997.

CHANG, T.-C.; WYSK, R. A.; WANG, H.-P.. Computer-Aided Manufacturing. Prentice Hall, 2a. edição, p. 672, Julho-1997.

CIMDATA, Inc. Product Data Management: The Definition � An Introduction to Concepts, Benefits, and Terminology. URL: http:// www. CIMdata. com, Dezembro-1999.

DIAS, A.. An Iterative CAD/CAM System Approach for Robot�s �Off-Line� Programming. Relatório de Atividades do Pós-doutorado, ISE Dept., Virginia Polytechnic Institute � USA, p. 72, 1998.

EASTMAN, C. M.. Out of STEP. Computer-Aided Design, Vol. 26, No. 5, p. 338-340, Julho-1994.

EASTMAN, C. M.; FERESHETIAN, N.. Information models for use in product design: a comparison. Computer-Aided Design, Vol. 26, No. 7, p. 551-572, Julho-1994.

FARIN, G.. Curves and Surfaces for CAGD � A Practical Guide. Academic Press, New York, 4a. edição, p. 429, 1997.

FUH, J. Y. H.; CHANG, C.-H.; MELKANOFF, M. A.. The development of an integrated and intelligent CAD/CAPP/CAFP environment using logic-based reasoning. Computer Aided Design, Elsevier Science, Vol. 28, No. 3, p. 217-232, 1996.

GUERRERO, V.; ROZENFELD, H.. Proposta de Classificação de Sistemas PDM. XV Congresso Brasileiro de Engenharia Mecânica, Águas de Lindóia-SP, 22-26/11/1999.

HSU, W.; WOON, I. M. Y.. Current research in the conceptual design of mechanical products. Computer-Aided Design, Elsevier Science Ltd., Vol. 30, No. 5, p. 377-389, 1998.

REFERÊNCIAS BIBLIOGRÁFICAS 102

IBM, Inc. An Overview of Object Oriented Programming. URL: http://www. inf.ufsc.br/poo/smalltalk/ibm/tutorial/oop.html, JANEIRO-2000.

JENSEN, C.; HINES, R.. Interpreting Engineering Drawings. Delmar Publishers, Inc., p. 400, 1989.

KERN, V. M.; BØHN, J. H.. STEP Databases for Product Data Exchange. First International Congress of Industrial Engineering, São Carlos�SP, Brasil, 4-7/Setembro, 1995.

KORTH, H. F.; SILBERSCHATZ, A.. Sistema de Banco de Dados. McGraw-Hill, Inc.; São Paulo, p.581, 1989.

KRAUSE, F.-L.; KIMURA, F.; KJELLBERG, T.; LU, S. C.-Y.. Product Modelling. Annals of the CIRP, p. 695-705, Vol. 42/2/1993.

KUMAR, V.; BURNS, D.; DUTTA, D.; HOFFMANN, C.. A framework for object modeling. Computer-Aided Design, Vol. 31, No. 9, p. 541-556, 1999.

KUMARA, S.; HAM, I.; AL-HAMANDO, M.; GOODNOW, K.. Causal Reasoning and Data Abstraction in Component Design. Annals of the CIRP, p. 145-148, Vol. 38/1/1989.

LEITE, L. L. P.. Introdução aos Sistemas de Gerência de Banco de Dados. Editora Edgard Blücher, São Paulo, 3a. reimpressão, p. 138, 1988.

LIANG, J.; SHAH, J. J.; SOUZA, R. D.; URBAN, S. D.; AYYASWAMY, K.; HARTER, E.; BLUHM, T.. Synthesis of consolidated data schema for engineering analysis from multiple STEP application protocols. Computer-Aided Design, Vol. 31, p. 429-447, 1999.

MÄNTYLÄ, M.. An Introduction to Solid Modeling. Computer Science Press, p. 401, 1988.

MCMAHON, C.; BROWNE, J.. CAD CAM: Principles, Practice and Manufacturing Management. Addison Wesley Longman, 2a edição, p. 665, Agosto�1998.

NARDELLI, E. S.. Diversidade de materiais ajuda na concepção de projetos. Revista CADesign, Market Press, Ano 5 � No. 54, 1999.

ROGERS, D. F.; ADAMS, J. A.. Mathematical Elements for Computer Graphics. McGraw-Hill, Inc; New York, 2a. edição, p. 611, 1990.

RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W.. Object-Oriented Modeling and Design. Prentice Hall, Inc.; New Jersey, p. 500, 1991.

SHAH, J. J.; MÄNTYLÄ, M.. Parametric and Feature-Based CAD/CAM. John Wiley & Sons, New York, p. 619, 1995.

REFERÊNCIAS BIBLIOGRÁFICAS 103

SHAH, J. J.; ROGERS, M. T.. Expert form feature modelling shell. Computer-Aided Design, Vol. 20, No. 9, p. 515-524, 1988.

SPATIAL Technology, Inc.. ACIS 3D Toolkit � SAT Format. URL: http:// www.spatial.com, 1999.

STEPTOOLS, Inc.. What is STEP? URL: http://www.steptools.com/library/ about_step.html, FEVEREIRO-1999.

ULLMAN, D. G.; WOOD, S.; CRAIG, D.. The Importance of Drawing in the Mechanical Design Process. Computer & Graphics, Vol. 14, No. 2, p. 263-274, 1990. URL: http://www.engr.orst.edu/~ullman

ZEID, I.. CAD/CAM Theory and Practice. McGraw Hill, Inc.; New York, p. 1052, 1991.

BBiibblliiooggrraaffiiaass

ASHLEY, S.. Manufacturing firms face the future. Mechanical Engineering, p. 70-74, Junho-1997.

BANKS, J.; GIBSON, R.. Simulation Modeling � Some Programming Required. IIE Solutions, p. 26-31, Fevereiro-1997.

BOKULICH, F.. CAD � Software Integration. Automotive Engineering International, p. 52-64, Abril-1999.

BECKERT, B.; KEMPFER, L.; SCHIMTZ, B.; DVORAK, P.. 1997 CAD/CAM � Planning Guide. A suplemento da Computer-Aided Engineering e Machine Design, p. 1-20, 1997.

CUNHA, R. R. M.. Padrão STEP para Transferência e Conversão de Dados. Seminário apresentado na disciplina EMC 6634, Dezembro-1996.

DIEHL, A.. Transferring files from CAD to CAM. Computer-Aided Engineering, p. 50-52, 1996.

DVORAK, P.. What moldmakers need from designers. Machine Design, p. 103-105, Janeiro-1998. URL: http://www.penton.com/md

LOFFREDO, D.. Efficient Database Implementation of EXPRESS Information Models. New York, 1998. PhD Thesis, Rensselaer Polytechnic Institute. URL: http://www.steptools.com/~loffredo, AGOSTO-1999.

MAZIERO, N. L.. Um Sistema Computacional Inteligente de Suporte ao Projeto, Manufatura e Montagem de Peças Baseado em Features: Uma Abordagem com Sistemas Especialistas. Florianópolis, 1998. Tese (Doutorado em Engenharia Mecânica) � Departamento de Engenharia Mecânica � Centro Tecnológico � Universidade Federal de Santa Catarina.

PIERRA, G.; AIT-AMEUR, Y.; BESNARD, F.; GIRARD, P.; POTIER, J-C.. A general framework for parametric product model within STEP and parts library. Artigo a ser apresentado no European Conference Product Data Technology, Londres. URL: http://www.nist.gov/sc4, FEVEREIRO-2000.

SALOMONS, O. W.. Computer Support in the Design of Mechanical Products � Constraint specification and satisfaction in feature based design for manufacturing. Groningen, 1995. PhD Thesis,. Department of Mechanical Engineering, Universiteit Twente. URL: http://www.pt.wb.

BIBLIOGRAFIAS 105

utwente.nl/staff/otto/thesis, SETEMBRO-1999.

SC4 Home Page. Welcome to ISO TC184/SC4 Developers of International Industrial Data Standards. URL: http://www.nist.gov/sc4, FEVEREIRO-2000.

SILVA JUNIOR, A. C.; CUNHA, R. R. M.. Problemas e Princípios de Solução na Integração CAD/CAM. Seminário apresentado na disciplina EMC 6327, Setembro-1999.

SMALL, C. H.. Forging links in the CAE, CAD, CAM chain requires new methodologies. Computer Design, p. 80-85, Setembro-1998.

AAppêênnddiicceess

APÊNDICE A. Exemplo de Arquivo IGES

This file was produced by MicroStation IGES S 11H,,1H;,40HExemplo para o texto do estudo dirigido.,16Hexemplo_iges.igs,G 114HMicroStation/J,14HMicroStation/J,32,38,6,38,15,40HExemplo para o textG 2o do estudo dirigido.,1.,2,2HMM,32,5.,14H1000413.133242,0.00001, G 3702.59607417999996,31HRaimundo Ricardo Matos da Cunha,16HEMC - CTC - UFSG 4C,8,0,13H990914.175752; G 5

100 1 0 1 1 0 3 000000000D 1100 1 4 1 0 0D 2124 2 0 0 0 0 0 000000400D 3124 0 0 3 0 0D 4110 5 0 1 1 0 0 000000000D 5110 1 4 2 0 0D 6116 7 0 1 1 0 0 000000000D 7116 1 4 1 0 0D 8

100,0.,0.,0.,50.,0.,50.,0.; 1P 1124,0.83800671448980135,-0.54565991832826466,0.,595.82816, 3P 20.54565991832826466,0.83800671448980135,0.,-136.91578,0.,0.,1., 3P 30.; 3P 4110,631.18349905942,-172.27111905942,0.,701.894177177953, 5P 5-101.56044094058,0.; 5P 6116,595.82816,-136.91578,0.; 7P 7S 1G 5D 8P 7 T 1

APÊNDICES 107

APÊNDICE B. Exemplo de Arquivo DXF

0 $LIMMAX 40 $DIMRND 9SECTION 10 0.05 40 $DIMSE1

2 12.0 9 0.0 70HEADER 20 $TEXTSTYLE 9 0

9 9.0 7 $DIMDLE 9$ACADVER 9 STANDARD 40 $DIMSE2

1 $ORTHOMODE 9 0.0 70AC1014 70 $CLAYER 9 0

9 0 8 $DIMEXE 9$ACADMAINTVER 9 0 40 $DIMTAD70 $REGENMODE 9 0.18 70

0 70 $CELTYPE 9 09 1 6 $DIMTP 9

$DWGCODEPAGE 9 CONTINUOUS 40 $DIMZIN3 $FILLMODE 9 0.0 70

ANSI_1252 70 $CECOLOR 9 09 1 62 $DIMTM 9

$INSBASE 9 256 40 $DIMBLK10 $QTEXTMODE 9 0.0 1

0.0 70 $CELTSCALE 920 0 40 $DIMTXT 9

0.0 9 1.0 40 $DIMASO30 $MIRRTEXT 9 0.18 70

0.0 70 $DELOBJ 9 19 1 70 $DIMCEN 9

$EXTMIN 9 1 40 $DIMSHO10 $DRAGMODE 9 0.09 70

545.82816 70 $DISPSILH 9 120 2 70 $DIMTSZ 9

-186.91578 9 0 40 $DIMPOST30 $LTSCALE 9 0.0 1

0.0 40 $DIMSCALE 99 1.0 40 $DIMTOL 9

$EXTMAX 9 1.0 70 $DIMAPOST10 $OSMODE 9 0 1

701.89418 70 $DIMASZ 920 0 40 $DIMLIM 9

-86.91578 9 0.18 70 $DIMALT30 $ATTMODE 9 0 70

0.0 70 $DIMEXO 9 09 1 40 $DIMTIH 9

$LIMMIN 9 0.0625 70 $DIMALTD10 $TEXTSIZE 9 1 70

0.0 40 $DIMDLI 9 220 0.2 40 $DIMTOH 9

0.0 9 0.38 70 $DIMALTF9 $TRACEWID 9 1 40

25.4 70 $DIMUNIT 9 09 0 70 $AUPREC 9

$DIMLFAC 9 2 70 $TDCREATE40 $DIMTFAC 9 0 40

1.0 40 $DIMDEC 9 2451654.4322685199 1.0 70 $MENU 9

$DIMTOFL 9 4 1 $TDUPDATE70 $DIMGAP 9 acad 40

APÊNDICES 108

0 40 $DIMTDEC 9 2451654.4322685199 0.09 70 $ELEVATION 9

$DIMTVP 9 4 40 $TDINDWG40 $DIMJUST 9 0.0 40

0.0 70 $DIMALTU 9 0.00000000009 0 70 $PELEVATION 9

$DIMTIX 9 2 40 $TDUSRTIMER70 $DIMSD1 9 0.0 40

0 70 $DIMALTTD 9 0.00000000009 0 70 $THICKNESS 9

$DIMSOXD 9 2 40 $USRTIMER70 $DIMSD2 9 0.0 70

0 70 $DIMTXSTY 9 19 0 7 $LIMCHECK 9

$DIMSAH 9 STANDARD 70 $ANGBASE70 $DIMTOLJ 9 0 50

0 70 $DIMAUNIT 9 0.09 1 70 $BLIPMODE 9

$DIMBLK1 9 0 70 $ANGDIR1 $DIMTZIN 9 1 70

70 $LUNITS 9 09 0 70 $CHAMFERA 9

$DIMBLK2 9 2 40 $PDMODE1 $DIMALTZ 9 0.0 70

70 $LUPREC 9 09 0 70 $CHAMFERB 9

$DIMSTYLE 9 4 40 $PDSIZE2 $DIMALTTZ 9 0.0 40

STANDARD 70 $SKETCHINC 9 0.09 0 40 $CHAMFERC 9

$DIMCLRD 9 0.1 40 $PLINEWID70 $DIMFIT 9 0.0 40

0 70 $FILLETRAD 9 0.09 3 40 $CHAMFERD 9

$DIMCLRE 9 0.0 40 $COORDS70 $DIMUPT 9 0.0 70

0 70 $AUNITS 9 09 0 70 $SKPOLY 9

$DIMCLRT 9 0 70 $SPLFRAME

70 $UCSNAME 9 0.0 300 2 $PUCSYDIR 9 -1.000000E+20

9 10 $WORLDVIEW 9$SPLINETYPE 9 0.0 70 $PLIMMIN70 $UCSORG 20 1 10

6 10 1.0 9 0.09 0.0 30 $SHADEDGE 20

$SPLINESEGS 20 0.0 70 0.070 0.0 9 3 9

10 30 $USERI1 9 $PLIMMAX9 0.0 70 $SHADEDIF 10

$ATTDIA 9 0 70 12.070 $UCSXDIR 9 70 20

0 10 $USERI2 9 9.09 1.0 70 $TILEMODE 9

$ATTREQ 20 0 70 $UNITMODE70 0.0 9 1 70

1 30 $USERI3 9 09 0.0 70 $MAXACTVP 9

APÊNDICES 109

$HANDLING 9 0 70 $VISRETAIN70 $UCSYDIR 9 16 70

1 10 $USERI4 9 09 0.0 70 $PINSBASE 9

$HANDSEED 20 0 10 $PLINEGEN5 1.0 9 0.0 70

2F 30 $USERI5 20 19 0.0 70 0.0 9

$SURFTAB1 9 0 30 $PSLTSCALE70 $PUCSNAME 9 0.0 70

6 2 $USERR1 9 09 40 $PLIMCHECK 9

$SURFTAB2 9 0.0 70 $TREEDEPTH70 $PUCSORG 9 0 70

6 10 $USERR2 9 30209 0.0 40 $PEXTMIN 9

$SURFTYPE 20 0.0 10 $PICKSTYLE70 0.0 9 -1.000000E+20 70

6 30 $USERR3 20 19 0.0 40 -1.000000E+20 9

$SURFU 9 0.0 30 $CMLSTYLE70 $PUCSXDIR 9 -1.000000E+20 2

6 10 $USERR4 9 STANDARD9 1.0 40 $PEXTMAX 9

$SURFV 20 0.0 10 $CMLJUST70 0.0 9 -1.000000E+20 70

6 30 $USERR5 20 09 0.0 40 -1.000000E+20 9

$CMLSCALE 1 ISM40 OLE2FRAME 90

1.0 2 09 AcDbOle2Frame 280

$PROXYGRAPHICS 3 070 "" 281

0 90 09 0 0

$MEASUREMENT 280 CLASS70 0 1

0 281 IMAGEDEF0 1 2

ENDSEC 0 AcDbRasterImageDef0 CLASS 3

SECTION 1 ISM2 HATCH 90

CLASSES 2 00 AcDbHatch 280

CLASS 3 01 "ACAD_SEDONA" 281

LWPOLYLINE 90 02 0 0

AcDbPolyline 280 CLASS3 0 1

"AutoCAD" 281 IMAGEDEF_REACTOR90 1 2

0 0 AcDbRasterImageDefReactor280 CLASS 3

0 1 ISM281 DICTIONARYVAR 90

APÊNDICES 110

1 2 10 AcDbDictionaryVar 280

CLASS 3 01 "AutoCAD" 281

IMAGE 90 02 0 0

AcDbRasterImage 280 CLASS3 0 1

ISM 281 IDBUFFER90 0 2

127 0 AcDbIdBuffer280 CLASS 3

0 1 "Acad"281 RASTERVARIABLES 90

1 2 00 AcDbRasterVariables 280

CLASS 3 0

LAYER_INDEX VPORT 362 5 1.0

AcDbLayerIndex 7 173 100 618.922157

"Acad" AcDbSymbolTable 2790 70 -131.784525

0 1 37280 0 0.0

0 VPORT 40281 5 121.71041

0 2E 410 100 1.5803

CLASS AcDbSymbolTableRecord 421 100 50.0

SPATIAL_INDEX AcDbViewportTableRecord 432 2 190.59402

AcDbSpatialIndex *ACTIVE 443 70 -190.59402

"Acad" 0 5090 10 0.0

0 0.0 51280 20 0.0

0 0.0 71281 11 22

0 1.0 720 21 100

CLASS 1.0 731 12 1

OBJECT_PTR 0.0 742 22 0

CAseDLPNTableRecord 0.0 753 13 0

"ASE-LPNTableRecord" 0.0 7690 23 0

1 0.0 77280 14 0

0 0.0 78281 24 0

0 0.0 00 15 ENDTAB

ENDSEC 0.0 0

APÊNDICES 111

0 25 TABLESECTION 0.0 2

2 16 LTYPETABLES 0.0 5

0 26 4TABLE 0.0 100

2 0.0 100100

AcDbSymbolTable 100 2370 AcDbSymbolTableRecord 100

9 100 AcDbSymbolTableRecord0 AcDbLinetypeTableRecord 100

LTYPE 2 AcDbLinetypeTableRecord5 CONTINUOUS 2

11 70 HIDDEN100 0 70AcDbSymbolTableRecord 3 64100 Solid line 3AcDbLinetypeTableRecord 72 __ __ __ __ __

2 65 72BYBLOCK 73 6570 0 73

0 40 23 0.0 40

0 0.37572 LTYPE 49

65 5 0.2573 22 74

0 100 040 AcDbSymbolTableRecord 49

0.0 100 -0.1250 AcDbLinetypeTableRecord 74

LTYPE 2 05 DOT 0

12 70 LTYPE100 64 5AcDbSymbolTableRecord 3 24100 . . . . . . . . . . . 100AcDbLinetypeTableRecord 72 AcDbSymbolTableRecord

2 65 100BYLAYER 73 AcDbLinetypeTableRecord70 2 2

0 40 DASHED3 0.25 70

49 6472 0.0 3

65 74 __ __ __ __ __ __73 0 72

0 49 6540 -0.25 73

0.0 74 20 0 40

LTYPE 0 0.755 LTYPE 49

13 5 0.5

APÊNDICES 112

74 AcDbSymbolTableRecord 20 100 CENTER

49 AcDbLinetypeTableRecord 70-0.25 2 6474 DIVIDE 3

0 70 ____ _ ____ _ ____ _0 64 72

LTYPE 3 655 ____ . . ____ . . ____ 73

25 72 4100 65 40AcDbSymbolTableRecord 73 2.0100 6 49AcDbLinetypeTableRecord 40 1.25

2 1.25 74DASHDOT 49 070 0.5 49

64 74 -0.253 0 74

__ . __ . __ . __ . __ 49 072 -0.25 49

65 74 0.2573 0 74

4 49 040 0.0 49

1.0 74 -0.2549 0 74

0.5 49 074 -0.25 0

0 74 ENDTAB49 0 0

-0.25 49 TABLE74 0.0 2

0 74 LAYER49 0 5

0.0 49 274 -0.25 100

0 74 AcDbSymbolTable49 0 70

-0.25 0 274 LTYPE 0

0 5 LAYER0 27 5

LTYPE 100 145 AcDbSymbolTableRecord 102

26 100 {ACAD_XDICTIONARY100 AcDbLinetypeTableRecord 360

5F205F5F5F5F205F 70 6102 1 100} 0 AcDbSymbolTable100 STYLE 70AcDbSymbolTableRecord 5 0100 17 0AcDbLayerTableRecord 100 ENDTAB

2 AcDbSymbolTableRecord 00 100 TABLE70 AcDbTextStyleTableRecord 2

0 2 APPID

APÊNDICES 113

62 STANDARD 57 70 8

6 0 100CONTINUOUS 40 AcDbSymbolTable

0 0.0 70LAYER 41 1

5 1.0 02A 50 APPID102 0.0 5{ACAD_XDICTIONARY 71 16360 0 1005F205F5F5F5F205F 42 AcDbSymbolTableRecord102 0.0 100} 3 AcDbRegAppTableRecord100 txt 2AcDbSymbolTableRecord 4 ACAD100 70AcDbLayerTableRecord 0 0

2 ENDTAB 01 0 ENDTAB70 TABLE 0

64 2 TABLE62 VIEW 2

7 5 DIMSTYLE6 5 5

CONTINUOUS 100 90 AcDbSymbolTable 100

ENDTAB 70 AcDbSymbolTable0 0 70

TABLE 0 12 ENDTAB 0

STYLE 0 DIMSTYLE5 TABLE 105

3 2 18100 UCS 100AcDbSymbolTable 5 AcDbSymbolTableRecord

100 1.0 340 BAcDbDimStyleTableRecord 147 17 100

2 0.09 275 AcDbSymbolTableRecordSTANDARD 71 0 10070 0 280 AcDbBlockTableRecord

0 72 0 23 0 281 *PAPER_SPACE

73 0 04 1 282 ENDTAB

74 0 05 1 283 ENDSEC

75 1 06 0 284 SECTION

76 0 27 0 285 BLOCKS

77 0 040 0 286 BLOCK

1.0 78 0 541 0 287 D

0.18 170 0 10042 0 288 AcDbEntity

0.0625 171 0 8

APÊNDICES 114

43 2 0 00.38 172 ENDTAB 10044 0 0 AcDbBlockBegin

0.18 173 TABLE 245 0 2 *MODEL_SPACE

0.0 174 BLOCK_RECORD 7046 0 5 0

0.0 175 1 1047 0 100 0.0

0.0 176 AcDbSymbolTable 2048 0 70 0.0

0.0 177 0 30140 0 0 0.00.18 178 BLOCK_RECORD 3141 0 5 *MODEL_SPACE0.09 270 A 1142 2 1000.0 271 AcDbSymbolTableRecord 0143 4 100 ENDBLK25.4 272 AcDbBlockTableRecord 5144 4 2 E1.0 273 *MODEL_SPACE 100145 2 0 AcDbEntity0.0 274 BLOCK_RECORD 8146 2 5 0

100 CIRCLE 11 DICTIONARYAcDbBlockEnd 5 701.894177 5

0 2B 21 1ABLOCK 100 -101.560441 102

5 AcDbEntity 31 {ACAD_REACTORSF 8 0.0 330100 1 0 19AcDbEntity 6 POINT 10267 CONTINUOUS 5 }

1 62 2D 1008 174 100 AcDbDictionary

0 100 AcDbEntity 0100 AcDbCircle 8 DICTIONARYAcDbBlockBegin 10 1 5

2 595.82816 6 1B*PAPER_SPACE 20 CONTINUOUS 10270 -136.91578 62 {ACAD_REACTORS

0 30 174 33010 0.0 100 19

0.0 40 AcDbPoint 10220 50.0 10 }

0.0 210 595.82816 10030 0.0 20 AcDbDictionary

0.0 220 -136.91578 33 0.0 30 STANDARD

*PAPER_SPACE 230 0.0 3501 1.0 0 1C

0 ENDSEC 00 LINE 0 MLINESTYLE

ENDBLK 5 SECTION 55 2C 2 1C

10 100 OBJECTS 102100 AcDbEntity 0 {ACAD_REACTORS

APÊNDICES 115

AcDbEntity 8 DICTIONARY 33067 1 5 1B

1 6 19 1028 CONTINUOUS 100 }

0 62 AcDbDictionary 100100 172 3 AcDbMlineStyleAcDbBlockEnd 100 ACAD_GROUP 2

0 AcDbLine 350 STANDARDENDSEC 10 1A 70

0 631.183499 3 0SECTION 20 ACAD_MLINESTYLE 3

2 -172.271119 350ENTITIES 30 1B 62

0 0.0 0 0

5190.052

90.071

249

0.562

2566

BYLAYER49

-0.562

2566

BYLAYER0

ENDSEC0

EOF

APÊNDICES 116

APÊNDICE C. Exemplo de Arquivo STEP

ISO-10303-21;HEADER;/* Exchange file generated using ST-DEVELOPER 1.6 */FILE_DESCRIPTION((''),'2;1');FILE_NAME('exemplo_step203','2000-04-19T10:03:22-03:00',('Raimundo Ricardo Matos da Cunha'),('EMC - CTC - UFSC'),'ST-DEVELOPER 1.6','MicroStation/J Version 07.01.00.62','Exemplo para o texto do estudo dirigido');FILE_SCHEMA (('CONFIG_CONTROL_DESIGN'));ENDSEC;DATA;#10=MANIFOLD_SURFACE_SHAPE_REPRESENTATION('Manifold Surface Shape Representation',(#11),#30);#11=SHELL_BASED_SURFACE_MODEL('',(#12));#12=OPEN_SHELL('',(#13));#13=ADVANCED_FACE('',(#19),#14,.T.);#14=PLANE('',#15);#15=AXIS2_PLACEMENT_3D('',#16,#17,#18);#16=CARTESIAN_POINT('',(595.82816,-136.91578,0.));#17=DIRECTION('',(0.,0.,1.));#18=DIRECTION('',(1.,0.,0.));#19=FACE_BOUND('',#20,.T.);#20=EDGE_LOOP('',(#21));#21=ORIENTED_EDGE('',*,*,#22,.T.);#22=EDGE_CURVE('',#23,#23,#25,.T.);#23=VERTEX_POINT('',#24);#24=CARTESIAN_POINT('',(637.72849572449,-109.632784083587,0.));#25=CIRCLE('',#26,50.);#26=AXIS2_PLACEMENT_3D('',#27,#28,#29);#27=CARTESIAN_POINT('',(595.82816,-136.91578,0.));#28=DIRECTION('',(0.,0.,1.));#29=DIRECTION('',(0.838006714489801,0.545659918328265,0.));#30=(GEOMETRIC_REPRESENTATION_CONTEXT(3)GLOBAL_UNCERTAINTY_ASSIGNED_CONTEXT((#37))GLOBAL_UNIT_ASSIGNED_CONTEXT((#36,#31,#35))REPRESENTATION_CONTEXT('Based on DGN file units settings',' '));#31=(CONVERSION_BASED_UNIT('DEGREE',#33)NAMED_UNIT(#32)PLANE_ANGLE_UNIT());#32=DIMENSIONAL_EXPONENTS(0.,0.,0.,0.,0.,0.,0.);#33=PLANE_ANGLE_MEASURE_WITH_UNIT(PLANE_ANGLE_MEASURE(0.0174532925199433),#34);#34=(NAMED_UNIT(*)PLANE_ANGLE_UNIT()SI_UNIT($,.RADIAN.));#35=(NAMED_UNIT(*)SI_UNIT($,.STERADIAN.)SOLID_ANGLE_UNIT());#36=(LENGTH_UNIT()

APÊNDICES 117

NAMED_UNIT(*)SI_UNIT(.MILLI.,.METRE.));#37=UNCERTAINTY_MEASURE_WITH_UNIT(LENGTH_MEASURE(2.1474836475E-007),#36,'distance_accuracy_value','');#38=DESIGN_CONTEXT('detail',#39,'design');#39=APPLICATION_CONTEXT('');#40=APPLICATION_PROTOCOL_DEFINITION('','config_control_design',1994,#39);#41=PRODUCT_DEFINITION('','',#42,#38);#42=PRODUCT_DEFINITION_FORMATION_WITH_SPECIFIED_SOURCE('','',#43,.NOT_KNOWN.);#43=PRODUCT('exemplo_iges1','','',(#51));#44=PRODUCT_RELATED_PRODUCT_CATEGORY('detail','',(#43));#45=MECHANICAL_CONTEXT('',#39,'mechanical');#46=PERSON_AND_ORGANIZATION(#47,#48);#47=PERSON('DO1','','',$,$,$);#48=ORGANIZATION('','','');#49=PERSON_AND_ORGANIZATION_ROLE('design_owner');#50=CC_DESIGN_PERSON_AND_ORGANIZATION_ASSIGNMENT(#46,#49,(#43));#51=MECHANICAL_CONTEXT('',#39,'mechanical');#52=PERSON_AND_ORGANIZATION(#53,#54);#53=PERSON('PCR1','','',$,$,$);#54=ORGANIZATION('','','');#55=PERSON_AND_ORGANIZATION_ROLE('creator');#56=CC_DESIGN_PERSON_AND_ORGANIZATION_ASSIGNMENT(#52,#55,(#42));#57=PERSON_AND_ORGANIZATION(#58,#59);#58=PERSON('DSU1','','',$,$,$);#59=ORGANIZATION('','','');#60=PERSON_AND_ORGANIZATION_ROLE('design_supplier');#61=CC_DESIGN_PERSON_AND_ORGANIZATION_ASSIGNMENT(#57,#60,(#42));#62=CC_DESIGN_APPROVAL(#63,(#42));#63=APPROVAL(#64,'');#64=APPROVAL_STATUS('approved');#65=APPROVAL_DATE_TIME(#66,#63);#66=DATE_AND_TIME(#67,#68);#67=CALENDAR_DATE(1997,11,7);#68=LOCAL_TIME(0,0,0.,#69);#69=COORDINATED_UNIVERSAL_TIME_OFFSET(0,0,.AHEAD.);#70=APPROVAL_PERSON_ORGANIZATION(#71,#63,#74);#71=PERSON_AND_ORGANIZATION(#72,#73);#72=PERSON('DAI1','','',$,$,$);#73=ORGANIZATION('','','');#74=APPROVAL_ROLE('');#75=CC_DESIGN_SECURITY_CLASSIFICATION(#76,(#42));#76=SECURITY_CLASSIFICATION('','',#77);#77=SECURITY_CLASSIFICATION_LEVEL('unclassified');#78=CC_DESIGN_APPROVAL(#79,(#76));#79=APPROVAL(#80,'');#80=APPROVAL_STATUS('approved');#81=APPROVAL_DATE_TIME(#82,#79);#82=DATE_AND_TIME(#83,#84);#83=CALENDAR_DATE(1997,11,7);#84=LOCAL_TIME(0,0,0.,#85);#85=COORDINATED_UNIVERSAL_TIME_OFFSET(0,0,.AHEAD.);#86=APPROVAL_PERSON_ORGANIZATION(#87,#79,#90);#87=PERSON_AND_ORGANIZATION(#88,#89);#88=PERSON('SCA1','','',$,$,$);#89=ORGANIZATION('','','');#90=APPROVAL_ROLE('');#91=CC_DESIGN_DATE_AND_TIME_ASSIGNMENT(#92,#96,(#76));#92=DATE_AND_TIME(#93,#94);

APÊNDICES 118

#93=CALENDAR_DATE(1997,11,7);#94=LOCAL_TIME(0,0,0.,#95);#95=COORDINATED_UNIVERSAL_TIME_OFFSET(0,0,.AHEAD.);#96=DATE_TIME_ROLE('classification_date');#97=PERSON_AND_ORGANIZATION(#98,#99);#98=PERSON('SCO1','','',$,$,$);#99=ORGANIZATION('','','');#100=PERSON_AND_ORGANIZATION_ROLE('classification_officer');#101=CC_DESIGN_PERSON_AND_ORGANIZATION_ASSIGNMENT(#97,#100,(#76));#102=CC_DESIGN_DATE_AND_TIME_ASSIGNMENT(#103,#107,(#41));#103=DATE_AND_TIME(#104,#105);#104=CALENDAR_DATE(1997,11,7);#105=LOCAL_TIME(0,0,0.,#106);#106=COORDINATED_UNIVERSAL_TIME_OFFSET(0,0,.AHEAD.);#107=DATE_TIME_ROLE('creation_date');#108=PERSON_AND_ORGANIZATION(#109,#110);#109=PERSON('DAP1','','',$,$,$);#110=ORGANIZATION('','','');#111=PERSON_AND_ORGANIZATION_ROLE('creator');#112=CC_DESIGN_PERSON_AND_ORGANIZATION_ASSIGNMENT(#108,#111,(#41));#113=CC_DESIGN_APPROVAL(#114,(#41));#114=APPROVAL(#115,'');#115=APPROVAL_STATUS('approved');#116=APPROVAL_DATE_TIME(#117,#114);#117=DATE_AND_TIME(#118,#119);#118=CALENDAR_DATE(1997,11,7);#119=LOCAL_TIME(0,0,0.,#120);#120=COORDINATED_UNIVERSAL_TIME_OFFSET(0,0,.AHEAD.);#121=APPROVAL_PERSON_ORGANIZATION(#122,#114,#125);#122=PERSON_AND_ORGANIZATION(#123,#124);#123=PERSON('API1','','',$,$,$);#124=ORGANIZATION('','','');#125=APPROVAL_ROLE('');#126=PRODUCT_DEFINITION_SHAPE('','',#41);#127=SHAPE_DEFINITION_REPRESENTATION(#126,#10);ENDSEC;END-ISO-10303-21;

APÊNDICES 119

APÊNDICE D. Exemplo de Arquivo ACIS

500 0 1 07 Unknown 11 ACIS 5.0 NT 24 Wed Apr 19 15:56:35 2000-1 9.9999999999999995e-007 1e-010body $-1 $1 $-1 $-1 #lump $-1 $-1 $2 $0 #shell $-1 $-1 $-1 $3 $-1 $1 #face $-1 $-1 $4 $2 $-1 $5 forward double in #loop $-1 $-1 $6 $3 #plane-surface $-1 595.82816000000003 -136.91578000000001 0 0 0 1 1 0 0forward_v I I I I #coedge $-1 $6 $6 $-1 $7 forward $4 $-1 #edge $-1 $8 -3.141592653589814 $8 3.1415926535897865 $6 $9 forward 7 unknown#vertex $-1 $7 $10 #ellipse-curve $-1 595.82816000000003 -136.91578000000001 0 0 0 141.900335724490034 27.282995916413206 0 1 I I #point $-1 553.92782427550981 -164.19877591641293 0 #End-of-ACIS-data

APÊNDICES 120

APÊNDICE E. Exemplo de Arquivo PARASOLID

**ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz*************************PARASOLID !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~0123456789****************************PART1;MC=unknown;MC_MODEL=unknown;MC_ID=unknown;OS=unknown;OS_RELEASE=unknown;FRU=Bentley_Systems;APPL=Microstation_modeler;SITE=Exton;USER=unknown;FORMAT=text;GUISE=transmit;KEY=C:\Users\ricardo\Doutorado\Disciplinas\TRIM 99-3\EMC6601-ED\exemplo_parasolid.x_t;FILE=C:\Users\ricardo\Doutorado\Disciplinas\TRIM 99-3\EMC6601-ED\exemplo_parasolid.x_t;DATE=unknown;**PART2;SCH=SCH_1100178_11004;USFLD_SIZE=0;**PART3;**END_OF_HEADER**************************************************************T51 : TRANSMIT FILE created by modeller version 110017817 SCH_1100178_110040742 1 2 0 2 3 12 2 11 0 0 0 0 0 0 1e3 1e-8 0 4 3 1 0 3 1 5 6 7 0 8 9 0 12 3 8

0 00 0 0 0 1e3 1e-8 0 2 0 1 0 2 1 10 0 11 12 13 0 14 13 10 3 0 3 0 0 15 0 13 0

3011 7 0 15 0 0 0 +.63118349905942 -.1722711190594195 0 .707106781185021

.707106781188074 0 29 12 8 0 14 16 0 .701894177177953 -.1015604409405804 0 19 13 1 03 00 10 V18 14 5 0 17 0 18 12 ?3 17 17 0 0 0 0 14 19 15 0 0 +18 18 2 0 19 14 0

16?3 17 19 0 0 0 0 18 17 15 0 0 -29 16 4 0 18 0 12 .63118349905942 -

.1722711190594195 0 16 15 6 0 ?17 0 0 11 0 0 10 13 5 3 0 2 0 20 0 0 8 20 50 6 9 0 20 0 0 0+.59582816 -.13691578 0 0 0 1 1 0 0 31 7 6 0 9 0 0 0 +.59582816 -.13691578 0 00 1.838006714489801 .545659918328265 0 .05 19 8 1 0 2 0 0 5 V16 9 5 0 ?21 0 0 7

00 2 17 21 0 22 21 21 0 23 9 0 0 +15 22 7 0 21 20 0 17 23 0 0 0 0 0 21 9 0 0

-1420 8 0 ?0 0 22 5 6 +0 0 0 0 5 1 0

APÊNDICES 121

APÊNDICE F. Programação Orientada a Objetos

IINNTTRROODDUUÇÇÃÃOO

O QUE É OOP? A Programação Orientada a Objetos (OOP � Object-Oriented Programming)

é diferente do estilo de programação procedural de linguagens como (C, Pascal,

etc.) em várias formas. Tudo em OOP é considerado e agrupado como objetos.

OOP é implementada pelo envio de mensagens aos objetos. Para entender este

conceito, primeiro é preciso saber o que é um objeto.

O QUE É UM OBJETO? Um objeto pode ser considerado como algo � real ou abstrato � que pode

realizar um conjunto de atividades. O conjunto de atividades que o objeto

realiza define o comportamento do objeto.

A interface do objeto consiste de um conjunto de comandos, onde cada

comando realiza uma ação específica. Um objeto pergunta a outro objeto para

realizar uma ação, enviando a ele uma mensagem. O objeto que envia a

mensagem é conhecido como requisitante, e o objeto que recebe a mensagem é

o fornecedor. O controle é passado para o objeto requisitado até ele completar o

comando. Em seguida, o controle retorna ao objeto solicitante (Ver Figura 34).

Figura 34. Interface de comunicação entre os objetos.

Os papéis assumidos entre o objeto solicitante (cliente) e o objeto

requisitado (servidor) é semelhante ao formato de uma arquitetura cliente-

servidor. Existe quem solicita o serviço, e quem fornece o serviço.

OBJETO SOLICITANTE OBJETO REQUISITADO

MENSAGEM

VALOR DERETORNO

APÊNDICES 122

No exemplo da Figura 35, um objeto ESCOLA pergunta o nome do objeto

ALUNO, enviando a ele uma mensagem perguntando pelo nome. O objeto

requisitado ALUNO, retorna o nome de volta ao objeto solicitante ESCOLA.

Figura 35. Mecanismo de mensagem entre dois objetos.

Uma mensagem pode também conter informação que o objeto solicitante

quer passar ao objeto requisitado. Esta informação é chamada de argumento

da mensagem. Um objeto requisitado sempre retorna um valor de volta ao

objeto solicitante. Este valor retornado pode ou não ser útil ao objeto

solicitante.

Figura 36. Passagem de parâmetro para um objeto.

Na Figura 36, o objeto ESCOLA deseja mudar o nome do objeto ALUNO. Ele

faz isto enviando uma mensagem para modificar o nome para um novo nome.

O novo nome é passado como um argumento na mensagem. Neste caso, o

objeto ESCOLA não se importa com o valor retornado pelo objeto requisitado na

mensagem.

MÉTODO Cada mensagem possui um código associado com ela. Quando um objeto

recebe uma mensagem, o código é executado. Noutras palavras, estas

ESCOLA ALUNO

MENSAGEM

NOME

responda-me o seu nome

ESCOLA ALUNO

MENSAGEM

NOME

Altere “nome” para este “nome”

APÊNDICES 123

mensagens determinam o comportamento do objeto, e o código determina como

o objeto executa cada mensagem. O código que está associado com cada

mensagem é chamado de método. O nome da mensagem é também chamado

de nome do método, devido a sua estreita ligação com o método.

Os métodos que operam sobre objetos específicos são métodos de

instância; e mensagens que invocam métodos de instância são chamados de

mensagens de instância. Já os métodos que operam sobre classes específicas

são métodos de classe.

Quando um objeto recebe uma mensagem, ele determina qual método está

sendo requisitado, e então passa o controle para o método. Um objeto tem

tantos métodos quanto ele necessite para realizar suas ações definidas.

Quando o objeto ALUNO recebe a mensagem nome, esta passa o controle para o

método nome definido em ALUNO (Ver Figura 37).

Figura 37. Métodos de um objeto.

DADOS DO OBJETO Cada objeto precisa manter a informação sobre como realizar o seu

comportamento definido. Alguns objetos também contêm variáveis que

suportam o comportamento deles. Estas variáveis são chamadas de variáveis

de instância. Somente os métodos de instância para um objeto podem se referir

e alterar os valores armazenados nas variáveis de instância. Os métodos de

instância de outros objetos não podem se referir aos dados desse objeto.

De acordo com Figura 38, um objeto só pode acessar os dados de um

outro objeto, se enviar uma mensagem para o objeto requisitado. Isto é

chamado de �encapsulamento de dados�, e garante um processo seguro para se

informar sobre dados do objeto.

INTERFACE

nome

nome:

nome: endereço:

nome

�Rod Smith�

APÊNDICES 124

Considerando o diagrama seguinte, as variáveis de instância �variávelUm�

até �variávelEne� só podem ser acessadas através dos respectivos métodos de

instância métodoUm até métodoEne. O objeto solicitante não pode se referir

diretamente às variáveis.

Figura 38. Acesso aos dados de um objeto.

Diferente da linguagem procedural, onde as áreas de dados comuns são

freqüentemente usadas para compartilhamento de informações, a OOP

desaconselha o acesso direto a dados comuns (outros dados que não são

variáveis globais) por outros programas. Somente o objeto que possui o dado é

que pode alterar o seu conteúdo. Outros objetos podem visualizar ou alterar

este dado enviando uma mensagem para o objeto possuidor do dado.

Os nomes das variáveis de instância podem ser idênticos aos nomes dos

métodos associados com elas. Por exemplo, o objeto ALUNO possui métodos de

nome, endereço, etc.; assim como variáveis de instância �nome�, �endereço�,

etc..

MECANISMO SEQÜENCIAL DE MENSAGENS É comum que uma mensagem encadeie o envio de outras mensagens - ou

por ele mesmo ou por outros objetos � com o intuito de completar a tarefa. Isto

é chamado de �mecanismo seqüencial de mensagens�. O controle não retorna

ao primeiro objeto solicitante, até que todas as outras mensagens sejam

completadas.

No exemplo da Figura 39, um objeto A envia uma mensagem ao objeto B.

Para o objeto B processar a mensagem, ele envia uma outra mensagem ao

objeto C. Igualmente, um objeto C envia uma mensagem ao objeto D. Daí, o

INTERFACE

métodoUm

métodoDois

métodoEne

variávelUm

variávelEne

ObjetoSolicitante

Objeto requisitado

APÊNDICES 125

objeto D retorna para o objeto C, o qual retorna para o objeto B, que então

retorna ao objeto A. O controle não retorna ao objeto A até que todas as outras

mensagens sejam completadas.

Figura 39. Encadeamento seqüencial de mensagens.

Figura 40. Abstração e representação de dados em OOP.

OOSS PPRRIINNCCÍÍPPIIOOSS DDAA OORRIIEENNTTAAÇÇÃÃOO AA OOBBJJEETTOO

Uma linguagem computacional é dita orientada a objetos se elas suportam

os seguintes princípios: abstração, polimorfismo, herança, e encapsulamento.

ABSTRAÇÃO DE DADOS O mecanismo básico utilizado para realização da análise do domínio da

aplicação é a abstração, através da qual um indivíduo observa a realidade

(domínio), e procura capturar a sua estrutura (abstrair entidades, ações,

Objeto A Objeto B Objeto C Objeto D

1 2 3

456

ABSTRAÇÃO

REPRESENTAÇÃO

APÊNDICES 126

relacionamentos, etc., que forem consideradas relevantes para a descrição

deste domínio). O resultado deste processo de abstração é conhecido como

Modelo Conceitual.

Para representar a abstração do conceito, o modelo conceitual pode ser

materializado segundo alguma forma (um desenho, uma maquete, um texto,

um diagrama, etc.). No caso específico da informática, as representações mais

convencionais são as linguagens de programação e as notações auxiliares na

forma de diagramas e figuras, conforme mostrado na Figura 40.

Figura 41. Encapsulamento de dados em OOP.

ENCAPSULAMENTO DE DADOS Na OOP, os objetos interagem uns com os outros através do envio de

mensagens. A única coisa que um objeto sabe a respeito de outro objeto é a

interface do objeto. Cada dado do objeto, e a lógica está escondida de outros

objetos. Noutras palavras, a interface encapsula o código e os dados do objeto

(Ver Figura 41).

Isto permite que o desenvolvedor separe a implementação do objeto, do

seu comportamento. Esta separação cria um efeito �caixa-preta�, onde o

usuário é isolado das mudanças de implementação. Contanto que a interface

permaneça a mesma, quaisquer mudanças da implementação interna é

transparente para o usuário. Por exemplo, se uma mensagem nome é enviada

ao objeto ALUNO, não é importante para o usuário saber como o desenvolvedor

implementou o código para manipular esta mensagem. Todos os objetos

solicitantes precisam é do correto protocolo para interação com o objeto ALUNO.

Métodos Dados

Interface do objeto

INTERFACE

Outros objetos

APÊNDICES 127

O desenvolvedor pode mudar a implementação a qualquer tempo, mas a

mensagem nome ainda funcionará porque a interface é a mesma.

POLIMORFISMO Outro benefício da separação da implementação e comportamento é o

polimorfismo. O polimorfismo permite que dois ou mais objetos respondam a

mesma mensagem. Por exemplo, um método nome poderia também ser

implementado para um objeto da classe CURSO. Mesmo que a implementação

desta mensagem nome possa retornar um número e um título do curso, o seu

protocolo é o mesmo que a mensagem nome para o objeto ALUNO. O

polimorfismo permite que um objeto solicitante se comunique com diferentes

objetos de maneira consistente, sem se preocupar quantas sejam as diferentes

implementações da mensagem.

Uma analogia de polimorfismo com o dia-a-dia, é como os estudantes

respondem ao sino da escola. Todo aluno conhece o significado do sino.

Quando o sino toca (mensagem), entretanto, ele tem seu próprio significado

para diferentes alunos (objetos). Alguns alunos vão para casa, alguns vão para

a biblioteca, e alguns outros vão assistir outras aulas. Todo aluno responde ao

sino, mas como eles respondem pode ser diferente.

Figura 42. Exemplo de polimorfismo em OOP.

Na Figura 42, tem-se um exemplo clássico de polimorfismo com a função

de impressão. Todo objeto imprimível deve saber como se imprimir. A

Documento imprimirPágina

Texto Objeto novo

APÊNDICES 128

mensagem para todos os objetos é a mesma imprimir, mas a implementação

real do que eles devem fazer para se imprimirem, varia.

O objeto solicitante não precisa saber como o objeto requisitado

implementa a mensagem. Somente os objetos requisitados se preocupam sobre

isto. Por exemplo, considere que exista um método imprimirPágina num

objeto DOCUMENTO, o qual tem a responsabilidade de imprimir uma página.

Para imprimir a página, o método imprimirPágina envia a mensagem

imprimir para cada objeto da página. O DOCUMENTO não precisa saber quais

os tipos de objetos estão na página; e sim, se cada objeto suporta o

comportamento de impressão.

Novos objetos podem ser adicionados à página sem afetar o método

imprimirPágina. Este método ainda envia a mensagem imprimir e o novo

objeto fornece o seu próprio método imprimir em resposta àquela mensagem.

O polimorfismo permite que o objeto solicitante se comunique com os

objetos requisitados sem ter que entender qual o tipo de objeto ele é, contanto

que o objeto requisitado suporte a mensagem.

HERANÇA Outro conceito importante da OOP é a herança. A herança permite que

uma classe tenha o mesmo comportamento de uma outra classe, e amplie ou

personalize o comportamento para proporcionar ações especiais para

necessidades específicas.

Figura 43. Exemplo de herança em OOP.

Por exemplo, na Figura 43, ambos os alunos das classes PÓS-GRADUAÇÃO e

GRADUAÇÃO, têm um comportamento similar quanto a gerência do �nome�,

�endereço�, etc.. Ao invés de colocar este comportamento em ambas as classes,

ele é colocado numa nova classe chamada ALUNO. As classes PÓS-GRADUAÇÃO e

Aluno

GraduaçãoPós-graduação

APÊNDICES 129

GRADUAÇÃO tornam-se subclasse da classe ALUNO, e ambas herdam o

comportamento de ALUNO.

As classes PÓS-GRADUAÇÃO e GRADUAÇÃO podem então adicionar

comportamentos específicos delas. Por exemplo, PÓS-GRADUAÇÃO pode estar

num programa de Mestrado ou de Doutorado. Por outro lado, a classe

GRADUAÇÃO pode ser classificado em calouro, iniciante, júnior, e sênior.

Classes que herdam de uma outra classe são chamadas de subclasses. A

classe de quem a subclasse foi herdada, é chamada de super-classe. No

exemplo acima, ALUNO é uma super-classe para as classes PÓS-GRADUAÇÃO e

GRADUAÇÃO. PÓS-GRADUAÇÃO e GRADUAÇÃO são subclasses de ALUNO.

REUSABILIDADE Uma das mais importantes características da programação OOP é a

habilidade de modificar soluções existentes para resolver novos problemas. Se

um problema particular foi resolvido usando um método de OOP, um outro

problema similar, mas ligeiramente diferente, geralmente pode ser resolvido

fazendo pequenas mudanças no protocolo de mensagem do objeto que já

existe. Muitas das vezes, isto requer a adição de novas mensagens. Outros

casos podem exigir a adição de novos objetos e novas mensagens, as quais

aqueles objetos respondem.

SSOOLLUUÇÇÃÃOO DDEE PPRROOBBLLEEMMAASS OORRIIEENNTTAADDOOSS AA OOBBJJEETTOOSS

O método de solução de problemas orientados a objetos é muito similar a

forma humana de resolver os problemas do cotidiano. Ele consiste na

identificação de objetos, e como usar esses objetos na correta seqüência para

resolver o problema.

Noutras palavras, a solução de problemas orientados a objetos consiste

em determinar objetos cujo comportamento resolva um problema específico.

Uma mensagem para um objeto faz com que ele realize sua operações, e

resolva a sua parte do problema.

O método de solução de problemas orientados a objeto, geralmente, pode

ser dividido em quatro passos:

APÊNDICES 130

PASSO 1. Identificar o problema;

PASSO 2. Identificar os objetos necessários para a solução;

PASSO 3. Identificar as mensagens a serem enviadas aos objetos;

PASSO 4. Criar uma seqüência de mensagens para os objetos que

resolvem o problema.

• EXEMPLO

PASSO 1 � Identificação do problema: Calcular a soma de dois números, e

imprimir o resultado.

PASSO 2 � Identificação dos objetos: Identificar objetos necessários para

resolver o problema.

NUM1 � primeiro número;

NUM2 � segundo número;

SOMA � resultado da adição dos números.

PASSO 3 � Identificação das mensagens: Mensagens necessárias a serem

enviadas para os objetos.

+ aNum � Esta mensagem é enviada para o objeto requisitado, com um

parâmetro aNum. O resultado desta mensagem é o valor (um objeto numérico)

do total da soma entre o objeto requisitado e �aNum�.

imprimir � uma mensagem que exibe o valor do objeto requisitado.

PASSO 4 � Seqüências de mensagens do objeto: A seqüência de

mensagens necessárias para resolver o problema.

(NUM1 + NUM2) imprimir

A mensagem + com um parâmetro NUM2 (um objeto), é enviada ao objeto

NUM1. O resultado disto é um objeto (NUM1 + NUM2), para o qual é enviada a

mensagem imprimir.

ESTUDO E DESENVOLVIMENTO DE M T D CAD/CAMgraco.unb.br/alvares/DOUTORADO/papers_omega/ricardo/... ·...

Documents

Transcript of ESTUDO E DESENVOLVIMENTO DE M T D CAD/CAMgraco.unb.br/alvares/DOUTORADO/papers_omega/ricardo/... ·...