O desenvolvimento de um aplicativo de verificação de requisitos através do Revit API Silvia Maria Soares de Araujo Pereira Fundação Oswaldo Cruz / Universidade Federal Fluminense Sergio Roberto Leusin de Amorim - GDP Gerenciamento e Desenvolvimento de Projetos Ltda. / Universidade Federal Fluminense Apresentação do processo de desenvolvimento do aplicativo para a verificação de alguns requisitos de projeto, utilizando filtros e banco de dados modelados segundo as regras de negócio estabelecidas para o programa de necessidades de arquitetura de um biotério. Objetivo de aprendizado Ao final desta palestra você terá condições de: Verificar a função dos filtros no aplicativo; Verificar a formulação das regras de negócio propostas para o aplicativo, segundo o programa de necessidades; Verificar a modelagem do banco de dados do aplicativo; Verificar o diagrama de classes proposto para o aplicativo; Verificar o funcionamento do aplicativo, através de um exemplo. Sobre os Palestrantes Silvia Maria Soares de Araujo Pereira Arquiteta e Urbanista formada pela Faculdade de Arquitetura e Urbanismo - Universidade Federal do Rio de Janeiro (2001). Mestre em Engenharia Civil pela Universidade Federal Fluminense (2004). Doutoranda em Engenharia Civil pela Universidade Federal Fluminense (tese defendida e aprovada em 11 de junho de 2014, cujo título é "A contribuição do BIM no processo de projeto de arquitetura - uma aplicação ao projeto de biotérios"), para o qual desenvolveu o aplicativo VeR_Arq_Bio, para o Revit 2013, que realiza a verificação automática de alguns requisitos em um projeto de arquitetura de biotério. Contato: silviaraujo@hotmail.com Sergio Roberto Leusin de Amorim Sócio gerente da GDP - Gerenciamento e Desenvolvimento de Projetos (www.gdp.arq.br), empresa dedicada ao desenvolvimento de projetos e gerenciamento de obras com uso de tecnologia BIM, onde já coordenou diversos projetos nesta tecnologia. Anteriormente foi sócio gerente da PAAL Projeto Arquitetos Associados, onde foi responsável por dezenas de projetos metroviários, de laboratórios e imobiliários. Professor Titular aposentado da Universidade Federal Fluminense. Doutor em Engenharia de Produção, pela COPPE UFRJ, com estágio no LATTS, École des Ponts et Chaussées, Paris. M.Sc. Pela COPPE UFRJ e arquiteto pela FAU UFRJ, 1974. Participante da CE 02 138 15 - Coordenação Modular para Edificações e da ABNT/CEE-134 - Modelagem de Informação da Construção, onde vem colaborando na elaboração de normas para Construção e em particular para a utilização do BIM Sócio fundador do Clube da Qualidade na Construção RJ, do SINDUSCON RIO, onde desenvolveu diversos projetos na área de gestão da qualidade em cooperação com empresas da área imobiliária. Consultor da CAPES, CNPq, FINEP, MDIC, FIESP, ABDI, da CAIXA ECONÔMICA FEDERAL, para os quais desenvolveu estudos setoriais, procedimentos de avaliação de sistemas tecnológicos inovadores e diversas consultorias sobre o tema da inovação. Currículo Lattes: http://lattes.cnpq.br/9035911586504341 Contato: sergio.leusin@gdp.arq.br
INTRODUÇÃO O objetivo deste trabalho é apresentar o desenvolvimento de uma ferramenta o VeR_Arq_Bio - que funciona internamente ao Revit, em sua versão 2013 e, com ela, reduzir a necessidade de exportação para outros softwares. O Revit API (Application Programming Interface) é a interface pela qual um programador pode se comunicar com o núcleo do software, através de bibliotecas disponibilizadas pela empresa que o comercializa, neste caso, a Autodesk. Utilizou-se para tal, a modelagem de um banco de dados com todos os itens a serem comparados em um projeto, além da modelagem das relações ou regras de negócio entre os itens a serem verificados. O processo de projeto de arquitetura de biotérios envolve diversas fases, requisitos específicos e, por tratar-se de um programa arquitetônico complexo, a ideia de se utilizar o VeR_Arq_Bio é de aumentar o controle nos arranjos de fluxos, a fim de se atender aos requisitos legais e de biossegurança, criando-se um padrão para verificação e validação nas fases mais técnicas deste processo. Pode-se, assim, sistematizar parte do processo de projeto, automatizando-se etapas de verificação e de documentação das tomadas de decisão. O APLICATIVO VERIFICADOR DE REQUISITOS: VER_ARQ_BIO Filtros O desenvolvimento do aplicativo iniciou-se pela programação em C# dos filtros. Utilizou-se para tal, o Visual Studio 1 em sua versão 2010. A programação (código) destes filtros baseou-se nos exemplos de códigos que há no Revit SDK 2013\Software Development Kit\Samples. Os filtros funcionam como um visualizador dos dados de projetos que serão verificados, comparados com um banco de dados. Foram utilizados quatro filtros para estas informações, a saber: informações do projeto, ambientes, equipamentos e conexões. Após a aplicação destes filtros, para que as informações possam ser verificadas, foram modeladas as regras de negócio 2. Assim, as informações extraídas do projeto são comparadas com as informações armazenadas em um banco de dados, segundo estas regras de negócio. Regras de Negócio Ambientes Com as regras para ambientes, serão verificados os nomes, as áreas mínimas, as alturas mínimas por ambiente, além dos materiais de acabamento para piso, parede e forro. Se houver algum desacordo ou ausência de informação para o ambiente projetado, o 1 O Visual Studio é um conjunto abrangente de ferramentas e serviços de criação de aplicativos para a plataforma Microsoft e também para outras plataformas. 2 Regras de negócio representam um importante conceito dentro do processo de definição de requisitos para sistemas de informação e devem ser vistas como uma declaração genérica sobre a organização (LEITE E LEONARDI, 1998 apud DALLAVALLE, 2000). 2
aplicativo acusará o erro através de caixa de diálogo, com texto explicativo. Estas informações serão salvas em arquivo de texto externo ao Revit. As áreas e altura dos compartimentos são sempre consideradas as mínimas e algumas delas serão determinadas em função do número de trabalhadores / usuários dos espaços, em função do tipo e quantidade de animal criado / mantido ou em função de outras áreas, como é o caso dos corredores descontaminados e não descontaminados. Cada ambiente poderá conter apenas os materiais de piso, parede e teto relacionados a ele, com base em uma lista de materiais mais usuais em biotérios. Equipamentos Com as regras de negócio para equipamentos, serão verificados os equipamentos e suas devidas localizações, levando-se em consideração o nível de biossegurança, e se são equipamentos obrigatórios (O) ou simplesmente recomendados (R). Cada ambiente poderá conter apenas os equipamentos relacionados a ele, sendo alguns obrigatórios e outros recomendados, dependendo do nível de biossegurança. Conexões Com as regras para conexões apresentadas, é possível verificar o fluxograma para o projeto de biotério. Isto porque, através do filtro de portas, tem-se a informação de que ambiente para qual ambiente a conexão é estabelecida por cada porta (porta.fromroom, porta.toroom) e assim comparada ao banco de dados modelado com estas regras de negócio. Cada departamento poderá se conectar a outros departamentos ou ao exterior, estabelecendo uma relação de proximidade. Cada compartimento poderá se conectar a outros compartimentos ou ao exterior, segundo as restrições apresentadas nos quadros referentes a cada departamento. Modelagem do Banco de Dados Depois das regras de negócio estabelecidas, as diversas tabelas resultantes desta ação foram levadas para o banco de dados, e tais informações foram então modeladas no Sql Server Express, dentro do Visual Studio. Ambientes A Figura 1 e a Figura 2 apresentam os dados de ambientes e de materiais para exemplificar o inter-relacionamento entre eles. Há a tabela com os diversos ambientes, cada qual com o seu identificador - ID. Da mesma forma, há a tabela de materiais. Interessante observar que, para cada material, há um hospedeiro, que pode ser piso, parede ou forro. O material pode se repetir, porém o ID é único, variando de acordo com o hospedeiro. Nota-se que há 366 combinações entre ambientes e materiais, como apresenta a Figura 2. 3
Figura 1 - Tabelas do arquivo de banco de dados - BioterioDB - com os itens de ambientes e de materiais. 4
Figura 2 - Tabela de inter-relacionamento entre ambientes e materiais. Equipamentos A Figura 3 e a Figura 4 apresentam os dados de equipamentos e de biossegurança para exemplificar o inter-relacionamento entre eles. Há a tabela com os equipamentos, cada qual com o seu identificador - ID. Da mesma forma, há a tabela com os níveis de biossegurança. Para um dado ambiente, há a obrigatoriedade ou a recomendação de um equipamento dependendo do nível de biossegurança. 5
Figura 3 - Tabelas do arquivo de banco de dados - BioterioDB - com os itens de equipamentos e de biossegurança. 6
Figura 4 - Tabela de inter-relacionamento entre ambientes, equipamentos e biossegurança. Conexões A Figura 5 apresenta os dados de ambientes para exemplificar o interrelacionamento entre eles, a fim de verificar o correto arranjo de fluxos. Ao filtrar as portas, é possível filtrar a informação de qual ambiente e para qual ambiente está a porta. Assim, é possível verificar se é correta ou não a conexão entre dois ambientes. 7
Figura 5 - Tabela do arquivo de banco de dados - BioterioDB - com os ambientes e seu interrelacionamento. Diagrama de classes Em programação orientada a objeto, uma classe é simplesmente uma representação de um tipo de objeto. Trata-se de uma estrutura que descreve o objeto. Assim como uma planta baixa de um projeto pode ser usada para criar diversas construções, uma única classe pode ser usada para criar quantos objetos forem necessários (MICROSOFT, 2014). Todos os objetos têm propriedades que descrevem seus atributos, que definem suas ações, métodos e eventos que definem suas respostas. Da mesma forma, a classe que define um objeto tem suas próprias propriedades, métodos e eventos (às vezes chamados membros) que são passados adiante para todas as instâncias de classe (MICROSOFT, 2014). No aplicativo em questão, as classes são separadas por funções e possuem uma relação de dependência entre elas, conforme apresentado no diagrama de classes do aplicativo (Figura 6). 8
Figura 6 Diagrama de classes do aplicativo. A classe AdskApplication é uma classe padrão do template do Revit API e permite a inclusão dos botões das novas funcionalidades / ferramentas na Ribbon Pannel do Revit. 9
As classes seguintes, CmdInformProj, CmdRooms, CmdEquipRooms e CmdPortasNivel, vincularão a seleção dos novos botões às aparições dos respectivos formulários. Ou seja, ao selecionar o novo botão de Informações do Projeto no Revit, aparecerá o formulário de Informações do Projeto, cuja classe é projectinformationform. Ao selecionar o botão Ambiente, aparecerá o formulário de Ambientes e Departamentos, cuja classe é roomsinformationform. Ao selecionar o botão Equipamentos, aparecerá o formulário de Equipamentos, cuja classe é equipmentsinformationform. E, ao selecionar o botão Conexões, aparecerá o formulário de Portas, cuja classe é doorsinformationform. As classes RoomsData, EquipData e DoorsData são responsáveis pelo preenchimento das informações em seus respectivos formulários com os dados de projeto, completando a função de filtro das informações para posterior comparação com o banco de dados. A classe AccessBase é responsável pelo acesso ao banco de dados e pelo retorno do comparativo ao usuário. As classes RetQueryAmbiente, RetQueryEquipamento e RetQueryConector são responsáveis pelos comparativos entre os dados de projeto e as informações armazenadas no banco de dados. O funcionamento Conforme mencionado, o plug-in VeR_ARQ_BIO irá aparecer na barra de ferramentas do Revit, em sua versão 2013, após o desenvolvimento do código em C#. Ao selecioná-lo, as opções dos filtros aparecem: Informações do Projeto, Ambientes, Equipamentos e Conexões, conforme apresenta a Figura 7. Figura 7 O novo plug-in na barra de ferramentas do Revit e as opções de filtros para a verificação das informações. Ao selecionar o filtro Ambientes, uma nova janela se abre com as informações dos ambientes e dos departamentos existentes no projeto. Ao selecionar um ambiente ou vários ambientes pelo ID (Figura 8), é possível realizar a verificação da adequação destas informações, pois as mesmas são comparadas às informações cadastradas no banco de dados, segundo as regras de negócio já estabelecidas. 10
Figura 8 Filtro Ambientes. A Figura 9 é um exemplo da caixa de texto que apresenta a verificação dos requisitos para os ambientes selecionados. Neste exemplo, os ambientes selecionados foram a Sala de Animais e a Sala de Procedimentos. Figura 9 Verificação de requisitos para os ambientes selecionados. Nota-se que, pelo comparativo com o banco de dados, o volume para a Sala de Animais, como não foi calculado e apresenta-se no projeto como 0 m³ é, portanto, inválido. Todos os outros requisitos verificados estão válidos (área, altura e materiais). Já para a Sala de 11
Procedimentos, há três requisitos inválidos: o volume, que, como o da Sala de Animais, não foi calculado; o material de piso (carpete é inválido como material de piso na Sala de Procedimentos), que constitui um erro forçado para fazer a demonstração do aplicativo; e a área, que com base no projeto original, encontra-se inferior à mínima. Este último constitui um tipo de erro de projeto de grande impacto para a sua correção e que, quanto antes for identificado, melhor para toda a equipe envolvida no processo de projeto. Após fechar esta caixa de texto (janela), aparecerá a mensagem de que um arquivo de texto, contendo estas informações, é criado e salvo no local indicado, conforme a Figura 10. Figura 10 Indicação da criação de um arquivo texto contendo as informações da verificação de requisitos realizada. CONSIDERAÇÕES FINAIS Com este trabalho, é possível demonstrar que a customização de ferramentas de projeto, neste caso, permitida pela tecnologia BIM e pela API do Revit (parametrização / modelagem orientada a objetos) pode contribuir fortemente para a melhoria do desempenho do processo de projeto através do aumento da qualidade do projeto e do aumento do fluxo e do controle da informação. Além disso, com esta ferramenta, espera-se evitar possível perda de informações (falhas no intercâmbio do modelo entre os softwares - interoperabilidade), eliminar uma das etapas do processo de projeto (transporte do modelo de um software a outro) e reduzir a necessidade de adquirir / operar outro software no processo de desenvolvimento do projeto. E espera-se que com o desenvolvimento do plug-in, outras verificações possam ser programadas e novos bancos de dados sejam modelados tanto para outras verificações em projetos de biotérios, como para outros tipos de programas arquitetônicos, como hospitais e escolas, por exemplo. REFERENCIAS BIBLIOGRÁFICAS DALLAVALLE, Silvia Inês; CAZARINI, Edson Walmir. Regras do Negócio, um fator chave de sucesso no processo de desenvolvimento de Sistemas de Informação. 2000. Disponível em: <http://www.abepro.org.br/biblioteca/enegep2000>. Acesso em: 06 mai. 2014. MICROSOFT CORPORATION. 20483B - Programming in C#. Official Microsoft Learning Products, 2012. 12