 Capa

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

UM SISTEMA DE MODELAMENTO
DE OBJETOS FUNCIONAIS

por

Glaucius Décio Duarte

Dissertação submetida como requisito parcial para
 a obtenção do grau de Mestre em
 Ciência da Computação

Prof. Anatólio Laschuk
Orientador

Prof. Benamy Turkienicz
co-orientador

Porto Alegre, maio de 1990.

In: UFRGS INSTITUTO DE INFORMÁTICA BIBLIOTECA. 

 Texto convertido para formato .epub em setembro/2013, por Fernanda Veleda Camacho
Projeto BibDiPeC, Fase II
Apoio:
PROPESP - IFSul, Campus Pelotas
FAPERGS

 Catalogação na Fonte

CATALOGAÇÃO NA FONTE

Duarte, Glaucius Décio

Um sistema de modelamento de objetos funcionais. Porto Alegre, PGCC da UFRGS, 1000.1 v.

Diss. (mestr. ci. comp.) UFRGS-PGCC, Porto Alegre, BR-RS, 1000.

Dissertação: Computação Gráfica, Geração de Objetos Funcionais, Geração de Objetos Tridimensionais.

 Agradecimentos

AGRADECIMENTOS

Agradeço ao Conselho Nacional de Desenvolvimento Ciêntifico e Tecnológico (CNPq) e à Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES) pelo auxílio financeiro, recebido em forma de bolsa, durante o curso de Pós-Graduação, e ao corpo docente do Curso de Pós-Graduação em Ciência da Computação da UFRGS, em especial ao meu orintador, Anatólio Laschuk, ao meu co-orientador Benamy Turkienicz (prof. do departamento de Urbanismo da Faculdade de Arquitetura da UFRGS), e a profª. Carla Maria Dal Sasso Freitas pelo apoio e pelas sugestões valiosas que muito me auxiliaram na elaboração deste trabalho.

 Lista de Abreviaturas

LISTA DE ABREVIATURAS

CAD (Computer Aided Design)

CAPES  (Coordenação de Aperfeiçoamento de Pessoas Nível Superior)

CNPq  (Conselho Nacional de Desenvolvimento Ciêntifico e Tecnológico)

Cont. (Continuação)

Deslocam.  (Deslocamento)

G+ (Geminação Positiva)

G- (Geminação Negativa)

Identif. (Identificação)

J+ (Justaposição Positiva)

J- (Justaposição Negativa)

Mod. (Módulo)

Quant. (Quantidade)

S+ (Superposição Positiva)

S- (Superposição Negativa)

UFRGS (Universidade Federal do Rio Grande do Sul)

 Resumo/ Abstract

RESUMO

Este trabalho apresenta uma metodologia computacional para a geração, manipulação e visualização de elementos tridimensionais cuja forma geométrica básica é o paralelepípedo. Os entes geométricos são agrupados em classes funcionais de objetos e suas ocorrências são representadas em uma estrutura de dados funcional, criando-se uma representação relacional dos atributos funcionais das respectivas entidades. Além disso, também são consideradas as relações funcionais que podem ser produzidas entre os objetos modelados, estabelecendo-se uma linguagem de ações que permite levar em consideração as consequências funcionais produzidas por um determinado estágio de projeto.

ABSTRACT

This work presents a computational methodology for generating, handling and rendering tridimensional elements using parallelopípedous as theis basic geometric form. The entities geometric are grouped in functional classes of objects and their occurrences are represented in a functional data structure where functional attributes for every entity are included using relational representations. Furthermore, functional relations among modelled objects are also considered and an action language is established in order to consider the functional consequences triggered by design actions during the different stages of the design process.

 Introdução

1.Introdução

A elaboração de um projeto utilizando-se um sistema computacional pode ser vista como um processo de interação contínua entre o projetista e o objeto de projeto, assim sendo, pode-se dizer que "...projetar é uma série de ações ou operações que levam a construção de um produto final". Muitas variáveis devem ser consideradas em um problema de projeto e os valores envolvidos sofrem várias alterações durante o processo. Assim, um projeto apresenta soluções preliminares (projeto esquemático), até atingir aproximações de alto nível (projeto preliminar e final). Portanto, pode-se afirmar que um projeto pode ser elaborado por meio de uma sequência de ações a serem aplicadas, preservando-se a interatividade com o projetista, de forma a permitir um correto feedback, caso seja necessário. (ALVES, 1987)

Computadores constituem-se num meio eficiente de assistência na tomada de decisões na elaboração de um projeto, seja ele, uma nova peça mecânica, uma estrutura de edifício, uma torre de alta tensão ou até mesmo um novo modelo de embarcação. Assim, o projetista pode decidir melhor se possuir um ambiente em que possa criar seu próprio universo de trabalho, i. é, um ambiente que permita a concepção, representação, refinamento e avaliação das ideias de projeto. Um ambiente adequado para desenvolvimento de projetos em arquitetura deve, portanto, permitir o uso de representações gráficas alternativas e manipulação de transformações geométrica. (ALVES, 1987)

Os profissionais envolvidos na tarefa de concepção de um projeto geralmente utilizam representações gráficas ou simbologia escritas, i. é,convenções. As convenções auxiliam tanto os profissionais envolvidos no projeto como a autras pessoas a entenderem melhor as qualidades e características dos objetos projetados. Assim, um ambiente computacional de trabalho adequado, deverá ter condições de representar e entender informações, tais como, tamanhos, proporções, meteriais, temperatura, peso, cores, formas e volumes. (ALVES, 1987)

Muitos sistemas do tipo CAD. (Computer Aided Design) surgiram a partir da metade dos anos 60, principalmente devido ao advento de computadores eficientes e periféricos para exibição gráfica de melhor nível. Inicialmente, os sistemas eram basicamente editores gráficos para elaboração de desenhos em duas dimensões(2D), que ofereciam aos usuários um limitado conjunto de primitivas gráficas (FOLEY, 1982), tais como, pontos, linhas, círculos e arcos. No final da década de 60, novos sistemas surgiram, incorporando recursos limitados para modelagem de objetos em três dimenções, elaborados a partir de construções fundamentadas empontos, linhas e arcos. Este tipo de representação passou a ser conhecido desde então como modelo "wireframe", visto que os objetos modelados por este processo pareciam ser construídos pela interligação de finos arames. Durante a década de 70 os sistemas de CAD passaram a incorporar técnicas para representação de objetos por meio de suas faces e como consequência, começaram a surgir processos para remoção de linhas e faces ocultas (FOLEY, 1982) (ROGERS, 1985), permitindo dessa forma uma representação mais realista e elaborada dos objetos projetados. Também, ao longo dos anos 70 e início da década de 80, problemas como a representação de faces curvas e o modelamento de objetos sólidos (MORTENSON, 1985) começaram a ser estudados pelos pesquisadores que atuam na área de computação gráfica (SMITHERS, 1989), inclusive o grupo de modelagem geométrica da UFRGS. Atualmente, essas técnicas estão implementadas em diversos pacotes do tipo CAD, disponíveis no mercado internacional de software.

Enquanto as técnicas apresentadas acima limitavam-se a uma descrição geométrica dos objetos, novas tendências começaram a surgir, baseadas em novas técnicas que objetivam uma forma de representação que também leva em consideração os relacionamentos funcionais, como pode ser visto em (GRABOWSKI, 1989). Assim, os objetos modelados, além de existirem geometricamente dentro de um universo de trabalho, terão uma função vital dentro do referido universo, e a ocorrência de um objeto poderá apresentar algum tipo de relacionamento com outros objetos. Note-se que um relacionamento poderá ser uma ligação ou um conhecimento recíproco de objetos. Assim, ao ativar-se uma operação alteradora ou de inserção, deve existir um meio para estabelecer as consequêntes alterações nos relacionamentos funcionais produzadas por essa ação, examinando-se também a existência ou não de conflitos ou restrições.

Como exemplo, suponha-se que um projetista está gerando objetos em um sistema de CAD que leva em consideração, além da representação geométrica dos objetos, as relações funcionais reais que ocorrem entre os entes projetados. Então, um objeto inicial é gerado e, após a geração desse primeiro elemento, um novo objeto é criado, sendo conectadoao primeiro. Os dois objetos são constituídos de um tipo de poliestireno expandido, conhecido como isopor, que é um material combustível. Ao ser criado um terceiro elemento, conectado ao segundo e constituído de material ferro previamente aquevido a uma temperatura de 1000°C, os dois primeiros são volatilizados. Nota-se, que se o sistema utilizado para geração dos três objetos fosse um sistema convencional de CAD, i. é, que leva em consideração apenas as características geométricas dos elementos modelados, tal consequência funcional talvez não tivesse sido considerada. Portanto, pode-se concluir que ao projetarmos algum coisa, uma representação geométrica convencional pode não ser suficiente para representar os objetos envolvidos no processo, visto que outros fatores, de carácter funcional, devem ser também considerados.

Os referidos fatores funcionais (funções vitais) de um projeto, podem ser inseridos em um sistema de CAD por meio de mecanismos condicionais ou de controle, aliados a descrição adequadas sobre os objetos envolvidos no projeto. Os mecanismos condicionais podem ser vistos como regras a serem seguidas durante os estágios do processo de projeto. Uma regra pode ser vista como sendo uma ação, que pode ser aplicada a um estágio inicial (um objeto inicial/ uma pré-condição), e cujo objetivo é atingir um estágio final (um resultado / uma pós-condição), que será o produto de uma composição das várias ações aplicadas.

Uma regra poderá ser aplicada a um objeto, para conceber um estágio mais avançago do projeto, paralelamente a um ou mais testes de validação das regras, i. é, ao ser aplicada uma regra, o sistema deverá verificar se a referida ação é permitida (regra válida) ou não (regra inválida). Assim, por exemplo, o plano diretor e ocódigo de edificações de uma cidade estabelecem uma série de construções, estabelecendo as condições mínimas que os ambientes devem satisfazer quanto a estabilidade/segurança, higiene e conforto ambiental. Tais instrumentos de controle poderiam ser vistos como regras que devem ser seguidas pelos proficionais envolvidos neste tipo de atividade. Portanto, um sistema computacional de auxilio a projetos deverá ter condições de indentificar uma ação que seja compatível com as regras estabelecidas. Para possibilitar isso, o sistema deverá possuir uma linguagem própria, de tal forma que permita ao projetista conceber um programa computacional, utilizando uma linguagem de programação própria para projetos, a qual será chamada no decorrer do trabalho de linguagem de ações,como proposto em (COYNE, 1986). Note-se, ainda, que as regras, por exemplo, estabelecem valores mínimos, i. é, o projetista deverá ter liberdade para utilizar valores maiores ou iguais aos estabelecidos, de tal forma que possa aplicar ao projeto um desenho próprio, se assim o desejar.

Além disso, é necessário mencionar mais uma vez, que os elementos de projeto deverão estar vinculados, de tal forma que uma alteração em im deles, poderá ativar uma reação em cadeia, provocando assim, alterações nos demais, se for necessário. Portanto, o sistema deverá ser sensível às modificações, reagindo às ações aplicadas.

A proposta deste trabalho é criar mecanismos computacionais para modelamento de objetos funcionais, permitindo além disso, que o projetista possa se comunicar melhor com os objetos envolvidos no projeto, como sugerido em (ALVES, 1987). O ambiente proposto deverá constituir-se numa ferramenta que permita ao projetista projetar melhor, utilizando-se de um processo que possibilite incluir etapas de "feedback", avaliação e reformulção de táticas envolvidas no processo de projeto (JOROFF, 1984), mas de tal forma que certas condições ou restrições de projeto sejam obedecidas utilizando-se um mecanismo de controle (COYNE, 1986) apropriado, e as consequências funcionais (vitais) sejam consideradas no decorrer das etapas do processo. Deve-se considerar, ainda, que podem existir duas classes de objetos de projeto: exatas (onde as restrições são mensuráveis) e portanto, de difícil mensuração) (TURKIENICZ, 1990). Então, por exemplo, a noção de funçao vital em arquitetura (categoria subjetiva) pode ser considerada imprecisa, e portanto, não deverá ser incluída neste trabalho. Quanto ao cálculo estrutural (categoria exata),a noção de função vital pode ser adotada sem maiores riscos, visto que as restrições podem ser mensuráveis.

 Utilização de regras de "Shape Grammars" na análise e criaçãode projetos

1.1Utilização de regras de "Shape Grammars" na análise e criaçãode projetos

Diversos trabalhos ligados à área de arquitetura fazem referência à utilização de regras de shape grammars na análise e criação de projetos. Uma apresentação de shape grammars é feita em (FLEMMING, 1986):

Shape Grammars podem ser usadas para explicar e descrever uma determinada associação de objetos que possuem características comuns, ou para desenvolver novos objetos e testar as regras em que eles se fundamentam.

Shape Grammars podem conduzir a resultados mais compreensivos, estabelecidos com precisão e rigor, e a um profundo entendimento das questões envolvidas.

Flemming (FLEMMING, 1986), referenciado também em (ALVES, 1987), estabelece a seguinte definição de Shape Grammars:

Shape Grammars: São conjuntos de regras, que, aplicadas a conjuntos de elementos, produzem efeitos sobre estes elementos e seus relacionamentos espaciais. São sistemas fundamentados em regras que, básicamente, consistem de um estágio inicial, um conjunto finito de elementos de um vocabulário, um conjunto de regras de produção (SE-ENTÃO) que são aplicadas aos elementos, e uma condição terminal.

No trabalho (FLEMMING, 1986), Flemming sugere a utilização de shape grammars no estudo de casos de organizações espaciais de residências. Assim, princípios do planejamento espacial poderiam ser estabelecidos, e esses princípios seriam considerados na concepção de regras de shape grammars que seriam utilizadas na geração de plantas baixas, obedecendo somente estes princípios. Então, seria considerado um estágio inicial, composto por um hall de entada, representado por um retângulo rotulado com o indentificador H, além de outros rótulos auxiliares (FR = FRente da casa e FU = FUndos da casa) que seriam utilizados como referenciais para a aplicação de regras de composição espacial . Note-se que os rótulos podem ser vistos como elementos que são utilizados para controlar a maneira como as relações espaciais são realizadas na geração de um novo elemento de um projeto. Então, algumas partes dos elementos de um projeto podem ser rotulados de forma que regras possam ser aplicadas somente se uma configuração correta de rótulos estiver presente. Portanto, certas regras podem ser aplicadas para construír configurações de rótulos para controlar a aplicação das regras subsequentes (ROONEY, 1987). Deve-se mensionar, ainda, que geralmente é desejável que o final de um projeto esteja livre de rótulos ou marcas especiais, visto que sua função é justamente guiar e controlar a geração de elementos. Os rótulos ou marcas são referenciados como dispositivos não terminais dos elementos, visto que eles não aparecem nas produções finais dos projetos válidos. Então, a ausência de rótulos ou marcas produz uma condição para a base de decisão completar a geração de formas usando regras.

 A Figura 1.2 mostra algumas regras que podem ser aplicadas ao estágio inicial para geração de outros estágios do processo de projeto do layout da organização espacial. A primeira regra adiciona uma sala (S) nos fundos (FU) do hall (H) que se localiza na frente da casa. Essa regra se fundamenta no fato de que em muitas casas o hall (H) e a sala de estar são adjacentes na frente da casa. Note-se, ainda, que foi criado um rótulo auxiliar (X) que tanto pode ser (FR) como (FU), o que possibilitaa aplicação das regras para os dois casos, por meio de uma operação de rotação. Além disso, na regra 4, foi utilizado o rótulo que representa o centro da planta.

Assim, por exemplo, aplicando-se a Regra 1 da Figura 1.2 pode-se obter várias soluções para uma organização espacial, que pode ser representada na forma de uma estrutura do tipo árvore, como mostra a Figura 1.3.

 Geração de objetos tridimensionais a partir da sugestão de utilização de regras de Shape grammars

1.2 Geração de objetos tridimensionais a partir da sugestão de utilização de regras de Shape grammars

Na maioria dos trabalhos que referenciam o uso de Shape Grammars na comcepção e análise de projetos, a abordagem bidimensional tem recebido uma maior atenção por parte dos autores (COYNE, 1986) (FLEMMING, 1986) (ROONEY, 1987), ficando a geração tridimensional, geralmente, colocada na forma de sugestões teóricas (AVLVES, 1987) (COYNE, 1986) (FLEMMING, 1986) (STINY, 1985), sem a apresentação de um desenvolvimento prático e formalizado. Assim, por exemplo, Stiny em seu trabalho (STINY, 1985), afirma que projetos podem ser gerados manipulando-se as relações espaciais existentes entre os volumes de um vocabulário. Então, um projeto pode iniciar com um volume simples e um novo projeto pode ser produzido a partir do projeto corrente pela adição ou subtração de um novo volume, criando-se relações espaciais que, posteriormente, poderão ser empregadas na geração de outros projetos, constituíndo dessa forma, uma linguagem de projeto fundamentada em shape grammars.

É de fundamental importância salientar que o trabalho a ser desenvolvido neste documento originou-se na idéia de construção de um "LEGO eletrônico", sugerida pelo arquiteto Benamy Turkienicz e publicada em (TURKIENICZ, 1990). Assim, no sistema proposto por Turkienicz, objetos tridimensionais seriam modelados por meio de acoplamentos, a partir de uma situação inicial, utilizando-se uma gramática de formas (shape grammars). Também, a parte referente à inserção de umalinguagem de ações e dos relacionamentos funcionais foram sugeridas por Turkienicz como objetivos a serem atingidos, o trabalho levou em consideração também uma análise de objetos armados com o jogo LEGO. Foi cedido por Turkienicz, também, um "LEGO de madeira" (TURKIENICZ, 1990) para manipular a análise.

Assim, no decorrer deste documento, o que se pretende fazer é explorar a aplicação das ideias de shape grammars em uma abordagem tridimensional, como sugerido por Turkienicz. A motivação principal para a elaboração dos capítulos constituíntes deste trabalho pode ser resumida em uma pergunta:

Como gerar e manipular objetos tridimensionais, a partir da ideia de composição de projetos utilizando-se regras de shape grammars?

Além de realizar uma investigação para descobrir uma forma adequada de satisfazer à pergunta colocada anteriormente, uma outra questão deverá ser respondida ao final deste trabalho:

Como incorporar os atributos e relacionamentos funcionais (funções vitais) aos elementos tridimensionais de um projeto, de forma que ao ser aplicada uma sequência de ações (regras), as consequências funcionais (vitais) resultantes possam ser obtidas para análise?

Este trabalho foi divido nos seguintes capítulos:

Capítulo 2: Apresenta algumas definições importantes relativas à utilização de regras na geração de volume, de acordo com os princípios de funcionamento de um "LEGO eletrônico", propostos em (TURKIENICZ, 1990).

Capítulo 3: Estabelece conceitos mais formalizados para a geração de volume e apresenta os primeiros mecanismos da linguagem de ações.

Capítulo 4: Apresenta o mecanismo de repetição gerativa, a ser utilizado para a geração simultânea de volumes, de acordo com uma regra de geração pré-estabelecida.

Capítulo 5: Estabelece mecanismos da linguagem de ações para a aplicação de operações de alteração sobre os volumes gerados.

Capítulo 6: Define um mecanismo que permite o acoplamento de dois ou mais conjuntos de volumes, gerados em momentos distintos no processo de projeto.

Capítulo 7: Incorpora procedimentos e dispositivos para automatizar a geração de volumes, de acordo com determinadas regras de ações de projeto. Além disso, são definidos alguns mecanismos auxiliares da linguagem de ações.

Capítulo 8: Acrescenta o mecanismo auxiliar de controle da linguagem de ações.

Capítulo 9: Define mecanismos para incorporar os atributos e os relacionamentos funcionais (vitais) dos elementos de um projeto.

Capítulo 10: Apresenta algumas possibilidades de aplicação das ideias estabelecidas nos capítulos anteriores em outras áreas de pesquisa (biologia, química e matemática).

Capítulo 11: Apresenta algumas conclusões a respeito do trabalho desenvolvido.

Anexos: Ilustram alguns resultados obtidos com a utilização do programa SMOF (Sistema de Modelamento de Objetos Funcionais) desenvolvido para testar as ideias apresentadas no decorrer deste documento.

 Utilização de regras na criação de volumes

2.UTILIZAÇÃO DE REGRAS NA CRIAÇÃO DE VOLUMES 

De acordo com (MAHFUZ, 1983), uma regra importante na geração dos elementos de um projeto é que um objeto inicial deve servir como ponto de partida para o projeto de outro. Assim, a elaboração de um projeto pode ser realizada em diversas etapas, a partir de uma situação inicial. Assim, deve-se gerar um volume inicial, e então, a partir desse volume inicial, criar outros volumes mediante a utilização de determinadas regras de geração de volumes, como sugerido nas definições deshape grammars (FLEMMING, 1986).

O volume básico que será utilizado como matéria-prima para a elaboração dos estudos contidos neste trabalho, será o paralelepípedo. Assim, todas as operações e procedimentos a serem concebidas posteriormente, serão fundamentadas nessa forma. O paralelepípedo foi escolhido porque é uma forma geométrica básica, de fácil definição e manuseio.

Inicialmente, considere-se um volume inicial, (um paralelepípedo), que terá 8 vértices (a, b, c, d, e, f, g e h), como ilustrado na Figura 2.1.

 A partir de V1, pode-se criar outros volumes, aplicando-se três tipos fundamentais de acoplamento de volumes, definidos em (ANDRADE, 1981). Note-se que o referido trabalho apenas define os acoplamentos, não apresentando uma gramática de formas para volumes. A seguir, serão definidos os tipos de acoplamento (positivos e negativos), que também não estão definidos em (ANDRADE, 1981). Observe-se que estes tipos de acoplamento foram definidos nesta dissertação devido a necessidade de acoplar nas duas direções distintas, para um mesmo tipo de acoplamento (geminação, justaposição e superposição). Vale mencionar, ainda, que as operações de acoplamento estão intimamente relacionadas aos rótulos das faces do volume de referência utilizado.

Geminação: É um acoplamento na direção lateral, à esquerda ou à direita do paralelepípedo.

Justaposição: É um acoplamento na parte posterior ou anterior do paralelepípedo.

Superposição: É um acoplamento na direção vertical, acima ou abaixo do paralelpípedo.

Visto que cada uma das três operações de acoplamento definidas acima podem ser subdivididas em duas operações, dependendo do sentido em que o acoplamento ocorrerá, pode-se redefini-las da seguinte maneira:

Geminação positiva: É um acoplamento à direita do paralelepípedo, i. é, no sentido do eixo X.

Geminação negativa: É um acoplamento à esquerda do paralelepípedo, i. é, no sentido inverso ao eixo X.

Justaposição positiva: É um acoplamento na parte posterior do paralelepípedo, i. é, no sentido do eixo Z.

Justaposição negativa: É um acoplamento na parte frontal do paralelepípedo, i. é, no sentido oposto ao eixo Z.

Superposição positiva: É um acoplamento na parte superior do paralelpípedo, i. é, no sentido do eixo Y.

Superposição negativa: É um acoplamento na parte inferior do paralelpípedo, i. é, no sentido inverso ao eixo Y.

As figura 2.2, figura 2.3, figura 2.4, figura 2.5, figura 2.6 e figura 2.7 mostram o funcionamento de cada uma das seis operações de acoplamento definidas acima. Note-se, ainda, que os elementos (volumes) vão sendo conectados como se fossem peças de um jogo de armar, de acordo com a proposta do "LEGO eletrônico", apresentada por Turkienicz (TURKIENICZ, 1990). 

Apertir de agora, torna-se necessário definir um conceito fundamental para o perfeito entendimento do que será apresentado a seguir, visto que este conceito está intimamente ligado à geração de novos volumes. Então, a partir de um paralelepípedo já existente no universo de trabalho pode-se definir:

Semente: é o paralelepípedo que é tomado como base para as operações de acoplamentos e alterações.

Deve-se considerar, então, o caso em que o novo volume a ser gerado pode ter suas dimensões diferentes daquelas que a semente possui. Além disso, se for considerado o fato de que uma operação de acoplamento, utilizando-se paralelepípedos pode ser realizada relativa a cada um dos quatro vértices da face da semente (a face de referência depende do tipo de acoplamento escolhido), é possível definir mais quatro operações a partir daquelas definidas anteriormente. Para demosntrar isso, considere-se o caso de uma germinação positiva.

Em primeiro lugar, torna-se necessário definir os nomes dos vértices, que serão tomados como referência (Figura 2.8).

O passo seguinte será a definição de quatro operações distintas para este tipo de acoplamento, relativas a G1, G2, G3 e G4 (Figuras 2.9 e 2.10).

Se as dimensões do paralelepípedo a ser criado forem maiores que as da semente, as operações acima ilustradas podem ser igualmente realizadas (Figura 2.11 e 2.12).

Outro conceito de fundamental importância é aquele que define as características geométricas de um novo volume a ser gerado:

Volume Padrão: Possui as características do novo paralelepípedo que será gerado a partir da semente.

Finalizando este capítulo, a Tabela 2.1 apresenta um resumo das operações de acoplamento necessárias para a manipulação de volumes (são necessárias 24 operações diferentes).

 Formalizando a geração de volumes

3. FORMALIZANDO A GERAÇÃO DE VOLUMES 

Na seção anterior, foram definidas as regras básicas de geração de volumes (por meio de acoplamentos), essenciais para a manipulação de objetos em três dimensões. Agora, serão estabelecidas alguns conceitos importantes, cuja finalidade, será proporcionar um formalismo adequado às operações de manipulação de volumes. Vale salientar, ainda, que os mecanismos que serão apresentados a partir de agora, posteriormente, farão parte da linguagem de ações que será apresentada no momento oportuno no decorrer deste trabalho.

 Volume Padrão

3.1 Volume Padrão

Em primeiro lugar, deve-se estabelecer as dimensões e demais características do volume padrão, visto que os volumes a serem gerados seguirão o padrão estabelecido por este mecanismo. Assim, pode-se definir o volume padrão:

Volume Padrão

Dimensão em X→ Cx
Dimensão em Y→Cy
Dimensão em Z→Cz
Textura das faces→T
Cor das faces→C

Representação Formal:

VP(Cx,Cy, Cz,T,C)

Como pode ser observado acima, serão necessários cinco parâmetros, na definição do volume padrão. Os três primeiros (dimensão em X, Y e Z), vão definir asdimensões relativas a cada um dos três eixos do sistema de coordenadas. Os parâmetros seguintes, textura e cor, serão utilizados para o preenchimento (pintura) das faces, cuja finalidade será proporcionar um aspecto mais elaborado (realístico), dos objetos gerados.

Volume Inicial

3.2 Volume Inicial

Visto que a criação de volumes será realizada pela aplicação de regras de geração, será necessário gerar uma forma inicial, que será o marco inicial do processo gerativo. Então, estabelecido o volume padrão, deve-se gerar o volume inicial, que será utilizado posteriormente como somente para a geraçãodos demais volumes. Note-se, ainda, que este volume será gerado com as características do volume padrão. O comando formal para geração do volume inicial pode ser visto logo a seguir:

Volume Inicial → VI (NV) : Gera o volume inicial com nome NV

Aplicando operações de transformação para gerar os diversos estágios do processo gerativo

3.3 Aplicando operações de transformação para gerar os diversos estágios do processo gerativo

A geração de um volume inicial pressupõe que existe um estágio zero, no qual não existe nenhum objeto e nenhuma operação foi ainda realizada. Esse estágio será representado por E0.

E0 : Estágio Zero

Gerado o volume inicial, pode-se aplicar uma operação de transformação sobre este volume, cujo objetivo é a criação de um novo estágio do processo gerativo. Esta transformação poderá ser qualquer uma das 24 operações de acoplamento de volume definidas anteriormente, e será indicada formalmente como pode ser visto a seguir:

E1 <- VI : Estágio 1 do processo gerativo é igual ao Volume Inicial.

t <- V(NV, RG) : transformação t gera o volume V, com nome NV e usa regra de geração RG.

 E1 * t  → E2 : Aplicação de uma transformação t sobre o Estágio 1, para geração do Estágio 2 do processo gerativo.

Portanto:

E2 : Estágio 2 do processo gerativo é igual ao volume inicial, mais o novo volume gerado pela operação de transformação t.

Observe-se, acima, que a transformação t necessita de dois parâmetros:

Nome do Volume (NV) : Sua função é proporcionar uma individualização do volume, de forma a permitir sua manipulação.

Regra de Geração (RG) : Estabelece o tipo de regra a ser utilizada na operação de acoplamento estabelecida pela transformação t. RG pode assumir os valores mostrados na Tabela 3.1.

A seguir, será apresentado um exemplo que ilustra a utilização dos conceitos definidos até o momento.

Exemplo 3.1→ Criar um volume inicial, de nome V1, cujas dimensões são todas iguais a 250, com uma textura cujo código é 1 e cor cujo código é 2 e, a seguir, aplicar duas geminações positivas (G1⁺), V2 e V3, e uma superposição negativa (S1⁻), V4, alterando-se a dimensão em 2 do volume padrão para 500.

Passo 1 - Gerar o Volume Padrão:
VP(250, 250, 250, 1, 2)

Passo 2 - Criar o Volume Inicial:
VI( 'V1') → E1

Passo 3 - Aplicar a primeira geminação:
t <- V( 'V2',1)
E1 * t  → E2

Passo 4 - Aplicar a segunda geminação:
t <- V( 'V3',1)
E2 * t  → E3

Passo 5 - Alterar o Volume Padrão:
VP(250, 250,500, 1, 2)

Passo 6 - Aplicar a superposição:
t <- V( 'V4',21)
E3 * t  → E4

A Figura 3.1 mostra o resultado do Exemplo 3.1.

Tabela 3.2 - Resumo dos mecanismos o símbolos do capítulo 

Criando um mecanismo de repetição para acelerar o processo de geração

4. CRIANDO UM MECANISMO DE REPETIÇÃO PARA ACELERAR O PROCESSO DE GERAÇÃO

Como pode ser observado no Exemplo 3.1, apresentado no capítulo anterior, a geração dos volumes V2 e V3, i. é, duas geminações positivas relativas a G1, teve que ser realizada em duas etapas distintas. Outra forma de realizar as mesmas operações, de maneira mais dinâmica (possibilitando maior rapidez na execução do processo gerativo), seria utilizar um mecanismo de repetição automática de operações de transformação (TURKIENICZ, 1990). Assim, seria possível gerar vários elementos do projeto, utilizando-se apenas uma operação de transformação de repetição r, o que produziria, obviamente, uma razoável economia de tempo no processo. 

A seguir, serão definidas algumas regras importantes para a comcepção do mecanismo em questão:

Regra 4.1 - Qualquer uma das operações de acoplamento de volumes poderá ser repetida mediante a utilização da operação de transformação de repetição.

Regra 4.2 - O mecanismo de repetição poderá ser utilizado por um conjunto de regras de geração, para produzir um projeto específico.

Regra 4.3 - O número de repetições, para cada operação de repetição, deverá obedecer a um parâmetro a ser definido na operação de transformação de repetição r.

      Portanto, pode-se definir uma operação de transformação de repetição r, como a seguir: 

           r <- VR (NV, RG, NR) : Transformação de Repetição 

Onde:

NV = Nome dos volumes a serem gerados

RG = Código da regra de geração a ser utilizada na operação de acoplamento (ver Tabela 3.1) (Regra 4.1)

NR = Número de repetições (Regra 4.3)

A seguir, será apresentado um exemplo que ilustra aplicação da operação de transformação r.

Exemplo 4.1 → Gerar um objeto, a partir do volume inicial V1, de mesmas características do Exemplo 3.1, utilizando o seguinte conjunto de regras de egração (Regra 4.2), na sequência solicitada: 3 geminações positivas, 2 justaposições positivas, 3 geminações negativas e 2 justaposições negativas.

→ Passo 1 -  Gerar o volume padrão:

VP (250, 250, 250, 1, 2)

→ Passo 2 - Criar o volume inicial:

VI ('V1') → E1

→ Passo 3 - Aplicar as geminações positivas:

r <- VR ('v1', 1, 3)

E1 * r→ E2

→ Passo 4 - Aplicar as justaposições positivas:

r <- VR ('v1', 9, 2)

E2 * r→ E3

→ Passo 5 - Aplicar as geminações negativas:

r <- VR ('v1', 5, 3)

E3 * r→ E4

→ Passo 6 - Aplicar as justaposições negativas:

r <- VR ('v1', 13, 2)

E4 * r→ E5

O resultado deste exemplo pode ser visto na Figura 4.1.

Ver Tabela 4.1 - Resumo dos mecanismos e símbolos do capítulo

Criando mecanismos alteradores para aumentar as alternativas de projeto

5. CRIANDO MECANISMOS ALTERADORES PARA AUMENTAR AS ALTERNATIVAS DE PROJETO 

Até aqui, para gerar um objeto, era necessário estabelecer um volume padrão e levando em consideração este padrão, gerava-se um volume inicial e a partir desta forma, outros volumes eram criados mediante a aplicação de regras de acoplamento. Se fosse preciso modificar as dimensões de  um dos volumes, isso deveria ser feito antes de sua geração, usando-se o mecanismo de definição de volume padrão.

Neste capítulo, serão definidos novos mecanismos que permitirão alterar os volumes após sua geração. Para tal, será necessário inicialmente, definir algumas regras fundamentais para a concepção dos mecanismos alteradores: 

Regra 5.1 - Os mecanismos alteradores devem ser utilizados após a aplicação das regras de geração de volumes (acoplamentos), visto que para alterar alguma coisa, é necessário que ela já exista.

Regra 5.2 - Serão necessários diferentes tipos de operações de transformação alteradoras, para permitir maior flexibilidade de projeto.

Regra 5.3 - Os mecanismos alteradores devem permitir sua utilização por meio de um conjunto de regras de geração, possibilitando a sua execução automática a partir das necessidades específicas de projeto.

Regra 5.4 - Ao ser ativado, o mecanismo alterador deverá realizar as operações alteradoras em todos os objetos que possuirem o mesmo parâmetro de individualização, i. é o mesmo nome.

A seguir, serão definidas as diferentes operações de transformação de alteração  α básicas para o desenvolvimento de projetos, visando atender a exigência estabelecida pela Regra 5.2.

Alterando as dimensões de um volume 

5.1 Alterando as dimensões de um volume 

Em primeiro lugar, será criada uma operação α, que permitirá alterar as dimensões dos volumes já criados pelas operações de acoplamento (ver Regra 5.1). Visto que na maioria das vezes, considerando-se as experiências de projeto, será necessário alterar apenas uma ou duas das dimensões dos volumes, os mecanismos em questão serão concebidos de tal maneira que as alterações possam ocorrer de forma independente uma da outra. A seguir, são apresentadas as operações para alteração das dimensões de volumes (paralelepípedos).

α <- ACx (NV, NCx) :Transformação Alteradora da Dimensão em X.

α <- ACy (NV, NCy) : Transformação Alteradora da Dimensão em Y.

α <- ACz (NV, NCz) : Transformação Alteradora da Dimensão em Z.

Onde:

NV = Nome do volume que sofrerá a alteração

NCx = Nova dimensão em relação ao eixo X

NCy = Nova dimensão em relação ao eixo Y

NCz = Nova dimensão em relação ao eixo Z

A seguir, será apresentado um exemplo ilustrativo das operações α, definidas até o momento.

Exemplo 5.1 → Gerar os marcos de uma janela (esquematizada logo abaixo), usando regras de geração de volumes e mecanismos alteradores (Regra 5.3).

Olhar esquema da janela Exemplo 5.1

→ Passo 1 -  Gerar o volume padrão:

VP (200, 140, 5, 1, 2)

→ Passo 2 - Criar o volume inicial:

VI ('M1') → E1

→ Passo 3 - Alterar o volume padrão:

VP (200, 10, 5, 1, 2)

→ Passo 4 - Aplicar uma superposições positivas:

S1⁺:

t <- V('M2', 17)

E1 *t→ E2

→ Passo 5 - Alterar a dimensão em Y de M1:

α <- ACy ('M1', 10)

E2 * α→ E3

→ Passo 6 -  Alterar o volume padrão:

VP (95, 130, 5, 1, 2)

→ Passo 7 - Aplicar uma superposições negativa:

S1⁻:

t <- V('M3', 21)

E3 *t→ E4

→ Passo 8 - Aplicar duas geminações positivas:

G1⁺:

r <- VR ('M3', 1, 2)

E4 * r→ E5

→ Passo 9 - Alterar a dimensão em X de M3: (ver Regra 5.4)

α <- ACx ('M3', 10)

E5 * α→ E6

Os resultados do Exemplo 5.1 ( que é uma forma de geração) podem ser observados nas Figuras 5.1 e 5.2.

 Deslocando um volume para outra posição

5.2 Deslocando um volume para outra posição 

Em determinados estágios de projeto, haverá a necessidade de deslocar um volume em particular, de tal maneira que possa ser atendida uma exigência de projeto. Portanto, deve ser criada uma operação de transformação alteradora de deslocamento que possa ser aplicada durante o processo gerativo. Vale salientar, ainda, que as operações de deslocamento d, constituem-se num tipo de operação alteradora α. Assim, será utilizada uma representação diferente, apenas para diferenciar os dois casos das operações de alteração.

Visto que um deslocamento pode acontecer na direção dos três eixos do sistema de coordenadas, serão necessárias três operações de transformação de deslocamento d distintas, para realizar esta tarefa:

d <- Dx (NV, D) : Deslocamento na direção do eixo X

d <- Dy (NV, D) : Deslocamento na direção do eixo Y

d <- Dz (NV, D) : Deslocamento na direção do eixo Z

Onde:

NV = Nome do volume que sofrerá a alteração

D = Valor do deslocamanto do volume em unidades de comprimento, levando em consideração o seguinte:

→ Deslocamento Positivo (+) : No sentido do eixo

→ Deslocamento Negativo (–) : No sentido oposto ao do eixo

Segue, logo abaixo, um exemplo que mostra o funcionamento das operações d:

Exemplo 5.2 → Gerar o objeto esquematizado a seguir, utilizando as operações de deslocamento d.

Esquema do projeto:

 ver esquema da projeto exemplo 5.2

→ Passo 1 -  Gerar o volume padrão:

VP (220, 300, 200, 1, 2)

→ Passo 2 - Criar o volume inicial:

VI ('M1') → E1

→ Passo 3 - Alterar o volume padrão:

VP (20, 300, 200, 1, 2)

→ Passo 4 - Aplicar uma geminação positiva G1⁺:

t <- V('M2', 1)

E1 *t→ E2

→ Passo 5 - Alterar a dimensão em X de M1:

α <- ACx ('M1', 20)

E2 * α→ E3

→ Passo 6 -  Alterar o volume padrão:

VP (200, 100, 200, 1, 2)

→ Passo 7 - Aplicar uma superposições negativa G2⁻:

t <- V('M3', 6)

E3 *t→ E4

→ Passo 8 - Deslocar M3:

d <- Dy ('M3', 100)

E4 * d→ E5

As Figuras 5.3 e 5.4 mostram os resultados do Exemplo 5.2, cujos passos do processo gerativo foram apresentados logo acima:

 Trocando o volume de referência 

5.3 Trocando o volume de referência 

Algumas vezes, surgirá a necessidade de trocar o volume de referência, para satisfazer a uma necessidade de projeto. Para que isso possa ser feito, deverá existir um mecanismo que realize uma operação de troca da semente, como definido a seguir:

TS (NS) → Operação para troca da semente

Onde:

NS = Nova semente

Vale mensionar a importância dessaoperação, que proporcionará uma maior flexibilidade durante os estágios do processo projetivo, visto que até aqui, ao ser aplicada uma operação de transformação, esta era realizada sobre o ultimo volume criado. Assim, antes não era possível aplicar uma operação transformadora sobre um volume gerado em outro estágio do projeto.

 Alterando a textura e a cor das faces de um volume 

5.4 Alterando a textura e a cor das faces de um volume 

Tabela 5.1 - Códigos de texturas para preenchimento (pintura) das faces dos volumes.

Tabela 5.2 - Códigos de cores.

Quando definiu-se a operação VP (Volume Padrão), criou-se dois parâmetros que estabeleciam uma textura e uma cor para o preenchimento das faces dos volumes, de forma a permitir uma aparência mais realista de um projeto. Assim, seria conveniente criar um mecanismo para alterar a textura e a cor dos volumes. Estes mecanismos serão definidos a seguir:

AT (NV, NT, NC) → Mecanismo que altera a textura e a cor de um volume já criado

Onde:

NV = Nome do volume que sofrerá a alteração

NT = Código da nova textura para preenchimento das faces do volume (ver Tabela 5.1)

NC = Código da nova cor (ver Tabela 5.2)

 Eliminação de um volume 

5.5 Eliminação de um volume 

Uma operação bastante útil para o processo de projeto, é aquela que permite eliminar um volume já criado, para possibilitar a aplicação de uma necessidade de projeto específica, tal como, criar um espaço vazio entre os volumes (TURKIENICZ, 1990). Além disso, esta operação de transformação de eliminação, permite corrigir uma operação executada de forma indesejável, pois, em muitas ocasiões durante os estágios de projeto, haverá a necessidade de modificar algumas partes, para melhorar o seu aspecto estético, ou mesmo para permitir a inclusão de um novo volume em uma posição específica, para satisfazer a uma determinada necessidade funcional do projeto.

Assim, a operação de transformação de eliminação e pode ser definida: 

e <- EV (NV) : Mecanismo para Eliminação de um volume

Onde:
NV = Nome do volume a ser eliminado

 Deformação de um volume existente

5.6 Deformação de um volume existente 

Após gerar um volume (lembrar que todo volume é gerado na forma de um paralelepípedo que possui as dimensões do volume padrão), deve ser possível alterar a sua forma para atender a uma necessidade de projeto. Assim, torna-se possível gerar outros tipos de figuras geométricas tridimensionais, através de uma deformação aplicada sobre o paralelepípedo existente. Esta operação alteradora funciona pelo deslocamento de algumas arestas específicas, escolhidas convenientemente de maneira a proporcionar o modelamento da figura geométrica na forma desejada. A Figura 5.5 mostra um exemplo ilustrativo dos conceitos até aqui estabelecidos. Note-se na Figura 5.5 que, por meio de uma deformação, torna-se possível obter arestas inclinadas em relação aos eixos do sistema de coordenadas.

A seguir será formalmente definida a operação alteradora de deformação D de um volume já existente no universo de trabalho. 

D <- DV (NV, CA, DX, DY, DZ) : Mecanismo para deformar um volume já existente

Onde:

NV = Nome do volume a ser deformado

CA = Código da aresta a ser deslocada (ver Figura 5.6)

DX = Valor do deslocamento no eixo X

DY = Valor do deslocamento no eixo Y

DZ = Valor do deslocamento no eixo Z

Vale salientar, ainda, que esta operação de transformação de alteração permite, entre outras coisas, a criação de elementos de projeto especiais ( com arestas não paralelas aos eixos do sistema de coordenadas), tais como: telhados, rampas e outros que podem ser construídos pela combinação de dois ou mais elementos primários. O Exemplo 5.2 ilustra uma utilização da operação D na criação de uma árvore.

Exemplo 5.3 → Gerar uma árvore, utilizando um mecanismo de deformação D. O resultado pode ser observado no ANEXO 1 no final deste trabalho.

Passo 1 - VP (75, 5, 75, 10, 3)

Passo 2 - VI ( 'A1')→ E1

Passo 3 - D <- DV ( 'A1',3, 0, 100, 0)
E1 * D  → E2

Passo 4 - D <- DV ( 'A1',4, 0, 100, 0)
E2 * D  → E3

Passo 5 - t <- V ( 'A2', 2)
E3 * t  → E4

Passo 6 - D <- DV ( 'A2',1, 0, 100, 0)
E4 * D  → E5

Passo 7 - D <- DV ( 'A2',4, 0, 100, 0)
E5 * D  → E6

Passo 8 - t <- V ( 'A3', 10)
E6 * t  → E7

Passo 9 - D <- DV ( 'A3',1, 0, 100, 0)
E7 * D  → E8

Passo 10 - D <- DV ( 'A3',2, 0, 100, 0)
E8 * D  → E9

Passo 11 - t <- V ( 'A4', 6)
E9 * t  → E10

Passo 12 - D <- DV ( 'A4',2, 0, 100, 0)
E10 * D  → E11

Passo 13 - D <- DV ( 'A4',3, 0, 100, 0)
E11 * D  → E12

Passo 14 - VP (20, 200, 20, 7, 7)

Passo 15 - t <- V ( 'T', 22)
E12 * t  → E13

Passo 16 - d <- Dx ( 'T', 10)
E13 * d  → E14

Passo 17 - d <- Dz ( 'T', -10)
E14 * d  → E15

Rotação de um volume

5.7 Rotação de um volume

Em algumas ocasiões, durante as etapas do processo produtivo, surge a necessidade de alterar a posição de um volume sem modificar as suas dimensões, mantendo-se assim, o seu aspecto geométrico. Isto pode ser feito através de uma operação alteradora que permita rotacionar o volume em torno de seu próprio eixo. Assim, torna-se possível obter diferentes alternativas de visualização para um mesmo projeto, por meio de uma simples rotação de uma ou mais partes, como acontece na utilização do "LEGO" de madeira de Turkienicz (TURKIENICZ, 1990). A Figura 5.7 mostra um exemplo de um projeto arquitetônico, composto por dois elementos (A e B). Note-se que são ilustradas duas alternativas distintas de projeto, sendo que o aspecto visual dessas alternativas se apresenta completamente modificado com a simples rotação do elemento A.

 A alteradora de rotação x  pode ser formalmente representada:

x <- RV (NV, AR, ER) : Mecanismo para rotacionar um volume em torno de seu próprio eixo

Onde:

NV = Nome dos volumes a serem individualizados

AR = Ângulo de rotação (em graus)

ER = Eixo de rotação (X, Y ou Z)

 Individualizando volumes de mesmo nome para permitir alterações somente em alguns deles

5.8 Individualizando volumes de mesmo nome para permitir alterações somente em alguns deles

Ao ser observada a Figura 5.8, pode-se concluir que um volume inicial ('V') foi criado e, a seguir, mais três volumes foram gerados pela aplicação de três geminações positivas (ambos os volumes com o mesmo nome, igual ao nome do volume inicial = 'V').

Pode ocorrer que após gerar os volumes, surja uma necessidade de alteração em apenas um deles. Nesse caso, se não houver um mecanismo que permita individualizar os volumes gerados, de mesmo nome, uma operação de alteração aplicada ao volume 'V' provocará a tal alteração em todos os quatro volumes gerados.

Assim, pode-se definir o mecanismo que permitirá individualizar volumes:

IV (NV) → Mecanismo para individualização de volumes

Onde:

NV = Nome dos volumes a serem individualizados

 A operação IV, definida acima, provocará uma alteração no nome de cada um dos volumes ( cujos nomes sejam iguais a NV), de forma a permitir o manuseio de cada um deles separadamente. Para tal, deverá ocorrer uma pesquisa relativa aos nomes dos volumes gerados até o momento, de forma a verificar quais os volumes que devem ser individualizados. Assim, ao encontrar um volume com nome igual a NV, o sistema deverá provocar uma alteração do nome conforme mostrado a seguir:

NV → #n

Onde:
# = Símbolo usado para identificar um volume individualizado.
n = Número inteiro atribuído de acordo com a sequência da pesquisa.

Exemplo: V → #1, #2, #3, #4, ...

A Figura 5.9 ilustra como seria executada uma alteração no segundo volume do exemplo da Figura 5.8.

Da mesma forma, após a execução das alterações que se fizerem necessárias, deve haver um mecanismo que permita o retorno do nome dos volumes à condição inicial, se isso for conveniente para o desenvolvimento das etapas seguintes do processo de projeto.

RN → Mecanismo para recuperar o nome original dos volumes individualizados

Assim, para o exemplo da Figura 5.8, após a execução da operação RN, todos os volumes voltarão a ter o nome 'V', permitindo dessa forma, a aplicação de um mesmo tratamento operacional a todos os quatro volumes simultaneamente.

 Alterando o nome de um volume 

5.9 Alterando o nome de um volume 

Um mecanismo simples, mas de grande utilidade na prática, deve ser definido para permitir alterar o nome de um volume já existente no universo de trabalho. A utilização do mecanismo que será definido formalmente nesta seção, permitirá modificar um nome de volume para outro que seja mais conveniente para a sequência dos estágios do processo projetivo. Além disso, permitirá agrupar objetos criados individualmente, de forma a proporcionar a aplicação de um mesmo tratamento alterador a todos simultaneamente, como se fossem apenas um (o processo inverso constituí-se na individualização).

AN (NA, NN) → Mecanismo para alterar o nome de um volume já existente no universo.

Onde:

NA = Nome atual

NN = Novo nome

Como observação, vale mensionar que, caso exista mais de um volume com nome igual a NA, todos sofrerão a alteração AN.

Tabela 5.3 - Resumo dos mecanismos e símbolos do capítulo

Acoplamento de universos

6. ACOPLAMENTO DE UNIVERSOS 

A geração de volumes, utilizando-se os mecanismos até aqui definidos, pode se tornar um processo bastante lento, visto que muitos estágios podem ser necessários para realizar as operações necessárias para se alcançar um resultado desejado. Como exemplo disso, pode-se citar o Exemplo 5.3, apresentado no capítulo anterior. Observe-se que nesse exemplo, foram necessários 17 passos para se gerar o elemento árvore. É lógico que quanto maior o número de passos para se atingir o resultado final de um projeto, mais lento torna-se o processo gerativo, o que pode se constituir numa grande barreira para a concepção de projetos utilizando-se um processo computacional.

Deve-se, portanto, criar uma forma para agilizar o processo, utilizando mecanismos que permitam a geração de volumes de maneira rápida, i. é, reduzindo-se o número de estágios necessários para a concepção de um projeto. Uma forma de obter uma redução significativa, seria o aproveitamento de volumes já criados e que pode ser observado mais uma vez no Exemplo 5.3. Observe-se que : 

 → para o Exemplo 5.3:

 passos  2,3,4 @ passos 5, 6, 7 @  passos 8, 9, 10 @  passos 11, 12, 13 

Assim, se existisse um mecanismo para aproveitamento dos volumes gerados pelos passos 2, 3 e 4, seria obtida uma economia de 9 passos, o que se constitui numa redução significativa, visto que o número de passos necessários para atingir o final do processo de projeto seria reduzido de 17 para 8 passos, i. é seria obtida uma redução na ordem de 53% (para o Exemplo 5.3). Note-se, que dependendo do projeto, uma economia ainda maior poderia ser alcançada (caso dos projetos que seguem um estilo pré-definido, com muitos elementos repetidos).

A seguir, serão apresentadas algumas regras de fundamental importância para a definição do mecanismo em questão:

Regra 6.1 - Deve haver um meio de "salvar" um conjunto de volumes em um meio magnético, para posterior utilização.

Regra 6.2 - Deve haver um mecanismo que permita "chamar" um conjunto de volumes previamente armazenados em um meio magnético, posicionando-se adequadamente no universo de trabalho.

Regra 6.3 - O posicionamento dos volumes deve seguir as regras estabelecidas para as operações de acoplamento de volumes.  

Para ilustrar a Regra 6.1, considere-se o Exemplo 5.3. Observe-se que é possível gerar uma parte da árvore individualmente e armazená-la em um arquivo de disco, i. é, os passos 1, 2, 3 e 4 podem ser aplicados inicialmente. Feito isso, o volume gerado é "salvo" para posterior utilização. Observe-se que o volume foi armazenado como um universo individualizado.

Utlizando-se um mecanismo que use a Regra 6.2, pode-se "chamar" a cópia fiel do volume que foi armazenada anteriormente como um universo, e acoplá-la ao volume existente no universo de trabalho, de acordo com as regras de acoplamento de volumes, i. é, geminando, justapondo e superpondo, de forma a obter a composição final do projeto. Para o caso do Exemplo 5.3, serão necessárias, na devida ordem: uma geminação positiva (mais uma operação de rotação de 90° em torno do eixo Y), uma justaposição positiva (seguida de uma rotação de 180° em torno do eixo Y) e uma geminação negativa (seguida de uma operação de rotação de 270° em torno do eixo Y), para completar o projeto da parte superior da árvore (Regra 6.3). Os passos 14 a 17 devem ser realizados a seguir. Note-se, que foram necessários mais de 3 passos para realizar as operações de rotação. Mesmo assim, obteve-se uma significativa redução no número de passos durante o processo, de 17 para 11, i. é, obteve-se uma redução de 35%.

A seguir, será apresentada a definição do mecanismo para acoplamento de universos q:

q <- AU (NU, NV, TA) : Mecanismo para acoplamento de universos

Onde:

NU = Nome do universo a ser acoplado

NV = Nome dos volumes do universo a ser acoplado, dentro do univerdo de trabalho atual

TA = Tipo de acoplamento a ser utilizado ( ver Tabela 6.1)

Note-se, que o mecanismo q poderia ser utilizado para gerar bibliotecas de universos que poderiam ser re-utilizadas em deferentes projetos. Assim, o elemento ilustrativo árvore, poderia ser gerado e armazenado em um meio magnético. Dessa forma, toda vez que o projetista necessitasse inserir um elemento árvore em um projeto, seria suficiente uma simples chamada ao universo existente nos arquivos magnéticos, aliada ao parâmetro de definição do tipo de acoplamento a ser executado. Além disso, outros elementos poderiam ser gerados e armazenados como parte integrante de uma biblioteca de elementos de projeto.

A seguir, o Exemplo 6.1 ilustra uma utilização prática dos conceitos apresentados neste capítulo.

Exemplo 6.1 → Gerar o edificio e a janela esquematizados a seguir e armazená-los em um meio magnético. A seguir, construir o projeto final do edifício, inserindo 2 elementos janela por andar.

Ver Esquema do projeto 6.1:

→ Geração do Edifício:

Passo 1 - VP (300, 800, 1000, 11, 7)

Passo 2 - VI ( 'A')

Passo 3 - VR ( 'A', 1, 2)

Passo 4 -ACx ( 'A', 100)

Passo 5 - IV ( 'A' )

Passo 6 - VP (200, 750, 800, 2, 5)

Passo 7 - TS ('#1')

Passo 8 - VR ( 'B', 2, 1)

Passo 9 - TS ('#2') 

Passo 10 - VR ( 'B', 2, 1)

Passo 11 - Dz ( 'B', 100)

Passo 12 - RN

Passo 13 - Salvar universo com nome 'EDIF'

→ Geração da janela:

Passo 1 - VP (200, 5, 2, 7, 16)

Passo 2 - VI ( 'J1')

Passo 3 - VR ( 'J1', 17, 2)

Passo 4 - IV ( 'J1')

Passo 5 - Dy ( '#3', 105)

Passo 6 - Dy ( '#2', 80)

Passo 7 - VP (5, 80, 2, 7, 16)

Passo 8 - TS ('#1')

Passo 9 - VR ( 'J2', 17, 1)

Passo 10 -VP (190, 80, 2, 1, 2)

Passo 11 -VR ( 'V', 1, 1)

Passo 12 - VP (5, 80, 2, 7, 16)

Passo 13 - VR ( 'J2', 1, 1)

Passo 14 - TS ('#2')

Passo 15 - VP (5, 25, 2, 7, 16)

Passo 16 - VR ( 'J2', 17, 1)

Passo 17 - VP (94, 25, 2, 1, 2)

Passo 18 - VR ( 'V', 1, 1)

Passo 19 - VP (2, 25, 2, 1, 2)

Passo 20 - VR ( 'J3', 1, 1)

Passo 21 - VP (94, 25, 2, 1, 2)

Passo 22 - VR ( 'V', 1, 1)

Passo 23 - VP (5, 25, 2, 7, 16)

Passo 24 - VR ( 'J2', 1, 1)

Passo 25 - RN

Passo 26 - Salvar universo com nome 'JANELA'

→ Janelas (1):

Passo 1 - Chamar universo 'JANELA'

Passo 2 - AU ( 'JANELA', 'J3', 5)

Passo 3 - AU ( 'JANELA', 'J1', 6)

Passo 4 - AN ( 'J1', 'J2' )

Passo 5 - AN ( 'V', 'J2' )

Passo 6 - AN ( 'J3', 'J2' )

Passo 7 - Dy ( 'J3', 130)

Passo 8 - Dy ( 'J1', -130)

Passo 9 - Salvar universo com nome 'JAN'

→ Janelas (2):

Passo 1 - AU ( 'JAN', 'JAN', 1)

Passo 2 - Dx ( 'JAN', 100)

Passo 3 - AN ( 'J1', 'JAN' )

Passo 4 - AN ( 'J2', 'JAN' )

Passo 5 - AN ( 'J3', 'JAN' )

Passo 6 - Salvar universo com nome 'JAN'

→ Projeto final:

Passo 1 - Chamar universo 'EDIF'

Passo 2 -  AU ( 'JAN', 'JAN', 4)

Passo 3 - Dx ( 'JAN', 100)

Passo 4 - Dy ( 'JAN', 90)

Passo 5 - Dz ( 'JAN', 100)

Os resultados deste exemplo podem ser observados no ANEXO 2 deste trabalho. 

Ver Tabela 6.2

Utilização de regras de geração para agilizar os estágios do processo projetivo 

7. UTILIZAÇÃO DE REGRAS DE GERAÇÃO PARA AGILIZAR OS ESTÁGIOS DO PROCESSO PROJETIVO 

Um projeto pode apresentar muitas representações ou descrições diferentes na passagem do desenvolvimento conceitual para a realização formal, análise e produção. Assim, no desenvolvimento de representações geométricas e propriedades físicas para uso em análise, o fato dessas representações se referirem a todas as classes de projeto não tem sido bem explorado. Portanto, por exemplo, no desenvolvimento de modelos sólidos, a ênfase tem sido relativa à criação de uma descrição detalhada de um projeto simples, mais do que prover ferramentas para a exploração de classes de possíveis projetos (ROONEY, 1987). Além disso, um elemento de projeto pode corresponder a uma variedade de possíveis alternativas na sequência de descrição, visto que os diferentes projetos são descritos pelas diferenças de suas características espaciais, geométricas e funcionais em suas possíveis partes.

Ao projetar-se alguma coisa, existe um fator de fundamental importância para o processo projetivo. A idéia de composição é central para a concepção de novos projetos. Além disso, a geração de volumes em um projeto apresenta duas áreas de concentração (ROONEY, 1987):

 Definição de um vocabulário de elementos, i. é, coleções relativamente simples de características formais, como por exemplo: vigas de edifício, rodas de automóvel ou as poltronas de um avião comercial.

Condições ou restrições de como esses elementos podem ser colocados juntos ou compostos. As restrições consistem numa tentativa de definir tipos de composições dos elementos que são permissíveis.

Neste capítulo, será apresentada a definição de vocabulário de elementos (TURKIENICZ, 1990), (MAKKUNI, 1987), gerado a partir da aplicação das regras de acoplamento de volumes e dos mecanismos alteradores.

 Geração de um vocabulário de elementos 

7.1 Geração de um vocabulário de elementos 

Inicialmente, será gerado um novo mecanismo para agilizar o processo de projeto, estabelecendo um conjunto de regras de geração de volumes, e definindo uma sequência de operações cuja execução possa ser simultânea, i. é, estabelecida a sequência, o processo ocorre de forma automática, sem a interferência do operador. Note-se, que esta capacidade de automação permite uma grande rapidez na construção de volumes, visto que com apenas um comando de ação, vários estágios de projeto podem ser executados para alcançar um objetivo pré-definido.

Nos capítulos anteriores, a geração de um projeto era realizada por meio da aplicação de regras de acoplamento de volumes a partir de um volume inicial, cujas dimensões e texturas eram definidas pelo volume padão. Além disso, era possível a execução de alterações de maneira conveniente, de forma a possibilitar a obtenção de uma exigência de projeto. Note-se, que eram necessários vários estágios para o processo de projeto atingir o resultado final.

O objetivo deste capítulo é estabelecer um mecanismo que permita automatizar a geração de volumes, de acordo com determinadas regras de ações de projeto. Dessa forma, será preciso estabelecer inicialmente uma linguagem de ações (MAKKUNI, 1987), que permita uma certa interação com o ambiente computacional e que, além disso, proporcione uma forma de tornar o processo visível. Assim, o projetista, de posse de um editor de  vocabulário (MAKKUNI, 1987), poderá estabelecer a sequência de execução de ações de projeto. Essa sequência, deve então, ser armazenada em um arquivo de ações, para posterior utilização pelo projetista que, de posse de um cardápio de elementos (TURKIENICZ, 1990), (MAKKUNI, 1987), poderá escolher uma das opções disponíveis (essas opções deverão ser apresentadas sob a forma de ícones, cuja finalidade específica será facilitar a tarefa de escolha).

 A linguagem de ações 

7.1.1 A linguagem de ações 

A linguagem de ações pode ser vista como uma parte integral da experiência de projeto, da representação do processo e da eventual formação e preservação de um projeto. Assim, o projetista, utilizando-se da linguagem de ações pode agir e refletir sobre o processo e até mesmo compartilhar esse processo com outros profissionais. Uma definição apropriada para a linguagem de ações é apresentada a seguir:

Linguagem de Ações - É uma coleção de ações definidas por uma operação de entrada que o editor de vocabulário reconhece como uma intenção de projeto para criar e manipular elementos do vocabulário (MAKKUNI, 1987).

Note-se que o mecanismo costrutor de um estágio de um elemento do vocabulário é um procedimento pramétrico, onde os argumentos representam as propriedades de projeto, i. é, propriedades de dimensionamento e proporcionamento de um elemento do vocabulário que o projetista precisa manipular. Assim, a linguagem de ações deve intervir entre as atribuições desses argumentos de projeto  e a construção de um estágio  (MAKKUNI, 1987).

Os comandos da linguagem de ações podem ser definidos em três tipos principais:

Comandos para geração de volumes (vistos nos capítulos anteriores)

Comandos auxiliares da linguagem (serão vistos a partir da seção 7.2 deste capítulo e no capítulo 8)

Comandos para geração de relações funcionais (serão vistos no capítulo 9)

O editor de vocabulário 

7.1.2 O editor de vocabulário 

O editor de vocabulário deverá, além de especificar a sequência de ações a serem utilizadas, definir um ícone para o elemento do vocabulário a ser gerado pelas ações, i. é, uma figura esquemática, que permita ao projetista identificar visualmente o elemento.

A concepção do editor pode ser realizada de duas formas distinatas:

Utilizando-se um procedimento escrito: Constituí-se num meio notacional que registra computacionamente, na forma de um texto, a sequência das ações de projeto a serem executadas para gerar um elemento do vocabulário.

Utilizando-se um procedimento gráfico interativo: Constituí-se na utilização de um meio computacional interativo que permita ao projetista visualizar os vários estágios de projeto.

No caso da utilização de um procedimento escrito, o usuário deverá digitar a sequência de ações na forma que foi apresentada nos capitulos anteriores, i. é, utilizando os formalizmos notacionais para as operações de acoplamento e de alteração, como exemplificado a seguir:

VP (100, 100, 100, 2, 1)

VI ('V1')

V ('V2', 1)

V ('V3', 5)

...

A seguir, um interpretador deverá ler a sequência de comandos e executá-la de forma automática.

 O editor de ícones

7.1.2.1 O editor de ícones

Note-se, que a geração do ícone deverá ser feita com auxílio de um Editor de Ícones, i. é, um editor de figuras bidimensionais, que após a sua geração, serão incorporadas ao elemento de projeto correspondente e que foi gerado pelo editor de vocabulário. Assim, toda vez que o projetista solicitar o cardápio de elementos do vocabulário (TURKIENICZ, 1990), (MAKKUNI, 1987), os ícones correspondentes serão apresentados em uma janela especial, de forma a facilitar a escolha do elemento a ser gerado.

O editor de ícones será constituído por uma malha padrão de posicionamento de pixels (pontos gráficos da tela ou de outro dispositivo de saída gráfica), que o projetista do ícone deverá preencher para obter o desenho esquemático do elemento do vocabulário que foi projetado. A Figura 7.1 ilustra a malha padrão (uma matriz bidimensional de 25 x 15 pixels) e um exemplo de ícone para o elemento janela, cuja sequência de geração foi apresentada no Exemplo 6.1 no capítulo anterior.

O projetista do elemento do vocabulário, além de criar um ícone para representar o objeto, deverá definir uma tecla de função (F1, F2, F3, ..., shift-F1, shift-F2, shift-F3,...), que ao ser ativada, provocará a execução automática do elemento selecionado. Os ícones serão gerados utilizando-se um programa especial (EDICON.EXE), utilitário do sistema principal (SMOF.EXE). O utilitário de edição terá funções específicas para acender e apagar os pixels da malha padrão. Após a definição do desenho do ícone, o usuário deverá gravar o ícone com o mesmo nome do arquivo de ações que o ativará (surgirá uma pergunta para esta tarefa).

Exemplo: 

JANELA. ICO <- arquivo do ícone

JANELA. REG <- arquivo de ações

Utilização de um procedimento gráfico-interativo para acompanhar o processo de edição 

7.1.2.2 Utilização de um procedimento gráfico-interativo para acompanhar o processo de edição 

O simples registro da sequência de ações não se constitui num meio eficiente para geração de elementos de vocabulário pois, se o projetista não tiver um ambiente a partir da edição dos mecanismos para geração de volumes, acoplamentos e alterações somente poderão ser visualizados ao final do processo de concepção. Assim, surge a necessidade de acompanhar cada uma das etapas do processo, de forma a permitir correções ou modificações de acordo com as necessidades do projeto do elemento.

Assim, o projetista deverá dispor de um ambiente gráfico que permita visualizar cada uma das operações requisitadas, i. é, deverão existir janelas de exibição, tanto para a observação dos objetos tridimensionais, como para exibição de vistas, em projeções ortogonais, de forma a permitir operações de deslocamento de um ponto de observação dos objetos. O ambiente gráfico em questão, apropriadamente denominado Câmera Sintética, foi desenvolvido durante as disciplinas de Computação Gráfica do CPGCC, e convenientemente aprimorado para incorporar a utilização dos mecanismos desenvolvidos neste documento, constituindo-se assim numa espécie de "laborátorio de pesquisas", onde os conceitos e idéias apresentados podem ser testados.

Note-se, ainda, que ao gerar um novo volume ou ao aplicar uma operação de transformação alteradora, a expressão sintática deverá ser registrada automaticamente no arquivo de edição. Da mesma forma, se um volume for eliminado, a correspondente expressão sintática que gerou o volume deverá ser eliminada, levando-se em consideração as consequências desta operação sobre a geração dos demais elementos.

Convém salientar, que o rpojetista poderá utilizar as duas opções ao mesmo tempo, o que dará maior flexibilidade ao sistema, i. é, a concepção do elemento do vocabulário poderá ser realizada paralelamente utilizando-se tanto o editor de vocabulário como o ambiente gráfico-interativo do sistema.

Incorporando um mecanismo para entrada de parâmetros 

7.2 Incorporando um mecanismo para entrada de parâmetros 

Em algumas situações, o usuário de um vocabulário de elementos pode necessitar de um mecanismo que permita a entrada de um ou mais parâmetros das operações de acoplamento e de alteração de volumes, a serem utilizados dentro da sequência de ações estabelecida no editor de vocabulário. Assim, por exemplo, o projetista pode querer gerar uma matriz bidimensional de volumes, de forma que o sistema solicite a entrada da ordem da matriz de volumes, ao ser pressionada a tecla de função que aciona a execução das ações estabelecidas no arquivo de ações do elemento. Note-se, que este simples mecanismo pode proporcionar uma grande flexibilidade ao sistema, que poderá gerar resultados diferentes a partir de uma mesma sequência de ações, visto que somente alguns parâmetros serão modificados. No caso da matriz bidimensional de volumes, o parâmetro a ser fornecido pelo projetista, será relativo ao mecanismo de repetição, i. é, o parâmetro NR das operações VR.

A entrada de um parâmetro será especificada pelo seguinte comando:

?M, IP: Mecanismo para entrada de um parâmetro a ser utilizado por uma sequência de ações, na geração de um elemento do vocabulário

Onde:

? = Símbolo utilizado para indentificar a entrada de um parâmetro

M = Mensagem a ser exibida na janela de mensagens do sistema

IP = Identificação do parâmetro

Assim, no caso de entrada de um parâmetro para identificar a ordem de uma matriz bidimensional de volumes o comando seria:

? 'Qual a ordem da matriz de volumes', NR

Assim, para o exemplo dado, toda vez que o interpretador encontrar um comando que possua o parâmetro NR, este assumirá o valor fornecido pelo projetista. A seguir, será apresentado um exemplo completo de uma sequência de ações para geração de uma matriz bidimensional de volumes, de ordem (N x 3) (Figura 7.2):

? 'Nome dos volumes', NV

? 'Ordem X da matriz de volumes', NR

VI (NV)

VR (NV, 1, NR)

V (NV, 17)

VR (NV, 5, NR)

V (NV, 17)

VR (NV, 1, NR)

 Um mecanismo para operações aritméticas 

7.3 Um mecanismo para operações aritméticas 

O mecanismo que será apresentado nesta seção terá como função uma forma para alteração de um determinado parâmetro aplicando-se sobre este parâmetro uma das quatro operações aritméticas definidas a seguir.

Mecanismos para alterações nos parâmetros gramaticais por meio de operações aritméticas.

+(IP, VA) <− Soma

- (IP, VA) <− Subtração

* (IP, VA) <− Multiplicação

/ (IP, VA) <− Divisão

$ (IP)  <− Raiz Quadrada

Onde:

IP = Identificação do parâmetro

VA = Valor ou parâmetro a ser utilizado na operação aritmética

Este mecanismo é util quando, por exemplo, ao ser fornecido um parâmetro ao sitema, utilizando-se o mecanismo para entrada de um parâmetro (apresentado na seção anterior), se quer alterar o seu valor numérico para geração de um volume com características relativas ao valor anterior. O exemplo apresentado a seguir, ilustra o funcionamento do mecanismo em discussão.

Exemplo 7.1 → Gerar o módulo ilustrado abaixo de forma que a dimensão em X dos elementos identificados pela letra B seja o dobro da dimensão em X dos elementos identificados pela letra A.

Ver esquema da janela exemplo 7.1

Sequência de ações:

? 'Largura das laterais do modulo (A) =', Cx

VP (Cx, 250, 50, 2, 1)

VI ('A')

* (Cx,2)

VP (Cx, 50, 50, 2, 1)

V ('B', 2)

TS ('A')

V ('B', 1)

/ (Cx,2)

VP (Cx, 250, 50, 2, 1)

V ('A', 1)

Note-se, que o identificador IP deverá ser um dos parâmetros numéricos estabelecidos nos mecanismos que foram definidos até aqui, i. é:

NR <−−−−−−−−−−−−−−−−− Número de repetições

Cx, Cy, Cz <−−−−−−−−−−− Dimensão em X, Y e Z

Dx, Dy, Dz <−−−−−−−−−−− Deformação em X, Y e Z

NCx, NCy, NCz <−−−−−−−− Nova dimensão em X, Y e Z

D <−−−−−−−−−−−−−−−−−− Deslocamento

AR <−−−−−−−−−−−−−−−−− Ângulo de rotação

 Atribuíção 

7.4 Atribuíção 

O mecanismo de atribuíção  é de fundamental importância para o perfeito funcionamento da linguagem de ações, visto que permite a transmissão do valor de um parâmetro para outro, de forma a satisfazer uma exigência do projeto de uma sequência de ações. Este mecanismo será apresentado a seguir.

: = (IP1, IP2): Mecanismo de atribuíção

Onde:

IP1 = Identificação do parâmetro que receberá o valor envolvido na atribuíção

IP2 =Identificação do parâmetro fonte do valor de atribuíção 

Note-se, que será imprenscindível considerar uma adequada compatibilidade entre os tipos dos parâmetros IP1 e IP2 para que a operação seja corretamente executada. Assim, se o tipo do parâmetro IP1 for inteiro, caso o tipo do parãmetro IP2 for real, este último deverá ser obrigatoriamente convertido para real.

O Exemplo 7.2, apresentado a seguir, ilustra o funcionamento do mecanismo de atribuíção.

Exemplo 7.2 → Gerar o elemento modular esquematizado abaixo, utilizando o mecanismo de atribuíção.

Ver esquema de projeto exemplo 7.2

Sequência de ações:

? 'd =', Cx

VP (Cx, 250, 50, 2, 1)

VI ('A')

/ (Cx,2)

- (Cx,25)

: = (Cz, Cx)

VP (50, 250, Cz, 2, 1)

V ('B', 9)

TS ('A')

V ('B', 13)

: = (D, Cx)

Dx ('B', D)

Exibição de mensagens

7.5 Exibição de mensagens 

Ao ser executada uma sequência de ações, pode ser interessante exibir ao usuário final do sistema uma determinada mensagem, de forma a possibilitar a transmissão de informações relevantes para a continuidade do processo de projeto. Além disso, essas informações devem ser exibidas em uma janela de exibição específica para essa finalidade, e podem consistir de :

Resultados numéricos de operações executadas.
Exemplo:
'Área total = 120'

Instruções para tomada de decisões a partir dos resultados obtidos após a execução de uma sequência de ações.
Exemplo:
'A seguir, não será permitido GEMINAR!'

Informações de operações executadas.
Exemplo:
'Erro −−−−−−> Dimensão inferior a 500'

Assim, pode-se definir o mecanismo para exibição de mensagens, como a seguir:

MENSAGEM (M,IP): Mecanismo para exibição de mensagens

Onde:

MENSAGEM = Identificador do mecanismo

M = Mensagem a ser exibida na janela de mensagens do sistema (entre apóstrofos)

IP = Identificação do parâmetro de exibição (opcional)

Como observação, vale salientar, que no caso da existência do parâmetro IP, este deverá ser substutuído dois apóstrofos.

Exemplos:

→ Mensagem com parâmetro de exibição:

MENSAGEM ('DIMENSÃO EM X =', Cx)

→ Mensagem sem parâmetro de exibição:

MENSAGEM ('OPERAÇÃO INVÁLIDA', ' ')

 Variáveis auxiliares

7.6 Variáveis auxiliares

Como pode ser observado nas definições dos mecanismos anteriores, o uso de parâmetros dentro de um comando de ação deve obedecer às seguintes regras sintáticas:

REGRA 1 → Somente deverão ser utilizados os parâmetros específicos, definidos para o mecanismo em uso.

Exemplos:

VP ( Cx, Cy, Cz, T, C) <− Comando válido

VP ( Cx, D, Cy, Textura, C) <− Comando inválido

D: erro 1: parâmetro pertencente a outro mecanismo

Cy: erro 2: fora de ordem

Textura: erro 3: parâmetro inexistente 

REGRA 2 → Valores numéricos ou strings serão aceitos, desde que, seja respeitada a  devida compatibildade em relação ao tipo do parâmetro esperado.

Exemplos:

VP ( 250, Cy, 50, 5, 5, C) <− Comando válido

VP ( 250-100, Cy, 50, 5 , 100, 2.5) <− Comando inválido

250-100: erro 1: operações aritméticas dentro do comando não são permitidas (devem ser realizadas antes e o resultado atribuído ao parâmetro Cx)

100: erro 2: muito grande

2.5: erro 3: tipo real

Como em todo a linguagem de programação, a linguagem de ações deve oferecer ao usuário programador uma forma temporária para o armazenamento de valores inteiros, reais ou strings. Assim, com esse recurso computacional, o usuário programador pode realizar operações  sobre o valor de um determinado parãmetro, sem a necessidade de sua perda ou alteração. Por exemplo, se o usuário final (que não precisa conhecer o programa) do sistema fornecer o valor da dimensão X do volume padrão, i.é, Cx, o mesmo valor pode ser atribuído a uma variável temporária que poderia ser multiplicada por 2 e dividida pelo valor de outro parâmetro, para ser posteriormente atribuído ao valor do parâmetro de deslocamento D. Note-se, que nesse caso não houve a perda do valor de Cx, visto que ele foi transportado para a variável temporária e, portanto, continua existindo e pode ser naturalmente utilizado. Observe-se, ainda, que uma variável temporária pode ser utilizada para armazenar o valor de qualquer parâmetro, desde que seja respeitada a compatibilidade de tipos.

Note-se que serão necessários 3 tipos de variáveis temporárias, ou auxiliares, cuja definição será apresentada a seguir.

Variáveis Auxiliares:

I: array [1..n] do tipo inteiro 

R: array [1..n] do tipo real

S: array [1..n] do tipo string

Onde:

n = número máximo de variáveis

Vale salientar, ainda, que a partir de agora, as variáveis auxiliares do tipo inteiro e real, poderão ser utilizadas nas operações aritméticas, de atribuíção, entrada de parâmetros e exibição  de mensagens.

O exemplo a seguir ilustra a utilização de variáveis auxiliares:

Exemplo 7.3 → Gerar os blocos esquematizados.

Ver esquema de projeto exemplo 7.2

Sequência de ações:

? 'Dimensao X dos blocos laterais =', R[1]

? 'Dimensao Y do bloco central =', R[2]

: = (Cx, R[1])

: = (Cy, R[2])

* (Cx, 3)

* (Cy, 2)

VP (Cx, Cy, 200, 2, 3)

VI ('B_LATERAL')

V ('B_LATERAL', 1)

: = (NCx, R[1])

ACx ('B_LATERAL', NCx)

: = (Cx, R[1])

: = (Cy, R[2])

* (Cx, 2)

VP (Cx, Cy, 200, 2, 3)

V ('B_CENTRAL', 6)

 Observações e comentários

 7.7 Observações e comentários

Determinadas porções de uma sequência de ações devem merecer uma atenção especial por parte do usuário programador e devem, portanto, receber algum tipo de especificação sob a forma de uma sequência textual de comentário. Assim, torna-se possível especificar o uso de um determinado mecanismo, informando a sua finalidade específica dentro da sequência de ações. Note-se, que com a utilização desse recurso é possível obter uma sequência de ações mais clara sob o ponto de vista do programador, visto que a função de cada segmento da sequência fica adequadamente especificada.

O símbolo @ será utilizado para identificar uma linha de comentário, como especificado a seguir:

@ C: linha de comentário

Onde:

@ = Indentificador da linha de comentário

C = Texto do comentário

→ Exemplo:

@ ---------------------------

@ Geração do módulo A

@ ---------------------------

Ver Tabela 7.1

Mecanismo de controle 

8. MECANISMO DE CONTROLE 

A linguagem de ações, cujas definições de seus mecanismos aparecem nos capítulos anteriores, permite a geração de objetos em três dimensões de acordo com uma sequência pré-estabelecida de ações. Assim, a criação de volumes dá-se de forma natural, sem restrições ou condições especiais de projeto, i. é, não ocorrem desvios condicionais, pois ainda não foi descrito um mecanismo para controlar a sequência de ações.

A definição de regras de geração (TURKIENICZ, 1990) e transformação de objetos tridimensionais pode ser realizada de forma a estabelecer diferentes sequências de ações, cuja utilização pode ou não ser ativada, mediante a utilização de obstáculos controladores, ou restrições (TURKIENICZ, 1990), como sugerido nas definições de shape grammars (FLEMMING, 1986). Esses mecanismos de controle devem ser aplicados de forma a permitir ou evitar o acesso a um ou mais segmentos para atingir um determinado objetivo de projeto. Assim, torna-se possível controlar estruturas de construção embutidas na linguagem de ações, permitindo a invocação automática de regras. Note-se que nesse caso, o processo de geração pode ser visto como uma pesquisa em uma estrutura do tipo árvore, cujos nodos constítuem soluções parciais de projetos, que podem ou não serem acessadas (GERO, 1985).

A aplicação de restrições (TURKIENICZ, 1990) à geração de volumes constituí outra abordagem para o mecanismo controlador. Nesse caso, por exemplo, somente determinados valores de parâmetro serão aceitos, de forma a atingir objetivos esperados na sequência de projeto. Assim,  rotações de determinados objetos poderiam ser previamente definidas em ângulos de 0°, 90°, 180° e 270°. O controle seria então aplicado de forma a evitar que o usuário tentasse rotacionar um objeto utilizando um ângulo diferente daqueles que foram anteriormente especificados.

A seguir, serão estabelecidas algumas regras importantes para formalizar a definição do mecanismo do controle:

Regra 8.1 - O mecanismo de controle deve exercer uma função de comparação entre dois parâmetros, sendo que, se o resultado da comparação for verdade, a sequência de ações que segue a instrução de controle deve ser executada.

Regra 8.2 - Deve haver um símbolo especial para indicar o fim de uma sequência de ações sob controle.

Regra 8.3 - Deve ser permitida a utilização de mais de uma comparação, sendo que, nesse caso, se o resultado de uma das comparações for falso, a sequência de ações que surge esta última instrução não deve ser executada.

Regra 8.4 - Deverá existir u operador específico para indicar cada uma das operações booleanas essenciais (igual, maior, menor e diferente).

A partir dos conceitos apresentados acima, será definido formalmente o mecanismo de controle x.

Mecanismo de Controle → x

OC1 (IP1', IP2' ') <− controle 1

OC2 (IP2', IP2' ') <− controle 2

.

.

OCn (IPn', IPn' ') <− controle n

AÇÃO 1

AÇÃO 2

.

.

AÇÃO m

!

Onde:

OC1...OCn = Operador de comparação (booleano)

= <− igual

> <− maior

< <− menor

# <− diferente

IP1'...IPn' = Identif. do primeiro parâmetro

IP1' '...IPn' ' = Identif. do segundo parâmetro

AÇÃO 1.. AÇÃO m = Sequência de ações sob controle

= Símbolo que indica o fim da Sequência de ações sob controle 

Note-se que o imterpretador da linguagem de ações, ao atingir o primeiro operador de comparação deverá verificar se o resultado da comparação é verdadeiro ou falso. Se for verdadeiro, então a próxima linha deverá ser executada. Se for falso, todas as ações que estiverem entre o controle que falhou e a marca de finalização da sequências de ações sob controle, deverão ser ignoradas pelo interpretador.

O Exemplo 8.1, apresentado a seguir, e convenientemente discutido, demonstra uma aplicação prática para o mecanismo x.

Exemplo 8.1 → Desenvolver uma sequência de ações para gerar os módulos de conexão A e B esquematizados abaixo, de forma que as conexões entre os módulos sejam realizados adequadamente de acordo com os três tipos de acoplamento permissíveis (geminação, justaposição e superposição).

Ver esquema exemplo 8.1

@ ===> Geracao do Modulo A

@ ===> Define CENTRO

VP (50, 50, 50, 2, 5)

@ ===> Define tipo de acoplamento

> (I[0], 0)

?'[1]G+ [2]G- [3]J+ [4]J- [5]S+ [6]S- ==>', I[1]

!

> (I[0], 0)

= (I[1], 1)

:= (RG, 1)

!

> (I[0], 0)

= (I[1], 2)

:= (RG, 5)

!

> (I[0], 0)

= (I[1], 3)

:= (RG, 9)

!

> (I[0], 0)

= (I[1], 4)

:= (RG, 13)

!

> (I[0], 0)

= (I[1], 5)

:= (RG, 17)

!

> (I[0], 0)

= (I[1], 6)

:= (RG, 21)

!

@ ===> Gera Centro

> (I[0], 0)

V ('CENTRO', RG)

!

> (I[0], 0)

VI ('CENTRO')

!

@ ===> Deslocamento em X+

@  ---------------------------

> (I[0], 0)

= (I[1], 1)

= (I[9], 1)

Dx ('CENTRO', 225)

!

> (I[0], 0)

= (I[1], 1)

= (I[9], 2)

Dx ('CENTRO', 225)

!

@ ===> Deslocamento em X-

@  ---------------------------

> (I[0], 0)

= (I[1], 2)

= (I[9], 1)

Dx ('CENTRO', -225)

!

> (I[0], 0)

= (I[1], 2)

= (I[9], 2)

Dx ('CENTRO', -450)

!

@ ===> Deslocamento em Z+

@  ---------------------------

> (I[0], 0)

= (I[1], 3)

= (I[9], 1)

Dz ('CENTRO', 225)

!

> (I[0], 0)

= (I[1], 3)

= (I[9], 2)

Dz ('CENTRO', 450)

!

@ ===> Deslocamento em Z-

@  ---------------------------

> (I[0], 0)

= (I[1], 4)

= (I[9], 1)

Dz ('CENTRO', -225)

!

> (I[0], 0)

= (I[1], 4)

= (I[9], 2)

Dz ('CENTRO', -225)

!

@ ===> Deslocamento em Y+

@  ---------------------------

> (I[0], 0)

= (I[1], 5)

= (I[9], 1)

Dy ('CENTRO', 450)

!

> (I[0], 0)

= (I[1], 5)

= (I[9], 2)

Dy ('CENTRO', 225)

!

@ ===> Deslocamento em Y-

@  ---------------------------

> (I[0], 0)

= (I[1], 6)

= (I[9], 1)

Dy ('CENTRO', -450)

!

> (I[0], 0)

= (I[1], 6)

= (I[9], 2)

Dy ('CENTRO', -225)

!

@ ===> Gera M5

VP (225, 50, 50, 2, 5)

TS ('CENTRO')

V ('M', 1)

@ ===> Gera M3

VP (50, 50, 225, 2, 5)

TS ('CENTRO')

V ('M', 13)

@ ===> Gera M1

VP (50, 225, 50, 2, 5)

TS ('CENTRO')

V ('M', 17)

@ ===> Gera M6

TS ('CENTRO')

V ('M', 21)

@ ===> Somente no CENTRO

AN (' CENTRO', 'C' )

TS ('C')

AN ('M', 'M1')

:= (I[9], 1)

+ (I[0], 1)

@ ===> Geracao do Modulo B

@ ===> Define CENTRO

VP (50, 50, 50, 2, 5)

@ ===> Define tipo de acoplamento

> (I[0], 0)

?'[1]G+ [2]G- [3]J+ [4]J- [5]S+ [6]S- ==>', I[1]

!

> (I[0], 0)

= (I[1], 1)

:= (RG, 1)

!

> (I[0], 0)

= (I[1], 2)

:= (RG, 5)

!

> (I[0], 0)

= (I[1], 3)

:= (RG, 9)

!

> (I[0], 0)

= (I[1], 4)

:= (RG, 13)

!

> (I[0], 0)

= (I[1], 5)

:= (RG, 17)

!

> (I[0], 0)

= (I[1], 6)

:= (RG, 21)

!

@ ===> Gera Centro

> (I[0], 0)

V ('CENTRO', RG)

!

> (I[0], 0)

VI ('CENTRO')

!

@ ===> Deslocamento em X+

@  ---------------------------

> (I[0], 0)

= (I[1], 1)

= (I[9], 1)

Dx ('CENTRO', 450)

!

> (I[0], 0)

= (I[1], 1)

= (I[9], 2)

Dx ('CENTRO', 450)

!

@ ===> Deslocamento em X-

@  ---------------------------

> (I[0], 0)

= (I[1], 2)

= (I[9], 1)

Dx ('CENTRO', -225)

!

> (I[0], 0)

= (I[1], 2)

= (I[9], 2)

Dx ('CENTRO', -450)

!

@ ===> Deslocamento em Z+

@  ---------------------------

> (I[0], 0)

= (I[1], 3)

= (I[9], 1)

Dz ('CENTRO', 225)

!

> (I[0], 0)

= (I[1], 3)

= (I[9], 2)

Dz ('CENTRO', 450)

!

@ ===> Deslocamento em Z-

@  ---------------------------

> (I[0], 0)

= (I[1], 4)

= (I[9], 1)

Dz ('CENTRO', -450)

!

> (I[0], 0)

= (I[1], 4)

= (I[9], 2)

Dz ('CENTRO', -450)

!

@ ===> Deslocamento em Y+

@  ---------------------------

> (I[0], 0)

= (I[1], 5)

= (I[9], 1)

Dy ('CENTRO', 225)

!

@ ===> Deslocamento em Y-

@  ---------------------------

> (I[0], 0)

= (I[1], 6)

= (I[9], 1)

Dy ('CENTRO', -225)

!

@ ===> Gera M5

VP (225, 50, 50, 2, 5)

TS ('CENTRO')

V ('M', 1)

@ ===> Gera M3

VP (50, 50, 225, 2, 5)

TS ('CENTRO')

V ('M', 13)

@ ===> Gera M2

VP (225, 50, 50, 2, 5)

TS ('CENTRO')

V ('M', 5)

@ ===> Gera M4

VP (50, 50, 225, 2, 5)

TS ('CENTRO')

V ('M', 9)

@ ===> Somente no CENTRO

AN (' CENTRO', 'C' )

TS ('C')

AN ('M', 'M2')

:= (I[9], 2)

+ (I[0], 1)

Observe-se, que a variável auxiliar I[0] foi utilizada como parâmetro especial para indicar se o próximo objeto a ser criado ( e sua sequência de ações correspondente) é o objeto inicial. Assim, se I[0] > 0, então o próximo objeto a ser criado não é o objeto  inicial e determinadas sequências de ações devem ser executadas. Outra variável auxiliar, I[9], também foi utilizada para indicar o tipo do último objeto que foi criado. Assim se I[9]=1, então, um objeto do tipo Módulo A foi gerado, e se I[9]=2, um objeto do tipo Módulo B foi o objeto anterior. Portanto, o valor atribuído a I[9] será utilizado como um fator de decisão que terá como função decidir qual sequência de ações deverá ser executada. Note-se, também, a importância do volume CENTRO, na geração dos módulos do exemplo, visto que ele é utilizado como um volume de referência para o perfeito funcionamento das operações de acoplamento. Assim, a primeira ação de geração volumétrica a ser executada é a criação e o devido deslocamento, de acordo com o tipo de acoplamento a ser executado (estabelecido pelo valor da variável auxiliar I[1]) do CENTRO do módulo e, a seguir, utilizando-se este volume como semente, os demais elementos do módulo são criados. Um exemplo ilustrativo pode ser visto no ANEXO 9 deste trabalho.

Ver Tabela 8.1

 Relações funcionais 

9. RELAÇÕES FUNCIONAIS 

A elaboração de um projeto pode ser vista como uma tarefa extremamente complexa, onde diversos aspectos devem ser considerados, dependendo da aplicação. Assim, por exemplo, não é suficiente considerar somente os aspectos gráficos ou geométricos dos elementos projetados. Outros fatores devem ser cuidadosamente considerados e analisados, incorporando assim, processos e estratégias, principalmente para permitir a tomada de certas decisões fundamentais para o projeto. Da mesma forma, devem existir mecanismos eficientes para permitir o armazenamento das características e dos requisitos do produto a ser desenvolvido. Assim, um sistema computacional de projeto, deve ser capaz de assimilar as exigências necessárias para se produzir o efeito desejado, relativas ao produto que se quer obter. Então, de posse dessas informações, reguladas pela incorporação de testes de compatibilidade, pode-se chegar ao resultado final com maior ou menor nível de sintonia com os efeitos desejados.

 Como definir a estrutura funcional de um projeto 

9.1 Como definir a estrutura funcional de um projeto 

Para que se possa construir corretamente a estrutura funcional de um projeto, deve-se, inicialmente, ativar uma sequência de procedimentos metódicos para o perfeito entendimento do processo projetivo.  

Então, como pode ser visto em (GRABOWSKI, 1989), um processo de projeto pode ser definido de acordo com as seguintes frases:

Elaborar os requisitos do projeto: Consiste em estabelecer a totalidade das funções do projeto, assim como, as restrições e condições iniciais que devem ser implementadas.

Definir a estrutura funcional: Consiste na decomposição das funções estabelecidas na fase anterior, em uma rede de sub-funções e funções primitivas.

Pesquisar Soluções: Implica na identificação apropriada de princípios (leis da física) para o cumprimento das funções.

Inserir os detalhes do projeto: Usa os diversos níveis funcionais para obter resultados mais ou menos detalhados.

Assim, um processo de engenharia de projeto pode ser utilizado para identificar as características funcionais para a especificação de um produto e sua manufatura. Então, torna-se possível a identificação de um conjunto de tipos básicos de conhecimento que podem ser gerados por atividades normalmente utilizadas em todos os tipos de engenharia de projeto (SMITHERS, 1989):

Descrição dos requisitos: Os requisitos são descritos ou modelados de modo formal ou informal e modificados de acordo com a elaboração das possibilidades de projeto, identificação de falhas e descoberta de inconsistências.

Decomposição: Os requisitos e suas respectivas ações são subdivididas em problemas de mais fácil gerenciamento.

Planejamento estratégico: As regras de objetivos intermediários e subproblemas são identificados, levando em consideração as características e dificuldades de projeto.

Detalhamento e parametrização: As partes de um projeto são trabalhadas em seus detalhes para estabelecer valores, parâmetros de projeto, custos, etc.

Síntese: Esquemas e soluções de projeto são gerados a partir de soluções parciais e subproblemas.

Simulação: Consiste na verificação da eficiência dos esquemas e mecanismos propostos.

Análise: Detalhes de projeto propostos, valores de parâmetros e outros aspectos são testados contra os requisitos e outros critérios.

Otimização: As interações e relacionamentos entre as subpartes de um projeto são otimizados em relação a critérios globais.

Documentação: Esclarecimentos sobre as decisões de projeto e decisões adotadas são preparadas e registradas.

Assim, ao final do processo de projeto,  é possível obter uma especificação completa do produto,  incluindo custo, manufatura, teste, documentação, instalação, manutenção, etc. Note-se, ainda, que o processo deve ocorrer de forma a permitir uma contínua exploração, avaliando-se as várias soluções possíveis, até que, finalmente, uma solução otimizada seja encontrada e, posteriormente, validada (SMITHERS, 1989).

 Criando classes de objetos de projeto 

9.2 Criando classes de objetos de projeto 

Inicialmente, consideram-se as seguintes regras:

Regra 9.1 - Os elementos de um projeto serão denominados objetos.

Regra 9.2 - Os objetos de um projeto serão agrupados em classes, i. é, ocorrências de objetos que possuem os mesmos atributos dentro do universo de projeto.

Regra 9.3 - Um objeto será constituído geometricamente por um ou mais volumes (acoplados de acordo com as regras e mecanismos definidos nos capítulos anteriores).

Para satisfazer à Regra 9.2, será estabelecida uma forma para gerar e armazenar as propriedades, ou atributos, de uma classe de objetos de projeto. Essa forma, de representação será utilizada pelo sistema principal de modelamento de objetos funcionais, que deverá possuir mecanismos para a criação de estruturas de dados. Aqueles mecanismos que foram definidos em capítulos anteriores deste trabalho serão incorporados posteriormente.

 Utilizando uma estrutura de dados relacional para representar os objetos de um projeto

9.2.1 Utilizando uma estrutura de dados relacional para representar os objetos de um projeto 

Um sistema relacional é um sistema em que os dados são vistos pelo usuário como tabelas e os operadores disponíveis para os usuários são operadores que permitem a geração de novas tabelas, a partir de outras já existentes (DATE, 1986). Além disso, ao ser definida uma estrutura de dados relacional, algumas terminologias formais devem ser definidas:

Domínio: É um conjunto de valores do qual são extraídos os valores reais de um determinado atributo.

Relações: Uma relação consiste de um conjunto fixo de atributos, sendo que cada atributo está associado a um determinado domínio (cabeçalho da relação), e de um conjunto de tuplas, i. é, conjuntos de pares valor-atributo. Assim, para cada atributo existe um valor pertencente a um determinado domínio.

Tuplas: Correspondem às linhas das relações.

Atributos: Correspondem às colunas das relações.

Chave Primária: É um identificador especial, i. é, um atrubuto ( ou uma combinação de atributos), que é utilizado para individualizar as tuplas de uma relação.

A Figura 9.1 mostra um exemplo de uma relação de materiais em projeto de instalação sanitária, onde pode ser observada a existência de três atributos (Nome, Unidade e Quantidade), além de uma chave primária (Material) que serve de parâmetro de individualização para acesso às informações contidas na relação. Observe-se também, os domínios de cada atributo que, neste exemplo, podem ser de dois tipos: string (sequência de caracteres alfa-numéricos e inteiro (valor numérico sem ponto decimal).

Figura 9.1 

Para complementar esta seção, vamos citar as principais propriedades das relações (DATE, 1986), que se constituem em algumas das razões pelas quais este tipo de estrutura de dados foi escolhido para representar objetos neste trabalho.

Não há tuplas duplicadas: Esta propriedade se fundamenta no fato de que o corpo de relação pode ser visto matematicamente  como um conjunto de tuplas e, por definição, não possuem elementos duplicados.

Tuplas não são ordenadas: Aqui também, considera-se que o corpo de uma relação é um conjunto matemático, e conjuntos não são ordenados. Portanto, a ordem em que as tuplas aparecem na relação não é importante.

Atributos não são ordenados: Mais uma vez, como relações são conjuntos de atributos, a ordem em que os atributos aparecem não é relevante. Assim, os atributos devem ser referenciados pelo nome e não pela posição que ocupam dentro da relação.

Os valores dos atributos são atômicos: Para cada posição linha/coluna de uma relação existe somente um valor, nunca um conjunto de valores, i. é, relações não apresentam grupos repetidos, sendo portanto normalizadas.

Note-se, ainda, que todos os entes (objetos) que existem na natureza são únicos, não existindo outro elemento exatamente igual ( até mesmo pelo fato de que "dois corpos não podem ocupar o mesmo lugar no tempo e no espaço"). Portanto, visto que as relações não apresentam elementos duplicados, este tipo de representação é castante adequado para representar os objetos de um projeto.

Vale mensionar, ainda, que é comum a utilização de estruturas de dados relacionais em sistemas gráficos interativos (PATNAIK, 1982) (SPOONER 1984). Assim, os conceitos que serão estabelecidos a seguir serão fundamentados em estruturas de dados relacionais, e deverão obedecer às definições estabelecidas nesta seção.

Geração de classes de objetos utilizando relações

 9.2.2 Geração de classes de objetos utilizando relações

A partir de agora, será utilizado um exemplo que servirá para ilustrar os conceitos e definições que serão desenvolvidos a seguir. O referido exemplo, com aplicação em cálculo estrutural de concreto armado (área de engenharia civil) foi escolhido devido ao fato de que representa uma série de propriedades e situações que se ajustão aos propósitos deste trabalho.

Inicialmente, considera-se a elaboração de um projeto de concreto armado para construção de um edifício, onde aparecem os seguintes elementos básicos (objetos) (ROCHA 1984).

Lajes: São placas de concreto armado, cuja função é resistir às cargas verticais transmitidas a um planos horizontal (piso dos edifícios).

Vigas: São peças de concreto armado, de altura superior a das lajes, que são dispostas em duas direções perpendiculares, servindo de apoio às lajes.

Pilares: São estruturas verticais que servem para transmitir as cargas de cada pavimento ( cuja estrutura é formada por lajes repousando em um conjunto de viags) às fundações. Note-se, ainda, que os pilares recebem as cargas dos pavimentos pelas vigas que se apoiam nestes elementos verticais.

Fundações: São estruturas destinadas a transmitir ao solo as cargas provenientes dos diversos pavimentos, servindo, portanto, de apoio aos pilares.

A seguir, a Figura 9.2 mostra um desenho esquemático dos elementos que foram definidos.

Os elementos estruturais definidos acima, podem ser vistos como classes de objetos, i. é, relações que descrevem a estrutura e comportamento de suas ocorrências. Assim, o comportamento de uma classe (Viga, por exemplo) é determinado pelos métodos funcionais (sequências de ações para geração de volumes e relações funcionais) desta classe. Além disso, cada classe de objetos, apresenta uma série individual de características (atributos), que devem ser considerados e devidamente armazenados em relações. Posteriormente, os procedimentos a serem executados deverão ser incluídos e associados às ocorrências de cada classe,  por meio de sequências e sub-sequências de ações, para a criação, manipulação, eliminação e ativação de outros procedimentos a serem considerados devido às consequências produzidas pela inserção ou eliminação de objetos no todo de projeto. Esta última consideração, será detalhadamente definida em outra seção neste capítulo, e vai tratar dos relacionamentos que ocorrem e que podem ser produzidos entre os objetos envolvidos em um processo de projeto.

Como exemplo, serão criadas as seguintes classes de elementos estruturais para uma estrutura de edifício:

Ver imagens:

Classe LAJE

Classe VIGA

Classe PILAR

Classe FUNDAÇÃO

 O mecanismo para criação de uma classe

9.2.3 O mecanismo para criação de uma classe 

A partir desta seção, serão definidos formalmente os mecanismos suplementares da linguagem de ações, para criação, gerenciamento e manipulação de relações funcionais. Uma observação importante a ser considerada, reside no fato de que estes mecanismos terão o seu funcionamento aplicado diretamente em meios de armazenamento externos ao sistema principal, i. é, por exemplo, em discos rígidos (winchester de computadores pessoais).

Figura 9.3- Independência entre o sistema principal e os dados funcionais.

A principal vantagem na utilização desse tipo de armazenamento de informações é permitir o armazenamento de grandes quantidades de dados, independentemente do limite de memória RAM dos computadores. Assim, visto que os dados residem em um meio externo ao sistema, este último pode crescer independentemente da quantidade de informações armazenadas. Também, o acesso e principalmente a portabilidade dessas informações torna-se mais eficiente, permitindo que outros sistemas possam fazer uso dos resultados obtidos, permitindo, por exemplo, a geração de relatórios, orçamentos e outros documentos necessários para a execução de um produto.  Como desvantagem, deve-se salientar que o acesso às informações será mais lento, visto que uma consulta em um meio de armazenamento externo não é realizada diretamente na memória do computador. A Figura 9.3 mostra um esquema onde podem ser observados o sistema principal e a base de dados.

A seguir, será definido o mecanismo para criação de classes de objetos funcionais.

Ver imagem do mecanismo para criação de classes

Como observação, deve-se mensionar que, a partir do momento em que o comando ART é executado, a referida classe é criada como seu primeiro atributo. Assim, outros atributos podem ser gerados para a mesma classe, incorporando-se aos demais anteriormente criados, bastando para isso, executar outro comando ART para a mesma classe.

 Representação das ocorrências de uma classe

9.3 Representação das ocorrências de uma classe

Após serem criados os atributos de uma classe de objetos e seus respectivos domínio, torna-se possível a representação das ocorrências ou entidades dessa classe, i. é, os objetos com suas características próprias que os individualizam no mendo real. Dessa forma, as entidades representarão as lajes, vigas, pilares e fundações do exemplo apresentado na seção necessárias para a aplicação das ações funcionais de projeto, que serão avaliadas no momento oportuno neste trabalho.

O comando da linguagem de ações ENT, cuja definição formal é apresentada a seguir, será utilizado para gerar uma ocorrência de uma classe.

ENT<cla; nun, at1, at2, at3, ..., atn> = Mecanismo para criação de uma entidade

Onde:

cla = nome da classe a que pertence a entidade (8 caracteres)
num = número da entidade (funciona como uma chave primária) (inteiro)

at1, at2, at3, ..., atn = valores das ocorrências dos atributos da classe (devem ser respeitados os domínios estabelecidos na relação de definição da classe correspondente)

Exemplo:

: = (I[2], 400)
: = (I[3], 500)
: = (I[5], 1400)
ENT<LAJE; 1, 0 , 0, I[2], I[3], 8, I[5]>
+ (I[2], 500)
ENT<LAJE; 2, 400 , 0, I[2], I[3], 7, 1540>

Arquivo LAJE. ENT:
LAJE1  0 0 400 500 8 1400
LAJE2 400 0 900 500 7 1540

Note-se que as ocorrências das entidades serão individualizadas pelo identificador especial localizado na primeira coluna da relação de entidade, e que será formado pela concatenação entre o nome da classe cla  e o número da entidade nun (LAJE1, LAJE2 no exemplo acima). Assim, esta chave primária vai servir como parâmetro de referência para acesso às informações relativas aos valores dos atributos de uma dada ocorrência.

Note-se, ainda, que a ordem em que foram estabelecidos os atributos de uma classe (gerada com o comando ATR), deve ser rigorosamente respeitada, visto que ao ser executado o comando ENT, os atributos existentes no arquivo da relação de atributos da classe, serão lidos na ordem em que foram criados, e simultaneamente a essa operação de leitura, os respectivos valores das ocorrências serão armazenados na relação de entidade.

Como observação complementar, deve-se considerar o fato de que os valores inicialmente atribuídos às ocorrências de uma classe de objetos podem não ser os parâmetros definitivos destas ocorrências, podendo sofrer alterações durante os estágios de desenvolvimento de um processo de projeto, para satisfazer necessidades específicas do projeto ou como resultado de um sub-procedimento de cálculo matemático para dimensionamento, por exemplo.

 Incorporando os relacionamento funcionais 

9.4 Incorporando os relacionamento funcionais 

Como foi visto, os objetos existentes e que podem ser identificados no mundo real, podem ser representados em uma relação do tipo entidade. Além disso, as entidades que possuem propriedades comuns, i. é, mesmos atributos, podem ser agrupados em uma mesma relação, constituindo dessa forma, as classes de objetos.

A partir desta seção, será considerado o fato de algumas ocorrências existentes nas relações de entidade dependem ou produzem efeitos sobre outras ocorrências de entidades. Este vínculo entre entidades pode ser criado ou eliminado durante as etapas de um projeto, podendo, dessa forma, existir em um dado momento e decorrido algum tempo, após a aplicação de algumas sequências de ações, deixar de existir, ou até mesmo multiplicar-se, gerando novas vinculações existenciais com outros objetos anteriormente criados.

Há dois tipos principais de relacionamentos (BJORK, 1989) que podem ocorrer entre os objetos de um projetos, que são:

 Um objeto pode pertencer a um objeto maior, sendo portanto, parte de outro (Figura 9.4 (a),onde os ferros FN1, FN2, FP1 e FP2 fazem parte da viga V1).

Um objeto pode estar conectado a outro objeto, estando portanto, acoplado a este outro objeto (Figura 9.4 (b), onde os módulos MOD1, MOD2, MOD3 e MOD4, estão conectados uns aos outros) .

Ver Figura 9.4

Observe-se, que nas Figuras 9.4(a) e 9.4(b), os relacionamentos "parte de " e "por acoplamento" são apresentados dob a forma de dois tipos particulares de diagramas. No segundo caso, foi utilizado o diagrama entidade-relacinamento (MARTIN, 1985) para representar como os relacionamentos ocorrem. Nesse caso, pode ser observada a utilização do símbolo † para representar um acoplamento simples, i. é, com apenas um objeto. Da mesma forma, o símbolo \I/ ( "pé-de-galinha"), foi empregado para representar a existência de um acoplamento múltiplo, i. é, com mais de um objeto. Por exemplo, o módulo MOD4 possuí um acoplamento simples do tipo S+ com o módulo de nome MOD3, que entretanto, apresenta um acoplamento múltiplo do tipo S- com o módulo MOD4, visto que existem dois módulos MOD3 e um módulo MOD4. Quanto ao tipo de relacionamento "parte de ", deve ser considerado que um objeto pode ser constituído por vários outros, e dependendo do nível de detalhamento que se queira, podem ser obtidas visões (WIEDERHOLOD, 1986) diferentes do mesmo objeto, aplicando-se refinamentos funcionais (JALOTE, 1989) que permitam visualizar ou emitir outros tipos de documentos, tais como relatórios ou relações de materiais, de partes específicas do produto que está sendo projetado (BJORK, 1989). Para representar sete tipo de relacionamento foi adotado o diagrama de ações (MARTIN, 1985) que pode ser visto  na Figura 9.4 (a). Neste exemplo, pode ser observada a existência de um volume principal V1 (viga de um edificio) e quatro outros volumes FN1, FN2, FP1 e FP2 (ferros negativos e positivos) que fazem parte de uma ocorrência da classe VIGA. Assim, em nível de refinamento menor, os elementos FN1, FN2, FP1 e FP2 podem ficar ocultos, mas se for necessário elevar este nível, para permitir um melhor entendimento dessa parte do projeto, pode ser criada uma nova visão do objeto VIGA, onde esses elementos agora aparecem e fazem parte integrante da ocorrência. A Figura 9.5 mostra um esquema diagramático para representação dos elementos estruturais de um edifício com um refinamento funcionais aplicado à ocorrência VIGA1 para exibição de uma visão das ferragens do referido elemento estrutural. Da mesma forma, o diagrama de ações pode sofrer refinamentos, permitindo assim, por exemplo, a representação das ações necessárias à geração dos volumes que constituem os objetos, assim como, das ações empregadas para gerar as relações de classe, entidade e outras que serão definidas a seguir. 

Ainda sobre a qustão dos refinamentos funcionais, este tipo de concepção de novos elementos e operações de projeto, pode ser vista como uma abstração hierárquica (BJORK, 1989), i. é, uma ferramenta que permita subdividir um objeto complexo em partes mais simples, estabelecendo também, os relacionamentos internos existentes entre estes elementos. 

 Ver Figura 9.5 - Esquema diagramático para representação de relacionamentos com uma visão de refinamento funcional.

Inerências

9.4.1 Inerências 

Por definição, inerência é qualidade de inerente, i, é, qualidade de algo " que por natureza está inseparavelmente ligado a alguma coisa" (FER, 1978). Visto que objetos pertencem a classes e as de objetos podem apresentar ligação funcionais entre sí, pode-se dizer que, algumas classes são inerentes ( subentendem) a outras classe.

Para exemplificar o conceito de inerência entre classes, considere-se o exemplo de trabalho, onde podem ser estabelecidos os seguintes conceitos:

 As ocorrências da classe LAJE se apoiam em ocorrências da classe VIGA.

As ocorrências da classe LAJE podem se acoplar lateralmente a outras ocorrências da classe LAJE.

As ocorrências da classe VIGA podem apoiar em ocorrências da classe PILAR.

As ocorrências da classe VIGA podem se  apoiar em outras ocorrências da classe VIGA.

As ocorrências da classe PILAR se apoiam em ocorrências da classe FUNDAÇÃO.

As ocorrências da classe PILAR podem se acoplar verticalmente à outras ocorrências da classe PILAR.

A Figura 9.6 mostra um diagrama das possíveis conexões funcionais entre os elementos de uma estrutura de edifício, fundamentada nos conceitos estabelecidos acima.

A seguir, será apresentado o comando da linguagem de ações responsável pela geração de inerências entre classe de objetos que tenham sido criadas anteriormente com o mecanismo ATR.

Ver imagem do comando da línguagem de ações

 Geração dos relacionamentos

9.4.2 Geração dos relacionamentos

A geração das ocorrências de relacionamentos funcionais entre as entidades pertencentes às classes de objetos, cuja inerência foi estabelecida no arquivo INERENC.CLA, pode ser realizada mediante a utilização do mecanismo para criação de relacionamentos REL, que será definido a seguir.

Ver imagem do mecanismo de criação de relacionamentos

Observe-se no exemplo apresentado acima, as duas formas permissíveis de refenciar uma entidade dentro do comando REL. A primeira delas usa o mecanismo TNM, que transforma um nome de entidade fornecido pelo usuário em um nome cujo formato é padronizado para satisfazer ao seu domínio dentro da relação de relacionamentos. 

TNM <vax; nem> = Aplica o formato padrão ao nome da ent.

Onde:
vax = variável auxiliar que receberá o nome de entidade padronizado em 16 caracteres
nem = nome da entidade (máximo de 16 caracteres)

A segunda forma de se referenciar a entidade (modo direto), se for utilizada, deve levar em consideração o fato de que o nome da entidade deve ter 16 caracteres. Portanto, se o nome tiver um número inferior ao exigido por este domínio, deverão ser utilizados tantos espaços quantos forem necessários para completar este número de caracteres.

Outro mecanismo auxiliar que pode ser utilizado é o comando NEN, servindo para referenciar um nome de entidade, sendo diferente do comando TNM na forma de indicação da entidade, visto que permite indicar o nome da classe (8 caracteres no máximo) e o número da entidade. Assim, o comando concatena cla com num para construir um nome no formato padrão para nomes de entidade, com 16 caracteres.

NEN <vax; cla; num> = Cria um nome de entidade no formato padrão com 16 caracteres, transferindo este nome para uma variável auxiliar do tipo string.

Onde:
vax = variável auxiliar que receberá o nome de entidade padronizado.
cla = classe a que pertence a entidade (8 caracteres)

num = número da entidade (inteiro)

Exemplo:
NEN<S[1]; VIGA, 5>
Efeito:
S[1] = ' VIGA5 ' (16 caracteres)

Mecanismos para leitura de atributos 

9.5 Mecanismos para leitura de atributos 

Após a geração das relações de entidades, os atributos destas poderão ser lidos e transferidos para variáveis auxiliares, respeitando-se os domínios. Esta operação de leitura é de fundamental importância para a aplicação de regras na tomada de decisões durante as etapas de elaboração de um projeto. Dessa forma, será possível o acesso às informações das características dos objetos envolvidos em um projeto, para um determinado instante do processo de geração. Note-se, ainda, que isto não significa que os valores acessados sejam valores definitivos, pois estes valores podem sofrer alterações durante a execução das diversas decomposições de ações funcionais.

A seguir, serão definidos os comandos para leitura de atributos para os domínios inteiro, real  e string.

ver imagem comando para leitura.

Realizando alterações nas relações de entidade

9.6 Realizando alterações nas relações de entidade 

Como foi mencionado anteriormente, os valores dos atributos não permanecem estáticos durante a execução das diversas etapas de um projeto. Assim, para satisfazer algumas necessidades específicas, tais como um re-dimensionamento geométrico ou deslocamento de um elemento, pode ser preciso alterar o conteúdo de um conjunto de atributos. Além disso, a ação de alterar algumas características funcionais de um objeto individual pode produzir consequências importantes sobre outros elementos do projeto, sendo necessário, portanto, em alguns casos, alterar os valores de alguns atributos desses objetos diretamente atingidos.

Os comandos que serão definidos a seguir, constituem-se num instrumento versátil para se indicar o atributo da ocorrência de uma classe a ser modificado.

Ver imagem dos comandos num instrumento versátil

Ver Figura 9.7 - Aplicação de uma geminação positiva a partir de uma laje inicial.

Para ilustrar a utilização dos mecanismos de alteração, considere-se as seguintes situações do exemplo de projeto de uma estrutura de edifício:

Gera-se, numa primeira etapa, uma laje inicial, que se apoia em quatro vigas, que por sua vez, se apoiam nos quatro pilares posicionados nos vértices da laje ( Figura 9.7 (a), onde se colocam também os esquemas de cargas).

Aplica-se uma geminação positiva, considerando-se como semente o objeto laje inicial (Figura 9.7 (b)).

Uma Consequênte (automática): As vigas V1 e V4 devem ser re-dimensionadas geometricamente (alteração no comprimento e na altura).

 Eliminação de uma entidade 

9.7 Eliminação de uma entidade 

Em determinadas situações de projeto, pode surgir a necessidade de eliminar uma entidade. Esta operação de remoção de um elemento pode ser motivada por razões econômicas ou detalhes construtivos fundamentais na experiência. Nesse caso, também devem ser consideradas as consequências funcionais que podem surgir a partir da remoção de um determinado elemento. Assim, por exemplo, não se pode simplesmente remover um pilar de uma estrutura. Outras providências (ações) devem ser executadas para impedir a queda da estrutura. Da mesma forma, não se pode retirar uma parede sem antes verificar se essa parede tem função estrutural ou se é apenas um simples enchimento divisório, sob pena de ocorrer um desabamento de toda a estrutura.

O comando ELE será empregado para referenciar a ocorrência de uma classe de objetos a ser eliminada da estrutura de dados do projeto.

ELE <cla; nen> = Elimina uma entidade.

Onde:
cla = nome da classe a que pertence a entidade (8 caracteres)

nen = nome da entidade a ser eliminada

Exemplo: (Figura 9.8)
NEN<S[1]; PILAR, 2>
NEN<S[2]; PILAR, 4>
ELE<PILAR; S[1]>
ELE<PILAR; S[2]>

Ver Figura 9.8

Eliminação de relacionamento 

9.8 Eliminação de relacionamento 

Como foi mensionado, a eliminação de um conjunto de elementos pode provocar a propagação de consequências sobre um conjunto de partes de um projeto. Assim, não é suficiente remover um elemento. Deve-se, além disso, eliminar todos os relacionamentos funcionais que este elemento possui com outras partes do todo projetado e ativar todas as ações necessárias para desencadear a totalidade dos efeitos produzidos pela remoção do elemento, ativando-se também todas as sequências de ações para remediar estes efeitos, evitando-se consequências indesejáveis.

A seguir, será apresentado o mecanismo que permite remover todos os relacionamentos funcionais de uma entidade para uma determinada inerência.

ELR <arq; nen> = Elimina os relacionamentos de uma entidade para uma determinada inerência.

Onde:
arq = nome do arquivo de relacionamentos (8 caracteres)

nen = nome da entidade a ter seus relacionamentos eliminados

Exemplo: 
NEN<S[1]; PILAR, 2>
NEN<S[2]; PILAR, 4>
ELE<P&V; S[1]>
ELE<P&V; S[2]>

Leitura dos relacionamentos de uma entidade

9.9 Leitura dos relacionamentos de uma entidade 

Em algumas ocasiões durante um projeto, será necessário determinar quais os relacionamentos que uma determinada entidade possui com outras entidades. Assim, será possível descobrir se uma entidade apresenta, em um dado instante de projeto, um relacionamento do tipo geminação positiva (G+) com alguma outra entidade. Se existir tal relacionamento, dependendo do objetivo que se queira atingir, o fluxo de execução deverá ser desviado para uma sequência de ações que considere essa instância. Se não existir, outras providências deverão ser adotadas, por exemplo, para remediar essa situação. Portanto, utilizando-se o mecanismo de controle, definido anteriormente neste trabalho, será possível criar novas decomposições de ações funcionais, estabelendo-se a totalidade das ocorrências de casos possíveis (Figura 9.9).

ver Figura 9.9

O mecanismo, definido a seguir, será empregado para fornecer os relacionamentos funcionais de uma entidade.

Ver comando de relacionamentos funcionais

 Mecanismo que fornece o nome da entidade que possui um determinado conjunto de atributos

9.10 Mecanismo que fornece o nome da entidade que possui um determinado conjunto de atributos

O comando da linguagem de ações que será apresentado a seguir, permite especificar um conjunto de valores e a obtenção d a entidade que possui essa ocorrência de atributos em um determinado instante da execução da sequência de ações de um projeto.

ver imagem do comando de ações

 Transferência do fluxo de ações

9.11 Transferência do fluxo de ações

A modularização (atividade de projeto lógico, que tem por finalidade a definição de uma organização modular, executável em algum ambiente de programação não especificado (STAA, 1983) das ações funcionais de um projeto é uma metodologia de programação recomendada. Seus benefícios mais evidentes são (STAA, 1983):

Criação de programas complexos em equipe, aumentando o grau de paralelismo e, consequêntemente, reduzindo o tempo de desenvolvimento.

Redução do tempo de compreensão, programação e teste, bem como redução da probabilidade de existência de falhas de programação.

Permite a aplicação de testes quase completos em módulos pequenos.

Redução no esforço de manutenção.

Reutilização de um módulo como componente de outra sequência de ações.

Por exemplo, a geração de um objeto laje inicial, utilizando-se a linguagem de ações, pode ser feita estabelendo-se a seguinte organização modular (Figura 9.10):

Ver Figura 9.10

Assim, o módulo LI1 cria as relações de atributos das classes LAJE_SEMENTE, VERTICE_POSICAO, VERTICE_VIGAS, LAJE, VIGA e PILAR, além da relação de inerências. O módulo LI2 será o responsável pela entrada de dados da laje inicial (dimensões, utilização etc) e pela manipulação desses dados para definição dos atributos dessa entidade. O módulo LI3 vai manipular e gerar as entidades da classe VIGA e o módulo LI4 fará o mesmo com as entidades da classe PILAR. Posteriormente, o módulo LI4 vai estabelecer os relacionamentos produzidos entre as entidades geradas. Finalmente, o módulo LI6 fará a leitura das características geométricas  entidades que foram criadas, gerando os volumes dessas entidades, utilizando os mecanismos para geração de volumes apresentados em capítulos anteriores deste trabalho. Esta operação de geração de volumes (utlizando-se uma representação do tipo "wireframe") vai originar a produção de outras relações (na mamória do computador), para representação dos vértices, arestas, faces etc.

A interligação entre os módulos será feita por meio de um mecanismo que permite transferir o controle de execução das ações de um módulo para outro. Este comando (TCA) será definido a seguir.

TCA<arq> = Transfere o controle de execução das ações.

Onde:
arq = Nome do arquivo de ações (. REG) (8 caracteres)

Exemplo: 
TCA<LI2>

Ver Figura 9.11

Note-se que o mecanismo de controle, visto no Capítulo 8, pode ser utilizado como um mecanismo de decisão relativo ao fluxo da sequência de ações a ser seguido em um projeto. Assim, por exemplo, vários casos podem ser considerados ao ser aplicada uma geminação positiva a partir de uma semente laje inicial. A Figura 9.11 mostra alguns desses casos e a Figura 9.12 apresenta a respectiva organização modular.

Ver Figura 9.12

Ver Tabela 9.1 e Tabela 9.1( cont)

 Aplicações 

10. APLICAÇÕES 

A geração de estruturas de concreto armado, vista no capítulo anterior deste documento, constitui-se num exemplo simplificado de aplicação dos conceitos e mecanismos apresentados. Assim, um número ilimitado de outras aplicações, mais elaboradas, em diversas áreas da ciência, podem ser produzidas utilizando-se um modelamento funcional de objetos, como será visto neste capítulo, abstraindo-se maiores detalhes que fogem ao escopo deste trabalho.

Biologia

10.1 Biologia

As leis de Mendel (1822-1884), a respeito da hereditariedade, estabelecem regras que mostram como se realiza a transmissão dos caracteres nos cruzamentos entre seres vivos (LARROUSE, 1962). De acordo com Mendel, os fatores hereditários são transmitidos de pai para filho através dos gametas (células sexuais), permanecendo segregados uns dos outros, sem se misturarem. Note-se, ainda, que os efeitos produzidos por estaação hereditária podem ser mascarados  pela dominância (caracter dominante = aquele que prevalece) de um sobre o outro(caracter recessivo = aquele que fica encoberto ou mascarado),embora isso nem sempre acontença. A partir desse fenômeno, Mendel estabeleceu a seguinte lei:

Primeira Lei de Mendel: "Os filhos de dois indivíduos puros, para to caráter, serão todos iguais. Mas seus netos estarão na proporção de 3:1 se houver dominância de um dos fatores, e de 1: 2: 1 se não houver".

Em uma de suas pesquisas, Mendel fez cruzamentos entre ervilhas verdes e ervilhas amarelas, obtendo resultados que posteriormente o ajudaram a formular sua primeira lei (i. é uma regra de hereditariedade).

Ver Figura 10.1

Observe-se que as sementes podem ser vistas como objetos, que possuem atributos especiais (fatores genéticos) e podem apresentar  relacionamentos entre sí (cruzamentos). A Figura 10.1 mostra um esquema diagramático para representar o relacionamento (cruzamento) entre duas entidades da mesma classe (semente amarela), e a Figura 10.2 faz o mesmo para um cruzamento entre sementes verdes. Nestas figuras, note-se que A é o fator das sementes amarelas, v o das sementes verdes.  Além disso, cada célula sexual dá um fator (gen) à semente e cada semente tem, portanto, dois fatores. Assim, num relacionamento de duas entidades da classe semente amarela, os fatores da entidade resultante deste cruzamento serão AA, e , num relacionamento de dois verdes, vv. Note-se, além disso, que os esquemas genéticos usam letras maiúsculas para indicar  fatores dominantes e minúsculas para os recessivos.

Ver Figura 10.2

Ver Figura 10.3

A seguir, a Figura 10.3 mostra um relacionamento entre uma entidade da classe semente amarela com uma entidade semente verde. note-se que as sementes resultantes são amarelas, mas dentro delas estão ocultos os fatores v que produzirão os verdes da próxima geração.

Na segunda gerção de híbridos, um quarto das sementes nascidas será verde, e só terão filhos verdes se continuarem a autofecundar-se. Serão sempre vv. Um quarto é de amarelos puros e será AA. Note-se, ainda, que dois quartos serão híbridos Av, que nas próximas gerações continuarão a decompor-se da mesma maneira. A Figura 10.4 mostra a segunda geração de sementes.

Ver Figura 10.4

Assim, os conceitos de hereditariedade vistos acima, podem ser programados utilizando-se a linguagem de ações, e as várias gerações de cruzamento de sementes podem ser vistas como níveis de decomposição de ações hereditárias. Dessa forma, utilizando-se este tipo de modelamento funcional, torna-se possível representar graficamente, na forma tridimensional (tudo o que existe na natureza é tridimensional - a representação plana é apenas um tipo de representação, um modelo simplificado), as projeções para as ocorrências de sementes em vagens de ervilha, como pode ser visto esquematicamente na Figura 10.5.

Ver Figura 10.5

Assim, os indivíduos verdes e amarelos puros ou híbridos poderiam ser representantes da classe:

Arquivo INDIVID. ATR:

I GERACAO

S FATOR_GENET1

S FATOR_GENET2

...

Exemplo: 

INDIVID. ENT:

INDIVID1 1 A v
INDIVID2 1 A v
INDIVID3 2 A A
...

Da mesma forma, os relacionamentos (cruzamentos) entre os indivíduos podem ser representados pelas relações:

Arquivo INERENC. CLA:

INDIVID INDIVID IND&IND

Arquivo IND&IND. REL:

INDIVID1 INDIVID2 1

...

1 = campo modificado para indicar a geração em que ocorre o relacionamento

Nota-se, ainda, que nesta aplicação seria necessário criar um novo mecanismo que permitisse a escolha ao acaso do fluxo de ações, visto que, no exemplo citado, a ação de um cruzamento entre dois indivíduos pode produzir quatro consequências funcionais diferentes, mas somente uma delas deverá ocorrer.

Química 

10.2 Química 

A química estabelece que a matéria é constituída de partículas extremamente pequenas, denominadas moléculas, separadas umas das outras por espaços vazios. Note-se que, neste caso, as moléculas também podem ser vistas como objetos tridimensionais. Além disso, as entidades moleculares são constituídas por partículas indivísiveis, denominadas átomos, i. é, os elementos químicos (H = hidrogênio, C = carbono, O = oxigênio etc). As moléculas e seus elementos químicos também apresentam propriedades especiais, atributos químicos, tais como: massa atômica, massa molecular, volume atômico, volume molecular, valência etc.

As moléculas das substâncias simples podem ser combinadas, gerando um relacionamento químico, onde devem ser considerados os grupamentos funcionais (radicais ou atômos) envolvidos no processo. Os relacionamentos químicos podem ser representados esquematicamente através de reações químicas, onde devem ser consideradas as fórmulas das moléculas das substâncias que reagem (se relacionam funcionalmente) para produzir outras substâncias. Assim, os efeitos produzidos pela reação, a partir do conhecimento de determinadas regras ou leis da química, como por exemplo, o príncipio da conservação dos elementos, poderiam ser considerados utilizando-se sequências de ações moleculares.

Portanto, as ligações moleculares entre os elementos químicos poderiam ser representadas na sua forma tridimensional, possibilitando dessa forma, a observação das estruturas moleculares espaciais ou estereoquímicas das substâncias químicas em sua disposição real no espaço. Como exemplo, pode ser citado o trabalho de Le Bel e Van't Hoff, que concluíram que as quatro valências do átomo de carbono não estão dispostas num mesmo plano, mas estão, ao contrário, orientadas como retas que, do centro de gravidade de um tetraedro regular, se dirigem para os quatro vértices. Além disso, essas quatro direções formam entre sí ângulos iguais, fato que traduz a equivalência das quatro ligações do carbono. Então, nessas condições, o metano, CH₄, apresenta a configuração espacial mostrada na Figura 10.6.

Ver Figura 10.6

A Figura 10.7 mostra a consequência funcional (numa representação simplificada plana) de uma tripla ligação molecular (triplo relacionamento entre entidades moleculares), onde três moléculas de acetileno C₂H₂ produzem uma molécula de benzeno C₆H₆, numa reação conhecida como polimerização.

Ver Figura 10.7

Então, os elementos químicos e as moléculas poderiam ser representados pelas seguintes classes de objetos químicos funcionais:

Ver imagem das classes de objetos químicos funcionais

Da mesma forma, os relacionamentos químicos podem ser representados pelas relações: ( ver imagem da relações).

Vale salientar que a introdução das regras químicas a serem introduzidas no sistema (utilizando-se a linguagem de ações), de forma a enriquecê-lo com mais conhecimentos funcionais na área, deve ser feita com a colaboração de um especialista químico, que é a pessoa indicada para este tipo de tarefa, visto que o fator experiência é de fundamental importância para a obtenção de um produto.

 Matemática 

10.3 Matemática 

Também na Computação Algébrica, um Sistema de Modelamento de Objetos Funcionais pode ser aplicado a um conjunto de termos algébricos representados por figuras geométricas tridimensionais (objetos algébricos), para produzir um resultado, i. é uma consequência funcional matemática. Nessa aplicação, os relacionamentos matemáticos são os operadores matemáticos, ativados pelos ícones operacionais, que ao serem aplicados às entidades de termos algébricos podem produzir uma entidade-solução.

Para exemplificar as idéias apresentadas acima, considera-se a seguinte equações algébrica:

2 * X1 + 2 = 10

Assim, a classe UNIDADE deverá ser criada para representar as ocorrências 2 e 10, sendo a incógnica X1 uma entidade da classe X, como mostrado a seguir:

Ver classe unidade

Note-se, ainda, que as ocorrências de termos algébricos podem ser representadas por volumes tridimensionais. Para tal, será estabelecido o seguinte conceito inicial, que será utilizado como unidade básica para representação tridimensional de termos algébricos:

Unidade algébrica computacional: é um cubo cujas arestas são unitárias (Figura 10.8).

      Ver Figura 10.8

A Figura 10.9 mostra a representação gráfica tridimensional para os objetos matemáticos da equação algébrica do exemplo apresentado.

Ver Figura 10.9

Analogamente, os termos algébricos X² e X³ poderiam ser representados tridimensionalmente, como pode ser visto na Figura 10.10. Note-se, portanto, que o termo lineas X equivale a um volume que possui duas dimensões unitárias e uma incógnita, o termo X² equivale a uma placa de espessura unitária e o termo X³ equivale a um cubo cujas arestas possuem a dimensão incógnita X.

Ver Figura 10.10

Assim, as operações algébricas poderiam ser aplicadas aos objetos algébricos na forma de relacionamentos algébricos. Então, inicialmente, haveria quatro relacionamentos algébricos básicos (equivalentes às quatro operações básicas), mais o relacionamento de igualdade:

Relacionamento de tipo SOMA → +

Relacionamento de tipo SUBTRAÇÃO → -

Relacionamento de tipo MULTIPLICAÇÃO → *

Relacionamento de tipo DIVISÃO → /

Relacionamento de tipo IGUALDADE → =

Portanto, os relacionamentos podem ser representados pelas seguintes inerências entre classes:

UN&X. REL:

UNIDADE1   X1    *G+

UNIDADE2   X1    +G-

UN&UN:

UNIDADE2   UNIDADE3     =G+

Note-se que os tipos de acoplamento (G+, G-, J+, J-, S+ e S-) também podem ser utilizados para indicar o sentido do relacionamento, estabelecendo dessa forma, qual o operador que está à esquerda e qual o que está à direita ( no caso de um relacionamento do tipo G). Então, os elementos de uma matriz tridimencional podem ser representados G, J e S (Figura 10.11):

Ver Figura 10.11

Assim, visto que é possível gerar elementos algébricos e estabelecer os relacionamentos que estes elementos podem apresentar entre sí, respeitando-se as respectivas inerências algébricas, pode-se aplicar sequências de ações matemáticas (regras algébricas) para operar os objetos de forma a obter uma solução para um dado problema. Como exemplos de regras podem ser citadas algumas propriedades algébricas para a adição:

Regra associativa:
a + (b + c) = (a + b) + c

Regra comutativa:
a + b = b + a

Regra do elemento neutro:
a + 0 = a

Regra do elemento inverso:
a + (-a) = 0

Portanto, utilizando-se a linguagem de ações  pode ser possível resolver, por exemplo, um sistema de equações algébricas tridimensionais, com seus elementos representados também na forma 3-D.

Os estudos mais aprofundados a respeito dos conceitos preliminares apresentados acima, assim como as suas aplicações, podem ser alvo de outros trabalhos de pesquisa, visto que fogem ao escopo deste documento, que visa lançar as sementes para a utilização de um modelamento de objetos funcionais em diferentes áreas de pesquisa. Portanto, um pesquisador da área de matemática computacional é o profissional indicado para aprofundar os estudos relativos às idéias iniciais que foram apresentadas nesta seção.

Conclusões

11. CONCLUSÕES

Ao longo deste trabalho procurou-se estabelecer mecanismos para a representação computacional na forma tridimensional de objetos funcionais. Tais elementos foram concebidos geometricamente como um agrupamento de volumes conectados uns aos outros por meio de operações de acoplamento, e existencialmente como entes que apresentam um conjunto de atributos ou características funcionais, sendo suas ocorrências representativas de determinados agrupamentos existenciais que foram conceitualmente denominadas classes de objetos funcionais. Além disso, foram definidos mecanismos, utilizando-se uma linguagem computacional apropriada, que permitem colocar os objetos funcionais dentro de uma realidade funcional (universo real), e estabelecer as consequências funcionais produzidas por uma ação desta natureza. Note-se que essas consequências são produzidas porque os objetos podem apresentar relacionamentos funcionais entre sí, e ao ser introduzido um novo objeto dentro de uma realidade espacial, tais relacionamentos devem ser considerados e as consequêntes reações em cadeia devem ser ativadas.

Assim, a geração de volumes pode ser realizada por meio de operações de acoplamento (geminação, justaposição e superposição), a partir de uma situação inicial, onde existe um volume inicial, onde existe um volume inicial que deve ser gerado utilizando-se os mecanismos VP(Cx, Cy, Cz, T, C) e VI(NV). Esta geração pode ser feita, utilizando o sistema principal SMOF.EXE, tanto na forma interativa (passo a passo) ou pela utilização dos mecanismos de geração de volumes, da linguagem de ações: V(NV, RG) e VR(NV, RG, NR). No segundo caso, os comandos de geração (VP, VI, V e VR) deverão ser escritos em um editor de textos na sequência apropriada de geração, conforme mostrado nos exemplos apresentados durante o trabalho, e gravados no disco com a extensão do nome do arquivo igual a .REG (Exemplo: JANELA.REG). Também, um ícone correspondente ao arquivo de ações deverá ser criado, de forma a permitir a ativação da sequência de ações (Ex: JANELA.ICO). Alterações poderão ser realizadas utilizando-se os comandos da linguagem de ações apresentados no capítulo 5.

Note-se que a geração e manipulação (alterações) de objetos (volumes + atributos + relacionamentos funcionais) serão utilizados de acordo com os princípios de geração de uma shape grammar, como sugerido na introdução deste trabalho. Assim, pode-se fazer as seguintes comparações entre as idéias de shape grammrs e os resultados obtidos neste trabalho (SMOF):

Shape grammars: A geração de objetos é realizada a partir de uma forma (shape) inicial bidimensional.
SMOF: A geração de objetos é realizada a partir de um volume inicial, utilizando-se o mecanismo VI(NV), com as características geométricas definidas pelo mecanismo VP(Cx, Cy, Cz, T, C).

Shape grammars: A geração de novas formas é realizada utilizando-se regras de uma gramática que são aplicadas a determinados rótulos dos elementos já existentes.
SMOF: A geração de novos volumes é realizada utilizando-se os mecanismos para geração de volumes V(NV, RG) e VR(NV, RG, NR). O parâmetro RG, nesse caso é o responsável pela aplicação das regras, onde os vértices das faces dos volumes são vistos como rótulos. A aplicação das regras pode ser controlada utilizando-se os mecanismos auxiliares da linguagem de ações.

Shape grammars: Uma gramática de formas pode ser utilizada para explicar e descrever uma determinada associação de objetos que possuem características comuns, ou para desenvolver novos objetos e testar as regras em que eles se fundamentam.
SMOF: Utlizando-se o modo interativo do sistema (mecanismos de geração e manipulação de volumes), pode-se desenvolver novos objetos. Um programa escrito utilizando-se a linguagem de ações pode ser utilizado para gerar e testar as regras em que um determinado objeto se fundamenta.

Shape grammars: São sistemas fundamentado em regras de geração e manipulação (aplicáveis por meio de uma ou mais sequências de ações, utilizando-se os mecanismos de uma linguagem de ações) que, basicamente, consiste de um estágio inicial EO (onde nenhuma operação foi executada), um conjunto finito de elementos de um vocabulário (ativados por meio de ícones e gerados utilizando-se a linguagem de ações), um conjunto de regras de produção (reguladas pelo mecanismo de controle definido no capítulo 8 deste trabalho), e uma condição terminal que pode ser definida utilizando-se uma sequência de ações para esta finalidade.

Dessa forma, pode-se concluir que as regras de shape grammars foram inseridas no contexto do trabalho sob a forma de sequência de ações a serem programadas utilizando-se a linguagem de ações.  Note-se, ainda, que todas as tarefas que são realizadas utilizando-se shape grammars podem ser realizadas pelo sistema SMOF, desde que um programa (que pode ser concebido em diversos módulos ativáveis pelos ícones) seja escrito utilizando-se a linguagem de ações.

 Outra questão que foi apresentada no ínicio deste documento, foi a possibilidade de incorporação de atributos especiais (tais como peso, temperatura,resistência a esforços físicos etc.). Esta necessidade foi suprida no capítulo 9, onde foram criados mecanismos para a geração dos atributos funcionais de objetos. Nesse capítulo, criou-se uma forma de representação em disco (na forma de relações) de classe de objetos, e de suas ocorrências ou entidades. Além disso, foram estabelecidos mecanismos para a incorporação dos relacionamentos funcionais (vitais) entre os objetos tridimensionais modelados. Dessa forma, um objeto ao ser criado pode ter, também, suas características funcionais (vitais) geradas no disco e, principalmente, os seus relacionamentos com outros objetos existentes no universo de trabalho. Portanto, posteriormente, se for necessário determinar a existência de um determinado relacionamento entre dois objetos, este estará registrado em um arquivo específico para esta finalidade. Então, utilizando-se os mecanismos para leitura de relacionamentos, este  poderá ser obtido para utilização pelos demais mecanismos auxiliares da linguagem de ações. Da mesma forma, as relações geradas poderão ser utilizadas para a formação de relatórios.

O capítulo 10 apresenta algumas sugestões de utilização dos conceitos apresentados neste documento, devendo merecer um tratamento mais aprofundado (em trabalhos futuros), pois o seu detalhamento foge ao escopo deste trabalho, que visa somente apresentar uma base introdutória à geração de objetos funcionais, fundamentada nas idéias de geração utilizando-se shape grammars. Portanto, o assunto não está esgotado e ainda há muito o que fazer, principalmente quanto a criação de aplicativos específicos para cada área do conhecimento, principalmente quanto a sua utilização na área de arquitetura, de acordo com a idéia de aplicação original do modelo, conforme sugerido por Turkienicz em (TURKIENICZ, 1990).

Uma restrição quanto à utlização do SMOF, refere-se à forma cúbica adotada como elemento básico de geração, visto que elementos ou detalhes curvos não podem ser representados. Relativamente a essa restrição, deve-se evidenciar que o sistema não foi concebido para trabalhar com detalhes de projeto, mas sim, para manipular formas em um nível que permite a concepção volumétrica (volumetria) de um projeto, de forma a permitir maior liberdade de criação (o detalhamento seria uma fase posterior).

Finalmente, deve-se mensionar que o SMOF apresenta as seguintes vantagens em relação a um sistema convencional de CAD (sistema de edição gráfica limitado a uma descrição  geométrica dos objetos):

Proporciona a geração de objetos de forma mais atraente (grande interatividade com o usuário projetista).

Torna mais ágil a tarefa de projeto, visto que o projetista pode dispor de elementos já prontos.

Evita preocupações a nível de detalhamento, como acontece nos projetos convencionais em que detalhes de desenho devem ser considerados.

É muito mais fácil gerar objetos utilizando-se um conjunto de elementos já prontos do que ter de construir cada um dos elementos durante o processo de projeto (TURKIENICZ, 1990).

Anexos 

ANEXOS 

Exemplos de objetos gerados pelo SMOF

ANEXO 1

ANEXO 2

ANEXO 3

ANEXO 4

ANEXO 5

ANEXO 6

ANEXO 7

ANEXO 8

ANEXO 9

ANEXO 10

  Bibliografia

 BIBLIOGRAFIA

ALVES, Manoel Rodrigues & RUANO, Miguel. Towards meaningful computacional descriptions of architectural form. Massachusetts, Massachusetts Institute of Technology, May 1997.

ANDRADE, Mônica Raposo, Manual de projetos de habitação popular. Recife, Secretaria de Habitação do Estado de Pernambuco, 1981.

BJORK, B-C. Basic structure of a proposed building product model. Conputer-Aided Design, Surrey, 21(2):71-78, May 1989.

COYNE, R. D. & GERO, J. S. Semantics and organization of knowledge in design. Design Computing, 1(1):68-89, Jan. 1986.

DATE, C. J. An introduction to database systems. 4.ed. Reading, Addison-Wesley, 1986, v.1.

FERREIRA, Aurelio Buarque de Hollanda. Pequeno Dicionário Brasileiro da Língua Portuguesa. Rio de Janeiro, Civilização Brasileira, 1978.

FLEMMING, Ulrich. The role of shape grammars in the analysis and creation of designs. Pittsburgh, Carnegie-Mellon University, Department of Architecture, 1986.

FOLEY, J. D. & VAN DAM, A. Fundamentals of interactive computer graphics. Reading, Addison Wesley, 1982.

GERO, J. S. & COYNE, R. D. Logic programming a means of representing semantics in design languages. Planning and design, 12:351-369, May 1985.

GRABOWSKI, Ing. H. & BENZ, Ing. T. Functional modelling in intelligent CAD-systems, Karlsruhe, University of Karlsruhe, 1989.

JALOTE, Pankaj. Funcional refinement and nested objects for object-oriented design. IEEE Transactions on Sofware Engineering, New York, 15(3): 264-270, May 1989.

JAROFF, Michel L. & MOORE, James A. Case method teaching about design process management. JAE, 38/1, Fall, 1984, p. 14-17.

LARROUSE Méthodique, Encyclopédie. Rio de Janeiro, Delta, 1962.

MAHFUZ, Edson da Cunha. An investigation into the nature of relationship between the parts and the whole in architectural composition. Pennsylvania, 1983.

MAKKUNI, Ranjit. A gestural representation of the process of composing chinese temples. IEEE Computer Graphics & Aplications, Los Alamos, 7(12):45-61, Dec. 1987.

MARTIN, James & MACLURE, Carma. Diagramming techniques for analysts and programmers. New Jersey, Prentice-Hall, 1985.

MORTENSON, Michel E. Geometric Modeling. New york, John Wiley & Sons, 1985.

PATNAIK, L. M. & RAMESH N. Implementation of an interactive relacional graphics database, Computer & Graphics, New York, 6(3):93-96, 1982.

ROCHA, Aderson Moreira da. Curso prático de concreto armado. São Paulo, Nobel. 1984, V.1.

ROGERS, David F. Procedural elements for computer graphics. New York, McGraw-Hill, 1985.

ROONEY, Joe. Principles of computer-aided design. Pitman/Open University, 1987.

SMITH, John Miles and SMITH, Diane C. P. Database abstractions: agregation. Communications of the ACM, New York, 20(6): 405-413, Jun. 1977.

SMITHERS, T. AI-based design versus geometry-based design or why design cannot be supported by geometry alone. Computer Aided Design, Surrey, 21(3): 141-150, Apr. 1989.

SPOONER, David L. Database support for interactive computer graphics. In: ACM-SIGMOD INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA, Boston, June, 18-21, 1984. Proceedings, New York, ACM,1984. Publicado em: SIGMOD RECORD, New York, 14(2):90-99, June 1984.

STAA, Arndt von. Engenharia de Programas. Rio de Janeiro, LTC, 1983.

STINY, George Nicholas. Computing With form and meaning in architecture. JAE, 39/1, Fall, 1985, p. 7-19.

WIEDERHOLD, Gio. Views, objects, and databases. Computer, Los Alamitos, 19(12): 37-44, Dec 1986.

OUTRAS FONTES

TURKIENICZ, Benamy. "LEGO eletrônico". Artigo aceito para publicação na Revista AU: Arquitetura e Urbanismo, em julho de 1990.