A norma WPS na integração do cadastro

Transcrição

1 A norma WPS na integração do cadastro Ricardo Castanheira Pereira Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Júri Presidente: Prof. José Manuel Nunes Salvador Tribolet Orientador: Prof. Mário Rui Fonseca dos Santos Gomes Co-Orientador: Prof. Bruno Emanuel da Graça Martins Vogal: Prof. José Luis Brinquete Borbinha Outubro 2009

2

3 Resumo e palavras-chave Na ausência de um cadastro nacional normalizado, várias organizações têm produzido os seus próprios cadastros. Estes trabalhos são desenvolvidos de forma dedicada à satisfação das necessidades individuais das organizações, com conteúdos, rigores posicionais e sistemas de informação diferenciados e heterogéneos. Esta dissertação aborda o cadastro urbano em Portugal, vendo-o como um problema de integração de sistemas de informação. Tal como este se encontra hoje, o cadastro, pode ser melhorado usando as mais recentes tecnologias relacionadas com Web Services e com a orquestração de Web Services (e.g. a norma Business Process Execution Language). Por o cadastro exigir uma forte componente geográca, estes serviços têm de ser capazes de lidar com informação geográca. Um dos objectivos do trabalho consiste em averiguar se a recente norma Web Processing Service (WPS), lançada pelo Open Geospatial Consortium (OGC), pode ajudar a resolver alguns dos problemas de integração dos sistemas envolvidos no cadastro urbano em Portugal. Com base numa metodologia de desenvolvimento orientada a serviços foi desenvolvida uma arquitectura contendo vários serviços web correspondentes às actividades desenvolvidas por cada uma das principais entidades envolvidas nos processos de gestão do cadastro urbano em Portugal. Foi ainda desenvolvido um serviços Web orquestrador, responsável pela execução de processos, tendo sido testadas as tecnologias WPS e BPEL. Esta arquitectura visa actuar como prova de conceito da facilidade de desenvolvimento que a plataforma de serviços potencia, mostrando a aplicabilidade deste tipo de arquitecturas ao problema do cadastro. Palavras-chave: Sistemas de Informação Geográca, WPS, OGC, Sistemas de Informação Cadastral, Sistemas de Informação Integrados, BPEL

4 Abstract and Keywords Without a national standardized cadastral record, several organizations have produced their own cadastral records. These, were developed and dedicated to the individual organization's needs with dierentiated and heterogeneous information systems. This thesis deals with urban cadastre in Portugal, seeing it has an integration systems problem. As it is today, the cadastre can be improved using the recent technologies related with Web services and with Web Services orchestrations (e.g. Business Process Execution Language). The urban cadastre requires a strong geographical component, for this reason, these services must be able to deal with spatial information. One of the objectives of this work is to investigate the recent standard Web Processing Service (WPS), launched by the Open Geospatial Consortium (OGC), and evaluate if it can help to solve some of the integration problems existing in the systems involved. It was developed a service-oriented architecture containing various web services related to the activities of each entity involved in the management of the urban cadastre processes in Portugal. It was also developed a web service orchestrator, responsible for executing the processes and has been tested the WPS and BPEL technologies. This architecture is intended to act as a proof of concept of the ease of development that this platform provides, demonstrating the applicability of these architectures to the urban cadastre problem. Keywords: Geographic Information Systems, WPS, OGC, Cadastral Information Systems, Information Systems Integrated, BPEL

5 Agradecimentos Esta dissertação traduz o atingir de uma meta, marcada por dedicação e esforço, mas que sobretudo me proporcionou muitas experiências, aprendizagens e alegrias. Como tal, não posso deixar de agradecer às pessoas que, mais do que terem tornado este momento possível, zeram com que o caminho percorrido valesse totalmente a pena. Em particular, o meu agradecimento especial aos Professores Mário Rui Gomes e Bruno Martins e também à Jacinta Almeida, com quem tive a oportunidade de colaborar ao longo do último ano, e cujos conselhos e orientações me foram fundamentais na concretização deste objectivo. A sua dedicação, disponibilidade e incentivo foram, sem dúvida, fundamentais. Agradeço, também, aos meus amigos e família, cujos trabalhos de mestrado motivaram a realização desta tese, pela oportunidade na aventura do empreendedorismo, onde muito aprendi, e, sobretudo, pela amizade. v

6 Conteúdo Resumo e palavras-chave Abstract and keywords Agradecimentos Lista de Acrónimos iii iv v xv 1 Introdução Motivação Objectivos Contribuições Organização do documento Conceitos e trabalho relacionado Sistemas de Informação Geográca Infra-estrutura de dados espaciais Normas relacionadas com serviços Web geográcos Web Services Geography Markup Language e Keyhole Markup Language Web Feature Service Web Map Service Web Processing Service Sistemas existentes de informação geográca Integração de Sistemas vi

7 Conteúdo vii Arquitecturas Orientadas a Serviços - Service Oriented Architecture s (SOAs) As formas de integração de SI Integração de processos Os Web Services na integração de SI Papel das normas para a integração de SI Business Process Execution Language Business Process Management Notation Motores de execução BPEL Microsoft BizTalk Apache ODE O Cadastro urbano Português Situação actual Iniciativas Síntese Problema Diagnóstico da situação actual Análise do problema Process Avaliar Imposto Municipal sobre Imóveis (IMI) Processo Actualizar proprietário de um imóvel Arquitectura dos processos actuais Processo Avaliar IMI Processo Actualizar Proprietário de um Imóvel Arquitectura de informação Síntese Proposta de solução Arquitectura de processos proposta Avaliar Imposto Municipal sobre Imóveis Actualizar proprietário de um imóvel Arquitectura de informação revista

8 Conteúdo viii 4.3 Síntese Arquitectura da solução Objectivos Visão geral Componentes da Arquitectura Plataforma de integração Modelo de serviços Descoberta de serviços Interface Caso de estudo Serviços Web envolvidos Serviços Implementados Web Service Câmara Web Service Finanças Web Service Conservatória Serviços Externos Orquestração de serviços Interface Síntese Avaliação Plano de testes Ambiente de execução dos testes Cenário de utilização e especicação de testes Testes de desempenho à plataforma e resultados Análise de resultados Avaliação dos processos actuais Avaliação dos processos propostos Tecnologias de comunicação de dados Concorrência no acesso aos serviços Síntese

9 Conteúdo ix 7 Conclusões e trabalho futuro Principais contribuições Trabalho futuro A Documentos 88 A.1 Modelo 1 usado actualmente pelas nanças A.2 Projecto de arquitectura A.3 Planta de implantação A.4 Planta de localização B A Screenshots de interfaces 93 B.1 Interface pedir pre-preenchimento Modelo B.2 Interface com código Postal errado e proposta de sugestão B.3 Interface pedir pré-preenchimento Modelo B.4 Interface inicial do processo Actualizar Proprietário de um Imóvel.. 95 B.5 Interface do processo Actualizar Proprietário de um Imóvel nal B.6 Interface processo Actualizar Proprietário de um Imóvel com id processo municipal errado B.7 Interface processo Actualizar Proprietário de um Imóvel com id da licença de utilização errado B.8 Interface processo Actualizar Proprietário de um Imóvel com NIP errado 98 C Testes funcionais 99 C.1 Criar um processo na Câmara C.2 Criar um Modelo C.3 Criar uma Certidão de Teor C.4 Executar processo Avaliar IMI C.5 Receber informação que o processo municipal pedido não existe na Câmara (Avaliar IMI) C.6 Envio do Modelo1 para a continuação do processo Avaliar IMI C.7 Executar processo Actualizar Dados dos Imóveis

10 Conteúdo x C.8 Receber informação que a Licença de Utilização pedida não existe no processo Actualizar Proprietário de um Imóvel C.9 Recebe informação que a Certidão de Teor não existe nas Finanças no processo Actualizar Proprietário de um Imóvel C.10 Receber informação que o Modelo 1 não existe nas Finanças no processo Actualizar Proprietário de um Imóvel C.11 Enviar Modelo1 necessário para a continuação do processo Actualizar Proprietário de um Imóvel C.12 Resultados dos testes

11 Lista de Figuras 2.1 Arquitectura WPS [8] Workow processo AS-IS: Avaliar IMI Workow processo actual: Actualizar Proprietário de um Imóvel Relacionamento entre entidades Exemplo de uma correspondência entre a aplicação do Urbanismo da Câmara e o Modelo Processo avaliar IMI proposto Actualizar proprietário de um imóvel proposta Arquitectura geral Modelo de serviços Modelo de dados do processo da Câmara Modelo de dados do Urbanismo Modelo de dados do Modelo Modelo de dados da Certidão de Teor Modelo de dados dos Dados de entrada para efectuar escritura Exemplo da utilização do serviço Yahoo Geocoder Schema contendo da planta de localização Exemplo da invocação da operação que devolve um processo na Câmara Exemplo da interface para criar um processo na Câmara Exemplo da interface de início do processo Avaliar IMI Exemplo do pré-preenchimento do Modelo A.1 Impresso Modelo 1 primeira parte xi

12 Lista de Figuras xii A.2 Impresso Modelo 1 segunda parte A.3 Exemplo de um projecto de arquitectura A.4 Exemplo de um projecto de arquitectura A.5 Exemplo de uma planta de localização B.1 Interface pedir pre-preenchimento do Modelo 1 do processo Avaliar IMI com erro de processo municipal Inexistente B.2 Interface com código Postal errado e proposta de sugestão B.3 Interface m do processo Avaliar IMI B.4 Interface inicial do processo Actualizar Proprietário de um Imóvel.. 95 B.5 Interface do processo Actualizar Proprietário de um Imóvel nal B.6 Interface processo Actualizar Proprietário de um Imóvel com id processo municipal errado B.7 Interface processo Actualizar Proprietário de um Imóvel com id da licença de utilização errado B.8 Interface processo Actualizar Proprietário de um Imóvel com NIP errado 98

13 Lista de Tabelas 3.1 Visão geral do ponto de vista processual Descrição processo AS-IS: Avaliar IMI Descrição processo AS-IS: Actualizar Proprietário de um Imóvel Entidades de Informação Entidades de Informação Deslocações no processo Avaliar IMI Deslocações no processo Actualizar Dados de Proprietário de um Imóvel Tabela comparativo dos campos preenchidos no Modelo Métricas de desempenho do processo Avaliar IMI Métricas de desempenho do processo Actualizar Proprietário de um Imóvel Tempos de invocação dos serviço com o aumento dos clientes em simultâneo para devolver um Processo Tempos de invocação dos serviço com o aumento dos clientes em simultâneo para criar o Modelo 1 nas Finanças C.1 Tabela do teste F C.2 Tabela do teste F C.3 Tabela do teste F C.4 Tabela do teste F C.5 Tabela do teste F C.6 Tabela do teste F C.7 Tabela do teste F xiii

14 Lista de Tabelas xiv C.8 Tabela do teste F C.9 Tabela do teste F C.10 Tabela do teste F C.11 Tabela do teste F C.12 Resultados dos testes funcionais

15 Lista de Acrónimos API Application Programming Interface B2B Business to Business BPMN Business Process Modeling Notation BPEL Business Process Execution Language EAI Enterprise Application Integration ESB Enterprise Service Bus GML Geography Markup Language HTML Hypertext Markup Language HTTP Hypertext Transfer Protocol IGP Instituto Geográco Português IMI Imposto Municipal do Imóvel IMT Imposto sobre as Transmissões Onerosas INSPIRE Infrastructure for Spatial Information in the European OASIS Open Standards for the information society SI Sistemas de Informação SOAP Simple Object Access Protocol SOA Service Oriented Architecture TI Tecnologias de Informação WSDL Web Service Denition Language WFS Web Feature Service WMS Web Map Service UDDI Universal Description Discovery and Integration UML Unied Modelling Language KML Keyhole Markup Language xv

16 Capítulo 1 Introdução O cadastro urbano refere-se a um registo com informação referente a uma determinada parcela de terreno. Para cada parcela de terreno, este registo deve conter dados como a localização, a forma (e.g. limites geométricos), a composição de cada edifício (caso exista sobre a parcela), a situação scal e a identicação dos direitos, ónus e encargos que recaem sobre os proprietários [4]. Vários processos relacionados com a administração pública e privados dependem de informação do cadastro urbano (e.g. gestão da oresta, ordenamento do território etc.). A gestão do cadastro urbano é hoje em dia muito rudimentar, tendo em conta as tecnologias de informação actuais. A inspiração para a realização deste trabalho surgiu após um breve contacto com o Município de Palmela, onde as limitações actuais se tornam evidentes. A ideia de estruturar um cadastro urbano moderno resvala na necessidade de compreender exactamente qual a sua verdadeira natureza e função. Conhecer bem o território é a base para qualquer forma de intervenção e desenvolvimento de projectos. Por conseguinte, o conhecimento exacto da extensão disponível a qualquer momento é de primordial importância sob qualquer ponto de vista. Actualmente, constata-se que as informações cadastrais se encontram em fontes dispersas e desactualizadas. Quem tem de fazer o transporte dos documentos entre as entidades envolvidas, é o cidadão [1]. Na ausência de um cadastro nacional, cada entidade (e.g. Câmaras municipais, Finanças, Conservatórias, etc.) teve que produzir os seus cadastros, trabalho este que foi desenvolvido de forma dedicada à 1

17 1.1. Motivação 2 satisfação das necessidades individuais das organizações e usando sistemas de informação diferenciados. A explicação para este fenómeno pode talvez ser encontrada na complexidade que caracteriza o cadastro. A procura do controlo da informação e da exibilização tornou a integração de sistemas informáticos, uma das grandes prioridades organizacionais. Por seu turno, a constante evolução das Tecnologias de Informação (TI) criou realidades tecnológicas díspares fomentando a necessidade de partilhar informação e funcionalidades entre sistemas. Para as organizações, a questão tecnológica da integração de Sistemas de Informação (SI) tornou-se cada vez mais complexa e é hoje um autêntico desao quanto à sua exibilidade, adaptabilidade, implementação, manutenção e gestão. Na verdade, torna-se imperioso desenvolver um sistema que sirva como ferramenta facilitadora de gestão e de tomada de decisões. Perante esta situação, um Sistema de Informação Geográca (SIG) apresenta-se como ferramenta fundamental de gestão do cadastro urbano. Um SIG é um sistema usado para armazenar analisar e manipular dados geográcos, ou seja, dados que representam objectos e fenómenos, em que a localização geográca é uma característica básica à informação e importante para análise. Uma das principais características de um SIG é a sua capacidade de manipular dados georefenciados e dados descritivos de forma integrada, disponibilizando-os de forma consistente para análise, consulta e tomada de decisão. Esta diversidade de informação mostra a necessidade que este tipo de sistema tem de lidar com os mais diversos tipos de fontes de dados. 1.1 Motivação Perante este cenário representante da situação actual, um desao importante consiste em analisar os dados do cadastro urbano de uma forma geoespacial pelo meio de sistemas ecientes baseados em tecnologias modernas. Já existem iniciativas que apontam no sentido de disponibilizar informação geográca através de infraestruturas de dados espaciais. Por exemplo a Infrastructure for Spatial Information in the European 1 (INSPIRE), é uma iniciativa lançada pela Comissão Europeia que 1

18 1.2. Objectivos 3 visa criar uma infra-estrutura europeia de informação geográca [14]. Em Portugal, o Sistema Nacional de Informação Geográca é o exemplo de uma infra-estrutura de dados espaciais nacional, coordenada pelo Instituto Geográco Português (IGP). Na vertente tecnológica, a recente norma Web Processing Service lançada pelo Open Geospatial Consortium 2 (OGC) pode ajudar na integração dos sistemas informáticos envolvidos no cadastro urbano. Esta norma foi desenvolvida com o intuito de facilitar o processamento de informação geográca, podendo também ser aplicada na integração de dados/serviços geográcos. No entanto esta norma não comtempla qualquer ligação com a linguagem Business Process Execution Language (BPEL), proposta pela Organization for the Advancing Open Standards for the information society 3 (OASIS), mais usada no meio empresarial, para a orquestração de Web Services). Seria interessante que se pudesse usar o melhor do WPS e do BPEL. 1.2 Objectivos Tendo em conta as considerações apresentadas anteriormente, o objectivo desta dissertação é avaliar a utilização de uma arquitectura baseada num conjunto de normas, ferramentas e tecnologias que suporte a gestão da informação associada aos processos do cadastro. Este sistema tem de estar preparado para lidar com informação de características geográcas ou não, proveniente de fontes heterogéneas, referentes a uma determinada parcela e ao seu proprietário. A hipótese que se pretende responder é se a norma WPS juntamente com a norma BPEL podem ser usadas para suportar processos do cadastro urbano, através de um SI distribuído com base numa arquitectura orientada a serviços. Os processos relacionados com o cadastro tal como se encontram actualmente, apresentam limitações. Tendo em conta a realidade tecnológica dos dias de hoje, alguns destes processos são inecientes. É objectivo deste trabalho conseguir automatizar ao máximo estes processos, tornando-os mais ecientes. De uma forma mais detalhada o trabalho tem os seguintes objectivos:

19 1.3. Contribuições 4 Fazer um levantamento dos processos actualmente envolvidos no cadastro urbano Português; Desenhar modelos de dados capazes de suportar electronicamente a informação do cadastro urbano Português; Desenvolver uma arquitectura de serviços Web para suportar alguns dos processos do cadastro urbano Português; Redesenhar alguns processos do cadastro urbano Português por forma a os optimizar; Aferir da possibilidade de utilizar a norma WPS para orquestração dos processos de cadastro, comprovando-se a compatibilidade da utilização da mesma em conjunto com a norma Business Process Execution Language (BPEL); 1.3 Contribuições Este trabalho ajudou a compreender as lacunas ou ineciências de alguns dos processos do cadastro urbano Português. Uma das contribuições foi o redesenhar destes processos, tendo por base o recurso a uma plataforma de serviços distribuída. Foi desenhada uma arquitectura tecnológica que permite tornar estes processos mais ecazes. Usando esta arquitectura o cidadão deixa de desempenhar o papel de transportador de documentos entre entidades, porque as entidades apesar de distribuídas, encontram-se integradas para resolver as necessidades quando dependem umas das outras. Foi desenvolvido um protótipo que implementa as norma WPS e tendo-se avaliado a forma de como estas normas se podem complementar na integração de serviços Web geográcos. Foi feita a divulgação do trabalho através de um artigo apresentado na Conferência da Associação Portuguesa de Sistemas de Informação (CAPSI 4 )

20 1.4. Organização do documento Organização do documento Esta dissertação encontra-se estruturada em sete capítulos. O primeiro capítulo, no qual esta secção se enquadra, introduz a problemática que é alvo de estudo no âmbito desta tese de mestrado, assim como os caminhos explorados na busca de soluções para a mesma. O segundo capítulo, referente ao estado da arte, concentra-se na apresentação dos temas chave deste trabalho, tais como os SIG, integração de sistemas e o cadastro urbano. No terceiro capítulo, são apresentados com mais detalhe dois processos associados ao cadastro urbano Português. No quarto capítulo, é apresentada uma reestruturação destes mesmos processos,tendo por base recurso a serviços Web. O quinto capítulo foca-se nas questões arquitecturais da solução proposta, denindo um modelo de serviços e os componentes da arquitectura, assim como o desenvolvimento do protótipo da solução. São também apresentadas as ferramentas tecnológicas que permitem cumprir os objectivos estabelecidos e que estão na base do protótipo desenvolvido. O sexto capítulo aborda os testes efectuados à plataforma de serviços para, no sétimo e último capítulo, se tirarem conclusões acerca dos resultados obtidos e se apresentarem caminhos futuros no desenvolvimento dos conceitos, tecnologias e metodologias discutidas neste trabalho.

21 Capítulo 2 Conceitos e trabalho relacionado Este capítulo tem como nalidade apresentar os conceitos necessários para a compreensão do contexto em que o problema abordado nesta dissertação se insere. Este trabalho aborda um problema pluridisciplinar, que agrega conhecimentos das áreas de sistemas de informação geográca, arquitecturas de software orientadas a serviços Web e ainda o cadastro urbano. Como tal, este capítulo cobrirá estas três áreas, realçando os conceitos mais importantes e apresentando o actual estado da arte. Este capítulo encontra-se organizado da seguinte forma: A Secção 2.1 foca-se nos sistemas de informação geográca. A Secção 2.2 aborda a integração de sistemas através da tecnologia dos Web Services. Finalmente, a Secção 2.3 aborda os sistemas de informação cadastral. O capítulo termina com um sumário dos conceitos mais importantes. 2.1 Sistemas de Informação Geográca Cowen deniu um Sistema de Sistema de Informação Geográca (SIG) como um sistema de apoio à decisão que envolve a integração de dados espacialmente referenciados com o objectivo de resolver um problema [5]. Por dados espacialmente referenciados, entende-se que existem associações entre os itens informacionais e entidades físicas existentes na superfície da Terra, através de uma posição num sistema de coordenadas geográcas bem denido. A multiplicidade de usos e visões possíveis aponta, para uma perspectiva multidisciplinar da sua utilização (e.g. gestão de fro- 6

22 2.1. Sistemas de Informação Geográca 7 tas ou gestão orestal) [9]. Os SIGs oferecem mecanismos para análise, gestão e representação da dimensão espacial dos fenómenos que ocorrem na supercie da terra. O cadastro urbano Português apresenta uma forte componente geográca e, como tal, precisa de um SIG que possa gerir toda a informação, seja ela de cariz geográco ou não Infra-estrutura de dados espaciais As Infra-estrutura de Dados Espaciais (IDE) são essencialmente SIGs distribuídos, podendo ainda ser denidas como um conjunto de esforços para garantir bases para descoberta, avaliação e utilização de dados espaciais 1. As IDEs tornaram-se muito importantes na determinação da forma pela qual os dados espaciais são utilizados numa organização, numa nação, ou em diferentes regiões do mundo [7]. Estas, ao partilharem os dados, fazem com que os seus utilizadores economizem recursos, tempo e esforço ao tentarem adquirir novos dados. Desta forma evita-se a duplicação de gastos associados com a geração e manutenção de dados e a sua integração com outros dados. Uma IDE baseia-se em três componentes importantes: A tecnologia (hardware, software, redes, bases de dados, planos de implementação técnica); As políticas e disposições institucionais (governança, segurança e privacidade de dados, a partilha de dados, a recuperação dos custos); As pessoas (formação prossional, desenvolvimento, a cooperação, a divulgação); Uma IDE pode então ser uma solução viável para ajudar no cadastro urbano através da integração da informação presente nas diferentes entidades envolvidas. Para que uma infra-estrutura deste tipo possa operar sem problemas de interoperabilidade, é 1

23 2.1. Sistemas de Informação Geográca 8 necessário que se adoptem normas relacionadas com serviços geográcos, presentes na secção seguinte Normas relacionadas com serviços Web geográcos A Web trouxe novas potencialidades para a publicação e exploração de informação geográca, nomeadamente em termos da sua acessibilidade. Para que o processamento de informação georeferenciada seja feito de uma forma interoperável através da Web, devem ser usadas as normas comuns. O Open Geospatial Consortium (OGC) é uma organização internacional cuja missão é desenvolver e denir normas para a interoperacionalidade de serviços, dados e aplicações geoespaciais [25]. As normas lançadas por este concórcio seguem o paradigma dos Web Services e, portanto, estão sujeitas a regras de concepção e de implementação. As regras de concepção incluem orientação a serviços, autodescrição dos serviços e operações sem estados persistentes (stateless operation). As regras de implementação endereçam outras questões relativas a interoperabilidade, incluindo a adopção de formatos de intercâmbio em XML e utilização de protocolos comuns à Internet. Entre as normas do OGC destacam-se a Geographic Markup Language (GML) e a Keyhole Markup Language (KML) para representar dados geográcos em XML (extensible Markup Language), assim como o Web Feature Service (WFS), o Web Map Service (WMS), e o Web Processing Service (WPS), respectivamente descrevendo interfaces de serviços Web para aceder a mapas, gerir informação geográca e processar informação geográca. A maior parte dos SIG comerciais ou Open Source suportam as normas do OGC Web Services Grande parte das normas lançadas pelo OGC, baseiam-se em Web Services (WS). Segundo Martínez [16], Um web service é uma aplicação que aceita solicitações de outros sistemas através da Web. O uso desta tecnologia pode fazer sentido em diferentes contextos, permitindo compatibilizar soluções díspares, através de formatos comuns de troca de informação baseados em tecnologias Web como o http e o XML

24 2.1. Sistemas de Informação Geográca 9 (e.g., o Simple Object Access Protocol (SOAP), o Web Service Denition Language (WSDL), e o Universal Description Discovery and Integration (UDDI)) [18]. O protocolo SOAP possibilita a comunicação entre serviços Web e tem a função de lidar com as mensagens de pedidos e respostas. Além da estrutura da mensagem básica, o padrão descreve como os receptores devem processar mensagens SOAP. O WSDL é um formato também baseado em XML que proporciona uma descrição de um determinado serviço Web e provê um ponto de acesso para os consumidores do serviço [22]. Uma descrição WSDL completa inclui dois tipos de informação, nomeadamente, uma interface do serviço e detalhes concretos de uma descrição do serviço, que os consumidores devem seguir para aceder ao serviço. O UDDI oferece aos consumidores de serviços Web um mecanismo para localizar os fornecedores, os serviços disponibilizados, e as informações necessárias para aceder a esses serviços. Podem ainda ser utilizadas algumas bibliotecas como por exemplo a Java XML API for Web Services (JAX WS), que pode ser vista como uma biblioteca de "chamadas remotas de procedimento" (em inglês, Remote Procedure Call(RPC)). O objectivo do RPC é permitir ao programa cliente invocar funções do programa servidor (remotas) como se fossem funções locais. Todos os aspectos de comunicação e de representação de dados são tratados pela biblioteca de RPC e por objectos gerados automaticamente designados por stubs e ties (i.e., objectos que convertem da representação de dados no programa cliente e no programa servidor para uma representação em formato normalizado, para transportar na rede). Resumindo, Web Services é uma tecnologia para comunicação entre sistemas. A comunicação entre os serviços é padronizada através de formatos/protocolos comuns na Web, possibilitando a independência de plataforma e de linguagem de programação Geography Markup Language e Keyhole Markup Language O GML é uma linguagem, codicada em XML, para a representação de informação geográca. O GML foi especicado simultaneamente para a modelação e distribuição de features geográcas que são denidas pelo OGC como abstracções de um fenó-

25 2.1. Sistemas de Informação Geográca 10 meno do mundo real, i.e. entidades geográcas associadas a uma localização relativa à Terra. Desta forma, o mundo real pode ser representado através de um conjunto de features [19]. O objectivo do GML é oferecer um conjunto de regras, com as quais uma aplicação pode descrever os seus dados. Para tanto, em GML começa-se por denir os esquemas XML (XML Schema) para o domínio concreto de aplicação. O esquema XML dene os elementos, os atributos e a estrutura, usados num documento que descreve os dados de um determinado domínio de aplicação. A versão GML 3.0 inclui esquemas que contêm os modelos de geometria, entidades e superfícies, que facilitam a denição dos esquemas concretos necessários em cada domínio de aplicação. A linguagem Keyhole Markup Language (KML) proposta pelo Google é um complemento ao GML, mais focada para a apresentação de informação geográca num cheiro XML, permitindo assim visualizar informação geográca em ferramentas de visualização [20]. Uma vantagem no uso de XML é a exibilidade oferecida para criar etiquetas que expressam o signicado do dado descrito, obtendo-se um documento rico semanticamente Web Feature Service A especicação Web Feature Service (WFS) [11] dene um serviço para a gestão de features geográcas, usando o formato GML. O serviço pode ser implementado pelo servidor em duas versões: básica, onde apenas operações de consulta cam disponíveis, ou transaccional, que inclui operações de inserção, remoção e actualização. A especicação dene as operações e os requisitos necessários para a concepção do servidor WFS. A especicação WFS dene: A utilização de HTTP (Hypertext Transfer Protocol) como meio de comunicação entre cliente e servidor; A utilização de GML para representação das entidades geográcas. As seguintes operações são denidas para o serviço: getcapabilities: descreve as características do servidor (auto-descrição do serviço);

26 2.1. Sistemas de Informação Geográca 11 describefeaturetype: descreve os tipos que caracterizam as entidades que podem ser servidas; getfeature: retorna as instâncias dos objectos disponíveis. O cliente pode seleccionar quais os objectos desejados por critérios espaciais ou baseados nas suas características; transaction: utilizado para a execução de operações de modicação dos objectos (inserção, remoção e actualização); lockfeature: bloqueia uma ou mais instâncias durante uma transacção; Todos os pedidos, e respectivas respostas, para as operações suportadas pelo serviço seguem os respectivos XML Schemas. Normalmente, para os pedidos mais simples é usado o protocolo HTTP GET. Os pedidos mais extensos e complexos, normalmente, são gerados em XML e enviados pelo protocolo HTTP POST ao servidor Web Map Service A especicação Web Map Service (WMS) [10] dene um serviço para a produção mapas de dados georeferenciados a partir de um conjunto bem denido de operações. A especicação WMS determina que um mapa é formado por um número de camadas e estilos de apresentação, agrupados numa ordem especíca, de forma semelhante à representação do mundo real adoptada pela maioria dos SIG. Os mapas produzidos são representações geradas em formatos de imagem, como PNG, GIF e JPEG, ou em formatos vectoriais, como o SVG. Uma camada pode normalmente ser considerada uma folha transparente que contém entidades representadas através de símbolos. A camada dene as entidades e o estilo dene como as entidades são representadas simbolicamente. Através de inclusão ou remoção dessas camadas, é possível obter mapas mais complexos ou mais simples. Existem três operações denidas pela especicação WMS: getcapabilities: descreve as características do servidor (auto-descrição do serviço); getmap: possibilita recuperar a imagem de um mapa cujos parâmetros geoespaciais e dimensionais são bem denidos. Através do modelo proposto pela especi-

27 2.1. Sistemas de Informação Geográca 12 cação é possível que um cliente solicite camadas individuais de mapas de diferentes servidores, viabilizando a criação de uma rede de servidores de mapas distribuídos; getfeatureinfo: esta operação é opcional segundo a especicação. Pode ser utilizada para obter informações sobre determinadas entidades que são exibidas no mapa. Através dessas operações a especicação pretende padronizar a forma na qual mapas são requisitados por clientes e a forma na qual os servidores descrevem os dados por eles manipulados Web Processing Service A norma Web Processing Service [12], proposta também ela pelo OGC, descreve uma forma de disponibilizar (geo) processos distribuídos numa IDE. Os processos referem-se a qualquer tipo de modelo ou algoritmo que lide com dados espacialmente referenciados, não existindo restrições sobre quais os tipos de operações que podem ser realizadas. Um WPS pode ser visto como um repositório global onde são guardados os processos publicados. Esta norma é exível, na medida em que não lida apenas com informação estática, sendo por isso possível obter dados provenientes de fontes distribuídas. Os dados de entrada podem ser incorporados no pedido que executa o processo ou podem ser referenciados desde fontes externas acessíveis via Web. Formatos de representação como o GML podem ser usados como dados de entrada ou de saída. Relativamente à saída, o WPS devolve o resultado de duas formas possíveis, enviando uma simples resposta ao cliente incluindo o estado do processo, ou alternativamente, retornando uma referência para os dados soba forma de um Uniform Resource Locator (URL). Do ponto de vista do cliente, o WPS é uma caixa preta onde existem processos que podem ser executados, sem o cliente necessitar de saber exactamente o modo como o processo será executado. A Figura 2.1 representa a arquitectura geral de um WPS 2, em que os algoritmos correspondem ao código associado a um processo. 2

28 2.1. Sistemas de Informação Geográca 13 Figura 2.1: Arquitectura WPS [8] A interface do WPS disponibiliza as seguintes três operações que estão referenciadas na Figura 2.1: Getcapabilities: descreve as características do servidor e apresenta ainda um catálogo dos processos publicados no servidor WPS; DescribeProcess: retorna uma especicação mais detalhada de um processo, incluindo os inputs e os outputs que são retornados pelo mesmo; Execute: executa o processo em si. Um dos pontos fortes desta norma é a compatibilidade com o protocolo SOAP. É importante existir esta normalização para que se reduza o esforço de programação e publicação de serviços. No entanto, a norma WPS apresenta algumas limitações, tais como o facto de não suportar o processamento de processos no formato Business Process Execution Language, que é uma linguagem para descrever processos de negócio bastante usada no meio empresarial. o BPEL encontra-se descrito com mais detalhe na secção [23]. Já existem implementações protótipo desta norma, como é o caso das implementações do Deegree e do 52ºNorth. No caso da implementação da organização 52º

29 2.1. Sistemas de Informação Geográca 14 North 3 para além das funcionalidades existentes no documento da especicação da norma, existem algumas extensões que ainda estão em discussão no OGC. Esta implementação, acrescenta duas operações à especicação do OGC com vista a resolver uma lacuna do WPS original, que consiste no facto de não ser possível publicar processos e retirá-los de uma forma dinâmica [2]. Para implementar esta extensão, o GetCapabilities teve que ser alterado, de maneira a que agora incorpore os processos publicados pela nova operação deployprocess. Esta extensão permite publicar qualquer tipo de processos dependendo de um deploymentprole, que caracteriza o tipo de processo a publicar. Um desses proles pode ser o BPEL, permitindo armazenar ainda o processo no WPS mas com uma terceira entidade envolvida que é um motor de BPEL. As operações deployprocess e undeployprocess, são acedidas tal como as outras operações já existentes na interface Sistemas existentes de informação geográca Uma aplicação SIG pode ser dividida em duas partes: a primeira corresponde à edição e manipulação de dados, a segunda ao espaço onde a informação é armazenada (Bases de dados Geográcas). Estes tipos de aplicações podem ser comerciais ou gratuitas. O ArcGIS, produzido pela ESRI, é apenas um exemplo de um sistema comercial que integra vários produtos de software diferentes. Embora tenha um elevado custo associado, é o sistema mais utilizado pelos técnicos de SIG na Administração Pública em Portugal. O ArcGIS desempenha um papel importante no cadastro Português, pois é através desta que que passa grande parte da informação geográca proveniente dos técnicos municipais (e.g áreas protegidas, áreas habitacionais). Também existem ferramentas gratuitas e de software livre, por exemplo, tanto o gvsig como o Kosmo são SIG que permitem editar uma grande variedade de tipos de dados [3]. Existem algumas Câmaras Municipais que já começam a adoptar estas tecnologias para gerir os seus dados. Existem processos relacionados com o cadastro urbano que têm naturalmente 3

30 2.2. Integração de Sistemas 15 que lidar com estas tecnologias. 2.2 Integração de Sistemas O cadastro Português é gerido por várias entidades que detêm os seus próprios SI, tendo-se que os mesmos não estão integrados. A integração de SI é um problema complexo que pode ser visto por diversas perspectivas. De acordo com o tipo de organização ou de tecnologia, podem ser adoptadas várias interpretações para o seu enquadramento [15]. A integração de SI pode ser vista como a partilha de informação e processos entre aplicações ou fontes de dados numa organização. A integração de SI engloba três áreas importantes nomeadamente, a informação, os sistemas informáticos e os processos organizacionais, que devem ser coordenadas e ajustadas sob pena de a integração não se adequar à dinâmica da organização Arquitecturas Orientadas a Serviços - Service Oriented Architecture s (SOAs) O conceito base de uma arquitectura orientada a serviços é o de organizar e utilizar um conjunto de capacidades computacionais distribuídas que podem estar sob o controlo de diferentes domínios [24]. Em geral, as entidades (pessoas e organizações) criam capacidades para resolver ou suportar uma solução para determinado problema que decorra da sua actividade. No mundo dos sistemas distribuídos, o valor extraído das arquitecturas orientadas a serviços resulta do facto de providenciarem uma poderosa plataforma de mapear as capacidades de acordo com as necessidades, permitindo combinar capacidades para responder a tais desaos. Visibilidade, interacção e efeito são três conceitos fundamentais quando se descreve o paradigma SOA: a visibilidade refere-se à capacidade de, aqueles que possuem necessidades e aqueles que oferecem capacidades, se verem mutuamente. Isto é normalmente efectuado através de descrições de aspectos funcionais/requisitos técnicos (constrangimentos, políticas, etc) e mecanismos de acesso ou resposta. Estas descrições devem ser feitas de forma a que a sua sintaxe e a sua semântica sejam acessíveis e compreensíveis por todos. Desta forma, a interacção corresponde à actividade de utilizar uma ca-

31 2.2. Integração de Sistemas 16 pacidade, normalmente através de trocas de mensagens num determinado ambiente de execução. O propósito de utilizar uma capacidade é obter um efeito no mundo real, sendo que este pode ser o retorno de informação ou a alteração dos estados das entidades envolvidas na interacção. Os serviços são por isso aquilo que junta as necessidades, representadas pelos consumidores dos serviços, com as capacidades, representadas pelos prestadores de serviços. Numa perspectiva de enquadramento, pode dizer-se que os conceitos chave no que diz respeito a SOA, são: Normas - As normas relacionam-se com protocolos de comunicação entre serviços, formatos de descrição dos dados, denições de registos, mecanismos de apresentação dos dados ou regras de orquestração dos serviços. Tendo como base normas é possível desenvolver serviços que sejam interoperáveis e que não se encontrem dependentes de uma determinada plataforma de hardware, linguagem de programação ou sistema operativo; Descoberta de serviços - utilizando mecanismos de descoberta, em que determinado serviço procura determinada informação que poderá ser fornecida por outro serviço, a executar-se no mesmo ambiente; Gestão - para além de garantir a segurança, habilidade, disponibilidade e escalabilidade dos sistemas, envolve a criação do serviço e a sua evolução desde a génese até ao m do seu ciclo de vida; Reutilização e re-conguração - sendo os serviços baseados em normas, exíveis e modulares, o objectivo é desenvolver uma vez e usar em diferentes situações, devendo ser fácil e rápido recongurá- los e adaptá-los. Assim, na descrição de um serviço devem ser tidos em conta duas perspectivas fundamentais: Processos - Um sistema baseado em processos pode ser modelado por cinco perspectivas: dados, recursos, uxo de controlo, tarefas e operações (ou aplicações). Estas podem ser modeladas à abordagem SOA: os serviços são uma especialização da perspectiva de operações mais geral. O uxo de controlo

32 2.2. Integração de Sistemas 17 orquestra os serviços via diferentes passos de processos, designados por tarefas. As operações por estas realizadas num uxo de controlo correspondem às invocações dos serviços. Dados - No que diz respeito à perspectiva dos dados, é necessário distinguir entre os dados de controlo e os dados de negócio que, efectivamente, são manipulados ao longo do uxo do processo. O processamento propriamente dito é efectuado ao nível de dados de controlo, tais como regras de encaminhamento do pedido para o respectivo serviço. A orquestração de serviços deverá lidar com os dados de controlo e a forma como os objectos de negócio são tratados a cada passo do processo As formas de integração de SI Com a evolução das tecnologias e a constante adaptação das organizações aos novos desaos dos seus meios ambientes, surgem diferentes necessidades de integração. Cada uma delas tem diferentes formas de intervenção e tipos de integração. Embora muito centrado na integração aplicacional, é comum designar o Enterprise Application Integration (EAI) como a família de referência para as soluções de integração de SI. Por seu turno, os defensores do Business Process Management (BPM) alegam que a sua família tecnológica engloba todas as soluções para a integração de SI [15]. A evolução das TI na área da integração tem revelado que os processos organizacionais são cada vez mais o centro das atenções. Isto deve-se à importância que os processos têm numa organização pela sua natureza estruturante. As soluções de BPM mais recentes incluem praticamente todas as tecnologias e conceitos de integração de SI que foram aparecendo ao longo dos tempos Integração de processos A automatização dos processos organizacionais representa uma das vertentes da integração de SI, pois como diria Gonçalves [13] as empresas são grandes colecções de processos. Estes processos correspondem ao modo de funcionamento das organizações, e denem a forma como a informação é tratada e circulada. A grande

33 2.2. Integração de Sistemas 18 valia desta abordagem é o facto de haver uma ligação directa entre os processos da organização e a tecnologia que suporta a sua implementação. As organizações modernas tendem a uniformizar e automatizar muitos dos seus processos com o objectivo de tornar mais simples e ecaz o seu controlo. A crescente procura de qualidade e excelência pelas organizações levam-nas a certicar-se de acordo com normas de qualidade que se centram na optimização e documentação dos processos organizacionais Os Web Services na integração de SI Independentemente das necessidades de integração, as Tecnologias de Informação oferecem alternativas tecnológicas que se enquadram em normas técnicas especicadas para o efeito. A integração de SI tira partido destas normas e é cada vez mais orientada para a organização e os seus processos. Com a evolução tecnológica é hoje possível disponibilizar informação ou procedimentos como serviços através de uma camada de abstracção suportada em tecnologia do tipo Web Services (WS). Os Web Services podem ser utilizados em qualquer uma das perspectivas da integração mencionadas nos pontos anteriores tirando, partido de todas as vantagens de cada uma delas. Estes criam uma nova camada de acesso aberta sobre cada tecnologia, permitindo tirar partido da sua informação ou dos seus procedimentos. À composição dos Web Services e do seu uxo de informação é chamado workow. Podem existir dois tipos de interacção dentro de um workow. Orquestração: É uma composição de processos de negócio (através de Web Services) onde existe a gura de um processo central (processo mestre) que controla e coordena os demais processos. Neste tipo de composição, cada processo participante não tem conhecimento de que faz parte de uma composição de processos, com excepção do processo mestre; Coreograa: É uma composição de processos de negócio (através de Web Services) onde não existe a gura de um processo central (processo mestre) que controla e coordena os processos. Neste tipo de composição, cada processo envolvido tem conhecimento de que faz parte de uma composição de processos, que precisa interagir com outros processos, de maneira ordenada, para que a composição resultante

34 2.2. Integração de Sistemas 19 tenha sucesso. Cada processo participante sabe exactamente quando actuar, com quais outros processos participantes interagir, quais operações deve executar, quais mensagens deve trocar e até mesmo o momento adequado de troca de mensagens; Papel das normas para a integração de SI O mercado da integração de SI é muito competitivo e dinâmico, existindo empresas que foram criadas exclusivamente para solucionar os seus problemas especícos. Há situações onde uma solução integradora pode não se revelar a mais adequada, obrigando a outras alternativas. Nos últimos anos têm surgido normas, quer para documentar, quer para suportar abordagens e tecnologias nesta área. Hoje em dia, ainda existem soluções proprietárias mas a tendência é para adoptar normas abertas. Neste âmbito, as normas denidas por organismos credenciados representam um factor importante na adaptabilidade e adequação de cada solução. Existe um estudo efectuado pelo Delphi Group que indica que as normas aumentam o valor dos actuais e futuros investimentos em SI. Ainda neste estudo são destacadas algumas normas importantes como o XML, o J2EE da SUN,.Net da Microsoft e também o protocolo SOAP. No caso da integração de SI, a identicação das normas a adoptar pode revelarse difícil e confusa visto que existem vários organismos e empresas, com diferentes interesses, que participam nestas especicações. Geralmente, a evolução do mercado e das próprias tecnologias é que dita a actualidade e a adopção de cada uma das normas que vão surgindo Business Process Execution Language Para além de ser uma das normas mais recentes, e baseada numa especicação da OASIS, o BPEL é suportado pela IBM, Microsoft, Oracle, BEA, SAP e Siebel, cujas soluções e clientes correspondem praticamente à totalidade do mercado nesta área. Esta norma baseada em XML e nos web services permite denir a orquestração dos serviços dentro de uma lógica processual. Permite ainda a integração ponto a ponto de sistemas ou aplicações e suporta interacções assíncronas. Esta especicação requer um motor que permita executar este tipo de processos. Esta norma baseia-se

35 2.2. Integração de Sistemas 20 na identicação das etapas de um processo, a sua interacção com outros sistemas e toda a lógica da sua execução. Os processos de negócio especicados em BPEL são totalmente executáveis e portáveis entre ferramentas BPEL [6]. A denição deste tipo de processos consiste em dois tipos de cheiros: um cheiro Web Service Description Language (WSDL) que especica os tipos de ligação entre as interfaces, propriedades, tipo de portas e operações, mensagens e parte de interesse do processo, incluindo serviços implementados e invocados pelo processo; e outro cheiro do tipo BPEL, que contém a denição do processo, mais concretamente: Os parceiros que representam os serviços envolvidos no workow; As variáveis usadas para manipular os dados trocados entre os parceiros e para guardar os estados dos processos; As actividades que descrevem o uxo, tais como, invocar um Web Service, igualar um valor a uma variável, etc; Business Process Management Notation Ao contrário da especicação anterior, o BPMN (Business Process Management Notation) 4 é uma especicação para a modelação visual de processos. O seu objectivo é facultar uma interface simples e poderosa, que possa ser simplesmente utilizada por analistas de negócios e por analistas de sistemas, funcionando como um contrato entre as partes. Na prática, o BPMN consiste numa série de padrões de representação gráca e lógica no desenho de processos. Já existem diversas ferramentas de desenhos de uxos que incorporaram o padrão BPMN Motores de execução BPEL Os motores de execução de workows BPEL são na realidade a versão actualizada, para serviços Web, dos sistemas tradicionais de gestão de workow. Os sistemas que 4

36 2.2. Integração de Sistemas 21 se destacam são o ActiveBPEL 5, o JBoss jbpm 6, o Microsoft BizTalk Server 7, IBM Websphere Process Server 8 e o Oracle BPEL Process Manager 9. No conjunto acima temos dois grandes grupos: sistemas comerciais e gratuitos. Entre os comercias temos o BizTalk, IBM WebSphere Process Server e o Oracle BPEL PM. Os gratuitos são o Apache ODE 10, ActiveBPEL e o JBoss jbpm Microsoft BizTalk O BizTalk é uma ferramenta de Enterprise Application Integration (EAI) que permite trocas de informações entre empresas através da integração de aplicações. Se essa tarefa for executada dentro de uma organização, fazendo a conexão entre duas ou mais aplicações distintas está-se aplicar o EAI. Se estas aplicações estiverem em duas ou mais empresas distintas, seria o chamado B2B. Esta ferramenta é ainda compatível com as normas BPEL e BPMN. A linguagem usada para a orquestração é o BPEL [21]. As capacidades de orquestração do BizTalk são focadas na comunicação entre sistemas, suportando processos de negócio que dependem da integração de diversos softwares. Possui como principais focos a integração de arquitectura corporativas (EAI), B2B e gestão de processos de negócio (BPM). O suporte a serviços Web do BizTalk é provido pela arquitectura ASP.NET que benecia da infra-estrutura Microsoft para a construção de workows em conformidade com a WCF (Windows Communication Foundation) para a criação se aplicações orientadas a serviço. Além disso, suporta especicações padrão da indústria como: WS-Security Protecção via integridade, condencialidade e autenticação directamente na mensagem XML; WS-ReliableMessaging Garantia de entrega, uma e uma só vez;

37 2.3. O Cadastro urbano Português 22 WS-AtomicTransaction WS Garante que as transacções ocorridas dentro do contexto dos bindings sejam efectuadas dentro do conceito ACID Apache ODE O Apache ODE (Orchestration Director Engine) é uma ferramenta que permite executar os processos de negócio especicados na norma BPEL. Tal como o Biztalk, este também comunica com web services através da troca de mensagens, tal como descrito no processo. Este motor também suporta mecanismos síncronos e assíncronos podendo as execuções ser de longa ou curta duração. Para compor a camada necessária para o desenvolvimento de aplicações baseadas na arquitetura dos Serviços Web, pode-se usar a framework de código aberto Apache Axis2 11 e o Apache Tomcat 12 como servidor de aplicações. Esta ferramenta precisa de ser publicada num servidor como por exemplo o Tomcat, também desenvolvido pela Apache e desta forma suporta também WSSecurity, WS-ReliableMessaging e WS-AtomicTransaction. Existe no entanto uma restrição no mecanismo de publicação, uma vez que é exigido que em anexo com os cheiros necessários para publicar o processo, esteja também presente um cheiro deploy.xml onde são especicados manualmente quais os partnerlinks desse mesmo processo. 2.3 O Cadastro urbano Português O objectivo desta secção é apresentar uma visão geral do cadastro urbano em Portugal. O cadastro em vigor em Portugal pode ser decomposto em rústico e o urbano. Este último é o foco deste trabalho. Para além de uma descrição da situação actual do cadastro é feita também uma descrição das iniciativas e projectos recentes que estão de alguma forma relacionadas com o cadastro

38 2.3. O Cadastro urbano Português Situação actual O cadastro urbano traduz a representação dos prédios (terrenos ou propriedades) que o Estado e os cidadãos possuem, assim como os direitos que estes têm sobre os mesmos. Refere-se então a um registo que contém um conjunto de dados que caracteriza e identica partes delimitadas do solo. Este registo deve descrever a localização, a forma geométrica e, caso exista na parcela (terreno do imóvel), a composição de cada edifício (componente geométrica), situação scal (componente scal) e / ou a identicação dos direitos, ónus e encargos que o proprietário possui (componente legal). Explicando de outra forma, é através da informação fornecida no cadastro que é possível encontrar a composição de um determinado edifício, a quem ele pertence, e que tipo de encargos (hipotecas, anexos, etc), o(s) titulare(s) deve(m) esperar. Em Portugal existem várias entidades envolvidas nos processos do cadastro urbano, nomeadamente: As Câmaras Municipais que têm como principal nalidade o licenciamento de construções (e.g. prédios para habitação, comércio de serviços e indústria) e de terrenos para construção; As Finanças, que são responsáveis pela inscrição destes novos prédios urbanos, para efeitos de avaliação do Código do Imposto Municipal sobre Imóveis (CIMI); A Conservatória do registo predial, que assegura a titularidade do imóvel e a sua situação jurídica. Sem uma certidão desta entidade (pressupõe a existência de um registo nem que seja provisório) não é possível comprar ou vender o imóvel; A conservatória dispõe do serviço "Casa Pronta" que permite fazer num único momento o contrato pretendido e o respectivo registo. A conservatória pode liquidar o Imposto sobre as Transmissões Onerosas (IMT) e, mediante solicitação do comprador, pedir a alteração da morada do mesmo, a isenção do Imposto Municipal sobre Imóveis (IMI) relativo a habitação própria e permanente e a inscrição ou a actualização de prédio urbano na matriz.

39 2.3. O Cadastro urbano Português 24 A informação do cadastro urbano, pode ser alterada por força das acções concretas, que são realizadas pelos vários titulares ou representantes legítimos dos interesses que nele se exprimem. A alteração do cadastro em Portugal advém de muitos processos envolvidos. De seguida são listados os processos mais importantes, considerados pelas autarquias: Actualização do Imposto Municipal do Imóvel (IMI); Actualização dos dados dos imóveis (e.g. mudança de proprietário de um terreno); Licenciamento Municipal (novos licenciamentos, alterações, alvarás de loteamento); Construção de Infra-Estruturas territorial: auto-estradas, caminhos-de-ferro, portos, aeroportos, barragens, sistemas de energias, sistemas técnicos de valorização agro-orestal, etc; Gestão territorial: delimitação das reservas territoriais, das servidões administrativas e das restrições da utilidade pública; Processos relacionados com averbamentos, heranças e partilhas; Devido à vasta lista de sub-processos, este projecto foca-se apenas nos dois primeiros, os quais serão explicados mais detalhadamente na Secção Iniciativas Existem algumas iniciativas que estão de alguma forma relacionadas com o cadastro Urbano: O SIMPLEX 13 é um programa criado pelo Governo Português, que aposta num investimento para simplicação administrativa. Para isto, pretende usar os meios tecnológicos mais recentes reconhecidos nacional e internacionalmente, como instrumentos cruciais para obter uma melhor qualidade de vida, transparência e abilidade do cidadão. 13

40 2.3. O Cadastro urbano Português 25 O Casa Pronta 14 é uma iniciativa que usou as novas tecnologias para acelerar processo de compra de uma casa. Esta iniciativa, pode no futuro, vir a ter alguns pontos de contacto com os processos que serão referidos mais à frente neste documento, nomeadamete no que se refere à actualização dos dados de um proprietário. A compra de casa envolve diversas entidades e o cidadão desempenhava o papel de transportador de documentos. Em comparação com os objectivos deste trabalho, o serviço Casa Pronta apenas se foca no processo de compra e venda de casa, enquanto o nosso trabalho é mais abrangente podendo englobar todo o tipo de processos relacionados com o cadastro urbano. O projecto Casa Pronta, apostou na ligação das Finanças com a Conservatória. O nosso projecto pretende integrar para além destas duas, ainda as Câmaras Municipais. Numa perspectiva futura, o serviço Casa Pronta pode ser complementado com alguns resultados deste trabalho. O SiNErGIC 15 é um projecto do IGP, ainda numa fase embrionária, que tem como objectivo principal viabilizar a existência de um cadastro predial em Portugal que seja exaustivo, actualizado e identicador das propriedades existentes no território Português. Este projecto pretende garantir a harmonização dos diferentes conjuntos de dados cadastrais, baseada na identicação dos prédios através da identicação inequívoca dos imóveis, utilizando um único número de identicação do prédio (NIP), comum a toda a administração pública [17]. Este projecto pretende fazer o levantamento de todo o território português em 15 anos. Este trabalho pode ajudar o SINERGIC na integração das diversas entidades envolvidas Síntese O âmbito deste projecto passa essencialmente por três áreas nomeadamente, os SIGs, a Integração de Sistemas e o Cadastro Urbano Português. Em relação aos SIGs, explicou-se que infraestruturas podem suportar sistemas

41 2.3. O Cadastro urbano Português 26 dotados com informação de cariz geográca e que normas regem este tipo de infraestrutura. Abordou-se com algum detalhe, o Web Processing Service. De seguida passou-se à Integração de Sistemas pois consideramos que o cadastro Português tem um claro problema de actualização de informação entre as várias entidades envolvidas. Também aqui se falou de serviços Web e das arquitecturas que os suportam. Por m abordou-se de uma forma mais geral o cadastro urbano Português, sendo no capítulo seguinte promenorizados dois processos relacionados com informação cadastral.

42 Capítulo 3 Problema Neste capítulo é apresentado o contexto em que se insere o cadastro urbano Português e seguidamente é feita a descrição do problema a resolver. 3.1 Diagnóstico da situação actual O cadastro Português não é gerido por apenas uma entidade mas sim por um conjunto de entidades (e.g. Câmaras Municipais, Bancos, IGP, Finanças) que participam nos processos cadastrais, tendo elas próprias o seu próprio cadastro individual. Estes processos apresentam lacunas, tendo em conta que não existe hoje em dia uma monitorização em tempo real do estado de um determinado processo. Muitos destes processos não chegam a concluir porque cam bloqueados ou usam dados errados. Em conjunto com a Câmara Municipal de Palmela, foi possível identicar algumas actividades que são efectuadas hoje em dia e que apresentam algumas lacunas: Projecto de alteração (ex: ampliação) e respectiva edicação autorizada na Câmara Municipal, avaliado nas Finanças e vendido na Conservatória, tendo por base a 1.º licença/admissão do projecto inicial e não com base no projecto alterado; Obra ampliada sem que seja actualizado o Imposto Municipal sobre Imóveis (IMI) referente à ampliação (recorrente com industrias e armazéns e constitui per si uma grande redução da receita de IMI nas Câmaras Municipais); 27

43 3.2. Análise do problema 28 Emissão de viabilidade de construção (informação prévia favorável) sem inscrição do prédio como urbano para efeitos de IMI; Dados do licenciamento/comunicação diferentes dos dados preenchidos no Modelo 1 das nanças; Licença de obra de edicação emitida e construção existente no terreno sem respectivo pedido de inscrição e/ou alvará de utilização; Alvará de utilização emitido e sem o respectivo pedido de inscrição de prédio; Avaliação de IMI sobre lote para construção quando o objecto de avaliação é o lote com edicação licenciada/admitida; As diversas entidades envolvidas apresentam dados diferentes para as mesmas entidades informacionais; Algumas destas falhas podem perfeitamente ser ultrapassadas com recurso aos meios tecnológicos mais recentes. A tecnologia WPS juntamente com o redesenho dos processos pode ser uma possível solução para estas limitações. 3.2 Análise do problema Como prova de conceito desta tese de mestrado, apenas serão abordados dois processos em pormenor, nomeadamente o processo Avaliar IMI e o Actualizar Proprietário de um Imóvel. A abordagem deste trabalho tem em conta as limitações apresentadas anteriormente e como tal será apresentada na secção seguinte uma avaliação mais pormenorizada destes dois processos que apresentam algumas destas lacunas e no Capítulo 4 são apresentados estes mesmos processos redesenhados Process Avaliar Imposto Municipal sobre Imóveis (IMI) Este processo tem como objectivo a realização da primeira avaliação do IMI, referente a um determinado imóvel. Para efectuar este processo é necessário um impresso, chamado Modelo 1, que serve para a inscrição e avaliação do prédio nas Finanças. As entidades intervenientes no processo são as seguintes:

44 3.2. Análise do problema 29 Câmara Municipal disponibiliza ao cidadão os dados iniciais necessários ao processo, em papel (Planta de Implantação, Alvará de Utilização, Projecto de arquitectura, Planta de Localização, Alvará de Loteamento, etc.) para a inscrição do prédio através da declaração do Modelo 1; Repartição de Finanças avalia o imóvel e atribui uma determinada taxa de IMI e um número de artigo caso seja um prédio novo, ou sempre que exista necessidade de nova avaliação (por exemplo uma transmissão) em que é novamente alterado para um novo número do artigo que identica o prédio resultante de uma nova avaliação. É necessário entregar o impresso Modelo 1; Actualmente, na sua forma não automatizada, o processo de criação de um artigo urbano é iniciado quando é feito o pedido de licença de construção. Após a fase de análise do processo e de emissão da licença de construção, decorre um prazo durante o qual pode ser solicitada a emissão do alvará de utilização ou a prorrogação da primeira licença. De seguida, o cidadão tem que solicitar à Câmara um conjunto de documentos, nomeadamente: O projecto de arquitectura referente ao imóvel; A planta de implantação desenhada sobre levantamento topográco à escala; A planta de localização à escala de 1:25000, indicando o local da situação do terreno abrangido pela operação; O alvará de utilização do imóvel (e.g. a licença de utilização); Quando tiver estes dados em sua posse, o próximo passo do cidadão é deslocar-se à repartição de Finanças e preencher o Modelo 1 apresentado-o juntamente com os documentos anteriormente referidos. É também feita a inscrição e avaliação do prédio com base nos dados recebidos do cidadão, vendo atribuído o respectivo valor de IMI. Um exemplo de não conformidade é a situação em que existe uma construção no terreno e não existe um processo de avaliação. Tal acontece, por exemplo, quando

45 3.2. Análise do problema 30 existe um alvará de obras de edicação, o prazo para requerer o alvará de utilização está concluído, e o requerente não solicitou a emissão do alvará de utilização ou o prolongamento da licença de construção. Como não é emitido o alvará de utilização (os Municípios não fazem um controlo automático entre a emissão do alvará de obras de edicação e o alvará de utilização) este prédio não é avaliado patrimonialmente, dado que o processo de avaliação só se inicia com a emissão desta licença. Este imóvel não será alvo de cobrança no âmbito do IMI, ou apenas existe avaliado como lote urbano para construção (se provém de um alvará de loteamento e este foi submetido via modelo 1 na emissão do respectivo alvará). Ao fazer uma avaliação pormenorizada deste processo, constata-se que tendo em conta as tecnologias de informação actuais, muitos dos passos envolvidos se tornam desnecessários. Cada entidade identicou pontos negativos, que podem ser melhorados ou alterados. De seguida são apresentados esses pontos, listados por entidade: Câmara municipal: Não existe um controlo automático e ecaz entre a emissão de licença/admissão de comunicação e a emissão do alvará de utilização; O número de alvarás de utilização emitidos não corresponde ao número de prédios avaliados; O objecto da avaliação não é o correcto; A avaliação do prédio nem sempre é concordante com as áreas e o uso constantes da licença/admissão de comunicação; Finanças: Entrega presencial (balcão) de toda a documentação necessária em suporte papel; Desconformidade de dados face à realidade; Não existe monitorização entre o processo de emissão de alvará de utilização e o processo de avaliação predial;

46 3.2. Análise do problema 31 Solicitações ao balcão de certidões de teor, em papel, para entrega, pelo cidadão, a outras entidades devido há ausência de informação de outros serviços no portal das nanças; Cidadão: Deslocação à autarquia para solicitar cópias de todos os documentos necessários para submissão do pedido de avaliação; Preenchimento da declaração do pedido de inscrição pelo próprio, tarefa dicultada pelo desconhecimento de toda a informação/dados a introduzir e sem vericação de dados e prazos a cumprir; Deslocação à repartição de nanças para entrega do pedido de avaliação e documentação necessária à sua instrução; Deslocação à conservatória para registo do prédio, que frequentemente, é apenas motivado pela realização de hipoteca ou venda; Processo Actualizar proprietário de um imóvel Este processo é desencadeado quando os dados referentes ao titular ou dados relativos ao próprio imóvel são alterados na Conservatória. As entidades envolvidas são: Câmara Municipal disponibiliza as licenças com base nos dados mais recentes do titular. Sendo as Câmaras Municipais responsáveis pelo licenciamento urbano, são estas que emitem, entre outros documentos, o alvará de licença de construção, que possibilita a construção numa determinada parcela de terreno, o alvará de licença de utilização, que prova as condições de habitabilidade da casa/prédio/imóvel/apartamento vericando se a obra se encontra conforme o projecto de urbanização aprovado e o uso previsto de acordo com o descrito no alvará de licença de construção; Repartição de Finanças reavalia o imóvel. É aqui que as casas/prédios/imóveis/apartamen se encontram inscritos conforme Caderneta Predial. Com estas informações

47 3.2. Análise do problema 32 obtém-se o estado real da situação scal e a quem exigir responsabilidades pelo cumprimento na regularização scal da construção; Conservatória torna legal a informação referente aos dados do titular. É aqui que se encontram todos os registos relativos a prédios (rústicos/urbanos) nas determinadas áreas geográcas. Existem aqui descrições físicas detalhadas, acessíveis a qualquer cidadão (requerimento especíco a ser elaborado na conservatória certidão de teor). É possível, a partir deste documento, saber se existem ónus ou encargos sobre a(o) casa/prédio/imóvel/apartamento e(ou) se a pessoa que pretende vender-lhe é de facto o proprietário; Actualmente, um cidadão desloca-se à conservatória para adquirir os documentos necessários, por exemplo para a escritura de uma compra de casa. Depois de efectuado o pedido, e entre outros passos que não são abordados neste trabalho (por não ter sido facultado o acesso), um dos requisitos do processo é fornecer a caderneta predial ou certidão de teor das Finanças que tem ser adquirida nas repartições de Finanças. Para isso o cidadão desloca-se à sua repartição de Finanças e requisita o documento, para posteriormente entregar na Conservatória. De seguida, outro documento requisitado é o alvará de utilização actualizado. Para isso, o cidadão, terá que se deslocar à sua autarquia e solicitar a licença correspondente ao número identicador do processo municipal, que é o arquivo com todos os dados relativos ao imóvel na Câmara. Depois de entregue ao cidadão, este terá que se deslocar novamente à Conservatória e entrega-la. Caso a licença de utilização esteja regular, então o processo prossegue e os dados são actualizados na Conservatória. A conservatória nem sempre tem a informação do proprietário mais actualizada, no entanto este registo é valido em termos legais (por vezes o cidadão só faz o registo na conservatória quando quer fazer a venda do prédio, este pode existir nas nanças e conservatória com titulares diferentes) e não existe qualquer intercâmbio de informação entre a Conservatória e as Finanças e a Câmara, tendo-se que muitas vezes cabe ao cidadão deslocar-se às respectivas para fornecer os dados mais recentes. Como esta informação não é actualizada muitas vezes acontece, por exemplo que a informação existente na Câmara ainda é referente ao promotor da obra licenciada, que pode não ser o actual utilizador da habitação. Esta informação só volta a ser

48 3.2. Análise do problema 33 actualizada quando o novo proprietário pretende, por exemplo, mudar o contador da água (muitas vezes continua o contador em nome antigo. A autarquia ca sem conhecimento do actual titular, só se for actualizado caso venha a ser solicitado novo processo de alterações). Nos municípios em cujas Conservatórias existe o programa do simplex Casa Pronta, a alteração de titularidade de um prédio (venda que pressupõe novo averbamento e nova avaliação) processa-se de modo diferente. Neste programa pressupõe-se a existência do alvará de utilização nas conservatórias, não sendo necessária a deslocação do cidadão à autarquia. No entanto, a comunicação entre a conservatória e a autarquia não existe como um processo explícito e é muitas vezes feita de modo familiar, via telefone. Esta comunicação deveria ser via Web e de modo ocial, uma vez que existe este tipo de comunicação entre a Conservatória e a entidade bancária pressupõe o acesso a todos os dados do prédio durante o tempo da execução da hipoteca bancária. Neste programa do simplex, o cidadão pode submeter na conservatória o pedido de Modelo 1. No entanto, os recursos humanos existentes nesta entidade não têm formação técnica para auxiliar o cidadão no preenchimento deste formulário. Mais uma vez, ao fazer-se uma avaliação pormenorizada deste processo, constatase que muitos dos passos envolvidos são desnecessários. Também aqui se identi- caram pontos negativos, que podem ser melhorados ou alterados se for usada uma arquitectura de software orientada aos serviços. De seguida são apresentados esses pontos, listados por entidade: Câmara municipal: Não existe um controlo automático e ecaz da informação do proprietário de um determinado imóvel se for alterado por outra entidade; Não existe uma ligação directa entre a Câmara e a Conservatória para a disponibilização de licenças; Entrega presencial (balcão) de toda a documentação necessária em suporte papel; Finanças:

49 3.3. Arquitectura dos processos actuais 34 Entrega ao balcão da documentação necessária em suporte papel: caderneta predial, alvará de utilização; Solicitações ao balcão de certidões de teor, em papel, para entrega, pelo cidadão, a outras entidades; Conservatória: Entrega ao balcão da documentação necessária em suporte papel: caderneta predial e licença de utilização; Solicitações ao balcão de certidões de teor, em papel, para entrega, pelo cidadão, a outras entidades; Cidadão: Deslocação à Câmara para solicitar cópias de todos os documentos necessários; Deslocação à repartição de nanças para solicitar caderneta predial; Deslocação à conservatória para alterar informação; 3.3 Arquitectura dos processos actuais O cadastro Português pode ser interpretado sob o ponto de vista processual. Tendo em conta a sua dimensão e responsabilidade, existe uma série de processos de diferentes naturezas. Nesta secção é feita uma descrição dos processos tal como eles são actualmente. A Tabela 3.1 oferece uma panorâmica geral da forma como estes estão organizados e como serão conhecidos daqui em diante (o suxo representa o identicador do processo): Macro-Processo Processo Sub-Processo [A] Alteração de um imóvel [A.1] Avaliar IMI N/D [B] Gestão dos dados de um imóvel [B.1] Actualizar proprietário de um imóvel N/D Tabela 3.1: Visão geral do ponto de vista processual

50 3.3. Arquitectura dos processos actuais 35 Seguidamente, os processos [A.1] e [B.1] são ser representados formalmente, através da notação BPMN. Referente ao macro-processo de Alteração de um imóvel, existe um processo fundamental que é a avaliação do IMI (ver ). Existem variadas formas de alterar um imóvel, seja por construção de um anexo ou pela simples demolição de uma parede, que é obrigatório por lei que se efectue a actualização do respectivo Imposto Municipal sobre Imóveis. O mesmo pode ser alterado sempre que o imóvel for alterado. O macro-processo Gestão dos dados de um imóvel tem como objectivo a gestão da informação referente a um determinado imóvel. Um dos possíveis passos deste macro-processo é a actualização do proprietário que foi entretanto alterado Processo Avaliar IMI Como foi dito anteriormente, o objectivo deste processo é a actualização do valor de IMI referente a um imóvel. Para que seja atingido este objectivo,é preciso passar por um conjunto de etapas. A Figura 3.1 e a Tabela 3.2 retratam a versão actual deste processo. Tabela 3.2: Descrição processo AS-IS: Avaliar IMI

51 3.3. Arquitectura dos processos actuais 36 Figura 3.1: Workow processo AS-IS: Avaliar IMI Processo Actualizar Proprietário de um Imóvel Aqui é também apresentada a tabela descritiva do processo, onde se pode ver as entidades envolvidas o seu objectivo e as suas principais actividades. Este processo apresenta também algumas ineciências do ponto de vista tecnológico tal como o [A.1]. O cidadão tem aqui ainda um papel muito activo e a Câmara municipal nunca chega a ter a informação actualizada do proprietário depois de este ter sido alterado na Conservatória.

52 3.3. Arquitectura dos processos actuais 37 Tabela 3.3: Descrição processo AS-IS: Actualizar Proprietário de um Imóvel Figura 3.2: Workow processo actual: Actualizar Proprietário de um Imóvel

53 3.3. Arquitectura dos processos actuais Arquitectura de informação As entidades de informação envolvidas nos processos descritos acima são apresentadas na Tabela 3.6: Nome Número de processo municipal Processo municipal Modelo 1 Imóvel Titular Pessoa singular Pessoa colectiva IMI Dados pessoais Alvará de utilização Planta de Implantação Descrição Número que identica um processo municipal arquivado na Câmara municipal. Dossier que contém dados relativos a um imóvel e ao seu titular. Impresso ocial da Direcção Geral de Contribuições e Impostos (DGCI) que tem como objectivo a Inscrição ou Actualização de Prédios Urbanos na Matriz. Prédio rústico ou urbano, água, árvore, arbusto e frutos naturais enquanto estiverem ligados ao solo, os direitos inerentes a estas coisas e as partes integrantes dos prédios rústicos e urbanos ligadas materialmente com carácter de permanência. É a pessoa que detém os direitos sobre um determinado imóvel. Titular único de um imóvel. Conjunto de titulares para o mesmo imóvel. É o imposto que incide sobre o valor patrimonial tributário dos imóveis situados em território português e a sua receita reverte a favor dos municípios onde se localizem. Os dados pessoais referem-se aos dados de um determinado titular de um imóvel. Alvará que contém um documento emitido pela Câmara Municipal autorizando que uma casa seja habitada, após ter sido vericado que reúne as condições exigidas para o efeito (segurança, salubridade, dimensões, etc.) e está em conformidade com o projecto aprovado. Planta de síntese do plano de pormenor que estabelece o parcelamento do loteamento urbano, bem como o alinhamento e perímetro das edicações principais e das edicações adjacentes.

54 3.3. Arquitectura dos processos actuais 39 Planta de Localização Projecto de Arquitectura Caderneta predial (ou Certidão d eteor das nanças) Conservatória Finanças Câmara Municipal Mapa com a localização de um determinado imóvel. Estão disponíveis os números de polícia, limites administrativos, arruamentos, lugares, edifícios e vias, bem como ortofotomapa (fotograa aérea). Desenho técnico, elaborado à mão ou com software próprio, onde se representa um corte plano horizontal de uma construção. A Caderneta Predial comprova a inscrição matricial de um prédio ou de uma fracção autónoma e deve informar sobre o denominado artigo desde o seu valor patrimonial, a sua composição, descrição e confrontações, até à identicação scal e nome do proprietário. Este documento é imitido pela Repartição de Finanças do Concelho a que pertence o imóvel. Documento que funciona como uma espécie de "bilhete de identidade" do imóvel e comprova a sua inscrição na matriz, identica a sua localização, a composição, a área, o proprietário e o valor patrimonial tributável. Entidade que gere a titularidade de um imóvel Entidade que gere o IMI correspondente a um imóvel. O IMI é criado aquando for avaliado o impresso Modelo 1. Entidade que efectua a gestão Urbanística providenciando também licenças e plantas. Tabela 3.6: Entidades de Informação A gura (Figura 3.3) ajuda perceber como estas entidades se relacionam: Figura 3.3: Relacionamento entre entidades

55 3.4. Síntese Síntese Neste capítulo foram identicados os principais problemas relativos ao cadastro urbano. Foi feito um levantamento dos principais problemas, através de entrevistas às diversas entidades envolvidas. Com base nesta recolha de informação foram escolhidos os dois principais processos para estas entidades e descrevemos a sua arquitectura de processos assim como a informacional.

56 Capítulo 4 Proposta de solução Tendo em conta o problema descrito no capítulo anterior, foram analisados exaustivamente os dois processos do Cadastro Português, para que se detectassem as ineciências existentes. Dessa análise, vericou-se que existia uma excessiva troca de informação entre o cidadão e as entidades responsáveis. Os processos avaliados foram então redesenhados. A solução proposta relativamente aos processos não deve ser considerada como uma reengenharia de processos de negócio, pois os processos mantêm-se quase inalterados. Essencialmente melhorou-se a troca de informação entre o cidadão e as entidades envolvidas, através da disponibilização da informação entre as mesmas. Para se pôr em prática todas estas sugestões, propõe-se o desenvolvimento de um sistema, responsável por suportar e agilizar os processos de negócio que estão a ser estudados, o qual vai conduzir a uma diminuição do trabalho que é feito manualmente pelas entidades envolvidas. Neste capítulo é apresentada a Arquitectura de Processos assim como a Arquitectura Informacional. No entanto, não foi possível apresentar a Arquitectura Aplicacional devido às restrições impostas pelas entidades envolvidas. 4.1 Arquitectura de processos proposta Como foi dito, não foi feita uma reengenharia dos processos. Essencialmente introduziramse algumas actividades que permitem facilitar a interacção dos cidadãos com as en- 41

57 4.1. Arquitectura de processos proposta 42 tidades públicas e tornar a informação mais ável e correcta. De seguida vão ser apresentadas apenas as alterações sobre os processos, tal como estão descritos, no Capitulo Avaliar Imposto Municipal sobre Imóveis Neste novo processo, continua a ser o cidadão quem o despoleta, mas agora para fazer o pedido de avaliação do IMI basta aceder a um portal online. Aqui é necessário que o cidadão forneça os dados relativos ao processo municipal do qual se pretende adquirir informação através do seu identicador único. Nestes processos propostos os acessos às entidades são feitos via Web. Cada entidade tem o seu serviço Web com as operações. Usando os dados de entrada fornecidos pelo cliente, é feito um pedido, à operação disponível no Web Service da Câmara para retornar os dados relativos ao processo municipal, incluindo as plantas e licenças assim como toda a informação do contribuinte e do imóvel. Muitos dos campos exigidos para o preenchimento do Modelo 1 devem ser fornecidos pela Câmara, por esta ter a informação mais actual e legal. Depois do processo municipal ser retornado, é feito um pré-preenchimento com os valores existentes na Câmara. Como se pode ver na Figura 4.1 existe um mapeamento entre os campos do Modelo 1 e a aplicação de urbanismo da Câmara Municipal (neste caso de Palmela). Toda a informação que a Câmara tiver do imóvel é preenchida no Modelo 1 sendo que os restantes campos são preenchidos pelo cidadão.

58 4.1. Arquitectura de processos proposta 43 Figura 4.1: Exemplo de uma correspondência entre a aplicação do Urbanismo da Câmara e o Modelo 1 Deve também ser usado um serviço que garanta que os dados introduzidos estão correctos, como por exemplo, averiguar se o Código Postal inserido está de acordo com a morada do imóvel. Este serviço permite ainda acrescentar ao Modelo 1 as coordenadas geográcas associadas ao imóvel, mais concretamente a latitude e longitude, que podem posteriormente ser usadas pelos técnicos scais das nanças. Para complementar este processo deve-se também usar outro serviço que retorne uma imagem com um mapa da zona onde o imóvel se insere. Esta imagem é anexada à planta de localização para complementar a planta fornecida pela Câmara. Caso esta vericação tenha sido bem sucedida, o Modelo 1 preenchido é validado e o processo entregue aos responsáveis pela avaliação do prédio urbano. As melhorias introduzidas neste processo são: Pré-preenchimento do Modelo 1, facilitando o trabalho do cidadão que assim

59 4.1. Arquitectura de processos proposta 44 só tem de preencher os campos restantes; Actualização do IMI passa a ser um processo rápido e sem erros; Redução da necessidade da participação do cidadão, pois os documentos são submetidos no novo sistema, e reencaminhados directamente para as aplicações; Partilha de informação entre as Finanças e as Câmaras Municipais; Associação automática das coordenadas geográcas ao imóvel; A Figura 4.1 mostra este processo proposto. Figura 4.2: Processo avaliar IMI proposto Actualizar proprietário de um imóvel O que se pretende na alteração deste processo é novamente facilitar a tarefa ao cidadão, evitando as deslocações desnecessárias que possam existir actualmente. Quando na conservatória for exigida a licença de utilização e a certidão de teor, é invocada a operação disponibilizada no Web Service da Câmara recebendo como entrada o número do processo municipal, o requerimento e o anexo, retornando a licença de utilização referente ao imóvel pretendido. Ao mesmo tempo é também

60 4.1. Arquitectura de processos proposta 45 invocada a operação nas Finanças correspondente ao retorno da certidão de teor pretendida. A certidão é invocada recebendo o NIP correspondente ao imóvel. Como se viu na descrição do processo actual, a Câmara não é actualizada com a informação nal referente ao novo proprietário. Como tal, quando o processo de alteração do proprietário for entregue na Conservatória é feita a escritura e legalização do novo proprietário. Depois deste passo, o orquestrador por sua vez será incumbido de, entregar a informação referente ao titular às outras entidades intervenientes. Na Câmara é actualizado o titular do imóvel em questão e nas nanças é entregue um novo Modelo 1 com base no anterior já existente mas onde o proprietário se encontra actualizado. As melhorias introduzidas neste processo são: Rápida devolução da licença de utilização e da certidão de teor das Finanças; A actualização do proprietário passa a acontecer automáticamente; Redução da necessidade da participação do cidadão, pois os documentos são submetidos no novo sistema, e reencaminhados directamente para as aplicações; Partilha de informação entre as Finanças, Conservatória do Registo Predial e Câmaras Municipais. Esta operação é feita em poucos segundos ao contrário do vasto tempo dispendido hoje em dia. A Figura 4.2 retrata todo este processo.

61 4.2. Arquitectura de informação revista 46 Figura 4.3: Actualizar proprietário de um imóvel proposta 4.2 Arquitectura de informação revista Depois da análise do problema, vericou-se a necessidade de apenas transformar algumas entidades informacionais que estão hoje em dia em papel para formato digital. De seguida apresentam-se estas entidades:

62 4.3. Síntese 47 Nome Modelo 1 Alvará de utilização Planta de Implantação Planta de Localização Projecto de Arquitectura Urbanismo Certidão de teor Serviço externo Processo municipal Descrição Este impresso tem exactamente os mesmos campos que o impresso físico mas passa agora a ser num formato digital Este alvará contém a licença de utilização e é um dos nós do processo municipal Esta planta contém a planta de implantação digital e é um dos nós do processo municipal Esta planta contém a planta de localização digital e é um dos nós do processo municipal Este projecto inclui a planta de arquiectura e é um dos nós do processo municipal O urbanismo corresponde a toda a informação existente na Câmara Municipal correspondente a um imóvel. É um dos nós do processo municipal A certidão de teor passa agora a estar disponível num formato digital com as respectivas secções da certidão física Serviço disponível na Web que inclui um conjunto de operações que podem ser usadas livremente Conjunto de toda a informação associada a um imóvel Tabela 4.2: Entidades de Informação 4.3 Síntese Neste capítulo foram descritas optimizações possíveis de serem realizadas sobre os processos apresentados no Capítulo anterior. Foram especicados os novos processos e apresentada também a arquitectura Informacional que indica as entidades informacionais usadas nos processos. No capítulo seguinte será apresentada a arquitectura que suporta estes processos.

63 Capítulo 5 Arquitectura da solução Neste capítulo são apresentados os conceitos, princípios e opções arquitecturais tomadas na plataforma orientada a serviços proposta, para suportar os processos do cadastro urbano. Primeiramente apresentar-se-á o modelo de serviços que serve de base à arquitectura, com uma categorização dos mesmos de acordo com os seus papéis e características. Posteriormente serão apresentadas os componentes arquitecturais que servem de base à plataforma e que suportam as tecnologias. Finalmente, será apresentada o caso de estudo acompanhado pela visão geral da arquitectura de software, que cumpre os princípios pretendidos na solução proposta, e que identica as ferramentas tecnológicas adoptadas para, em colaboração, atingir os objectivos estabelecidos, detalhando o seu funcionamento e a forma como têm impacto no desenvolvimento dos serviços por cima da plataforma. 5.1 Objectivos Com base nas normas WPS e BPEL apresentadas anteriormente, este trabalho propõe uma plataforma distribuída orientada a serviços, que sirva de suporte ao cadastro urbano. Ambas as normas procuram favorecer a independência das aplicações, fornecendo um modelo de programação o mais neutral possível relativamente às tecnologias de implementação, aos protocolos de comunicação e ao tipo de dados manipulados ao nível aplicacional. Baseando a descrição do sistema numa arquitectura centrada em componentes e orientada a serviços favorece-se a cooperação 48

64 5.2. Visão geral 49 entre objectos de negócio e facilita-se a interoperabilidade entre os mesmos, criando condições para a existência de sistemas cada vez mais exíveis e adaptáveis às características dinâmicas e de constante mudança dos ambientes onde estes se executam. 5.2 Visão geral A Figura 5.1, mostra a arquitectura da solução proposta. Esta arquitectura mostra que os serviços da Câmara, Finanças e Conservatória são distribuídos tacticamente mas ao mesmo tempo comunicam entre si ou seja integrados do ponto de vista estratégico. Cada uma das entidades envolvidas tem o seu próprio Web Service. Existe ainda um serviço de orquestração que trata de executar os processos que envolvem as diferentes entidades, e um directório UDDI onde serão publicados os contractos dos serviços. Nesta arquitectura existem três Web Services que correspondem às entidades públicas envolvidas. Figura 5.1: Arquitectura geral A arquitectura é baseada na interacção de três personagens: Fornecedor de Serviços, Consumidor de Serviços e Registo dos Serviços. A interacção destas entidades envolve as operações de publicação, pesquisa e ligação. Vejamos a denição de cada uma destas funções : Fornecedor de serviços: é a entidade que fornece o Web Service, neste caso a

65 5.3. Componentes da Arquitectura 50 Câmara, as Finanças e a Conservatória e ainda outros serviço externos usados nos processos. Disponibiliza o serviço para que alguém possa utilizá-lo. Mas, para que isto ocorra, ele precisa de descrever o Web Service num formato normalizado (WSDL), que seja compreensível para qualquer um, que necessite de usar esse serviço, e também publicar os detalhes sobre o seu Web Service num registo central que esteja disponível, neste caso no UDDI; Consumidor de serviços: qualquer um que utilize um Web Service criado por um fornecedor de serviços. Neste caso o principal consumidor é o orquestrador do processo embora este também seja publicado como um serviço e esteja também disponível. Este conhece a funcionalidade do Web Service, a partir da descrição disponibilizada pelo fornecedor de serviços, recuperando os seus detalhes através de uma pesquisa sobre o registo publicado; Registo dos serviços: o registo de serviços é a localização central onde o fornecedor de serviços pode relacionar os seus Web Services, e no qual um consumidor de serviços pode pesquisá-los. Portanto, o fornecedor de serviços dene a descrição do serviço para o Web Service e publica esta para o consumidor de serviços no registo de serviços. O UDDI pode desempenhar este papel; A comunicação nesta arquitectura é feita usando o protocolo SOAP desenvolvido para ser exível, permitindo a comunicação entre máquinas em ambientes heterogéneos. O seu sucesso deve-se essencialmente ao facto de ser simples, de ser formatado em XML e transportado por HTTP - ou seja, utiliza protocolos há muito adoptados pela indústria. 5.3 Componentes da Arquitectura Esta secção aborda os principais componentes do modelo de serviços que constituem o núcleo de execução da plataforma de serviços. Como tal, serão apresentados os mecanismos utilizados para atingir a funcionalidade pretendida para cada um destes serviços.

66 5.3. Componentes da Arquitectura Plataforma de integração A plataforma de integração é o componente core desta arquitectura onde os processos se executam. Esta plataforma pode ser vista como um conjunto de componentes que fornece à camada de lógica de negócio um conjunto base de serviços de integração ao nível dos dados, sendo uma peça fundamental numa arquitectura orientada a serviços, complementando em grande medida as facilidades de colaboração de serviços oferecida por uma plataforma de gestão de serviços. O objectivo fundamental é o de fornecer meios de comunicação entre vários sistemas incompatíveis, sem ter que efectuar adaptações à medida, para permitir a troca de dados entre serviços, sendo uma base de troca de mensagens para os vários serviços e clientes. Num ambiente de serviços distribuído, em que um processo pode ser encarado como serviço que fornece funcionalidades aos restantes e que pode, ele próprio, tirar partido das características de escalabilidade e robustez que a plataforma fornece, a sua mais valia é ainda maior no que diz respeito à interoperabilidade e integração de serviços e à adaptabilidade do sistema. A norma WPS na versão não especica qualquer tipo de ligação com a linguagem BPEL, como tal, esta plataforma resulta da composição da norma WPS, para orquestrar essencialmente os processos que envolvam dados geográcos uma vez que os processos relativos ao cadastro Português contêm dados espaciais, juntamente com a linguagem BPEL, que é a linguagem mais usada para descrição de processos de negócio no meio empresarial. O ponto de contacto deste componente da arquitectura é pela interface da implementação da norma WPS que funciona como um wrapper sobre o motor BPEL, desempenhando assim o papel de interface deste componente, através das três operações standard (getcapabilities, describeprocess e execute). Caso seja necessário complementar o processo WPS com um BPEL é feito o mapeamento dos dados de entrada do processo BPEL invocando o mesmo ao motor responsável pela execução dos processos descritos em BPEL. Desta forma é ainda possível interagir com outras normas especicadas pelo OGC, tais como o GML, WFS e WMS. Tal como é apresentado na Figura 5.2, pode existir então aqui uma integração com serviços SIG (e.g. Google Earth e ArcGIS) que não foi implementado no protótipo deste trabalho.

67 5.3. Componentes da Arquitectura 52 O pedido efectuado ao servidor WPS é feito via HTTP Post, assim como o pedido feito por este ao Motor BPEL. Já para se efectuarem os pedidos GetCapabilities e o Describe Process é usado o HTTP Get. Desta forma podem existir interacções entre os dois processos e o resultado para o cliente pode até ser a mistura de informação geográca com um processo BPEL Modelo de serviços O modelo de serviços estabelece uma organização conceptual para os vários serviços a correr na plataforma. São apresentados de seguida os vários tipos de serviços denidos no modelo e respectiva função na arquitectura. Tratando-se de uma arquitectura SOA, uma característica da solução proposta é o facto de, independentemente da funcionalidade que cada serviço a executar na plataforma desempenha, todos eles representam entidades pares, que são as entidades de uma mesma camada em máquinas diferentes, que se executam em ambiente dinâmico e distribuído e que exportam funcionalidade para os restantes. A Figura 5.2 representa as diferentes categorias de serviços a contemplar pela arquitectura de software orientada a serviços, identicando os principais componentes existentes em cada categoria: De acordo com a gura, podem identicar-se três áreas fundamentais dos serviços a correr na plataforma. Será efectuada uma abordagem vertical, começando por se apresentar as áreas de serviços para, posteriormente, se abordarem alguns dos serviços que fornecem a funcionalidade propriamente dita. Cada um destes serviços pode ter uma interface que permita invocar as suas operações públicas. Orquestração de Serviços - Conjunto de serviços que fornecem as facilidades base da plataforma, desde o ambiente de execução, aos mecanismos de descoberta e composição de serviços; Serviços Implementados - Os serviços implementados correspondem a uma categoria de serviços que fornecem capacidades adicionais possuindo conteúdos e funcionalidades que podem ser utilizados para tirar um melhor partido da plataforma e dos restantes serviços. Estes serviços são desenvolvidos à medida;

68 5.3. Componentes da Arquitectura 53 Serviços Externos - O conceito de serviço externo está relacionado com o conjunto de serviços que estão disponiveis na Web a qualquer utilizador (e.g. Yahoo, Google); Figura 5.2: Modelo de serviços Cada serviço implementado tem o seu modelos de dados. Uma vez que os serviços Web trocam mensagens XML, usaram-se os respectivos XML Schema para descrever o modelo de dados de cada serviço. Vericou-se então que se tornaria vantajoso usar uma base de dados que tem como unidade fundamental de armazenamento, um documento XML, análogo às bases de dados relacionais que utilizam a linha de uma tabela como unidade de armazenamento. A existência de linguagens de interrogação e interacção, como o XQuery 1 e o XUpdate 2, permitem integrar em plataformas XML a interacção directa com as bases de dados, sem recurso a linguagens de programação convencional

69 5.4. Caso de estudo Descoberta de serviços A descoberta de serviços pode ser feita por meio do UDDI ou através da operação WPS GetCapabilities embora com objectivos diferentes. Esta última permite que o cliente receba metadados do servidor tais como a identicação e actividades que podem ser executadas pelos processos publicados no servidor WPS (e.g. identicador, título, resumo, metadados, versão). O UDDI funciona como uma lista de páginas amarelas onde se pode encontrar todos os serviços aqui publicados independentemente, sejam eles processos BPEL ou serviços Web. O serviço é publicado num registo UDDI que inclui, para além da descrição sumária do mesmo, a referência do seu endereço e do documento WSDL (interface) correspondente Interface Correspondem a consumidores dos serviços disponibilizados ao nível da plataforma de serviços, mas com características de integração na mesma que lhes permitam usufruir dos mecanismos de descoberta e interacção com os serviços de forma facilitada. Podem passar por interfaces Web em Java (usadas para testar o protótipo deste trabalho), HTML ou Flash, aplicações tradicionais de janelas para PC e aplicações orientadas a dispositivos móveis. 5.4 Caso de estudo Depois de estabelecidos os objectivos do modelo e apresentados os componentes da arquitectura, será de seguida apresentada o caso de estudo que se baseia na aplicação desta arquitectura no cadastro Português. São também explicadas as tecnologias e o software usado nesta arquitectura Serviços Web envolvidos Na implementação, os serviços Web representam um determinado papel dentro da lógica de negócio. Os serviços usados podem ser de dois tipos: os serviços implementados para simular as entidades envolvidas, e os serviços externos que são

70 5.4. Caso de estudo 55 disponibilizados por empresas como a Yahoo, etc. De seguida vão ser especicados os dois tipos de serviços usados. Para implementar os serviços foi usada a biblioteca Java XML API for Web Services (JAX WS) a qual, permite implementar serviços baseados nas normas XSD, WSDL e SOAP. Através desta biblioteca, é possível implementar Web Services partindo de um contrato WSDL (o qual utiliza XML Schemas para denir os tipos de dados envolvidos nas mensagens) ou partindo de código Java Serviços Implementados Os três serviços implementados correspondem às entidades públicas envolvidas nos processos estudados. No início deste projecto foi perguntado às mesmas se podiam disponibilizá-los mas devido a questões burocráticas ou até mesmo por inexistência, foi decidido fazer implementar esses serviços de raíz e tentando fazer uma aproximação o mais real possível. Em cadas um dos serviços, os dados estão armazenados numa base de dados XML que permite executar XQuery directamente sobre os dados. Os resultados destas queries são, serializados e devolvidos ao cliente. Neste protótipo foi usado a base de dados XML Qizx 3. Esta base de dados é usada para guardar os dados relativos aos Web Services implementados. Para resolver problemas de deadlocks foi preciso implementar mecanismos de trincos Web Service Câmara Este serviço é gerido pela Câmara Municipal e tem como objectivo disponibilizar operações que interajam com os documentos locais. Estes documentos podem ser plantas, licenças ou até os chamados processos municipais. Foi lançado um decreto-lei que obriga todas as Câmaras a guardarem as plantas e outros documentos em formato digital. Por isso, foi assumido que estes documentos estarão disponiveis neste tipo de formato. A informação gerida pela Câmara tem então duas vertentes: uma primeira que 3

71 5.4. Caso de estudo 56 corresponde à informação geográca que as autarquias dispõem, e uma segunda que trata das licenças e de toda a informação referente ao processo a licenciar (gestão urbanística). O contrato WSDL associado ao serviço tem as seguintes operações: Criar Processo: Esta operação tem como objectivo criar um processo na Câmara. Para isso, é obrigatório fornecer, toda a informação referente ao registo do processo. A informação restante, senão for fornecida nesta operação, pode ser depois adicionada através de outras operações. O resultado desta operação indica o estado, conrmando se o processo foi ou não criado no sistema da Câmara com sucesso; Devolver Processo: Esta operação permite devolver um processo municipal já existente na base de dados, através do seu identicador. O resultado deste processo contem todas as secções referentes ao urbanismo, licenças e ainda plantas; Adicionar Projecto Arquitectura: Esta operação permite adicionar toda a informação referente ao projecto de arquitectura, que inclui nos dados de entrada as imagens das plantas de arquitectura e as suas áreas, o identicador do processo assim como o número de requerimento e anexo. A resposta indica se o pedido foi bem ou mal adicionado; Adicionar Planta Localização: Esta operação permite adicionar ao processo a planta de localização referente ao terreno através do XML de entrada que também contém o identicador do processo assim como do anexo e do requerimento. A resposta indica se o pedido foi bem ou mal adicionado; Adicionar Planta Implantação: Esta operação permite adicionar ao processo a planta de implantação referente ao terreno através do XML de entrada que também contém o identicador do processo assim como do anexo e do requerimento. A resposta indica se o pedido foi bem ou mal adicionado; Adicionar Licença Utilização: Esta operação permite adicionar ao processo a licença de utilização referente ao terreno através do XML de entrada que

72 5.4. Caso de estudo 57 também contém o identicador do processo assim como do anexo e do requerimento. A resposta indica se o pedido foi bem ou mal adicionado; Devolver Licença Utilização: Esta operação permite devolver uma licença de utilização. Para que isto aconteça tem de receber como entrada o número do processo onde está inserida assim como o número da licença de utilização. O resultado deste pedido é um XML correspondente à licença de utilização; A Figura 5.3 representa o modelo de dados usado neste serviço mais concretamente no que se refere ao Processo Municipal da Câmara Figura 5.3: Modelo de dados do processo da Câmara Este processo abrange ainda o nó Urbanismo que se encontra mais detalhado na Figura 5.4. Este nó foi feito com base no software de gestão do urbanismo na Câmara.

73 5.4. Caso de estudo 58 Figura 5.4: Modelo de dados do Urbanismo Web Service Finanças As nanças têm hoje em dia uma plataforma onde se encontram vários serviços online, como por exemplo a entrega do IRS 4. O serviço Web desenvolvido no contexto deste trabalho, apenas simula os serviços das Finanças necessários nos processos descritos. Este tem como principal objectivo acrescentar a possibilidade de gerir o Modelo 1, assim como a certidão de teor. Para gerir o Modelo 1 implementaram-se as seguintes operações: Criar Modelo 1: Esta operação tem como objectivo inscrever um prédio urbano na matriz. Para isso, é fornecido através de um XML, a informação referente ao impresso Modelo 1. O resultado desta operação é um XML que indica o estado, conrmando se o processo foi ou não criado no sistema das Finanças com sucesso. 4

74 5.4. Caso de estudo 59 Devolver Modelo 1: Esta operação permite devolver o impresso Modelo 1 através do seu identicador, caso já tenha sido criado no sistema das Finanças. O resultado deste processo é um XML com todas as secções referentes ao impresso. Para se modelar a informação do Modelo 1 usou-se uma XML Schema, organizada de acordo com as secções existentes no formulário em papel (ver Apêndice A.2) Titular do prédio ou fracção Motivo da entrega da declaração Identicação matricial Situação do prédio Tipo de prédio a avaliar Caderneta urbana O modelo de dados do Modelo 1 encontra-se especicado na gura 5.5. Figura 5.5: Modelo de dados do Modelo 1

75 5.4. Caso de estudo 60 Para gerir a Certidão de Teor o serviço suporta as seguintes operações. Criar Certidão de Teor: Esta operação tem como objectivo criar a Certidão de Teor que acontece depois de os técnicos scais avaliarem o imóvel. Recebe como entrada a estrutura de dados correspondente à certidão. O resultado desta operação é a introdução na base de dados deste registo e reporta se esta inserção foi bem-sucedida; Devolver Certidão de Teor: Esta operação permite devolver uma determinada Certidão de Teor, recebendo como entrada o seu identicador neste caso o NIP. O resultado deste processo é um XML contendo a estrutura da caderneta caso esta já tenha sido criada no sistema das Finanças; Para se denir a Certidão de Teor usou-se uma estrutura de dados XML Schema, organizada de acordo com as secções existentes: Identicação do Prédio Localização do Prédio Descrição do Prédio Áreas Fracção Autónoma Localização da Fracção Elementos da Fracção Áreas da Fracção Dados de Avaliação Titulares Isenções

76 5.4. Caso de estudo 61 O modelo de dados da Certidão de Teor encontra-se especicado na Figura 5.6. Figura 5.6: Modelo de dados da Certidão de Teor Web Service Conservatória Como foi dito na Secção 2.4.3, a Conservatória dispõe do serviço Casa Pronta que providencia ao cidadão alguns serviços online. As operações implementadas neste Web Service podem complementar algumas das acções executadas no Casa Pronta. Este serviço tem como principal preocupação a gestão dos dados da escritura. O contrato WSDL associado ao serviço disponibiliza então as seguintes operações: Fazer escritura: Esta operação tem como objectivo receber os dados necessários relativos a um determinado imóvel para fazer a escritura. Para isso, são fornecidos como input a certidão de teor das Finanças a Licença de Utilização e os dados relativos ao novo titular. O resultado desta operação é a introdução na base de dados deste registo para que seja entregue aos técnicos da Conservatória e reporta se esta inserção foi bem-sucedida; Devolver escritura: Esta operação permite devolver a escritura através do NIP, caso exista no sistema da Conservatória;

77 5.4. Caso de estudo 62 Apagar escritura: Esta operação apaga uma escritura através do NIP e devolve uma mensagem que indicando o sucesso da operação; Na Figura 5.7 está especicado o modelo de dados relativo aos dados de entrada para ser efectuada a escritura. Figura 5.7: Modelo de dados dos Dados de entrada para efectuar escritura Serviços Externos Os serviços externos desempenham um papel de auxílio à orquestração ou até mesmo no código do processo WPS. Estes serviços podem ser invocados usando o pedido GET ou Post consoante o tipo de serviço usado. O Yahoo Geocoder 5 é um serviço que permite através de uma dada morada retornar um XML com toda a sua informação, como por exemplo a rua, código postal, coordenadas da latitude e longitude etc. Para executar estes pedidos a Yahoo disponibiliza uma API de acesso. O objectivo é efectuar geocoding ou seja atribuir um identicador, neste caso de cariz geográco, a um conjunto de dados. Nos processos explorados neste trabalho, este serviço é usado para validar se os dados introduzidos estão coerentes, (e.g. quando é introduzido um código postal pelo cidadão, verica-se se esse mesmo código está de acordo com a morada introduzida ver Figura 5.8) mantendo desta forma a integridade dos dados. É também 5

78 5.4. Caso de estudo 63 adicionado ao Modelo 1 a latitude e longitude facilitando desta forma o trabalho dos scais das nanças. Este serviço foi usado directamente no processo BPEL fazendo a invocação através de um wrapper SOAP/WSDL. Figura 5.8: Exemplo da utilização do serviço Yahoo Geocoder Outro serviço que foi usado, foi o serviço Static Maps do google que através de um pedido GET retorna uma imagem aérea dependendo de alguns parâmetros. Os parâmetros do pedido incluem uma chave de utilizador gerada pela Google, a morada, o nível de zoom, e o tamanho da imagem a ser gerada. Como tal, na schema correspondente à Planta de Localização das Finanças existem dois elementos cujo tipo são base64binary. O elemento localizacao corresponde à planta de localização retornada pela Câmara e o elemento localizacaoauxiliar à imagem do Static Maps. Existe ainda um dado a sublinhar, enquanto o serviço Yahoo Geocoder foi invocado dentro do processo BPEL, o Static Maps foi invocado dentro do processo WPS apenas para mostrar a exibilidade da arquitectura.

79 5.4. Caso de estudo 64 Figura 5.9: Schema contendo da planta de localização Orquestração de serviços A lógica é uma das camadas desta arquitectura, que nesta implementação é tratada por um orquestrador. Este orquestrador trata de executar os processos de negócio. Cada entidade envolvida nos processos descritos tem o seu próprio Web Service com as suas operações especícas. No entanto, estes serviços só por si não resolvem o problema. É preciso existir um orquestrador de processos que faça circular o uxo de informação. Os processos redesenhados alvo de estudo nesta dissertação, foram implementados em BPEL através do IDE Netbeans e posteriormente publicados no motor de orquestração de BPEL Apache ODE. As Figuras 5.10 é apenas um exemplo de uma operação efectuada no processo Avaliar IMI que corresponde à invocação da operação que devolve um determinado processo municipal na Câmara usando a ferramenta gráca do Netbeans. Figura 5.10: Exemplo da invocação da operação que devolve um processo na Câmara Estes processos foram implementados de acordo com os desenhos BPMN apresentados no Capítulo 4. Este motor implementa a lógica de alto nível, e fornece o suporte para as interacções assíncronas (computacionais ou humanas). Desta forma

80 5.4. Caso de estudo 65 conseguimos colocar a lógica do negócio expressa apenas por uma linguagem de alto nível, o BPEL (usando editores grácos). A publicação dos processos WPS passa por dois passos. No primeiro são publicadas as classes Java onde está especicado o código dos processos (AvaliarIMI.java e ActualizarProprietarioImovel.java). No segundo são publicados os cheiros XML correspondentes às descrições dos processos, nomeadamente as entradas e saídas, e outro tipo de descrições, para posterior invocação da operação describeprocess. Foi neste passo que foram denidos os processos Avaliar IMI e o Actualizar Dados dos Imóveis no WPS. Ao ser feita a invocação do processo WPS por parte do cliente, este por sua vez tem de invocar o processo respectivo no motor BPEL. Para que isto aconteça os dados de entrada têm de ser convertidos e ser feita uma chamada HTTP POST aos endpoints dos processos BPEL alojados no motor. Foram testadas duas formas de fornecer os dados. Na primeira foram mapeados os inputs recebidos pelo WPS na string, dentro do código do processo WPS, usada para fazer o pedido SOAP ao processo publicado no servidor Apache ODE. Na segunda esta string foi construída no lado do cliente, ou seja pela interface, sendo posteriormente enviada por inteiro para o WPS que desta forma não teve que fazer o mapeamento, procedendo-se directamente à invocação do processo BPEL Interface A tecnologia Saop UI foi usada para testar directamente os serviços implementados e também os processos publicados no servidor Apache ODE. Ao serem fornecidos os contractos WSDL correspondentes aos serviços, é gerado pela ferramenta um formulário com os campos necessários para a sua execução (ver gura 5.11).

81 5.4. Caso de estudo 66 Figura 5.11: Exemplo da interface para criar um processo na Câmara Para executar os processos WPS foram desenvolvidas umas aplicações cliente em Java que pretende ser a interface com a qual o cidadão vai interagir. Estas aplicações efectuam pedidos HTTP POST, ao servidor WPS. Para isto, o utilizador preenche os campos correspondes aos dados exigidos para a execução dos processos e faz submeter como se pode ver na gura A resposta da operação execute é um documento XML contendo o resultado do processo que é transformado numa forma gráca para o utilizador.

82 5.4. Caso de estudo 67 Figura 5.12: Exemplo da interface de início do processo Avaliar IMI Para se executarem os processos publicados é preciso seguir uma sequência de passos. Por exemplo, para efectuar a avaliação do IMI é necessário que o processo já exista na base de dados da Câmara por isso para criar o processo na Câmara é necessário utilizar o programa SoapUI para invocar a operação criar processo do serviço Web da Câmara. Quando este processo existir pode-se invocar o processo WPS usando a interface Java. Avaliar IMI 1. Criação de um Processo Municipal (cliente SoapUI Pro); 2. O utilizador preenche os campos necessários ao início da execução do processo (Aplicação JAVA); 3. O utilizador recebe os dados relativos ao primeiro pedido com sucesso (Aplicação JAVA);

83 5.4. Caso de estudo O utilizador recebe a informação que o processo pedido não existe na Câmara Municipal (Aplicação JAVA); 5. O utilizador envia os dados pedidos para a continuação do processo (Aplicação JAVA); 6. O utilizador recebe a informação se o processo foi nalizado com sucesso ou não (Aplicação JAVA); Actualizar Dados do Proprietário de um Imóvel 1. Criação de um Processo Municipal (cliente SoapUI Pro); 2. Criação de uma Certidão de Teor (cliente SoapUI Pro); 3. Criação de um Modelo 1 (cliente SoapUI Pro); 4. O utilizador preenche os campos necessários ao ínicio da execução do processo (Aplicação JAVA); 5. O utilizador recebe os dados relativos ao primeiro pedido com sucesso (Aplicação JAVA); 6. O utilizador recebe a informação que o processo pedido não existe na Câmara Municipal (Aplicação JAVA); 7. O utilizador recebe a informação que a licença pedida não existe no processo (Aplicação JAVA); 8. O utilizador recebe a informação que a certidão de teor não existe nas Finanças (Aplicação JAVA); 9. O utilizador recebe a informação que o Modelo 1 não existe nas Finanças (Aplicação JAVA); 10. O utilizador envia os dados pedidos para a continuação do processo (Aplicação JAVA); 11. O utilizador recebe a informação se o processo foi nalizado com sucesso ou não (Aplicação JAVA);

84 5.5. Síntese Síntese Neste Capítulo foi apresentada uma arquitectura que segue a losoa SOA permitindo disponibilizar aplicações e informação como serviços. Esta realidade permite a reutilização e integração destes serviços em soluções mais abrangentes e exíveis para o desempenho dos processos do Cadastro Urbano. Apesar do principal propósito ser a ilustração de algumas formas de integração, suportadas em diferentes normas e tecnologias, a alternativa criada com a norma WPS em conjunto com a linguagem BPEL é, neste caso concreto, um complemento que permite uma maior abragência no tipo de processos a executar podendo ser de teor geográco ou não. Por ser usada a norma WPS os Web Services envolvidos podem também disponibilizar dados geográcos seguindo as normas OGC, como por exemplo, o WMS ou WFS. Foi também apresentado o caso de estudo relativo ao protótipo implementado onde são apresentados os dois processos estudados do cadastro Português aplicados nesta arquitectura. Para a execução destes processos foram usados dois serviços externos que permitiram acrescentar valor aos processos estudados. Pelo facto da arquitectura ser baseada nas normas e tecnologias mais recentes, a administração pública pode vir a cooperar melhor, reduzindo os problemas de interoperabilidade que existem hoje em dia. Relativamente aos processos propostos, os técnicos scais das Finanças podem sair beneciados visto que os dados fornecidos pelo modelo 1 estão agora em consonância com os dados de licenciamento da Câmara, permitindo fazer uma avaliação com base em valores correctos, os técnicos da Câmara podem requisitar dados às outras entidades envolvidas via Web usando as operações dos Serviços Web. Para além dos aspectos positivos desta arquitectura esta arquitectura apresenta algumas limitações que podem ser melhoradas, como por exemplo, facto de a norma WPS não apresentar os WSDLs relativos aos processos directamente, faz com que o cliente invoque a operação getcapabilities num browser ou crie manualmente o WSDL correspondente ao processo, pois ainda não há forma de o fazer automaticamente. Por outro lado a operação getcapabilities não é suciente para esta arquitectura, visto que apresenta apenas os serviços disponíveis no servidor WPS, pelo que para descobrir o serviço é preciso saber o endereço do serviço, foi por esta razão

85 5.5. Síntese 70 que se incluiu na arquitectura o serviço UDDI, mas que não foi implementado no protótipo. Não existe um modo exível de publicação dos processos no WPS, e para isso sugere-se a integração do módulo WPS-Transactional para publicação e remoção de processos de forma dinâmica. A integração de um módulo de autenticação que lide não só com aspectos ao nível da autorização para a utilização dos serviços, como também ao nível dos dados privados dos utilizadores que são trocados no sistema. De notar que para o servidor WPS ainda não existe nenhuma especicação OGC relativa à segurança. Explorar outros processos do cadastro urbano Português, para além dos dois explorados neste trabalho, que possam ser mais ecientes usando esta arquitectura.

86 Capítulo 6 Avaliação O presente capítulo apresenta uma descrição das ideias e conceitos de alto-nível que foram consideradas para os testes efectuados ao projecto. Serão descritos os objectivos a atingir com os mesmos e o tipo de testes escolhido para os obter. Para além de testes funcionais aos diferentes componentes e serviços de núcleo da plataforma, foram efectuados testes de desempenho para aferir da aplicabilidade de arquitecturas orientadas a serviços como uma melhor solução para ambientes dinâmicos, avaliando a obtenção dos benefícios e vantagens pretendidas. Relativamente aos testes funcionais, o correcto funcionamento dos componentes foi aferido através de um cenário concreto de utilização. Quanto aos testes de desempenho da plataforma, para cada teste serão descritas as condições e objectivos dos testes para depois serem analisados os resultados obtidos. 6.1 Plano de testes Esta secção descreve em que ambiente foram feitos os testes à arquitectura, apresentando também uma breve descrição dos testes funcionais. Neste plano de testes foram identicados os objectivos de qualidade do projecto desenvolvido e o conjunto de testes a ser executado de forma a avaliar e atingir esses mesmos objectivos. Os vários componentes de software e características pretendidas para a plataforma serão testados e critérios para a aceitação dos resultados serão denidos. 71

87 6.1. Plano de testes Ambiente de execução dos testes Os testes foram efectuados numa instalação do sistema operativo Windows Vista SP1, embora outras plataformas sejam suportadas. Sob o ponto de vista do hardware utilizado, os testes foram efectuados num computador com um processador Core2Duo a 2,5GHz com 3Gb de memória. Foram utilizados no que diz respeito a software, as seguintes versões das ferramentas: Java Virtual Machine - versão rc, 52N WebProcessingSerive implementation, Apache ODE 1.3.2, Apache Tomcat 6.0, Apache Maven Apesar de distribuída, o testes a esta arquitectura foram efectuados na mesma máquina. No que diz respeito a clientes dos serviços, foi utilizada uma aplicação Java desenvolvida à medida através do programa Netbeans IDE 6.1 e a interface gráca SoapUI Pro 3.0 para invocação de serviços através de Hypertext Transfer Protocol (HTTP) para automatização de tarefas de teste e simulação de um cliente de webservices Cenário de utilização e especicação de testes Este cenário de utilização pretende avaliar um conjunto de interacções típicas com o sistema por parte dos utilizadores que procuraram demonstrar o correcto funcionamento do protótipo do caso de estudo apresentado no capítulo anterior. O conjunto de interacções que irão ser efectuadas, com vista a vericar as funcionalidades disponibilizadas pela aplicação são apresentadas no Apêndice C. Neste apêndice encontram-se especicados os testes funcionais, decorrentes da aplicação do sistema ao cenário de utilização descrito, sendo que um único teste poderá validar mais do que uma das funcionalidades identicadas anteriormente. Cada teste apresenta uma descrição dos objectivos a atingir com o mesmo, identica as pré-condições necessárias à sua execução, descreve o conjunto de passos a efectuar e especíca, naturalmente, o resultado esperado para o mesmo. De salientar que todos estes testes se revelaram bem sucedidos.

88 6.2. Testes de desempenho à plataforma e resultados Testes de desempenho à plataforma e resultados Análise de resultados Para avaliar se o WPS pode suportar os processos redesenhados, foi necessário denirem-se algumas métricas de desempenho em duas situações diferentes: a primeira consiste na execução dos processos como existem actualmente e a segunda através da execução dos processo denidos neste protótipo Avaliação dos processos actuais Actualmente não existe nenhum estudo que indique o tempo que em média se demora a efectuar estes dois processos. Contudo, através de entrevistas com alguns dos stakeholders envolvidos nestes processos pode-se armar, que as entidades, por exemplo, não sabem sequer qual o estado em que o processo se encontra relativamente a um determinado imóvel. Como foi dito na Secção 3, é o cidadão quem tem de entregar os documentos necessários entre as entidades envolvidas, desta forma mecânica pode-se adivinhar que cada processo ao nível da comunicação demore várias horas dependendo de alguns factores tais como, o tipo de deslocação, a distância das entidades ou se os documentos estão disponíveis aquando dessas deslocações. Para além destes factores relativos à comunicação da informação, falta ainda referir o próprio tempo de execução de cada actividade do processo nas entidades envolvidas. Um exemplo destas actividades corresponde ao preenchimento do Modelo 1, tendo-se até que muitas vezes o cidadão paga a terceiros para o preencher. Por isso conclui-se que estes processos podem demorar horas ou meses. Ao nível das interacções do cliente, usando os processos redesenhados, não é preciso este deslocar-se ao balcão das entidades para ir buscar ou entregar documentos o que só por si traz algumas vantagens. Nas Tabelas 6.1 e 6.2 são apresentadas as deslocações físicas que têm de ser feitas nos processos actuais e que deixam de ser necessárias nos processos redesenhados:

89 6.2. Testes de desempenho à plataforma e resultados 74 Processo Avaliar IMI Tipo de deslocação Número de vezes Pedir documentos de um processo Modelo 1 (Câmara) 1 Buscar documento de um processo Modelo 1 (Câmara) 1 Entregar Modelo 1 (Finanças) 1 TOTAL 3 Tabela 6.1: Deslocações no processo Avaliar IMI Processo Actualizar Dados de Proprietário de um Imóvel Tipo de deslocação Número de vezes Pedir documentos de um processo para Modelo 1 (Câmara) 1 Levantardocumento de um processo para Modelo 1(Câmara) 1 Pedir licença de utilização de um processo (Finanças) 1 Pedir certidão de teor de um imóvel(finanças) 1 Levantar certidão de teor de um imóvel(câmara) 1 Entregar dados para escritura (Finanças) 1 TOTAL 6 Tabela 6.2: Deslocações no processo Actualizar Dados de Proprietário de um Imóvel Avaliação dos processos propostos Através desta arquitectura pode-se constatar que é o cidadão o principal beneciado, pois este já não tem de servir de orquestrador do processo e ter que ir levantar entregar documentos ou até mesmo preenchê-los. A grande vantagem desta arquitectura é a grande diferença de tempos entre os processos executados desta forma e os executados actualmente, mas para além disso pode-se saber, a qualquer momento, em que estado está o processo. Observando os valores dos testes efectuados (Anexo C), consegue-se deduzir que todos os tempos apresentados são efectuados em poucos segundos o que regista um importante signicado tendo em conta as dias ou meses que levam actualmente. Apesar de não existirem dados relativos aos tempos de deslocação podemos deduzir e armar que se forem multiplicados minutos ou horas por deslocação se percebe que se estas deslocações/transporte forem efectuadas por meio desta arquitectura o cidadão não tem de se deslocar e pode ser feito por meio electrónico em segundos. Não é so nas deslocações que o cidadão é beneciado, através da orquestração dos serviços, o número de campos preenchidos pelo cidadão pode ser mais reduzido, tendo em conta que cada entidade partilha agora os dados entre si, sem que seja

90 6.2. Testes de desempenho à plataforma e resultados 75 necessário o cidadão repetir o preenchimento de campos que já tinha preenchido anteriormente. Como se pode ver na Tabela 6.3 neste protótipo são pré-preenchidos 34 campos levando a uma redução de 28,22%. A Figura 6.1 é um exemplo ilustrativo do pré-preenchimento do Modelo 1 feito no processo BPEL. Número de campos total Número de campos pre-preenchidos Redução em % ,22 Tabela 6.3: Tabela comparativo dos campos preenchidos no Modelo 1 A Figura 6.1 é um exemplo ilustrativo do pré-preenchimento do Modelo 1 feito no processo BPEL. Figura 6.1: Exemplo do pré-preenchimento do Modelo 1 A informação passou de um formato físico para um formato digital, pelo que existe uma redução de informação física nomeadamente papel, pois esta deixa de circular entre as entidades. Por esta razão o custo monetário, é menor pois as transacções deixam de ser feitas apenas em papel e mecanicamente. Na entrega do Modelo 1 foi ainda adicionado a latitude e longitude que foi considerado pelos técnicos da Câmara como sendo de elevada importância. Para ajudar os técnicos foi adicionada uma planta de localização gerada pelo serviço

91 6.2. Testes de desempenho à plataforma e resultados 76 Google, juntamente com a planta de localização retornada pela Câmara (Apêndice A.5) Tecnologias de comunicação de dados Este teste à plataforma de serviços consiste na execução de um serviço de contagem através de diversos clientes que utilizam tecnologias de comunicação diferentes. Desta forma, para além de procurar avaliar o desempenho de cada tecnologia, pretende também vericar aspectos não funcionais da plataforma bem como vantagens resultantes da utilização das metodologias orientadas a serviços. De seguida vão ser exibidos os resultados das invocações aos dois processos estudados. Os resultados apresentados foram executados usando a interface Java desenvolvida para o efeito. As Tabelas 6.4 e 6.5 reectem as métricas de desempenho para os pedidos: Ordem de execução 1 2 Tarefa a executar Pre-preencher Modelo 1 Criar Modelo 1 Processo Avaliar IMI Aplicação Java (WPS) Tempo de execução (ms) Tamanho (b) SoapUI (ODE) Tempo de execução (ms) Tamanho (b) Tabela 6.4: Métricas de desempenho do processo Avaliar IMI Ordem de execução 1 2 Processo Actualizar Proprietário de um Imóvel Aplicação Java (WPS) Tarefa a Tamanho (b) executar Fazer escritura e pre-preencher Modelo 1 Criar Modelo 1 Tempo de execução (ms) SoapUI (ODE) Tempo de execução (ms) Tamanho (b) Tabela 6.5: Métricas de desempenho do processo Actualizar Proprietário de um Imóvel

92 6.2. Testes de desempenho à plataforma e resultados 77 Para fazer estas medições foram usadas duas tecnologias, o SoapUI para efecutar pedidos directamente ao motor BPEL ODE sem passar pelo WPS e o Jmeter para medir os tempos de execução via WPS. Os tempos apresentados nas tabelas são a média dos resultados de invocação de dez pedidos não simultâneos e o tamanho corresponde ao tamanho da mensagem enviada que se mantém igual em todos os pedidos. Apesar de serem tecnologias diferentes pode-se vericar que não houve grandes discrepâncias entre os tempos de invocação de cada pedido. Na Tabela 6.4 observase que o primeiro pedido é mais rápido que o segundo, isto explica-se pelo tipo de operações executadas pelo processo. Enquanto no primeiro é apenas efectuada uma invocação ao serviço da Câmara e feito o pre-preenchimento, no segundo para além do pedido ao serviço das Finanças para registar o Modelo 1 também é invocado o serviço externo do Yahoo, desta forma explica-se o aumento do tempo de execução do processo. A Tabela 6.5 retrata os dados relativos à invocação do processo Actualizar Proprietário de um Imóvel. Neste processo observa-se que os tempos são maiores relativamente ao processo Avaliar IMI. Isto explica-se pela quantidade de operações dentro deste processo. O primeiro pedido começa pela invocação da operação na Câmara que retorna uma Licença de Utilização, depois pede às Finanças a certidão de teor para de seguida enviar estas duas mais a informação dada pelo cliente referente ao titular do imóvel à Conservatória recorrendo à operação para fazer a escritura. Para nalizar é pedido às Finanças que retornem o Modelo 1 criado pelo titular anterior do imóvel e por m é efectuado o pre-preenchimento desse mesmo Modelo 1 para o cliente. O segundo pedido começa por enviar o novo Modelo1 para as Finanças já com o novo titular. Depois deste passo é pedido à Câmara o processo Municipal para na secção do Urbanismo ser actualizado o Titular do Imóvel. Com base nos resultados obtidos é possível constatar desde logo que o desempenho das diferentes tecnologias é muito semelhante no que respeita ao tempo de execução. Não houve uma grande diferença entre as invocações efectuadas pelo WPS e as efectuadas pelo ODE. A invocação via WPS demorou mais tempo embora seja uma diferença curta tendo em conta que o WPS ainda invoca o processo disponibi-

93 6.2. Testes de desempenho à plataforma e resultados 78 lizado no motor ODE. A diferença foi de apenas aproximadamente, 300 ms, o que revelou ser um bom resultado tendo em conta que ao prejudicar a performance neste tempo está a abrir portas para uma maior abrangência no tipo de processos. Este teste permitiu mostrar a potencialidade de optimização de performance e agilidade que as ferramentas utilizadas ao nível da plataforma de serviços podem fornecer aos serviços já desenvolvidos. Adicionalmente, a utilização de vários clientes, alguns dos quais correspondem a sistemas já existentes, provam a concretização do objectivo de interoperabilidade para a troca de dados, preconizado para a plataforma Concorrência no acesso aos serviços O teste de concorrência no acesso aos serviços consiste na variação do número de clientes que executam pedidos quase em simultâneo ao serviço de avaliação do IMI. O objectivo deste teste é demonstrar que todos os pedidos são processados e que existe justiça no acesso aos mesmos, não havendo clientes a ser privilegiados relativamente a outros. A métrica utilizada foi o tempo médio de invocação para os pedidos de cada cliente, sendo que o número de clientes em simultâneo variou entre 1 e 10. Este teste foi efectuado com recurso à aplicação Jmeter que efectua várias invocações com destinos diferentes. Este consistiu em ir gradualmente aumentando o número de clientes, quase em simultâneo, lançados para a execução dos pedidos ao dito serviço. Os destinos dos pedidos são: Invocação da operação devolverprocesso na Câmara; Invocação da operação criarmodelo1 nas Finanças; Invocação via WPS; As Tabelas 6.6 e 6.7 mostram o resultado da invocação das operações devolução de um processo existente na Câmara e criar Modelo 1 nas Finanças respectivamente. apresenta os resultados obtidos para a invocação. Cada barra corresponde ao resultado médio do número de clientes em simultâneo.

94 6.2. Testes de desempenho à plataforma e resultados 79 Tabela 6.6: Tempos de invocação dos serviço com o aumento dos clientes em simultâneo para devolver um Processo Tabela 6.7: Tempos de invocação dos serviço com o aumento dos clientes em simultâneo para criar o Modelo 1 nas Finanças É possível vericar que o tempo médio de invocação em cada caso é muito próximo para os vários clientes em cada um dos cenários (visível pela proximidade das barras no gráco). Tal como era de esperar, o tempo médio de invocação por pedido aumenta com o aumento do número de clientes. É também respeitada a ordem de chegada dos pedidos. Tentou-se igualmente submeter o servidor WPS a este teste no entanto, constatouse que surgiram problemas de sincronização resultantes da base de dados Derby DB usada pelo motor Apache ODE. À medida que o número de clientes aumentava, o

95 6.3. Síntese 80 tempo de execução aumentava de uma forma exponencial chegando a atingir os 60 segundos, quando não existiam este tipo de problemas. Como tal este motor de BPEL não passou com sucesso no teste de escalabilidade devido à base de dados Derby DB. Uma possível solução seria conseguir usar este motor juntamente com uma base de dados mais robusta que suporte transacções em larga escala. 6.3 Síntese Neste Capítulo foram efectuados dois tipos de testes aos processos estudados, que nos permitiram concluir aspectos positivos e negativos. Começando pelos positivos e tendo em conta que o cidadão foi sempre o nosso principal foco, concluímos que o esforço do cidadão foi reduzido principalmente em dois aspectos. Primeiro, este deixa de desempenhar o papel de transportador de documentos entre entidades reduzindo o número de deslocações consideradas desnecessárias. Segundo, o cidadão deixa de ter que preencher todos os campos do Modelo1, e passa a preencher apenas os dados que não estão disponíveis nas entidades envolvidas, existindo no mínimo uma redução de 28,22% do número de campos podendo esta percentagem ser aumentada. Comparando os tempos de execução dos processos e sem ter qualquer tipo de estudo relativo aos processes actuais, pode-se concluir que os processos executados nesta arquitectura demoram entre 1286 e 5428 ms, que é um resultado melhor do que o efectuado sicamente pelo cidadão. Finalmente estes testes permitiram concluir que o facto de se usar o WPS como um wrapper sobre o motor BPEL apenas aumentou em 100 ms o desempenho dos processos, fazendo uma comparação entre as vantagens, conclui-se que seria preferível perder 300 ms de desempenho e poder usufruir desta arquitectura. Estes testes permitiram também descobrir algumas lacunas, como é o caso do teste de escalabilidade que nos permitiu concluir que o Apache ODE com a base de dados Derby DB, como motor de BPEL revelou ser uma boa opção mas não para plataformas de grande escalabilidade devido aos problemas de sincronização das transacções. Infelizmente não foram usados dados reais devido a problemas burocráticos e como tal, foram usados dados ctícios.

96 Capítulo 7 Conclusões e trabalho futuro Devido aos avanços das tecnologias de SDI e web services, a evolução da interoperabilidade de sistemas de informações geográcas tem obtido auspiciosos patamares. Consequentemente, há uma melhor disseminação e utilização da informação espacial. Esta evolução, aliada ao facto do avanço das tecnologias de localização de serviços espaciais, tem pressionado para que se faça uso de tecnologias que façam uso da informação geográca. Como tal, este trabalho consistiu numa prova de conceito que mostrou que a norma WPS (que permite processar dados geográcos) juntamente com a linguagem BPEL (que não permite processar dados geográcos) podem ser usadas para suportar processos do cadastro mais modernos e alinhados com a tecnologia actual. A sua operacionalização é uma tarefa políticamente muito complexa uma vez que envolve entidades da Administração Central e Local com estratégias diferenciadas. Neste trabalho pretendeu-se fornecer à Câmara de Palmela conhecimento sobre como as novas tecnologias podem suportar os seus requisitos. Foi feito um estudo de caracterização do cadastro urbano com as diversas entidades envolvidas para perceber os pontos de vista de cada uma, incluindo o que está bem e o que pode ser melhorado. Para se perceber bem o cadastro urbano, estudaram-se os seus processos. Devido à sua complexidade focou-se apenas em dois deles. Como o cadastro está relacionado com uma componente geográca, foi feito um estudo sobre os Sistemas de Informação Geográca que abrange não só os conceitos como também as ferramentas que os suportam. Foi também efectuado um estudo sobre 81

97 7.1. Principais contribuições 82 integração de sistemas, estudando-se as melhores práticas assim como os conceitos e tecnologias usadas. Depois de se perceber a realidade actual, foram apresentadas soluções aos processos estudados, soluções essas que foram denidas com base nos argumentos dados pelas entidades envolvidas e com base também nas tecnologias e normas modernas para facilitar estes processos. Com os processos denidos, foi denida uma arquitectura que os suporta com base nas tecnologias e conceitos referidos ao longo do documento. Nesta arquitectura foram referidas as tecnologias que se pretende usar para implementar esta solução. Uma dessas tecnologias é o WPS, que ao que tudo indica pode desempenhar um papel importante para o cadastro Português, dada a sua componente geográca e por se tratar de uma interface normalizada. Desta forma surge assim um repositório de processos, que tanto podem ser geográcos e interagir com outras normas OGC, como podem não conter dados geográcos e estarem no formato BPEL. A implementação da norma WPS tal como está especicada na versão apresenta a limitação de não ser possível publicar e retirar os processos de uma forma dinâmica. Também no decorrer deste trabalho participou-se no desenvolvimento do protótipo WPS-Transactional com vista a acrescentar mais duas operações, deployprocess e undeployprocess. Foi desenvolvida uma aplicação protótipo, baseada na especicação WPS, que tira partido das funcionalidades de processamento de dados geográcos, a qual foi usada na invocação de processos BPEL. A arquitectura proposta conseguiu cumprir com os objectivos propostos resultando em várias contribuições importantes. 7.1 Principais contribuições A principal contribuição desta dissertação é o desenvolvimento de uma arquitetura orientada a serviços para o compartilhamento de serviços espaciais em conjunto com a norma BPEL. Esta arquitetura torna-se relevante devido aos seguintes aspectos: Arquitectura orientada a serviços: devido à exibilidade possibilitada pela a arquitectura, o utilizador desta arquitectura, apenas deve aceder a um

98 7.2. Trabalho futuro 83 catálogo para localizar os serviços. Interoperabilidade entre os SDIs: a arquitectura desenvolvida permite que vários SDIs troquem informações de forma transparente ao utilizador. Como é uma arquitectura baseada em normas qualquer sistema que respeite estas normas pode ser facilmente integrado. WPS e BPEL: A conjunção destas duas normas permite a execução de processos geográcos em conjunto com processos descritos na linguagem BPEL referência no meio empresarial para descrição de processos de negócio. Cooperação entre entidades: Através dos processos redesenhados e com o suporte desta arquitectura baseada nas normas e tecnologias mais recentes, as entidades da administração pública podem cooperar melhor, reduzindo os problemas de interoperabilidade que existem hoje em dia; Cidadão sai beneciado: Com a implementação desta arquitectura o cidadão sai beneciado na redução do seu esforço nestes processos, seja ao nível das deslocações seja ao nível dos campos a preencher nos formulários. Avaliação mais correcta: Os técnicos scais das Finanças podem agora fazer uma avaliação do imóvel mais justa, pois os dados que servem de base à avaliação (fornecidos pelo Modelo 1) estão coerentes com os do licenciamento da Câmara. O valor do IMI cobrado aos cidadãos é então mais correcto e actual devido ao facto de os dados estarem sincronizados entre as diferentes entidades intervenientes. Os resultados apresentados atingem os objetivos desta dissertação. Não obstante alguns pontos de melhoria que foram identicados ao longo da elaboração deste trabalho, que são apresentados na seção que segue. 7.2 Trabalho futuro Esta arquitectura apresenta também alguns pontos que podem ser melhorados e que faltaram desenvolver ao longo deste trabalho, nomeadamente:

99 7.2. Trabalho futuro 84 Escalar esta arquitectura a nível nacional: Esta problemática foi estudada em conjunto com as entidades de Palmela (Câmara Municipal, Finanças e Conservatória), no entanto, este cenário deve ser o mesmo em grande parte do país pelo que se torna desaante levar esta arquitectura a um patamar nacional; Gestão da arquitectura e interface: Neste trabalho faltou decidir quem será o gestor desta arquitectura ou até que interface será usada para o cidadão. Existiram algumas possibilidades, como por exemplo usar o portal das Finanças, mas que nunca chegou a ser decidido quem a iria gerir. Explorar outros processos do cadastro urbano Português: Neste trabalho foram estudados apenas dois processos para prova de conceito, no entanto existem muitos outros processos, que podem ser explorados; Testes envolvendo um ambiente de larga escala: Como o objeto de estudo é geogracamente distribuído, devem ser realizados maiores simulações utilizando a rede da Internet para interligar SDIs em diversos estados e países. Por falta de tempo, tivemos que restringir nosso estudo de caso nesta dissertação.

100 Bibliograa [1] Bordalo A. Desenho urbano e cadastro predial. Declaração política de arquitectura da Ordem dos Arquitectos, texto de opinião P04, A cidade para o cidadão, [2] Schaeer B. Towards a transactional web processing service (wps-t). Institute for Geoinformatics, University of Muenster, Proceedings of the 6th Geographic Information Days, [3] Stefan S. ; Erwan B. An overview on current free and open source desktop gis developments. Int. J. of Geographical Information Science, [4] C. M. Cruz. A importância do cadastro no processo de desenvolvimento urbano português. In XI Colóquio Ibérico de Geograa, [5] Cowen D. GIS versus CAD versus DBMS: What are the dierences? Photogrammetric Engineering and Remote Sensing, [6] Maldaner L.; Pasqual E. Uma análise de linguagens de composição de serviços: A utilização de bpel e yawl. Master's thesis, União Dinâmica de Faculdades Cataratas (UDC), [7] Júnior F. Sws-gis: uma arquitetura baseada em serviços para uma federação de spatial data infrastructures. Programas de Pós-graduação da CAPES, [8] Stoter J. Foerster T. Establishing an ogc web processing service for generalization processes. Workshop of the ICA Commission on Map Generalisation and Multiple Representation,

101 Bibliograa 86 [9] Câmara G. ; Medeiros G. Princípios básicos em geoprocessamento. Sistema de informações geográcas: Aplicações na agricultura. Brasília, DF, EMBRAPA., Volume 2, [10] Open GIS Consortium Inc. Web map service implementation specication version [11] Open GIS Consortium Inc. Web feature service implementation specication version [12] Open GIS Consortium Inc. Web processing service implementation specication version [13] Gonçalves J. As empresas são grandes colecções de processos. RAE - Revista de Administração de Empresas, Volume 40 - Número 1 - Janeiro-Março [14] R. Julião. A directiva inspire e sua implementação em portugal. Revista Ingenium Janeiro / Fevereiro, Volume 109, [15] Victor M. Integração de sistemas de informação: Perspectivas, normas e abordagens. Master's thesis, Universidade do Minho, [16] A. Martínez. Uma ferramenta de apoio ao desenvolvimento de web services. Master's thesis, Universidade Federal de Campina Grande, [17] A. Mateus. Interesse e valia do sinergic à luz de uma análise custo-benefício. Revista Ingenium Janeiro / Fevereiro, Volume 109, [18] Ramalho J. ; Henriques P. Xml & xsl: da teoria à prática. FCA - Editora Informática ISBN: , Oct [19] C. Portele. Geography markup language encoding standard. Open Geospatial Consortium, Inc, [20] Lake R. Kml and gml working together. acedido a 08/07/2009, 2007.

102 Bibliograa 87 [21] Christoph Schittko. Web service orchestration with bpel. Acedido em 28/04/2009, XML Conference and exposition, [22] L. Srinivasan and J. Treadwell. An overview of soa, web services and grid computing. HP Software Global Business Unit, [23] Beate Stollberg and Alexander Zipf. Geoprocessing services for spatial decision support in the domain of housing market analyses experiences from applying the ogc web processing service interface in practice [24] Erl T. Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Prentice Hall/PearsonPTR, [25] Liping D. ; Aijun C. ; Wenli Y. ; Peisheng Z. The integration of grid technology with ogc web services (ows) in nwgiss for nasa eos data

103 88

104 A.1. Modelo 1 usado actualmente pelas nanças 89 Apêndice A Documentos A.1 Modelo 1 usado actualmente pelas nanças Figura A.1: Impresso Modelo 1 primeira parte

105 A.1. Modelo 1 usado actualmente pelas nanças 90 Figura A.2: Impresso Modelo 1 segunda parte

106 A.2. Projecto de arquitectura 91 A.2 Projecto de arquitectura Figura A.3: Exemplo de um projecto de arquitectura A.3 Planta de implantação Figura A.4: Exemplo de um projecto de arquitectura

107 A.4. Planta de localização 92 A.4 Planta de localização Figura A.5: Exemplo de uma planta de localização

108 Apêndice B A Screenshots de interfaces B.1 Interface pedir pre-preenchimento Modelo 1 Figura B.1: Interface pedir pre-preenchimento do Modelo 1 do processo Avaliar IMI com erro de processo municipal Inexistente 93

109 B.2. Interface com código Postal errado e proposta de sugestão 94 B.2 Interface com código Postal errado e proposta de sugestão Figura B.2: Interface com código Postal errado e proposta de sugestão B.3 Interface pedir pré-preenchimento Modelo 1 Figura B.3: Interface m do processo Avaliar IMI

110 B.4. Interface inicial do processo Actualizar Proprietário de um Imóvel95 B.4 Interface inicial do processo Actualizar Proprietário de um Imóvel Figura B.4: Interface inicial do processo Actualizar Proprietário de um Imóvel B.5 Interface do processo Actualizar Proprietário de um Imóvel nal Figura B.5: Interface do processo Actualizar Proprietário de um Imóvel nal

111 B.6. Interface processo Actualizar Proprietário de um Imóvel com id processo municipal errado 96 B.6 Interface processo Actualizar Proprietário de um Imóvel com id processo municipal errado Figura B.6: Interface processo Actualizar Proprietário de um Imóvel com id processo municipal errado

112 B.7. Interface processo Actualizar Proprietário de um Imóvel com id da licença de utilização errado 97 B.7 Interface processo Actualizar Proprietário de um Imóvel com id da licença de utilização errado Figura B.7: Interface processo Actualizar Proprietário de um Imóvel com id da licença de utilização errado

113 B.8. Interface processo Actualizar Proprietário de um Imóvel com NIP errado 98 B.8 Interface processo Actualizar Proprietário de um Imóvel com NIP errado Figura B.8: Interface processo Actualizar Proprietário de um Imóvel com NIP errado