Enoque Moisés Quaresma Carvalho - files.isec.ptfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/teses/Tese_Mest_ Enoque... · Fiscalização Municipal I Agradecimentos Quero agradecer a

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Departamento de Engenharia Informática e de Sistemas

Mestrado em Informática e Sistemas

FISCALIZAÇÃO MUNICIPAL

Enoque Moisés Quaresma Carvalho

Estágio realizado no âmbito da unidade

curricular de Estágio/Projecto Industrial

do Mestrado em Informática e Sistemas

Coimbra, Dezembro 2009

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Departamento de Engenharia Informática e de Sistemas

Mestrado em Informática e Sistemas

FISCALIZAÇÃO MUNICIPAL

Enoque Moisés Quaresma Carvalho

Orientador DEIS/ISEC: Doutor Jorge Barbosa

Orientadores AIRC: Eng.º Pedro Nascimento

Eng.ª Helena Silva

Coimbra, Dezembro 2009

Fiscalização Municipal

I

Agradecimentos

Quero agradecer a Deus pela Sua protecção e constante cuidado.

À minha família que me ama e que me encorajou até este dia.

Ao meu fiel amigo e colega André Simões, por ter estado praticamente sempre do meu lado desde que nos conhecemos na pré-primária.

À minha querida Debinha por ser perfeita mesmo nos dias em que sente que não é.

Ao Pixiu pela amizade, constante boa disposição e por me obrigar a não desistir. És Super.

Aos meus orientadores Pedro Nascimento e Helena Silva pelo caminho percorrido e pela dedicação.

Aos colegas de estágio Ivo Santos, Eduardo Pratas e Bárbara Correia.

Aos colegas da AIRC José Cura, Nuno Silva, Luís Arede, Luís Costa.

Ao Doutor Jorge Barbosa.

A todos o meu obrigado


II

Resumo A Fiscalização Municipal é uma área importante em qualquer Município. Sendo esta área essencial e não existindo ainda uma aplicação que pudesse satisfazer as suas várias necessidades, foi criada a Gestão de Fiscalização Municipal (GFM). Este estágio pretende continuar o trabalho previamente começado nesta aplicação Windows. Sendo também pertinente o auxilio do fiscal no terreno foi criada uma aplicação para Windows Mobile, o Sistema Móvel de Fiscalização Municipal (mGFM).


III

Abstract A very important area in a Town Hall is the inspection of several issues, including construction sites. As this area is essential and as yet there is no application that could meet its needs, it was created the Gestão de Fiscalização Municipal (GFM), to provide inspectors with the proper tools to do their jobs. The objective of this internship is to continue the previous work on this Windows application. It's also relevant to aid the inspector on the field, and with that purpose in mind, it was created an application for Windows Mobile, Sistema Móvel de Fiscalização Municipal (mGFM).


IV

Acrónimos

Abreviatura Definição AFC AIRC Foundation Classes AIRC Associação de Informática da Região Centro

AIRC2000 Pacote de software autárquico, constituído por um conjunto de módulos aplicacionais que cobrem quase a totalidade do sistema de informação das autarquias.

CNA Comissão de Normalização da AIRC CLR Common Language Runtime COM Component Object Model CVS Concurrent Versions System DEIS Departamento de Engenharia Informática e de Sistemas DLL Dynamic-link library ou Biblioteca de ligação dinâmica DW Datawindow EDAFC Equipa de Desenvolvimento das AFC EPI Estágio/Projecto Industrial ERP Enterprise Resource Planning GFM Gestão de Fiscalização Municipal IGA Identidade Gráfica da AIRC IPC Instituto Politécnico de Coimbra ISEC Instituto Superior de Engenharia de Coimbra MIS Mestrado em Informática e Sistemas mGFM Sistema Móvel de Gestão de Fiscalização Municipal mSIC Sistema Móvel para Inventário OLE Object Linking and Embedding

PB PowerBuilder - ferramenta de desenvolvimento da Sybase, com programação orientada objectos, de aplicações Windows, onde existe uma forte interacção com Sistemas de Gestão de Bases de Dados Relacionais.

PBL PowerBuilder Library PFC PowerBuilder Foundation Classes PFE PowerBuilder Foundation Extension RAPI Remote Application Programmer's Interface SGBD Sistema de Gestão de Base de Dados SGD Sistema de Gestão Documental SPO Sistema de Processos de Obras SIC Sistema de Inventário e Cadastro Patrimonial SQL Structured Query Language WMDC Windows Mobile Device Center XML eXtensible Markup Language


V

Índice

Agradecimentos ...................................................................................................................................... I Resumo .................................................................................................................................................. II Abstract ................................................................................................................................................ III Acrónimos .............................................................................................................................................IV Índice de Ilustrações .............................................................................................................................VII Índice de Tabelas ................................................................................................................................. VIII 1. Introdução ...................................................................................................................................... 1

1.1. Contexto do Estágio ............................................................................................................... 1 1.2. Descrição da Entidade de Acolhimento .................................................................................. 1 1.3. Âmbito do Estágio .................................................................................................................. 2 1.4. Objectivos.............................................................................................................................. 3 1.5. Estrutura do Documento ........................................................................................................ 4

2. Planeamento e Gestão do Projecto ................................................................................................. 5 2.1. Coordenação e reuniões ........................................................................................................ 5 2.2. Equipa de Projecto ................................................................................................................. 5 2.3. Metodologia de Desenvolvimento.......................................................................................... 5 2.4. Plano de Desenvolvimento ..................................................................................................... 8

2.4.1. Formação .............................................................................................................................. 8 2.4.2. Programa de trabalhos......................................................................................................... 10 2.4.3. Calendarização das tarefas ................................................................................................... 10 3. Actividades Desenvolvidas ............................................................................................................ 11

3.1. Tecnologias e Ferramentas Utilizadas ................................................................................... 11 3.2. Definição do Problema ......................................................................................................... 12 3.3. Análise ................................................................................................................................. 12

3.4. Ambiente de Desenvolvimento ........................................................................................ 12 3.5. Arquitectura do Sistema da Aplicação Windows ............................................................... 13

4. Estágio Previamente Realizado ...................................................................................................... 15 4.1. Conceito de Informação ....................................................................................................... 15 4.2. Sistema de Processos de Obras ............................................................................................ 16 4.3. Sistema de Gestão Documental ............................................................................................ 17 4.4. Base de Dados ..................................................................................................................... 17 4.5. Manutenção ........................................................................................................................ 17 4.6. Fiscais e de Equipas de fiscalização....................................................................................... 18 4.7. Gestão ................................................................................................................................. 19 4.8. Consulta .............................................................................................................................. 19 4.9. Mapas ................................................................................................................................. 20


VI

4.10. Informação .......................................................................................................................... 20 4.11. Reclamação ......................................................................................................................... 21 4.12. Evento ................................................................................................................................. 21 4.13. Selecção de Participantes ..................................................................................................... 22 4.14. Área de Trabalho ................................................................................................................. 22

5. Trabalho Desenvolvido na GFM ..................................................................................................... 23 5.1. Implementação GFM ........................................................................................................... 23

6. Trabalho Desenvolvido na DLL....................................................................................................... 32 6.1. Arquitectura DLL de sincronização ....................................................................................... 32 6.1. Implementação DLL de sincronização ................................................................................... 33

7. Trabalho Desenvolvido na mGFM .................................................................................................. 34 7.1. Arquitectura Aplicação Windows Mobile .............................................................................. 34 7.2. Implementação Aplicação Windows Mobile ......................................................................... 34 7.3. Testes .................................................................................................................................. 42

8. Conclusões.................................................................................................................................... 43 8.1. Resultados do Estágio .......................................................................................................... 43 8.2. Principais Dificuldades ......................................................................................................... 44 8.3. Apreciação crítica do Estágio ................................................................................................ 44 8.4. Trabalho Futuro ................................................................................................................... 44

9. Referências Bibliográficas.............................................................................................................. 45 10. Anexos ..................................................................................................................................... 46


VII

Índice de Ilustrações Figura 14 - Esquema do scrum ................................................................................................................ 7 Figura 15 - Exemplo do modelo de heranças do framework AIRC ............................................................ 7 Figura 16 - Ambiente de desenvolvimento ............................................................................................ 13 Figura 17 - Arquitectura das PFC’s ......................................................................................................... 14 Figura 18 - Arquitectura das AFC’s ........................................................................................................ 14 Figura 19 - Arquitectura GFM................................................................................................................ 15 Figura 1 - Esquema do processo de Fiscalização .................................................................................... 16 Figura 2 - Exemplo de uma janela coddesc (Janela Tipos de Utilização) .................................................. 18 Figura 3 - Exemplo de uma funcionalidade de manutenção (Janela Tipos de Informação) ...................... 18 Figura 5 – Entidades por Tipo [Fiscais]................................................................................................... 18 Figura 6 - Gestão (Janela Manutenção de Informação) .......................................................................... 19 Figura 7 - Consultas (Janela Consulta de Informação) ............................................................................ 19 Figura 8 - Mapas ................................................................................................................................... 20 Figura 10 - Reclamação (Separador dos Reclamantes) ........................................................................... 21 Figura 11 - Evento................................................................................................................................. 21 Figura 13 – Área de Trabalho ................................................................................................................ 22 Figura 20 - Evento................................................................................................................................. 24 Figura 21 - Periodicidade (vista Semanal) .............................................................................................. 24 Figura 22 - Periodicidade (vista Mensal) ................................................................................................ 25 Figura 23 - Resumo da periodicidade criada .......................................................................................... 25 Figura 24 - Tipos de Eventos ................................................................................................................. 26 Figura 25 – Agenda (vista do Mês) ........................................................................................................ 26 Figura 26 - Submenu Agendar novo evento ........................................................................................... 27 Figura 27 - Agenda (vista do Dia) ........................................................................................................... 27 Figura 28 - Exemplo em que se devolveu uma equipa de fiscais ............................................................ 28 Figura 29 – Janela de Factos ................................................................................................................. 28 Figura 30 – Área de Trabalho ................................................................................................................ 29 Figura 31 - Área de Acompanhamento .................................................................................................. 29 Figura 32 - Pesquisa de Títulos de Processos de Obras .......................................................................... 30 Figura 33 – PDA (Enviar) ....................................................................................................................... 31 Figura 34 - PDA (Receber) ..................................................................................................................... 31 Figura 35 - Arquitectura DLL de sincronização ....................................................................................... 33 Figura 36 - Arquitectura mGFM............................................................................................................. 34 Figura 37 - Menu .................................................................................................................................. 35 Figura 38 - Área de Acompanhamento .................................................................................................. 35 Figura 39 - Carregar Processos .............................................................................................................. 36 Figura 40 - Processos ............................................................................................................................ 36 Figura 41 - Morada do Processo de Obra .............................................................................................. 37 Figura 42 - Nova Informação (Dados) .................................................................................................... 37 Figura 43 - Nova Informação (Data) ...................................................................................................... 38 Figura 44 - Nova Informação (Resumo) ................................................................................................. 38 Figura 45 - Informação (Entidade e Morada) ......................................................................................... 39 Figura 46 - Informação (nova Entidade e Morada) ................................................................................. 39 Figura 47 - Freguesias ........................................................................................................................... 40 Figura 48 - Pesquisar Morada e Nova Morada ....................................................................................... 40 Figura 49 - Novo Sítio e Nova Morada (morada em falta) ...................................................................... 41 Figura 50 - Pesquisar Informações ........................................................................................................ 41


VIII

Índice de Tabelas Tabela 1 - Equipa do Projecto ................................................................................................................. 5 Tabela 2 - Termos do scrum .................................................................................................................... 6


1

1. Introdução 1.1. Contexto do Estágio O presente relatório foi realizado no âmbito da unidade curricular de Estágio/Projecto Industrial do 2º Ano do Mestrado em Informática e de Sistemas (MIS) – Ramo de Tecnologias de Informação e do Conhecimento do Departamento de Engenharia Informática e de Sistemas (DEIS), no Instituto Superior de Engenharia de Coimbra (ISEC). O estágio foi realizado na Associação de Informática da Região Centro (AIRC), com uma duração de dois semestres. Foi iniciado a 4 de Maio de 2009 e teve a sua conclusão a 30 de Novembro de 2009. Este estágio foi realizado por Enoque Moisés Quaresma Carvalho e teve a orientação por parte do DEIS do Doutor Jorge Barbosa e por parte da AIRC do Engenheiro Pedro Nascimento e da Engenheira Helena Silva.

1.2. Descrição da Entidade de Acolhimento A AIRC é uma Associação de direito público, fundada por 30 municípios da região centro e cuja principal actividade é a produção de software e fornecimento de produtos e serviços preferencialmente dirigidos à administração pública local. A AIRC iniciou a sua actividade em 1982 para um número muito restrito de clientes, tendo registado um crescimento constante e atingindo, nesta data, cerca de 300 clientes pertencentes à administração pública, entre os quais cerca de 60% das Câmaras Municipais, 50% dos Serviços Municipalizados, mais de meia centena de Juntas de Freguesia e ainda outros organismos da administração pública, tais como Associações de Municípios e Regiões de Turismo. A AIRC possui uma estrutura composta por 80 profissionais altamente qualificados, tanto ao nível da investigação e desenvolvimento de projectos, como da assistência técnica ao utilizador. A experiência adquirida ao longo de 25 anos, conjugada com o elevado know-how dos seus profissionais, permitiu desenvolver um pacote de software de grande qualidade, denominado AIRC2000, constituído por um conjunto de módulos aplicacionais que praticamente abrangem a totalidade das áreas de negócio das entidades pertencentes à administração pública local. Este pacote de software começou a ser idealizado em 1998, sendo criado nessa altura um novo modelo conceptual de todo o sistema de informação das autarquias, baseado num sistema de gestão de base de dados relacional, capaz de servir de base ao desenvolvimento de todo o novo pacote integrado de software da AIRC. Nos últimos anos tem-se assistido a uma expansão da AIRC relativamente a outros domínios aplicacionais, nomeadamente:

Software Intranet e Internet vocacionado para soluções que permitam a comunicação e partilha de conhecimento dentro dos Municípios, bem como a difusão de informação de uma forma prática e simples num ambiente universal, com recurso ao Browser Internet; este género de software permite ainda uma solução de front-office desenvolvida para Intranets, tendo como objectivo principal a personalização e aceleração do processo de atendimento ao público nas Câmaras Municipais.


2

Sistemas Móveis direccionados para a mobilidade no acesso ao tratamento informático das aplicações do pacote de software AIRC2000, de forma a complementar as funcionalidades de aplicações como a Gestão de Stocks, Gestão de Inventário e a Leitura de Contadores de Água, recorrendo ao uso de ferramentas móveis (PDA, leitores portáteis, etc.);

Sistemas de Apoio à Decisão, sistemas baseados em DataWarehouses que possuem como principal objectivo a extracção de informação útil da Base de Dados relacional, vocacionada para satisfazer as necessidades de informação dos utilizadores das aplicações das áreas de Gestão de Recursos Humanos e da Contabilidade.

A par da vasta gama de produtos disponibilizados pela AIRC, esta oferece ainda um alargado conjunto de serviços que vão desde consultoria, assistência técnica e formação personalizada aos utilizadores dos clientes AIRC, com especial ênfase nos módulos aplicacionais do pacote de software AIRC2000.

1.3. Âmbito do Estágio A AIRC sentiu que era uma necessidade dos seus clientes terem uma aplicação que os auxiliasse no processo de Fiscalização Municipal. Alguns clientes manifestaram interesse em adquirir uma aplicação para tal efeito, pois actualmente não existe uma ferramenta que os possa auxiliar. O desenvolvimento desta aplicação já foi iniciado no âmbito de outro estágio. Este estágio pretende continuar esse projecto e desenvolver também um módulo para PocketPC, disponibilizando então uma solução móvel a ser usada pelos fiscais nas suas deslocações aos locais a serem inspeccionados. A Fiscalização Municipal envolve muitas áreas distintas: obras, publicidade, licenciamento de estabelecimentos, ambiente e trânsito. Estas diferentes áreas têm procedimentos comuns como a definição de fiscais, de equipas que efectuam as fiscalizações e a calendarização de fiscalizações, mas também têm especificações próprias bastante distintas como todo o processo de fiscalização e de documentação gerada. Assim pode-se considerar a Gestão de Fiscalização Municipal (GFM) uma aplicação onde estariam as partes comuns de todas as áreas de fiscalização e que contém módulos específicos para cada uma das áreas. Neste momento envolve apenas a área de obras particulares, mas no futuro ambiciona-se que abranja todas as áreas mencionadas. As tarefas da fiscalização consistem basicamente em verificar e dar informações sobre o estado das obras em curso no concelho, quer as licenciadas, ou ainda as obras que estão a decorrer sem licença ou seja irregularmente. Para além disso, os fiscais, também fazem parte de comissões de vistorias a alguns equipamentos públicos (estabelecimentos de dança, parques infantis, postos de combustível, etc). O desenvolvimento da GFM foi começado no âmbito de outro estágio, realizado por outra pessoa, e todo o trabalho previamente elaborado será descrito num capítulo próprio deste relatório. A GFM usa uma base de dados global, projectada para servir as diversas aplicações a integrar nos clientes AIRC. A aplicação foi desenvolvida para funcionar sobre a plataforma Windows, acedendo a uma base de dados residente num servidor, que numa primeira fase deve usar um SGBD (Sistema Gestor de Bases de Dados) Informix. Esta aplicação pertencerá ao conjunto de aplicações que constituem o ERP AIRC2000. Pretendeu-se portanto continuar o desenvolvimento da aplicação de Gestão de Fiscalização Municipal (GFM), formam implementadas funcionalidades como o Acompanhamento de Títulos e possibilitada a criação de Eventos. Foi também desenvolvida uma aplicação para PocketPC: o Sistema Móvel de Gestão de Fiscalização Municipal (mGFM). Com esta aplicação móvel é possível oferecer um meio pelo qual o


3

fiscal, nas suas deslocações aos locais de obras, possa registar todos os dados relativos a uma fiscalização. Foi também criada na GFM uma área de sincronização de dados entre o PC e o PocketPC que permite ao fiscal escolher que títulos enviar para o PocketPC a fim de serem fiscalizados e depois permite receber as informações registadas no PocketPC e as guardar na base dados do ERP.

1.4. Objectivos O estágio tinha como objectivos gerais:

Investigação e continuação do desenvolvimento de uma aplicação, para a plataforma Windows, para auxiliar a Fiscalização Municipal;

Investigação e desenvolvimento de um módulo, para a plataforma PocketPC, para auxiliar a Fiscalização Municipal;

Uso de duas linguagens de programação orientadas a objectos (Powerbuilder e C#); Trabalhar com bases de dados Informix e Microsoft SQL Server Compact Edition; Adquirir conhecimentos nas tecnologias utilizadas; Cumprir um determinado conjunto de tarefas que se consideram necessárias para uma boa

integração na equipa de desenvolvimento de software da AIRC. Após uma análise das necessidades, definiram-se os seguintes objectivos para a aplicação GFM:

Realização de uma gestão descentralizada (multiposto) da informação relativa às fiscalizações/vistorias efectuadas dentro de determinada área de actuação do Município;

Agenda e planeamento de fiscalizações, com seguimento do resultado e acções subsequentes. Registo de fiscalizações não previstas no planeamento;

Registo dos autos resultantes de cada fiscalização, e registo de eventuais acções imediatas como consequência da mesma (embargo de obra, encerramento de estabelecimento, …);

Integração com a aplicação de Contra-Ordenações para dar o devido seguimento e tratamento legal às infracções detectadas em cada fiscalização;

Permitir pesquisas sobre os dados, disponibilizando um leque variado de critérios de pesquisa, possibilitando a elaboração de mapas detalhados das fiscalizações efectuadas e restante informação associada, com relevância neste âmbito;

Os objectivos do módulo de mobilidade são os seguintes:

Registo das informações/participações resultantes de cada fiscalização;

Várias consultas para apoio aos fiscais no terreno, de forma a permitir a rápida identificação e registo dos dados de cada fiscalização;


4

1.5. Estrutura do Documento

O presente relatório de estágio encontra-se organizado em 6 capítulos, sendo eles: Introdução, Planeamento e Gestão do Projecto, Actividades Desenvolvidas, Conclusões, Referências Bibliográficas e Anexos. Esta estrutura pretende abordar de uma forma concreta o trabalho desenvolvido ao longo do estágio, dando o seguimento desde a ideia (proposta de estágio), passando pelo planeamento do projecto, o trabalho desenvolvido durante o estágio, e finaliza com as conclusões obtidas.

No Capítulo 1, Introdução, é realizada a introdução ao presente relatório de estágio, onde é mencionado o seu contexto, assim como uma descrição alargada da entidade de acolhimento, o âmbito e objectivos do estágio.

O Capítulo 2, Planeamento e Gestão do Projecto, visa apresentar as formas de coordenação realizadas durante o estágio, quais as metodologias de desenvolvimento utilizadas e o plano de desenvolvimento.

No Capítulo 3, Actividades Desenvolvidas, encontram-se descritas as diversas actividades desenvolvidas ao longo do estágio, desde a análise de requisitos, ferramentas e tecnologias utilizadas, passando pela implementação e testes.

O Capítulo 4, Estágio Previamente Realizado foca o que foi realizado no estágio que iniciou o desenvolvimento da GFM.

O Capítulo 5, Trabalho Desenvolvido na GFM mostra o trabalho elaborado neste estágio na aplicação GFM.

O Capítulo 6, Trabalho Desenvolvido na DLL mostra o trabalho elaborado neste estágio na DLL de sincronização.

O Capítulo 7, Trabalho Desenvolvido na mGFM mostra o trabalho elaborado neste estágio na aplicação móvel mGFM.

O Capítulo 8, Conclusões referem-se as conclusões obtidas com a realização deste estágio. Desta forma, as conclusões são divididas em 4 grupos: os resultados atingidos, as principais dificuldades sentidas ao longo do estágio e as soluções encontradas para as ultrapassar, uma análise crítica do estágio ao nível do trabalho desenvolvido e do desenvolvimento pessoal e as aspirações para o trabalho futuro.

O Capítulo 9, Referências Bibliográficas, contém uma listagem das referências bibliográficas utilizadas como fundamento de pesquisa para a realização deste estágio.

Os Anexos, refere-se à inclusão de diversos documentos que se consideram de apoio para uma análise mais detalhada do trabalho realizado neste estágio.


5

2. Planeamento e Gestão do Projecto 2.1. Coordenação e reuniões Ao longo do desenvolvimento do projecto foram efectuadas reuniões de acompanhamento do trabalho realizado, com o objectivo de garantir que o projecto estava a evoluir de acordo com o previsto. Essas reuniões podem ser classificadas em: reuniões de acompanhamento, reuniões de análise e definição de trabalho a realizar e reuniões de apresentação do trabalho realizado à Identidade Gráfica da AIRC (IGA). As reuniões de acompanhamento serviram para apresentar o trabalho realizado aos orientadores dentro da empresa. Foram reuniões em que todos os estagiários e respectivos orientadores participaram, estando também presente o Coordenador de Desenvolvimento da AIRC e o orientador do DEIS. As reuniões de análise e definição de trabalho a realizar foram realizadas com os orientadores da AIRC. Existiram também reuniões com a IGA para determinar o interface gráfico das aplicações.

2.2. Equipa de Projecto A tabela abaixo apresenta os elementos constituintes da equipa de projecto. Esta equipa é constituída pelos orientadores da AIRC, pelo estagiário e orientador do DEIS.

Nome Função

Doutor Jorge Barbosa Orientador DEIS/ISEC

Eng.º Pedro Nascimento Orientador AIRC

Eng.ª Helena Silva Co-orientadora da AIRC

Enoque Moisés Quaresma Carvalho Estagiário

Tabela 1 - Equipa do Projecto

2.3. Metodologia de Desenvolvimento Actualmente na AIRC é usado o Scrum como metodologia de gestão e planeamento de projectos. Anteriormente usava-se o RUP (Rational Unified Process). Na tabela 1 são descritos alguns termos para melhor compreender esta metodologia.


6

Daily Scrum Reunião diária em que os elementos da equipa partilham o que andam a fazer Product Backlog Lista de funcionalidades a serem implementadas no projecto Product Owner Pessoa que define as funcionalidades do produto e que lhes atribui prioridades Sprint Período de tempo no qual é desenvolvido uma série de actividades com um

objectivo específico Sprint Backlog Lista de tarefas, extraídas do Product Backlog, a realizar num Sprint Sprint Planning Meeting

Reunião realizada no início de um Sprint para planeá-lo

Sprint Retrospective Reunião, realizada no final de um sprint, depois do Sprint Review Meeting, para identificar o que funcionou no Sprint e o que pode ser melhorado

Sprint Review Meeting Reunião, realizada no final de um Sprint, para se apresentar o resultado do Sprint e avaliar o seu sucesso

Scrum Master Pessoa responsável por coordenar a equipa, garantir que não há impedimentos e que se verificam as melhores condições possíveis para o desenvolvimento do projecto

Scrum Team Equipa de desenvolvimento do produto

Tabela 2 - Termos do scrum

No Scrum os projectos são divididos em Sprints (normalmente mensais), que são períodos de tempo em que se desenvolve um conjunto de actividades. As funcionalidades a serem implementadas no projecto são descritas numa lista chamada Product Backlog, que pode ser actualizada ao longo do desenvolvimento do projecto, conforme as necessidades verificadas para o projecto. As funcionalidades são definidas pelo Product Owner. No início de cada Sprint faz-se uma reunião, Sprint Planning Meeting, na qual estão presentes o Product Owner, o Scrum Master e a equipa (Scrum Team), para planear o Sprint que se inicia. Nessa reunião o Product Owner determina prioridades para as funcionalidades do Product Backlog e descreve-as e a equipa selecciona as que será capaz de implementar. As tarefas que são para desenvolver ao longo de um Sprint passam-se do Product Backlog para o Sprint Backlog. O Sprint Backlog ajuda a dividir o trabalho pelos membros da equipa. Durante esta reunião a Scrum Team e o Product Owner definem aquilo que se tentará alcançar no Sprint com um objectivo. O Product Owner deve garantir que não vão aparecer novos requisitos ao longo do Sprint e quando este começar, a equipa deve-se manter concentrada apenas no objectivo traçado. Todos os elementos da equipa reúnem diariamente para fazer um Daily Scrum, que normalmente é feito de manhã. Deve ser sempre feita no mesmo local e à mesma hora. O objectivo desta reunião diária é partilhar o que foi feito no dia anterior, identificar constrangimentos e dar prioridade ao trabalho que se vai realizar nesse dia. Não se deve fazer do Daily Scrum uma reunião para resolução de problemas, como tal, as pessoas devem ficar em pé para não haver tendência a prolongar demasiado a reunião. Cada elemento da equipa deve dizer o que fez no dia anterior, o que vai fazer no dia actual e se há algum constrangimento ou problema que impeça o desenvolvimento do trabalho. Com estas reuniões diárias as pessoas conseguem ficar com uma boa noção do trabalho que foi feito e que ainda falta fazer. Caso haja constrangimentos o Scrum Master deve-os tentar tratar o mais rapidamente possível. No final de um Sprint é feito um Sprint Review Meeting, para a equipa apresentar as funcionalidades que foram implementadas e avaliar o sucesso do Sprint com base no que foi definido como objectivo.


7

Seguidamente é feito um Sprint Retrospective para identificar o que funcionou bem, o que pode ser melhorado e que acções se podem tomar para melhorar. Assim a equipa parte para o planeamento do próximo Sprint, reiniciando-se o ciclo.

Figura 1 - Esquema do scrum

Para além da metodologia de scrum, a AIRC tem um repositório com uma pasta para cada projecto onde fica guardada diversa documentação, como o modelo de base de dados e os documentos Product Backlog e Sprint Backlog entre outros. Relativamente à programação em si é usado Source Code Control (SCC) para permitir que vários programadores estejam em simultâneo a trabalhar no mesmo projecto. A AIRC possui a nível do PowerBuilder (a ferramenta de desenvolvimento), um framework comum a todas as suas aplicações. Esse framework foi criado com base nas bibliotecas disponibilizadas pela Sybase, implementadas sobre o PowerBuilder, e designadas por PFC’s (PowerBuilder Foundation Classes). Esse conjunto de bibliotecas originais foi, ao longo do tempo, reestruturado de acordo com as necessidades internas da AIRC, dando origem às AFC’s (AIRC Foundation Classes), um outro nível de bibliotecas, que foram desenvolvidas por uma equipa de programação da AIRC, a EDAFC (Equipa de Desenvolvimento das AFC’s). É este nível que constitui a base de construção das aplicações da AIRC. O nível PFE (PowerBuilder Foundation Extension) é composto por heranças das AFC’s para que seja possível o nível AFC manter-se comum e os programadores alterarem o nível PFE. Para além de poderem programar este nível também podem programar a nível da aplicação, no caso GFM, em que podem herdar objectos de níveis anteriores.

Na figura 3 apresenta-se um esquema do modelo de heranças de bibliotecas, que compõe o framework de desenvolvimento de aplicações da AIRC adaptado para este projecto. Os programadores apenas devem trabalhar nos últimos 2 níveis, PFE e nível da aplicação.

Figura 2 - Exemplo do modelo de heranças do framework AIRC


8

Os níveis PFC e AFC disponibilizam vários serviços ligados aos objectos, nomeadamente janelas e datawindows que permitem simplificar a realização de operações. O nível AFC permitiu acrescentar um conjunto de funcionalidades às PFC’s de forma a facilitar o trabalho do programador e criar software com maior potencial. Como tal o framework inicial contém um conjunto de bibliotecas que implementam funcionalidades comuns a todas as aplicações. Assim, a equipa de desenvolvimento tem desde logo uma aplicação com funcionalidades básicas e pode partir para a implementação das funcionalidades específicas para a aplicação em causa. Do framework comum inicial podem-se destacar algumas funcionalidades como:

Gestão de entidades; Gestão de utilizadores; Ligação à base de dados; Configuração de opções básicas e propriedades do sistema; Informações da aplicação e do sistema; Menu por defeito.

2.4. Plano de Desenvolvimento

2.4.1. Formação Durante o primeiro mês de Estágio, houve uma formação sobre a ferramenta de desenvolvimento PowerBuilder. Nesta formação foram focados os seguintes pontos:

Introdução ao PowerBuilder

o O que é o PowerBuilder o PowerBuilder VS VisualStudio

Casos Práticos o Diagrama de Classes / Conceito de Herança o Criar a estrutura no PowerBuilder e fazer o paralelo com o VisualStudio

Criação de um projecto em PowerBuilder o Ligação à Base de Dados o Criação de tabelas (Painter)

Utilização do IDE o Criação de Windows, UserObjects e controlo

Debug o Breakpoints, Watchs, Call Stacks

Funções & Eventos o Comparação entre funções e eventos o O porquê do Pré/Pós processamento

DataStore o DW External e Objectos não Visuais o Buffers o ItemStatus o Retrieve/Update

DataWindow o DropDownDataWindow o Eventos da DataWindow o Retrieve/Update


9

Ambiente de Desenvolvimento o Instalação da ADM e configuração do Informix SDK Client o Projecto PB e configuração do Database Profile o Incluir PFC´s no PB Help

Arquitectura de PFCs & AFCs Iniciar um projecto

o Ambiente Inicial o Mapeamento do app_manager o Definições de Variable Types da aplicação o Configuração do ficheiro INI

Processo de Save DropDownDataWindow Framework comum Entidades

o Tipos de Entidade o Janela de Entidades Geral o Configuração e Integração da Janela

Janela de Mapas Arquitectura de Serviços

o Tipos de Serviços o Funcionamento dos Serviços o Categorias de Serviços

Criação de serviços Arquitectura de WebServices no PB

o Arquitectura Geral o Arquitectura AIRC

Utilização de WebServices o Utilização de WebServices externos o Implementação de um componente o Deploy para diferentes servidores aplicacionais o Utilização de WebServices AIRC (HTTP) o Utilização de WebServices AIRC (IIOP)

Criação de um WebService Depois desta formação houve um dia destinado a avaliação através de duas provas práticas. Em cada uma das provas foi facultado um projecto do PowerBuilder com o Framework da AIRC em que era pedido que colocássemos certas funcionalidades a funcionar. Houve ainda outra formação em modelação de dados e normalização em que foi apresentado o sistema de base de dados usado pela AIRC e também a apresentação da ferramenta da Sybase PowerDesigner. Esta formação decorreu na tarde do dia 9 de Julho. Em Setembro foi realizada uma formação que focou todos os aspectos que constituem o desenvolvimento de uma aplicação móvel para PocketPC. Foram criados vários projectos que serviram para demonstrar o funcionamento de cada componente que é necessário ao funcionamento de uma aplicação para Windows Mobile. Foi criado um projecto no Powerbuilder onde era feita a exportação e importação de dados através de uma DLL de sincronização criada também para a formação. Esta DLL tinha por objectivo criar a base dados do PocketPC, inserir na mesma os dados provenientes do projecto exemplo no Powerbuilder e


10

transferir a base dados para o PocketPC. No Visual Studio 2008 foi criado um projecto para Smart Device em que eram apresentados os dados da base de dados criada pela DLL e era possível criar e editar novas informações. Estas novas informações foram devolvidas ao projecto no Powerbuilder através dos métodos existentes na mesma DLL que permitiam copiar a base de dados do PocketPC e exportar os dados para XML. No decorrer desta formação foram ainda apresentados todos os projectos de mobilidade da AIRC. Existem neste momento três soluções móveis: uma para inventário patrimonial, outra para recolha de leituras de contadores de água e uma para gestão de stocks.

2.4.2. Programa de trabalhos Para além das actividades ocasionais, deverá ser cumprido o seguinte plano de actividades para o desenvolvimento do projecto:

T1 – Análise – Análise e identificação dos problemas existentes.

T2 – Desenho – Apresentação de soluções de acordo com as necessidades recolhidas.

T3 – Implementação – Construção dos âmbitos identificados, considerando a definição e criação das diferentes fases de produção.

T4 – Testes e Validação – Execução de testes para validação das tarefas desenvolvidas.

T5 – Deployment – Disponibilização dos resultados.

2.4.3. Calendarização das tarefas As tarefas acima descritas, incluindo os testes de validação de cada módulo, foram planeadas de acordo com a seguinte calendarização:

Meses

Tarefas N+0 N+1 N+2 N+3 N+4 N+5 N+6 N+7 N+8

T1

T2

T3

T4

T5

Metas

INI

M1

M0

M2

M3

M0

M0

M0

M0

M0

M0

M0

M0

M0

M0

M0

M0

M4

M5


11

INI Início dos trabalhos M1 (INI + 4 Semanas) Tarefa T1 terminada M2 (INI + 8 Semanas) Tarefa T2 terminada M3 (INI + 28 Semanas) Tarefa T3 terminada M4 (INI + 30 Semanas) Tarefa T4 terminada M5 (INI + 34 Semanas) Tarefa T5 terminada

3. Actividades Desenvolvidas 3.1. Tecnologias e Ferramentas Utilizadas Durante o período de estágio, foram utilizadas diversas tecnologias e ferramentas necessárias à elaboração da aplicação pretendida e de outras tarefas indirectamente ligadas ao projecto. Neste capítulo são apresentadas as aplicações envolvidas, assim como uma pequena descrição das mesmas.

Microsoft Word Esta ferramenta foi utilizada para a elaboração dos documentos desenvolvidos ao longo do estágio, sendo proprietária da Microsoft Corporation.

Microsoft Excel O Excel foi utilizado para a elaboração de documentação desenvolvida ao longo do estágio, sendo propriedade da Microsoft Corporation.

Notepad++ O Notepad++ é um editor de código livre (e um substituto do Notepad), que suporta várias linguagens de programação. Foi utilizado para criação e edição de código SQL e C#. TortoiseCVS 1.8 Através desta ferramenta foi possível fazer o controlo de versões de ficheiros utilizados no projecto para permitir a sua partilha e resolver conflitos de edição.

PowerBuilder 11.2 O PowerBuilder é uma ferramenta de desenvolvimento de software, da Sybase, que possui uma vasta gama de recursos para programação de aplicações de arquitectura cliente/servidor em que exista uma forte interacção com base de dados. Foi usada para o desenvolvimento da aplicação GFM.

PowerDesigner 11 O PowerDesigner, também é uma ferramenta desenvolvida pela Sybase, útil para a modelação dos esquemas conceptuais e físicos da base de dados, assim como, na modelação do processo de negócio. Foi usado para a modelação da base de dados usada na aplicação GFM.

Informix 11.5 O Informix, da IBM, é um Sistema de Gestão de Base de Dados (SGBD) que aparenta grande estabilidade e fiabilidade, características fundamentais para suportar bases de dados de elevada dimensão. Foi o motor de base de dados utilizado no desenvolvimento da aplicação GFM.


12

Microsoft Visual Studio 2008 Professional Edition O Microsoft Visual Studio é um pacote de programas da Microsoft, para desenvolvimento de software, especialmente dedicado, ao framework .NET e às linguagens Visual Basic (VB), C , C++, C# (C Sharp) e J# (J Sharp). Foi usada no desenvolvimento da aplicação mGFM e da DLL de sincronização.

Microsoft Visual Studio Team System 2008 Team Explorer O Microsoft Visual Studio Team System 2008 é uma solução integrada de gestão do ciclo de vida da aplicação que permite aos membros de sua equipe colaborarem e se comunicarem de forma mais eficaz, garantirem a qualidade do software e obterem maior visibilidade sobre o ciclo de vida de desenvolvimento de softwares. Foi usada no desenvolvimento da aplicação mGFM e da DLL de sincronização.

Microsoft SQL Server Compact 3.5 SP1 O SQL Server Compact permite criar base de dados compactos que podem ser usados em computadores desktop e em dispositivos inteligentes. Ele compartilha um modelo de programação comum com outras versões do SQL Server. O SQL Server Compact oferece funcionalidade de base dados relacional: uma fonte de dados robusta, um processador para optimização de consultas, e conectividade confiável e escalonável. A aplicação mGFM e a DLL de sincronização usam este SGBD.

3.2. Definição do Problema Sentiu-se a necessidade de ter uma aplicação que agilizasse todos os processos que envolvem a Fiscalização Municipal. Neste âmbito foi criada uma aplicação, a GFM, que pretende colmatar todas as necessidades de um fiscal. Este estágio veio continuar o desenvolvimento dessa aplicação para Windows. O fiscal também necessita de algo que o auxilie nas suas deslocações a obras. Neste sentido é necessária a existência de uma aplicação móvel que o assista no terreno. Com esse propósito foi criada uma aplicação para Windows Mobile que permite registar todos os dados necessários de uma fiscalização.

3.3. Análise Para que fosse possível continuar o trabalho existente na GFM foi necessário estudar todo o progresso previamente alcançado no projecto. Foi necessário aprender alguns termos técnicos, tomar conhecimento da estrutura de tabelas da base de dados e compreender todo o processo de fiscalização. Para o desenvolvimento da aplicação Windows Mobile foi muito importante a análise das soluções de mobilidade já existentes.

3.4. Ambiente de Desenvolvimento O ambiente de desenvolvimento do projecto foi constituído por:

Uma máquina de desenvolvimento com: Informix ODBC Driver PowerBuilder PowerDesigner TortoiseCVS


13

Visual Studio 2008 Ferramentas de apoio ao projecto

Um servidor com o motor de dados (Informix); Um servidor que permite o repositório documental gerido pelo ToitoiseCVS; Um PocketPC Unitech PA600 com Windows Mobile 5.0

A figura seguinte representa o ambiente de desenvolvimento do projecto.

Figura 3 - Ambiente de desenvolvimento

3.5. Arquitectura do Sistema da Aplicação Windows

As aplicações desenvolvidas na AIRC em Powerbuilder são construídas de acordo com uma plataforma base já definida, criada com o objectivo de ter uma base de trabalho estável, baseada em hierarquias, a partir da qual são desenvolvidas as aplicações. De seguida vai ser feita uma descrição dessa arquitectura e dos seus conceitos básicos, assim como da forma como a GFM está integrada na mesma.

3.5.1. PowerBuilder Foundation Classes (PFC) e Extensions (PFE) O PowerBuilder apresenta um conjunto de objectos gerais que têm como objectivo facilitar o desenvolvimento de aplicações, e estão agrupados num conjunto de livrarias denominadas PowerBuilder Libraries (PBL’s). Estes objectos são criados e mantidos pela Sybase, essas alterações são feitas no nível base da arquitectura, ou seja, o nível das PowerBuilder Foundation Classes (PFC), e podem ser aplicados nas aplicações ou estendidos (conceito de herança, da programação orientada a objectos) através de um segundo nível as PowerBuilder Foundation Extensions (PFE). A alteração dos objectos no nível PFE não é afectada por alterações (correcções) que possam ser feitas pela Sybase uma vez que essas alterações são feitas a nível PFC, e por isso herdadas pelas PFE. Por este motivo é possível adicionar código aos objectos já existentes sem que este seja afectado por alterações nos níveis inferiores. Convém também referir que os objectos disponibilizados pelas PFC variam desde componentes visuais usados para construção de interfaces (janelas, botões, etc.), componentes a adicionar às janelas (calculadora, calendário, etc.), a serviços que possam ser utilizados para facilitar a programação (sincronização de dados, validações, etc.)


14

Figura 4 - Arquitectura das PFC’s

3.5.2. AIRC Foundation Classes A necessidade de criar uma plataforma estável que servisse como base a todas as aplicações da AIRC, levou a que a AIRC tenha decidido estender as capacidades existentes ao nível PFC criando um nível intermédio entre o nível base das PFC e o de extensão (PFE). Este conjunto de livrarias foi denominado AIRC Foundation Classes (AFC) e é desenvolvido e mantido pela Equipa de Desenvolvimento das AFC (a EDAFC).

Figura 5 - Arquitectura das AFC’s

3.5.3. Arquitectura GFM A arquitectura da aplicação GFM mantém a estrutura definida para as PFC, AFC e PFE, adicionando um novo nível onde vão ser definidos os objectos ou serviços criados especificamente para a aplicação GFM, ou objectos necessários para a aplicação GFM que sejam herdados do nível PFE e que sejam alterados ao nível da aplicação. As equipas de desenvolvimento da AIRC (com a excepção da EDAFC) apenas podem efectuar alterações no nível das PFE e da aplicação em que estiverem a trabalhar. No entanto, em alguns casos específicos os objectos estão preparados para serem adaptados a cada aplicação. Essas alterações devem ser feitas no nível PFE e, se for necessário, esses objectos podem ser herdados para o nível da aplicação e posteriormente alterados, neste caso herdam as alterações efectuadas no nível PFE. Um exemplo de uma situação em que as alterações devem ser feitas ao nível PFE, e posteriormente herdadas para o nível da aplicação, é o caso em que se pretenda que todas as janelas filhas da aplicação


15

tenham uma barra de ferramentas criada especificamente para a aplicação. Nesse caso deve ser definido no nível PFE a barra de ferramentas a usar e as restantes janelas herdadas para o nível da aplicação a partir da janela escolhida vão ter a mesma barra de ferramentas. Existe ainda uma PBL que inclui outros objectos gerais a todas as aplicações AIRC. Estes objectos foram criados e são mantidos pela EDAFC (tal como as AFC), e têm como objectivo disponibilizar um conjunto de janelas que permitam gerir informação comum a todas as aplicações AIRC, garantindo assim uma melhor integração entre as diversas aplicações. A existência de janelas comuns permite ainda que um utilizador de diversas aplicações disponibilizadas pela AIRC não tenha, por cada aplicação, janelas diferentes que tratem a mesma informação. Como se pode verificar na figura seguinte a arquitectura GFM está estruturada por camadas, e as alterações para a aplicação GFM devem ser feitas ao nível PFE e da aplicação.

Figura 6 - Arquitectura GFM

4. Estágio Previamente Realizado Neste estágio deu-se continuidade a um projecto começado no ano passado na AIRC por Ana Costa, no âmbito de uma cadeira de estágio do 5º ano da Licenciatura em Informática e Sistemas do departamento de Engenharia Informática e de Sistemas do ISEC. Antes de descrever o que já se encontrava desenvolvido é necessário apresentar o Conceito de Informação e apresentar o Sistema de Processos de Obras (SPO) e o Sistema de Gestão Documental (SGD). O SPO e o SGD pertencem ao conjunto de aplicações existentes no ERP da AIRC e têm algumas funcionalidades que a GFM utiliza.

4.1. Conceito de Informação É importante clarificar um conceito que vai ser usado posteriormente e que pode causar algumas dúvidas. Esse conceito é o da Informação. Vulgarmente usa-se o termo informação para designar


16

conhecimento, dados, factos. No contexto de Fiscalização o termo Informação é usado para definir algo muito específico. Um fiscal quando detecta uma irregularidade faz uma participação sobre ela. No âmbito de fiscalização de obras essa participação tem o nome de Informação.

Figura 7 - Esquema do processo de Fiscalização

Um processo de fiscalização poderá ter origem numa reclamação, ou numa Informação ou num auto de notícia. Vamos imaginar a seguinte situação: uma pessoa apresenta no Município uma reclamação de uma obra de um vizinho. Esta é registada e no Município é dado seguimento à mesma. Um fiscal deverá verificar se a reclamação tem fundamento e elaborar a sua informação ou participação. Essa informação pode ser movimentada por diferentes órgãos (internos ou externos ao Município) e caso se verifique que existe uma situação irregular, é criado um auto de notícia. No exemplo apresentado o que desencadeou a acção de fiscalização foi uma reclamação, mas esta pode ter origem numa informação, ou no caso de irregularidades ou contra-ordenações é gerado automaticamente o auto de notícia.

4.2. Sistema de Processos de Obras Como já foi referido a GFM pretende no futuro integrar todas as áreas que envolvem a Fiscalização Municipal. Neste momento apenas existe a integração com o Sistema de Processos de Obras (SPO) também pertencente ao ERP Airc2000. O controlo administrativo de Obras Particulares caracteriza-se por uma grande complexidade de procedimentos, sendo o principal propósito da aplicação SPO, simplificar todo o processo envolvente. O SPO pretende atingir os seguintes objectivos:

Reduzir o tempo de trabalho manual e aumentar o grau de precisão, permitindo gerar e alterar os documentos usuais das Obras Particulares Autárquicas;

Controlar automaticamente os processos de Obras Particulares, salientando-se as seguintes fases: Recepção de processos, Movimentação de processos e Informação ao público.


17

4.3. Sistema de Gestão Documental O SGD visa dar resposta a um dos pontos mais sensíveis das empresas ou organizações – a gestão de documentos. Essa gestão consiste em gerir todos os documentos produzidos ou recebidos por uma instituição, desde a sua passagem pelo registo central até à eliminação, independentemente do valor, suporte, formato ou frequência de utilização. Este sistema está no centro da integração de todas as aplicações AIRC, o que possibilita o registo, consulta e pré-visualização de qualquer documento gerado pelas aplicações Software AIRC 2000.

4.4. Base de Dados A AIRC possui um modelo de base de dados global e integrado no qual a informação considerada comum está contida em tabelas gerais, para optimizar o uso da base de dados pelas diversas aplicações e evitar a utilização de informação redundante. Para definir o modelo de dados para a aplicação GFM foi usado um modelo de dados da AIRC no qual foi necessário criar novas tabelas para a aplicação e relações entre elas. Foram efectuadas algumas relações com tabelas gerais e também com tabelas de algumas aplicações específicas como é o caso do SPO e do SGD. Já tinham sido criadas 23 tabelas para a aplicação GFM e foram usadas 4 tabelas gerais e 3 outras tabelas das aplicações referidas com as quais a GFM interliga. Em Anexo encontra-se um documento elaborado onde estão presentes todas as alterações à base de dados Informix.

4.5. Manutenção Foram previamente criadas uma série de funcionalidades de manutenção, isto é, possibilitar a inserção, alteração e remoção de dados de uma tabela específica da base de dados e que permitem devolver esses dados. São funcionalidades auxiliares mas fundamentais para efectuar a gestão de informação e que vão ser necessárias na caracterização de outras funcionalidades, com um carácter mais importante na aplicação. Como a AIRC possui um framework com vários objectos comuns a todas as aplicações, houve algumas funcionalidades que foram usadas na aplicação e que não foram criadas porque já existiam e apenas foram usadas ou adaptadas como é o caso das janelas coddesc e outras janelas gerais. As janelas coddesc são janelas que permitem efectuar com facilidade a manutenção de tabelas auxiliares em que apenas sejam efectuadas operações típicas (inserir, editar, eliminar, devolver) e podem ser utilizadas em modo de selecção e/ou manutenção. Algumas funcionalidades de manutenção são apresentadas em janelas gerais coddesc já criadas a nível AFC (Tipos de Construção, Tipos de Utilização, Tipos de Eventos, Tipos de Reclamação, Grupo de Factos).


18

Figura 8 - Exemplo de uma janela coddesc (Janela Tipos de Utilização)

Foram criadas também outras duas funcionalidades para manutenção chamadas Tipo de Informação e Factos. Existe no Framework da AIRC um tipo de janelas coddesc que poderia ter sido utilizado para as implementar, mas como se pretende fazer a verificação dos dados a devolver, nomeadamente se estão definidos como inactivos, as janelas foram criadas de raiz.

Figura 9 - Exemplo de uma funcionalidade de manutenção (Janela Tipos de Informação)

4.6. Fiscais e de Equipas de fiscalização No desenvolvimento da área que permite a gestão de Fiscais foi usada um objecto presente no Framework da AIRC chamado Entidades por Tipo. Nesta área estão presentes todos os fiscais existentes. Esta gestão está presente na janela de Equipas de fiscalização e tem como objectivo definir as equipas de fiscalização, em que cada equipa é composta por fiscais. Para tal usou-se a janela geral de Listas de Distribuição, presente nas AFC. Para seleccionar o fiscal a adicionar numa equipa é chamada a janela de Ficais.

Figura 10 – Entidades por Tipo [Fiscais]


19

4.7. Gestão As funcionalidades de gestão servem para fazer a manutenção de dados, isto é, permitem pesquisar dados de acordo com os critérios de pesquisa e também fazer a respectiva manutenção (criar novos dados, editar ou eliminar). As janelas de gestão desenvolvidas foram: Manutenção de Informações e Manutenção de Reclamações.

Figura 11 - Gestão (Janela Manutenção de Informação)

4.8. Consulta As funcionalidades de consulta servem para fazer pesquisa de dados. A nível de estruturação e funcionamento das pesquisas são similares às de gestão, mas não possibilitam a manutenção de dados. Foram implementadas as seguintes janelas: Consulta de Informações, Consulta de Reclamações e Consulta de Eventos.

Figura 12 - Consultas (Janela Consulta de Informação)


20

4.9. Mapas Foi desenvolvido também um mapa que permite efectuar uma listagem de dados de informações referentes a obras e imprimi-los.

Figura 13 - Mapas

4.10. Informação A funcionalidade Informação tem como objectivo efectuar uma nova Informação ou editar uma Informação já existente. Caso se seleccione que a obra sobre a qual se está a fazer a Informação é licenciada a aplicação permite aceder à janela Pesquisa de Processo de Obras, caso o SPO esteja instalado no cliente ou então permite preencher os dados manualmente. No caso da integração com o SPO ser possível, ao clicar no botão de Associar Processo é aberta a janela Pesquisa de Processo de Obras que permite identificar o processo de obras para o qual pretendo registar a informação. Existe uma opção Gerar documento, que como o próprio nome indica permite criar um documento. É possível definir o modelo de documento a usar. A aplicação também possui uma opção para formatar e colocar marcadores no modelo.

Figura 14 - Informação


21

4.11. Reclamação A funcionalidade Reclamação tem como objectivo efectuar uma nova reclamação ou editar uma reclamação já existente. Contem uma área com 3 tabpages. O primeiro para listar os reclamantes, permite adicionar, através da janela de entidades geral, e remover as pessoas que fazem a reclamação e em que se têm de escolher o reclamante principal. O segundo, idêntico ao primeiro mas para registar as pessoas de quem se esta a fazer a reclamação. O terceiro tem como objectivo agregar fotografias à reclamação como prova da mesma.

Figura 15 - Reclamação (Separador dos Reclamantes)

4.12. Evento A funcionalidade Evento tem como objectivo registar um novo evento ou editar um evento já existente. É composta por uma área para os participantes do Evento, à semelhança da janela de Nova Informação onde é possível adicionar fiscais a partir da janela Selecção de Participantes ou entidades a partir da janela de entidades geral. As restantes áreas são para as datas e horas do evento, para a morada do evento e para os dados do evento em si.

Figura 16 - Evento


22

4.13. Selecção de Participantes A funcionalidade de Selecção de Participantes tem como objectivo seleccionar os participantes de um evento ou de uma Informação. Permite efectuar uma pequena pesquisa pelo nome de um fiscal. Foi usada uma TreeView, um objecto para apresentar a informação de uma forma hierarquizada. No primeiro nível encontra-se apenas a distinção entre Equipas ou Fiscais. No segundo nível das Equipas encontra-se o nome das mesmas e no nível a seguir os fiscais pertencentes a cada uma das equipas. No segundo nível dos Fiscais encontra-se o nome de todos os fiscais existentes. Para o segundo e terceiro níveis a informação é carregada de forma dinâmica através dos dados existentes na base de dados. Após selecção na janela dos fiscais e/ou equipas que se pretendem como participantes é possível devolver estes dados.

Figura 17 - Selecção de Participantes

4.14. Área de Trabalho A área de trabalho tem como objectivo conter as funcionalidades principais da área da Fiscalização que se seleccionar. Esta janela é composta por várias zonas: uma para seleccionar a área de Fiscalização, outra para seleccionar a funcionalidade pretendida, outra com um calendário e os eventos do dia actual e uma zona dinâmica que é actualizada conforma a funcionalidade seleccionada. Essa zona dinâmica funciona como uma janela de gestão (explicada anteriormente) e foi implementada recorrendo a um objecto visual que contem os conteúdos que se pretendem mostrar. Importa ainda referir que esta janela é do tipo Sheet Window (um tipo de janela que permite abrir outras em simultâneo) pois assim o utilizador pode mantê-la aberta, enquanto acede a outras janelas.

Figura 18 – Área de Trabalho


23

5. Trabalho Desenvolvido na GFM 5.1. Implementação GFM Seguidamente serão descritas as funcionalidades desenvolvidas para a aplicação e para melhor entender o seu funcionamento, segue-se um conjunto de termos técnicos usados no desenvolvimento com a ferramenta PowerBuilder. Uma datawindow é um componente que permite ler e actualizar dados em tabelas de base de dados, bem como realizar consultas e servir como interface para o utilizador. Permite também a edição do seu SQL no próprio código da aplicação. Uma datawindow tabular é uma datawindow com os dados dispostos em formato de listagem/tabela em que cada linha corresponde a um registo. Uma datawindow freeform é uma datawindow com os dados dispostos de forma livre como se de um formulário se tratasse. Ao contrário da tabular que pode apresentar vários registos ao mesmo tempo a freeform apresenta apenas um registo. Numa datawindow treeview os dados são apresentados em grupos. Pode-se portanto recolher ou expandir vários registos ao mesmo tempo referentes ao mesmo grupo. Uma datawindow external é uma datawindow que não acede à base de dados e que pode ser tabular ou freeform. A aplicação foi portanto desenvolvida recorrendo ao uso da ferramenta de desenvolvimento PowerBuilder, com base no framework comum das aplicações AIRC e seguindo as normas da AIRC. As interfaces são as janelas e objectos que permitem realizar as funcionalidades pretendidas da aplicação. Á excepção da janela Área de Trabalho, todas as outras são do tipo Response Windows. Este tipo de janelas quando abertas mantêm-se activas sem permitir que outra janela da aplicação fique acessível enquanto o utilizador não fechar a janela activa.

5.1.1. Evento Para o fiscal é essencial ter uma forma de organizar e gerir todos os seus compromissos relacionados com as fiscalizações. Ele acompanha várias obras e desde o início da obra até ao final das mesmas, terá que visitar os locais várias vezes e no caso de verificar alguma irregularidade registar uma Informação. Os Eventos dão resposta a esta necessidade. Esta janela já existia mas o seu interface e o seu funcionamento foi alterado. Foi adicionada uma área onde é possível chamar a janela de Periodicidade (explicada a seguir) e então estabelecer as regras para criar um evento periódico. Isto é útil porque um fiscal tem a necessidade de visitar os mesmos locais regularmente e assim pode-se estabelecer com que periodicidade o evento ocorre. O método de gravação desta funcionalidade foi alterado. Foram criados objectos não visuais que permitem a gravação de vários eventos. Com o modo de gravação definido anteriormente não era possível gravar mais do que um evento, logo não era possível criar eventos periódicos. Assim são invocados métodos presentes num objecto não visual e são passados todos os dados a gravar na base de dados.


24

Figura 19 - Evento

5.1.2. Periodicidade Para criar um evento periódico basta na janela Evento clicar em Periodicidade. A funcionalidade de Periodicidade permite-nos definir todas as regras para criar eventos periódicos. A repetição do evento pode ser Semanal ou Mensal. No caso de se optar por uma periodicidade semanal pode-se escolher a que dias da semana se repete o evento. O evento pode não ocorrer todas as semanas, mas de 3 em 3 semanas por exemplo. Para que isso aconteça basta que se indique o intervalo, em semanas, da repetição do evento.

Figura 20 - Periodicidade (vista Semanal)

Escolhendo-se a periodicidade mensal temos duas opções. Na primeira pode-se escolher a que dia do mês se repete o evento. Na segunda opção há mais escolhas à disposição. Existem duas listas drop down com vários itens. Os itens da primeira lista são: primeira(o), segunda(o), terceira(o), quarta(a), última(o). Os itens da segunda lista são: dia, dia da semana, segunda-feira, terça-feira, quarta-feira, quinta-feira, sexta-feira. Visto existirem várias opções disponíveis podem-se criar várias periodicidades. Por exemplo, pode-se querer que um determinado evento se repita na primeira segunda-feira de cada mês, para isso escolhia-se na primeira lista o item primeira(o) e na segunda lista o item segunda-feira.


25

Figura 21 - Periodicidade (vista Mensal)

A Vigência da periodicidade é o intervalo de tempo para o qual vão ser criados os eventos. Escolhe-se a data de início e depois existem duas alternativas: ou se escolhe a data em que termina o período de tempo ou se indica qual o número de ocorrências que se pretende para o evento. Ao escolher uma data para o término da periodicidade o número de ocorrências é actualizado e o mesmo acontece ao definir o número de ocorrências a data também é actualizada. Para passar a informação da periodicidade entre a janela Evento e a de Periodicidade foi criado um objecto de atributos que contem toda a informação necessária.

Figura 22 - Resumo da periodicidade criada

Ao definir a periodicidade de um evento aparece na janela Evento um resumo das regras criadas para a definição da periodicidade. No caso da imagem acima foi definido uma periodicidade mensal que se repete a cada três meses na primeira segunda-feira de cada mês para o período apresentado. É ainda apresentado também quantas vezes ocorre o evento. É possível editar a periodicidade clicando em Periodicidade ou eliminar as regras definidas fazendo Remover periodicidade. A funcionalidade Periodicidade vai calcular todas as datas em que o evento ocorre. Essa informação é passada à janela Evento que na altura da gravação vai invocar métodos de objectos não visuais que tratam da gravação em base de dados dos eventos. Todos os eventos a gravar têm informação comum como os participantes ou a morada onde se realiza o evento. O que varia de evento para evento será a data de início e fim do evento.

5.1.3. Tipos de Eventos Nesta funcionalidade é possível gerir os tipos de Eventos, tendo a possibilidade de associar a cada evento uma cor. Existe também a opção de inactivar o tipo de evento.


26

Figura 23 - Tipos de Eventos

5.1.4. Agenda Para efectuar a manutenção de eventos foi implementada uma janela de calendário/agenda em que se pode clicar nos dias e inserir um novo evento para esse dia, ou clicar nos eventos já criados e fazer a sua manutenção. Como é algo que pode ser usado por várias aplicações essa funcionalidade foi implementada a nível AFC e a aplicação GFM foi das primeiras aplicações da AIRC a usar essa janela.

Figura 24 – Agenda (vista do Mês)


27

Esta janela tem três áreas distintas: a de Criação de Eventos à esquerda, a de Opções mais abaixo e a do Calendário do lado direito. Na primeira área está disponível todo o tipo de eventos que se pode criar. Os tipos de eventos podem estar activos ou inactivos. Não é possível criar eventos de tipos inactivos. Cada evento tem associado uma cor que é possível editar na janela de Tipos de Eventos. Na área de Opções pode-se fazer a consulta, manutenção e apagar um evento seleccionado na área de Calendário. É possível também escolher a data a visualizar quer seja escolhendo a opção Hoje ou Ir para data. Depois há a possibilidade de escolher um filtro e apresentar só eventos de acordo com o filtro escolhido. É possível escolher para filtro a data, hora ou designação do evento. A área Calendário tem duas vistas: a vista do mês e a vista do dia. Em qualquer uma das vistas é possível seleccionar um evento e fazer a sua consulta, manutenção ou eliminação clicando com o botão direito do rato sobre esse mesmo evento e escolhendo uma dessas opções no menu pop-up que aparece. Também é possível criar eventos clicando numa área livre de um dia, também com o botão direito do rato, e escolher no menu pop-up um tipo de evento a partir da opção Agendar novo evento. O submenu Agendar novo evento é criado dinamicamente a partir dos eventos activos lidos da base de dados. Esta alteração foi efectuada a nível AFC porque o número de itens no menu era fixo e assim são lidos os tipos de eventos activos da base de dados e consoante o seu número assim são criados os itens do menu.

Figura 25 - Submenu Agendar novo evento

Figura 26 - Agenda (vista do Dia)

5.1.5. Selecção de Participantes

A funcionalidade de Selecção de Participantes tinha alguns erros que foram corrigidos e foi mudado o seu modo de funcionamento quanto aos dados a serem devolvidos. Um dos erros existentes acontecia


28

quando se fazia Devolver e se tinha seleccionado um ramo da tree view e depois se retirava a selecção desse mesmo ramo. O resultado era que eram devolvidos os dados relativos a esse ramo, mesmo não estando seleccionado. Os dados que eram devolvidos podiam ter dois tipos: Equipa ou Fiscal. Foi alterado o evento associado ao botão Devolver para que em vez de devolver equipas devolvesse todos os fiscais dessas mesmas equipas. Foi feita esta alteração para que se possa, depois em várias janelas da aplicação, mostrar apenas informação que diga respeito a um determinado fiscal. Um dos exemplos é a apresentação dos eventos em que um determinado fiscal participa.

Figura 27 - Exemplo em que se devolveu uma equipa de fiscais

5.1.6. Factos A janela de manutenção de Factos tem uma área onde são apresentados os factos já existentes. Essa área era composta por uma datawindow tabular. Foi mudada para uma datawindow treeview, para que fosse dado mais ênfase à apresentação dos factos. Assim os factos agora são mostrados por grupos de factos.

Figura 28 – Janela de Factos

5.1.7. Área de Trabalho Na Área de Trabalho existe uma área que contém um calendário, a opção de adicionar novo evento e onde são apresentados os eventos para o dia actual. Foi alterado o modo de apresentação dos eventos do dia para que apenas sejam apenas mostrados os eventos referentes ao funcionário que efectuou login na aplicação. Os dias em que existem eventos estão realçados no calendário e ao clicar numa data é possível visualizar os eventos para essa data. Cada evento tem associada a cor do tipo de evento escolhido. Ao fazer duplo clique numa data acedemos à janela Evento para criação de um evento para essa data. Para editar um evento do dia seleccionado basta fazer duplo clique sobre ele.


29

Figura 29 – Área de Trabalho

5.1.8. Área de Acompanhamento

Na Área de Trabalho existem quatro áreas principais: Informação, Reclamações, Eventos e Acompanhamento. A área de Acompanhamento permite que o fiscal seleccione títulos de processos de obras através da janela Pesquisa de Processos. Nesta área então o fiscal terá acesso a todos os títulos que acompanha. Para criar uma Informação basta fazer uma pesquisa, seleccionar o título em questão e clicar em Nova Informação. O evento open da janela de Informação foi alterado para que ao efectuar esta operação todos os campos do processo sejam automaticamente preenchidos.

Figura 30 - Área de Acompanhamento


30

5.1.9. Pesquisa de Títulos de Processos de Obras Nesta janela temos uma área de pesquisa do lado esquerdo onde é possível pesquisar títulos do tipo alvará ou comunicação prévia ou por ambos os tipos. Estes são os tipos de título que, na legislação em vigor, dão direito ao requerente de realizar a operação urbanística (obra) que pretende. Temos também os outros critérios referentes ao processo de obras associado ao título. Seleccionando o título e clicando em Devolver o fiscal confirma que pretende acompanhar determinada obra. Mais uma vez foram criados objectos não visuais para a gravação na base de dados destes dados.

Figura 31 - Pesquisa de Títulos de Processos de Obras

5.1.10. PDA Esta é a funcionalidade que trata da sincronização com o PocketPC. Foi desenvolvida uma DLL, descrita mais à frente, que possibilita efectuar todas as operações que envolvem todo o processo de sincronização de dados com o PocketPC. Existem duas áreas: Enviar e Receber. Na área Enviar é possível pesquisar os títulos dos processos de obras que o fiscal já acompanha e desses títulos escolher quais enviar para o dispositivo móvel. O fiscal, se assim o pretender, pode adicionar para envio todos os resultados de uma pesquisa clicando no botão Adicionar Todos. A GFM cria todos os ficheiros XML necessários à exportação dos dados incluindo todas as Freguesias do concelho e suas Moradas, tipos de Utilização e de Construção. As Freguesias e suas Moradas foram convertidas para XML porque, como será visto na implementação da aplicação móvel, o fiscal pode criar uma Informação não licenciada ou seja para o caso de não existir processo de obra associado.


31

Figura 32 – PDA (Enviar)

A área de Receber permite a recepção das Informações registadas no PocketPC e a sua gravação na base de dados.

Figura 33 - PDA (Receber)


32

6. Trabalho Desenvolvido na DLL 6.1. Arquitectura DLL de sincronização A DLL de sincronização já referida e que é utilizada pela GMF foi desenvolvida no Visual Studio usando a linguagem de programação C#. No ambiente de desenvolvimento Powerbuilder é criado um OLEObject que é um objecto que funciona como proxy para uma API externa, neste caso a DLL criada. No modelo de sincronização de uma das aplicações móveis da AIRC, o Sistema Móvel para Inventário (mSIC), sempre que se pretende actualizar uma base de dados do PocketPC é necessário através da aplicação do PC (o Sistema de Inventário e Cadastro Patrimonial - SIC) exportar ficheiros de texto com as informações necessárias. A actualização é basicamente a conversão da informação existente nos ficheiros de texto exportados pela aplicação do PC para a base de dados existente no PocketPC (Microsoft SQL Server CE). Para fazer o retorno dos dados registados no PocketPC também são gerados ficheiro de texto que são depois lidos e interpretados pelo SIC e então são guardados na base dados do ERP. Na utilização do mSIC os utilizadores são sempre obrigados a efectuar quatro passos. Exportar dados para ficheiros de texto no SIC, importar os ficheiros de texto no PocketPC, exportar os dados registados no PocketPC e por fim importar os ficheiros de texto no SIC. Existe ainda outro problema. O processo de interpretação dos dados contidos nos ficheiros de texto e a sua inserção na base de dados do PocketPC é um processo lento. Esta operação como é efectuada no PocketPC está dependente das suas capacidades de processamento que é inferior às capacidades de processamento de um PC. Como a base de dados do PocketPC não se comporta como um servidor e como o sistema de ficheiros do PocketPC não é compatível com win32, não há forma de nos ligarmos directamente à base de dados através do Desktop. Sendo assim, a DLL tem de copiar o ficheiro correspondente à base de dados do Desktop para o PocketPC e/ou do PocketPC para o Desktop e manipular os dados da base de dados a usar no PocketPC, através de uma versão do SQLCE para Desktop, em função do que se pretende fazer: enviar ou receber os dados do PockectPC. Com o uso desta DLL de sincronização permite-se ao fiscal uma melhor experiência de interacção com todo o processo de sincronização de dados. Todo este processo de exportação e importação de dados na GFM é imperceptível para o utilizador. Basta um clique na janela PDA e todo o processo de envio/recepção é tratado sem que o utilizador necessite de efectuar outra qualquer operação. Todo o processamento é efectuado do lado do PC e não no PocketPC. Para que o envio de dados ocorra são realizados os seguintes passos no PC:

1. Verificar se o ActiveSync está ligado; 2. Converter para ficheiros XML todos os dados necessários; 3. Criar a base de dados do PocketPC; 4. Importar os dados presentes nos ficheiros XML para a base dados criada; 5. Transferir a base de dados através do ActiveSync para o PocketPC.

Para que a recepção de dados ocorra são realizados os seguintes passos no PC:

1. Verificar se o ActiveSync está ligado;


33

2. Transferir a base de dados através do ActiveSync do PocketPC para o PC; 3. Converter para ficheiros XML todos os dados necessários; 4. Importar os dados presentes nos ficheiros XML para a GFM;

O envio e recepção da base de dados do PocketPC é realizado através de uma biblioteca integrada na DLL de sincronização chamada OpenNETCF Desktop Communication Library. Esta biblioteca é open source e está disponível para download. Ela permite expor os métodos que o Active Sync ou o Windows Mobile Device Center (WMDC) oferecem para a manipulação de ficheiros entre PC e PockectPC. Este interface é chamado de Remote Application Programmer's Interface (RAPI).

Figura 34 - Arquitectura DLL de sincronização

Legenda: 1. Base de dados do ERP em Informix; 2. Ficheiros XML gerados para importação/exportação de dados; 3. Base de dados SQLCE que é transferida para o/do PocketPC através dos ActiveSync; 4. Base de dados SQLCE presente no dispositivo móvel; 5. OpenNETCF Desktop Communication Library cujas funções envolvem todas as acções sobre o

ActiveSync.

6.1. Implementação DLL de sincronização A DLL de sincronização foi implementada em C#. Tem métodos que permitem criar a base de dados temporária no PC, verificar se o ActiveSync está ligado ou seja se há conexão com o dispositivo móvel e as funções que permitem transferir a base de dados para e do PocketPC. O resultado do projecto de sincronização no Visual Studio consiste em dois ficheiros essenciais. A DLL e um ficheiro de registo. Para a criação do ficheiro de registo é utilizado um comando nas propriedades do projecto. É usado o executável regasm.exe (Assembly Registration tool) que está na pasta do Framework .NET. Esta ferramenta lê os meta-dados existentes dentro do assembly criado (a DLL) e adiciona as entradas necessárias ao registo do Windows, o que permite aos clientes Component Object Model (COM) a criação de código mais transparente. O comando usado nas propriedades do projecto para geração automática do ficheiro de registo (.reg) é o seguinte: set dnf=C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727 %dnf%\regasm $(TargetFileName) /regfile:$(TargetName).reg


34

Cada computador com a Common Language Runtime (CLR) instalado tem uma cache que tem o nome de Global Assembly Cache. Esta cache armazena assemblies designados especialmente para serem usados entre aplicações no PC. Para registar a DLL criada nesta cache é usado o executável gacutil.exe presente na directoria \Microsoft SDKs\Windows\v6.0A\bin\. Para que o registo da DLL na cache fosse mais fácil foi criado um ficheiro batch (.bat) com o seguinte conteúdo: cd bin\Debug "C:\Programas\Microsoft SDKs\Windows\v6.0A\bin\gacutil" /i mGFMsync.dll ECHO Pressione qualquer tecla para terminar. Pause > nul exit

7. Trabalho Desenvolvido na mGFM 7.1. Arquitectura Aplicação Windows Mobile Toda a lógica que corresponde a manipulação de dados foi colocada dentro de uma classe separada:

Figura 35 - Arquitectura mGFM

Para que a Aplicação, mGFM, aceda aos dados presentes na base de dados SQL Server CE terá sempre de utilizar os métodos existentes na classe de acesso a dados. Para executar um SQL select na base dados, a Aplicação tem de usar a instância da classe de acesso a dados para aceder ao método da mesma classe com esse propósito. Cada classe e janela só são criados uma vez para uma melhor gestão de memória do PocketPC. Cada objecto do tipo classe ou janela tem uma função com o nome instance, a qual verifica se existe ou não uma instância desse mesmo objecto. Se existir devolve o existente. Caso contrário cria uma instância. Então para aceder por exemplo a um método de nome metodobd da classe de acesso a dados é necessária sempre a invocação do método instance dessa classe.

7.2. Implementação Aplicação Windows Mobile De seguida serão apresentadas a classe Base de Dados e as funcionalidades de toda aplicação mGFM.


35

7.2.1. Classe Base de Dados A classe Base de Dados é a classe de acesso a dados da arquitectura da mGFM. Os seus métodos são usados para a gestão e manutenção dos dados na base de dados. Existe um método que permite verificar a existência da base de dados no inicio da aplicação.

7.2.2. Menu

Esta é a janela inicial da mGFM e o ponto de partida para todas as outras janelas e funcionalidades implementadas. Existem 4 áreas: Acompanhamento, Processos, Informações e Tabelas Auxiliares. Na janela ainda é possível aceder às mesmas áreas através do menu, no canto inferior esquerdo da janela. Para fechar a aplicação basta aceder também ao ícone correspondente na barra inferior da janela.

Figura 36 - Menu

7.2.3. Área de Acompanhamento

Ao aceder a esta área o fiscal tem uma janela de pesquisa onde pode pesquisar os processos que acompanha e que decidiu previamente enviar para o PocketPC para fiscalização.

Figura 37 - Área de Acompanhamento


36

Os critérios de pesquisa existentes são Processo, Nome e Morada. Existe também a possibilidade de não inserir nenhum critério e assim apresentar todos os processos existentes na base dados. Ao seleccionar um processo é possível criar ou editar a Informação correspondente a esse processo de obras.

7.2.4. Área Processos

Nesta área o fiscal tem acesso a todos os processos de obras. Antes de poder ver todos os dados relativos a cada processo, todos os processos são carregados para memória para que seja possível transitar de processo para processo rapidamente.

Figura 38 - Carregar Processos

A janela Carregar Processos permite, através da criação de uma thread para o efeito, que os dados relativos aos processos sejam lidos processo a processo.

Figura 39 - Processos

Depois de colocar todos os processos em memória são visualizados os dados relativos a um processo. O titular do processo e o seu número de contribuinte são mostrados no topo da janela. Usando o scroll


37

vertical o fiscal transita para outro processo. Tem também disponível um separador com os dados da morada do processo de obra.

Figura 40 - Morada do Processo de Obra

Nesta área também é possível criar ou editar uma informação existente.

7.2.5. Informação A janela Informação, acessível tanto da área de Acompanhamento como da área Processos, como referido, permite o registo de uma Informação/participação.

Figura 41 - Nova Informação (Dados)

No separador Dados existem quatro campos de preenchimento obrigatório. Número da Informação, Data, Tipo de Construção e Tipo de Utilização. Estes dois últimos são componentes do tipo ComboBox e os seus itens são lidos da base de dados. Para o preenchimento da Data foi usado o componente de calendário.


38

Figura 42 - Nova Informação (Data)

No separador Resumo o fiscal tem à sua disposição um campo, também de preenchimento obrigatório, onde poderá registar a participação.

Figura 43 - Nova Informação (Resumo)

Os separadores Entidade e Morada apresentam os dados relativos ao titular do processo e morada do processo de obra. Os campos destes dois separadores não possibilitam edição.


39

Figura 44 - Informação (Entidade e Morada)

Esta janela é ainda usada para registar Informações que não têm processo de obras associado, onde o fiscal pode criar uma Informação sempre que veja algo irregular. Por exemplo, numa das suas saídas periódicas vê uma obra que não tem identificado um título para a construção, vulgo obra ilegal, regista no PocketPC uma Informação que depois de transferida para o PC e registada na GFM, permite gerar um Auto de Notícia. Para criar uma nova informação sem processo de obra associado, acede-se através da Área Informações. As diferenças para uma informação relacionada com um processo de obra é que neste caso o fiscal, para além de inserir os dados da informação e o resumo, terá de inserir os dados relativos à entidade e morada.

Figura 45 - Informação (nova Entidade e Morada)

Para o preenchimento da morada o fiscal escolhe uma Freguesia na ComboBox respectiva e na ComboBox Morada são carregadas todas as moradas da freguesia seleccionada. Se a morada não existir é possível criar uma nova. A selecção da freguesia é possível através de uma janela desenvolvida para esse efeito, à qual se acede através do botão de três pontos (…) ao lado da ComboBox correspondente.


40

Figura 46 - Freguesias

A criação de nova morada é feita através do botão de três pontos ao lado da ComboBox Morada. Ao clicar nesse botão vamos para uma área de pesquisa de moradas. Ao clicar no botão Nova acede-se à janela Nova Morada.

Figura 47 - Pesquisar Morada e Nova Morada

Na janela Nova Morada a selecção da freguesia pode ser efectuada da mesma forma que na janela Informação. Também é possível criar um Sítio/Lugar.


41

Figura 48 - Novo Sítio e Nova Morada (morada em falta)

Depois de seleccionada uma freguesia, inserida a morada e seleccionado o sítio/lugar (opcional dado que podem haver moradas sem sítio/lugar), pode-se proceder à criação da nova morada. A janela Nova Morada é fechada e retorna-se à janela Pesquisar Morada podendo aí devolver a morada seleccionada (a que acabou de ser criada) para a janela de Informação.

7.2.6. Área Informações Na área Informações o fiscal tem acesso a todas as Informações registadas no PocketPC, e é possível como já foi referido a criação de uma informação sem associação a processo.

Figura 49 - Pesquisar Informações


42

7.3. Testes

Ao longo do desenvolvimento das aplicações efectuaram-se vários testes pontuais e informais para garantir determinados comportamentos por parte das mesmas. Os testes são feitos imediatamente após modificação de alguma funcionalidade, de forma a garantir o correcto funcionamento e coerência do código existente.


43

8. Conclusões

8.1. Resultados do Estágio Foram atingidos os seguintes objectivos na aplicação Gestão de Fiscalização Municipal:

Criação de uma Agenda para o fiscal planear e gerir os seus Eventos e planificar as suas fiscalizações, podendo estas serem periódicas ou não;

Gestão de Eventos a partir da área de trabalho da aplicação; Criação de uma área de Acompanhamento de Títulos de processos de Obras da aplicação SPO.

Pretende-se que nesta área estejam presentes todos os processos de obras que o fiscal acompanha;

Criação de uma área para a sincronização de dados com o PocketPC. Nesta área é possível escolher que processos passar para o dispositivo móvel e depois descarregar do PocketPC os dados provenientes de uma fiscalização;

Criação de uma DLL que é usada pela GFM para efectuar todas as operações que envolvem a manipulação dos dados a enviar e a receber do PocketPC.

Para o módulo PocketPC foram alcançados os seguintes objectivos:

Criação de uma área de Acompanhamento onde o fiscal pode pesquisar processos de obras e daí criar ou editar uma Informação/participação.

Criação de uma área em que todos os processos passados para o PocketPC são carregados e apresentada toda a sua informação. Nesta área é possível transitar rapidamente de processo para processo e saber se já existe ou não Informação para esse processo. Caso exista, permite-se a sua edição. Se não existe permite-se a sua criação.

Desenvolvimento de uma área para pesquisa das informações registadas e permitir a edição das mesmas. A partir desta área possibilitar a criação de uma Informação que não tem processo de obra associado. Para este caso é necessário a inserção dos dados relativos à entidade e à morada da obra.

Apesar de não ter sido possível atingir todos os objectivos propostos inicialmente para a aplicação Windows, na GFM foi feito um trabalho inédito na criação de uma DLL de sincronização e houveram requisitos que foram adicionados à implementação do Sistema Móvel de Gestão de Fiscalização Municipal. Os seguintes objectivos, inicialmente propostos, não foram concretizados pois foi dispendido mais tempo no desenvolvimento da aplicação mGFM, à qual foram adicionadas novas funcionalidades que não estavam previstas:

Realização de uma gestão descentralizada (multiposto) da informação relativa às fiscalizações/vistorias efectuadas dentro de determinada área de actuação do Município;

Registo dos autos resultantes de cada fiscalização, e registo de eventuais acções imediatas como consequência da mesma (embargo de obra, encerramento de estabelecimento, …);

Integração com a aplicação de Contra-Ordenações para dar o devido seguimento e tratamento legal às infracções detectadas em cada fiscalização;


44

O método de sincronização que foi implementado faz com que todo o processo seja muito mais simples e transparente para o utilizador. Não tem que efectuar mais do que dois passos para enviar e receber os dados, como já foi explicado. O principal requisito adicionado à mGFM é a criação de Informações sem processo de obra associado. Isto envolveu a criação de janelas para a criação e selecção da morada a associar à Informação. Foi também necessário criar novos métodos de inserção e actualização dos dados da base de dados relativos a este requisito. Este requisito não estava nos planos originais do planeamento de estágio mas ao ter sido realizado é uma mais-valia para a mGFM.

8.2. Principais Dificuldades A principal dificuldade encontrada no decorrer do estágio foi a adaptação à ferramenta de desenvolvimento utilizada, o PowerBuilder, devido à existência de pouca documentação de apoio, uma vez que não é uma ferramenta muito usada e por isso não existir muita informação sobre a mesma (nem mesmo na Internet). Inicialmente a adaptação à arquitectura das aplicações da AIRC levou algum tempo uma vez que, apesar de existir alguma documentação, existiam algumas funcionalidades e serviços em foi necessário consultar documentação relativa não só às AFC mas também relativa às PFC. À medida que essas funcionalidades foram implementadas em diversas áreas esta dificuldade foi sendo ultrapassada.

8.3. Apreciação crítica do Estágio Este estágio foi uma experiência enriquecedora a nível profissional e a nível pessoal uma vez que permitiu o contacto com uma empresa reconhecida a nível nacional, que possui equipas dinâmicas, e com processos de desenvolvimento bem definidos. Este conjunto de características permite uma fácil integração de alunos finalistas ao mercado de trabalho, e a metodologias de desenvolvimento actuais e de eficácia reconhecida.

8.4. Trabalho Futuro Como trabalho futuro pode-se apontar algumas funcionalidades importantes a adicionar à aplicação GFM:

Associar fotografias às reclamações; Movimentar Informações entre funcionários; Melhor integração com a aplicação do ERP Sistema de Gestão Documental; Registo dos autos resultantes de cada fiscalização, e registo de eventuais acções imediatas

como consequência da mesma; Integração com a aplicação de Contra-Ordenações para dar o devido seguimento e tratamento

legal às infracções detectadas em cada fiscalização; Para a aplicação mGFM:

Sincronização dos eventos da GFM com a Agenda do PocketPC permitindo assim que o fiscal para onde quer que vá tenha consigo os seus compromissos.

Alteração de alguns aspectos do interface gráfico.


45

9. Referências Bibliográficas [1] Documentação relativa às AFC´s, AIRC (documentação interna da AIRC) [2] “Guia de boas práticas para a interface das aplicações”, Janeiro de 2008, AIRC (documentação interna da AIRC) [3] “Normas de Análise”, Maio de 2008, AIRC (documentação interna da AIRC) [4] “Normas de Programação”, Outubro de 2000, AIRC (documentação interna da AIRC) [5] “PowerBuilder Foundation Classes Getting Started”, Julho 2004, Sybase (documentação do PowerBuilder) [6] “PowerBuilder Foundation Classes Library User´s Guide”, Junho 2001, Sybase (documentação do PowerBuilder) [7] “Rapi” http://rapi.codeplex.com/


46

10. Anexos

Documents

Enoque Moisés Quaresma Carvalho - files.isec.ptfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/teses/Tese_Mest_ Enoque... · Fiscalização Municipal I Agradecimentos Quero agradecer a