features modelamento 3d

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

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

EExxaammee ddee QQuuaalliiffiiccaaççããoo

TTRROOCCAA DDEE DDAADDOOSS EE IINNFFOORRMMAAÇÇÕÕEESS BBAASSEEAADDAASS EEMM FFEEAATTUURREESS NNAASS FFAASSEESS DDEE PPRROOJJEETTOO MMEECCÂÂNNIICCOO

AAPPLLIICCAANNDDOO SSIISSTTEEMMAASS CCAADD Aluno: Raimundo Ricardo Matos da Cunha Curso: Doutorado em Engenharia Mecânica – Programa de Pós-

graduação em Engenharia Mecânica Área de concentração: Projeto de Sistemas Mecânicos com ênfase

em Sistemas CAD/CAE/CAM Orientador: Prof. Altamir Dias, Dr. Eng.

Florianópolis – SC novembro/2000

II

SSuummáárriioo

CAPA............................................................................................................... I

SUMÁRIO ....................................................................................................... II

LISTA DE FIGURAS ........................................................................................ V

LISTA DE TABELAS......................................................................................VII

LISTA DE SIGLAS........................................................................................VIII

RESUMO....................................................................................................... IX

CAPÍTULO 1 – INTRODUÇÃO.......................................................................... 1 1.1. APRESENTAÇÃO GERAL.................................................................................................. 1

1.1.1. Contexto e Motivações da Proposta de Tese ....................................................... 1 1.1.2. Escopo da Proposta .......................................................................................... 4 1.1.3. Objetivos e Contribuições ................................................................................. 6

1.2. TRABALHOS DE REFERÊNCIA PARA A PROPOSTA.................................................................. 7 1.2.1. Trabalhos de Evolução da Informação nas Fases de Projeto............................... 7 1.2.2. Trabalhos de Orientação a Objeto para o Projeto ............................................. 12 1.2.3. Trabalhos de Modelagem de Features para o Projeto ....................................... 13

1.3. TÓPICOS ABORDADOS.................................................................................................. 14 CAPÍTULO 2– REPRESENTAÇÃO DOS DADOS NO PROCESSO DE PROJETO16

2.1. INTRODUÇÃO ............................................................................................................. 16 2.2. MODELO E REPRESENTAÇÃO......................................................................................... 18 2.3. MODELO DO CICLO DE VIDA DO PRODUTO ...................................................................... 20

2.3.1. Modelo Geométrico......................................................................................... 22 2.4. ESTRUTURA DE DADOS DO PRODUTO ............................................................................. 24

2.4.1. Representação da Estrutura de Dados ............................................................ 25 2.5. A INFORMAÇÃO NO PROJETO ........................................................................................ 27

2.5.1. Tipo e Representação da Informação de Projeto ............................................... 28 2.5.2. Representação da Informação nos Projetos Informacional e Conceitual ............ 29

CAPÍTULO 3 – MODELAGEM E PROGRAMAÇÃO ORIENTADA A OBJETOS... 35 3.1. INTRODUÇÃO ............................................................................................................. 35

3.1.1. O Que é POO ou OOP? ................................................................................... 35 3.1.2. O Que é um Objeto? ....................................................................................... 36 3.1.3. Métodos do Objeto.......................................................................................... 37 3.1.4. Dados do Objeto............................................................................................. 38

III

3.2. MECANISMO SEQÜENCIAL DE MENSAGENS ...................................................................... 39 3.3. ESTRATÉGIAS DE ORIENTAÇÃO A OBJETOS ...................................................................... 40

3.3.1. Abstração....................................................................................................... 40 3.3.2. Separação ...................................................................................................... 41 3.3.3. Composição ................................................................................................... 41 3.3.4. Generalização................................................................................................. 41

3.4. O PARADIGMA DA ORIENTAÇÃO A OBJETO....................................................................... 42 3.4.1. Abstração de Dados........................................................................................ 42 3.4.2. Encapsulamento de Dados ............................................................................. 43 3.4.3. Polimorfismo .................................................................................................. 44 3.4.4. Herança ......................................................................................................... 45 3.4.5. Reusabilidade ................................................................................................ 46

3.5. SOLUÇÃO DE PROBLEMAS ORIENTADOS A OBJETOS .......................................................... 46 CAPÍTULO 4 – TECNOLOGIA DE FEATURES APLICADA NO PROJETO

MECÂNICO................................................................................................... 49 4.1. INTRODUÇÃO ............................................................................................................. 49 4.2. CONCEITOS DE FEATURE ............................................................................................. 50 4.3. A DISCUSSÃO FEATURES VERSUS OBJETOS..................................................................... 53

4.3.1. Objetos/Features de Projeto ........................................................................... 54 4.4. DEFINIÇÃO DE FEATURES............................................................................................. 55 4.5. REPRESENTAÇÃO DE FEATURES..................................................................................... 56 4.6. TÉCNICAS DE GERAÇÃO DE FEATURES............................................................................ 57

4.6.1. Reconhecimento Interativo/Manual de Features ............................................. 57 4.6.2. Reconhecimento Automático de Features ........................................................ 57 4.6.3. Projeto por Features (Design by Features) ....................................................... 58

4.7. IDENTIFICAÇÃO DE FEATURES ....................................................................................... 60 4.8. CLASSIFICAÇÃO DE FEATURES....................................................................................... 61 4.9. EXEMPLOS DE FEATURES NO SISTEMA CAD .................................................................... 63

CAPÍTULO 5 – SISTEMAS CAD NO PROJETO MECÂNICO ............................ 65 5.1. INTRODUÇÃO ............................................................................................................. 65 5.2. MUDANÇAS DE APLICAÇÃO DO SISTEMA CAD .................................................................. 66 5.3. RECURSOS COMPUTACIONAIS DOS SISTEMAS CAD ........................................................... 69 5.4. MODELAGEM DE OBJETOS EM CAD............................................................................... 72 5.5. QUESTÕES RELEVANTES NO CONTEXTO DA PROPOSTA....................................................... 74

5.5.1. O CAD com Modelagem de Features e Orientação a Objetos ............................ 74 5.5.2. Outras Questões ............................................................................................ 75

CAPÍTULO 6 – PROPOSTA DE TESE ............................................................. 77 6.1. INTRODUÇÃO ............................................................................................................. 77 6.2. TRANSFORMAÇÃO DOS DADOS DE PROJETO..................................................................... 78

IV

6.3. SISTEMÁTICA DE PROJETO NO SISTEMA CAD................................................................... 80 6.4. IDENTIFICAÇÃO E CLASSIFICAÇÃO DAS FEATURES DE PROJETO............................................ 82

6.4.1. Identificação das Features .............................................................................. 82 6.4.2. Critérios de Classificação................................................................................ 83 6.4.3. Esboço da Proposta de Estrutura de Dados..................................................... 84

6.5. EXEMPLO DE EVOLUÇÃO DOS DADOS DE PROJETO ........................................................... 85 6.6. INTERFACE E ARQUITETURA COMPUTACIONAL .................................................................. 88

6.6.1. Interface da Aplicação para o Usuário ............................................................. 88 6.6.2. Arquitetura Computacional ............................................................................ 90

6.7. CONSIDERAÇÕES FINAIS .............................................................................................. 90 6.7.1. Benefícios da Proposta ................................................................................... 90

CAPÍTULO 7 – PLANEJAMENTO DAS ATIVIDADES DE IMPLEMENTAÇÃO DA

TESE............................................................................................................ 92 7.1. INTRODUÇÃO ............................................................................................................. 92 7.2. CRONOGRAMA DE ATIVIDADES ...................................................................................... 96 7.3. MATERIAIS E EQUIPAMENTOS........................................................................................ 96

REFERÊNCIAS BIBLIOGRÁFICAS................................................................. 98

BIBLIOGRAFIAS ..........................................................................................101

V

LLiissttaa ddee FFiigguurraass

Figura 1. Evolução do processo de projeto. ............................................................................. 7 Figura 2. Metodologia de projeto proposta por Pahl e Beitz.................................................... 17 Figura 3. Relacionamento entre modelos do ciclo de vida do produto..................................... 21 Figura 4. Estrutura de dados em árvore binária para esquema CSG...................................... 23 Figura 5. Estrutura de dados para esquema B-Rep............................................................... 23 Figura 6. Exemplo genérico de estrutura do produto............................................................. 25 Figura 7. Exemplo de uma estrutura de dados computacional do produto. ............................ 26 Figura 8. Transformação das informações no projeto informacional....................................... 29 Figura 9. Matriz para levantamento das necessidades........................................................... 31 Figura 10. Matriz para conversão dos requisitos de usuário em requisitos de projeto............. 31 Figura 11. Exemplo de questionário estruturado para levantamento de necessidades ............ 32 Figura 12. Estrutura de função do produto numa forma hierárquica e representada por ícones

..................................................................................................................................... 32 Figura 13. Exemplo de matriz morfológica para representação das alternativas de solução do

problema....................................................................................................................... 33 Figura 14. Mecanismo de mensagens: interface de comunicação entre os objetos. ................. 36 Figura 15. Mecanismo de mensagem entre dois objetos. ....................................................... 37 Figura 16. Passagem de parâmetro para um objeto............................................................... 37 Figura 17. Métodos de um objeto.......................................................................................... 38 Figura 18. Acesso aos dados de um objeto............................................................................ 39 Figura 19. Encadeamento seqüencial de mensagens. ............................................................ 39 Figura 20. Abstração e representação de dados em POO. ...................................................... 42 Figura 21. Encapsulamento de dados em POO. .................................................................... 43 Figura 22. Exemplo de polimorfismo em POO. ...................................................................... 44 Figura 23. Exemplo de herança em POO............................................................................... 45 Figura 24. Passos de criação de um modelo de objetos.......................................................... 48 Figura 25. Evolução dos modeladores geométricos................................................................ 50 Figura 26. Abstração do contexto de OBJETOS e FEATURES. ............................................... 54 Figura 27. Contextos relevantes na definição de uma feature. ............................................... 60 Figura 28. Exemplo de features básicas, genéricas e especializadas no MicroStation Modeler

v7.1............................................................................................................................... 64 Figura 29. Barra de ferramentas das features definidas no sistema CAD Solidworks.............. 64 Figura 30. Barra de ferramentas das features definidas no sistema CAD Solid Edge. ............. 64

VI

Figura 31. Evolução da tecnologia dos sistemas CAD. ........................................................... 69 Figura 32. Exemplo de perfis bidimensionais gerando formas sinuosas. ................................ 71 Figura 33. Biblioteca de componentes padronizados disponíveis no MicroStation/J Modeler

v7.1............................................................................................................................... 71 Figura 34. Fases de projeto com as respectivas entradas e saídas. ........................................ 79 Figura 35. Fases de projeto e documentação do produto. ...................................................... 79 Figura 36. Processos x Fases de Projeto – Produto x Dados e Informações. ............................ 80 Figura 37. Classificação de features no processo de projeto................................................... 84 Figura 38. Mecanismo a ser projetado utilizando o modelo de features. ................................. 86 Figura 39. Esboço de uma peça numa fase de projeto preliminar. ......................................... 87 Figura 40. Detalhamento final do modelo geométrico. ........................................................... 88 Figura 41. Visão geral das fases de implementação da tese. .................................................. 95 Figura 42. Cronograma de Atividades ................................................................................... 96

VII

LLiissttaa ddee TTaabbeellaass

Tabela 1. Fases do projeto de uma casa................................................................................ 11 Tabela 2. Evolução das estratégias de modelagem orientada a objetos. .................................. 12 Tabela 3. Definição de uma ontologia de termos e conceitos .................................................. 19 Tabela 4. Categorias de informação na fase de projeto informacional..................................... 30 Tabela 5. Estratégias de projeto de software em POO ............................................................ 42

VIII

LLiissttaa ddee SSiiggllaass

API – Application Programming Interface ........................................................ 14

B-Rep – Boundary Representation ................................................................. 23

CAD – Computer-Aided Design ........................................................................ 2

CAFD – Computer-Aided Fixture Design......................................................... 58

CAM – Computer-Aided Manufacturin ............................................................ 49

CAPP – Computer-Aided Process Planing ....................................................... 50

CAX – Computer-Aided "X" ............................................................................ 67

CNC – Computer Numerical Control................................................................ 57

CSG – Constructive Solid Geometric ............................................................... 22

DBMS – Database Management System ........................................................ 34

FEM – Finite Element Method ........................................................................ 24

GT – Group Technology ................................................................................. 51

JDBC – Java Database Connectivity.............................................................. 70

JMDL – Java MicroStation Development Language......................................... 14

KBE – Knowledge-based Engineering ............................................................ 56

MDL – MicroStation Development Language ................................................... 70

ODBC – Open Database Connectivity............................................................. 70

OMT – Object Modeling Technique ................................................................. 48

OOA – Object-Oriented Analysis .................................................................... 48

OOP – Object-Oriented Programming.............................................................. 35

POO – Programação Orientada a Objetos ...................................................... 35

QFD – Quality Function Deployment .............................................................. 91

UML – Unified Modeling Language................................................................. 48

IX

RReessuummoo

As informações e os dados de projeto possuem características geométricas e não-

geométricas. Estes dois tipos de informação precisam ser encapsulados numa estrutura de

dados única – as features de projeto –, para terem um significado de aplicação. A idéia é

utilizar o conceito de modelagem por features para fazer a identificação de informações e dados

de cada uma das fases do projeto mecânico, buscando encontrar uma assinatura de cada fase do projeto. Além disso, o conjunto de features da fase atual deve ser uma evolução da

informação geométrica e não-geométrica da fase anterior.

Os objetivos principais são: Modelar features de projeto que encapsulam a evolução dos

dados e informações de Engenharia nas fases de projeto; Capturar a intenção do projetista ao

utilizar as features definidas e implementadas no sistema CAD; Reusar, trocar e compartilhar

essas informações num ambiente computacional de CAD.

A pesquisa se concentra no estudo da tecnologia de features numa visão voltada para o

projeto, e modelagem com base nos princípios de orientação a objetos. A abordagem inicial

consiste na identificação e classificação de features que evoluam nas diferentes fases do projeto

mecânico de produtos. Para isso será implementada uma interface computacional que permita

instanciar features próprias de cada fase do projeto e editar a informação não-geométrica

necessária para dar um significado de aplicação. Numa etapa de testes e validação, faz-se a

importação das features instanciadas para dentro do ambiente de um sistema CAD

convencional, a fim de criar o projeto detalhado do produto.

A proposta contribui para comprovar a necessidade de mudança na forma de pensar a

estrutura de dados em que um sistema CAD deve ser construído. Juntos, os conceitos e

modelos de objetos e features definidos, possibilitarão a captura do significado de Engenharia

embutido nas entidades gráficas de um sistema CAD convencional. Além disso, as features

identificadas devem servir de informação útil para o projetista e resultar num sistema CAD

mais integrado às fases informacional, conceitual, preliminar e detalhada da sistemática de

projeto.

CCaappííttuulloo 11

IInnttrroodduuççããoo

11..11.. AAPPRREESSEENNTTAAÇÇÃÃOO GGEERRAALL

Neste capítulo, é feita uma apresentação geral da proposta, para tornar

mais claro os relacionamentos entre os tópicos abordados.

O objetivo principal é evidenciar o escopo de atuação – Quais são as

principais áreas de conhecimento da proposta de tese? –, e que certamente

exigirão pesquisas mais detalhadas.

Na seqüência, são descritas as motivações que levaram à escolha do tema

de pesquisa, citando quais são os objetivos e as possíveis contribuições da

implementação desta proposta de tese. Citam-se também os trabalhos

referenciais que se alinham com as idéias descritas nesta proposta.

1.1.1. CONTEXTO E MOTIVAÇÕES DA PROPOSTA DE TESE

Algumas questões, provenientes de conversas, discussões e leitura de

referências bibliográficas sobre o tema, motivaram essa proposta de tese.

Numa maneira de iniciar e incitar a discussão, as principais questões foram

listadas a seguir:

• Quais são os dados e informação de projeto que podem ser identificados

CAP. 1 – INTRODUÇÃO 2

e modelados por features de projeto?

• Como os dados de projeto evoluem e se transformam?

• De quais formas os dados de projeto podem ser integrados e capturados

num sistema CAD?

• Como e o que é preciso, em termos computacionais, para propiciar e

estender funcionalidades de apoio ao projeto dentro dos sistemas CAD?

A partir das questões levantadas acima, é possível concluir que as

necessidades atuais de mercado e o avanço das pesquisas na área de projeto

mecânico resumem-se a dois importantes enfoques de discussão, os quais

serão considerados nesta proposta:

• Um nível mais básico, relacionado à questão da modelagem e representação computacional da informação e dados de projeto;

• E um segundo nível, relacionado à questão da integração de ferramentas computacionais de suporte ao projeto mecânico de

produtos.

O primeiro ponto acima consiste na modelagem e representação de dados

de projeto baseados em features de projeto e implementadas conforme os

princípios de orientação a objetos. Essa visão é requisito básico para

consolidação de uma renovada aplicação da ferramenta CAD no projeto,

contribuindo para o estado da arte em sistemas CAD.

Já o segundo ponto é entendido como sendo uma aplicação do primeiro.

Nessa proposta a modelagem será direcionada para realizar a captura,

recuperação, armazenamento e a evolução das informações e dados nas fases

de projeto, contribuindo para o estado da arte em suporte computacional ao

projeto mecânico de produtos. Como resultado é esperada a validação da

estrutura de dados de projeto baseados em features.

Atualmente, esses pontos são temas em pesquisas de aplicação dos

sistemas CAD (Computer-Aided Design), nos tópicos de: Modelagem de Dados

de Projeto, Tecnologia de Features, Padrões para Troca de Dados de Projeto. E

essas áreas de conhecimento, por sua vez, conduzem a uma outra diversidade

de áreas de pesquisas relacionadas ao projeto mecânico, tais como:


Metodologias de Projeto, Desenvolvimento de Produto, Implementação de

Ferramentas Computacionais de Suporte ao Projeto Mecânico.

Em razão disso, alguns fatores diretos e indiretamente relacionados

estimulam a desenvolver pesquisas dentro desse contexto, e convencem da

possibilidade de contribuir para o estado da arte em sistemas CAD aplicados

ao suporte computacional do projeto mecânico de produtos:

• Não existem evidências ou argumentos claros do significado ou

interpretação de features no contexto de projeto, e qual a relação de

equivalência com o conceito de objeto no contexto de representação

computacional da informação. Apesar dos anos de pesquisas em

tecnologia de features e aplicação da modelagem orientada a objetos,

ainda hoje esses pontos geram uma certa polêmica e algumas

obscuridades sutis. O principal motivo disso é devido ao

amadurecimento ainda incipiente em tratar com os conceitos de ambos

os contextos, seja de orientação a objeto quanto de tecnologia de

features. O Capítulo 4 inicia uma discussão sobre a relação de

equivalência entre os conceitos de objetos e features, com o objetivo de

contribuir para o esclarecimento dos conceitos básicos dessa proposta

e incitar outras opiniões e pontos de vista;

• Principalmente nas fases iniciais do processo de projeto verifica-se uma

falta estrutura de dados e interfaces computacionais para lidar com a

informação e os dados de projeto mais subjetivos, não-geométricos, que

não possuem uma conotação de valor ou quantidade. Vários autores

tiveram essa conclusão: (ULLMAN et al., 1990), (HSU e WOON, 1998), e

(OGLIARI, 1999). Em suma, está se falando da informação e dos dados

que geralmente são processados na mente do projetista (as intenções),

mas que não são refletidos e capturados no modelo de informação do

projeto ou produto, e que por isso não são compartilhados ou

reusados. No Capítulo 2 descreve algumas formas de representação

computacional desses dados de projeto, e no Capítulo 6 tem-se a

proposta de estrutura de dados baseada em features que capturam a

informação de projeto nas fases;


• Necessidade de integração entre ferramentas computacionais, que

favoreçam a reusabilidade e interoperabilidade de informações e dados

de projeto.

Esta proposta direciona-se para um melhoramento da representação

computacional dos dados, voltada para o contexto de projeto dentro de um

sistema CAD, numa linha de pensamento já levantada por (WARMAN, 1990) –

A Modelagem de Objetos no Sistema CAD. Dessa forma, estar-se-á

preparando uma base de modelagem computacional sólida e consistente, com

as vantagens que a orientação a objetos pode oferecer. As atividades

subseqüentes do ciclo de vida do produto podem usar toda implementação

realizada, e assim reusá-la noutro contexto de aplicação, seja de Planejamento

do Processo (projeto de sistemas de fixação de peças), Fabricação (geração do

código comando numérico), Análise de Tensão (geração de malhas para

elementos finitos), Análise de Montabilidade, ou em outras atividades de

interesse de Engenharia e do ciclo de vida do produto.

Como contribuição importante desse trabalho para outros futuros

trabalhos extensíveis ou relacionados a esse, é importante que se tenha

iniciado uma discussão, reflexão e alguns direcionamentos no sentido de

apontar para a necessidade de mudança na forma de pensar e representar a

estrutura de dados em que um sistema CAD deve ser construído.

Na literatura científica existem diversos trabalhos que discutem temas

relacionados a essa pesquisa. Todos eles acrescentam contribuições e

conseguem avanços em pontos isolados ou específicos. Normalmente, a

contribuição resulta num protótipo computacional, que implementa as idéias

defendidas. No tópico de revisão bibliográfica, esses trabalhos são discutidos

com mais detalhes.

1.1.2. ESCOPO DA PROPOSTA

Pelo que foi introduzido no tópico de contextualização da proposta de tese,

o escopo dessa pesquisa abrange dois itens principais, os quais se constituem

na maior parte da discussão colocada no texto, a saber:

• A modelagem de dados e de estruturas de dados computacionais


baseadas em features para o projeto mecânico com sistemas CAD;

• O suporte computacional na evolução e transformação das informações

e dados de projeto mecânico de produtos durante as fases de projeto.

As informações e os dados de projeto possuem características geométricas

e não-geométricas. Estes dois tipos de informação precisam ser encapsulados

numa estrutura de dados única, e então assumirem um significado para um

contexto de aplicação mais específica. Nesta proposta, as features de projeto

são consideradas como unidades de informação, servindo como meio de

representação computacional para transmissão da informação de projeto.

Pretende-se utilizar o conceito de modelagem por features para fazer a

identificação de informações e dados de cada uma das fases do projeto

mecânico, buscando encontrar uma assinatura de cada fase do projeto. E

dessa forma, o conjunto de features da fase atual deve ser uma evolução da

informação geométrica e não-geométrica da fase anterior.

A abordagem inicial consiste na identificação e classificação de features

que evoluam nas diferentes fases do desenvolvimento do produto. Para isso

será implementada uma interface computacional que permita instanciar

features próprias de cada fase do projeto e editar a informação não-geométrica

necessária para dar um significado de aplicação. Numa etapa seguinte de

testes e validação, faz-se a importação das features instanciadas para dentro

do ambiente de um sistema CAD convencional, a fim de criar o projeto

detalhado do produto.

Essa proposta vai ao encontro de uma solução que facilite para o

projetista desenvolver sua atividade principal; que é projetar, mas usando uma

ferramenta com interface computacional melhorada e integrada. É importante

também que, para fins de sistematização e facilidade de integrar-se ao projeto e

demais etapas subseqüentes do ciclo de vida do produto, propõe-se que a

modelagem de dados considere a evolução baseada numa sistemática de

projeto com fases bem definidas.

A partir do sistema CAD, aliado a uma nova visão de aplicação dessa

ferramenta no processo de projeto, é que se vislumbrará a integração

necessária para utilização de outros sistemas e recursos computacionais já


disponíveis, tais como: bases de dados de componentes padronizados,

bibliotecas de features, banco de dados de funções de produtos e princípios de

solução, regras especialistas, etc.. Maiores detalhes sobre os recursos

computacionais disponíveis nos sistemas CAD são citados no Capítulo 5.

No desenvolvimento desses pontos de discussão, exige-se conhecimento

adquirido e experimentado dos princípios de modelagem orientada a objeto e de

features, além de conhecimento de como são definidos, representados, e

processadas as informações e os dados de projeto. O conhecimento prévio

dessas técnicas de modelagem é básico para visualizar contribuições nesta

área de projeto auxiliado por computador, e o que é mais importante – propor

alternativas de solução. O Capítulo 3 traz mais detalhes sobre os fundamentos

da modelagem orientada a objetos, e o Capítulo 4 complementa com as

definições sobre a tecnologia de features.

É importante deixar claro a posição de destaque do sistema CAD nessa

proposta de tese, atuando como uma plataforma-cliente para a implementação

de ferramentas computacionais de apoio ao projeto. O sistema CAD também

será a ferramenta que se beneficiará dos resultados obtidos com a

implementação das idéias aqui defendidas.

1.1.3. OBJETIVOS E CONTRIBUIÇÕES

Utilizando os princípios de modelagem orientada a objeto e de features de

projeto, pretende-se:

• Definir classes de features que encapsulem os atributos relevantes

para capturar e caracterizar a evolução e transformação das

informações e dados de projeto;

• Proporcionar meios de recuperação e visualização da evolução e

transformação das informações e dados de Engenharia no modelo

geométrico, para a documentação do projeto mecânico;

• Proporcionar o reuso, a troca e o compartilhamento dos dados de

projeto através de uma estrutura de classes de features de projeto

incorporada a um sistema CAD;

• Contextualizar os conceitos de features de projeto e objetos,

ressaltando similaridades e diferenças;


• Capturar aspectos da intenção do projetista para dentro do modelo

geométrico sólido gerado pelo sistema CAD.

A satisfação desses objetivos passa pela obtenção de uma forma

computacional representativa da forma de pensar do projetista. Dentre os

modelos computacionais, o modelo de objetos é o que mais se aproxima e pode

atender esses requisitos da atividade de projetar. Juntos, os conceitos e

modelos de objetos e features definidos, possibilitarão a captura do significado

de Engenharia embutido nas entidades gráficas de um sistema CAD

convencional. Além disso, as features identificadas devem servir de informação

útil para o projetista, e resultar num sistema CAD mais integrado às fases de

projeto informacional, conceitual, preliminar e detalhado.

11..22.. TTRRAABBAALLHHOOSS DDEE RREEFFEERRÊÊNNCCIIAA PPAARRAA AA PPRROOPPOOSSTTAA

1.2.1. TRABALHOS DE EVOLUÇÃO DA INFORMAÇÃO NAS FASES DE PROJETO

As pesquisas agora estão se direcionando para dar suporte às fases

iniciais do processo de projeto, além da fase de projeto detalhado.

Segundo Van Der Net, citado em (MAZIERO, 1998), um único modelo do

produto deveria ser suficiente para descrever as informações em todos os

estágios de projeto e processos de manufatura. Estando as informações num

único modelo, elas seriam interpretadas conforme a necessidade dos diferentes

estágios. Como mostrado na Figura 1, utilizam-se conceitos de estado e estado

de transição para descrever o projeto de produtos, considerando que um estado

de transição usa um estado como entrada e que o resultado é um novo estado.

Figura 1. Evolução do processo de projeto.

TRANSFORMAÇÃO DE PROJETO PROJETO

estado n

PROJETO

estado (n + 1)

Decisões de projeto


(MCGINNIS e ULLMAN, 1992) afirmam que as alterações de estado são por

causa das decisões de projeto tomadas, evidenciadas pelas alterações sofridas

nos atributos das restrições de projeto.

Para Van Der Net, o modelo do produto pode servir para satisfazer três

necessidades básicas:

• Numa visão de integração das fases do ciclo de vida do produto – serve

para capturar e registrar as intenções, desejo e raciocínio do projetista;

• Numa visão de projeto – serve para criar uma descrição consistente do

produto para auxiliar o próprio projeto, assim como atividades

subseqüentes do ciclo de vida;

• E numa visão de fabricação – permite analisar a manufaturabilidade do

produto, simultaneamente ao desenvolvimento do projeto.

(MCGINNIS e ULLMAN, 1992) escreveram um artigo onde a evolução do

projeto de componentes mecânicos foi traçada desde a sua concepção até o

projeto completo. Os autores definiram um conjunto de restrições, que

serviram de estrutura para um protocolo de captura das intenções do

projetista. Este protocolo formal foi estruturado com base no protocolo verbal

dos projetistas, quando os mesmos trabalhavam em cima de um problema de

projeto. Essa técnica é conhecida como “Análise de Protocolo”, e envolveu o uso

de vídeo e gravação para captura da verbalização dos projetistas durante a

sessão de projeto.

Os critérios adotados para construção do protocolo consistiram em

identificar restrições, as quais eram classificadas de acordo com a sua fonte

(origem), o nível de abstração, a forma e a função. Os autores verificaram que o

projeto de um componente exige a identificação de três tipos de restrições:

inicialmente começa com a determinação de restrições de forma e função; a

seguir, inclui restrições oriundas do domínio de conhecimento do projetista; e

finalmente aquelas restrições derivadas de cada decisão realizada durante o

andamento do projeto. Esse inter-relacionamento de restrições é que

constituem o refinamento de informação sobre o componente. Identificando as

restrições, o passo seguinte consiste em esclarecer as definições e os

relacionamentos delas com as features de projeto.


Neste trabalho, os autores identificaram dois tipos de estruturas

protocolares para caracterizar o relacionamento entre restrições e features de

projeto. Esses protocolos de relacionamento são exemplificados a seguir:

Tem-se o protocolo de instanciação das features:

• <feature de forma> – <instanciação>

• <feature funcional> – <instanciação>

Ex.: [tempo de operação – é de 40s]; ou [profundidade do furo – ≥ 10mm]

Tem-se o protocolo de relacionamento entre features:

• <feature dependente – relação – feature independente(s)>

O protocolo acima estabelece que uma ou mais features restringem uma

única feature. Ao todo, identificaram-se dez possibilidades de protocolos

correspondendo ao padrão acima. Por exemplo:

• <feature de forma> – <relação de forma> – <feature independente(s)>

Ex.: [posição do furo – no meio de (a) – base de apoio]

• <feature de forma> – <relação funcional> – <feature independente(s)>

Ex.: [furo central – suporta – eixo principal]

Esse trabalho desenvolvido por McGinnis e Ullman resultou em idéias

fundamentais para o entendimento de relacionamentos entre restrições e

features de projeto, e sua evolução no processo de projeto mecânico. Outros

trabalhos que podem substanciar a discussão dessa temática estão em

(ULLMAN et al., 1988) e (ULLMAN, 1990).

Uma representação da evolução e transformação dos dados de projeto

baseada num modelo de features foi proposta por (ACHTEN e LEEUWEN,

1998). Neste trabalho, os autores realizaram um estudo de caso aplicado ao

domínio do projeto arquitetônico (projeto de uma casa).

Baseado nos desenhos mostrados na Tabela 1, os quais correspondiam às

fases de projeto, fez-se uma análise conforme os passos citados a seguir:

• Em cada fase (desenho), fez-se uma identificação das informações a

serem definidas como features, de forma a ficar ciente do tipo de

informação a ser tratada no problema;

• Se os elementos são novos, faz-se a definição e o registro dos tipos de


features simples e complexas necessárias. Aqui, cabe uma análise do

que realmente é importante incluir na definição da feature, a fim de

estabelecer o quanto genérica é a feature;

Ex.: Exemplo de um tipo de feature Space, dado pelos autores

complex BuildingElement.space.Space { TypeDate {23/10/2000} TypeAuthor {RR} TypeDescr {“Space element within which activities can take place”} Spec BuildingElement.space.Space contains[0..?] Spec User.value.Daylighting datlightIsUsed[1..1] Spec User.value.Function function; Has BuildingElement.structure.Rooftype kindOfRoof; Spec User.value.NumberOfPersons; }

• No caso de features já definidas, faz-se a instanciação dos

correspondentes objetos, preenchendo os respectivos atributos.

Ex.: A instanciação de uma feature Space Living, dado pelos autores

Building.space.Space Living = { contains[1] = Dining contains[0] = Sitting function = FunctionLiving }

Os tipos e as instâncias das features são definidos e representados

textualmente através de uma linguagem de definição própria, chamada de

FTDL – Feature Type Definition Language, tal como mostrado nos exemplos

acima. Essa linguagem é suportada por uma ferramenta desenvolvida no

âmbito do trabalho, e descritas em outros trabalhos do grupo de pesquisa.

A partir da especificação de projeto, a qual é relatada como “relatório de

projeto”, os autores identificam os objetos presentes, os quais constituirão o

modelo de features (objetos). Os objetos instanciados são os elementos que

encapsulam as informações de projeto e que servirão de meio para visualizar a

evolução durante as fases do projeto. Alguns objetos são instanciados como

features (Space, Door, Roof, Table, Function, etc.). E outros como restrições

do tipo interfeatures (Space_adjacent_Space, Stair_NOTin_Space), de acesso

(Space_Space), e visuais (Space_NOTvisual_Space). Esta fase é considerada

como sendo a “fase 0” do projeto.


Tabela 1. Fases do projeto de uma casa (ACHTEN e LEEUWEN, 1998).

Fase 1: O relatório funcional é convertido em

espaços posicionados na planta do projeto, dando

uma indicação do espaço requerido e do leiaute. A

massa principal é localizada a noroeste, deixando

espaço para o jardim. O módulo usado é de 1,20 m.

Ele é um “módulo-rascunho” usado pelo arquiteto.

Fase 2: Muitos espaços estão localizados no piso

térreo. O estudo da fachada mostra a construção na

vista frontal, incluindo posicionamento de janelas e

a forma do teto.

Fase 3: O arquiteto usa uma grade “1” para

estabelecer uma escala das dimensões ocupadas

pelos espaços principais do projeto. O uso de uma

segunda grade (grade “2”) é para o piso da garagem,

que está posicionada no canto superior esquerdo.

Concluiu-se que a garagem, posicionada

ortogonalmente em relação aos demais espaços,

tornar-se-ia muito visível (dominante), por isso a

rotação da grade 2 com relação à grade 1.

Fase 4: A parte central da construção está baseada

na grade 2. Os espaços são colocados de acordo

com a nova grade, para ver como foi calculado.

Os autores concluíram que o modelo de produto baseado em features,

juntamente com outras tecnologias (tais como realidade virtual), consolida-se

como um formalismo adequado para a representação da evolução dos dados

durante as fases de projeto e captura das intenções do projetista.

Considerando estes trabalhos, surge o interesse nessa proposta de

estender essa mesma idéia para o contexto do projeto mecânico de produtos

industriais.

Fase 1

Fase 2

Fase 3

Fase 4


1.2.2. TRABALHOS DE ORIENTAÇÃO A OBJETO PARA O PROJETO

Durante toda a década de 90, o modelo computacional mais recomendado

para a modelagem de dados foi o modelo baseado em objetos (WARMAN, 1990)

(KUMAR et al., 1999). E essa escolha ainda prevalece para os dias atuais e o

para o futuro da modelagem de entidades computacionais. A Tabela 2, baseada

em (KUMAR et al., 1999), mostra a evolução das estratégias de modelagem com

objetos.

Tabela 2. Evolução das estratégias de modelagem orientada a objetos.

ANO APLICAÇÕES ATRIBUTOS DOS OBJETOS REPRESENTAÇÃ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 – 1980 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

Modelos de objetos

(WARMAN, 1990) discutiu o uso do método orientado a objetos em projeto,

associado à aplicação de sistemas CAD. Ele defende que no projeto, todas as

manifestações da criatividade se baseiam em métodos gráficos para capturar a

intenção ou o raciocínio do projetista. Por isso, todos os métodos gráficos

devem ser “imitados” na interface do projetista com o computador. Quanto à

informação de projeto e interação computacional, Warman sugere uma forma

de diálogo, no qual os elementos podem ser editados e manipulados como

objetos, pesquisa em base de dados e definição do problema de projeto.

Dependendo da fase particular do ciclo de vida de projeto existem no mínimo

dois tipos de necessidades de informação: uma informação da visão geral do

estado atual do projeto; e a informação detalhada relacionada a aspectos

particulares de projeto.

Pelo que se tem pesquisado na Internet, e em alguns trabalhos sobre a

aplicação de modelagem orientada a objetos no âmbito dos sistemas CAD,

percebe-se uma tendência inicial com aplicações na área de Arquitetura e


Construção Civil (ACHTEN e LEEUWEN, 1998) e (DAY, 2000).

Essa necessidade de utilizar a modelagem de objetos é crescente na área

de Projeto e Desenvolvimento de Produto, e é a tendência atual do mercado.

1.2.3. TRABALHOS DE MODELAGEM DE FEATURES PARA O PROJETO

O modelo de dados está sendo melhorado, à medida que a tecnologia de

Computação Gráfica, Teoria de Modelagem de Sólidos e a Engenharia de

Software vêm também evoluindo, e juntamente com a evolução dos

computadores e meios de comunicação. Para o futuro próximo dos sistemas

CAD devem incorporar estas novas ou renovadas características.

No estágio atual, o patamar de abstração de captura das intenções do

projetista tem se baseado em definições de features básicas e de features

específicas de aplicações mais comumente realizadas ou de natureza particular

(forma, funcional, montagem, material, estética, etc.). Os modelos baseados em

features são mais flexíveis, pois podem enfocar diferentes visões de um

produto. Essa característica da modelagem por features está de acordo com a

natureza dinâmica do projeto.

Para eliminar ou reduzir as deficiências dos sistemas CAD atuais, tem-se

usado a tecnologia de features, que possibilita a representação das informações

tão necessárias para integração das atividades do ciclo de vida do produto.

Para (SHAH, 1991), dentro do contexto de Engenharia, features são

formas genéricas que os engenheiros associam certas propriedades ou

atributos e conhecimentos úteis em processos de raciocínio sobre o produto, ou

seja, as features podem ser vistas como primitivas de Engenharia.

(SALOMONS, 1993) afirma que as features podem ser tratadas como

objetos de projeto, pertencendo a uma classe geral, a qual herda propriedades

de outras classes.

No âmbito dessa proposta de tese vem sendo desenvolvido um trabalho de

Mestrado de implementação computacional utilizando o sistema CAD

MicroStation/J, da Bentley. O trabalho enfatiza a questão da integração do

sistema CAD com informações de features colocadas num banco de dados

relacional Access, da Microsoft, na fase de detalhamento de projeto. Já fornece

indícios da possibilidade de integração da informação de projeto através de


modelos baseados em features implementadas a partir de perfis

parametrizados bidimensionais armazenados numa biblioteca de perfis. Esse

trabalho pretende personalizar uma arquitetura computacional constituída por

banco de dados relacional, sistema CAD, e algumas features básicas já

existentes no sistema CAD. A personalização deve ser implementada usando a

linguagem de programação Java, disponível dentro do sistema CAD

MicroStation/J através de uma API – Application Programming Interface

chamada JMDL – Java MicroStation Development Language.

11..33.. TTÓÓPPIICCOOSS AABBOORRDDAADDOOSS

A proposta de tese colocada neste trabalho é constituída pela abordagem

dos seguintes tópicos:

O Capítulo 2 que trata da Representação dos Dados no Processo de Projeto – discute sobre o tipo de informação, técnicas de captura, e das formas

utilizadas para representar as informações dentro das fases de projeto.

O Capítulo 3 que trata da Modelagem e Programação Orientada a Objetos – discute os conceitos básicos sobre objetos e modelagem orientada a

objetos.

O Capítulo 4 que trata da Tecnologia de Features Aplicada no Projeto Mecânico – discute os conceitos sobre a tecnologia de features e mostra as

vantagens em adotar esse modelo como unidade de informação de projeto.

Juntos, os dois capítulos fornecem grande parte da base teórica necessária

para a implementação dessa proposta de tese.

O Capítulo 5 que trata dos Sistemas CAD no Projeto Mecânico – faz

uma descrição dos recursos disponíveis nos sistemas CAD para aplicações de

projeto.

O Capítulo 6 que trata da Proposta de Tese – descreve em mais detalhes

os objetivos principais e o enfoque de aplicação da proposta.

E para encerrar o texto, é colocado um capítulo que trata sobre o

planejamento e cronograma de Atividades, e sobre os recursos e materiais

necessários para implementação da proposta de tese.


RReepprreesseennttaaççããoo ddooss DDaaddooss nnoo PPrroocceessssoo ddee PPrroojjeettoo

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

Os modelos de projeto utilizados na Engenharia se resumem 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, citam-se as várias metodologias de

projeto descritas na literatura.

• 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 do projeto, que pode assumir formas

diferenciadas dependendo do enfoque ou contexto. Estes modelos

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

No desenvolvimento de ferramentas computacionais de suporte ao

CAP. 2 – REPRESENTAÇÃO DOS DADOS NO PROCESSO DE PROJETO 16

processo de projeto exige-se que o projeto aconteça com base no entendimento

do processo de projeto, a fim de que a integração da ferramenta e da

metodologia seja otimizada. Por isso, é importante considerar a proposta de

metodologia de projeto mais representativa do processo de projeto, por ser a

mais referenciada em trabalhos dessa área. Trata-se da metodologia proposta

por Pahl e Beitz, resumida na Figura 2. Ela é considerada uma abordagem

tradicional ou clássica na área de projeto de produtos industriais, e reflete a

linha de pensamento básico da escola alemã.

A metodologia de Pahl e Beitz enfoca além dos aspectos procedurais da

atividade de projeto, também enfoca aspectos relacionados à percepção,

cognição e modelagem do problema de projeto. O objeto de projeto é tratado

como um sistema técnico, constituído pela transformação de energia, material

e informação, e cujo comportamento funcional é determinado por princípios

baseados em leis físicas.

Figura 2. Metodologia de projeto proposta por Pahl e Beitz.

Tarefa Elaborar as especificações

Especificações Identificar os problemas essenciais Estabelecer a estrutura de funções Pesquisar princípios de solução Combinar e concretizar em variantes de concepção Avaliar segundo critérios técnicos e econômicos

Desenvolver leiautes e formas preliminares Selecionar o(s) melhor(es) leiaute(s) preliminar(es) Refinar e avaliar sob critérios técnicos e econômicos

Otimizar e completar o projeto das formas Verificar erros e controlar custos Preparar a lista das partes preliminares e os documentos de produção

Finalizar os detalhes Completar os desenhos detalhados e documentos de produção Verificar todos os documentos

Concepções

Leiaute Preliminar

Leiaute Definitivo

Documentação

tarefa

Concepção

Projeto Preliminar (de configuração)

Projeto Detalhado

Definição da Definição da tarefa

Solução


Embora seja uma abordagem clássica da metodologia de projetos, a

seqüência das fases, passos, atividades e ações podem ser consideradas como

guia para uma abordagem de Engenharia Simultânea.

Considerando uma visão global das propostas de metodologias de projeto,

consensualmente elas abordam quatro fases, as quais podem ser resumidas

quanto às ações e resultados obtidos em cada etapa, a saber:

• Projeto informacional: definição das especificações de projeto;

• Projeto conceitual: seleção de uma alternativa de solução conceitual;

• Projeto preliminar: encorpamento do leiaute do produto;

• Projeto detalhado: detalhamento de dimensões, tolerâncias do

produto, e documentação final.

Os resultados de cada etapa precisam ser representados em modelos. E

esses modelos, que próprios do processo de projeto, por sua vez precisam ser

representados no computador, numa forma que imite a representação

entendida pelo projetista.

22..22.. MMOODDEELLOO EE RREEPPRREESSEENNTTAAÇÇÃÃOO

Um modelo busca representar de algum modo a realidade através de

informações. O conteúdo da informação é construído de conceitos e relações

com outros conceitos. O conceito é definido como um elemento do pensamento.

É uma construção mental dos objetos do mundo real, os quais podem ser

físicos ou abstratos.

Neste ponto, vale a pena ter uma base de referência da terminologia

adotada no texto. (HSU e WOON, 1998) definem uma ontologia como sendo um

conjunto útil de conceitos e termos que é geral o bastante para descrever

diferentes tipos de conhecimento em diferentes domínios; mas ao mesmo

tempo, específico o suficiente para poder ser aplicado numa tarefa em

particular.

Modelo/Representação é um instrumento para representar/imitar algo do

mundo real ou imaginário. Logo, o modelo em si pode ser algo físico, palpável,


identificável ou apresentável de alguma forma. Fazendo uma analogia, um

modelo ou uma representação seria o correspondente ao “numeral”, que é o

símbolo/ícone/simbologia usado para representar a idéia de número. A

modelagem, por sua vez, corresponde à própria idéia/abstração do conceito de

“número”. A modelagem indica a técnica ou método utilizado para modelar os

conceitos do mundo real ou imaginário.

Segundo o dicionário Aurélio, modelo e representação, são definidos como:

MODELO: “S. m. 1. Objeto destinado a ser reproduzido por imitação. 2. Representação em pequena escala de algo que se pretende executar em grande. 3. Molde (1). 4. Pessoa ou coisa cuja imagem serve para ser reproduzida em escultura, pintura,

fotografia, etc. 5. Aquilo que serve de exemplo ou norma; molde: modelo literário. 6. Aquele a quem se procura imitar nas ações, no procedimento, nas maneiras, etc.; molde:

tomar alguém por modelo. ... 13. Fís. Conjunto de hipóteses sobre a estrutura ou o comportamento de um sistema físico

pelo qual se procuram explicar ou prever, dentro de uma teoria científica, as propriedades do sistema. [Pl.: modelos (ê). Cf. modelo, do v. modelar.]

Modelo icônico. 1. Aquele que reproduz a aparência física do objeto representado.” REPRESENTAÇÃO: “S. f. 4. Reprodução daquilo que se pensa.”

Pela Tabela 3, deseja-se fazer uma correspondência e unificação na

interpretação dos conceitos de modelo/representação e modelagem.

Tabela 3. Definição de uma ontologia de termos e conceitos

MODELO / REPRESENTAÇÃO MODELAGEM NUMERAL NÚMERO

SÍMBOLO / ÍCONE / SIMBOLOGIA IDÉIA / CONCEITO / ABSTRAÇÃO

Vendo os significados das palavras “modelo” e “representação”, conclui-se

que eles dizem a mesma coisa. A intenção aqui é justificar, a correspondência

entre estas palavras, ou seja, quando se fala em modelo implica em fazer uso

de uma representação do problema real.

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

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

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


estrutura de como as partes do projeto se agrupam para atender a função.

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.

Uma leitura complementar sobre esses tipos de modelos pode ser consultada

em (CUNHA e DIAS, 2000).

22..33.. MMOODDEELLOO DDOO CCIICCLLOO DDEE VVIIDDAA DDOO PPRROODDUUTTOO

O modelo do produto é um conjunto de modelos, os quais são construídos

fazendo-se a relação entre os conceitos de Engenharia e os conceitos do

modelo. Através das representações gráficas, que são o modelo de

representação da realidade, são relacionados os conceitos de Engenharia

(dimensões, tolerâncias, intenção de projeto, processos de fabricação, etc.).

(KRAUSE et al., 1993) e (MCMAHON e BROWNE, 1998) discutem o

relacionamento entre os diversos modelos aplicados ao produto, e que

constituem o seu ciclo de vida. Conforme mostra a Figura 3, os modelos do

ciclo de vida do produto podem ser agrupados em quatro categorias:

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

Para (KRAUSE et al., 1993), um modelo do produto deve conter

informações que incluam dados, estrutura, e algoritmos. Os algoritmos fazem a

ponte de ligação entre os usuários, os dados e a estrutura. Os dados de um

modelo do produto, geralmente são determinados pela estrutura e pelo seu

conteúdo. E a estrutura é dependente da natureza do produto, e das

ferramentas usadas para modelar as informações e construir o esquema

necessário para a base de dados. Pode-se dizer que a estrutura de dados, que

representa o modelo do produto, vem a ser o núcleo, a matéria-prima do

sistema computacional. Portanto, uma estrutura inadequada, dificulta

sobremaneira a implementação de algoritmos que utilizam as informações

contidas na estrutura.

Figura 3. Relacionamento entre modelos do ciclo de vida do produto (Baseado

em MCMAHON e BROWNE, 1998).

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


Wingard, em 1992, citado por (MAZIERO, 1998), propõe um modelo de

produto que, inicialmente, divide-o em duas partes: modelo geométrico e o

modelo tecnológico. A ligação entre os dois modelos é feita por uma interface.

Para aplicação, o modelo é dividido em três níveis:

• Nível meta-classe: é onde estão descritos o modelador de sólidos e os

elementos tecnológicos gerais;

• Nível classe: é onde estão descritas as aplicações específicas;

• Nível instância-classe: é onde as entidades e o modelo geométrico são

criados.

Nesta proposta de tese, está se colocando que a informação geométrica e

não-geométrica seja encapsulada em unidades de informação (features de

projeto), que estão definidas por meio de classes de objetos, e interajam com

um sistema CAD, trocando e compartilhando informações de projeto.

2.3.1. MODELO GEOMÉTRICO

O modelo geométrico constitui-se no modelo que guarda as informações

necessárias para visualização dos conceitos modelados. O modelo geométrico

armazena o arranjo das informações geométricas, de modo que mantenham a

consistência e representatividade com o mundo real.

A modelagem geométrica mais elementar corresponde à representação

através de linhas e pontos, conhecida como modelo de arame ou wireframe.

Este modelo, em virtude de sua simplicidade de construção, foi muito utilizado

no passado; todavia, no caso de uma maior complexidade das peças, sua

estrutura torna-se inadequada para a representação. Essa limitação dos

modelos wireframe fez com eles perdessem espaço para outros esquemas de

modelagem geométrica. O esquema de modelagem baseado em “Geometria

Construtiva de Sólidos” ou CSG (Constructive Solid Geometry), opera segundo

uma série de operações lógicas booleanas e transformações geométricas

realizadas sobre um conjunto limitado de sólidos básicos – conhecidas como

primitivas. Conforme a Figura 4, a estrutura dos dados geométricos é

capturada numa árvore binária, onde cada nodo-pai possui dois nodos-filho.

Outro esquema de modelagem importante é o de Representação por


Contorno, ou B-Rep (Boundary Representation).

Figura 4. Estrutura de dados em árvore binária para esquema CSG.

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, como mostrado na

Figura 5. Através dessa estrutura de dados, é possível representar os sólidos, e

identificar o lado interior e exterior do contorno que envolve o sólido.

Figura 5. Estrutura de dados para esquema B-Rep.

A representação de componentes baseada apenas no modelo geométrico

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 v4v2 x2 y2 z2 f2 v6 v2 v1 v5v3 x3 y3 z3 f3 v7 v3 v2 v6v4 x4 y4 z4 f4 v8 v4 v3 v7v5 x5 y5 z5 f5 v5 v1 v4 v8v6 x6 y6 z6 f6 v8 v7 v6 v5v7 x7 y7 z7

f3f2

diferença

cilindro união

bloco2 bloco1


não é satisfatória, em razão de dois fatores preponderantes:

• A representação de diversos elementos fundamentais à descrição do

projeto não está adequadamente contemplada nesses esquemas de

modelagem, considerando a necessidade de sua posterior recuperação

e utilização pelos sistemas computacionais.

• A representação da forma da peça através apenas das primitivas

geométricas, não captura nem enfatiza conceitos e abstrações que

facilitem a compreensão do projeto, como a intenção do projetista.

22..44.. EESSTTRRUUTTUURRAA DDEE DDAADDOOSS DDOO PPRROODDUUTTOO

A representação da estrutura conceitual do produto exige uma estrutura

de dados apropriada, que reflita o relacionamento entre os seus componentes.

(MCMAHON e BROWNE, 1998) citam alguns requisitos desejados numa

estrutura de dados computacional para suportar uma modelagem interativa:

• Permitir a manipulação de dados de forma interativa, oferecendo

recursos de interface amigável ao usuário para realizar operações de

inserção, modificação, e deleção de dados na estrutura computacional.

• Suportar tipos de dados diversos - geométricos, textual, dimensões,

rótulos (labels), trajetórias de ferramentas, malhas para análise por

FEM – Finite Element Method, etc..

• Permitir associatividade entre elementos geométricos e propriedades

tais como: número de penas (canetas); estilo de linhas, cor, etc..

• Permitir associatividade entre dados dos elementos onde for importante

e necessário para o modelo.

• Fornecer recursos para recuperação de peças da estrutura de dados

em operações de deleção ou modificação. Funções do tipo “desfazer”

(UNDO) e “refazer” (REDO), comumente encontradas em sistemas CAD.

• Fornecer recursos para armazenar geometrias comumente usadas, com

repetidas referências à geometria armazenada como instâncias.

• Deve ser compacta, para minimizar o armazenamento em disco e

utilização da memória principal.


• Permitir modelos de vários tamanhos, além suportar e entender várias

combinações de novas entidades definidas pelo usuário.

• Permitir um acesso rápido e eficiente dos dados.

Alguns dos requisitos listados acima são conflitantes, o que restringe o

projeto de organização da estrutura de dados.

Do sistema CAD, espera-se que ele forneça recursos para capturar no

computador ações e decisões tomadas na atividade de projeto. Uma variável

importantíssima na atividade de projeto é o tempo. Dependendo do momento,

uma informação ou dado de projeto pode se apresentar de formas diferentes. E

para representar esse contexto temporal, o dado ou informação pode necessitar

de uma estrutura de dados específica ou peculiar e que seja extensível e

flexível. Ela deve atuar como uma framework (estrutura de organização dos

dados), muito mais do que como uma forma de representação estática.

2.4.1. REPRESENTAÇÃO DA ESTRUTURA DE DADOS

A estrutura de dados computacional a ser utilizada para representar a

estrutura do produto é do tipo em árvore, onde cada nó representa uma lista

ligada. De cada célula das listas ligadas podem partir novas listas,

caracterizando um aninhamento de listas. Como exemplo, considere a

estrutura do produto mostrada na Figura 6.

Figura 6. Exemplo genérico de estrutura do produto.

Conforme é mostrado na Figura 7, na representação em árvore, o produto

PRODUTO

CONJUNTO

SUBCONJUNTO #2

PEÇA

FEATURES

SUBCONJUNTO #1 SUBCONJUNTO #N


constitui-se como a raiz que aponta para uma lista ligada de conjuntos. Como

restrição, o produto possui um único conjunto, que na representação da lista

ligada é implementada com uma única célula.

Figura 7. Exemplo de uma estrutura de dados computacional do produto.

A estrutura do produto admite que um conjunto tenha um ou mais

subconjuntos, dependendo da complexidade a ser representada. Assim, de um

conjunto, sai uma lista de subconjuntos.

Um subconjunto, representado numa célula da lista de subconjuntos, é

composto por várias peças. Para cada subconjunto, uma lista de peças deve

estar ligada, resultando numa lista de peças que por sua vez sai de uma célula

da lista de subconjuntos.

PRODUTO

Lista de Conjuntos

Lista de Subconjuntos

Lista de Peças

Lista de features externas

Lista de features modificadoras


Lista de features internas



EIXO

FURO

Chanfro

Chanfro

Canal

Canal


Uma peça é composta por várias features. A partir desse nível da

estrutura, ela segue a classificação das features adotada em (MAZIERO, 1998).

As features são classificadas em features básicas externas (volume positivo) e

internas (volume negativo). Essa classificação é representa na estrutura de

dados por duas novas listas ligadas, que correspondem às listas de features

básicas “eixo” e “furo”. As features básicas externas e internas podem ser

associadas às features modificadoras. De acordo com a definição, as features

modificadoras são representadas por listas ligadas que saem da célula de uma

lista de features básicas externas e internas.

22..55.. AA IINNFFOORRMMAAÇÇÃÃOO NNOO PPRROOJJEETTOO

Imagine-se um projetista, fazendo parte de uma equipe de projeto, onde

não exista o emprego de nenhuma sistemática de projeto para desenvolver seus

produtos. Geralmente essa forma de trabalho é marcada por certos vícios e

paradigmas, frutos de alguma experiência adquirida em situações semelhantes

anteriores. A discussão quanto ao emprego ou não de uma sistemática de

projeto, pode tornar-se uma questão menor se os resultados finais já estiverem

sendo alcançados satisfatoriamente. Vale ressaltar, que uma prática comum de

procedimentos padronizados e sistematizados, adotada e aceita por outros,

pode tornar muito mais eficiente a atividade de desenvolvimento de produtos.

Todavia, da forma descrita acima, o sucesso ou não das decisões de

projeto só serão sentidos ao final se não forem providenciados meios de

avaliação das decisões e resultados. E isso não é, nem muito bom nem muito

saudável, do ponto de vista de mercado atual. Neste caso, o sucesso ou não

das decisões tomadas é muito incerto.

A importância do emprego de uma sistemática de projeto vem sendo

ressaltada por pesquisadores de projeto de sistemas mecânicos, pois ela torna

o processo de projeto muito mais orientado, gerenciável, e previsível,

fornecendo parâmetros palpáveis e visíveis da eficiência ou não dos resultados,

mesmo em fases ainda iniciais do processo. Por outro lado, alguns também

ressaltam que a sistematização pode inibir ou limitar a criatividade. O ideal


seria um meio termo, um pouco de flexibilidade e liberdade juntamente com

um pouco de métodos e técnicas.

Essa discussão reflete que o desenvolvimento de um processo de projeto

de produto é altamente imprevisível, aleatório, não determinista e dependente

de fatores, que às vezes são alheios aos resultados pretendidos. Geralmente o

resultado principal desejado pela equipe de projeto é uma solução para uma

necessidade de um cliente. E esse quadro é até compreensível já que o

processo de projeto é conduzido por seres humanos.

Dentro dessa dinâmica do processo de projeto, a informação é um dos

elementos metodológicos de projeto. Neste trabalho de tese, deseja-se ter uma

metodologia de projeto como base para a modelagem da informação de projeto

e posterior visualização de uma ferramenta computacional. De início, este

trabalho, está enfocado na discussão das formas de representação da

informação de projeto, e na sua transformação durante as fases.

A informação assume o papel de matéria-prima inicial do processo de

projeto, e dos resultados obtidos durante o projeto. Então, uma avaliação sobre

as formas de representação da informação é de fundamental importância para

o modelo de informação do projeto.

2.5.1. TIPO E REPRESENTAÇÃO DA INFORMAÇÃO DE PROJETO

A principal preocupação com a forma de representação da informação de

projeto não está na fase de detalhamento do projeto, onde a informação já

assume características bem definidas, e de certa forma já invariáveis. A

preocupação maior está em definir meios computacionais de capturar a

intenção do projetista nas fases iniciais de projeto, principalmente nas fases

informacional e conceitual. E depois, utilizar a informação inicial para

relacioná-la de forma inteligente, útil, e reusável do ponto de vista de projeto,

com as formas de representação detalhada, já disponíveis nos sistemas CAD.

Esse relacionamento entre ferramentas já disponíveis no sistema CAD deve

priorizar principalmente a integração para suportar o projeto. Isso exige um

modelo computacional complexo, pois a Babel da Representação de Informação é diversa.

A intenção desse tópico é mostrar a representação da informação de


projeto utilizada em trabalhos desenvolvidos na área de projeto mecânico de

produtos industriais. De forma a exemplificar e reutilizar alguns esforços de

pesquisa nesta área, o estudo feito aqui tomou por base em teses desenvolvidas

no âmbito das fases informacional (especificação de projeto) e conceitual

(seleção de uma alternativa de solução conceitual).

2.5.2. REPRESENTAÇÃO DA INFORMAÇÃO NOS PROJETOS INFORMACIONAL E

CONCEITUAL

Os autores estabelecem que o processo de projeto se inicia com o

esclarecimento ou definição da “tarefa de projeto”. A atividade de projeto deve

ser precedida por um trabalho da equipe de “marketing”, executado para

definir, dentre o universo de produtos possíveis, aquele produto que vai ser

projetado e configurar, assim, a “tarefa de projeto”, como o documento que dá

início ao processo de projeto.

A Figura 8 mostra a transformação da informação no projeto

informacional.

Figura 8. Transformação das informações no projeto informacional.

O projeto informacional é executado para transformar a informação de

entrada em especificações de projeto. Estas especificações se constituirão no

guia dos trabalhos nas fases posteriores do processo de projeto, razão pela qual

a sua obtenção implica numa responsabilidade para o sucesso do projeto no

seu conjunto.

Para uma adequada estruturação do projeto informacional, consideram-se

quatro categorias de informação, como categorias relevantes realmente

existentes no processo: as necessidades, os requisitos de usuário, os requisitos

de projeto e as especificações de projeto. Elas estão resumidas na Tabela 4.

Fase Inicial do Processo de Projeto Projeto Informacional

Necessidades

Requisitos de usuários

Requisitos de

projeto

Especificações de

Projeto

Problema de Projeto

Especificações de Projeto


Tabela 4. Categorias de informação na fase de projeto informacional.

TIPO DE INFORMAÇÃO SIGNIFICADO

Necessidade Declaração direta de usuário ou clientes

Requisito de usuário Necessidade, levada à linguagem de projeto

Requisito de projeto Requisito mensurável, aceito para o projeto

Especificação de projeto Característica de projeto e/ou do produto

Na realidade, estas informações mínimas devem estar contidas no

problema de projeto, porém, deve-se revisar o problema visando complementá-

las. Conforme recomendações de (FONSECA, 2000), os dados a serem

levantados antes de iniciar o trabalho são:

• Dados do estudo de marketing prévio (revisão do documento);

• Tipo de produto;

• Tipo de projeto;

• Volume planejado de fabricação;

• Desejos explícitos expostos no problema de projeto; e

• Restrições do projeto ou do produto.

Esses dados devem estar registrados num documento chamado de “ordem

de projeto”, o qual deve conter o mencionado problema, seja procedente da

equipe de marketing, ou procedente do ambiente externo. Na ordem de projeto

referida devem aparecer, obrigatoriamente os seguintes campos: Objetivos;

Metas; Restrições; Desejos explícitos e Descrição do problema de projeto.

Na fase inicial tem-se a necessidade de representar as especificações de

projeto. Esse tipo de informação é representado por um conjunto de tabelas ou

matrizes, as quais auxiliam na sistematização da tomada de necessidades,

requisitos dos usuários e requisitos de projeto. Essas tabelas também ajudam

na comparação e conversão de requisitos.

A matriz das necessidades, mostrada na Figura 9, é constituída por linhas

representando as fases do ciclo de vida do produto, e as colunas representadas

pelos atributos básicos do produto.


Figura 9. Matriz para levantamento das necessidades (FONSECA, 2000).

Na Figura 10 aparecem os requisitos de usuário, como linhas da matriz,

tendo como colunas os atributos específicos do produto.

Figura 10. Matriz para conversão dos requisitos de usuário em requisitos de

projeto (FONSECA, 2000).

Os cruzamentos das linhas (requisitos de usuário) com as colunas

(atributos específicos), ajudam a equipe de projeto decidir quais requisitos de

projeto, os quais são mensuráveis, satisfazem o requisito de usuário da linha,

Produção

Montagem

Transporte

Armazenagem

Função

Uso

Manutenção

Funcionamento Ergonomia Estética Econômico Normalização ModularCiclo deVida

Atributos básicos do produto

Ter fácilsoldagem.

Ser pintada sem desperdício.

Ter mínimotempo produção

Ter custo mínimo produção.

Ter facilitadaa montagem.

Ter facilidadede transporte.

Ter facilidadede armazenag.

Ter mesa mais larga. Ser ergonômica.Ter mesa inclinada. Não seja dura.Ter encosto maior. Não ter ressaltos.

Ter porta material.Ter mesa c/port.mat.

Ter coragradável.

Ter estruturaleve.

Ter facilidadede manutenção.

Estrutura mod.resistente.

Ter uniõesnormalizadas.

Geométricos Material Cor Peso ou massa Forças Cinemática Tipo Energia Fluxo Sinais Estabilidade QualidadeRequisitosde usuário

Atributos específicos do produto

Ter fácil soldagem.

Ser pintada sem desperdícios.

Ter mínimo tempode produção.

Ter custo mínimode produção.

Ter facilitada amontagemTer facilitado otransporte.Ter facilitada aarmazenagem.

Ter porta materialcadeira e na mesa.

Ter cor agradável.

Ter estruturaleve.

Ter estrutura mod.resistente.

Ter mesa e encostomaiores.

Reduzir juntascomplexas.

Madeira etubo aço.

Evitarcoresvivas

Usar peçassimilares.

Mínimo depeças.

Elementosnormalizados.

Reduzir juntascomplexas

Formasencaixáveis.Formasempilháveis.

Usar a estruturapara o porta mat.

Estruturamodular simples

Incrementar asáreas de mesa eencosto.

Decidir seçõesdos tubos.


podendo-se gerar o(s) correspondente(s) requisito(s) de projeto nas interseções.

Outra forma de capturar a informação das necessidades e requisitos do

usuário nas fases informacional e conceitual é através de questionário

estruturado e listas de verificação (checklist) relacionados ao domínio do

produto, conforme está exemplificado pela Figura 11.

Figura 11. Exemplo de questionário estruturado para levantamento de

necessidades (OGLIARI, 1999).

Figura 12. Estrutura de função do produto numa forma hierárquica e

representada por ícones (OGLIARI, 1999).


Numa etapa seguinte do processo de projeto, tem-se a necessidade de

representar a estrutura de funções do produto, com vistas a complementar os

requisitos de projeto com o aspecto funcional. Conforme afirma (OGLIARI,

1999), esse é um processo de fatoração ou Divida e Conquiste (Divide &

Conquest).

As funções do produto podem ser representadas por ícones ou símbolos

indicativos ao nome da função. Esses ícones podem ser relacionados através de

uma árvore hierárquica, de forma a compor a estrutura de funções do produto.

Na Figura 12 tem-se um exemplo desse tipo de informação. A estrutura de

funções do produto estabelece uma solução funcional particularizada

O modelo seguinte, utilizado para representar os princípios de solução que

atendem às funções e permitem comparar e avaliar diferentes alternativas de

solução é dado através da matriz morfológica. Conforme é mostrado na Figura

13, tem-se os elementos do domínio do problema de projeto e as funções do

produto nas duas primeiras colunas. As demais colunas da matriz são

preenchidas com princípios de solução que compõem alternativas de solução

para o problema.

Figura 13. Exemplo de matriz morfológica para representação das alternativas

de solução do problema (OGLIARI, 1999).

A partir das formas de representação utilizadas para representar as

Concepções alternativas Elementos do domínio Funções do gabinete Concepção 1 Concepção 2 Concepção n

enclausurar componentes internos

fixar componentes internos

X

X

X

X

X

X

Componentes internos

etc. informar o usuário do produto

TEXTO

FORMA

TEXTO

Usuários do produto

etc. vedar contra influências nocivas do ambiente

Ambiente do produto

etc. combinar com outros produtos

Demais sistema técnicos

etc. função processo

função molde Funções especiais

função material


informações de projeto, conclui-se que:

• Para o relacionamento de informações nas fases informacional e

conceitual, a forma mais usual de visualização de grupos informações

de projeto é feita através de tabelas ou matrizes. Essas tabelas,

normalmente podem ou devem está vinculadas a banco de dados

(DBMS – Database Management Systems), os quais proporcionam aos

usuários das ferramentas de suporte ao projeto todas as vantagens de

um banco de dados (CUNHA e DIAS, 2000).

Nesta discussão sobre a escolha de uma forma de modelo mais adequado

para capturar a evolução dos dados de projeto, é importante ter um

entendimento detalhado dos conceitos, relações e interações existentes entre

features, objetos, restrições e decisões no contexto do processo de projeto, os

quais serão elementos que constituirão a informação de projeto desta proposta.


MMooddeellaaggeemm ee PPrrooggrraammaaççããoo OOrriieennttaaddaa aa OObbjjeettooss


A tecnologia de objetos é um conjunto de metodologias de programação,

projeto e análise que se concentram na modelagem das características e do

comportamento de objetos do mundo real.

Neste capítulo, o objetivo é comentar sobre os principais conceitos da

orientação a objetos, tratando-a como uma forma de modelagem

computacional no contexto de aplicação de projeto. A orientação a objeto em

CAD utiliza os objetos (features) como uma unidade de representação para

armazenar intenções do projetista.

3.1.1. O QUE É POO OU OOP?

A Programação Orientada a Objetos – POO (OOP – Object-Oriented

Programming) é diferente do estilo de programação procedural de linguagens

como (C, Pascal, Fortran, etc.) em várias formas. Tudo em POO é considerado e

agrupado como objetos. POO é implementada pelo mecanismo de envio de

CAP. 3 – MODELAGEM E PROGRAMAÇÃO ORIENTADA A OBJETOS 35

mensagens aos objetos.

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

No meio computacional, um objeto pode ser abstraído como modelos

computacionais de algo do mundo real. Eles são abstrações (modelos) para

programação de software. Segundo (HSU e WOON, 1998), um objeto é uma

entidade que combina atributos e comportamento numa estrutura de dados

indivisível ou inseparável.

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 solicitante, e o objeto que recebe a mensagem é o

requisitado. O controle é passado para o objeto requisitado até ele completar o

comando. E finalmente, o controle retorna ao objeto solicitante, como mostra a

Figura 14.

Figura 14. Mecanismo de mensagens: interface de comunicação entre os

objetos.

Os papéis assumidos pelos objetos envolvidos – solicitante (cliente) e

requisitado (servidor) –, são semelhantes aos papéis desempenhados numa

arquitetura cliente-servidor. Existe quem solicita o serviço, e quem o fornece.

No exemplo da Figura 15, um objeto FEATURE_CHANFRO pergunta qual a

aresta do objeto PEÇA de ser chanfrada, enviando a ele uma mensagem

perguntando pelo aresta. O objeto requisitado PEÇA, retorna a aresta de volta

OBJETO SOLICITANTE OBJETO REQUISITADO

MENSAGEM

VALOR DERETORNO


ao objeto solicitante FEATURE_CHANFRO.

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 para o objeto

solicitante, o qual pode ou não ser útil ao objeto solicitante.

Figura 15. Mecanismo de mensagem entre dois objetos.

Na Figura 16, o objeto FEATURE_CHANFRO deseja mudar o valor do chanfro

no objeto PEÇA. Ele faz isto enviando uma mensagem para modificar o valor do

chanfro para um novo valor. O novo valor é passado como um argumento na

mensagem. Neste caso, o objeto FEATURE_CHANFRO não se importa com o valor

retornado pelo objeto PEÇA, requisitado na mensagem.

Figura 16. Passagem de parâmetro para um objeto.

3.1.3. MÉTODOS DO OBJETO

Cada mensagem possui um código associado a ela. Quando um objeto

recebe uma mensagem, o código é executado. Noutras palavras, estas

mensagens determinam o comportamento do objeto, e o código determina como

o objeto executa cada mensagem. O código que está associado a 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.

FEATURE_CHANFRO PEÇA

MENSAGEM

novo valor do chanfro

altere “valor” para “novo valor”

FEATURE_CHANFRO PEÇA

MENSAGEM

aresta

responda-me qual é a aresta


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 chamadas de

mensagens de instância. Já os métodos que operam sobre classes específicas

são métodos de classe. Nas linguagens de programação, os métodos de classe

são declarados com o modificador do tipo estático (static).

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 PEÇA recebe a mensagem novo valor, esta passa o controle

para o método novo valor definido em PEÇA, como mostra a Figura 17.

Figura 17. Métodos de um objeto.

3.1.4. 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 a Figura 18, 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”, o qual fornece e garante um

mecanismo seguro para se informar sobre dados do objeto. 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.

Diferente da linguagem procedural, onde a área de dados comuns é

freqüentemente usada para compartilhamento de informações, a POO

INTERFACE do objeto

Peça

volume:

massa:

novo valor:

novo valor

10


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.

Figura 18. Acesso aos dados de um objeto.

Os nomes das variáveis de instância podem ser idênticos aos nomes dos

métodos associados com elas. Por exemplo, o objeto PEÇA possui métodos de

massa, volume, etc.; e também variáveis de instância “massa”, “volume”, etc..

33..22.. MMEECCAANNIISSMMOO SSEEQQÜÜEENNCCIIAALL DDEE MMEENNSSAAGGEENNSS

É 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 objeto solicitante, até que todas as mensagens sejam completadas. No

exemplo da Figura 19, um objeto A envia uma mensagem ao objeto B.

Figura 19. Encadeamento seqüencial de mensagens.

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

Objeto A Objeto B Objeto C Objeto D

1 2 3

4 5 6

INTERFACE

do OBJETO

métodoUm

métodoDois

métodoEne

variávelUm

variávelEne

Objeto Solicitante

Objeto requisitado


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.

33..33.. EESSTTRRAATTÉÉGGIIAASS DDEE OORRIIEENNTTAAÇÇÃÃOO AA OOBBJJEETTOOSS

As estratégias de orientação a objetos são eficientes para a construção de

modelos de software de entidades no domínio do mundo real. o projeto de

software é em grande parte a construção de um modelo de software do mundo

real, onde cada entidade real é representada no programa por um

correspondente objeto de software. O objeto de software simula as ações e

condições do seu correspondente objeto do mundo real.

A filosofia de “programação como modelagem” é mais evidente em

ambientes virtuais tridimensionais, onde as características visuais do mundo

real são simuladas dentro do mundo virtual. Isso foi também afirmado

(ACHTEN e LEEUWEN, 1998), os quais pensaram em criar um ambiente virtual

para desenvolvimento de projeto.

A seguir, tem-se uma discussão sobre as principais estratégias de

orientação a objetos.

3.3.1. ABSTRAÇÃO

A abstração é uma técnica de projeto que enfatiza os aspectos essenciais

de uma entidade, e ignora ou esconde os aspectos menos importantes ou não

essenciais. A abstração é uma importante ferramenta para a simplificação de

um fenômeno complexo para um nível onde a análise, a experimentação, e o

entendimento sejam realizáveis.

Em software, a abstração está interessada nos atributos e comportamento

das entidades. Os atributos referem-se às propriedades ou características

associadas com uma entidade, ao passo que o comportamento refere-se ao

conjunto de ações que a entidade pode realizar. Num objeto de software, os

atributos são representados pelos dados associados ao objeto.


3.3.2. SEPARAÇÃO

A separação refere-se à distinção entre o comportamento observável do

sistema que está sendo modelado, e do significado ou mecanismo pelos quais o

comportamento é atingido. Noutras palavras, isso se refere à separação entre o

“quê” deve ser feito, do “como” deve ser feito.

A separação ajuda a um usuário trabalhar com um sistema complexo,

sem preocupar-se em entender como o sistema foi implementado. Por exemplo,

isso é semelhante a um usuário de um sistema CAD criar um modelo

geométrico complexo de uma peça, e depois pedir para girar o modelo. Ele

então utiliza um comando que executa a rotação do modelo de acordo com o

ângulo pedido. Ele não se preocupa como o sistema vai recalcular todas as

faces do novo modelo.

3.3.3. COMPOSIÇÃO

A composição trata com sistemas complexos maiores considerando como

uma organização de sistemas menores e mais simples. A composição reflete o

relacionamento “parte-todo” da orientação a objetos. Esse relacionamento

ajuda a implementar uma das vantagens da orientação a objeto, a

reusabilidade de objetos já existentes para compor outros objetos mais

complexos.

3.3.4. GENERALIZAÇÃO

A generalização consiste em identificar similaridades de comportamento e

atributos num conjunto de objetos. Esse tipo de mecanismo, ajuda a

implementar três conceitos importantíssimos da orientação a objetos:

• de herança, através do relacionamento “é um”;

• de polimorfismo, através de algoritmos lógicos para testar que tipo de

objeto está sendo processado em tempo de execução;

• de padrões (patterns), neste caso os atributos e comportamentos de um

objeto podem ser parcialmente definidos de forma a torná-los aplicáveis

a um intervalo de situações. Os padrões também podem modelar

relacionamentos entre objetos.


A Tabela 5 resume os tipos de estratégias para modelagem segundo

princípios de orientação a objeto.

Tabela 5. Estratégias de projeto de software em POO (KAFURA, 2000).

ESTRATÉGIA DE PROJETO DEFINIÇÃO

Abstração Simplificando para a sua essência a descrição da entidade do mundo real

Separação Tratando independentemente o “que” uma entidade faz, do “como” ela faz aquilo

Composição Construindo o todo de sistemas complexos a partir de partes mais simples, numa das duas formas: associação, agregação

Generalização Identificando elementos comuns entre entidades diferentes, numa das quatro formas: hierarquia, genericidade (genericity), polimorfismo, padrões (patterns)

33..44.. OO PPAARRAADDIIGGMMAA DDAA OORRIIEENNTTAAÇÇÃÃOO AA OOBBJJEETTOO

Uma linguagem computacional é dita orientada a objetos se ela suporta os

seguintes princípios: abstração, encapsulamento, polimorfismo e herança.

3.4.1. 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,

relacionamentos, etc., que forem consideradas relevantes para a descrição deste

domínio). O resultado deste processo de abstração é conhecido como Modelo

Conceitual.

Figura 20. Abstração e representação de dados em POO.

ABSTRAÇÃO

REPRESENTAÇÃO


Conforme é mostrado na Figura 20, 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 comuns são as

linguagens de programação e as notações auxiliares de diagramas e figuras.

3.4.2. ENCAPSULAMENTO DE DADOS

Na POO, 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 sua lógica estão escondidas de

outros objetos. Noutras palavras, a interface encapsula o código e os dados do

objeto, como mostra a Figura 21.

Figura 21. Encapsulamento de dados em POO.

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 são

transparentes para o usuário. Por exemplo, se uma mensagem qual_aresta é

enviada ao objeto PEÇA, não é importante para o usuário do objeto PEÇA, saber

como o desenvolvedor implementou o código para manipular esta mensagem.

Todos os objetos solicitantes precisam é do protocolo correto para interação

com o objeto PEÇA; ou seja, precisa-se saber quais parâmetros são necessários

para repassar ao objeto, a fim de que ele possa responder à mensagem. O

desenvolvedor pode mudar a implementação a qualquer momento, mas a

Métodos públicos

Métodos privados

DADOS

MENSAGENS

Interface do Objeto

OBJETO_2

OBJETO_1

OBJETO_N


mensagem qual_aresta ainda funcionará porque a interface é a mesma.

3.4.3. 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 FEATURE. Mesmo que a implementação

desta mensagem nome possa retornar um número e um nome da peça, o seu

protocolo é o mesmo que a mensagem nome para o objeto PEÇA. 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 no dia-a-dia refere-se à maneira como os

estudantes respondem ao sino da escola. Todo aluno conhece o significado do

sino. Quando o sino toca (mensagem), 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.

Na Figura 22, 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

mensagem para todos os objetos é a mesma imprimir, mas a implementação

real do que eles devem fazer para se imprimirem, varia.

Figura 22. Exemplo de polimorfismo em POO.

Documento imprimirPágina

Texto Objeto novo


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.

3.4.4. HERANÇA

Outro conceito importante da POO é 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.

Por exemplo, na Figura 23, ambas as features das classes FURO e CANAL

têm um comportamento similar quanto a gerência do “nome”, “posição”, etc..

Ao invés de colocar este comportamento em ambas as classes, ele é colocado

numa nova classe chamada FEATURE. As classes FURO e CANAL tornam-se

subclasse da classe FEATURE, e ambas herdam o comportamento de FEATURE.

Figura 23. Exemplo de herança em POO.

As classes FURO e CANAL podem então adicionar comportamentos

específicos delas. Por exemplo, FURO pode ser passante ou não-passante,

Feature

Canal Furo


rebaixado ou escareado. Por outro lado, a classe CANAL pode ser classificada

em retangular ou arredondada.

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, FEATURE é uma super-classe para as classes FURO e CANAL.

FURO e CANAL são subclasses de FEATURE.

3.4.5. REUSABILIDADE

Uma das mais importantes características da programação POO é a

habilidade de modificar soluções existentes para resolver novos problemas. Se

um problema particular foi resolvido usando um método de POO, 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.

33..55.. 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. 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 suas operações, e resolva a

sua parte do problema.

De forma simples, o método de solução de problemas orientados a objeto,

geralmente, pode ser dividido em quatro passos:

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 ou especificaçã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 a

mensagem imprimir é enviada.

Os passos indicados acima podem ser considerados apenas como tendo

um efeito didático demonstrativo do que seria um processo mais complicado de

modelagem para um problema real. (JURISTO e MORENO, 2000) enfocaram o

problema de construção de um modelo de objetos a partir de uma descrição

textual do problema, e concluíram sobre a falta de um guia regras com

fundamentação teórica bem estabelecida.

De forma resumida, a Figura 24 mostra que a criação do modelo de

objetos começa por uma especificação do problema, geralmente na forma de


texto. No estágio 1, o analista do problema extrai a informação requerida para

o processo de análise orientada a objetos (OOA – Object-Oriented Analysis),

principalmente requisitos funcionais. No estágio 2, o analista então depura a

informação obtida, a fim de encontrar sinônimos ou polissemias (propriedade

de uma palavra possuir vários significados). No estágio 3, ele separa os dados

que o sistema processa (dados estáticos), dos dados que descrevem o

comportamento do problema (dados dinâmicos).

Figura 24. Passos de criação de um modelo de objetos.

Esses estágios iniciais (1, 2 e 3) servem como uma filtragem da informação

necessária para a estruturação dos modelos de objeto e de comportamento. O

processo de modelagem não é uma tarefa trivial, e dele depende todo o modelo

computacional gerado para representar o problema do mundo real. Detalhes

maiores sobre a criação de modelos de objetos podem ser consultados neste

trabalho, ou seguir outras metodologias como a de Rumbaugh (OMT – Object

Modeling Technique), UML – Unified Modeling Language, etc.. Podem ser

consultadas as referências (RUMBAUGH et al., 1991) e (ERIKSSON e PENKER,

1998).

Lista de Requisitos

Estágio 1: Extração de informações essenciais

Estágio 2: Análise de significados

Estágio 3: Separação da informação estática e dinâmica

Estágio 4: Estruturação dos requisitos estáticos

Estágio 5: Estruturação dos requisitos dinâmicos

Estágio 6: Construção do modelo de Objetos

Estágio 7: Construção do modelo de comportamento

Estágio 8: Integração do modelo de objetos e comportamento

Estágio 9: Verificação do modelo de objetos e comportamento

Validação


TTeeccnnoollooggiiaa ddee FFeeaattuurreess AApplliiccaaddaa nnoo PPrroojjeettoo MMeeccâânniiccoo


As features são úteis em muitas atividades relacionadas ao projeto

mecânico. Como por exemplo: na criação de geometria das peças que

constituem o produto, na especificação de tolerâncias e projeto da montagem.

Os modelos de features atuam como uma descrição do produto num nível mais

alto de representação, e também disponibilizam informação melhorada para a

automatização de métodos de análise, tais como: análise de tensões usando

elementos finitos, avaliação da manufaturabilidade, análise de tolerâncias

usando métodos numéricos, e estimativa de custos. O projetista pode ter

decisões mais fundamentadas e acertadas fazendo interações com outras

análises realizadas simultaneamente. Esse é um dos grandes benefícios da

modelagem por features.

Em termos cronológicos, a modelagem por features é uma tecnologia

relativamente nova em CAD/CAM (Computer-Aided Manufacturing), tendo

iniciado as pesquisas na década de 80 como é mostrado na Figura 25.

CAP. 4 – TECNOLOGIA DE FEATURES APLICADA NO PROJETO MECÂNICO 49

Enquanto que na modelagem de sólidos somente a informação sobre a

geometria é armazenada, em modelagem por features também a informação

funcional é armazenada no modelo do produto.

Figura 25. Evolução dos modeladores geométricos (Baseado em SHAH e

ROGERS, 1988).

A aplicação da tecnologia de features em atividades de projeto permite a

reutilização de informações, modelagem rápida, propagação de alterações e

padronização de representações. Devido a estes e outros benefícios, ela tem

sido reconhecida como fundamental para integração do CAD com outras

ferramentas de auxílio computacional à Engenharia, tais como CAM, CAE,

CAPP (Computer-Aided Process Planning), etc..

44..22.. CCOONNCCEEIITTOOSS DDEE FFEEAATTUURREE

É grande a diversidade de conceitos sobre features na literatura científica.

Geralmente, o contexto fica em torno de uma visão fabricação, planejamento do

processo e projeto.

Os primeiros trabalhos de pesquisas que utilizavam o conceito de features,

mostravam uma faceta puramente voltada para o contexto de fabricação.

Segundo (SHAH, 1991), muitos dos trabalhos tinham o objetivo de desenvolver

métodos para extração da geometria da peça a partir de modeladores sólidos, e

Modeladores baseados em features

Modeladores wireframe

1965 1970 1975 1980 1985 1990 2000 ………… ANO

MO

DELA

DOR

ES

Modeladores de superfícies

Modeladores de sólidos

Aplicações baseadas em features


daí disponibilizar essa geometria para geração de planejamento de processos,

codificação para Tecnologia de Grupo (GT – Group Technology), e programação

de comando numérico. Para a fabricação, o conceito de features encerra um

conjunto de formas e atributos tecnológicos associados com operações e

ferramentas de fabricação.

Na visão da comunidade de modelagem geométrica, o conceito de features

está estreitamente relacionado a um conjunto de entidades geométricas e

topológicas que são referenciadas e interpretadas juntas. Abaixo, segue um

conjunto de definições que refletem essa linha de pensamento.

Segundo (WARMAN, 1990), tem-se que:

• Uma feature de projeto pode ser vista como um objeto que é capaz de

reagir a mensagens.

Segundo (MCGINNIS e ULLMAN, 1992), tem-se que:

• A feature é qualquer característica particular ou específica de um

objeto de projeto, a qual contém ou relata informação sobre o objeto.

Elas são verbalmente representadas na forma de substantivos.

Segundo (SHAH e MÄNTYLÄ, 1995), tem-se que:

• Features são estruturas de conhecimento estereotipadas embutidas em

processos cognitivos de projeto, análise, planejamento, e todas as

outras atividades de Engenharia.

Segundo Jasthi, citado por (MAZIERO, 1998), tem-se que:

• Feature é uma forma geométrica definida por um conjunto de

parâmetros, os quais têm um significado especial para projeto ou

manufatura, portanto capazes de fornecer informações num mais alto

nível conceitual.

Segundo (MCMAHON e BROWNE, 1998), tem-se que:

• Feature é qualquer geometria percebida, elemento funcional ou

propriedade de um objeto, útil no entendimento da função,

comportamento ou performance do mesmo.

Segundo (ACHTEN e LEEUWEN, 1998), tem-se que:

• Feature é um conjunto de informações de alto-nível de abstração,

possivelmente gerada durante o projeto, definindo um conjunto de

características ou conceitos com um significado semântico para uma


visão particular no ciclo de vida de um “prédio”.

Neste caso em particular, os autores referem-se a um “prédio”, pois os

mesmos atuam no contexto do projeto arquitetônico. Todavia, a definição é

extensível para um domínio qualquer de modelagem da informação de projeto,

inclusive de projeto mecânico, substituindo “prédio” por “produto mecânico”.

Segundo (BIDARRA, 1999), tem-se que:

• Features são representações dos aspectos de forma de um produto, os

quais são mapeados para uma forma genérica e são funcionalmente

significantes para alguma fase do ciclo de vida do produto.

Pela análise da série de definições, resumiu-se neste trabalho que:

OBJETO (Geometria, Topologia) SemânticaFeature≡ ⇔ ∪ (4.1)

Interpretada como expresso pela Equação (4.1), a geometria e a topologia

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

Não importa quão geral possa ser a definição de features, o que deve ser

considerado é que as features encapsulam significado de Engenharia às formas

geométricas. (SALOMONS, 1993) afirma que Shah estabeleceu requisitos

mínimos que toda feature deve satisfazer:

• Ela deve ser um constituinte físico de um produto;

• Poder ser mapeada para uma forma genérica;

• Possuir um significado de Engenharia;

• Possuir propriedades previsíveis.

A tecnologia de features possui um conjunto de características que a

indicam como sendo um meio adequado para a modelagem de informações do

produto e processo de projeto mecânico, a saber:

• Possui um alto-nível de informação com um significado semântico;

• Permite definir características e conceitos físicos e não físicos

associados com o produto;


• Facilita a propagação de alterações no modelo de features;

• Permite acompanhar e visualizar a evolução da informação de projeto

durante as fases de projeto;

• Pode referir-se a uma visão particular do ciclo de vida do produto.

44..33.. AA DDIISSCCUUSSSSÃÃOO FFEEAATTUURREESS VVEERRSSUUSS OOBBJJEETTOOSS

Com base nos conceitos de orientação a objetos, torna-se importante

enquadrar essa técnica de modelagem dentro do contexto de projeto mecânico

e das features. Existem diversos trabalhos relacionados ao conceito de

features. Eles abordam uma variedade de diferentes contextos do ciclo de vida

do produto que podem ser modelados através de features.

Para efeito de reusabilidade e extensibilidade dos conceitos, deve-se

assumir algumas considerações para a modelagem de objetos no contexto do

projeto mecânico:

• Existem dois contextos distintos: o contexto computacional de

orientação a objetos, e o contexto de projeto com features.

• Nem todo OBJETO é uma feature. Ou seja, OBJETO é mais genérico.

Feature é mais específico.

• Toda feature de projeto é uma entidade que pode ser modelada por

orientação a objetos. Ou seja, assim toda feature é um OBJETO.

O que se quer esclarecer neste trabalho é: Com base na leitura de artigos,

seja na área de features quanto na de objetos, a polêmica só surge devido uma

diferença de interpretação, contextualização, e visualização dos conceitos de

objetos e features. Quando se pensa em modelar features no computador, a

abstração de features como objetos é que mais satisfatória. Fora disso, os

conceitos existem independentemente.

No âmbito da modelagem computacional orientada a objetos, a definição

de objeto engloba a definição de feature. No caso de projeto de componentes

mecânicos, desenvolvimento de produto e sistemas computacionais de suporte

ao projeto, a idéia de feature se enquadra perfeitamente com a modelagem e


programação baseada e orientada a objetos.

Mas o termo objeto é abrangente, e por isso muito subjetivo. Tudo no

mundo real ou abstrato das idéias pode ser modelado por objetos. E vale

salientar que “objeto” é um termo distante da linguagem usual do projetista.

Daí porque surge o termo feature, que passa a idéia de objeto num contexto de

Engenharia. O conceito de features nada mais é que uma abstração do

conceito mais amplo de objetos, trazido para um contexto de projeto no caso

deste trabalho de pesquisa. A Figura 26 ilustra o que foi dito anteriormente.

Figura 26. Abstração do contexto de OBJETOS e FEATURES.

4.3.1. OBJETOS/FEATURES DE PROJETO

Um dos objetivos dessa pesquisa é estabelecer uma terminologia e uma

representação dos dados de projeto, os quais possam facilitar a implementação

computacional num ambiente de sistema CAD para suporte ao projeto de

componentes mecânicos. Os objetos de projeto ajudam a identificar os dados e

informações que precisam constituir a base para a estrutura de dados

adequada à troca e ao compartilhamento de informações nas fases de projeto, e

assim facilitar a utilização de sistemas CAD nestas fases, integrando-o

eficientemente ao processo.

Uma idéia natural do projetista é visualizar um produto sendo constituído

por montagens, componentes, interfaces e features, etc.. As features mais

relevantes de serem identificadas nesta fase são as features de projeto. As

features constituirão a base para a captura e armazenamento das informações

de projeto. Nesta pesquisa, o enfoque será sobre as features de projeto, ou seja,

os dados característicos do produto que permitirão estender e propagar a

Features

CAD

Contexto Computacional de Projeto

OBJETOS


intenção do projetista para fases subseqüentes da atividade de projeto.

Numa fase inicial do projeto de um componente mecânico, tem-se uma

vaga idéia do que se quer projetar, ou mesmo, apenas informações ainda não

detalhadas, imprecisas e inexatas. Essa idéia apresenta-se na forma de uma

especificação de projeto que, por sua vez, adveio de uma fase informacional.

Os objetos de projeto, presentes numa fase inicial, podem ser: produto,

sistema, peça, feature de projeto. Num nível mais grosseiro, esses objetos

podem compor uma visão geral do que se quer detalhar em etapas posteriores

do projeto.

Dentre os objetos de projeto, as features de projeto são os que servem de

informação básica mais apropriada para a representação das características

dos demais objetos que podem ser instanciados.

Nesse trabalho de tese, as features de projeto constituem-se no elemento

básico de informação para captura, recuperação, troca e compartilhamento de

dados entre modelos de representação para o projeto. Este tipo de modelo

baseado em features ajuda, principalmente, no momento de implementação e

utilização de um sistema CAD.

44..44.. DDEEFFIINNIIÇÇÃÃOO DDEE FFEEAATTUURREESS

Segundo (SALOMONS, 1995), a definição de features diz respeito a como

uma feature se parece, como ela deve se comportar, e quais são as suas

características. A definição diz respeito a como o computador enxerga um

conjunto de entidades representadas graficamente e o identifica como uma

feature, que além da informação geométrica, encapsula um conjunto de

informações de contexto de aplicação.

Os sistemas CAD geralmente oferecem recursos limitados para definição

de novas features (user-defined features). Nos sistemas CAPP, quando existe

essa possibilidade, elas geralmente se apresentam na forma de algoritmos para

reconhecimento de features.

Se sistemas de CAD e CAPP oferecem recursos de definição de features,

elas normalmente consistem de algum tipo de interface de programação para o

modelador geométrico. No entanto, a interface de programação tem acesso


limitado às funções de processamento da geometria do modelador.

Nos sistemas de “Engenharia Baseada no Conhecimento” (KBE –

Knowledge-Based Engineering), a interface de programação e o acesso do

modelador geométrico são melhores, quando comparados aos sistemas CAD

convencionais. Os métodos baseados em linguagem são uma outra alternativa

para definição de features.

Um usuário encarregado de definir novas features deve ser um

especialista em projeto ou fabricação, ou em ambos. Atualmente, os recursos

de definição de features exigem que o usuário também possua habilidade de

programação. Isso se deve ao fato de que os sistemas CAD comerciais, só

oferecem algumas features básicas. Se realmente necessário, a definição de

novas features exige um aprofundamento maior na utilização do sistema,

geralmente exigindo usar recursos de parametrização de perfis bidimensionais,

ou mesmo linguagens de programação para implementar algoritmos de

reconhecimento (interativo ou automático). Na prática, esse tipo de usuário é

não é fácil de encontrar.

44..55.. RREEPPRREESSEENNTTAAÇÇÃÃOO DDEE FFEEAATTUURREESS

Segundo (SALOMONS, 1995), a representação de features refere-se a como

a informação da feature – características e comportamentos – é representada

internamente no computador.

Para melhor se adequar ao processo de projeto, as features devem ser

entendidas em termos de sua geometria, especificações e detalhes para

satisfazer certos requisitos funcionais. A representação de feature também

inclui os métodos e as restrições para sua criação. Desta forma, elas

automatizam muitas tarefas freqüentemente realizadas pelo usuário durante a

modelagem geométrica do produto.

Um ambiente de modelagem de features deve fornecer métodos para

instanciação de novas features durante a utilização do sistema pelo usuário.

Normalmente, estes métodos de instanciação são os mesmos para todos

os tipos de features. Assim, cada feature possui um conjunto de métodos que


não se alteram, independentemente das outras features existentes na

biblioteca do ambiente e de outras que venham a ser adicionadas ao sistema.

Esse conjunto de métodos pode fazer parte da interface do usuário, para

auxiliá-lo durante o processo de instanciação. E a execução desses métodos,

deve disparar um processo de atualização da base de dados do sistema, para

que o mesmo mantenha-se ciente do estado do modelo de features do produto.

44..66.. TTÉÉCCNNIICCAASS DDEE GGEERRAAÇÇÃÃOO DDEE FFEEAATTUURREESS

4.6.1. RECONHECIMENTO INTERATIVO/MANUAL DE FEATURES

O usuário seleciona, interativamente na tela, elementos de um modelo

geométrico já representado, e os redefine como fazendo parte de uma feature

predefinida no sistema. O processo de reconhecimento é manual, e depende da

interpretação do usuário. Segundo (SHAH, 1991), esse tipo de abordagem tem

sido bastante utilizada para a entrada de dados em programas de

planejamento de processos, e geração de trajetórias de ferramentas em

programas de comando numérico (CNC – Computer Numerical Command).

4.6.2. RECONHECIMENTO AUTOMÁTICO DE FEATURES

A partir do modelo geométrico previamente representado, um algoritmo

computacional é executado para identificar automaticamente as features.

Jasthi e Dong, citados por (MAZIERO, 1998), argumentam que nessa

abordagem, é preciso desenvolver algoritmos complexos e específicos para fazer

o reconhecimento automático de formas geométricas simples. Isso torna a

abordagem difícil de ser aplicada na prática. Para (BRONSVOORT, 1994), o

reconhecimento de features é uma atividade um tanto redundante: na fase de

projeto, os conceitos de alto nível de informação do produto são traduzidos pelo

projetista em informações geométricas de baixo nível, as quais voltam a ser

processadas na fase de reconhecimento, com a finalidade de recuperar

novamente as informações de alto nível do produto.

(FUH et al., 1996) apresentam um sistema CAD/CAPP/CAFD (Computer-


Aided Fixture Design) integrado e baseado em inteligência artificial, o qual

utilizando a linguagem de programação computacional Prolog, faz o

reconhecimento de features através de regras e fatos. O sistema utiliza uma

representação tridimensional da peça para extrair as informações geométricas,

e uma representação bidimensional para extrair a informação tecnológica. Eles

também reconhecem que as definições de features podem ser ambíguas,

resultando na dificuldade de extração da features. Por outro lado, eles também

afirmam que a abordagem de projeto por features é inconsistente com o que

tradicionalmente é seguido pelos projetistas, o que pode forçá-los a trabalhar

em detalhamentos e especificações muito maiores e bem antes do estágio

realmente necessário. Essa forma de trabalhar é bastante observada em alguns

sistemas CAD, os quais apresentam todas as informações das features no

momento da sua criação ou instanciação.

(MAZIERO, 1998) observa que a inconsistência entre a forma de trabalhar

dos projetistas e dos sistemas CAD, pode ser contornada adotando-se uma

metodologia onde as informações possam ser repassadas ao modelo num

momento conveniente para o projetista. Por exemplo, inicialmente pode-se

deixar o projetista livre para criar as formas geométricas inicias do projeto; e

somente depois ou quando o projetista achar oportuno, permitir a cotagem de

dimensões e especificações de tolerâncias. Esse seria o comportamento ideal de

um sistema CAD de suporte às atividades de projeto.

4.6.3. PROJETO POR FEATURES (DESIGN BY FEATURES)

O modelo da peça é representado diretamente no sistema através de

features. Nessa abordagem, o usuário baseia-se na existência de uma

biblioteca de features e de procedimentos de utilização preconcebidos em

termos de primitivas de Engenharia, procurando obter uma representação de

mais alto nível, próxima à necessidade de concepção do projetista e que reflita

a sua intenção ou raciocínio.

Existem dois métodos de implementação da abordagem de projeto por

features: a geometria destrutiva, e a síntese de elementos volumétricos. A

geometria destrutiva baseia-se na subtração ou extração de volumes da peça

em bruto ou matéria-prima, representada por um bloco ou volume inicial. Esse


método está intrinsecamente associado ao processo de fabricação. O segundo

método trabalha com a junção elementar de volumes, os quais são definidos de

acordo com o projeto ou significado de manufatura.

Schulz, citado por (MAZIERO, 1998), compara essas metodologias

considerando o suporte para o projetista. Ele destaca algumas vantagens da

abordagem de projeto por features com relação às outras abordagens

mencionadas:

• O projetista interage com o sistema, o qual oferece uma semântica que

representa elementos de projeto e manufatura;

• As relações geométricas são definidas para o mais alto nível, o que

evita a interação com a geometria de baixo nível, e reduz as

possibilidades de erro;

• Permite que o projetista transfira informações da base de dados que

está disponível durante o processo de projeto;

• O modelo da peça captura muito mais informações, tanto geométricas

como tecnológicas, o que permite a sua reutilização em estágios

subseqüentes do ciclo de vida do produto;

• As bibliotecas de features podem ser usadas para modelar peças, com

a possibilidade de simular a sua fabricação e estimar custos;

• As intenções e o raciocínio do projetista são capturados no modelo do

produto.

Para Mäntylä, as principais vantagens no uso direto de features no projeto

incluem:

• Um vocabulário mais natural para expressar as peças do produto, do

que simplesmente a modelagem geométrica;

• A possibilidade de usar features como base para a modelagem de

informações do produto em diferentes fases do projeto ou do seu ciclo

de vida;

• Um aumento de produtividade do projetista.

(MAZIERO, 1998) adverte que a utilização de features conduz a uma

especialização cada vez maior do sistema, à medida que o nível de informação


vai tornando-se mais alto. Como vantagem compensadora, tem-se maior

rapidez em produzir o projeto, e conseqüentemente, redução do custo final do

produto e vantagem sobre a concorrência. Uma desvantagem que pode ser

mais aparente no início da construção e utilização de uma biblioteca é a

limitação de opções de features que restringe o seu domínio de aplicação. Mais

esse é um problema que também vai se contornando, à medida que a biblioteca

é atualizada e acrescida de novas features.

44..77.. IIDDEENNTTIIFFIICCAAÇÇÃÃOO DDEE FFEEAATTUURREESS

Cada produto tem seu conjunto característico de features. As features são

também dependentes do processo usado para criar um produto.

(SHAH e MÄNTYLÄ, 1995), baseando-se numa visão de espaço vetorial,

colocam que a definição da feature é dependente dos seguintes elementos: o

tipo de produto, a aplicação, e o nível de abstração. A Figura 27 resume isso,

colocando os três elementos como bases para a definição do espaço de

features. Esses elementos devem ser considerados e podem ser utilizados como

critérios de uma classificação de features.

Figura 27. Contextos relevantes na definição de uma feature.

Um conceito importante para esse trabalho, define o que pode ser

chamado de featurização de um produto. A featurização é um processo de

encapsulação das características geométricas e funcionais do produto, no

contexto de uma aplicação específica, através da utilização do conceito de

features.

Em cada aplicação, é preciso realizar três passos para concluir o processo

de “featurização”:

Tipo de Produto Aplicação

Nível de Abstração

Espaço de Features


• Identificação: significa determinar quais regiões ou partes do produto

podem ser consideradas um estereótipo de forma, sendo tratada como

uma unidade de informação com significado para o contexto do

projetista.

• Formalização: significa identificar as propriedades (nome, tipos de

atributos e parâmetros) de uma classe de feature necessária para a

aplicação. Pode-se ver que é um processo de modelagem da informação

contida na classe de feature.

• Arquivamento: significa pensar na representação computacional da

classe de feature identificada e modelada nos passos anteriores, de

forma a disponibilizá-la numa biblioteca de features.

A identificação e formalização de features constituem-se num processo

custoso e evolutivo, cujos benefícios são de longo prazo. Somente após atingir

um certo número de features na biblioteca, é que se pode ter os benefícios

esperados de aumento da produtividade e rapidez no processo de projeto e

desenvolvimento do produto.

Por conta desses “porém” quanto à utilização da tecnologia de features

para gerar o produto no sistema CAD, é que se deve fazer uma análise acurada

antes de realizar uma featurização do produto. Uma questão que pode ser

considerada é se o ciclo de vida do produto é longo o suficiente para justificar

um investimento em se fazer a featurização. A consideração é pertinente, pois

não se justifica formalizar uma feature para que ela seja mais adiante

esquecida numa biblioteca, e não seja reusada. Isso vai de encontro,

completamente, com os princípios de definição de uma feature já discutidos

anteriormente. A idéia é que as features sejam reusáveis e extensíveis para

aplicações subseqüentes do ciclo de vida do produto.

44..88.. CCLLAASSSSIIFFIICCAAÇÇÃÃOO DDEE FFEEAATTUURREESS

A classificação de features é necessária para que sejam conhecidos

realmente os tipos de features existentes e a sua localização dentro do contexto


em análise.

As features de forma são classificadas, inicialmente quanto ao modo de

representação, em:

• Features Paramétricas: podem ser instanciadas através de um

conjunto de parâmetros geométricos.

Ex.: Um furo pode ser definido pelos seguintes parâmetros, o valor do seu

diâmetro e do seu comprimento (profundidade).

• Features Não-Paramétricas: são definidas através de um conjunto de

entidades geométricas de baixo nível, explicitamente identificadas; ou

por um conjunto específico de features paramétricas (Macros), onde são

definidas através da descrição da forma.

Ex.: Um furo passante pode ser definido pelas suas superfícies – a lateral,

a de entrada, e a de saída.

Em termos de contexto de aplicação, uma outra classificação de features

pode ser dada por:

• Features Macro ou Globais: quando podem e são utilizadas em

qualquer fase do processo de projeto mecânico; e podem ser

instanciadas para qualquer aplicação, quando requerida.

Ex.: parafuso comum (regular bolt); haste rosqueada (stud bolt); mola

(spring); engrenagens retas (spur gears); engrenagens cônicas (bevel gears);

engrenagens helicoidais (helical gears); rolamentos de rolos (roller bearings);

polia com aros ou de raios (pulley with arms or web).

• Features Micro ou Locais: quando possuem um contexto bem

específico, particular, ou detalhado.

Ex.: rebaixo (counterbore); escareado (countersink); cotovelo (elbow); placa

dobrada (bend plate); cunha ou plano inclinado (wedge); elemento para

suportar esforço de escoramento ou pressão, semelhante a um olhal (seam).

• Features de Fabricação: features relacionadas a operações comuns de

processo de fabricação, tipo:

Ex.: dobramento (bend); torção (twist); conformação ou estampagem

(stamping).

(MCGINNIS e ULLMAN, 1992) classificam dois tipos de features que os


projetistas utilizam no contexto do projeto mecânico:

• Features de Forma: incluem as features geométricas, topológicas, de

fabricação, e features de tolerância, além de quaisquer outras features

utilizadas para descrever a estrutura física dos objetos de projeto.

• Features Funcionais: incluem o propósito, intenção do objeto de

projeto, tais como suporte, estabilidade, ou resistência; e o

comportamento que o objeto de projeto tem, tais como se ele suporta,

gira, ou desloca-se, etc..

Ex.: Um elemento pivô. Algumas features de forma consideram a

geometria, diâmetro, posição, e processos de fabricação. Enquanto que a

feature funcional poderia defini-lo como um objeto, que fornece um ponto

de suporte onde outros elementos giram em torno.

44..99.. EEXXEEMMPPLLOOSS DDEE FFEEAATTUURREESS NNOO SSIISSTTEEMMAA CCAADD

As funcionalidades proporcionadas por cada um dos sistemas são

basicamente as mesmas. A diferença maior é percebida apenas na interface do

usuário que o sistema oferece.

Os sistemas variam quanto à origem (comercial ou acadêmico), à

quantidade de features disponíveis, à integração com o modelador de sólidos,

aplicação (projeto, fabricação, etc...) e grau de avanço tecnológico. Geralmente,

elas permitem a modelagem geométrica de formas sólidas baseadas em

features genéricas ou especializadas.

Importante ressaltar que as definições das features encontradas nos

sistemas CAD atuais, comumente abordam apenas a visão de detalhes

construtivos da peça. Esses detalhes são definidos com base nos conceitos de

fabricação, em features de forma tais como: arredondamentos, chanfro, furo,

canal, nervuras, reforço, etc.. As definições dessas features encapsulam apenas

o caráter geométrico numa forma parametrizada, a seqüência de construção,

ou os parâmetros básicos em caixas de diálogo. O caráter semântico das

intenções do projetista em utilizar a forma geométrica para gerar a solução de

projeto é perdido, e não é associado ao modelo geométrico. Assim, o modelo de


informação de projeto é “pobre” de informação não-geométrica relacionada ao

projeto.

A Figura 28 apresenta exemplos de features genéricas e especializadas

encontradas no MicroStation Modeler v7.1, da Bentley.

Figura 28. Exemplo de features básicas, genéricas e especializadas no

MicroStation Modeler v7.1.

A Figura 29 apresenta o conjunto de features do sistema CAD Solidworks

v99. O sistema é fornecido pela empresa de mesmo nome que o do produto.

Figura 29. Barra de ferramentas das features definidas no sistema CAD

Solidworks.

A Figura 30 apresenta o conjunto de features do sistema CAD Solid Edge

Part v7.0, da Unigraphics Solutions.

Figura 30. Barra de ferramentas das features definidas no sistema CAD Solid

Edge.

Outros exemplos de sistemas CAD, criados em pesquisas acadêmicas, que

adotaram o conceito de features podem ser consultadas nas seguintes

referências: (SHAH e MÄNTYLÄ, 1995), (SALOMONS, 1995), (MAZIERO, 1998),

(SCHÜTZER et al., 1999), (BIDARRA e BRONSVOORT, 2000), etc..


SSiisstteemmaass CCAADD nnoo PPrroojjeettoo MMeeccâânniiccoo


No começo da utilização dos sistemas CAD nas atividades de projeto, a

principal preocupação se concentrava na automação das atividades

relacionadas à geração de desenhos técnicos. Os sistemas CAD eram vistos e

usados como pranchetas eletrônicas estilizadas.

Na maioria dos casos, a aplicação deles se resumia a automatizar

atividades com características tais como:

• Atividades repetitivas e tediosas: geralmente esse tipo de atividade não

acrescenta nenhum ou pouco valor técnico de Engenharia à atividade

principal, que no caso do CAD, deveria ser de projetar e de suportar o

processo de projeto;

• Atividades que possuem uma seqüência de implementação definida e

padronizada; ou seja, adequada a um processo de automatização.

O objetivo principal era aumentar a produtividade e a documentação do

CAP. 5 – SISTEMAS CAD NO PROJETO MECÂNICO 65

desenho detalhado do produto. Esse objetivo foi alcançado, de certa forma,

quando os recursos do CAD eram aplicados correta e extensivamente no

ambiente de trabalho. Todavia, é fato que a ferramenta adequada não é

condição suficiente para garantir bons resultados. Ela apenas habilita o

usuário a conseguir o objetivo pretendido.

A adaptação ao uso de uma nova tecnologia ou à mudança de

procedimentos, mesmo que através de uma boa ferramenta, sempre exige um

esforço inicial e alguns percalços até se conseguir o domínio pleno ou

satisfatório da ferramenta. Esse período de adaptação depende de alguns

fatores, sendo que os principais e mais decisivos apontados aqui são:

• Nível de conhecimento teórico/prático do usuário: é desnecessário,

senão redundante enfatizar que experiências anteriores com a

utilização, ou um conhecimento teórico embasado no potencial de um

sistema CAD genérico, ou ambos, são necessários para utilização

satisfatória dos recursos de produtividade oferecidos por um sistema

CAD. O mais importante e que exige mais perícia, atenção e tempo, é

saber visualizar as limitações na aplicação do sistema.

• Facilidade que a tem ferramenta de oferecer, quanto ao uso, os seus recursos computacionais: neste ponto é decisiva a importância

da interface do usuário. Uma interface mal projetada induz erros ou

deixa o usuário indeciso durante a realização de algumas operações, ou

pode até mesmo embutir vícios na forma de trabalhar de um usuário

mais incauto ou inexperiente. No sistema CAD, uma interface amigável

deve conduzir o usuário na realização da operação, de forma a levá-lo

ao término dela, sem atropelos e sem a necessidade de tentativas

prévias para entender ou dominar o recurso.

55..22.. MMUUDDAANNÇÇAASS DDEE AAPPLLIICCAAÇÇÃÃOO DDOO SSIISSTTEEMMAA CCAADD

Ver-se que a forma como era encarada a aplicação do sistema CAD é a

mesma que de uma ferramenta computacional qualquer. Isso reflete o


pensamento da época da introdução dos computadores dentro da rotina do

ambiente de trabalho, onde se buscava apenas automatizar tarefas.

Devido à importância dos sistemas CAD, e CAX’s em geral, justifica-se a

procura dos aspectos necessários para otimização da aplicação de tais

ferramentas no suporte ao projeto. Os sistemas CAD exercem um papel

importante de documentação, gerenciamento, compartilhamento e troca de

dados de projeto na maior parte das atividades de um sistema de fabricação.

Tem-se exigido dos sistemas CAD uma adaptação à realidade de um

mercado consumidor ansioso por diversidade e qualidade nos produtos

fabricados, e ao dinamismo da economia globalizada. Na rotina das empresas e

escritórios de projeto, isso é refletido pelo aumento do fluxo de informações e

dados intersetores, os quais precisam estar integrados dentro do processo de

projeto e do fluxo de trabalho. Num ambiente como este, a medida de

produtividade do sistema CAD está associada diretamente à flexibilidade e aos

seus recursos computacionais. São essas qualidades que habilitam o sistema

CAD se integrar às atividades de projeto e desenvolvimento do produto. Essa

não é só uma exigência feita aos sistemas CAD, mas a todas as ferramentas

computacionais de suporte ao projeto, que a documentação dos dados e

informações relacionadas ao projeto sejam de alguma forma armazenadas e

capturadas adequadamente no computador.

Embora a modelagem geométrica represente um importante avanço e

melhoramento sobre os sistemas CAD, estes ainda possuem algumas

deficiências que precisam ser consideradas para efetivamente servirem como

meio de integração com outras atividades relacionadas à Engenharia. Abaixo,

listam-se algumas dessas dificuldades ou questões ainda não otimizadas pelos

sistemas CAD:

• Interpretação da informação geométrica a partir do ponto de vista de

fabricação;

• Disponibilidade de informação associada – tipo não-geométrica –

necessária para um processo subseqüente de planejamento;

• Dificuldade de integrar sistemas especialistas ou modelos de análise

com modelos geométricos;

• Falta de padronização na forma de representação computacional da


informação e do dado de projeto no CAD;

• Dificuldade de processamento de dados abstratos, que muitas das

vezes dizem respeito à intenção do projetista;

• As bases de dados ou modelos de dados de informação não suportam

todas as informações processadas num ciclo de desenvolvimento do

produto.

(ULLMAN et al., 1990) adverte que o suporte proporcionado pelos sistemas

CAD concentra-se muito mais em suportar o desenho (“D” – DRAFTING) em si,

do que atender às necessidades de projeto (“D” – DESIGN).

Wigard, citado por (MAZIERO, 1998), afirma que nos programas

CAD/CAM atuais, o usuário deve expressar o conceito que ele quer representar

usando elementos relacionados à representação interna do modelo. Isso pode

mascarar o real significado dos conceitos, e levar o raciocínio e a criatividade

do projetista para questões não relacionadas com a sua atividade principal,

que é projetar. E essa forma de visualizar a ferramenta CAD está passando por

um processo de grandes mudanças. Conforme já advertido, o CAD deve deixar

de ser apenas desenho (drafting, drawing) e assumir a sua verdadeira

identidade, o projeto (design).

Atualmente, os sistemas CAD buscam se equipar de um conjunto de

recursos computacionais que auxiliem o projetista não só na geração de

desenhos apropriados para a fabricação; mas também e, sobretudo, numa

série de tarefas de Engenharia presentes no processo de projeto. Eles vêm

evoluindo progressivamente para sistemas capazes de auxiliar o projetista

durante todo o processo de projeto, lidarem com qualquer tipo de objeto direta

ou indiretamente relacionado e, conectarem-se com quaisquer outros sistemas

de informação. Isso é um processo transitório de mudança de pensamento, e

que deve levar alguns anos para encontrar o seu ponto de equilíbrio. A Figura

31 ilustra o que foi discutido no texto acima.

Através de experimentos e uma análise dos resultados obtidos, (ULLMAN

et al., 1990) também assinalou quatro áreas onde a ferramenta CAD pode e

deve se desenvolver. São questões onde ainda muitas pesquisas podem ser

realizadas. Essas estão resumidas e comentadas abaixo:


• Permitir e oferecer entradas de informações e dados de projeto por meio

de rascunhos, uma forma rápida e comumente usada por engenheiros

e projetistas para materializar idéias. E essa informação tem os seus

méritos e seu valor técnico;

• Permitir uma variedade de interfaces para o projetista. Isto não

significa disponibilizar mais formas para definir um círculo, mas

selecionar e padronizar uma interface que aproxime o usuário da

ferramenta computacional;

• Reconhecer features dependentes do contexto de aplicação e tratá-las

como objetos;

• Ser hábil a gerenciar restrições abstratas e restrições funcionais, e

garantir ou sugerir solução para elas.

Figura 31. Evolução da tecnologia dos sistemas CAD.

55..33.. RREECCUURRSSOOSS CCOOMMPPUUTTAACCIIOONNAAIISS DDOOSS SSIISSTTEEMMAASS CCAADD

Certas características e recursos computacionais de um sistema CAD são,

geralmente, mais requeridos e necessários do que outros. De acordo com

(WAKEFORD e FAY, 1998), quando usuários procuram por um novo sistema

PRO

DUTI

VIDA

DE

1900 1950 1960 1970 1980 1990 2000 TEMPO

Períodos de adaptação com a nova tecnologia

CAD

Computação Gráfica Interatividade

CAD Integrado e Corporativo Ferramentas de EEM

Prancheta


CAD para atender às suas necessidades mais básicas e comuns, eles listam os

seguintes itens:

• Habilidade de importar dados a partir de outros sistemas CAD;

• Integração e conectividade com sistemas CAM;

• Interface do usuário.

Essas características e recursos do sistema CAD acabam servindo de

critério decisivo para escolha, pois elas servem de apoio básico para utilizá-lo

eficientemente e produtivamente. Os dois primeiros itens listados acima estão

diretamente relacionados ao formato de arquivo proprietário do sistema CAD, e

à estrutura de dados e informações.

Os sistemas CAD oferecem algumas ferramentas e recursos de

personalização, os quais permitem desenvolver e implementar outros recursos

estendidos e mais ajustados às necessidades específicas de um usuário. A

título de exemplo, citam-se alguns recursos encontrados no sistema CAD

MicroStation/J Modeler, da Bentley.

• Modelagem paramétrica: Perfis paramétricos bidimensionais, definição

de restrições geométricas e relações dimensionais entre entidades

geométricas e gráficas. Exemplo na Figura 32;

• Desenvolvimento de bibliotecas de células personalizadas;

• Definições de features básicas. Exemplo nas figuras no tópico 4.9;

• Bibliotecas de componentes padronizados. Exemplo na Figura 33;

• Interface de integração com sistemas de banco de dados, permitindo o

sistema CAD ler informações a partir de um banco de dados;

Ex.: Através de drivers ODBC – Open Database Connectivity, da Microsoft;

ou JDBC – Java Database Connectivity, da Sun Microsystems.

• Interface de integração com linguagens de programação, através de

API’s próprias do sistema CAD.

Ex.: Basic, MDL (MicroStation Developer Language) em C, e JMDL em

Java.

À medida que as informações e os dados vão se tornando mais complexos,

o auxílio de ferramentas computacionais ao projeto torna-se indispensável na


realização de tarefas mais criativas, de gerenciamento e suporte eficiente da

dinâmica de projeto de um produto, como por exemplo:

• Aumento da eficiência dos métodos de modelagem do produto:

captura da intenção do projetista dentro do modelo geométrico gerado

pelo sistema CAD; geração e seleção automática de soluções

alternativas a partir de uma especificação textual ou gráfica de projeto;

• Gerenciamento e manutenção das informações e dados de projeto:

estrutura de dados representativa do contexto de projeto, reusáveis e

extensíveis em aplicações subseqüentes do ciclo de vida do produto;

• Integração com o processo de projeto e fluxo de trabalho da empresa: interoperabilidade com outras ferramentas computacionais;

interfaces computacionais personalizadas e ajustadas para aplicações

específicas.

Figura 32. Exemplo de perfis bidimensionais gerando formas sinuosas.

Figura 33. Biblioteca de componentes padronizados disponíveis no

MicroStation/J Modeler v7.1.

A utilização desses recursos já disponíveis na maioria dos sistemas CAD

classificados como de média e alta aplicação (middle/high-application),

habilitam o usuário a implementar recursos computacionais estendidos, que


atendam e suportem operações comuns desejadas por um usuário.

A intenção é desenvolver recursos que facilitem para o usuário do sistema

a captura da intenção do projetista durante a criação do modelo sólido. Devido

às particularidades próprias da atividade de projetar, é complicado

disponibilizar um conjunto de ferramentas integradas que satisfaçam por

completo as diferentes necessidades do usuário.

55..44.. MMOODDEELLAAGGEEMM DDEE OOBBJJEETTOOSS EEMM CCAADD

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.

O termo “CAD Orientado a Objetos” significa que o sistema usa uma

representação de objetos do mundo real. Isto é, o usuário não opera num nível

semântico de linhas, superfícies ou sólidos primitivos, mas com objetos do

mundo real, tais como porta, janela, peça, ressalto, chanfro, rolamento,

dobramento, etc.. Além disso, o sistema sabe como os objetos interagem com

os demais.

A grande vantagem da utilização de modelagem de objetos em CAD é que

os modelos de objetos se auto-validam, porque eles são descrições dos objetos

do mundo real. De acordo com o conceito, um objeto sabe o que ele é.

Um objeto é uma entidade que combina sua estrutura de dados e seu

comportamento numa estrutura de dados única. Segundo (MONTENEGRO e

PACHECO, 1994), a um objeto qualquer estão associados o seu estado,

comportamento e identidade. Esses elementos são definidos conforme abaixo:

• Estado: o estado de um objeto é definido pelas propriedades

(ATRIBUTOS) que ele possui e pelos correspondentes valores

assumidos por estas propriedades.

• Comportamento: o comportamento de um objeto é definido pela forma

como ele age e reage, em termos de mudança do seu estado e

relacionamento com os demais objetos. A ação e reação dos objetos se


processam através dos seus MÉTODOS.

• Identidade: a identidade de um objeto é definida como a propriedade

que o distingue dos demais objetos.

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

Nos sistemas CAD, seja em termos de Engenharia de Software (o software

em si, do ponto de vista do programador) quanto da modelagem dos dados (o

modelo de informação, do ponto de vista do usuário), a modelagem por objetos

permite desde a modelagem dos dados assim como a modelagem da própria

interface do usuário. Todo o ambiente computacional (estrutura de dados e

interface do usuário) pode ser construído com base num mesmo modelo de

entidades – o OBJETO.

Existem algumas implementações de sistemas CAD baseados em objetos,

todavia estão mais desenvolvidas no âmbito das interfaces para o usuário. No

que se refere à representação computacional da estrutura de dados, existe um

ponto cheio de possibilidades de contribuições, que devem se beneficiar dos

novos recursos de transmissão, acesso, e compartilhamento de informação via

Internet.

A necessidade de utilizar esses recursos de rede computacionais

integradas é crescente na área de Projeto e Desenvolvimento de Produto, a fim


de facilitar a implementação da Engenharia Simultânea.

55..55.. QQUUEESSTTÕÕEESS RREELLEEVVAANNTTEESS NNOO CCOONNTTEEXXTTOO DDAA PPRROOPPOOSSTTAA

Para a implementação dessa proposta de evolução dos dados de projeto,

considerações relacionadas à modelagem de features e orientação a objetos nos

sistemas CAD são importantes. Nas subseções seguintes, são feitos alguns

comentários sobre estes dois tópicos.

5.5.1. O CAD COM MODELAGEM DE FEATURES E ORIENTAÇÃO A OBJETOS

Em termos de desenvolvimento de sistemas computacionais e modelagem

de problemas, a orientação a objetos é a tendência atual em sistemas CAD

(WARMAN, 1990). E esta tendência vem acompanhada da modelagem de

features, a qual se traduz no correspondente paradigma para fins de

modelagem computacional das entidades geométricas e dos conceitos

discutidos nessa proposta.

Sabe-se que, no nível mais básico, os recursos computacionais de

sistemas CAD realizam suas operações sobre primitivas geométricas de baixo

nível. Através dos recursos de personalização e programação busca-se

aumentar o nível semântico das entidades pela introdução de raciocínio do

projetista na modelagem de definição das entidades geométricas do sistema

CAD. Tenta-se dessa forma, facilitar a interface de trabalho do usuário em

manipular as entidades geométricas do CAD.

Atualmente, o conceito mais evoluído, em termos de abstração de entidade

para um sistema CAD, é o de feature. O conceito de feature, sob o ponto de

vista tecnológico de Engenharia, tem um significado e uma relação direta com

a encapsulação de dados geométricos, topológicos e funcionais. O paradigma

de orientação a objetos acrescenta ao conceito de feature, a semântica

(significado) da intenção do projetista, representada pela identificação da

função global do produto ou da forma (geometria, topologia), pelo nível de

abstração, etc..

Através da parametrização e pela definição de restrições geométricas e


relações dimensionais, tem-se a possibilidade de especificar uma feature ou

objeto do domínio de Engenharia.

Todavia, quanto à definição de features, o que se tem nos atuais sistemas

CAD são implementações estáticas, que não agregam mecanismos ou

algoritmos de validação à definição da feature. Os algoritmos de validação

garantem a integridade semântica das features durante as operações de

modelagem de interações com outras features já existentes no modelo. A

importância da validação semântica para a modelagem de features pode ser

constatada nos exemplos apresentados nos trabalhos de (SHAH e MÄNTYLÄ,

1995) e (BIDARRA e BRONSVOORT, 2000).

É neste ponto, de validação das inter-relações entre features e

manutenção do significado, que os sistemas CAD comerciais falham. A causa

se deve à falta de algoritmos de validação para avaliar a integridade da

semântica das features. Essa semântica das features depende da intenção do

projetista em usar uma certa entidade geométrica dentro de seu contexto

específico de aplicação. (BIDARRA e BRONSVOORT, 2000) adverte para o fato

de que os modelos de features atualmente em uso nos sistemas CAD

comerciais são mal definidos, pois ainda não adicionaram a validação

semântica e a manutenção do significado dentro da definição da feature. Neste

caso, o usuário fica encarregado de realizar a verificação e validação do modelo

de features de acordo com a sua interpretação, ou de implementar a validação

dentro da definição da feature.

5.5.2. OUTRAS QUESTÕES

A partir desse estudo, deve-se ponderar sobre duas questões: a validação

do modelo de features no CAD, e a padronização dos termos e definições para

as features implementadas. São questões ainda não resolvidas ou não

incorporadas, de forma comercial, nos atuais sistemas CAD.

No caso da padronização dos termos e conceitos utilizados durante o

processo de projeto, a linha de pesquisa dessa proposta inicia um estudo que

deve modelar os principais conceitos e entidades de projeto. É um importante

benefício resultante da aplicação de uma base comum de features, conceitos e

funções de projeto. Essa base comum minimiza e unifica o escopo de


interpretações por parte dos integrantes de uma equipe de projeto.

Conclui-se também que a maior dificuldade em qualquer classificação de

features, passa pela questão da falta de uma padronização das representações

computacionais utilizadas. Ocorre que, normalmente, embora as features

sejam definidas numa mesma semântica, elas podem apresentar diferentes

representações computacionais. A padronização não é uma tarefa fácil em

qualquer área ou assunto. As variáveis que influenciam a aceitação ou não de

uma padronização são muitas.

Além das ferramentas computacionais adequadas para fins de

implementação, discutiu-se também a necessidade de utilização das

modelagens de features e de orientação a objetos. Juntos, os conceitos de

features e de objetos, possibilitam a captura do significado de Engenharia

presente nas entidades gráficas do sistema CAD.

Essa proposta de um sistema CAD associado às fases do processo de

projeto através da modelagem de features, favorece a troca e o

compartilhamento de dados do processo de projeto, de forma a possibilitar que

o projeto seja gerado, interpretado ou organizado dentro de um sistema CAD.


PPrrooppoossttaa ddee TTeessee


A evolução das decisões no projeto de componentes mecânicos pode ser

capturada ou obtida através de uma análise detalhada dos procedimentos

executados durante as fases de projeto.

A idéia principal desse trabalho é determinar o conjunto de informações

importantes para cada fase de projeto, as quais são modeladas e representadas

como features, e assim obter uma identidade da fase. Esse conjunto de

informações características seria chamado, ou interpretado como uma

identidade da fase de projeto correspondente.

Para a definição das features que representariam a identidade das fases

de projeto, tem-se a necessidade de sistematizar o tipo de informação ou de

dados que ocorrem nas fases; e a forma como esses dados são fornecidos,

representados e armazenados no computador.

As definições de um protocolo e de uma terminologia padronizada e

apropriada de conceitos podem auxiliar na sistematização da modelagem de

informação. Essa sistematização deve priorizar um levantamento de quais

informações são importantes, quais as formas de representação, e o

CAP. 6 – PROPOSTA DE TESE 77

estabelecimento da estrutura de dados adequada para cada fase de projeto, a

qual resulte em informações geométricas e não-geométricas de projeto.

Para a representação desse conjunto de informações, propõe-se a

utilização de modelos baseados em features como unidades de informação. A

intenção nesta proposta é aplicar uma abordagem baseada em modelos de

features de projeto para toda a estrutura de informação do produto.

66..22.. TTRRAANNSSFFOORRMMAAÇÇÃÃOO DDOOSS DDAADDOOSS DDEE PPRROOJJEETTOO

O projeto é considerado como um sistema que transforma informações

(BACK, 1983). Os objetivos de capturar os dados de projeto de um componente

é poder mostrar o desenvolvimento e a propagação das restrições de projeto, a

relação entre as features de projeto e as restrições, e identificar as

necessidades de representação computacional no projeto mecânico. Isso

significa obter um retrato da história do projeto como informação do produto.

No projeto de um componente, algumas restrições sobre sua forma e

função são dadas no início do problema. Outras restrições aparecem a partir

do domínio de conhecimento do projetista. Outras são derivadas a partir de

cada decisão de projeto tomada. É o relacionamento desses tipos de restrições

de projeto que formam o refinamento evolucionário de um componente. Esta

evolução é traçada em detalhes, e a fonte de cada restrição de projeto fica

claramente demonstrada.

Outro objetivo é esclarecer os conceitos e definições, e mostrar os

relacionamentos entre os termos: restrição de projeto e features de projeto.

Esses conceitos são, às vezes, usados de forma inconsistente. Para traçar a

história do projeto de um componente específico, suas restrições e features têm

de ser bem identificadas e esclarecidas, e as relações entre elas desenvolvidas.

Na evolução da história do projeto, alguns requisitos para a representação dos

dados de projeto são identificados.

Para implementação da proposta colocada nesse trabalho, o sistema CAD

é a ferramenta principal. A ênfase neste trabalho será sobre os sistemas CAD,

ou seja, pretende-se pensar em soluções que possam ser incorporadas aos


recursos computacionais normalmente existentes num sistema CAD qualquer,

de forma a melhor integrá-lo à atividade de projeto.

No início da utilização dos sistemas CAD nas atividades de projeto, a

maior preocupação se concentrava na automação dos processos de geração de

desenho. O objetivo era aumentar a produtividade e a documentação do projeto

detalhado do produto. Ou seja, a fase de documentação ficava no final, e

isolada das demais fases do processo de projeto, como mostra a Figura 34.

Figura 34. Fases de projeto com as respectivas entradas e saídas (Baseado em

OGLIARI, 1999).

Conforme mostrado pela Figura 35, é preciso que o sistema CAD

armazene os dados e informações de projeto desde o seu início. Nesse estudo

sugere-se que a fase de documentação do projeto ocorra desde a fase

Informacional/Conceitual até o projeto detalhado. Dessa forma, tem-se a

documentação do produto fazendo parte de todas as fases do projeto, e não

somente do final.

Figura 35. Fases de projeto e documentação do produto.

A partir dessa visualização diferenciada da ordem das fases de projeto,

uma sistemática integrada ao sistema CAD é proposta na seção seguinte.

Projeto Informacional

Informações de Mercado


Concepção do Produto

Leiaute do Produto

Documentação do Produto

Projeto Conceitual

Projeto Preliminar

Projeto Detalhado

Documentação do Produto pelo Sistema CAD

Projeto Informacional

Informações de Mercado


Concepção do Produto

Leiaute do Produto

Projeto Conceitual

Projeto Preliminar

Projeto Detalhado


66..33.. SSIISSTTEEMMÁÁTTIICCAA DDEE PPRROOJJEETTOO NNOO SSIISSTTEEMMAA CCAADD

O reuso, a troca e o compartilhamento de dados e informações de

Engenharia no processo de projeto, necessitam de bases computacional e

metodológica consistentes para serem satisfatórias e eficientes.

A fim de facilitar e otimizar a integração de qualquer ferramenta

computacional na atividade de projeto sugere-se a aplicação de uma

sistemática de projeto, com fases bem definidas.

Assim sendo, com o objetivo de introduzir o uso do CAD suportando dados

e informações gerados nas atividades de projeto, as fases de projeto

consideradas nesse estudo são as que estão representadas por retângulos,

como é mostrado na Figura 35. Com base em (SHAH e MÄNTYLÄ, 1995)

sugerem que uma linguagem para o desenvolvimento de produto deve

considerar dois elementos: o processo e o produto.

Confrontando a Figura 35, com o que dizem acima Shah e Mäntylä, pode-

se visualizar que os processos são as fases de projeto, e dão uma indicação

sobre quais processos os dados do produto estão sujeitos na respectiva fase. Já

as entradas e saídas, representadas por círculos, constituem os estados do

projeto, e dão uma indicação dos dados e informações do produto, ou seja, do

estado do produto. Isso é mostrado na Figura 36.

Figura 36. Processos x Fases de Projeto – Produto x Dados e Informações.

Nesta linguagem de desenvolvimento do produto, os processos informam

sobre a evolução do produto através dos estados de projeto. Cada ação de

projeto o modifica. Ou seja, os estados de projeto são como fotografias

instantâneas tiradas durante seu desenvolvimento. Então, é importante

caracterizar conceitos que estão associados a cada fase do processo de projeto,

e as suas correspondentes transições.

FASE DE PROJETO

dados e informações de

entrada

dados e informações de

saída

Estado (i) do produto

Estado (i + 1) do produto

PROCESSO

ENTRADAS

SAIDAS


Assim, as diferentes fases e transições são classificadas como:

• No Projeto Informacional, as informações de mercado, caracterizadas

pelos interesses ou manifestações das pessoas que direta ou

indiretamente relacionam-se com o produto, transformando-se em

especificações de projeto que caracterizam os problemas técnicos e

as restrições a serem resolvidas.

• No Projeto Conceitual, os valores quantificados das especificações de projeto, transformando-se numa solução de concepção simplificada

para o problema de projeto. Essa solução é caracterizada pelas

principais funcionalidades e princípios de solução, e representados

através de esquemas ou esboços das formas aproximadas do projeto.

• No Projeto Preliminar, as funções do produto e princípios de solução,

transformando-se num leiaute do produto, caracterizado e

representado pelos elementos que constituem o produto e suas

principais geometrias e formas.

• No Projeto Detalhado, tem-se o detalhamento do leiaute do produto.

As entradas e saídas de cada fase de projeto, assinaladas pelos conceitos

em negrito nos comentários anteriores, são compostas por informações

geométricas e não-geométricas. Estas informações podem ser definidas como

features de projeto, e podem ser organizadas de acordo com os princípios de

orientação a objeto, a fim de suportar a reusabilidade da modelagem dos dados

de uma estrutura computacional.

A proposta é de que a evolução do projeto seja baseada: na sistemática de

projeto da Figura 35. E a modelagem dos dados e informações importantes das

fases de projeto se baseie na modelagem de features de projeto e na modelagem

de objetos.

Assim, em cada fase, as features de projeto terão dados e informações

relacionados à sua evolução dentro do projeto. Essas features devem evoluir a

partir dos esboços de formas do projeto e grandezas numéricas extraídas numa

fase informacional e conceitual, para features de detalhamento durante o

projeto detalhado. A modelagem de objetos, por sua vez, fornece os meios e

princípios para definição de estruturas de dados reusáveis e adequadas à


captura do comportamento, da função e da intenção do projetista.

Como um primeiro esforço para implementação dessa proposta, na seção

seguinte são identificadas e classificadas algumas features de projeto.

66..44.. IIDDEENNTTIIFFIICCAAÇÇÃÃOO EE CCLLAASSSSIIFFIICCAAÇÇÃÃOO DDAASS FFEEAATTUURREESS DDEE PPRROOJJEETTOO

6.4.1. IDENTIFICAÇÃO DAS FEATURES

Para realização desta tarefa de identificação e classificação das features

deve-se ter em mente os seguintes aspectos, conforme sugerem (BRONSVOORT

e JANSEN, 1993) e (SHAH e MÄNTYLÄ, 1995): o nível de abstração, o domínio

da aplicação, e o tipo de produto.

O significado de uma informação sempre será dependente do (a):

• Conhecimento prévio e experiência sobre o assunto em discussão;

• Interpretação ou contexto do domínio de aplicação;

• Nível de abstração ou detalhamento do assunto;

• Forma de representação.

Nesse trabalho a princípio, esses aspectos se resumiram a duas questões

básicas:

• Quais conceitos devem ser modelados para armazenar a evolução do

processo de projeto de um produto?

• Quais informações podem ou devem ser armazenadas dentro de uma

classificação de features de projeto?

Abaixo, tem-se a listagem de algumas features que podem ser usadas

durante a modelagem do projeto. As features da fase de projeto são uma

composição de outras features que caracterizam a fase de projeto.

Feature Informacional: questões do projetista, requisitos do projeto.

Atributos: identificador, texto da questão, representação gráfica.


Feature Conceitual: esboço, regiões de interesse ou de atenção especial

no projeto, posicionamentos, restrições dimensionais e geométricas.

Atributos: Dimensões aproximadas (comprimento, altura, largura); Faixa de

valores possíveis e/ou aceitáveis; Distâncias relativas; Forma ou perfil principal;

Orientação.

Feature Preliminar: princípios de solução, leiaute.

Atributos: nome, descrição, representação, função global, listas das

features associadas.

Feature Detalhada: diz respeito às features disponíveis nos sistemas CAD

comerciais, num nível de detalhamento final do projeto. Os valores dos

atributos são mais exatos, ou seja, com baixa probabilidade de incerteza. Isso

se justifica até porque o projeto já está numa fase de detalhamento.

Atributos: Dimensões nominais; tolerâncias, montagem, material,

acabamento superficial, tratamentos térmicos e superficiais.

É fato que algumas das features citadas como exemplo podem estar

presentes em diferentes fases do processo de projeto. Isso exige uma atenção

especial na modelagem da intenção de projeto e no desenvolvimento da

interface do sistema CAD.

Esses conceitos, dados, e informações devem ser visualizados no sistema

CAD numa forma de representação gráfica, quando possível, e modelados de

acordo com os princípios de orientação a objeto.

6.4.2. CRITÉRIOS DE CLASSIFICAÇÃO

Na classificação das features do processo de projeto, os atributos

escolhidos para defini-las estão baseados em alguns critérios. Estes critérios

usados são brevemente descritos na seqüência a seguir:

Critério 1: Identificação da feature

São atributos de identificação da feature dentro do sistema

computacional, tais como o nome e o seu identificador. Os atributos dessa

categoria são importantes principalmente para o sistema CAD, pois a partir


deles pode-se saber quais features estão presentes no modelo de features em

cada estado do projeto.

Critério 2: Dados geométricos ou topológicos

São atributos que informam valores de dimensões que caracterizam a

feature, a forma, as tolerâncias.

Critério 3: Dados ou informações da semântica da feature

São atributos que guardam a informação da intenção do projetista, que

possam ser utilizados tanto numa fase posterior do projeto ou atividade

subseqüente do ciclo de vida do produto. Esse tipo de informação deve ter uma

natureza dinâmica, de adaptação ao contexto de aplicação do dado,

caracterizando um fenômeno de polimorfismo.

6.4.3. ESBOÇO DA PROPOSTA DE ESTRUTURA DE DADOS

As features são modeladas como objetos que encapsulam os dados

geométricos e topológicos, e a sua semântica (identidade, estado,

comportamento) com atributos próprios de cada fase do projeto.

Uma proposta de classificação de features com base no processo de

projeto, que enfatiza a evolução do projeto durante as fases de

desenvolvimento, é dada na Figura 37.

Figura 37. Classificação de features no processo de projeto.

A estrutura hierárquica assume uma característica de relacionamento

FEATURE

FEATURE INFORMACIONAL

FEATURE CONCEITUAL

FEATURE PRELIMINAR

FEATURE DETALHADA


generalização/especialização. Cada classe de feature, por sua vez, assume uma

característica de relacionamento todo-parte.

A classe FEATURE é abstrata, ou seja, não existe instanciação de objetos

desta classe. Em princípio, ela deve ter atributos genéricos para identificação

da feature, e métodos de manipulação, tal como a instanciação, inserção e

remoção da feature no modelo, etc.. A intenção é que outras classificações de

features, em níveis mais inferiores da hierarquia de classes, possam herdar os

seus atributos, e assim favorecer a reusabilidade dos dados.

As demais classes de features – INFORMACIONAL, CONCEITUAL, PRELIMINAR, e

DETALHADA – são especializações da classe-pai FEATURE. Elas serão

constituídas pela composição de outras features, de forma que representam a

fase de projeto correspondente. Visto por esse ângulo, as features serão tidas

como uma “identidade da fase de projeto”, sendo representativas do estado

atual de informação em cada fase de projeto.

A representação dos dados e informações de projeto é dependente da

modelagem realizada para esses dados. A construção de quaisquer outras

unidades de informação, para uma reusabilidade em fases subseqüentes do

processo de projeto ou do ciclo de vida de um produto, também é dependente

desse processo de modelagem. Por isso que uma atenção especial deve ser

dada à modelagem dos dados de projeto, que por sua vez vai decidir o sucesso

ou não de uma proposta para troca de dados eficiente entre as diferentes fases

de projeto. A estrutura de dados deve também servir para tornar mais eficiente

a atividade de projetar o produto utilizando ferramentas computacionais

apropriadas, tais como sistemas CAD otimizados e integrados com ferramentas

e recursos de banco de dados.

66..55.. EEXXEEMMPPLLOO DDEE EEVVOOLLUUÇÇÃÃOO DDOOSS DDAADDOOSS DDEE PPRROOJJEETTOO

Esse tópico tem o objetivo de exemplificar a idéia de identificação de

features que caracterizam as fases de desenvolvimento de um projeto. O

exemplo, baseado em (SHAH e MÄNTYLÄ, 1995), consiste em modelar o

conjunto de informações do projeto de uma placa que suporta o mecanismo de


barras para regular o vidro lateral da porta de um automóvel. O mecanismo é

mostrado na Figura 38.

Figura 38. Mecanismo a ser projetado utilizando o modelo de features.

Esse mecanismo é constituído de vários componentes, a saber: braço da

janela, setor de engrenagem, mola, pivô principal, pivô secundário, motor, e

manivela. A partir da biblioteca de features modeladas para compor a estrutura

do produto, pode-se instanciá-las para compor a informação sobre a estrutura

do produto.

A questão desafiante aqui é estruturar a feature tal que ela possa receber

um vínculo para o modelo geométrico da montagem do produto. Vale ressaltar

também o interesse de que toda informação instanciada possa ser armazenada

através de mecanismos de serialização ou persistência da orientação a objeto.

O tipo de informação instanciado pode ser diverso, o que dificulta a

modelação da feature. A idéia é fazer uma composição de objetos, de forma a

armazená-la como uma feature de alto nível na hierarquia de classes.

Assim, as informações geométricas e não-geométricas das fases

informacional e conceitual, poderiam instanciar features que contivessem

estruturas adequadas para armazenar os dados na forma mais usual, que seja

tabelas alimentadas por banco de dados. As informações seriam então

vinculadas às formas gráficas, as quais são constituídas por features básicas

do sistema CAD.

Uma feature dessa fase do projeto poderia assumir a seguinte forma:

Setor de engrenagem

Pivô principal

Mola Braço da janela

Pivô secundário Manivela

Motor

Região ainda não definida do

motor

Fim de curso


Feature_Informacional { Restrição_PesoConjunto Material Tabela_Necessidades_Cliente Tabela_Requisitos …

}

Seguindo uma metodologia de projeto, poder-se-ia ter uma estrutura de

funções, a qual iria compor a feature conceitual.

Feature_Conceitual { Lista_Funções_Globais Lista_Funções_Parciais Lista_Funções_Elementares Lista_Ícones_de_Projeto …

}

Na fase de projeto preliminar, a informação geométrica ainda não é

definitiva. Se for possível compor um objeto o qual capture as informações

disponíveis nesta fase, elas podem ser usadas definir a feature dita preliminar.

Figura 39. Esboço de uma peça numa fase de projeto preliminar.

Um exemplo de feature preliminar, com base na Figura 39, seria:

Feature_Preliminar { Forma_Esquemática_Produto Posicionamento_Furo

Regiões de interesse

Posicionamento de furos

Perfil externo da peça

Arranjo de furos


Disposição_Furo Áreas_Principais_Produto … }

As features que comporiam o detalhamento do produto, como mostra

Figura 40, seriam advindas do sistema CAD já num nível de detalhamento e

recebendo todas as informações anteriores das fases iniciais de projeto. Esse

tipo de feature detalhada pode assumir a seguinte forma:

Feature_Detalhada { Lista_Features_básicas Features_compostas … }

Figura 40. Detalhamento final do modelo geométrico.

Essa visão das features de projeto modeladas como classes de objetos é a

base dessa proposta de tese. Ela será a base consistente para a integração de

informações entre as fases de projeto.

66..66.. IINNTTEERRFFAACCEE EE AARRQQUUIITTEETTUURRAA CCOOMMPPUUTTAACCIIOONNAALL

6.6.1. INTERFACE DA APLICAÇÃO PARA O USUÁRIO

Dentro do ambiente do sistema CAD, o mesmo deve ser planejado de

Protusão de retenção da mola

reforço para engrenagem

Perímetro do flange

Cavidade para posicionamento do

motor

Furos


modo a incorporar as classes de features de projeto, citadas na seção anterior.

Em cada fase da sistemática de projeto, as features podem possuir

atributos que são específicos, ou seja, que só dizem respeito àquela fase, ou

cuja informação só pode ser inferida naquele instante. Essa característica de

algumas features sugere uma outra classificação considerando o escopo de

atuação da feature durante a modelagem da peça ou produto.

Com base nos exemplos de (ROY e PANAYIL, 1997), a seguinte

classificação de features é dada:

• Features Macro ou Globais: são features que podem e são utilizadas

em qualquer fase do processo de projeto mecânico; e podem ser

instanciadas para qualquer aplicação e quando forem necessárias.

Observa-se que essas features possuem uma semântica bem definida, que

é independente do contexto de aplicação, e possuem alto nível semântico ou

encapsulação de atributos.

• Features Micro ou Locais: são features que possuem um contexto

bem específico, particular, ou detalhado.

A idéia da classificação de features como global ou local, é definir seu

escopo de atuação dentro de cada uma das fases de projeto. Isso pode ser

modelado como sendo mais um atributo da definição da feature, e através de

uma análise e escolha cuidadosa dos modificadores de acesso das classes de

features. Esse atributo ou modificador de acesso vai indicar se a feature é

global ou local. Dependendo desse valor, outros atributos da feature podem

estar habilitados ou não.

A interface do usuário deve apresentar, além das features de forma,

comumente modeladas nos sistemas CAD comerciais e em uso, também

features que encapsulam aspectos informacionais, conceituais, preliminares, e

de detalhamento do projeto.

Essas features poderão estar disponíveis na forma de barra de

ferramentas, onde em cada botão com o rótulo correspondente à classe de

features da fase de projeto que se está modelando.


6.6.2. ARQUITETURA COMPUTACIONAL

Numa etapa posterior, esse estudo concentrar-se-á:

• Em estudar melhor as relações entre conceitos modelados como

features, durante as fases de projeto. Isso servirá para comprovar o

relacionamento entre os conceitos, e a sua evolução.

• E detalhar a interface do usuário e a arquitetura computacional dos

componentes da solução para o ambiente computacional.

A princípio, a arquitetura computacional para o protótipo, deve considerar

a integração entre um sistema CAD, como plataforma-cliente; uma aplicação

de interface do usuário implementada em Java, informações de features de

projeto armazenadas em arquivos de objetos.

66..77.. CCOONNSSIIDDEERRAAÇÇÕÕEESS FFIINNAAIISS

6.7.1. BENEFÍCIOS DA PROPOSTA

Alguns benefícios podem ser inferidos sobre a conveniência de se adotar a

sistemática de projeto juntamente com um sistema CAD.

A principal contribuição é fazer a identificação, classificação e

sistematização das features relacionadas a cada fase. Tais features serão

modeladas como classes de objetos; e dessa forma, disponibilizá-las como fonte

de informação no sistema CAD, para a geração de projetos novos, bem como

para serem utilizadas na recuperação da intenção do projetista durante o

reprojeto e reuso de informação do produto.

Como benefícios secundários ou relacionados, pode-se mencionar que:

• A identificação e evolução de features nas fases de projeto,

incorporadas nas modelagens de feature e orientação a objeto,

sinalizam para o projetista a possibilidade de integração do sistema

CAD com outras ferramentas ou métodos utilizados no processo de

projeto sistemático.

(OGLIARI, 1999) cita alguns desses métodos de sistemática de projeto, já


normalmente usados na fase de projeto conceitual: questionário estruturado,

pesquisa de mercado, casa da qualidade (QFD – Quality Function Deployment),

síntese de funções, matriz morfológica e valoração das alternativas de solução.

• As fases de projeto, com seus dados e informações de entrada e saída,

informam sobre o nível de abstração desses dados que estão sendo

manipulados no estado atual do projeto, e permitem inferir sobre qual

será a sua provável evolução numa fase posterior do processo.

A otimização das ferramentas computacionais para suporte à atividade de

projeto passa por uma solução também otimizada de captura e representação

dos dados de projeto. A necessidade de integração entre diferentes ferramentas

computacionais para suporte ao processo de projeto é um consenso e uma

necessidade compartilhada por vários pesquisadores.


PPllaanneejjaammeennttoo ddaass AAttiivviiddaaddeess ddee IImmpplleemmeennttaaççããoo ddaa TTeessee


O projeto desta tese constitui-se num trabalho inicial de pesquisa sobre a

troca e o compartilhamento de dados de projeto. Esse tema é atual e passível

de várias contribuições. Portanto, é pretensão e acredita-se que os resultados

iniciados por essa pesquisa podem gerar diversos outros trabalhos

complementares e suplementares a esse.

Durante a realização desse projeto, realizar-se-ão as seguintes atividades,

conforme descritas a seguir:

A) ESTUDO DE TÉCNICAS DE SUPORTE À TROCA DE DADOS NO PROCESSO DE PROJETO;

Pesquisa bibliográfica em artigos e periódicos científicos, revistas

especializadas e livros, sobre a descrição de técnicas modernas aplicadas no

processo de projeto.

OBSERVAÇÃO: Essa fase já foi realizada durante no período que

CAP. 7 – PLANEJAMENTO DAS ATIVIDADES DE IMPLEMENTAÇÃO DA TESE 92

compreendeu o início do Doutorado (04/1999) até a presente data. Ela

consistiu de uma pesquisa intensiva nas diferentes formas das fontes

bibliográficas disponíveis, seleção, leitura, interpretação, e discussão para o

enfoque da proposta.

As pesquisas sobre o tema dessa proposta já resultaram em alguns

trabalhos publicados, os quais seguem abaixo:

• Uma Revisão das Tecnologias de Integração de Dados em CAD/CAM.

Trabalho aceito e apresentado no CONEM – Congresso Nacional de

Engenharia Mecânica, em Natal-RN, no período de 07–11/Agosto/2000.

• Um Esboço de uma Nova Sistemática de Suporte às Fases do Processo de Projeto aplicando Sistemas CAD.

Trabalho aceito e apresentado no IX COCIM – Congresso Chileno de

Engenharia Mecânica, no período de 10-13/Outubro/2000.

Esse tema também foi pesquisado num tópico especial como disciplina, e

resultou na redação de uma monografia, a qual foi defendida perante uma

banca examinadora. O objetivo principal foi fazer um levantamento das

técnicas, ferramentas e pesquisas realizadas na troca de dados em CAD/CAM

(CUNHA e DIAS, 2000).

• Estudo e Desenvolvimento de Metodologias na Troca de Dados em CAD/CAM.

B) ESTUDO PRÁTICO DAS FERRAMENTAS E RECURSOS DO SISTEMA CAD MICROSTATION/J E DO SEU MODELADOR DE SÓLIDOS MICROSTATION MODELER;

O objetivo aqui é a organização de informações para troca de dados com

base no conceito de features. Essa atividade compreende a realização de

estudos de caso, com a "featurização" de alguns produtos da indústria

Metal/Mecânica.


OBSERVAÇÃO: No âmbito desta proposta, vem sendo desenvolvido um

trabalho de Mestrado. Nesse trabalho, já foram explorados os recursos

oferecidos pelo sistema CAD, principalmente no que diz respeito aos recursos

de personalização e implementação para o desenvolvimento de funcionalidades

extensíveis ao sistema, além da integração com outros aplicativos: Banco de

dados relacionais, e linguagens de programação.

C) LEVANTAMENTO DAS INFORMAÇÕES E DADOS IMPORTANTES PARA A CARACTERIZAÇÃO DA FASE DE PROJETO;

Nesta fase, o mais importante é identificar principalmente as informações

não-geométricas e associá-las à informação geométrica gerada no sistema CAD.

D) MODELAGEM E IMPLEMENTAÇÃO DE UMA BIBLIOTECA INICIAL DE CLASSES PARA A DEFINIÇÃO DE FEATURES DE PROJETO;

A biblioteca de classes deve ser organizada de forma que possa ser

utilizada no processo de projeto, conforme a proposta se propõe esta proposta.

E) INCORPORAR AO SISTEMA CAD A BIBLIOTECA DE CLASSES DO ITEM D, POR MEIO DE UMA ARQUITETURA COMPUTACIONAL;

A arquitetura computacional deve contemplar a integração entre as

ferramentas (linguagem de programação e sistema CAD). Para tanto será

necessário trabalhar a API de funções do sistema CAD, para realizar a

integração de dados.

F) PROPOSTA DE UMA METODOLOGIA PARA REUTILIZAÇÃO DAS INFORMAÇÕES DE PROJETOS;

Com base nos estudos de caso do item anterior, a metodologia indicará e

serão implementados técnicas e procedimentos computacionais para

armazenamento e recuperação das informações de projeto.

G) ANÁLISE DA PROPOSTA NO SUPORTE AO PROCESSO DE PROJETO; E


ESTABELECIMENTO DE DIRETRIZES SOBRE A ADEQUABILIDADE OU NÃO DAS TÉCNICAS PARA TROCA DE DADOS, EM FUNÇÃO DA APLICAÇÃO ESPECÍFICA.

A título de entender a extensão dessa proposta, a Figura 41 dá uma visão

geral dos principais assuntos relacionados com o tema dessa pesquisa, e de

quais ferramentas de implementação serão consideradas.

Pode-se dizer que até a data presente foi ultrapassada a fase de

Embasamento Teórico, a qual ficou caracterizada pela realização dos créditos

das disciplinas, revisão bibliográfica, treinamento e adaptação com o sistema

CAD e a linguagem de programação Java.

Figura 41. Visão geral das fases de implementação da tese.

As fases seguintes, de Modelagem, Implementação, e Testes, serão

implementadas a posterior. Um início da fase de Modelagem foi dada no

Capítulo 6, a qual é caracterizada pela utilização dos conceitos de orientação a

objeto e tecnologia de features para modelar a informação de projeto.

Na fase de Implementação é onde serão integrados os aplicativos do

EVOLUÇÃO DOS DADOS DE PROJETO

Orientação a O

bjeto

Tecnologia de Features

Sistemática de Projeto

MODELAGEM

Arquitetura C

omputacional

Integração de Ferramentas

Sistema C

AD

Linguagem de Program

ação

Arquivo/Estrutura deTroca de D

ados

TESTES DOPROTÓTIPO

IMPLEMENTAÇÃO

Estudo de Casos

Validação Final

MicroStation / J

Modeler

Linguagem JA

VA

Créditos / D

isciplinas /Estudo D

irigido

Revisão B

ibliográfica

EMBASAMENTOTEÓRICO

TESE

Sistema de B

anco de Dados


sistema CAD e a linguagem de programação, com as classes de features

modeladas na fase anterior, para incorporar as informações não-geométricas

no sistema CAD. É uma fase caracterizada por muita prática computacional.

A fase de Testes consistirá na realização de estudos de caso com vistas a

obter resultados e validar a estrutura de dados, o protótipo computacional e a

toda a pesquisa.

77..22.. CCRROONNOOGGRRAAMMAA DDEE AATTIIVVIIDDAADDEESS

O cronograma de atividades foi segmentado em tarefas a serem realizadas

para se conseguir obter os resultados desejados. A escala de tempo

corresponde aos anos divididos em meses, conforme é mostrado na Figura 42.

O intervalo considerado leva em conta o tempo ainda disponível para

finalização dos trabalhos de tese.

As tarefas citadas no cronograma constituem-se numa visão global apenas

das atividades consideradas mais importantes, e que de certa forma poderão

caracterizar fases de implementação, e gerar resultados para a tese.

Figura 42. Cronograma de Atividades

77..33.. MMAATTEERRIIAAIISS EE EEQQUUIIPPAAMMEENNTTOOSS

Para implementação da tese, têm-se disponíveis recursos computacionais

Identificação das informações deprojeto

Modelagem das classes de features

Aplicação de estudo de caso 1

Testes e validação

Testes e validação

Otimização e ajustes do código

Redação da tese

Aplicação de estudo de caso 2

Implementação da interface doprotótipo computacional

Protótipo computacional

Estágio de docência

Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar

2000 2001 2002 2003Tarefas


de hardware e software.

Nas pesquisas desenvolvidas em CAD/CAM, em termos de equipamento,

dispõe-se de um computador adquirido recentemente (JUNHO/2000) e uma

impressora jato de tinta. A configuração é satisfatória para a realização das

pesquisas.

Segue a especificação: Processador Pentium III 500 MHz; 128 MBytes de

memória RAM; 1 unidade de disco rígido com capacidade de 9.2 GBytes; 1

unidade de drive de 1,44 MBytes; 1 unidade de CDROM 48X, Monitor SVGA de

17 polegadas, dot pitch 0.28; Placa de vídeo de 8 MBytes; Placa de rede; e

Impressora HP DeskJet 680C.

Em termos de software, dispõe-se de um sistema CAD com módulos para

Engenharia Mecânica. Trata-se do MicroStation/J, da Bentley, versão 7.1, e do

Modelador de sólidos Modeler, também da Bentley.

Os pacotes de linguagem de programação Java, são disponíveis

gratuitamente na Internet na URL da Sun Microsystems (www.java.sun.com).

RReeffeerrêênncciiaass BBiibblliiooggrrááffiiccaass

ACHTEN, H.; LEEUWEN, J. van.. A Feature-based Description for Design Processes: A Case Study. 1998. URL: http://ds.calibre.bwk.tue.nl/ Research/publications/ddss98/achten.pdf, OUTUBRO–2000.

BACK, N.. Metodologia de Projeto de Produtos Industriais. Rio de Janeiro, Ed. Guanabara Dois, p. 389, 1983.

BIDARRA, R.. Validity Maintenance in Semantic Feature Modeling. Delft, 1999, 147 p.. Tese – Technische Universiteit Delft.

BIDARRA, R.; BRONSVOORT, W. F.. Semantic feature modelling. Computer-Aided Design, vol. 32, p. 201-225, Março–2000.

BRONSVOORT, W. F.; JANSEN, F. W.. Feature modeling and conversion – Key concepts to concurrent engineering. Computers in Industry, vol. 21, p. 61-86, 1993.

CUNHA, R. R. M.; DIAS, A.. Estudo e Desenvolvimento de Metodologias na Troca de Dados em CAD/CAM. Estudo Dirigido – Disciplina EMC 6601: Tópicos Especiais em Projeto de Sistemas Mecânicos, Florianópolis-SC, 139 p., Abril–2000.

FOLEY, J. D.; DAM, A.; FEINER, S. K.; HUGHES, J. F.. Computer Graphics – Principles and Practice. Addison-Wesley Publishing Co., The Systems Programming Series, 2a. edição em C, 1996.

FONSECA, A. J. H.. Trechos extraídos de uma versão do trabalho de tese, 2000.

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, vol. 28, No. 3, p. 217-232, 1996.

GOSLING, J.; MCGILTON, H.. The Java Language Environment – A White Paper. Maio–1996. URL: java.sun.com/doc/language_environment, AGOSTO–2000.

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.

IBM, Inc. An Overview of Object Oriented Programming. URL: www.inf.ufsc

REFERÊNCIAS BIBLIOGRÁFICAS 98

.br/poo/smalltalk/ibm/tutorial/oop.html, JANEIRO–2000.

JURISTO, N.; MORENO, A. M.. How to Use Linguistic Instruments for Object-Oriented Analysis. IEEE Software, p. 80-88, Maio/Junho–2000.

KAFURA, D.. Object-Oriented Software Design & Construction with JAVA. Prentice Hall, New Jersey, 655 p., 2000.

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.

MÄNTYLÄ, M.. An Introduction to Solid Modeling. Computer Science Press, 401 p., 1988.

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, 317 p.. Tese (Doutorado em Engenharia Mecânica) – Departamento de Engenharia Mecânica – Universidade Federal de Santa Catarina.

MCGINNIS, B. D.; ULLMAN, D. G.. The Evolution of Commitments in the Design of a Component. Journal of Mechanical Design, vol. 114, Março–1992. URL: www.engr.orst.edu/~ullman

MCMAHON, C.; BROWNE, J.. CAD CAM: Principles, Practice and Manufacturing Management. Addison Wesley Longman, 2a. edição, 665 p., Agosto–1998.

MONTENEGRO, F.; PACHECO, R.. Orientação a Objetos em C++. Editora Moderna, Rio de Janeiro-RJ, p. 394, 1994.

OGLIARI, A.. Sistematização da Concepção de Produtos Auxiliada por Computador com Aplicações no Domínio de Componentes de Plástico Injetados. Florianópolis, 1999, 349 p.. Tese (Doutorado em Engenharia Mecânica) – Departamento de Engenharia Mecânica – Universidade Federal de Santa Catarina.

OZAWA, M.; CUTKOSKY, M. R.; HOWLEY, B. J.. Model Sharing Among Agents in a Concurrent Product Development Team. IFIP Working Group 5.2, 3o. Workshop KIC-3, p. 1-11, Dezembro–1998.

ROY, U.; PANAYIL, D.. Development of a Feature-based Rapid Design Environment. Comput. Appl. Eng. Educ., John Wiley & Sons, vol. 5, p. 41-60, 1997.

SALOMONS, O. W; VAN HOUTEN, F. J. A. M.; KALS, H. J. J.. Review of Research in Feature-Based Design. Journal of Manufacturing Systems,

REFERÊNCIAS BIBLIOGRÁFICAS 99

vol. 12, No. 2, 27 p., 1993.

SALOMONS, O. W.. Computer Support in the Design of Mechanical Products – Constraint specification and satisfaction in feature based design for manufacturing. Twente, 1995. PhD Thesis, Department of Mechanical Engineering, Universiteit Twente. URL: www.pt.wb.utwente.nl /staff/otto/thesis, SETEMBRO–1999.

SCHÜTZER, K.; GLOCKNER, C.; BATOCCHIO, A.. Implementação e Testes de um Ambiente Integrado de Projeto Baseado em “Manufacturing Features”. XV COBEM – Congresso Brasileiro de Engenharia Mecânica, Águas de Lindóia - SP, 22-26/Novembro, 1999.

SHAH, J. J.. Assessment of features technology. Computer-Aided Design, vol. 23, No. 5, p. 331-343, Junho–1991.

SHAH, J. J.; MÄNTYLÄ, M.. Parametric and Feature-based CAD/CAM: Concepts, Techniques, and Applications. Nova York, John Wiley & Sons, 619 p., 1995.

SHAH, J. J.; ROGERS, M. T.. Expert form feature modelling shell. Computer-Aided Design, vol. 20, No. 9, p. 515-524, 1988.

ULLMAN, D. G.; DIETTERICH, T. G.; STAUFFER, L. A.. A Model of the Mechanical Design Process Based on Empirical Data. Academic Press Limited, AI EDAM, vol. 2 (1), p. 33-52, 1988. URL: www.engr.orst.edu/ ~ullman

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: www.engr.orst.edu/~ullman

WAKEFORD, L.; FAY, T.. Choosing a CAD System with Automation in Mind. Computer-Aided Engineering, Julho–1998.

WARMAN, E. A.. Object Oriented Programming and CAD. Journal of Engineering Design, vol. 1, No. 1, p. 37-46, 1990.

ZEID, I.. CAD/CAM Theory and Practice. McGraw Hill, Inc.; New York, 1052 p., 1991.

BBiibblliiooggrraaffiiaass

AU, C. K.; YUEN, M. M. F.. A semantic feature language for sculptured object modeling. Computer-Aided Design, vol. 32, p. 63-74, 2000.

ERIKSSON, H.-E.; PENKER, M.. UML Toolkit. John Wiley Sons, Inc.; New York, 398 p., 1998.

LIU, S.; SOONG, G. E.. Modeling Workflows with Reactive Objects. Proceedings of FAIM, 10th International Conference, College Park, Maryland–USA, vol. 1, p. 623-630, Junho–2000.

OZAWA, M.; CUTKOSKY, M. R.; HOWLEY, B. J.. Model Sharing among Agents in a Concurrent Product Development Team. Submetido ao IFIP Working Group 5.2, Third Workshop KIC-3, Dezembro-1998.

REGLI, W. C.; CICIRELLO, V. A.. Managing digital libraries for computer-aided design. Computer-Aided Design, vol. 32, p. 119-132, 1999.

RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSEN, W.. Object-Oriented Modeling and Design. Prentice Hall, Inc.; New Jersey, 500 p., 1991.

SILVA J., A. C.; DIAS, A.. Desenvolvimento de um Sistema para Troca de Dados em Projeto Mecânico. Estudo Dirigido – Disciplina EMC 6601: Tópicos Especiais em Projeto de Sistemas Mecânicos, Florianópolis-SC, 98 p., Abril–2000.

ULLMAN, D. G.. Toward the Ideal Mechanical Engineering Support System. URL: www.engr.orst.edu/~ullman; www.wbh.com/cadsociety/ wholepage_summit.html

features modelamento 3d

Documents

engenharia mecnica rea

fases de projeto

projeto de sistemas

estrutura de dados

trabalhos de modelagem

dados no processo

proposta de tese

escopo da proposta