Mostrar código-fonte de Modelos de informação “completos” e “parciais”

Adaptado a partir de<ref>POÇAS MARTINS, J. P. 2009. Modelação do Fluxo de Informação no Processo de Construção - Aplicação ao Licenciamento Automático de Projectos. PhD Thesis, Universidade do Porto.</ref>.

=Modelos de informação “completos” e “parciais”=
==Aspectos gerais==

Os conceitos de modelos “completos” e modelos “parciais” são fundamentais para a definição de uma solução para a representação de produtos de construção que possa ser aplicada a actividades concretas realizadas pelos intervenientes do processo construtivo. De acordo com o que se apresenta no presente subcapítulo, os modelos de informação completos e parciais têm objectivos e campos de aplicação distintos, embora possam (e devam) ser compatíveis. Apresenta-se, no final desta página, uma tabela onde se resume os aspectos mais relevantes abordados ao longo deste subcapítulo.

As designações “completo” e “parcial” encerram, de alguma forma, uma contradição. Com efeito, todos os modelos são derivados da realidade por supressão de detalhes considerados menos relevantes, ou de modelação mais difícil. Por outras palavras, um modelo não é mais do que uma abstracção da realidade.

Assim, todos os modelos são “parciais” no sentido em que são uma visão simplificada da realidade. Com efeito, é esta simplificação que torna os modelos de informação úteis, permitindo que sejam usados para retratar e para prever o comportamento do único modelo verdadeiramente completo: a realidade.

Importa, pois, procurar definir qual o nível de pormenorização adequado para o modelo, tendo em conta as práticas correntes seguidas pelos diversos intervenientes no processo construtivo. A definição da estrutura de um modelo e do seu nível de pormenorização é uma tarefa que encerra um elevado grau de subjectividade. Com efeito, de acordo com (Turk 2001), não é possível afirmar que um modelo é correcto ou incorrecto, salvo no que diz respeito à sua coerência interna. Ainda assim é possível avaliar a sua capacidade para satisfazer um determinado conjunto de requisitos definidos por um utilizador ou por uma comunidade de utilizadores. É esta natureza subjectiva dos modelos que os torna, na opinião de alguns autores, interpretações da realidade ao invés de representações da realidade.

Nos últimos anos têm sido desenvolvidos esforços no sentido de construir um modelo completo a ponto de definir características físicas e outras propriedades de cada elemento de construção. As iniciativas mais promissoras resultam, directa ou indirectamente, do trabalho iniciado com o programa ISO-STEP. Este projecto visa desenvolver um modelo para produtos (incluindo produtos de construção) independente de qualquer aplicação informática (ver [[BIM]]).

O grau de pormenorização deste tipo de modelos permite-lhes incluir informações que transcendem as características dos seus componentes. Com efeito, para além da definição de um conjunto de propriedades para cada componente individual ou família de componentes, é possível estabelecer relações entre os vários componentes a colocar em obra. Estas relações serão mantidas, mesmo em caso de se proceder a alterações no projecto. As relações definidas no modelo podem ser simplesmente geométricas, por exemplo, uma parede interior poderá ser definida entre duas paredes vizinhas que lhe são perpendiculares, mas podem assumir a forma de restrições à implementação de determinada solução construtiva.

Isto significa que, para além de informação, é possível incorporar conhecimento num modelo desta natureza. É também possível transferir esta informação entre diversas aplicações, por exemplo, CAD, análise estrutural, térmica ou acústica, aplicações ERP, etc. Por outro lado, importa considerar algumas desvantagens significativas inerentes à adopção de um modelo completo:

# Dificuldade em actualizar modelo:<br />Mesmo que a base de dados de materiais e componentes do modelo fosse abrangente (o que suporia um volume de trabalho verdadeiramente prodigioso), o aparecimento de novos materiais implicaria um processo de actualização constante e uma disponibilização, por parte dos fornecedores ou outros agentes, de toda a informação considerada relevante para as aplicações a utilizar. Toda a informação teria de ser validada antes de ser incluída no modelo. A prescrição de materiais e componentes que não estejam completamente definidos na base de dados poderia inviabilizar a utilização de um modelo para análise, por exemplo.
# Introdução de alterações significativas nos processos de trabalho, especialmente ao nível da fase de projecto:<br />Por um lado, parece evidente que este tipo de abordagem reduziria o trabalho relacionado com a introdução de dados e que facilitaria a alteração de dados de projecto. Permitiria, por exemplo, actualizar o modelo estrutural de um edifício directamente a partir de uma alteração na posição de um pilar definido no seu modelo geométrico (isto é, o projecto de estabilidade estaria ligado ao projecto de arquitectura). <br/>Por outro lado, considera-se que uma ferramenta desta natureza poderá tender a condicionar a adopção de soluções construtivas, dificultando a implementação de soluções que não sejam devidamente suportadas pelo modelo (O impacto da utilização de modelos paramétricos nos processos criativos é discutido em maior detalhe em (Turk 2001)). A adopção de soluções “mistas”, em que algumas peças seriam definidas no modelo e outras seriam especificadas e desenhadas segundo os processos usuais parece pouco viável, uma vez que este tipo de abordagem corromperia a integridade do modelo. Uma solução alternativa passaria pela possibilidade de criar novos componentes e regras ou pela possibilidade de alterar as definições existentes, isto é, por permitir editar o modelo padrão. Esta solução permitiria manter a integridade do modelo (embora crie o risco de corrupção através da introdução de dados inadequados, não validados), mas levaria a uma inevitável disseminação de modelos incompletos, com informações não validadas. Para além disto, obrigaria os utilizadores a dominar um conjunto de operações complexas para a definição de novos elementos de construção. Actualmente esses modelos são criados em linguagens de programação específicas (EXPRESS, NIAM, etc.) e é pouco crível que a comunidade de projectistas adopte este tipo de procedimento. Esta previsível dificuldade em produzir alterações no modelo predefinido ou em aceitar soluções “mistas” pode resultar numa situação de “tudo-ou-nada” em que apenas os componentes definidos no modelo podem integrar o projecto a definir.<br />
# Pode ser vontade de qualquer interveniente manter sigilo sobre alguns dados, quer por os considerar confidenciais (rendimentos de mão de obra, por exemplo), quer por desejar prevenir a utilização dos seus elementos de análise para fins imprevistos.

Alguns autores sugerem simplesmente que a introdução de toda a informação relacionada com um edifício num formato digital é dispendiosa, ineficiente e desnecessária (Johnson et al. 1999).

Outras críticas aos modelos completos apontam a lentidão do seu desenvolvimento e a elevada complexidade associada à sua implementação (Behrman 2002). As dificuldades apontadas são inerentes à imposição de um formato padrão por parte de um conjunto limitado de organizações – implementação ''top-down''.

==Avaliação de diferentes tipos de abordagem ao desenvolvimento de formatos padrão==

O desenvolvimento de formatos padrão para as tecnologias de informação apresenta já uma história longa. A ''World Wide Web'', por exemplo, foi construída sobre um conjunto muito bem sucedido de formatos, incluindo a linguagem HTML – ''Hypertext Markup Language'' – e o formato XML – ''Extended Markup Language''.

As abordagens seguidas durante o desenvolvimento destes formatos podem ser divididas em duas categorias distintas (Behrman 2002):

# Abordagens minimalistas: As abordagens do tipo minimalista valorizam formatos padrão simples e a sua rápida aceitação por parte da comunidade de utilizadores. É uma abordagem do tipo ''bottom-up'' que começa com um conjunto limitado de regras de representação. O desenvolvimento do formato é iterativo e empírico – o formato vai sendo ampliado à medida que é bem sucedido na resolução de problemas concretos. Alguns exemplos que resultam de abordagens ao desenvolvimento do tipo minimalista são as linguagens HTML, SQL e C e o protocolo TCP/IP.
# Abordagens estruturalistas: As abordagens do tipo estruturalista valorizam formatos padrão completos e detalhados. É uma abordagem do tipo ''top-down'' que começa com um modelo de nível elevado e que prossegue depois para níveis mais baixos, onde o detalhe é maior. Frequentemente, o processo de desenvolvimento é muito lento e a tarefa tende a afigurar-se colossal. As aplicações práticas deste tipo de tecnologias tendem a não surgir até que o modelo atinja um nível de desenvolvimento suficientemente detalhado, pelo que a sua aceitação por parte da comunidade de utilizadores é, regra geral, demorada. Entre as iniciativas que seguem abordagens deste tipo conta-se o ''Standard for the Exchange of Product Model Data'' (STEP).

Considera-se que as abordagens de desenvolvimento que seguem exclusivamente a via estruturalista são menos aptas a solucionar os problemas concretos que se colocam à indústria da construção. A dimensão do problema, as características da indústria e a prática tradicional (já avaliados nos capítulos anteriores) são obstáculos relevantes à imposição de um formato padrão abrangente seguindo um desenvolvimento do tipo ''top-down''.

Com efeito, afigura-se provável que, mesmo modelos que mereceram a aceitação geral da comunidade académica, não gozam da mesma popularidade junto da comunidade técnica. Os modelos “completos” são extremamente interessantes na óptica da comunidade académica, não só pela clara atractividade associada ao conceito da possibilidade de representar, de forma completa, um produto de construção em todas as suas fases, mas também porque abre um novo e vasto campo de investigação na área da gestão da informação. Por outro lado, importa reflectir acerca da reduzida aceitação que este tipo de modelos goza ainda junto da comunidade técnica. É importante admitir que a comunidade técnica não reconhece actualmente valor – no sentido económico da expressão – nas potencialidades oferecidas por estes modelos a ponto de justificar uma adesão significativa às novas práticas que lhes estão associadas. Mesmo nos ainda raros casos em que os técnicos utilizam modelos completos e lhes reconhecem valor, referem-se frequentemente apenas a aspectos limitados dos modelos, por exemplo a aspectos geométricos usados na detecção de incompatibilidades entre projectos de especialidades distintas. Um estudo consultado (McGraw Hill Construction 2007) revela que 80% dos engenheiros que utilizam BIM, usam esta tecnologia para produzir imagens tridimensionais dos produtos de construção (''renders''), 50% usam BIM para detectar incompatibilidades (geométricas) de projecto e que apenas 46% o usam para efectuar análises estruturais, por exemplo. Com efeito, os BIM continuam a não cobrir todos os domínios na área do projecto, nem todas as fases do projecto (Weise et al. 2008).

Em síntese, importa considerar a hipótese de que os modelos “completos” não têm dado resposta satisfatória aos problemas concretos colocados pelos técnicos ''hoje''.

Considera-se que pode ser preferível uma solução alternativa que permita incorporar alterações relativamente pequenas aos procedimentos de trabalho actuais de forma a assegurar uma transformação gradual nos processos de trabalho. Esta visão não colide de forma alguma com o objectivo de criar um modelo completo, apenas se considera improvável que tal modelo possa ser adoptado pela comunidade técnica a curto ou a médio prazo e que não se deve esperar uma alteração brusca nos procedimentos habitualmente seguidos na construção. Admite-se que uma solução que permita a utilização de ferramentas informáticas habitualmente empregues nas diferentes fases do processo construtivo e que relacione a informação gerida por cada uma destas aplicações possui vantagens significativas sobre uma solução do tipo “tudo-ou-nada”. Uma solução deste tipo não exclui a possibilidade de usar modelos completos como repositórios de informação, tornando-os importantes para assegurar a interoperabilidade entre diferentes utilizadores e entre diferentes aplicações.

Um modelo que resulta de uma abordagem minimalista apresenta vantagens claras para a comunidade técnica dado que visa, em primeiro lugar, dar resposta aos seus problemas concretos. Durante a fase de desenvolvimento, podem coexistir diversos modelos concorrentes para um mesmo fim que, eventualmente, poderão ser selectivamente agregados num modelo de espectro mais alargado. Estes modelos podem ser desenvolvidos de modo independente – não existe uma obrigatoriedade na adesão a outro tipo de formatos padrão, nem uma necessidade absoluta de desenvolver vários modelos de modo coordenado. No caso da construção, seria possível (e previsível) assistir-se a um rápido surgimento de modelos para as áreas em que o seu desenvolvimento e a sua implementação seriam mais vantajosas e mais fáceis, nomeadamente nas actividades com uma componente de pré-fabricação mais acentuada. Dado que o objectivo principal de cada participante no processo de desenvolvimento será a resolução dos seus problemas específicos (ou os problemas do sector onde se insere) o processo poderia nunca vir a culminar num modelo completo. Ainda assim, é possível conseguir uma representação global de um produto de construção através de uma federação de modelos parciais em alternativa a um único modelo completo (Turk 2001).

Encontrou-se, na bibliografia consultada, uma conclusão acerca da abordagem mais vantajosa a seguir na produção de formatos padrão. O autor, embora alerte para a necessidade de avaliar cada caso separadamente, sintetiza da seguinte forma as conclusões reunidas após a análise de um conjunto significativo de esforços de desenvolvimento de formatos padrão em áreas distintas:

''
<nowiki>[…] Formatos padrão </nowiki> bem sucedidos
<nowiki> começam pequenos e crescem com um consenso em torno de um núcleo central. […] A [conclusão acerca da abordagem ao desenvolvimento] que emerge da comunidade de especialistas em </nowiki> standards reflecte as seguintes lições: reunir um conjunto restrito de fornecedores, redigir uma especificação curta e simples que cubra os aspectos importantes, omitir os aspectos não fundamentais, prever eventuais expansões ou contracções da especificação, identificar oportunidades para a testar no mundo real e lançá-la tão cedo quanto for possível.'' (Libicki 1995)

==Modelos completos e modelos parciais: Tabela resumo==

Segue-se uma tabela que resume o conteúdo do presente subcapítulo:

<div align=center>
'''Tabela  – Modelos completos e parciais (síntese)'''

<table class=MsoNormalTable border=1 cellspacing=0 cellpadding=0
style='border-collapse:collapse;border:none'>

<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border-top:solid black 1.5pt;
border-left:none;border-bottom:solid black 1.0pt;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'><i>&nbsp;</i></p>
</td>
<td width=216 valign=top style='width:162.0pt;border-top:solid black 1.5pt;
border-left:none;border-bottom:solid black 1.0pt;border-right:none;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'><i>Modelo
Completo</i></p>
</td>
<td width=216 valign=top style='width:162.0pt;border-top:solid black 1.5pt;
border-left:none;border-bottom:solid black 1.0pt;border-right:none;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'><i>Modelo
Parcial</i></p>
</td>
</tr>

<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border:none;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Objectivo</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Pretende
vir a constituir um formato padrão</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Visa dar
resposta a um ou mais problemas específicos</p>
</td>
</tr>
<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border:none;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Dimensão</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Modelo
detalhado e completo</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Modelo
constituído por um conjunto limitado de regras de representação, pelo menos
na fase inicial</p>
</td>
</tr>
<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border:none;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Interoperabilidade</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Âmbito
alargado do modelo permite que seja usado para a partilha de informação entre
sistemas com diferentes finalidades</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Interoperabilidade
pode ser garantida por uma federação de modelos, não por um modelo único</p>
</td>
</tr>
<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border:none;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Abordagem
ao desenvolvimento</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Abordagem
estruturalista do tipo <i>top-down</i></p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Abordagem
minimalista do tipo <i>bottom-up</i></p>
</td>
</tr>
<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border:none;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Intervenientes
no processo de desenvolvimento</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Equipa
restrita centraliza desenvolvimento</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Disseminação
de equipas de desenvolvimento</p>
</td>
</tr>
<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border:none;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Envolvimento
da comunidade de utilizadores</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Aplicações
práticas do modelo só são possíveis depois de este ter atingido um grau de
desenvolvimento significativo. Comunidade de utilizadores tem um impacto
reduzido no desenvolvimento.</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Modelo
avança por processo iterativo. Validação empírica do modelo por parte de
comunidade de utilizadores condiciona desenvolvimento de sucessivas versões.</p>
</td>
</tr>
<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border:none;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Adopção</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Demorada</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Adopção
ou extinção rápidas</p>
</td>
</tr>
<tr style='page-break-inside:avoid'>
<td width=132 valign=top style='width:98.8pt;border-top:none;border-left:
none;border-bottom:solid black 1.5pt;border-right:solid black 1.0pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>Exemplos</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;border-bottom:solid black 1.5pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'>ISO-STEP,
IFC</p>
</td>
<td width=216 valign=top style='width:162.0pt;border:none;border-bottom:solid black 1.5pt;
padding:0cm 5.4pt 0cm 5.4pt'>
<p class=MsoNormal style='line-height:normal;page-break-after:avoid'><span
lang=EN-US>TCP/IP, HTML, XML, SQL, C</span></p>
</td>
</tr>
</table>

<references/>

[[Categoria:Gestão da Informação]]
[[Categoria:BIM]]