İnşaat Mühendisliğinde Bentonit Kullanımı ve Bazı Özellikleri

Foram gastas aproximadamente nove horas para obter o c´odigo final do SARB (duas horas na an´alise, uma hora no mapeamento, quatro horas na implementac¸˜ao e duas horas em testes). Cerca de mil e seiscentas LOC foram produzidas para adaptar o GREN a esse exemplo espec´ıfico. Esses n´umeros s˜ao pequenos se for considerado o n´umero de Pontos por Func¸˜ao (PF) (Albrecht, 1984; Jones, 1991) do sistema resultante, que ´e de aproximadamente 370 (foi utilizado um fator de 0.9 para calcular o PF). Para obter a mesma funcionalidade programando esta aplicac¸˜ao do nada seriam exigidas, no m´ınimo, cinco vezes mais linhas de c´odigo do que foram necess´arias usando o GREN, considerando que a linguagem Smalltalk requer vinte e uma linhas de c´odigo por ponto por func¸˜ao (Jones, 1989). Al´em do mais, a maioria do c´odigo adicionado consiste de m´etodos para lidar com os novos atributos adicionados `as classes, que n˜ao faziam parte dos padr˜oes. Por exemplo, para cada novo atributo da classe Cidad˜ao existem m´etodos para atribuir, recuperar e inicializar o objeto, al´em do c´odigo na classe da camada GUI para permitir sua edic¸˜ao nos formul´arios de entrada de dados. Ainda, parte do c´odigo ´e gerado automaticamente por programac¸˜ao visual. Isso ocorre para os formul´arios da GUI que foram adaptados ao SARB, por exemplo, por meio da mudanc¸a de alguns campos de entrada para o local apropriado. Portanto, o c´odigo que deve ser

4.6 Considerac¸˜oes Finais 83 criado ´e bem mais simples do que o c´odigo de uma aplicac¸˜ao convencional, na qual deve-se tratar da implementac¸˜ao de todas as regras de neg´ocio do dom´ınio.

4.6

Considerac¸ ˜oes Finais

Este Cap´ıtulo apresentou em detalhes o processo de construc¸˜ao de um framework caixa branca com base em uma linguagem de padr˜oes para um dom´ınio espec´ıfico. Para exemplificar esse processo apresentou-se o framework GREN, que foi constru´ıdo com base na linguagem de padr˜oes GRN. Definiu-se ent˜ao um processo para instanciac¸˜ao de um framework caixa branca usando a linguagem de padr˜oes correspondente. Esse outro processo tamb´em foi ilustrado usando o GREN e a GRN.

Os processos propostos fornecem uma forma sistem´atica de construir e instanciar um fra- mework, facilitando seu reuso por meio de uma linguagem de padr˜oes que guia a criac¸˜ao de novas aplicac¸˜oes no dom´ınio. A linguagem de padr˜oes ´e usada durante todo o processo de construc¸˜ao do framework, desde sua concepc¸˜ao e identificac¸˜ao da flexibilidade desejada, at´e sua validac¸˜ao e documentac¸˜ao. Ainda que trabalhosa, a instanciac¸˜ao do framework para sistemas espec´ıficos po- der´a ser feita com o m´ınimo de conhecimento sobre o framework e a linguagem de programac¸˜ao na qual ele est´a escrito, pois a documentac¸˜ao sugerida no processo proposto possui o mapeamento dos padr˜oes de an´alise pertencentes `a linguagem de padr˜oes para as classes e m´etodos do framework que devem ser adaptados para obter a aplicac¸˜ao resultante. Assim, sabendo-se quais padr˜oes fo- ram aplicados, pode-se consultar essa documentac¸˜ao para saber exatamente o que deve ser feito no framework para obter o c´odigo da aplicac¸˜ao final desejada.

Conforme descrito na sec¸˜ao 3.5.6, a GRN foi utilizada para modelar o sub-sistema de controle de preju´ızos causados pelos buracos, mesmo n˜ao abrangendo essa funcionalidade. Isso foi feito considerando-se apenas a sintaxe dos padr˜oes, ao inv´es de sua semˆantica. Da mesma forma, o GREN pˆode ser usado para implementar esse sub-sistema, bastando para isso seguir o cookbook

normalmente, como se faz para os padr˜oes cuja semˆantica est´a de acordo com o dom´ınio coberto. Esse fato confirma a afirmac¸˜ao de Johnson (1992), de que “um bom framework ser´a utilizado de maneiras jamais concebidas por seus projetistas”. O sistema resultante comportou-se de forma satisfat´oria ap´os esse uso mais flex´ıvel, evitando que se programasse a partir do zero essa parte da funcionalidade.

O pr´oximo cap´ıtulo descreve detalhadamente o processo de desenvolvimento de uma ferra- menta (em ingˆeswizard) para automatizar a instanciac¸˜ao do framework caixa-branca com base na

linguagem de padr˜oes correspondente (passo 3 da Figura 8.1). Descreve tamb´em o processo de instanciac¸˜ao do framework usando essewizard, que consiste no passo 4b da Figura 8.1.

C

´

5

O Processo de Construc¸ ˜ao e Utilizac¸ ˜ao

de um Wizard baseado na Linguagem

de Padr ˜oes

5.1

Considerac¸ ˜oes Iniciais

A dificuldade de reuso de frameworks, ou seja, sua instanciac¸˜ao para atender aos requisitos de sis- temas espec´ıficos, foi um dos fatores fundamentais para motivac¸˜ao do trabalho descrito nesta tese. O processo proposto na sec¸˜ao 4.4, de instanciac¸˜ao de frameworks com base em uma linguagem de padr˜oes, sistematiza essa tarefa e torna-a pass´ıvel de ser executada por desenvolvedores n˜ao familiarizados com a estrutura interna do framework. No entanto, tal atividade envolve trabalho repetitivo e bastante programac¸˜ao em uma linguagem espec´ıfica. Por outro lado, a sistematizac¸˜ao dessa tarefa, que se tornou vi´avel ap´os a definic¸˜ao do processo de instanciac¸˜ao, motiva a criac¸˜ao de uma ferramenta que automatize esse processo.

Assim, neste Cap´ıtulo descrevem-se dois processos: o primeiro detalhando a construc¸˜ao de um Wizard para instanciac¸˜ao do framework caixa branca e o segundo para instanciac¸˜ao do fra-

mework utilizando esseWizard. Esses processos referem-se aos passos 3 e 4b do processo geral

da Figura 8.1 e foram agrupados neste Cap´ıtulo devido ao seu relacionamento: o processo de instanciac¸˜ao definido no passo 4b atua como um manual de uso do Wizard constru´ıdo pelo pro-

5.2 Alternativas para Construc¸˜ao de umWizard 85