5.3
Integra¸c˜ao entre os Componentes do Sistema
Separadamente, todos os m´odulos e tecnologias discutidas anteriormente n˜ao fazem nenhum sentido para o sistema, sendo assim ´e preciso criar uma estrutura l´ogica para fazer com que essas tecnologias e m´odulos “conversem entre s´ı”. Considerando a dimens˜ao do projeto e a diversidade de componentes agregados para a sua constitui¸c˜ao, o sistema foi desenvolvido obedecendo aos paradigmas de orienta¸c˜ao a objetos e programa¸c˜ao gen´erica, sendo que quando poss´ıvel tamb´em foram utilizados padr˜oes de projeto.
5.3.1
Programa¸c˜ao Orientada a Objetos
A programa¸c˜ao orientada a objetos j´a pode ser considerada uma tecnologia madura e bem estabelecida, cujos conceitos tˆem sido estudados desde o final da d´ecada de 60. Em particular nos ´ultimos dez anos tˆem surgido muitas metodologias e estudos visando potencializar o seu uso, al´em de um consider´avel crescimento na utiliza¸c˜ao e aceita¸c˜ao dessa tecnologia em toda a ind´ustria de software, de tal forma que a mesma pode ser encontrada em grandes ´areas, como: banco de dados, redes, internet e interfaces gr´aficas com o usu´ario (O’DOCHERTY, 2005; SINTES, 2002).
A programa¸c˜ao orientada a objetos oferece um mecanismo poderoso para se lidar com a complexidade de um projeto computacional, fornecendo ferramentas para tornar os programas mais claros, seguros e favorecendo a manuten¸c˜ao destes. Ainda, esta ´e par- ticularmente conveniente para o desenvolvimento de aplica¸c˜oes gr´aficas de uma maneira geral. Isto porque, componentes desses programas podem ser implementados na forma de objetos intuitivos (O’DOCHERTY, 2005). Por exemplo, um ponto ou segmento de reta po- dem ser realizados de forma direta, como componentes gr´aficos que possuem dados como posi¸c˜ao, tamanho e cores, assim como, m´etodos para mudar os seus valores e para exibir o componente em si, n˜ao existindo uma separa¸c˜ao entre os dados e os m´etodos ou fun¸c˜oes que fazem algum tipo de processamento sobre os mesmos.
Como pode ser observado nas Se¸c˜oes 5.4, 5.5, 5.6 e 5.7, foram utilizados extensiva- mente os conceitos de heran¸ca e polimorfismo da programa¸c˜ao orientada a objetos no desenvolvimento do sistema proposto.
5.3 Integra¸c˜ao entre os Componentes do Sistema 87
5.3.2
Programa¸c˜ao Gen´erica
Apesar da orienta¸c˜ao a objetos fornecer ferramentas para se lidar com toda a com- plexidade relacionada ao desenvolvimento de software, em alguns casos n˜ao ´e vantajoso o acoplamento entre os algoritmos e estruturas de dados fornecido pelo desenvolvimento de software orientado a objetos. Por exemplo, segundo Vinhas et al. (2002), no desen- volvimento de software SIG, um grande n´umero de algoritmos n˜ao dependem da imple- menta¸c˜ao de uma estrutura de dados em particular, mas apenas de algumas propriedades semˆanticas fundamentais destas como a habilidade de ir de um elemento da estrutura ao pr´oximo ou de comparar dois elementos. Por isso o desenvolvimento de SIG pode ser melhorado atrav´es da combina¸c˜ao da id´eia das t´ecnicas de orienta¸c˜ao a objeto com o paradigma de programa¸c˜ao gen´erica.
De acordo com Pirkelbauer et al. (2008), a programa¸c˜ao gen´erica tem se consolidado como uma importante ferramenta no desenvolvimento de bibliotecas de software com alto grau de eficiˆencia e reusabilidade isto porque, a programa¸c˜ao gen´erica ´e voltada para a constru¸c˜ao de algoritmos que independem de um determinado tipo ou estrutura de dados e que sejam t˜ao eficientes (com rela¸c˜ao a velocidade de execu¸c˜ao e utiliza¸c˜ao de recursos) quanto, a implementa¸c˜ao desses mesmos algoritmos acoplados a determinados tipos ou estruturas de dados (VINHAS et al., 2002).
No desenvolvimento do sistema proposto, foi efetuado o uso da programa¸c˜ao gen´erica no desenvolvimento da funcionalidade de agrega¸c˜ao de dados do usu´ario no componente de software respons´avel pela cria¸c˜ao e manuten¸c˜ao de TINs (vide Se¸c˜ao 5.4.2 na p´agina 96).
5.3.3
Padr˜oes de Projeto
O desenvolvimento de software orientado a objetos ´e uma tarefa dif´ıcil, o software orientado a objetos reutiliz´avel ´e mais dif´ıcil ainda. Sendo assim, tendo por objetivo conseguir um maior aproveitamento desse paradigma de programa¸c˜ao tamb´em foram uti- lizados alguns padr˜oes de projeto no desenvolvimento do sistema proposto.
Padr˜oes de projeto provˆeem solu¸c˜oes elegantes, de f´acil reuso e manuten¸c˜ao, para problemas comuns da ´area de programa¸c˜ao. A seguir s˜ao dadas algumas defini¸c˜oes para o termo padr˜ao de projetos (BUCHMANN et al., 1996;GAMMA et al., 1998; LASATER, 2007):
• “S˜ao solu¸c˜oes recorrentes para problemas que ocorrem com maior frequˆencia na ´area da programa¸c˜ao”;
5.3 Integra¸c˜ao entre os Componentes do Sistema 88
• “Conjunto de regras descrevendo como completar determinadas tarefas na ´area de desenvolvimento de software”;
• “Identificam e especificam abstra¸c˜oes que est˜ao acima do n´ıvel de classes e instˆancia, ou componentes”.
Dentro do contexto da programa¸c˜ao orientada a objetos, o uso de padr˜oes de pro- jeto n˜ao apenas auxilia na identifica¸c˜ao e especifica¸c˜ao de objetos ´uteis na solu¸c˜ao de determinados problemas como tamb´em oferece solu¸c˜oes para o gerenciamento da comu- nica¸c˜ao entre objetos, e metodologias para o desenvolvimento de software visando a sua extensibilidade (futuras mudan¸cas no c´odigo n˜ao devem afetar partes j´a resolvidas). Mais especificamente, os padr˜oes de projetos podem ser divididos em trˆes categorias: criacio- nais, estruturais e comportamentais.
Padr˜oes Criacionais: contˆem indica¸c˜oes sobre a melhor maneira (melhores lugares e qual a ordem) de se criar instˆancias de um objeto em sistemas de software complexos.
Padr˜oes estruturais: contˆem descri¸c˜oes de como ferramentas da orienta¸c˜ao a objetos (como heran¸ca e polimorfismo) podem ser utilizadas na cria¸c˜ao de estruturas mai- ores a partir da combina¸c˜ao de classes e objetos. Por exemplo, como combinar as estruturas de dados e algoritmos fornecidos pela CGAL e pela STL na cria¸c˜ao do modelo computacional que consiga representar a superf´ıcie de um terreno usando TIN (como os dados ser˜ao guardados ou compartilhados por essas estruturas).
Padr˜oes Comportamentais: se preocupam e modelar a troca de informa¸c˜oes entre
objetos. Por exemplo, se o usu´ario clicar com ou mouse sobre uma tela do sistema, qual componente de software ser´a respons´avel por capturar esse evento, quem ser´a respons´avel por processar esse evento, ou seja, como os diferentes componentes do m´odulo de visualiza¸c˜ao do sistema (Qt, o OSG e o OpenGL) ir˜ao se comportar (interagir entre si) mediante os eventos gerados pelo usu´ario.
Resumindo, padr˜oes de projeto resolvem muitos problemas que programadores ori- entados a objeto podem se deparar por representar uma experiˆencia coletiva de boas pr´aticas de programa¸c˜ao e resolu¸c˜ao de determinados problemas recorrentes da ´area de desenvolvimento e projeto de software, permitido a estes aprenderem com o sucesso de outros programadores ao inv´es de com seus pr´oprios fracassos.
No presente trabalho foram utilizados os seguintes padr˜oes de projeto no desenvolvi- mento do sistema proposto:
5.3 Integra¸c˜ao entre os Componentes do Sistema 89
• Padr˜ao de Projeto Iterador (Iterator ): esse padr˜ao de projeto foi utilizado no acesso ao conjunto de v´ertices, arestas e faces contidos na estrutura de dados res- pons´avel pela representa¸c˜ao computacional do TIN, e tamb´em no acesso aos dados (nesse caso pontos com coordenadas (x, y, z)) de superf´ıcies contidos em arquivos em disco. A Se¸c˜ao 5.4.4 contem uma descri¸c˜ao mais detalhada desse padr˜ao de projeto e de como ele est´a inserido no sistema desenvolvido.
• Padr˜ao de Projeto Factory : esse padr˜ao de projeto foi utilizado no desenvol- vimento do m´odulo de software respons´avel pela leitura de diferentes formatos de arquivos raster e vetorial pelo sistema. Uma melhor descri¸c˜ao desse padr˜ao e o seu uso ´e dado na Se¸c˜ao 5.5.1.
Al´em dos padr˜oes de projeto citados acima, tamb´em foram utilizados os seguintes conceitos durante o desenvolvimento do sistema:
• Handler: o conceito de handler foi utilizado no acesso individual aos elementos v´ertices, aresta e faces armazenados na estrutura de dados utilizada na represen- ta¸c˜ao computacional do TIN. S˜ao dados mais detalhes sobre esse conceito e a sua utiliza¸c˜ao na Se¸c˜ao 5.4.3.
• Circuladores (Circulators): esse conceito foi utilizado na implementa¸c˜ao das classes respons´aveis pelo acesso `as rela¸c˜oes de conectividade dos v´ertices e faces do TIN representado pelo sistema. Maiores detalhes sobre esse conceito e a sua inser¸c˜ao no sistema s˜ao dados na Se¸c˜ao 5.4.5.
• M´aquina de Estado Hier´arquica (Statechart): todo o sistema de controle da
interface gr´afica do sistema desenvolvido foi criado utilizando m´aquinas de estado hier´arquicas. Na Se¸c˜ao 5.7 ´e dada uma melhor descri¸c˜ao desse conceito e a sua inser¸c˜ao no sistema.