RELATÓRIO DE PROJECTO sobre WEB

DEPARTAMENTO DE INFORMÁTICA
Faculdade de Ciências - Universidade de Lisboa
Bloco C6 - Piso 3 - Campo Grande, 1749-016 Lisboa
Tel & Fax: 351.217500084
RELATÓRIO DE PROJECTO
sobre
WEB APPLICATIONS
realizado na
LINK CONSULTING
por
Bruno Manuel Duarte Bento
Universidade de Lisboa
Faculdade de Ciências
DEPARTAMENTO DE INFORMÁTICA
Faculdade de Ciências - Universidade de Lisboa
Bloco C6 - Piso 3 - Campo Grande, 1749-016 Lisboa
Tel & Fax: 351.217500084
RELATÓRIO DE PROJECTO
sobre
WEB APPLICATIONS
realizado na
LINK CONSULTING
por
Bruno Manuel Duarte Bento
Responsável pela FCUL: Eng. Pedro Antunes
Responsável pela LINK CONSULTING : Eng. José Afonso Pires
Lisboa, Junho de 2005
Agradecimentos
Agora que este estágio se encontra concluído, gostaria de deixar algumas palavras de
agradecimento às pessoas que tornaram a sua realização possível.
Em primeiro lugar, gostaria de agradecer o acompanhamento dado pelo coordenador do
projecto Engº João Assunção, pelo Director da Unidade de Portais & Intranets, Engº José
Afonso Pires e pelo Professor da Faculdade de Ciências da Universidade de Lisboa,
Pedro Antunes,
que tiveram a disponibilidade para rever e dar opiniões
sobre o
documento. Sem eles, o texto teria muitas mais gralhas do que certamente possui.
Gostaria de agradecer aos meus colegas de trabalho deste projecto e também, de um
modo geral, a todos os colegas da Unidade de Portais & Intranets, de entre os quais
destaco a Drª Cintia Cardoso, o Engº Paulo Monteiro e o Engº Paulo Mateus que
contribuíram significativamente para os conhecimentos que hoje possuo.
Finalmente, à minha família, um enorme pedido de desculpas por estar tão ausente e não
passar, nem de perto nem de longe, o tempo suficiente com eles. É devido a eles que posso
ser quem sou e a quem tudo devo.
Lisboa, Junho de 2005
Bruno Bento
Indíce
1
INTRODUÇÃO .....................................................................................................................6
1.1
1.2
1.3
1.4
APRESENTAÇÃO DO PROJECTO ............................................................................................... 7
INSTITUIÇÃO LINK ................................................................................................................. 7
ESTRUTURA DO RELATÓRIO .................................................................................................... 9
RESUMO DO TRABALHO REALIZADO ...................................................................................... 9
2
OBJECTIVOS DO PROJECTO E CONTEXTO DO TRABALHO .............................10
2.1
2.2
2.3
2.4
OBJECTIVOS DO PRÉ-PROJECTO ........................................................................................... 11
OBJECTIVOS DO PROJECTO ................................................................................................... 11
PLANO INICIAL DO PROJECTO ............................................................................................... 12
CONTEXTO DO TRABALHO..................................................................................................... 13
3
METODOLOGIA E CALENDARIZAÇÃO DO TRABALHO......................................16
3.1
3.2
3.2.1
3.2.2
3.2.3
3.2.4
3.2.5
3.3
3.3.1
3.3.2
3.4
3.4.1
3.4.2
3.4.3
3.5
METODOLOGIA DE GESTÃO DE PROJECTOS ......................................................................... 17
MODELO DE DESENVOLVIMENTO ......................................................................................... 17
FASE DE VISÃO..................................................................................................................... 18
FASE DE CONCEPÇÃO ........................................................................................................... 18
FASE DE IMPLEMENTAÇÃO................................................................................................... 19
FASE DE TRANSIÇÃO ............................................................................................................ 19
FASE DE OPERAÇÃO ............................................................................................................. 20
ANÁLISE DO RISCO ................................................................................................................. 20
IDENTIFICAÇÃO DOS RISCOS ................................................................................................ 21
GESTÃO DOS RISCOS ............................................................................................................ 21
RECURSOS ............................................................................................................................... 22
ORGANIZAÇÃO E CONTROLO DO PROJECTO ........................................................................ 23
RECURSOS DE HARDWARE ..................................................................................................... 25
RECURSOS DE SOFTWARE...................................................................................................... 25
CALENDARIZAÇÃO FINAL DO TRABALHO ............................................................................. 27
4
TRABALHO REALIZADO ...............................................................................................28
4.1 TRABALHO REALIZADO NO PRÉ-PROJECTO ......................................................................... 29
4.1.1 NA SONAE MCH .................................................................................................................. 29
4.1.2 NO PEP ................................................................................................................................ 30
4.1.3 NO EBANKA ......................................................................................................................... 30
4.2 TRABALHO REALIZADO NO PROJECTO ................................................................................. 32
4.2.1 ARQUITECTURA TECNOLÓGICA ........................................................................................... 32
4.2.2 .NET FRAMEWORK E LINGUAGEM C# .................................................................................... 33
4.2.3 ARQUITECTURA FÍSICA ........................................................................................................ 36
4.2.4 ARQUITECTURA LÓGICA ...................................................................................................... 36
4.2.5 PLANO DE TESTES................................................................................................................. 47
4.2.6 TRABALHO REALIZADO POR MIM ......................................................................................... 48
5
SUMÁRIO E CONCLUSÕES............................................................................................49
5.1
SUMÁRIO ................................................................................................................................. 50
Relatório do Projecto em Engenharia Informática
Página 4 de 62
Indíce
5.2
CONCLUSÕES .......................................................................................................................... 50
6
GLOSSÁRIO .......................................................................................................................51
7
BIBLIOGRAFIA E REFERÊNCIAS................................................................................53
7.1
7.2
ENDEREÇOS WEB .................................................................................................................... 54
LIVROS E DOCUMENTOS ........................................................................................................ 54
8
ANEXOS ..............................................................................................................................56
8.1
8.2
ANEXO I – MODELO DE DADOS .............................................................................................. 57
ANEXO II – FIGURAS .............................................................................................................. 58
Relatório do Projecto em Engenharia Informática
Página 5 de 62
1 INTRODUÇÃO
Relatório do Projecto em Engenharia Informática
Página 6 de 62
Introdução
Este documento relata o estágio efectuado por mim, aluno da Licenciatura em
Informática da Faculdade de Ciências da Universidade de Lisboa, na empresa link
consulting (LINK).
Neste capítulo faço a apresentação do estágio, uma descrição da estrutura do
relatório e uma pequena apresentação daquilo que fiz durante o estágio.
1.1 APRESENTAÇÃO DO PROJECTO
Este projecto visa a integração de alunos da FCUL, que tenham concluído os
primeiros quatro anos da Licenciatura em Informática, numa empresa do país, com o
objectivo de aí efectuar um Projecto em Engenharia Informática do Curso de
especialização profissional em Engenharia da FCUL.
A LINK foi uma das empresas que solicitou um estágio à FCUL no qual fui
integrado. O estágio desenrolou-se na Unidade de Portais & Intranets (UPI), durante um
período de 9 meses, desde 1 de Setembro de 2004 a 31 de Maio de 2005.
O projecto em causa é para o cliente Sistema Mutimunicipal do rio Lis do
Saneamento Integrado (SIMLIS), que pretende que seja construído um Sistema de
Informação com o objectivo de fazer a gestão de todo o seu processo de negócio.
O SIMLIS é uma empresa concessionária do Sistema Multimunicipal de
Saneamento do Lis com vista à recolha, tratamento e rejeição de efluentes dos municípios
de Batalha, Leiria, Marinha Grande, Ourém e Porto de Mós.
Um projecto de execução SIMLIS pode ser encontrado na Internet em
http://www.iambiente.pt/IPAMB_DPP/docs/SE131.pdf .
1.2 INSTITUIÇÃO LINK
Como já foi dito o estágio desenrolou-se na LINK, nomeadamente na UPI. Importa
referir, de forma resumida, a origem e quais as funções da LINK.
A LINK está situada na Av. Duque D’Ávila, 23, em Lisboa. Esta empresa teve
origem na transformação em estrutura empresarial dos Centros de Transferência de
Tecnologia do INESC da área de Informática e Computadores. Estes Centros tinham sido
criados em 1991 com base num contrato estabelecido com o PEDIP, no âmbito dos
Programas PEDIP. No espírito original do contrato com o PEDIP existia o objectivo de que
as actividades dos Centros de Transferência de Tecnologia viessem a ser totalmente
suportadas por mecanismos de mercado. Dado ser essa a situação dos Centros da área de
Informática e Computadores, no contexto da reorganização das actividades do INESC,
decidiram os respectivos sócios efectuar o “spin-off” destas actividades numa única
empresa, que veio a dar origem à LINK, cujo propósito foi procurar desenvolver este
património técnico.
A LINK, criada em 1999, é uma empresa de consultoria e serviços que intervém nas
áreas de consultoria, desenvolvimento e operacionalização de modelos de negócio
electrónico e em consultoria e desenvolvimento de infra-estruturas de Telecomunicações,
bem como soluções de Comunicações móveis e de Portais de Voz e WAP.
A LINK tem como “Missão” tornar os clientes líderes no alinhamento, integração,
eficácia e segurança dos seus processos com as Tecnologias de Informação, através da sua
Relatório do Projecto em Engenharia Informática
Página 7 de 62
Introdução
experiência, competência e continua inovação em consultoria e engenharia de sistemas de
informação. E como “Visão” ser reconhecida entre as melhores empresas de consultoria e
engenharia no sector das Tecnologias de Informação no país; procurada pelos clientes que
têm problemas complexos, pelos profissionais que aspiram a grandes desafios e pelos
investidores que pretendem um investimento sólido.
Os principais clientes são os seguintes:
Figura 1 – Principais clientes da LINK.
A LINK também aposta na penetração de novos mercados.
Figura 2 – Novos mercados onde a LINK aposta.
Relatório do Projecto em Engenharia Informática
Página 8 de 62
Introdução
1.3 ESTRUTURA DO RELATÓRIO
9 O primeiro capítulo é constituído pela a Introdução, onde é apresentado o
estágio, a apresentação da instituição onde decorreu, a estrutura do relatório e um
resumo do trabalho realizado;
9 O segundo capítulo apresenta os Objectivos do Projecto e o plano inicial que foi
elaborado para se atingir os mesmos. Adicionalmente desenvolve o Contexto de
Trabalho do Projecto, tratando-se no essencial de uma introdução técnica ao tema;
9 No terceiro capítulo é relatada a Metodologia de Trabalho usada no
desenvolvimento do mesmo e a respectiva Calendarização;
9 O quarto capítulo apresenta o Trabalho Realizado em fase de pré-projecto, do
qual resultou na integração em equipas de projecto e liberdade de autonomia, e na
fase de projecto, documentando aquilo que foi feito e quais as ferramentas
utilizadas. Apresenta as várias abordagens estudadas para atingir os objectivos
definidos e detalha aquela que foi escolhida. Refere também qual a minha
colaboração concreta no projecto;
9 O quinto capítulo apresenta um Sumário daquilo que foi feito e adicionalmente
relata a Conclusão do Relatório;
9 Por fim, são apresentados o Glossário, a Bibliografia e os Anexos usados.
1.4 RESUMO DO TRABALHO REALIZADO
De uma forma breve e sucinta, podemos dividir o estágio em duas fases. Na
primeira, com a duração de cerca de 2 meses, para autoformação (com acompanhamento)
em novas tecnologias e integração em equipas de projectos para a realização de pequenas
tarefas. E a segunda, para a construção da aplicação para gestão de todo o processo de
negócio do SIMLIS.
Por fim, o último mês de estágio, foi passado a realizar um relatório sobre todo o
trabalho efectuado no período de estágio.
Relatório do Projecto em Engenharia Informática
Página 9 de 62
2 OBJECTIVOS DO
PROJECTO E
CONTEXTO DO
TRABALHO
Relatório do Projecto em Engenharia Informática
Página 10 de 62
Objectivos do Projecto e Contexto do Trabalho
2.1 OBJECTIVOS DO PRÉ-PROJECTO
Esta secção encarrega-se de apresentar os objectivos da fase de pré-projecto de uma
forma resumida.
Os objectivos focaram com aspectos tecnológicos bem como os relativos a questões
de metodologia de trabalho.
Do mencionado anteriormente destacam-se:
9 Aprendizagem da plataforma .Net, em particular dos WebServices;
9 Desenvolvimento de competências de programação;
9 Interiorizar a metodologia de desenvolvimento de projectos.
Em termos da integração na equipa de projecto, foram definidos os seguintes
objectivos:
9 Análise de documentos de requisitos a fim de alcançar o desenvolvimento de
componentes;
9 Autonomia na realização de tarefas de desenvolvimento;
9 Realização de testes unitários aos componentes desenvolvidos;
9 Elaboração do manual do utilizador.
2.2 OBJECTIVOS DO PROJECTO
Nesta secção serão descritos os objectivos da fase de projecto. Sabe-se que o
objectivo principal é o resultado prático do projecto, ou seja, uma aplicação informática
útil para o SIMLIS e que siga as especificações efectuadas e aprovadas.
Contudo, é importante mencionar outros objectivos que estiveram sempre presentes
e que são:
9 A integração numa equipa de projecto;
9 Contacto com a documentação funcional e técnica;
9 Aprofundamento da capacidade de redacção de relatórios;
9 Adquirir experiência profissional.
De seguida será efectuada a descrição, de uma forma mais pormenorizada, os
principais objectivos deste projecto, no que toca ao aplicativo a implementar.
Actualmente os colaboradores do SIMLIS têm a necessidade de aceder a diversa
informação díspar e não relacionada, contida nos imensos volumes de processos existentes.
Relatório do Projecto em Engenharia Informática
Página 11 de 62
Objectivos do Projecto e Contexto do Trabalho
Por vezes alguns processos podem estar entregues a uma entidade externa por um
determinado período de tempo, tornando impossível a sua consulta e mesmo tornando
difícil o controlo dos prazos estipulados. Por outro lado, os processos que se encontram no
SIMLIS nem sempre se encontram à disposição e em bom estado de conservação ou não se
sabe onde estão armazenados, demorando por vezes muito tempo até que se encontrem.
Estes problemas são facilmente ultrapassados, com a ajuda de uma Base de Dados
Relacional e uma aplicação para gerir a mesma.
A solução apresentada tem como objectivo reduzir a circulação do volume de papel
em que assentam os processos, diminuir o tempo de apreciação dos processos de
constituição de expropriação e ter um registo sobre os contactos efectuados, registo da
documentação e controlo de pagamentos, e que sirva de apoio à decisão com base em toda
a informação e historial que a Base de Dados disponibiliza.
No que toca a aspectos técnicos, a interface da aplicação perante o utilizador é
baseada em HTML produzido por ASP.NET. A partir das páginas ASP.NET pode-se aceder
a toda a informação armazenada na Base de Dados (SQL Server 2000 SP2 com Reporting
Services), bem como efectuar a gestão dos dados.
Uma das grandes vantagens de se ter utilizado documentos ASP.NET no sistema
WWW é que permite o acesso à informação através de diversos locais e podendo
eventualmente aceder com diversos dispositivos. Deste modo, os utilizadores podem
aceder à informação a partir de qualquer PC instalado no interior do SIMLIS ou através de
um PC externo com ligação à Intranet (caso sejam cumpridos todos os requisitos em
termos de configuração de rede e segurança).
Com este sistema a SIMLIS pretende atingir os seguintes resultados:
9 Importar a informação contida em Excel para um repositório único;
9 Registar, Pesquisar e Consultar informação relativa a Parcelas e Interessados;
9 Registar e controlar os pagamentos a titulo de indemnização e compensatórios
efectuados aos proprietários;
9 Registar a obtenção de licenças RAN, REN, DH;
Este projecto foi elaborado por uma equipa de consultores. No capítulo 4.2.6, são
apresentadas as funcionalidades implementadas por mim durante o projecto. As
funcionalidades a implementar no futuro são descritas no capítulo 5.1.
2.3 PLANO INICIAL DO PROJECTO
O planeamento de um projecto é algo bastante importante e que nos dá uma
perspectiva do tempo necessário, recursos e riscos envolvidos na elaboração do mesmo. O
plano do projecto é algo que será actualizado ao longo do tempo.
O modelo de desenvolvimento da aplicação é constituído por diversas fases que
serão abordadas com maior detalhe no capítulo 3.2.
Relatório do Projecto em Engenharia Informática
Página 12 de 62
Objectivos do Projecto e Contexto do Trabalho
ID
Task Name
22
1
2
'04 Dec
29 06 13 20
27
'05 Jan
03 10
17
'05 Feb
24 31 07
SMLS_04_0269
Gestão do Projecto
3
Planeamento
4
Start Up
5
Controlo
01-27
6
Encerramento
01-28
7
Desenho e Concepção
8
Levantamento das Interfaces Aplicacionais
9
Elaboração da Arquitectura de Informação
10
Arquitectura de Informação Aprovada
11
Especificação de Requisitos Funcionais
12
Especificação de Requisitos Funcionais Aprovada
13
Elaboração do Guião Interactivo
14
Guião Interactivo Aprovado
15
Concepção do Design Gráfico
16
Design Gráfico Aprovado
17
Desenho dos Ambientes e Sistemas
18
Desenho dos Ambientes e Sistemas Aprovado
19
Especificação de Testes de Aceitação
20
21
11-26
12-02
12-03
12-07
12-09
Desenho Técnico
Desenvolvimento
22
Desenvolvimento e Parametrização
33
Importação de dados
34
Fim do Desenvolvimento
35
Testes de Integração
36
11-24
01-10
Transição
37
Infra Estrutura
38
Documentação
39
Formação
40
Testes de Aceitação
41
Correcções
42
Entrada em Produção
01-27
Figura 3 – Calendarização Inicial
A Calendarização apresentada anteriormente trata-se da Calendarização Inicial
proposta pela equipa LINK tendo em conta os requisitos e envolvimento da equipa do
cliente.
No capítulo 3.5 é apresentada a Calendarização Final, que corresponde ao
verdadeiro tempo despendido no projecto.
2.4 CONTEXTO DO TRABALHO
Em termos de localização, o projecto desenrolou-se na UPI (instalações da LINK) e
por fim é instalado nas instalações do cliente SIMLIS em Leiria.
Ao longo deste capitulo, vou desenvolver o principal objecto de trabalho, Servidões
e Expropriações, sobre o qual incidiu o trabalho.
Dizer que o processo de Expropriação consiste na aquisição de uma propriedade
privada mediante o pagamento de uma indemnização e o processo de Servidão consiste na
autorização de passagem de tubagens pelo terreno de outrem, é algo demasiado vago. É
preciso referir todas as entidades que são envolvidas e como funcionam.
Relatório do Projecto em Engenharia Informática
Página 13 de 62
Objectivos do Projecto e Contexto do Trabalho
De seguida irei descrever, detalhadamente, o propósito de cada um dos tipos de
entidades envolvidas e como funcionam.
9 Subsistema é um conjunto de todas as infra-estruturas com unidades finais de
tratamento (bastar ter uma ETAR para já ser um subsistema, no entanto, poderá
ainda ser constituído por Estações Elevatórias, ETAR e Emissários), do sistema de
saneamento da área de intervenção do SIMLIS.
9 Projecto é uma empreitada de execução de determinadas infra-estruturas dos
diversos subsistemas. Um mesmo projecto poderá envolver obras em diversos
subsistemas.
9 Infra-estrutura responsável pelo transporte efluente. Uma infra-estrutura
pertence a um único subsistema e projecto e pode ser construída em várias parcelas.
9 Parcela representa uma área de terreno necessário para a implantação da infraestrutura. Numa parcela é construída somente uma infra-estrutura e pode ser
possuída por vários interessados. Se não existir acordo para a utilização da parcela
com pelo menos um dos interessados então a parcela encontra-se em litígio.
9 Confrontações consiste na identificação de objectos/terrenos que confinam com
a parcela.
9 Litigio é o conjunto dos processos legais para a entrada no terreno e registo da
servidão no caso de não existir acordo. O processo de litígio é único por parcela e é
decomposto em dois processos sequencias, Vistoria e Arbitragem, que pode ser
resolvido a qualquer altura.
9 Vistoria é a identificação de todas as características da parcela por um perito
nomeado pelo tribunal. Se após este processo se mantiver o litígio então será
despoleta a arbitragem.
9 Arbitragem é a avaliação da parcela por um perito nomeado pelo tribunal, onde
o perito vai avaliar a parcela e emitir o relatório a enviar para o tribunal, para o
SIMLIS e para os proprietários. Após este processo o valor de indemnização será
estabelecido pelo tribunal. O processo de litígio é concluído sem no entanto se ter
chegado a acordo com os interessados.
9 DUP é a Declaração de Utilidade Pública emitida pelo Ministério do Ambiente.
Para este processo é necessário juntar determinados documentos dos quais vão ficar
registados os seguintes:
o Licenças de RAN e REN no caso de existir alguma parcela com estas
naturezas;
o Publicação dos Editais;
o Garantias Bancárias;
o Primeira notificação aos interessados das parcelas que não têm acordo.
Relatório do Projecto em Engenharia Informática
Página 14 de 62
Objectivos do Projecto e Contexto do Trabalho
A DUP é pedida para cada infra-estrutura com parcelas sem acordo e todos
os interessados dessas parcelas notificados. Após a obtenção de DUP, é associada
às parcelas, da infra-estrutura, que ainda não tenham DUP definida, a identificação
da DUP obtida.
9 Interessados são todas as entidades envolvidas na parcela (proprietário,
arrendatário, procuradores e outros utilizadores) . Um interessado só existe no
contexto de uma parcela. A mesma entidade se associada a mais de uma parcela, é
tratada como sendo interessados diferentes. Um interessado pode ser contactado
pelo SIMLIS várias vezes.
9 Contacto identifica uma comunicação entre o SIMLIS e um interessado. Um
contacto somente é efectuado a um interessado, se uma mesma carta for enviada a
múltiplos interessados de uma parcela, resulta em vários contactos efectuados. Cada
contacto contem as referências dos documentos enviados ao interessado. Um
contacto pode ter mais do que um documento enviado.
9 Pagamento identifica um pagamento efectuado pelo SIMLIS no âmbito de
obtenção de contracto de servidão para uma parcela. Um pagamento somente é
efectuado para uma parcela. Cada pagamento contem referências dos documentos
associados ao pagamento. Um pagamento pode ter mais do que um documento
associado. Pagamentos com valores negativos são recebimentos.
9 Pedido Pagamento é o conjunto de todos os documentos que comprovam a
ocorrência das despesas elegíveis das respectivas candidaturas aos fundos
comunitários e que permitem receber os respectivos subsídios. Um pedido
pagamento é o conjunto de todas as despesas.
9 Despesa é o conjunto de todos os documentos que comprovam a ocorrência das
despesas elegíveis por parcela e tipo de pagamento. Uma despesa é associada a um
pedido de pagamento. Para um mesmo pedido de pagamento e parcela uma despesa
de uma dado tipo é única.
9 Correspondência é a entidade que representa um contacto de correspondência
do SIMLIS. Correspondência é de entrada, do exterior para o SIMLIS.
Correspondência é de saída, do SIMLIS para o exterior identificada por nº de ordem
interno indexado ao ano. Correspondência é sempre dirigida a um destinatário.
9 Referência Documento identifica a referência para um documento físico
arquivado. Várias entidades contêm referências a documentos nomeadamente:
o Parcela – documentos associados a uma parcela;
o Pedido DUP – documentos manipulados no âmbito de um pedido DUP;
o Contacto – notificações, documentos enviados a interessados de parcelas;
o Pagamento – documentos associados a pagamentos.
Relatório do Projecto em Engenharia Informática
Página 15 de 62
3 METODOLOGIA E
CALENDARIZAÇÃO DO
TRABALHO
Relatório do Projecto em Engenharia Informática
Página 16 de 62
Metodologia e Calendarização do Trabalho
3.1 METODOLOGIA DE GESTÃO DE PROJECTOS
A LINK, consciente da importância da gestão dos seus projectos, engloba na sua
estrutura organizacional uma área designada por Project Support Office (PSO). O PSO tem
como missão garantir a qualidade da gestão dos projectos LINK, desenvolveu uma
metodologia para esse efeito e tem vindo a desenvolver sistemas de informação de suporte
à mesma.
O modelo de gestão de projectos da LINK, encontra-se representado na Figura 4 Metodologia de Gestão de Projectos da LINK, no anexo II - Figuras. Este modelo resulta
da adaptação do modelo seguido pelo Project Management Institute (PMI) e é aplicável a
qualquer tipo de projecto, independente da tecnologia envolvida.
Podemos observar que o modelo divide-se em cinco macro-processos que respeitam
ao arranque do projecto, ao planeamento, execução, controlo e encerramento do projecto.
Entre os processos de execução e de controlo verifica-se um ciclo que só é
quebrado quando estão criadas as condições, de acordo com o plano de projecto, para se
passar ao processo de encerramento, ou quando é assegurada pelos fluxos de reporting de
progresso da execução dos trabalhos, dos quais é obtido feedback que se poderá traduzir na
aprovação dos trabalhos executados ou em pedidos de correcção.
Cada um dos macro-processos acima referenciados encontra-se detalhado no
documento de referência da Link Consulting (2004) - “Metodologia de Gestão de
Projectos”, que não está disponível*.
3.2 MODELO DE DESENVOLVIMENTO
O desenvolvimento de software é um processo complexo, que não deverá ser
realizado ao acaso, sendo tomadas decisões apenas quando preciso, ou dependendo
totalmente na qualidade das tecnologias disponíveis. Pelo contrário, deve seguir uma
metodologia que combine métodos compreensivos para todas as fases do trabalho,
ferramentas de desenvolvimento, técnicas para assegurar a qualidade do software e uma
filosofia de coordenação, controle e gestão dos recursos disponíveis. Esta metodologia tem
como objectivo ajudar ao planeamento das tarefas de cada fase do desenvolvimento, bem
como a definição da melhor forma de as realizar.
O modelo de desenvolvimento usado foi o Modelo da LINK que é uma
metodologia iterativa que segue uma instanciação do RUP, aplicável a qualquer tecnologia
escolhida. Este modelo é apresentado esquematicamente na Figura 5 - Metodologia de
desenvolvimento da LINK, no anexo II - Figuras.
O modelo apresentado processa-se em ciclos, como se pode observar, e cada ciclo
resulta numa nova release da aplicação. Isto processa-se usualmente de acordo com um
plano de releases, definido quer devido à necessidade de lançamentos faseados com
funcionalidade incremental, quer por ser exigida a construção prévia de protótipos que têm
que ser evoluídos para os produtos finais.
Relatório do Projecto em Engenharia Informática
Página 17 de 62
Metodologia e Calendarização do Trabalho
A passagem da Fase de Visão para a Fase de Concepção dá-se sempre que há uma
definição de objectivos a desenvolver. A passagem para a Fase de Implementação ocorre
no final da fase de desenho. Quando a aplicação está pronta a entrar em operação, inicia-se
a fase de Transição, normalmente com uma release beta (também conhecida como piloto),
apenas disponível a um conjunto restrito de utilizadores. Esta fase termina com o roll-out
(entrega) definitivo da aplicação e a sua disponibilização aos utilizadores em geral.
Retoma-se então a fase de Visão, para o desenvolvimento da próxima release da aplicação.
3.2.1 Fase de Visão
A primeira Fase de Visão coincide normalmente com a elaboração da proposta, esta
deve assegurar o acordo relativamente aos objectivos a serem desenvolvidos.
É durante a Fase de Visão que se estabelecem as regras de negócio para a aplicação
a desenvolver e se define o âmbito do projecto.
Os resultados expectáveis desta fase são apresentados de seguida:
9 Uma visão genérica dos requisitos fundamentais, características chave e
constrangimentos principais da aplicação a desenvolver;
9 Elaboração de um ou mais protótipos.
Alguns dos principais critérios a ter em conta na Fase de Visão são:
9 A concordância dos vários intervenientes relativamente ao âmbito e estimativas;
9 A compreensão dos requisitos essenciais, por vezes evidenciada com alguns
casos de uso iniciais;
9 A credibilidade das estimativas, prioridade, riscos e o processo de
desenvolvimento.
3.2.2 Fase de Concepção
A Fase de Concepção tem como objectivo a análise e desenho da aplicação. As
actividades desta fase asseguram a estabilidade da arquitectura e requisitos e a
minimização dos riscos, de forma a ser possível predizer com certeza o esforço necessário
para completar o desenvolvimento.
Os principais critérios de avaliação da Fase de Concepção são normalmente os
seguintes:
9 A estabilidade da visão da aplicação;
9 A estabilidade da arquitectura;
9 O tratamento e resolução dos maiores riscos técnicos.
Genericamente, os resultados da Fase de Concepção são em geral os seguintes:
Relatório do Projecto em Engenharia Informática
Página 18 de 62
Metodologia e Calendarização do Trabalho
9 O modelo de casos de uso e a captura de requisitos suplementares, não
funcionais, não associados a um caso de uso especifico;
9 Levantamento das entidades;
9 O desenho da interface com o utilizador;
9 A revisão da lista de riscos e do caso de negócio apresentado na visão;
Nesta fase, são produzidos um conjunto de documentos que descrevem o resultado
da análise de concepção da aplicação.
A Fase de Concepção termina com as estimativas dos tempos de implementação por
parte da equipa de desenvolvimento. As estimativas por caso de uso devem incluir as fases
de análise, desenho, codificação, testes unitários, integração e documentação.
3.2.3 Fase de Implementação
Durante a fase de implementação, todas as componentes e funcionalidades da
aplicação são desenvolvidas, integradas numa release e cuidadosamente testadas. O
resultado desta fase é “uma aplicação” pronta a ser disponibilizada aos seus utilizadores
finais. Este deverá no mínimo compreender os seguintes aspectos:
9 Estar integrado nas plataformas adequadas;
9 Ser acompanhado de uma primeira versão dos manuais de utilização e
instalação;
9 O desenho detalhado, conteúdo a descrição de release.
Os critérios de avaliação para esta Fase de Implementação são:
9 A estabilidade e maturidade do desenvolvimento, por forma a ser
disponibilizado à comunidade de utilizadores;
9 Resultados dos testes;
9 A preparação de todos os intervenientes para a transição da aplicação.
3.2.4 Fase de Transição
O objectivo principal da Fase de Transição é fazer transitar a aplicação para a sua
comunidade de utilizadores, ou seja conseguir:
9 A autonomia dos utilizadores fase ao suporte;
9 A concorrência dos intervenientes de que a aplicação está consciente com a
visão inicial;
9 Disponibilizar a release final da aplicação, da forma mais rápida e prática.
Relatório do Projecto em Engenharia Informática
Página 19 de 62
Metodologia e Calendarização do Trabalho
A Fase de Transição inicia-se sempre que o desenvolvimento se encontra “maduro”
o suficiente para ser disponibilizado aos seus utilizadores finais. Isto requer tipicamente
que um subconjunto das funcionalidades sejam completadas a um nível aceitável de
qualidade, e que a documentação para os utilizadores esteja disponível de forma que a
transição forneça resultados positivos a todas as partes.
A Fase de Transição inclui o seguinte:
9 Testes para validar o sistema relativamente às expectativas dos utilizadores;
9 Se é o caso, a operação paralela com as aplicações que está substituir;
9 Se é o caso, conversação de base de dados operacionais;
9 Formação dos utilizadores e administradores.
No final desta fase decide-se se os objectivos da visão foram atingidos e se deve
iniciar outro ciclo de desenvolvimento.
Os critérios de avaliação para esta fase centram-se exclusivamente na satisfação dos
seus utilizadores.
3.2.5 Fase de Operação
No caso da metodologia de desenvolvimento de aplicações da LINK, a fase de
operação compreende a garantia da aplicação, que assegura apenas a manutenção
correctiva dos desenvolvimentos efectuados pela LINK. A garantia exclui os aspectos
como os seguintes:
9 O suporte a anomalias de sistemas externos;
9 Alterações que resultem de mudanças face aos requisitos especificados nos
documentos produzidos na Fase de Concepção;
9 Testes.
Cada uma das fases mencionadas anteriormente encontra-se detalhada no
documento de referência de Assunção, João (2003) - “Metodologia de Desenvolvimento de
Aplicações Workflow”, que não se encontra disponível*.
3.3 ANÁLISE DO RISCO
Sempre que somos confrontados com um projecto de desenvolvimento de software,
temos que ter em conta a análise do risco relacionada com processo de desenvolvimento.
A análise do risco é constituída por duas actividades, sendo a primeira, a
identificação dos riscos inerentes ao projecto em questão, porque nem todos os projectos
estão sujeitos aos mesmos riscos, a segunda é a gestão dos riscos identificados na
actividade anteriormente, ou seja, é o estudo e escolha de medidas alternativas que
permitam minimizar e controlar os riscos.
Relatório do Projecto em Engenharia Informática
Página 20 de 62
Metodologia e Calendarização do Trabalho
De seguida são apresentados os que foram mais importantes no projecto e como
foram abordados.
3.3.1 Identificação dos Riscos
Os riscos que vamos enfrentar são de três tipos: riscos de projecto, riscos técnicos e
riscos de negócio.
Os que mais poderão influenciar o projecto a ser desenvolvido são:
9 Riscos de projecto
o Interpretação incorrecta dos requisitos do cliente;
o Desenvolver um produto cujo custo final seja muito elevado;
o Atraso na entrega do produto final.
9 Riscos técnicos
o Interface inapropriada para o tipo de utilizador;
o Impossibilidade de garantir a manutenção do sistema;
o Tecnologia inadequada.
9 Riscos de negócio
o Falta de formação dos utilizadores;
o Perder o apoio da direcção do SIMLIS;
o Desenvolver um produto que não venha a ser utilizado.
3.3.2 Gestão dos Riscos
Finalmente, são apresentadas as medidas que poderão permitir minimizar e
controlar cada um dos riscos indicados.
9 Riscos do projecto
o Interpretação incorrecta dos requisitos do cliente. O contacto por parte da
direcção do SIMLIS com a aplicação que estava a ser desenvolvida permitiu
que qualquer erro resultante de má interpretação fosse corrigido de
imediato;
o Desenvolver um produto cujo custo final seja muito elevado. No inicio do
projecto foram definidos os recursos de hardware e software necessários.
Entretanto foi utilizada tecnologia sobre a qual nunca tinha sido usada e
como tal não se sabia dar uma estimativa exacta. Contudo foi atribuída uma
Relatório do Projecto em Engenharia Informática
Página 21 de 62
Metodologia e Calendarização do Trabalho
tarefa para autoformação na tecnologia em questão tendo em conta os
recursos monetários disponíveis;
o Atraso na entrega do produto final. Para evitar este risco foi necessário levar
a sério a calendarização do projecto, certificar-se das tarefas já concluídas,
preparar adequadamente as restantes e controlar os prazos definidos para a
realização de cada uma, de acordo com a calendarização.
9 Riscos técnicos
o Interface inapropriada para o tipo de utilizador. Quanto a este risco, só
quando os utilizadores começarem a utilizar a aplicação é que podemos tirar
conclusões. No entanto tentou-se identificar o melhor possível o domínio da
aplicação, assim como o grau de conhecimento e objectivos dos utilizadores
da aplicação. Também será fornecido um Manual do Utilizador para ajudar
os utilizadores na utilização do sistema. Contudo, as aplicações da Web,
hoje em dia, têm vindo a ser muito populares daí que se opta-se pela criação
de ecrãs da aplicação sob a forma de páginas HTML;
o Impossibilidade de garantir a manutenção do sistema. A melhor maneira de
combater este risco foi a criação de documentação, para auxiliar os
programadores e informar sobre todos os passos do processo de
desenvolvimento de software;
o Tecnologia inadequada. Este risco foi combatido com a escolha das
tecnologias mais poderosas que existem actualmente no mercado. No
entanto, sabe-se que no futuro aparecerão novas tecnologias mais potentes.
Este risco poderá ser superado no futuro com a adaptação da nova
tecnologia através do processo de migração.
9 Riscos de negócio
o Falta de formação dos utilizadores. Este risco é travado com o fornecimento
do Manual do Utilizador e através de formação dada pelos responsáveis da
LINK aos utilizadores finais;
o Perder o apoio da direcção do SIMLIS. É conveniente manter a direcção
informada em relação ao estado do processo de desenvolvimento de
software;
o Desenvolver um produto que não venha a ser utilizado. Este risco segue as
medidas a serem tomadas no risco da “Interface inapropriada para o tipo de
utilizador”.
3.4 RECURSOS
Para que o planeamento efectuado seja cumprido é necessário dispor de recursos
humanos, de hardware e de software.
Relatório do Projecto em Engenharia Informática
Página 22 de 62
Metodologia e Calendarização do Trabalho
3.4.1 Organização e Controlo do Projecto
3.4.1.1
Organização do Projecto
A Organização do Projecto apresentada tem como objectivo definir os níveis de
responsabilidade e decisão, bem como os canais e processos de comunicação, capazes de
assegurarem o sucesso do projecto.
Figura 6 – Organização do Projecto
O Gestor de Projecto, Engº João Assunção, da LINK tem como responsabilidades:
9 O planeamento e controlo dos objectivos do projecto, nomeadamente âmbito,
tempo, custos, qualidade e organização;
9 A garantia da correcta identificação e quantificação dos riscos do projecto, bem
como o planeamento das acções de resposta aos mesmos;
9 A constituição e gestão da equipa de projecto e a direcção das reuniões com a
equipa de projecto;
9 O controlo do projecto, comparando a situação actual face ao planeado,
identificando desvios e propondo acções correctivas;
9 A elaboração e distribuição de relatórios periódicos de situação do projecto,
assegurando a comunicação com os vários stakeholders.
O gestor de projecto do cliente tem como responsabilidades:
Relatório do Projecto em Engenharia Informática
Página 23 de 62
Metodologia e Calendarização do Trabalho
9 Assegurar e coordenar o envolvimento dos elementos da sua organização de
acordo com o definido no plano do projecto;
9 Assegurar, conjuntamente com o gestor de projecto da LINK, o controlo do
projecto, especialmente nos componentes definidos sendo da responsabilidade da
sua organização;
9 Colaborar, conjuntamente com o gestor de projecto da LINK, na elaboração dos
relatórios de progresso do projecto.
O Responsável Técnico, Engº Paulo Mateus, da LINK tem como responsabilidades:
9 O planeamento e controlo do processo de desenvolvimento de software;
9 A garantia da qualidade do software desenvolvido;
9 A decisão sobre as opções tecnológicas que melhor se enquadrem face aos
requisitos da solução a desenvolver;
9 A distribuição da execução das tarefas de garantia de qualidade (especificação
de requisitos, especificação de testes) e de controlo de qualidade (testes de unidade;
testes de integração, testes de carga e desempenho);
9 A elaboração e distribuição de relatórios periódicos de progresso do projecto,
assegurando a comunicação com a Gestão do Projecto.
A Equipa de Consultores, constituída por Engº Paulo Mateus, Engº Carlos Dias e
por mim, Bruno Bento, tem como responsabilidades:
9 A equipa de consultores, coordenada pelo Responsável Técnico na vertente de
execução técnica e pelo Gestor de Projecto da LINK na vertente de gestão de
recursos humanos, assegurará a execução de todas as actividades de acordo com o
planeamento acordado.
A Equipa do Cliente tem como responsabilidades:
9 A Equipa do Cliente, cuja coordenação é da exclusiva responsabilidade do
Gestor de Projecto do Cliente, pode contar com Utilizadores Chave, aptos a
definirem os requisitos funcionais e de desempenho da solução, bem como de
verificarem a conformidade da solução final face aos requisitos.
3.4.1.2
Controlo do Projecto
Para efectuar o Controlo do Projecto foram usados os seguintes procedimentos de
comunicação:
9 Relatórios de controlo de projecto;
9 Reuniões de controlo de projecto.
Relatório do Projecto em Engenharia Informática
Página 24 de 62
Metodologia e Calendarização do Trabalho
Ao longo do Ciclo de Vida do projecto foram produzidos periodicamente relatórios
de progresso. Estes relatórios, destinados ao Gestor de Projecto, reflectem a situação de
cada componente do projecto relatada pelos coordenadores de cada um dos pacotes de
trabalho.
As reuniões de controlo de progresso tiveram uma periodicidade semanal, tendo por
objectivo a revisão dos relatórios de progresso. Evidenciam:
9 O trabalho concluído desde a última reunião;
9 O trabalho em curso;
9 O trabalho em atraso;
9 O planeamento do trabalho para o próximo período;
3.4.2 Recursos de hardware
Os recursos de hardware utilizados no desenvolvimento da aplicação foram os
seguintes:
9 Máquina servidor de Base de Dados;
9 Máquina servidor de web;
9 Máquinas clientes de desenvolvimento.
3.4.3 Recursos de software
O software instalado nestas máquinas para o desenvolvimento da aplicação
pretendida é:
9 Microsoft Visual Source Safe
o O VSS é uma ferramenta de colaboração para programadores de aplicações.
Com esta ferramenta é possível dentro da equipa de desenvolvimento,
controlar os acessos e versões. A grande vantagem de usar este software e
não outro semelhante existente no mercado prende-se com a integração com
os produtos Microsoft. Esta ferramenta foi adoptada para controlar o código
fonte do projecto.
9 Concurrent Version System
o O CVS é também uma ferramenta de controlo de versões e acessos de um
sistema durante o processo de desenvolvimento. Esta é a ferramenta de
eleição na LINK para controlo de versões de documentos. Os documentos
em questão são a especificação técnica e funcional, o manual do utilizador e
de instalação, entre outros.
9 Visual Studio 2003
Relatório do Projecto em Engenharia Informática
Página 25 de 62
Metodologia e Calendarização do Trabalho
o O VS 2003 é o ambiente de desenvolvimento das aplicações .NET.
9 .NET Framework
o Trata-se da infra-estrutura básica sobre a qual as aplicações correm.
9 Microsoft Internet Information Services
o
O IIS é um servidor Web da plataforma Microsoft.
9 Microsoft SQL Server 2000
o O SQL Server é uma base de dados de referência do mercado
proporcionando uma base sólida e escalável do sistema.
9 Microsoft Office Visio 2003
o É uma ferramenta simples e flexível para criar com facilidade gráficos e
fluxogramas para entender, visualizar conceitos mais rapidamente e
comunicar informações com maior eficiência.
9 Microsoft Office Word 2003
o Processador de texto escolhido para processar todos os documentos
realizados para o projecto.
9 Internet Explorer v6.0
o Ferramenta utilizada para visualizar as páginas web.
9 SQL Server Query Analyzer
o Ferramenta que oferece um ambiente extremamente flexível para correr ad
hoc queries. Esta ferramenta faz parte do pacote do SQL Server.
9 SQL Server Enterprise Manager
o Ferramenta que oferece um ambiente para criar e gerir Base de Dados, bem
como navegar pelos dados. Esta ferramenta faz parte do pacote do SQL
Server.
9 Microsoft Windows XP Professional Version 2002 Service Pack 2
o Sistema operativo sobre o qual todas as ferramentas mencionadas
anteriormente correm.
Os produtos anteriormente seleccionados para a realização do projecto foram
aqueles que têm em conta o valor que trazem para o SIMLIS quer para este projecto quer a
médio e longo prazo. Na decisão da escolha do software pesou o SIMLIS ter um contrato
com a Microsoft no que toca aos produtos.
Relatório do Projecto em Engenharia Informática
Página 26 de 62
Metodologia e Calendarização do Trabalho
3.5 CALENDARIZAÇÃO FINAL DO TRABALHO
Apesar do esforço feito para cumprir à risca a calendarização inicial, é sempre de
esperar que aconteçam sempre imprevistos que levem ao atraso das tarefas definidas.
A falta de experiência da minha parte, nomeadamente na resolução de bugs
(problemas), levou a que pontualmente fosse notado algum atraso, que mais tarde foi
recuperado com um esforço adicional da minha parte. Este contratempo permitiu que mais
tarde o desenvolvimento do código para a aplicação fosse mais rápido.
Sendo considerada informação sensível no que toca à sua divulgação ao exterior, o
plano de projecto final não será aqui exposto.
Relatório do Projecto em Engenharia Informática
Página 27 de 62
4 TRABALHO
REALIZADO
Relatório do Projecto em Engenharia Informática
Página 28 de 62
Trabalho Realizado
4.1 TRABALHO REALIZADO NO PRÉ-PROJECTO
Esta secção encarrega-se de relatar o trabalho realizado durante a fase de préprojecto de uma forma resumida.
Como já foi mencionado no capítulo 2.1, os objectivos do pré-projecto consistiam
na adaptação ao trabalho em equipas de trabalho segundo a Organização e Controlo do
Projecto, e também no enriquecimento de conhecimentos das novas tecnologias.
De seguida são apresentados os projectos em que estive inserido nesta fase.
4.1.1 Na Sonae MCH
A minha primeira colaboração foi dada no projecto que era para o cliente Sonae
Distribuição – Modelo Continente Hipermercados e consistiu num processo de
uniformização dos layouts das aplicações WF (WorkFlow). Pretendia-se alterar o design e
as cores para corresponder ao conteúdo do Guião Interactivo Genérico que entretanto fora
actualizado.
As vantagens deste desenvolvimento são várias:
9 Restabelecimento de um padrão uniforme de interface para o utilizador, que está
de acordo com o grafismo da Worklist Única e da própria NGI (Nova Geração do
INSITE). Este ponto é especialmente importante tendo em conta o crescente número
de utilizadores deste WF.
9 Enriquecimento de algumas componentes do WF Bens e Serviços, que permitem
no futuro uma maior rapidez na alteração das interfaces.
9 Melhoria significativa na usabilidade de alguns dos ecrãs que serão alterados.
9 Adopção de
desenvolvimento.
alguns
componentes
comuns,
reduzindo
esforço
de
Na Figura 7 - Exemplo de um ecrã do WF Bens e Serviços, no anexo II - Figuras,
encontra-se um exemplo que ilustra os resultados que se pretendem obter com este
desenvolvimento.
A minha participação no projecto foi nas seguintes etapas definidas na metodologia:
9 Desenvolvimento
o Alterações das Interfaces
o Passagens a Staging (pré-produção)
9 Transição
o Preparação da Passagem a Produção
Relatório do Projecto em Engenharia em Informática
Página 29 de 62
Trabalho Realizado
Neste trabalho também tive a oportunidade de aprofundar os meus conhecimentos
em folhas de estilo CSS, JavaScript e HTML.
4.1.2 No PEP
Noutra aplicação da Sonae, PEP, “Planeamento de Eventos Promocionais”, o
objectivo era desenvolver novas funcionalidades, utilizando a tecnologia VBA em Excel
onde pude aprofundar os meus conhecimentos académicos.
O PEP é um sistema de informação, cuja principal base é o sistema Retek, que
permite a gestão centralizada das lojas, com destaque para a gestão de produtos,
fornecedores e encomendas.
A Figura 8 - Folha “Definição de Promoções” da aplicação PEP, no anexo II Figuras, mostra um dos ecrãs da aplicação PEP.
A proposta de desenvolvimento do PEP que me foi pedido para implementar
encontra-se no documento de referência de Monteiro, Paulo (2004) - “Proposta
Desenvolvimento: PEP - Desenvolvimento da template v1.18”, o qual não se encontra
disponível*.
4.1.3 No eBanka
Terminei a primeira fase do estágio num projecto que se chama eBanka
(http://ebanka.promosoft.com/) que é um produto constituído por Home Banking com
componente de portal institucional e tem como objectivo responder às necessidades das
instituições bancárias que pretendem utilizar a Internet como mais um canal de
comunicação com os seus actuais e potenciais clientes. Desta maneira permite que os
clientes efectuem operações de transferências internas e externas, consulta de saldos,
pedidos de cheques, extravio de cheques, consulta de movimentos, consulta de câmbios,
etc.
A figura seguinte mostra o ambiente da aplicação eBanka na sua vertente de Home
Banking:
Relatório do Projecto em Engenharia Informática
Página 30 de 62
Trabalho Realizado
Figura 9 – Aplicação eBanka
A equipa deste projecto era constituída por um gestor de projecto, um responsável
técnico e um consultor. Eu desempenhei a função de consultor, onde executei as tarefas
que me foram atribuídas.
A minha contribuição neste projecto consistia em desenvolver um WebService que
é responsável por receber as operações dos clientes, verificar se os clientes estão registados
no sistema e invocar um Componente COM, utilizando a tecnologia C# sobre WebServices
do .Net.
Este WebService também é responsável por manipular todas as mensagens XML
retornadas pelo Componente COM, esta manipulação foi feita com a ajudas das classes de
manipulação de XML do .Net.
WebServices são uma nova e inovadora técnica para a troca de dados via Web que
se tem utilizado muito para fornecer e consumir serviços na Web. Toda a comunicação
entre os servidores WebServices e os seus clientes é através de mensagens XML sobre o
protocolo HTTP.
Mas para a comunicação ser baseada em XML é necessário um protocolo que seja
responsável por encapsular as chamadas dos métodos e propriedades dos objectos em
XML, este protocolo chama-se SOAP.
Contudo, para um cliente invocar os serviços fornecidos por um servidor é
necessário que conheça a assinatura desses serviços e isto é conseguido através do padrão
WSDL, que fornece a descrição de tudo que um WebService possui.
Relatório do Projecto em Engenharia Informática
Página 31 de 62
Trabalho Realizado
4.2 TRABALHO REALIZADO NO PROJECTO
4.2.1 Arquitectura tecnológica
Este capitulo foi reservado ao relato das soluções tecnológicas abordadas e
adoptadas para a realização do projecto.
Antes da criação do projecto foi necessário decidir, em fase de especificação
técnica quais as linguagens de programação a utilizar, e quais os mecanismos de
comunicação da aplicação com a Base de Dados a implementar e qual a interface mais
apropriada para o sistema.
Para desenvolver a aplicação para o negócio do SIMLIS foi colocada a questão do
tipo de interface, windows application ou web application.
As windows applications consistem em aplicações com interface com o utilizador
semelhante aos dos programas actuais para o Sistema Operativo Windows, pelo que, as web
applications são aplicações destinadas a serem vistas sobre a Internet em browsers.
A solução escolhida foi a interface das web applications, esta solução permite o
acesso à informação através da Internet. Desta modo são apresentadas as seguintes
vantagens no seu uso:
9 Os utilizadores SIMLIS podem aceder de uma forma fácil à informação a partir
de qualquer PC instalado no interior do SIMLIS ou através de um PC externo com
ligação à Internet;
9 Facilita a manutenção do sistema, uma vez que as actualizações reflectem para
todos os utilizações sem afectar nada;
9 Não necessita de ser instalado nada no computador do cliente, somente ter um
browser.
No entanto para a concretização da interface web application é necessário ter uma
infra-estrutura sobre o qual a aplicação corre. Como infra-estrutura, optou-se pela .Net
Framework, embora exista outra concorrente forte como a J2EE da Sun.
Dentro da .Net Framework optámos por escolher a linguagem de programação C#,
porque é uma linguagem nova e moderna que visa facilitar o desenvolvimento de
aplicações.
O capítulo 4.2.2 foi reservado à .Net Framework e à linguagem C#, onde estas
foram abrangidas de uma forma mais resumida.
A escolha da interface anteriormente mencionada levou à necessidade de utilização
de um servidor web para permitir o acesso às páginas ASP.NET e HTML criadas, por parte
dos browsers instalados nas máquinas do SIMLIS e por qualquer máquina com acesso à
Internet.
No entanto, não só a escolha de um servidor web se tornou necessária, mas também
a escolha do servidor de Base de Dados. Existiam duas soluções possíveis para resolver o
problema.
Relatório do Projecto em Engenharia Informática
Página 32 de 62
Trabalho Realizado
A solução passava pela implementação através da utilização do Servidor Web da
Microsoft, chamado IIS.
Relativamente ao servidor de Base de Dados tínhamos a oportunidade de escolher
entre o SQL Server e o Oracle, decidimos escolher o SQL Server.
Ambos os Sistemas de Gestão de Base de Dados referenciados são grandes
potências no mercado, que podem ser usados para construir sistemas eficientes e estáveis.
Apesar de tudo a escolha foi obvia já que o cliente com a escolha do SQL Server,
não teria adição de custos.
Mas o SQL Server tem algumas vantagens em comparação com Oracle e viceversa.
Algumas vantagens do SQL Server são as seguintes:
9 É mais barato comprar que o Oracle;
9 É geralmente mais fácil de instalar, usar e gerir.
O conjunto de produtos seleccionados para concretizar o projecto SIMLIS passou
pelo facto de o SIMLIS possuir um acordo de licenciamento com a Microsoft para usar os
seus produtos.
Como ferramentas de controlo de versões e acessos do projecto durante o processo
de desenvolvimento usou-se o VSS e o CVS.
O VSS é uma ferramenta que permite de forma segura, dentro da equipa de
desenvolvimento, controlar os acessos e versões. Esta ferramenta foi adoptada para
controlar o código fonte do projecto.
O CVS também permite o controlo de acesso e versões, mas decidiu-se usar este
utilitário para manipular os documentos do projecto, pois a integração das ferramentas com
o VSS é total.
Como ferramenta de desenvolvimento de aplicações .NET utilizou-se o VS 2003.
Este ambiente de desenvolvimento abrangente para múltiplas linguagens, destinada ao
rápido desenvolvimento e integração de aplicações. Também oferece um ambiente
altamente produtivo para o desenvolvimento de uma ampla variedade de aplicações e
tecnologias conectadas com a plataforma .Net. Através do uso do ambiente de runtime de
alta performance Microsoft .Net Framework, o VS 2003 .NET oferece aos programadores
poderosas ferramentas de design, construção, testes e instalação de aplicações, permitindo
também que as melhores práticas e orientações possam ser partilhadas num ambiente de
trabalho em equipa.
4.2.2 .Net Framework e linguagem C#
Este capitulo foi dedicado para explicar de forma resumida uma das partes
preponderantes onde incidiu o projecto realizado.
A .Net Framework trata-se da infra-estrutura, que visa obter uma forma simples e
unificada de desenvolvimento de aplicações, e sobre a qual as aplicações correm. Esta
infra-estrutura é constituída por diversas partes, tal como é ilustrado na figura 11.
Relatório do Projecto em Engenharia Informática
Página 33 de 62
Trabalho Realizado
Figura 10 – Arquitectura da plataforma .NET
Todas as aplicações escritas para a .NET correm dentro de uma máquina
virtual chamada CLR. O código que se encontra a executar aqui dentro chama-se
managed code e beneficia de várias características como:
9 Gestão automática de memória
o O CLR dispõe de um garbage collector que se encarrega de limpar os
objectos que já não estão a ser utilizados pelas aplicações.
9 Segurança
o O CLR mecanismos que permitem atribuir permissões ao código baseadas
na sua proveniência e em quem está a executar. Existem também
mecanismos que permitem garantir que o código a executar é valido e não
irá corromper outros programas que se encontrem a executar no CLR.
9 Tradução de código intermédio para código nativo
o Ao compilar um programa na plataforma .NET, tipicamente este é traduzido
de uma linguagem de alto nível para uma linguagem intermédia chamada
MSIL. O CLR possui um compilador just-in-time que se encarrega de
traduzir código intermédio para código nativo do processador, antes de o
executar.
9 Carregamento dinâmico de classes
o O CLR torna possível carregar em tempo de execução segmentos de código
que antes não estavam presentes na máquina virtual.
O CLR encontra-se a executar por cima do sistema operativo, utilizando os seus
serviços.
Por cima da máquina virtual básica, existe um conjunto de bibliotecas
estandardizadas que permitem às aplicações tomar pedido de um rico conjunto de
APIs. Existe um conjunto de bibliotecas básicas, denominadas por Base Class
Relatório do Projecto em Engenharia Informática
Página 34 de 62
Trabalho Realizado
Library, que oferecem recursos como acesso a ficheiros, estruturas de dados básicas
(hash tables, listas, etc.), acesso a recursos de rede e outras. Em seguida,
encontram-se bibliotecas que permitem aceder a base de dados (ADO.NET) e
manipular informação em geral (por exemplo, em XML). No topo da hierarquia
estão as bibliotecas que permitem efectuar desenvolvimento web (ASP.NET) e criar
interfaces com o utilizador em Windows (Windows Forms).
Um ponto interessante é que o .NET foi pensado não apenas para aplicações que
sejam programadas em C#, mas também noutras linguagens. Na .NET Framework,
as linguagens de alto nível são compiladas para uma linguagem intermédia
chamada MSIL. É esse código que é executado no CLR. A Common Language
Specification constitui uma norma que especifica o que é que tem de ser suportado a
nível de uma linguagem de programação para esta ser compatível com a infraestrutura .NET e com as aplicações que se encontram a correr no CLR.
Quanto ao C# posso dizer que é uma linguagem nova e moderna que visa
facilitar o desenvolvimento de aplicações. Combina as melhores características do
C++, do Visual Basic e mesmo do Java. Eis as principais características desta nova
linguagem, que acho que são dignas de referência:
9 Orientada aos componentes
o Um dos grandes passos em termos de engenharia de software, foi o conceito
de componente. Um componente é uma unidade binária de código que pode
ser incluída numa aplicação. Tipicamente a manipulação de componentes
faz-se de forma visual, por drag-and-drop e, configuração das suas
propriedades e interligações.
9 Robusta e moderna
o O C# é uma linguagem orientada aos objectos, possuindo mecanismos
como, garbage collection, que liberta o programador da gestão explícita da
memória; excepções, que permitem uma gestão robusta dos erros nos
programas.
9 Familiar
o O C# baseia a sua sintaxe na linguagem C++ e, em certa medida, na
linguagem Java. Hoje em dia existem muitos programadores que já
conhecem essas linguagens, fazendo com que a transição para o C# seja
relativamente pacífica.
No entanto uma nova linguagem por muito poderosa que seja não é
verdadeiramente útil se não tiver um grande número de bibliotecas de funções
directamente disponíveis. O C# em si não possui bibliotecas. Contudo os programas
escritos nesta linguagem executam sobre a .NET Framework, que possui um vasto
conjunto de bibliotecas, assim como outras funcionalidades que permitem uma
grande versatilidade em C#.
Relatório do Projecto em Engenharia Informática
Página 35 de 62
Trabalho Realizado
4.2.3 Arquitectura física
O conjunto de soluções escolhidas no capítulo 4.2.1, deu origem à seguinte
arquitectura:
Figura 11 – Arquitectura física
Os componentes apresentados relacionam-se da forma apresentada a seguir.
O servidor IIS recebe pedidos dos browsers das máquinas cliente e é responsável
por dirigi-los ao servidor da Base de Dados. Para que tal seja possível é preciso efectuar
uma conexão entre estes dois servidores, passando o IIS a ser cliente do servidor de Base
de Dados. Essa conexão é realizada via SQL Server .Net Data Provider. Depois de
executar a resposta ao pedido, o servidor da Base de Dados enviá-la-á para o IIS. Esta
resposta é a informação que o IIS envia à aplicação C#, que constrói uma página ASP.NET
e passa ao browser.
4.2.4 Arquitectura lógica
A arquitectura de desenvolvimento da aplicação pode ser caracterizada num serviço
de três camadas:
9 Camada de apresentação;
9 Camada de lógica de negócio;
Relatório do Projecto em Engenharia Informática
Página 36 de 62
Trabalho Realizado
9 Camada de base de dados.
Figura 12 – Arquitectura lógica
A arquitectura lógica apresentada permite que a interface com o utilizador apenas
trate de aspectos de visualização de informação. Todos os pedidos de informação são
efectuados à lógica de negócio. Assim, torna-se muito mais simples realizar a manutenção
da interface do utilizador. Qualquer mudança neste componente da arquitectura não
influência outros.
A camada lógica de negócio permite separar a lógica de negócio da Base de Dados,
deixando de estar dependente do Sistema de Gestão de Base de Dados utilizado. Esta
camada é implementada utilizando tipicamente linguagens como o C#, VB ou outras
semelhantes que permitem muito maior flexibilidade e complexidade em relação ao que
está disponível nos Sistemas de Gestão de Base de Dados, onde as linguagens estão muito
mais direccionadas por forma a permitir fácil e rápida implementação de consultas,
actualizações, inserções e remoções.
Por fim temos a camada de Base de Dados como base de toda a aplicação. Aqui
residem os dados dos utilizadores. Ao exterior são oferecidas capacidades de execução de
consultas, actualizações, inserções, remoções usando o standard SQL. As potencialidades
disponíveis dependem sempre de qual o Sistema de Gestão de Base de Dados escolhido,
sendo que a utilização de funcionalidades especificas do Sistema de Gestão de Base de
Dados para melhoria de performance ou facilitação do desenvolvimento é totalmente
independente e não afecta de forma alguma a implementação da lógica de negócio e da
interface gráfica.
Relatório do Projecto em Engenharia Informática
Página 37 de 62
Trabalho Realizado
4.2.4.1
Camada de apresentação
O primeiro componente do sistema é o único que é visível para o utilizador, o
browser. A partir deste utilitário o utilizador pode efectuar operações de consultar,
pesquisar, inserir, alterar e eliminar sobre a informação da Base de Dados de uma forma
transparente, dando a sensação que a aplicação é constituída somente por este componente.
Nesta secção faço uma explicação sobre o funcionamento da aplicação em geral,
estruturas de dados e linguagens utilizadas para realizar esta camada. De seguida é
abordada a validação de dados, terminando com a segurança da aplicação.
4.2.4.1.1
Modelo de programação
Em ASP.NET existem dois modelos de programação: code behind e code in page.
O modelo utilizado foi o code behind, aqui encontramos uma verdadeira separação do
HTML e do código C#. Neste modelo, para cada ficheiro .aspx, extensão dos ficheiros
ASP.NET, existe um ficheiro .aspx.cs onde está escrito todo o código.
No ficheiro aspx, existe apenas, a parte HTML e a parte da declaração dos
componentes do ASP.NET, onde o reaproveitamento do código é grande e facilita muito a
programação. Os componentes utilizados foram:
9 HTML Controls
o São os controlos HTML básicos (Div, B, Table, ...).
9 HTML Server Controls
o São controlos HTML executados no servidor Web (Calendar, Datagrid, ...).
9 Web Server Controls
o São os controlos ASP.NET.
9 Web User Controls
o São Web Server Controls definido pelo programador.
9 Validation Controls
o São Web Server Controls que contêm lógica para validar o input de outros
Server controls.
No ficheiro .aspx.cs encontra-se o código C# correspondente às funcionalidades da
interface.
4.2.4.1.2
Interface HTML
Relativamente ao funcionamento da aplicação, para se utilizar a mesma o utilizador
tem que ter um browser aberto e depois carregar sobre o menu Favorites e escolher a
opção
SIMLIS
ou
então
escrever
o
URL
da
aplicação,
http://localhost/SIMLIS_WEB/homepage.aspx, na caixa de texto Address.
Relatório do Projecto em Engenharia Informática
Página 38 de 62
Trabalho Realizado
Figura 13 – Inicialização da aplicação a partir dos Favorites
Após seleccionada a opção SIMLIS, a página principal da aplicação é exibida como
mostra a Figura 14 - Ecrã principal da aplicação do SIMLIS, no anexo II - Figuras.
O Menu SIMLIS permite ao utilizador aceder às seguintes opções:
9 Área de gestão de dados relativos a Pagamentos;
9 Área de gestão de dados relativos ao Cadastro;
9 Área de gestão de dados relativos a Candidatura a Fundos de Coesão;
9 Área de gestão de dados auxiliares.
Em todas as páginas do SIMLIS existe a barra de funcionalidades que está exibida
na Figura 15 do anexo II - Figuras.
Nesta barra podemos encontrar funcionalidades que estão apresentadas na Figura 16
do anexo II - Figuras.
Cada um dos itens apresentados no Menu SIMLIS quando seleccionados, exibem
uma página semelhante à apresentada na Figura 17 do anexo II - Figuras.
A página seleccionada é constituída por um Menu Lateral que permite navegar
entre os vários dados relativos à área gestão de dados seleccionada, nesta caso, ao
Cadastro; por um rodapé; por uma Área de Operação, reservada às operações de pesquisa,
consulta, inserção, actualização e remoção de registos; para além da Barra de
Funcionalidades.
Para o efeito foram utilizados usercontrols (ficheiros .ascx), que foram desenhados
para permitir reutilizar funcionalidades comuns da interface do utilizador:
9
<uc1:cabecalhopage id="Cabecalho" Tipo=”C” runat="server"></uc1:cabecalhopage>
o Este usercontrol é responsável pela apresentação da barra de cabeçalho
correspondente à área de gestão de dados seleccionada e servir como link
para o Menu SIMLIS.
Relatório do Projecto em Engenharia Informática
Página 39 de 62
Trabalho Realizado
Ver as Figuras 18, 19, 20, 21, 22, no anexo II - Figuras, que apresentam as várias
barras de cabeçalho da aplicação.
9
<uc3:MenuCabecalho id="MenuCabecalho" runat="server"></uc3:MenuCabecalho>
o Este usercontrol é responsável pela construção do menu do cabeçalho
correspondente à Barra de Funcionalidades, e servir como link para cada
área de dados.
Ver a Figura 23 do anexo II - Figuras.
9 <uc5:Menu
id="MenuLateral"
runat="server"
ElemId="C"
ElemSelected="InterL" SubElemSelected="InterC"></uc5:Menu>
ElemOpen="InterL"
o Este usercontrol é responsável pela construção do menu lateral
correspondente à área de dados seleccionada, neste caso, foi a área de dados
relativos ao Cadastro.
Ver a Figura 24 do anexo II - Figuras.
9
< uc2:FooterPage id="Footer" runat="server"></uc2:FooterPage>
o Este usercontrol é responsável pela construção do rodapé comum a todas as
áreas de dados.
Na Área da Operação não foi mencionado nenhum usercontrol, porque esta varia
consoante a operação escolhida, daí serem aplicados diversos usercontrols para cada uma
das operações.
No caso da operação escolhida tenha sido a pesquisa, foi utilizado um usercontrol
de pesquisa, que agrupa um conjunto de outros usercontrols e de controlos ASP.NET, como
por exemplo:
9 <asp:CheckBox>
9 <asp:Panel>
9 <asp:TextBox>
9 <asp:ValidationSummary>
9 <asp:Button>
9 <asp:CompareValidator>
Os controlos de HTML utilizados foram:
9 <Div>
9 <A href>
9 <Br>
9 <Table>
Relatório do Projecto em Engenharia Informática
Página 40 de 62
Trabalho Realizado
9 <input>
9 <H3>
9 <Label>
Os usercontrols usados dentro do usercontrol de pesquisa tem a função preencher
DropDownLists (caixas de selecção), como por exemplo, preencher a DropDownList dos
subsistemas com todos os subsistemas disponíveis no sistema; ou exibir um calendário para
o utilizador seleccionar uma data.
Ainda na operação de pesquisa foi utilizado outro usercontrol para apresentar a
listagem das ocorrências encontradas segundo o critério de pesquisa escolhido. Este
usercontrol recebe um objecto Pesquisa com os dados dos campos de pesquisa e depois é
responsável por chamar os métodos da camada da lógica de negócio para receber os dados
da Base de Dados e por fim apresenta-os ao utilizador através dum controlo
<asp:DataGrid>, este controlo apresenta um grande número de funcionalidades para
formatar a listagem dos dados apresentados.
A Figura 25 do anexo II - Figuras, ilustra a utilização do controlo <asp:DataGrid>.
Na operação de inserção, actualização, consulta e remoção foi utilizado um
usercontrol responsável por encapsular um conjunto de controlos ASP.NET, que constroem
a página de inserção, actualização, consulta e remoção. Os controlos utilizados servem para
exibir os campos a preencher e para validar os dados digitados ou seleccionados pelo
utilizador nesses campos. De seguida são exibidos alguns controlos utilizados:
9 <asp:ValidationSummary>
9 <asp:Panel>
9 <asp:Hyperlink>
9 <asp:RequiredFieldValidator>
9 <asp:Label>
9 <asp:Button>
Alguns controlos de HTML utilizados foram:
9 <Table>
9 <Label>
9 <Input>
9 <Div>
A Figura 26 no anexo II - Figuras, ilustra o uso dos controlos referenciados .
A área da operação de inserção está disponível a partir da selecção do tópico inserir
do menu lateral, dentro da área de dados seleccionada.
Relatório do Projecto em Engenharia Informática
Página 41 de 62
Trabalho Realizado
As operações de actualização e remoção estão disponíveis a partir da listagem das
ocorrências ou da operação de consulta. Por fim a operação de consulta está disponível a
partir da listagem.
Todos os outros itens quer desta área de dados quer das restantes, seguem o mesmo
raciocínio.
O documento de referência de Bento, Bruno (2005) - “SMLS_04_0269 Manual
Utilizador”, onde se encontra o funcionamento da interface com maior detalhe, não está
disponível*.
4.2.4.1.3
Validação de dados
Um aspecto muito importante a nível da camada de apresentação é a validação de
dados. Nunca podemos ficar na expectativa que o utilizador insira valores coerentes com os
da Base de Dados, porque, por exemplo, pode digitar dados numéricos no nome de uma
pessoa para criar um novo registo, sem aperceber-se do acontecido.
Na aplicação desenvolvida existem vários formulários de inserção e actualização
referentes a diversos tipos de informação; nomes, moradas, telefones, nº de contribuintes e
bilhetes de identidade, datas, idades, etc.; pelo que se torna obrigatório analisar a coerência
dos valores digitados pelo utilizador. É obvio que os erros ortográficos não são apanhados
pelos validadores. Contudo, numa actualização posterior desse registo, o utilizador pode
corrigi-lo.
Existem duas formas de validar os dados introduzidos pelo utilizador. Validações
feitas no lado do cliente (clientside), ou seja pelo browser, através da linguagem JavaScript
ou do lado do servidor (serverside) pelo código C#. Das duas formas apresentadas, a
primeira é a preferível porque não requer o consumo de recursos do servidor e por isso
sempre que foi possível optou-se pelo uso desta linguagem. Mas o que acontece é que por
vezes não é possível fazer as validações do lado do cliente, como por exemplo, antes de
inserir um dado identificador na Base de Dados temos de verificar se já lá existe.
De seguida na Figura 27 no anexo II - Figuras, é apresentado um ecrã com o uso da
linguagem JavaScript.
4.2.4.1.4
Segurança
Outro aspecto que requer destaque neste documento é a segurança, mais
propriamente dito, a validação de utilizadores que entram na aplicação ASP.NET
desenvolvida.
A .Net Framework juntamente com o IIS disponibilizam sistemas de autenticação,
optou-se pelo método de Windows Integrated Authentication e Digest Authentication pelo
facto de estes tipos de autenticação já se encontrarem implementados.
Relatório do Projecto em Engenharia Informática
Página 42 de 62
Trabalho Realizado
Figura 28 – Métodos de Autenticação fornecidos pelo IIS
No método Windows Integrated Authentication a autenticação é feita através do
sistema operativo Windows que vai utilizar os utilizadores registados no sistema operativo
que, normalmente, já existem no sistema das empresas.
Por outro lado, no método Digest Authentication os utilizadores fornecem um
username e password para se conectarem, no entanto, a password é cifrada antes de ser
enviada sobre a rede.
Após ter sido feita a autenticação no IIS, o processo é encaminhado para a aplicação
ASP.NET, cujas verificações são feitas com base no ficheiro de configuração, web.config,
da aplicação.
Para concretizar o nosso objectivo tivemos que definir no web.config o tipo de
autenticação, Windows, recorrendo ao uso das tags que se segue:
<system.web>
<authentication
</system.web>
mode=”Windows” />
Depois de termos indicado o tipo de autenticação, tivemos de definir as
autorizações tanto de utilizadores (users) como de grupos (roles) de utilizadores.
<authorization>
<deny users=”[comma separated list of users]”
roles=”[comma separated list of roles]” />
<allow users=”[comma separated list of users]”
roles=”[comma separated list of roles]” />
</authorization>
O método Digest Authentication só é utilizado caso o método Windows Integrated
Authentication falhe.
Relatório do Projecto em Engenharia Informática
Página 43 de 62
Trabalho Realizado
4.2.4.2
Camada de lógica de negócio
A lógica de negócio estabelece a ligação entre a camada de interface e o Sistema de
Gestão de Base de Dados, via SQL Server .Net Data Provider, tratando os dados de modo a
que estes se encontrem de acordo com as regras de negócio do sistema.
A linguagem de programação eleita para o desenvolvimento desta camada foi o C#
pelas razões mencionadas no capítulo 4.2.2.
A .Net Framework fornece um conjunto de classes para facilitar o acesso das
aplicações às Base de Dados de diversos tipos, cujo nome é ADO.NET.
Um exemplo de como usar estas bibliotecas é mostrado de seguida.
Comentários em C#
//importar o conjunto de classes fornecidas pelo SqlServer .Net
Data Provider para acesso à Base de Dados
using System.Data.SqlClient;
Os principais objectos utilizados do SqlServer .Net Data Provider são:
9 SqlConnection
o Representa um única conexão persistente ao SQL Server data source.
9 SqlParameter
o Representa um parâmetro a ser passado, neste caso numa ad hoc query
(instrução SQL executada directamente).
9 SqlCommand
o Representa alguma coisa que pode ser executada, neste caso uma ad hoc
query.
9 SqlDataReader
o Representa a maneira mais rápida para ir buscar um conjunto de dados a
partir de uma Base de Dados.
Os objectos mencionados anteriormente foram utilizados nas operações de
pesquisar, inserir, consultar, eliminar e actualizar informação das diversas entidades sobre
a Base de Dados.
9 Para realizar a camada de lógica de negócio da operação de pesquisa definimos
um objecto Pesquisa, com o valor dos campos digitados pelo utilizador, de seguida
foi necessário utilizar um objecto SqlConnection para abrir uma ligação com o data
source. Quando se abre uma conexão é preciso que se defina a propriedade
ConnectionString do objecto SqlConnection.
SqlConnection myConnection = new SqlConnection();
Relatório do Projecto em Engenharia Informática
Página 44 de 62
Trabalho Realizado
myConnection.ConnecyionString
“UserID=sa;” + “Pwd=;”;
=
“Server=SQLSRV01;”
+
“Database=SMLS_04_0269;”
+
Connection String
De seguida, foi necessário preparar um objecto SqlCommand com a ad hoc
query a ser executada mediante um dado critério de pesquisa definido pelo
utilizador através da interface.
SqlCommand myCommand = new SqlCommand();
Para definir um critério foi necessário recorrer à utilização do objecto
SqlParameter, como podemos observar a seguir.
Criar um atributo do critério de
pesquisa, neste caso subsistemaId
SqlParameterCollection Params = myCommand.Parameters;
Params.Add(new SqlParameter("@subsistemaId", SqlDbType.Int));
Params["@subsistemaId"].Value = “S1”;
Propriedade do objecto SqlCommand
que define a ad hoc query a executar
myCommand.CommandText = “SELECT nome FROM Interessado”;
Associar um comando à
conexão definida anteriormente
myCommand.Connection = _ctx.Dados.Connection;
Executar a ad hoc query
sob o efeito de transacção
myCommand.Transaction = _ctx.Dados.Transaction;
Por fim, utilizou-se o objecto SqlDataReader para ir buscar o conjunto de
dados devolvidos pelo critério definido na operação pesquisar sobre a Base de
Dados. O conjunto de resultados, resultset, contido num SqlDataReader é forwardonly e read-only, isto significa que, somente se pode ler as linhas dentro de um
resultset sequencialmente a partir do inicio ao fim, não se pode modificar quaisquer
dados.
SqlDataReader myReader = myCommand.ExecuteReader();
while(myReader.Read()){
myReader.GetInt32(0),
//INTERESSADO_ID -> InteressadoId
myReader.GetString(1),
//SUB_SISTEMA_ID -> SubSistemaId
}
Cada resultado do conjunto de resultados é colocado num objecto Info, este
objecto foi criado por nós para guardar os dados vindos da Base de Dados para
posterior manipulação.
9 Na camada de lógica de negócio da operação de inserção criámos um objecto
Info com o valor do campos digitados pelo utilizador. Para além do objecto Info foi
também necessário utilizar um objecto SqlConnection, SqlCommand, SqlParameter
e definir as suas propriedades, tal como na operação de pesquisa. Ao invés da
operação de pesquisa, onde se utilizou o método ExecuteReader() do objecto
SqlCommand, na operação de inserção utiliza-se o ExecuteScalar(), este método
retorna a primeira coluna da primeira linha do resultset, neste caso, retorna o
identificador atribuído à nova ocorrência.
object ret = myCommand.ExecuteScalar();
Ou utiliza-se o ExecuteNonQuery(), este método não retorna um resultset, neste
caso, não pretendemos obter o identificador atribuído à nova ocorrência a quando
da inserção.
Relatório do Projecto em Engenharia Informática
Página 45 de 62
Trabalho Realizado
myCommand.ExecuteNonQuery();
9 Para a operação de consulta foram utilizados as mesmas propriedades e métodos
dos objectos mencionados na operação de pesquisa.
9 Para a operação de actualização foram utilizados as mesmas propriedades e
métodos dos objectos mencionados na operação de pesquisa, com excepção do
método ExecuteReader(), do objecto SqlCommand, que foi substituído pelo
método ExecuteNonQuery() e do objecto Pesquisa que foi substituído por dois
objectos Info, um com os novos dados actualizados, o outro com os dados não
actualizados, isto para saber quais os campos a actualizar.
myCommand.ExecuteNonQuery();
9 Para a operação de eliminação foram utilizados as mesmas propriedades e
métodos dos objectos mencionados na operação de actualização, com excepção dos
objectos Info.
4.2.4.3
Camada de Base de Dados
Esta camada é responsável pela persistência dos dados da aplicação, isto foi
conseguido com a utilização de uma Base de Dados. O Sistema de Gestão de Base de
Dados foi o SQL Server.
A informação foi organizada em tabelas, atributos e registos. E de seguida foi
definido o modo como estas tabelas se relacionam entre si.
Para aceder e manipular os dados da Base de Dados SQL Server usou-se ad hoc
queries. As Ad hoc queries fornecem uma maneira rápida de ir buscar dados á Base de
Dados ou de fazer alterações na Base de Dados.
As quatro principais instruções T-SQL usadas para manipular os dados SQL Server
foram:
9 SELECT
o Instrução que permite ir buscar os dados armazenados na Base de Dados.
9 INSERT
o Instrução permite adicionar novos dados à Base de Dados.
9 UPDATE
o Esta instrução permite modificar dados que já se encontram na Base de
Dados.
9 DELETE
o Através desta instrução é possível eliminar dados a partir da Base de Dados.
Para construir as ad hoc queries foi utilizada a ferramenta SQL Server Query
Analyzer.
Relatório do Projecto em Engenharia Informática
Página 46 de 62
Trabalho Realizado
O ambiente de desenvolvimento usado para gerir tabelas, campos e dados;
relacionamentos de tabelas; e criar diagramas de base de dados. foi o SQL Server
Enterprise Manager.
No Anexo I encontra-se o Modelo de Dados da aplicação.
4.2.5 Plano de testes
Este capitulo foca sobre o plano de testes a executar sobre a aplicação desenvolvida
anteriormente.
O objectivo dos testes é avaliar a conformidade da aplicação desenvolvida
relativamente aos requisitos especificados e ao desenho, garantindo deste modo a qualidade
do código produzido.
Para a aplicação em questão foram escolhidos fazer Testes Funcionais (caixa preta),
tendo em conta o baixo orçamento e a importância que estes trazem para o SIMLIS. Por
exemplo, os Testes de Carga não são de tanta importância, uma vez que, o tempo de
resposta não é importante e a quantidade de dados é baixa.
Cada especificação de testes é identificada por:
9 Ref. Teste
o Por exemplo, 1.
9 Classe Teste
o Por exemplo, FU – Funcional e UI – User Interface.
9 Teste a executar
o Por exemplo, inserir interessado já existente.
9 Passos/detalhe do teste
o Por exemplo, Escolher Parcela e de seguida inserir novo registo usando o
NOME de um interessado já existente.
9 Requisitos/Pré-Condições
o Por exemplo, Perfil Cadastro.
9 Resultado esperado
o Por exemplo, o sistema não permite e apresenta uma mensagem a informar.
9 Responsável pela execução
9 Data execução
Relatório do Projecto em Engenharia Informática
Página 47 de 62
Trabalho Realizado
9 Resultado
Após a realização destes testes, efectuados por uma equipa, sempre que possível,
distinta da de desenvolvimento, serão feitos os testes pelo cliente para se dar a aceitação da
aplicação.
4.2.6 Trabalho realizado por mim
No projecto em questão, a minha contribuição foi dada nas Fases de
Implementação, Transição e Operação onde fui um dos elementos da equipa responsável
pela implementação da aplicação Web.
Quando entrei no projecto o meu trabalho foi ler os documentos da especificação
funcional e técnica que tinha de seguir para realizar o trabalho, para depois ser feita uma
reunião com o Responsável Técnico para tirar dúvidas que eventualmente surgissem.
Passada esta altura fui integrado na equipa de desenvolvimento.
O documento de referência de Mateus, Paulo (2004) - “SMLS_04_0269
Especificação Técnica” e Mateus, Paulo (2004) - “SMLS_04_0269 Especificação
Funcional”, onde se encontra a especificação técnica e funcional do projecto, não está
disponível*.
Durante a fase de planeamento decidiu-se que eu na Fase de Implementação iria ter
a oportunidade de fazer um pouco de tudo excepto o Modelo de Dados que iria ser feito
por outro elemento experiente nessa área.
Eu fiquei responsável por desenvolver a camada de interface, as páginas ASP.NET,
e a camada da lógica de negócio, os ficheiros de acesso à Base de Dados, para as entidades
Interessado, Contacto, Pagamentos, Gestão de Pedidos Dup, Gestão de Referências
Documentos da Pedido Dup, Gestão de Referências de Documentos de Contacto, Gestão
de Despesas, Gestão de Correspondência e Gestão de Pedidos de Pagamento.
Na Fase de Transição, fui responsável pela elaboração do Manual de Utilização da
aplicação.
Por fim também fui integrado na Fase de Operação onde terei como funções
assegurar a manutenção correctiva dos desenvolvimentos efectuados.
Relatório do Projecto em Engenharia Informática
Página 48 de 62
5 SUMÁRIO E
CONCLUSÕES
Relatório do Projecto em Engenharia em Informática
Página 49 de 62
Sumário e Conclusões
5.1 SUMÁRIO
Este capitulo apresenta uma síntese do trabalho que foi realizado neste estágio.
O resultado deste estágio foi o desenvolvimento de uma Web Application que
permite efectuar as operações inserir, actualizar, pesquisar, consultar e eliminar sobre a
informação que se encontra numa Base de Dados, que permitirá aos colaboradores SIMLIS
obter um registo de vários pontos fulcrais como, contactos efectuados, registo de
documentação e controlo de pagamentos.
A aplicação em questão foi desenvolvida de forma a ser acedida através da Internet.
Para o efeito, foi necessário configurar o IIS para criar uma Web que receba os pedidos dos
clientes e envie-os à aplicação para respectivo processamento e que devolva o resultado do
processamento ao cliente.
5.2 CONCLUSÕES
Durante este período de estágio na LINK tive a oportunidade de trabalhar com um
conjunto diversificado de tecnologias na área das Web Applications, que revolucionaram o
mercado quer pelo ambiente de execução quer pelas linguagens que dispõe, muito
poderosas para a criação de aplicações.
Tive o privilégio de prestar os meus serviços numa das grandes empresas deste país
na área de consultoria informática, quer pela diversidade de áreas de competência, quer
pelos clientes, onde destaco a unidade em que estive inserido durante este período, a UPI..
Aqui foi-me dada a possibilidade de integração em ambientes de produção, a aquisição de
novos conhecimentos, ganhar autonomia e experiência profissional. Este estágio foi a
ponte entre a vida académica e a vida profissional.
A parte curricular da licenciatura teve papel preponderante na minha formação,
onde destaco as cadeiras de Fundamentos de Sistemas de Informação, Tecnologias de Base
de Dados, Programação Imperativa, Interfaces Pessoa-Máquina e Projecto de Sistemas de
Informação que contribuíram de forma decisiva para a angariação de outros conhecimentos
fundamentais para a realização deste projecto.
Por fim, este estágio permitiu-me realizar uma certificação “Microsoft 70-315:
Developing and Implementing Web Applications with Microsoft Visual C#.NET”, nas
tecnologias que utilizei para a realização do projecto, passando assim a possuir um titulo de
MCP (Microsoft Certified Professional).
Relatório do Projecto em Engenharia Informática
Página 50 de 62
6 GLOSSÁRIO
Relatório do Projecto em Engenharia em Informática
Página 51 de 62
Glossário
A lista de siglas e abreviaturas utilizadas neste documento encontram-se
organizadas por ordem alfabética ascendente.
*
**
ADO
API
ASP
ASP.NET
BCL
CLR
CLS
CSS
CVS
ETAR
HTML
IE
IIS
INESC
FCUL
LINK
MCH
MSIL
PC
PEDIP
PL/SQL
PMI
PSO
RUP
SIMLIS
SOAP
T-SQL
UPI
URL
VBA
VS
VSS
XML
XSL
WAP
WBS
WSDL
WWW
Documento interno que não pode ser divulgado.
Alguns dados não podem ser divulgados, por serem dados pessoais.
Access Data Objects
Application Programming Interface
Active Server Pages
Active Server Pages .NET
Base Class Library
Common Language Runtime
Common Language Specification
Cascading Style Sheets
Concurrent Version System
Estação de Tratamento de Águas Residuais
HyperText Markup Language
Internet Explorer
Internet Information Services
Instituto de Engenharia de Sistemas de Computadores
Faculdade de Ciências da Universidade de Lisboa
Link Consulting – Tecnologias de Informação, S.A.
Modelo Continente Hipermercados
Microsoft Intermediate Language
Personal Computer
Programa Estrutural de Desenvolvimento para a Indústria Portuguesa
Procedural Language / Structured Query Language
Project Management Institute
Project Support Office
Rational Unified Process
Saneamento Integrado dos Municípios do Lis
Simple Object Access Protocol
Transact-Structured Query Language
Unidade de Portais & Intranets
Uniform Resource Locator
Visual Basic for Applications
Visual Studio
Visual Source Safe
Extensible Markup Language
Extensible Stylesheet Language
Wireless Application Protocol
Work Breakdown Structure
WebServices Description Language
World Wide Web
Relatório do Projecto em Engenharia Informática
Página 52 de 62
7 BIBLIOGRAFIA E
REFERÊNCIAS
Relatório do Projecto em Engenharia em Informática
Página 53 de 62
Bibliografia e Referências
7.1 ENDEREÇOS WEB
http://msdn.microsoft.com/library
- Portal de Documentação sobre Programação
http://www.pontonetpt.com
- Portal de Documentação sobre Programação .NET
http://www.link.pt
- Site da Link Consulting – Tecnologias de Informação, S.A.
http://www.w3schools.com
- Portal de Documentação sobre Programação para a Web
http://www.codeproject.com/aspnet
- Portal de Documentação sobre Programação para a Web
http://www.hitmill.com/programming/dotnet/csharphtml
- Site com uma série de Links para sites de C#
http://www.softsteel.co.uk/tutorials/cSharp/contents.html
- Site sobre programação C#
http://www.adp.pt
- Site das Águas de Portugal
7.2 LIVROS E DOCUMENTOS
Kalani, Amit (2003) - “MCAD/MCSD Training Guide (70-315): Designing And
Implementing Web Applications With Visual C# .NET”
Microsoft - “Documentação do .NET Framework SDK” USA: Microsoft, 2000
Marques, Paulo e Cardoso, Hernâni (2002) - “C# Curso Completo”
Assunção, João (2003) - “Metodologia de Desenvolvimento de Aplicações
Workflow”
Vieira, João (2003) - “Programação com ASP.NET”
Falcão, Luís (2003) - “A plataforma .NET”, Centro de Cálculo do Instituto
Superior de Engenharia de Lisboa
Link Consulting (2004) - “Proposta nº SMLS_04_0269”
Link Consulting (2004) - “Metodologia de Gestão de Projectos”
Relatório do Projecto em Engenharia Informática
Página 54 de 62
Bibliografia e Referências
Mateus, Paulo (2004) - “SMLS_04_0269 Especificação Técnica”
Mateus, Paulo (2004) - “SMLS_04_0269 Especificação Funcional”
Bento, Bruno (2005) - “SMLS_04_0269 Manual Utilizador”
Monteiro, Paulo (2004) - “Proposta Desenvolvimento: PEP - Desenvolvimento da
template v1.18”
Relatório do Projecto em Engenharia Informática
Página 55 de 62