relatorio abracar@escola

118
IPV- Instituto Politécnico de Viseu ESTV - Escola Superior de Tecnologia de Viseu Departamento de Informática Relatório de Projecto/Estágio da Licenciatura em Engenharia Informática Sistema de Gestão de Agrupamento de Escolas - Projecto Abraçar@Escola Realizado em Agrupamento de Escolas de Abraveses por António Manuel Costa Nascimento Nuno Miguel Mendes Marques Orientadores ESTV – Engenheiro José António Oliveira Entidade – Professor José Adriano de Almeida Agnelo Viseu, 2007

Upload: antonio-nascimento

Post on 29-Nov-2014

1.298 views

Category:

Documents


1 download

DESCRIPTION

Tese final Licenciatura

TRANSCRIPT

Page 1: Relatorio Abracar@Escola

IPV- Instituto Politécnico de Viseu ESTV - Escola Superior de Tecnologia de Viseu

Departamento de Informática

Relatório de Projecto/Estágio da Licenciatura em Engenharia Informática

Sistema de Gestão de Agrupamento de Escolas - Projecto Abraçar@Escola

Realizado em

Agrupamento de Escolas de Abraveses por

António Manuel Costa Nascimento

Nuno Miguel Mendes Marques

Orientadores ESTV – Engenheiro José António Oliveira Entidade – Professor José Adriano de Almeida Agnelo

Viseu, 2007

Page 2: Relatorio Abracar@Escola

IPV- Instituto Politécnico de Viseu ESTV - Escola Superior de Tecnologia de Viseu

Departamento de Informática

Relatório de Projecto/Estágio da Licenciatura em Engenharia Informática

Sistema de Gestão de Agrupamento de Escolas - Projecto Abraçar@Escola

2007

Realizado em

Agrupamento de Escolas de Abraveses de

15-02-2007 a 06-07-2007

Por

António Manuel Costa Nascimento Nuno Miguel Mendes Marques

Orientadores

ESTV – Engenheiro José António Oliveira Entidade - Professor José Adriano de Almeida Agnelo

Viseu, 2007

Page 3: Relatorio Abracar@Escola

Agradecimentos

Gostaríamos de agradecer a todas as pessoas que nos ajudaram e apoiaram no

desenvolvimento deste projecto ao longo de vários meses. Queríamos agradecer

especialmente a ajuda dos nossos orientadores tanto o da Instituição acolhedora como o do

Instituto Politécnico de Viseu.

Não nos poderíamos esquecer também dos nossos pais, namorada, amigos que com muita

paciência nos ajudaram nos momentos mais difíceis, para assim podermos concluir este

trabalho.

Durante a aprendizagem das linguagens e ferramentas usadas não nos podemos esquecer do

grande contributo e ajuda do professor José Agnelo.

I

Page 4: Relatorio Abracar@Escola

Resumo

Este projecto propõe desenvolver um sistema de gestão de conteúdos, através de um portal,

que tem como principal objectivo a disseminação, partilha e acesso à informação entre os

vários actores do universo da Escola, tais como, os Alunos, Professores, Encarregados de

Educação e sociedade em geral.

Pretende-se de certa maneira promover o trabalho colaborativo e a aplicação das novas

tecnologias de informação e comunicação, por toda a comunidade escolar. Este projecto

consiste numa solução on-line, alojada num servidor próprio. A construção deste espaço de

partilha e divulgação de informação está relacionada com a gestão do próprio agrupamento,

bem como o apoio às actividades desenvolvidas no mesmo.

O portal Abraçar@Escola irá conter três funcionalidades principais, um Sistema de INews

dinâmico, que vai permitir fazer toda a gestão de conteúdos do site, uma agenda de eventos,

com as funcionalidades de eventos enviados para o e-mail e impressão de modelos, para uma

futura impressão. Por fim haverá o Help-Desk que terá a funcionalidade básica de um fórum,

onde pode ser colocada informação e também um local onde os professores poderão tirar

dúvidas aos alunos e ou encarregados de Educação.

O projecto Abraçar@Escola consiste numa solução baseada no modelo Application Service

Provider, podendo adoptar uma arquitectura distribuída, uni ou multi-instância, e sendo

suportada por tecnologias abertas e acessíveis em larga escala, preferencialmente via web.

Palavras-chave:

Gestão de Conteúdos escolares, e-Learning, disseminação, partilha e acesso à informação,

trabalho colaborativo.

II

Page 5: Relatorio Abracar@Escola

Índice

Agradecimentos ...........................................................................................................................I Resumo ...................................................................................................................................... II Índice ........................................................................................................................................ III Índice de Tabelas .......................................................................................................................V Índice de Figuras ......................................................................................................................VI 1. Introdução...........................................................................................................................1

1.1. Problema.....................................................................................................................1 1.2. Nota Introdutória ........................................................................................................2 1.3. Enquadramento...........................................................................................................3 1.4. Objectivos e Contribuições.........................................................................................4 1.5. Organização do relatório ............................................................................................5

2. Fundamentos Teóricos........................................................................................................6 2.1. Linguagens Utilizadas ................................................................................................7

2.1.1. Linguagem HTML ..............................................................................................7 2.1.2. ASP.NET ............................................................................................................9 2.1.3. Linguagem SQL SERVER ...............................................................................16 2.1.4. Linguagem AJAX.............................................................................................19 2.1.5. Linguagem VB ..................................................................................................20

2.2. Ferramentas Utilizadas .............................................................................................21 2.2.1. Visual Studio .NET ..........................................................................................21 2.2.2. Internet Information Service.............................................................................23 2.2.3. Microsoft SQL Server ......................................................................................23 2.2.4. Adobe Photoshop..............................................................................................24

3. Estudo da Usabilidade ......................................................................................................26 3.1. Princípios de Design .................................................................................................26

3.1.1. Proximidade......................................................................................................26 3.1.2. Alinhamento .....................................................................................................26 3.1.3. Repetição ..........................................................................................................27 3.1.4. Contraste...........................................................................................................27

3.2. Perguntas de Heurística ............................................................................................28 3.2.1. Público-alvo......................................................................................................28 3.2.2. Objectivo do site...............................................................................................28 3.2.3. O que o Público-alvo espera do portal..............................................................29 3.2.4. A atitude a imprimir ao portal ..........................................................................30 3.2.5. A sensação a transmitir ao utilizador................................................................30 3.2.6. As cores dominantes.........................................................................................31

4. Análise e Requisitos .........................................................................................................32 4.1. Requisitos Não Funcionais .......................................................................................32

4.1.1. Usabilidade .......................................................................................................32 4.1.2. Desempenho e escalabilidade...........................................................................33 4.1.3. Independência do local e do tipo de acesso......................................................33 4.1.4. Privacidade e confidencialidade .......................................................................33 4.1.5. Abertura e integração com outros sistemas ......................................................33 4.1.6. Avisos/Alertas segundo múltiplas formas ........................................................34

4.2. Requisitos Funcionais...............................................................................................34

III

Page 6: Relatorio Abracar@Escola

4.2.1. Actores principais .............................................................................................35 4.2.2. Casos de uso principais ....................................................................................36

4.3. Modelo Entidade Relacionamento............................................................................39 4.3.1. Diagrama ER ....................................................................................................39 4.3.2. Tabela Pessoas..................................................................................................41 4.3.3. Relação Pessoas – Pessoas_Cargos – Cargos...................................................41 4.3.4. Relação Pessoas_Cargos – Pessoas_Orgaos - Orgaos......................................42 4.3.5. Relação Pessoas_Orgaos – Eventos – Pessoas_Eventos ..................................43 4.3.6. Relação Pessoas_Orgaos – Noticias .................................................................43 4.3.7. Relação Menus – Submenus – Noticias ...........................................................44 4.3.8. Tabela Históricos..............................................................................................45 4.3.9. Tabela Citações ................................................................................................45

5. Desenvolvimento e Disposição do Portal.........................................................................47 5.1. Interface Gráfica .......................................................................................................47

5.1.1. Página Principal do Portal ................................................................................47 5.1.2. Página Notícias .................................................................................................48 5.1.3. Página Eventos .................................................................................................49 5.1.4. Página do Fórum...............................................................................................50

5.2. Painel Administrativo...............................................................................................51 5.2.1. Funcionalidades do Painel Administrativo.......................................................51 5.2.2. Zona de gestão utilizadores ..............................................................................52 5.2.3. Zona de gestão de Cargos.................................................................................54 5.2.4. Zona de Gestão de Órgãos................................................................................55 5.2.5. Zona de gestão de notícias................................................................................58 5.2.6. Zona de gestão de eventos ................................................................................59 5.2.7. Zona de Gestão de Citações .............................................................................62 5.2.8. Zona de gestão de menus e sub menus .............................................................62 5.2.9. Zona de gestão de Históricos............................................................................63

6. Conclusões........................................................................................................................65 6.1. Validação dos Objectivos Originais .........................................................................65 6.2. Principais Contribuições...........................................................................................65 6.3. Trabalho Futuro ........................................................................................................65 6.4. Conclusão .................................................................................................................66

Referências ...............................................................................................................................67 Bibliografia...............................................................................................................................68 7. Anexo A – Application Code ...........................................................................................69 8. Anexo B – Scripts da Base de Dados .............................................................................103

IV

Page 7: Relatorio Abracar@Escola

Índice de Tabelas

Tabela 2-1 Estrutura do cabeçalho num documento HTML ......................................................8 Tabela 2-2 Estrutura do corpo num documento HTML............................................................9 Tabela 2-3 - Ficheiros de uma Aplicação Web ........................................................................13

V

Page 8: Relatorio Abracar@Escola

Índice de Figuras

Figura 1-1 Visão global do projecto Abraçar@Escola...............................................................3 Figura 2-1 Estrutura de um documento HTML..........................................................................7 Figura 2-2 Visão global da framework .NET............................................................................10 Figura 2-3 Tecnologia Clinte Servidor ASP.Net......................................................................12 Figura 2-4 Exemplo de código de um ficheiro .aspx vazio ......................................................13 Figura 2-5 Estrutura de Pastas de uma aplicação Web.............................................................14 Figura 2-6 Páginas Code-Behind..............................................................................................14 Figura 2-7 Ligação de Código de Páginas Code-Behind .........................................................15 Figura 2-8 Configurar a segurança de acesso ao código ASP.NET .........................................15 Figura 2-9 Modelo Clássico com e sem AJAX .........................................................................20 Figura 2-10 - Criação Projecto Visual Studio...........................................................................21 Figura 2-11 Aspecto visual do ambiente do Visual Studio. NET .............................................22 Figura 2-12 Criação de uma Base de dados no SQL Server .....................................................24 Figura 2-13 - Exemplo de uma imagem aberta com o Photoshop ...........................................25 Figura 4-1 Vários Actores intervenientes do projecto Abraçar@Escola .................................36 Figura 4-2 Casos de Uso - Cargos e Utilizadores.....................................................................37 Figura 4-3 Casos de Uso - Criação de Órgãos..........................................................................37 Figura 4-4 Casos de uso - Gerir Noticias .................................................................................38 Figura 4-5 Casos de uso Fórum................................................................................................38 Figura 4-6 Casos de Uso - Eventos ..........................................................................................39 Figura 4-7 Modelo Entidade Relacionamento Abraç[email protected] Figura 4-8 Constituição de tbl_Pessoas....................................................................................41 Figura 4-9 Relação Pessoas – Pessoas_Cargos – Cargos .........................................................42 Figura 4-10 Relação Pessoas_Cargos – Pessoas_Orgaos - Orgaos..........................................43 Figura 4-11 Relação Pessoas_Orgaos – Eventos – Pessoas_Eventos ......................................43 Figura 4-12 Relação Pessoas_Orgaos – Noticias .....................................................................44 Figura 4-13 Relação Menus – Submenus – Noticias................................................................45 Figura 4-14 Tabela Históricos ..................................................................................................45 Figura 4-15 Tabela Citações.....................................................................................................46 Figura 5-1 - Aspecto visual do Portal Abraçar@Escola...........................................................47 Figura 5-2 Aspecto visual do módulo de Notícias ...................................................................48 Figura 5-3 Aspecto visual do módulo de Eventos....................................................................49 Figura 5-4 - Aspecto Visual do Fórum Abraçar@Escola.........................................................50 Figura 5-5 Aspecto Visual do Painel Administrativo Abraçar@Escola ..................................51 Figura 5-6 Ícones situados no topo do Painel de Administração, correspondentes ás funcionalidades.........................................................................................................................51 Figura 5-7 Tabela de Utilzadores com acesso..........................................................................52 Figura 5-8 - Opções e Datalist de Utilizadores.........................................................................52 Figura 5-9 Formulário para criação de um utilizador...............................................................52 Figura 5-10 Atribuição de Cargos a um certo número de utilizadores.....................................53 Figura 5-11 Envio de dados por SMS e Correio electrónico aos utilizadores..........................54 Figura 5-12 Tabela de Cargos ..................................................................................................54 Figura 5-13 Opções e Datalist de Cargos .................................................................................55 Figura 5-14 Preenchimento de um novo cargo.........................................................................55 Figura 5-15 Tabela Órgãos .......................................................................................................55

VI

Page 9: Relatorio Abracar@Escola

Figura 5-16 Opções e Datalist de Órgãos.................................................................................56 Figura 5-17 Criação de um Órgão ............................................................................................56 Figura 5-18 Atribuição de Utilizadores a Órgãos.....................................................................57 Figura 5-19 Atribuições de Utilizadores a um Orgão ..............................................................57 Figura 5-20 Tabela de Notícias ................................................................................................58 Figura 5-21 Opções e Datalist das Notícias .............................................................................58 Figura 5-22 Preenchimento do formulário Notícias .................................................................59 Figura 5-23 Tabela de Eventos.................................................................................................59 Figura 5-24 Opções de Datalist de Eventos .............................................................................60 Figura 5-25 Preenchimento do Formulário Eventos ................................................................60 Figura 5-26 Atribuição de utilizadores a eventos e possibilidade de enviar notificações........61 Figura 5-27 Opções da tabela Citações ....................................................................................62 Figura 5-28 Preenchimento de Citações...................................................................................62 Figura 5-29 - Opções de Menus e Sub Menus..........................................................................62 Figura 5-30 Criação de um novo menu ....................................................................................63 Figura 5-31 Criação de um Sub menu......................................................................................63 Figura 5-32 Tabela de Históricos .............................................................................................63 Figura 5-33 Opções de Históricos ............................................................................................64 Figura 5-34 Histórico de utilizadores .......................................................................................64 Figura 5-35 Histórico de Notícias ............................................................................................64 Figura 5-36 Histórico de Eventos.............................................................................................64 Figura 7-1 Ficheiro clsCalendario.vb .......................................................................................69 Figura 7-2 Ficheiro clsCargos.vb – parte 1/3 ...........................................................................70 Figura 7-3 Ficheiro clsCargos.vb – parte 2/3 ...........................................................................70 Figura 7-4 Ficheiro clsCargos.vb – parte 3/3 ...........................................................................71 Figura 7-5 Ficheiro clsCitacoes.vb...........................................................................................71 Figura 7-6 Ficheiro clsEmail.vb ...............................................................................................72 Figura 7-7 Ficheiro clsEncriptar.vb- parte 1/2 .........................................................................73 Figura 7-8 Ficheiro clsEncriptar.vb- parte 2/2 .........................................................................74 Figura 7-9 Ficheiro clsEventos.vb – parte 1/8..........................................................................75 Figura 7-10 Ficheiro clsEventos.vb – parte 2/8........................................................................76 Figura 7-11 Ficheiro clsEventos.vb – parte 3/8........................................................................76 Figura 7-12 Ficheiro clsEventos.vb – parte 4/8........................................................................77 Figura 7-13 Ficheiro clsEventos.vb – parte 5/8........................................................................78 Figura 7-14 Ficheiro clsEventos.vb – parte 6/8........................................................................79 Figura 7-15 Ficheiro clsEventos.vb – parte 7/8........................................................................80 Figura 7-16 Ficheiro clsEventos.vb – parte 8/8........................................................................81 Figura 7-17 Ficheiro clsHistorico.vb – parte 1/13....................................................................81 Figura 7-18 Ficheiro clsHistorico.vb – parte 2/13....................................................................82 Figura 7-19 Ficheiro clsHistorico.vb – parte 3/13....................................................................83 Figura 7-20 Ficheiro clsHistorico.vb – parte 4/13....................................................................83 Figura 7-21 Ficheiro clsHistorico.vb – parte 5/13....................................................................84 Figura 7-22 Ficheiro clsHistorico.vb – parte 6/13....................................................................85 Figura 7-23 Ficheiro clsHistorico.vb – parte 7/13....................................................................85 Figura 7-24 Ficheiro clsHistorico.vb – parte 8/13....................................................................86 Figura 7-25 Ficheiro clsHistorico.vb – parte 9/13....................................................................87 Figura 7-26 Ficheiro clsHistorico.vb – parte 10/13..................................................................87 Figura 7-27 Ficheiro clsHistorico.vb – parte 11/13..................................................................88 Figura 7-28 Ficheiro clsHistorico.vb – parte 12/13..................................................................89 Figura 7-29 Ficheiro clsHistorico.vb – parte 13/13..................................................................89

Figura 7-30 Ficheiro clsPessoas.vb – parte 1/8 ........................................................................90

VII

Page 10: Relatorio Abracar@Escola

Figura 7-31Ficheiro clsPessoas.vb – parte 2/8 .........................................................................90 Figura 7-32 Ficheiro clsPessoas.vb – parte 3/8 ........................................................................91 Figura 7-33 Ficheiro clsPessoas.vb – parte 4/8 ........................................................................92 Figura 7-34 Ficheiro clsPessoas.vb – parte 5/8 ........................................................................92 Figura 7-35 Ficheiro clsPessoas.vb – parte 6/8 ........................................................................93 Figura 7-36 Ficheiro clsPessoas.vb – parte 7/8 ........................................................................93 Figura 7-37 Ficheiro clsPessoas.vb – parte 8/8 ........................................................................94 Figura 7-38 Ficheiro clsSms.vb................................................................................................95 Figura 7-39 Ficheiro clsMenus.vb– parte 1/2...........................................................................96 Figura 7-40 Ficheiro clsMenus.vb– parte 2/2...........................................................................97 Figura 7-41 Ficheiro clsNoticias.vb– parte 1/5 ........................................................................98 Figura 7-42 Ficheiro clsNoticias.vb– parte 2/5 ........................................................................99 Figura 7-43 Ficheiro clsNoticias.vb– parte 3/5 ......................................................................100 Figura 7-44 Ficheiro clsNoticias.vb– parte 4/5 ......................................................................101 Figura 7-45 Ficheiro clsNoticias.vb– parte 5/5 ......................................................................102

VIII

Page 11: Relatorio Abracar@Escola

1.Introdução

1. Introdução

1.1. Problema

As sociedades actuais encontram-se em plena era da informação. Neste contexto a educação é

considerada como sendo uma importante área estratégica de desenvolvimento, riqueza e

prosperidade. Portugal tem vindo a concretizar progressivamente nas últimas décadas um

esforço muito significativo na aposta do e-government, que consiste em propôr e discutir

formas de gestão desburocratizadas, participadas e eficientes suportadas por arquitecturas de

sistemas de informação, não só na área da educação mas também em sistemas de logística,

transporte, turismo, entre outras [1,2,3].

O sistema de ensino tem vindo a ser alvo de várias tentativas de adaptação às novas

tecnologias, de tentativas de desburocratização, de tentativas de aceleração dos processos

envolvidos. O problema tem sido que são os processos que são adaptados e não as tecnologias

que são inteiramente aproveitadas. Tal como uma grande empresa, o sistema de ensino é

composto por vários departamentos, muitos recursos humanos, materiais e processos de

workflow complexos e distribuídos. Mas ao contrário de uma grande empresa, não tem um

departamento de Tecnologias de Informação que estuda estes processos e os tenta resolver a

um nível global. As escolas existem como ilhas isoladas, distintas e com uma forte falta de

intercomunicação.

Uma escola é constituída pelas mais diversas entidades, tais como: equipamento físico

(escola, salas, refeitório, biblioteca, espaços desportivos, enfermaria, etc.), funcionários do

conselho executivo (presidente, dois vice presidentes, vogais, etc.), funcionários da secretaria

(chefe, administrativos, etc.), docentes, discentes, encarregados de educação e funcionários

não docentes. Uma escola tem como objectivos leccionar e avaliar os seus alunos,

proporcionar-lhes actividades extracurriculares, participar resultados ao Ministério da

Educação, entre outros, contando para isso com todas as entidades atrás referidas.

A visão do Abraçar@Escola está numa solução que possa não só resolver os problemas de

uma escola, mas de todo o sistema de ensino e facilitar e modernizar os processos

envolventes.

1

Page 12: Relatorio Abracar@Escola

1.Introdução

1.2. Nota Introdutória

O projecto “Abraçar@Escola” consiste em desenvolver um sistema de informação que tem

como objectivo uniformizar, facilitar e suportar a gestão de conteúdos programáticos de

ensino, e gestão de Eventos realizados no sector escolar. De salientar que este projecto está

orientado ao sistema educativo público Português. O sistema desenvolvido terá de suportar as

seguintes funcionalidades: a gestão de escolas, alunos, órgãos, professores, turmas e

mecanismos de suporte ao e-learning, entre outras. Adicionalmente, tem como missão

facilitar a disseminação, partilha e acesso à informação entre os vários actores do universo da

educação, tais como alunos, professores, administrativos, encarregados de educação e

técnicos do Ministério da Educação.

O Abraçar@Escola adopta parcialmente o modelo Application Service Provider (ASP) e

consiste numa arquitectura distribuída-federada, multi-instância, sendo acessível a partir de

qualquer Web Browser, o que dispensa a instalação de componentes de software nas máquinas

dos utilizadores. O conceito da arquitectura distribuída-federada diz respeito ao facto de, para

além de existir uma instância única Abraçar@Escola, designada como global/nacional, se

poder vir a instalar instâncias do Abraçar@Escola locais/regionais a um ou mais

agrupamentos de escolas, ou nas próprias escolas, podendo as várias instâncias funcionar com

um razoável nível de autonomia.

O Abraçar@Escola é um sistema desenvolvido exclusivamente com tecnologia Microsoft,

tirando particular vantagem da infra-estrutura .NET e das seguintes tecnologias: SQL Server,

C# e ASP.NET.

O sistema de gestão do agrupamento de escolas de Abraveses assenta sobre a plataforma de

um portal, com três grandes funcionalidades. O portal vai suportar gestão de conteúdos

dinamicamente, de notícias, de agenda de eventos e do fórum. As funcionalidades de notícias

e eventos, irão ser mostradas de forma hierárquica, consoante o seu órgão ou cargos, para

assim tornar a gestão de conteúdos mais optimizada.

Espera-se que deste modo os vários intervenientes no agrupamento de escolas de Abraveses

possam através da Internet na escola ou em suas casas, interagir com o sistema, criando

notícias, adicionando eventos, participando activamente nos fóruns no caso de terem

permissões para tal.

2

Page 13: Relatorio Abracar@Escola

1.Introdução

1.3. Enquadramento

Este projecto final de curso foi desenvolvido no âmbito do projecto Abraçar@Escola que está

a cargo do Professor José Agnelo da Escola E.B 2,3 Azeredo Perdigão. Na Figura 1-1 é

possível ver as actividades que foram e estão a ser desenvolvidas no âmbito do projecto.

Figura 1-1 Visão global do projecto Abraçar@Escola

A primeira componente, “Gestão Organizacional”, tem como objectivo garantir o suporte

modular e extensível de aspectos gerais de um sistema típico de ASP. Entre outros, este

componente garante o suporte de conceitos como serviços, pessoas, órgãos, cargos, secções e

menus. Adicionalmente, suporta conceitos gerais tais como: utilizadores, permissões, e

controlos de acesso.

A segunda componente, “Gestão Operacional”, tem como objectivo providenciar um

conjunto específico de serviços de gestão do ensino. Concretamente, encontram-se definidos

as seguintes funcionalidades: gestão de notícias, gestão de eventos, gestão de utilizadores,

fórum digital e suporte ao e-Learning. O objectivo deste trabalho foi realizar esta componente

do projecto Abraçar@Escola. Ao longo deste relatório irá ser descrito todo o trabalho

realizado no âmbito desta componente. Consideramos esta componente, como a parte

fundamental do nosso projecto, pois é aqui que estão implementadas as funcionalidades que

melhor podem servir interesses tanto por parte do corpo docente da escola, como dos alunos e

seus encarregados de educação.

3

Page 14: Relatorio Abracar@Escola

1.Introdução

Por fim, a terceira componente, “Disseminação e Acesso à Informação” tem como objectivo

a produção e disseminação de informação das escolas do agrupamento de Abraveses.

Adicionalmente, esta informação será publicada e ou disseminada automaticamente segundo

diferentes aproximações, desde publicação de informação em locais electrónicos apropriados

da escola, até ao envio dessa informação via EMail ou SMS; passando por uma integração

mais coesa com base em Web Services apropriados.

1.4. Objectivos e Contribuições

O projecto pretende que ao longo do segundo semestre do ano lectivo 2006/2007, seja

construído um espaço na Web de partilha e divulgação de informação relacionada com a

gestão do agrupamento de escolas de Abraveses, bem como o apoio às actividades

desenvolvidas no mesmo.

A construção do espaço na Web, será um projecto colaborativo entre alunos, professores,

órgãos do agrupamento e encarregados de educação.

Os objectivos inerentes ao projecto em questão são os seguintes:

‒ Dinamizar a comunicação entre os diferentes intervenientes do processo educativo do

agrupamento;

‒ Compilação de conteúdos educativos genéricos;

‒ Informação institucional e promocional;

‒ Plataforma para gestão de conteúdos,

‒ Fomentar a partilha de conteúdos disciplinares;

‒ Fomentar a transparência do processo educativo;

‒ Promover a educação para a sociedade do conhecimento;

‒ Promover a literacia digital dos agentes educativos;

‒ Desenvolver um espírito colaborativo entre as escolas do agrupamento;

‒ Aumentar a abertura da escola à comunidade em que se insere;

4

Page 15: Relatorio Abracar@Escola

1.Introdução

‒ Fomentar a aplicação das T.I.C. na prática pedagógica dos professores;

‒ Fomentar nos alunos a utilização pedagógica das T.I.C., designadamente a Internet,

como instrumento de aprendizagem;

‒ Promover aprendizagens no âmbito disciplinar independentemente do espaço físico da

escola;

‒ Fomentar o uso educativo do computador;

1.5. Organização do relatório

Este relatório está dividido em capítulos e sub-capítulos, de modo a utilização deste, seja mais

fácil, a sua compreensão do conteúdo e o seu desenvolvimento lógico.

No capítulo dois iremos falar sobre as linguagens e ferramentas usadas no nosso projecto. No

capítulo três falamos sobre aspectos de usabilidade e heurísticas do nosso portal. No capítulo

quatro falamos sobre requisitos funcionais, não funcionais, actores, casos de uso e por fim do

nosso modelo entidade relacionamento. Por fim no capítulo cinco apresentamos a estrutura do

nosso portal, quer para a aplicação Web para cliente, quer para a aplicação Web para

administrador.

5

Page 16: Relatorio Abracar@Escola

2.Fundamentos Teóricos

2. Fundamentos Teóricos

O projecto Abraçar@Escola está a ser desenvolvido recorrendo a ferramentas e tecnologias da

Microsoft, nomeadamente a plataforma de desenvolvimento .NET, para efectuar o seu

desenvolvimento. Recorremos ao uso de páginas ASP.NET, com uso intensivo de Web

Controls que permitem a replicação e o aproveitamento de código e funcionalidades comuns,

de forma a acelerar o processo de desenvolvimento da aplicação através das classes

providenciadas pela framework.

Visto todas as interacções entre o sistema e os utilizadores se efectuarem no contexto da

Internet, tornou-se necessário a utilização de um servidor Web para disponibilizar os serviços

aos utilizadores, o servidor escolhido foi o IIS (Internet Information Service), este servidor

permite uma fácil integração com a plataforma de desenvolvimento .NET e com o SQL

Server. De início instalámos o IIS nos nossos computadores pessoais para efectuarmos os

testes necessários, mas após isso passámos toda a aplicação para o servidor que o Instituto

Politécnico de Viseu nos cedeu. Para tal tivemos que recorrer a várias pesquisas sobre como

poderíamos configurar a nossa aplicação no servidor que nos tinha sido cedido.

Relativamente aos dados que o sistema terá de manipular, estes são mantidos e geridos por

uma base de dados SQL Server, permitindo um fácil escalonamento, backup e replicação ou

sincronização de dados. Essa base de dados fica a cargo do servidor do IPV, ao qual

necessitamos de pedir uma conta para alojar a nossa base de dados. Uma vez criada a conta

para a base de dados, teríamos que aceder a um interface online, o SQL Management, onde

podemos inserir as tabelas, procedimentos, vistas e correr scripts em código SQL.

Foram seleccionadas estas ferramentas e tecnologias devido aos seguintes factores:

• A existência de um protocolo de licenças para desenvolvimento e ensino entre a

Microsoft e o Instituto Politécnico de Viseu;

• A plataforma de desenvolvimento .NET ser relativamente recente, por este motivo

existe um interesse em explorar esta plataforma e as tecnologias nela presentes;

• A constatação da qualidade, fiabilidade e produtividade das ferramentas Microsoft.

6

Page 17: Relatorio Abracar@Escola

2.Fundamentos Teóricos

2.1. Linguagens Utilizadas

2.1.1. Linguagem HTML

A linguagem HTML (acrónimo para a língua inglesa: HyperText Markup Language, que

significa Linguagem de Marcação de Hipertexto) é uma linguagem de marcação utilizada para

produzir páginas na Web. Os documentos em HTML, podem ser interpretados por todos os

browers [4].

Todos os documentos HTML apresentam etiquetas, elementos entre parênteses angulares

(sinais de maior e menor) (< e >). Estes Elementos são os comandos de formatação da

linguagem. A maioria das etiquetas tem o seu fecho correspondente. Se por exemplo abrir um

elemento (<etiqueta>), terei que o fechar também (</etiqueta>). Isto é necessário porque as

etiquetas servem para definir a formatação de uma porção do documento, e assim marcamos

onde começa e termina o texto com a formatação específica. Alguns elementos são chamados

vazios pois não marcam uma região de texto, apenas inserem algum elemento no documento.

Uma etiqueta é formada por comandos, atributos e valores. Os atributos modificam os

resultados padrões dos comandos e os valores caracterizam essa mudança. Temos o seguinte

exemplo, <HR color =”RED”>, onde HR é o comando que desenha uma linha, o comando

color é um atributo que especifica uma cor diferente da cor padrão (preto) e o RED é o valor

do atributo color, que é a linha que será desenhada. Cada comando tem seus atributos

possíveis e seus valores. Um exemplo, é o atributo size que pode ser usado com o comando

FONT, com o HR mas que não pode ser usado com o comando BODY. Isso quer dizer que

devemos saber exactamente quais os atributos e valores possíveis para cada comando.

Figura 2-1 Estrutura de um documento HTML

As etiquetas não são sensíveis ao tamanho (case sensitive), portanto tanto faz escrever

<HTML>, <Html>, <html> ou <HtMl>. As etiquetas básicas de HTML, cuja presença é

altamente recomendável nas páginas são o <html>, que define o início de um documento

7

Page 18: Relatorio Abracar@Escola

2.Fundamentos Teóricos

HTML e indica ao navegador que todo conteúdo posterior deve ser tratado como uma série de

códigos HTML, o <head>, que define o cabeçalho de um documento HTML, que traz

informações sobre o documento que está sendo aberto e o <body> que define o conteúdo

principal, o corpo do documento. Esta é a parte do documento HTML que é exibida no

navegador. No corpo podem-se definir propriedades comuns a toda a página, como cor de

fundo, margens, e outras formatações, como se pode verificar na Tabela 2-1 e na Tabela 2-2.

Tabela 2-1 Estrutura do cabeçalho num documento HTML

Cabeçalho

Comando Descrição <title> Define o título da página, que é exibido na barra de título dos browsers.

<style> Define formatação em CSS. <script> Define programação de certas funções em página com scripts, podendo

adicionar funções de JavaScript. <meta> Define propriedades da página, como codificação de caracteres descrição da

página, autor, etc. São meta informações sobre documento. Tais campos são muitos usados por motores de busca para obterem mais informações sobre o documento, afim de classificá-lo melhor. Por exemplo, pode-se adicionar o código <meta name="description" content="descrição da sua página" /> no documento HTML para indicar ao motor de busca que texto de descrição apresentar junto com a ligação para o documento.

<link> Define ligações da página com outros arquivos como feeds, CSS, scripts, etc.

As tags <input> podem ser de vários tipos, dependendo do que especificarmos no atributo.

‒ <input type=”text”> -É usado quando queremos um campo de texto;

‒ <input type=”password”> -É usado quando queremos um campo de password, o que

quer que escrevamos aparece apenas em “*”;

‒ <input type=”hidden”> -É usado quando queremos um campo de oculto, para enviar

alguma informação adicional.;

‒ <input type=”radio”> -É usado quando queremos que o utilizador escolha uma opção

entre as que lhes são mostradas;

‒ <input type=”checkbox”> -Através desta opção o utilizador está livre para escolher

várias alternativas entre as são mostradas;

‒ <input type=”submit”> -Este tipo de input é usado para submeter o formulário para ao

servidor.

8

Page 19: Relatorio Abracar@Escola

2.Fundamentos Teóricos

‒ <input type=”reset”> -Este tipo de input é usado para limpar todos os campos do

formulário.

Tabela 2-2 Estrutura do corpo num documento HTML

Corpo

Comando Descrição <h1>, <h2>,... <h6> Cabeçalhos e títulos no documento em diversos tamanhos.

<p>: Novo parágrafo. <br>: Quebra de linha.

<table>: Cria uma tabela (linhas são criadas com <TR> e novas células com <TD>. Já os cabeçalhos de coluna são criados com a etiqueta <TH>.)

<div>: Determina uma divisão na página a qual pode possuir variadas formatações.

<font>: Forma um texto (fonte, cor e tamanho) de um trecho do texto.

<b>, <i>, <u> e <s>: Negrito, itálico, sublinhado e riscado, respectivamente <img>: Imagem. <a>: Hiper-ligação para um outro local, seja uma página, um e-mail

ou outro serviço <textarea>: Caixa de texto (com mais de uma linha); estas caixas de texto

são muito usadas em blogs, elas podem ser auto seleccionáveis e conter outros códigos a serem distribuídos.

<acronym>: Acrónimo (sigla) <cite>: Citação <adress>: Endereço

2.1.2. ASP.NET

O ASP.NET é a plataforma da Microsoft para o desenvolvimento de aplicações Web, e é o

sucessor da tecnologia Active Server Pages (ASP). É um componente do IIS (Internet

Information Services) que permite através de uma linguagem de programação integrada na

framework .NET, criar páginas dinâmicas. Não é nem uma linguagem de programação como o

VBScript, PHP, nem um servidor Web como IIS ou o Apache.

O ASP.NET é baseado no framework .NET herdando todas as suas características, por isso,

como qualquer .NET, as aplicações para essa plataforma podem ser escritas em várias

linguagens, como o C# e o Visual Basic .NET.

9

Page 20: Relatorio Abracar@Escola

2.Fundamentos Teóricos

Embora se possa já desenvolver aplicações ASP.NET, utilizando somente o bloco de notas e o

compilador .NET, o ambiente mais comum das aplicações é o Visual Studio .NET, que já

possui algumas características que facilitaram o nosso trabalho em termos de programação,

através de componentes visuais para a criação de formulários para as páginas Web [4].

Uma aplicação Web desenvolvida com tecnologia ASP.NET pode reutilizar código de

qualquer outro projecto escrito para a plataforma .NET, mesmo que em uma linguagem

diferente. Uma página ASP.NET escrita em VB.NET pode chamar componentes escritos em

C# ou WebServices escritos em C++, por exemplo. Ao contrário da tecnologia ASP, as

aplicações ASP.NET são compiladas antes da execução, trazendo sensível ganho no

desempenho.

As aplicações Web ASP.NET necessitam da framework .NET e do servidor IIS, para executar,

pelos menos na plataforma Windows.

Figura 2-2 Visão global da framework .NET

A plataforma .Net é um conjunto de tecnologias que foi projectado para mudar o conceito de

desenvolvimento de aplicações para a Internet. A plataforma .NET contempla o

desenvolvimento de aplicações escaláveis e distribuídas, fornecendo novas possibilidades

para construir aplicações baseadas em Web Service, suportando a infra-estrutura da Internet,

incluindo HTTP e XML.

10

Page 21: Relatorio Abracar@Escola

2.Fundamentos Teóricos

A plataforma .NET basicamente inclui:

• .NET framework

• .NET Building Block Services

• Visual Studio .Net

• .Net Enterprises Services(2003 family)

A .NET framework é constituída por duas partes principais: a CLR - Common Language

Runtime e a .NET Framework class library. A primeira é a responsável pela independência de

linguagem de programação e a segunda disponibiliza os principais recursos de programação,

além de incluir os três principais componentes: ASP.NET, Windows Forms e o ADO.NET.

O coração da plataforma .NET é o CLR (Common Language Runtime), que é uma aplicação

similar a uma máquina virtual que se encarrega de providenciar a execução das aplicações

para ela escritas. São oferecidos a estas aplicações numerosos serviços que facilitam o seu

desenvolvimento e manutenção que favorece confiança e segurança.

O CLR é o verdadeiro responsável pela interoperabilidade entre as linguagens suportadas pela

plataforma .Net. O compilador de cada linguagem segue uma série de padrões (Common

Language Specification) para compilar seus códigos, por isso as outras linguagens conseguem

"entender" as classes e os métodos, dentre outras informações, que essa linguagem definiu.

Por exemplo, quando se escreve uma classe em SmallTalk.Net e se compila, o compilador de

SmallTalk não irá compilá-la da mesma forma que compilaria fora da plataforma, esse vai

compilar segundo uma série de especificações que o IL (Intermediate Language) vai gerar.

Quando essa classe tiver que ser acedida por uma outra, escrita em C#, por exemplo, a

plataforma .Net encarrega-se de ler a IL gerada e expor a classe que foi criada.

No desenvolvimento do software, uma framework é uma estrutura de suporte definida em que

um outro projecto de software pode ser organizado e desenvolvido. Uma framework pode

incluir programas de suporte, bibliotecas de código, linguagens de script e outros softwares

para ajudar a desenvolver e juntar diferentes componentes de um projecto de software.

Frameworks são projectados com a intenção de facilitar o desenvolvimento de software,

habilitando designers e programadores a gastarem mais tempo determinando nas exigências

do software do que com detalhes de baixo nível do sistema.

11

Page 22: Relatorio Abracar@Escola

2.Fundamentos Teóricos

Figura 2-3 Tecnologia Clinte Servidor ASP.Net

12

Page 23: Relatorio Abracar@Escola

2.Fundamentos Teóricos

Na Figura 2-3 podemos ver de como a tecnologia Cliente/Servidor ASP.NET funciona. Cria-

se um projecto no Visual Studio .NET, editando os ficheiros remotamente ou directamente do

nosso computador. Uma vez que a pasta da aplicação esteja no servidor, o código ASP.NET é

corrido unicamente no servidor, e aos browsers de quem está a visitar a aplicação só chegará

código HTML. Podemos ver ainda que durante este processo o servidor pode efectuar

transacções com o servidor da base de dados.

Aquando a criação de um novo projecto de uma aplicação Web, é necessário saber que

ficheiros essa aplicação vai ter, e qual a estrutura que esses ficheiros disponibilizam. Para tal é

importante saber com que tipos de ficheiros nos regemos aquando a criação de uma aplicação

Web no Visual Studio .NET. A Tabela 2-3 mostra os tipos de ficheiros existentes de uma

aplicação Web.

Tabela 2-3 - Ficheiros de uma Aplicação Web Tipo de Ficheiro Extensão

Ficheiro de Solução de Projecto .snl ou .suo Ficheiros de Projecto .vbproj ou .csproj

Ficheiros da Aplicação Web

Formulários - .aspx

Serviços Web- .asmx

Classes ou code-behind - .vb ou .cs

Classes Globais Aplicação - .asax

Ficheiro Configuração - Web.config Componentes do Projecto Ficheiros - .dll

Figura 2-4 Exemplo de código de um ficheiro .aspx vazio

13

Page 24: Relatorio Abracar@Escola

2.Fundamentos Teóricos

Na Figura 2-4 podemos ver um ficheiro de aplicação Web do tipo .aspx, que normalmente é

onde construímos os nossos formulários.

Todos estes ficheiros são guardados de uma forma estruturada, quer no servidor, quer no

disco rígido de um computador normal. De seguida, na Figura 2-5 mostramos a estrutura dos

ficheiros de uma aplicação Web num computador normal á esquerda, e num servidor à direita.

Figura 2-5 Estrutura de Pastas de uma aplicação Web

Existem três maneiras de implementarmos código no ASP.NET. Podemos simplesmente

misturar código HTML com Visual Basic (VB) no mesmo ficheiro .aspx, podemos

implementar no mesmo ficheiro, mas separar o código por secções, distinguindo o código

HTML do VB, e por fim e na nossa opinião, a melhor forma é termos um ficheiro separado

com as funções de VB, ficando com o mesmo nome do ficheiro .aspx, mas com uma extensão

diferente (.aspx.vb). Na Figura 2-6 podemos ter uma ideia de como funcionam as páginas com

Code-Behind.

Figura 2-6 Páginas Code-Behind

14

Page 25: Relatorio Abracar@Escola

2.Fundamentos Teóricos

De maneira a compreendermos como trabalham as páginas Code-Behind, precisamos de saber

que têm que se criar ficheiros separados para a interface e para a lógica de negócio. Podemos

fazer isto usando a directiva @Page para ligar os dados aos ficheiros.

Figura 2-7 Ligação de Código de Páginas Code-Behind

De seguida vamos explicar como configurar a segurança de acesso ao código de ASP.NET.

Por norma, as aplicações Web que funcionam com confiança total não têm qualquer restrição

de permissões. Para modificar os níveis de confiança da segurança de acesso ao código no

ASP.NET, é necessário estabelecer um parâmetro no Machine.config ou no Web.config e

configurar a aplicação como esta sendo parcialmente de confiança.

O elemento <trust> em Machine.config controla se a segurança de acesso ao código vai ser

activada ou não para uma aplicação Web. Deve-se abrir o ficheiro Machine.config, e procurar

por "<trust>", como está representado na Figura 2-8 Configurar a segurança de acesso ao

código ASP.NET

Figura 2-8 Configurar a segurança de acesso ao código ASP.NET

Com o nível de confiança definido como "Full", a segurança de acesso ao código é

efectivamente desactivada porque nenhuma exigência de permissões fica no caminho das

tentativas de acesso aos recursos. Esta é a única opção para as aplicações Web ASP.NET

criadas na .NET Framework versão 2.0. Descendo na lista de "Full" até "Minimal", cada nível

retira mais permissões, restringindo ainda mais a capacidade da nossa aplicação aceder a

recursos protegidos e realizar operações privilegiadas. Conforme o nível, maior será o

isolamento da aplicação.

15

Page 26: Relatorio Abracar@Escola

2.Fundamentos Teóricos

2.1.3. Linguagem SQL SERVER

Structured Query Language, ou Linguagem de Consulta Estruturada ou SQL, é uma

linguagem de pesquisa declarativa para bases de dados relacionais (base de dados relacional).

Muitas das características originais do SQL foram inspiradas na álgebra relacional.

O SQL foi desenvolvido originalmente no início dos anos 70 nos laboratórios da IBM em San

Jose, dentro do projecto System R, que tinha por objectivo demonstrar a viabilidade da

implementação do modelo relacional proposto por E. F. Codd. O nome original da linguagem

era SEQUEL, acrónimo para "Structured English Query Language" (Linguagem de Consulta

Estruturada em Inglês), vindo daí o facto de, até hoje, a sigla, em inglês, ser normalmente

pronunciada "síquel".

A linguagem SQL é um grande padrão de bases de dados. Isto deve-se à sua simplicidade e

facilidade de uso. O SQL diferencia-se das outras linguagens de consulta a bases de dados no

sentido em que uma consulta SQL especifica a forma do resultado e não o caminho para

chegar a ele. O SQL é uma linguagem declarativa, em oposição a outras linguagens

procedimentais. Isto reduz o ciclo de aprendizagem daqueles que se iniciam na linguagem.

Embora o SQL tenha sido originalmente criado pela IBM, rapidamente surgiram vários

"dialectos" desenvolvidos por outros produtores. Essa expansão levou à necessidade de ser

criado e adaptado um padrão para a linguagem. Esta tarefa foi realizada pela American

National Standards Institute (ANSI) em 1986 e ISO em 1987.

O SQL foi revisto em 1992 e a esta versão foi dada o nome de SQL-92. Foi revisto novamente

em 1999 e 2003 para se tornar SQL1999 (SQL3) e SQL2003, respectivamente. O SQL1999

usa expressões regulares de emparelhamento, queries recursivas e triggers. Também foi feita

uma adição controversa de tipos não-escaláveis e algumas características de Object Oriented.

O SQL 2003 introduz características relacionadas ao XML, sequências padronizadas e colunas

com valores de auto-generalização (inclusive colunas-identidade).

DML - Linguagem de Manipulação de Dados

16

Page 27: Relatorio Abracar@Escola

2.Fundamentos Teóricos

Primeiro há os elementos da DML (Data Manipulation Language - Linguagem de

Manipulação de Dados). A DML é um subconjunto da linguagem usada para seleccionar,

inserir, actualizar e apagar dados.

• SELECT é o normalmente mais usado do DML, comanda e permite ao utilizador

especificar uma query como uma descrição do resultado desejado. A questão não

especifica como os resultados deveriam ser localizados.

• INSERT é usada para somar uma fila (formalmente um tuplo) a uma tabela existente.

• UPDATE para mudar os valores de dados numa fila de tabela existente.

• DELETE permite remover filas existentes de uma tabela.

• BEGIN WORK (ou START TRANSACTION, dependendo do dialecto SQL) pode ser

usado para marcar o começo de uma transacção de bases de dados que pode ser

completada ou não.

• COMMIT envia todos os dados das mudanças permanentemente.

• ROLLBACK faz com que as mudanças nos dados existentes desde que o último

COMMIT ou ROLLBACK sejam descartadas.

COMMIT e ROLLBACK interagem com áreas de controlo como transacção e alocação.

Ambos terminam qualquer transacção aberta e liberam qualquer cadeado ligado a dados. Na

ausência de um BEGIN WORK ou uma declaração semelhante, a semântica de SQL é

dependente da implementação.

DDL - Linguagem de Definição de Dados

O segundo grupo é a DDL (Data Definition Language - Linguagem de Definição de Dados).

Uma DDL permite ao utilizador definir tabelas novas e elementos associados. A maioria das

bases de dados de SQL comerciais tem extensões proprietárias no DDL.

Os comandos básicos da DDL são:

• CREATE cria um objecto (uma Tabela, por exemplo) dentro da base de dados.

17

Page 28: Relatorio Abracar@Escola

2.Fundamentos Teóricos

• DROP apaga um objecto do banco de dados.

Alguns sistemas de bases de dados usam o comando ALTER, que permite ao utilizador alterar

um objecto, por exemplo, adicionando uma coluna a uma tabela existente.

Outros comandos DDL:

• ALTER TABLE

• CREATE INDEX

• ALTER INDEX

• DROP INDEX

• CREATE VIEW

• DROP VIEW

DCL - Linguagem de Controle de Dados

O terceiro grupo é o DCL (Data Control Language - Linguagem de Controle de Dados). DCL

controla os aspectos de autorização de dados e licenças de usuários para controlar quem tem

acesso para ver ou manipular dados dentro do banco de dados.

Duas palavras-chaves da DCL:

• GRANT - autoriza ao utilizador a executar ou configurar operações.

• REVOKE - remove ou restringe a capacidade de um utilizador executar operações.

Outros comandos DCL:

• ALTER PASSWORD

• CREATE SYNONYM

18

Page 29: Relatorio Abracar@Escola

2.Fundamentos Teóricos

2.1.4. Linguagem AJAX

AJAX (acrónimo em língua inglesa de Asynchronous Javascript And XML) é o uso sistemático

de tecnologias providas por browsers, como Javascript e XML, para tornar páginas mais

interactivas com o utilizador, utilizando-se de solicitações assíncronas de informações. AJAX

não é somente um novo modelo, é também uma iniciativa na construção de aplicações Web

mais dinâmicas e criativas. AJAX não é uma tecnologia, são realmente várias tecnologias

trabalhando juntas, cada uma fazendo a sua parte, oferecendo novas funcionalidades. O AJAX

incorpora no seu modelo.:

Apresentação baseada em padrões, usando XHTML e CSS;

Intercâmbio e manipulação de dados usando XML e XSLT;

Recuperação assíncrona de dados usando o objecto XMLHttpRequest, e JavaScript unindo

todas elas em conjunto.

O modelo clássico de aplicação Web trabalha assim: A maioria das acções do utilizador na

interface dispara uma solicitação HTTP para o servidor Web. O servidor processa algo,

recuperando dados, realizando cálculos, conversando com vários sistemas legacy , e então

retorna uma página HTML para o cliente. É um modelo adaptado do uso original da Web

como um agente de hiper texto, porém o que faz a Web boa para hipertexto, não

necessariamente a faz boa para aplicações de software.

Esta aproximação possui muito dos sentidos técnicos, mas não faz tudo que um utilizador

experiente poderia fazer. Enquanto o servidor está a fazer o seu trabalho, o que é que o

utilizador está a fazer? O que é certo, é que ele esteja a esperar. E a cada etapa numa tarefa, o

utilizador aguarda mais uma vez.

Obviamente, se nós estivéssemos a projectar a Web a partir do zero para aplicações, não

faríamos com que os utilizadores esperassem sem alcançar nada. Uma vez que a interface está

carregada, porque é que a interacção do utilizador deveria parar a cada vez que a aplicação

precisasse de algo do servidor? Na realidade, é porque o utilizador deveria ver a aplicação e

recorrer ao servidor várias vezes?

A maior vantagem das aplicações AJAX é que elas correm no próprio browser. Então, para

estar apto a executar aplicações AJAX, bastar possuir algum dos browsers modernos, ou seja,

19

Page 30: Relatorio Abracar@Escola

2.Fundamentos Teóricos

lançados após 2001. São eles: Mozilla Firefox, Internet Explorer 5+, Opera, Konquero e

Safari.

Figura 2-9 Modelo Clássico com e sem AJAX

2.1.5. Linguagem VB

Visual Basic.NET é uma linguagem de programação totalmente orientada a objectos e com

suporte total a UML, criada pela Microsoft e distribuída com o Visual Studio .NET (Versão

seguinte ao Visual Basic 6.0), embora hoje já haja o Visual Basic 2005.

O Visual Basic.NET é um produto extremamente diferente do antigo Visual Basic 6.0, não

podendo ser considerada uma versão seguinte. Não apenas a maneira de programar foi

alterada, mas todo conceito de orientação a objectos trouxe poder para a linguagem. A

Microsoft simplesmente descontinuou o antigo Visual Basic 6.0 tornando o produto parecido

com as demais linguagens do Visual Studio, parecido em questões de recursos e portabilidade

pois o Visual Basic.NET ainda é muito diferentes de linguagens como o Visual C++, C#, etc.

Porém esta nova versão aproximou o Visual Basic.NET das grandes linguagens de

programação, aumentando a aceitação dos programadores Java e até mesmo C++, embora

20

Page 31: Relatorio Abracar@Escola

2.Fundamentos Teóricos

programadores Java caso tenham que migrar para plataforma Microsoft preferem o C#.

Apesar da linguagem ser parecida com o antigo Visual Basic 6.0 a migração destes

programadores para a nova plataforma e utilização do Visual Basic.NET é mais fácil para

programadores que utilizam linguagens orientada a objecto por causa da grande diferença. Os

programadores do antigo Visual Basic 6.0 acostumados com a orientação a eventos encontram

dificuldades para utilizar o Visual Basic.NET.

2.2. Ferramentas Utilizadas

2.2.1. Visual Studio .NET

A ferramenta mais utilizada durante o projecto, foi sem dúvida o Visual Studio 2005 da

Microsoft. O Microsoft Visual Studio é um pacote de programas da Microsoft, para

desenvolvimento de software, especialmente dedicado, ao framework .NET e às linguagens

Visual Basic, C ,C++, C# e J#. Também é um grande produto de desenvolvimento na área

web, usando a plataforma do ASP.NET. As linguagens com maior frequência nessa plataforma

são: VB.NET e o C#.

O Microsoft Visual Studio .NET é uma ferramenta de desenvolvimento que surgiu no final de

2001. O seu surgimento revolucionou a maneira de se programar, principalmente para a Web

e dispositivos móveis, por ser uma ferramenta que facilitou o que antes era bastante complexo

de fazer. De seguida iremos mostrar como se cria um novo projecto para uma aplicação Web.

Figura 2-10 - Criação Projecto Visual Studio

21

Page 32: Relatorio Abracar@Escola

2.Fundamentos Teóricos

Figura 2-11 Aspecto visual do ambiente do Visual Studio. NET

Legenda:

1- Explorador de Servidores

2- Caixa de Ferramentas

3- Editor / Navegador

4- Explorador de Soluções

5- Propriedades

6- Navegador de Objectos

22

Page 33: Relatorio Abracar@Escola

2.Fundamentos Teóricos

2.2.2. Internet Information Service

O IIS (Internet Information Services) é um servidor web criado pela Microsoft para os

sistemas operativos deservidores. A primeira versão foi introduzida com o Windows NT

Server versão 4, e passou por várias actualizações.

Uma das suas características mais utilizadas é a gestão de páginas HTML dinâmicas, que

diferentemente de outros servidores web, usa tecnologia proprietária, o ASP (Active Server

Pages), mas também se podem usar outras tecnologias com adição de módulos de terceiros.

Depois do lançamento da plataforma .NET em 2002 o IIS ganhou também a função de fazer a

gestão do ASP.NET. Este é formado basicamente por dois tipos de aplicações:

• Páginas Web: Tradicionais acedidas por utilizadores, que contém a extensão ASPX

• Web Services: Funções disponibilizadas pela rede, chamada por aplicações de ASMX.

O ASP.NET, assim como o seu concorrente directo, o JSP é compilado antes da execução.

Esta característica traz vantagens sobre as opções interpretadas, como o ASP e o PHP.

2.2.3. Microsoft SQL Server

O SQL Server (versão 2000) é um SGBD - Sistema de Gestão de Bases de dados da Microsoft

(originalmente o projecto do SQL Server foi desenvolvimento pela Sybase) que pode ser

instalado no Windows NT/2000 e Win9x e que possui as seguintes características.

É fácil de usar (se comparado com outros SGBD). Oferece escalabilidade, ou seja, podemos

começar a desenvolver num computador pessoal, e de seguida migrar a nossa base de dados

para sistemas de multiprocessamento, embora com algumas dificuldades, respeitantes aos

scripts de código SQL gerado. Implementa o datawarehouse , através do Analysis Services. É

relativamente barato (comparado com outros SGBD).

Geralmente dizemos que o SQL Server é um SGBD cliente/Servidor pois comporta diferentes

tipos de plataformas e possui funcionalidades divididas entre clientes e servidores, onde o

cliente fornece uma ou mais interfaces que vão ser usadas para requerer uma solicitação ao

servidor (SGBD). Este por sua vez, processa a solicitação e devolve o resultado ao cliente.

23

Page 34: Relatorio Abracar@Escola

2.Fundamentos Teóricos

Figura 2-12 Criação de uma Base de dados no SQL Server

O SQL Server possui uma linguagem relacional chamada de Transact-SQL que é um dialecto

da linguagem SQL - Structured Query Language. A principal característica da linguagem SQL

é ter sido projectada para trabalhar com conjuntos de registros de dados, enquanto que as

linguagens tradicionais (C++, VB, Delphi,..) podem tratar apenas um registo de cada vez.

Além disto o SQL não precisa descrever em detalhe como realizar uma tarefa, este apenas

descreve o que o utilizador final deseja.

O SQL divide-se em dois subconjuntos de linguagem:

• A linguagem de Definição de Dados - DDL - que usa instruções para descrever o

esquema das tabelas da base de dados

• A linguagem de Manipulação de Dados - DML - que usa instruções para manipular os

dados.

2.2.4. Adobe Photoshop

O Adobe Photoshop é um software caracterizado como editor de imagens bidimensionais do

tipo raster (possuindo ainda algumas capacidades de edição típicas dos editores vectoriais)

desenvolvido pela Adobe Systems. É considerado o líder no mercado dos editores de imagem

profissionais, assim como o programa de facto para edição profissional de imagens digitais e

trabalhos de pré-impressão.

Apesar de ter sido concebido para edição de imagens para impressão em papel, o Photoshop

está a ser cada vez mais usado também para produzir imagens destinadas à World Wide Web.

As versões mais recentes incluem um segundo programa, o Adobe ImageReady, muito

24

Page 35: Relatorio Abracar@Escola

2.Fundamentos Teóricos

semelhante ao Photoshop, que em conjunto com o Photoshop, é utilizado para a edição e

criação de imagens e animações para a web.

Figura 2-13 - Exemplo de uma imagem aberta com o Photoshop

25

Page 36: Relatorio Abracar@Escola

3.Estudo da Usabilidade

3. Estudo da Usabilidade

3.1. Princípios de Design

3.1.1. Proximidade

Segundo o princípio da proximidade, itens relacionados entre si devem ser agrupados e

aproximados uns dos outros, para que sejam vistos como um conjunto coeso. Itens ou

conjuntos de informações que não estão relacionados entre si não deveriam estar próximos;

isso oferece ao leitor uma pista visual imediata da organização e do conteúdo da página.

O propósito básico da proximidade é o de organizar, tornando a leitura e a memorização mais

fácil. Como resultado da organização da comunicação, também se criam brancos (espaços

negativos) mais atraentes e mais organizados.

Quando vários itens estão próximos entre si, eles tornam-se uma unidade visual e não várias

unidades separadas.

Quando os elementos similares são agrupados numa unidade, a página fica mais organizada. É

possível saber por onde começar a leitura e onde terminá-la. Além disso, o espaço em branco

também fica mais organizado.

3.1.2. Alinhamento

Segundo o princípio do alinhamento, nada deve ser colocado arbitrariamente numa página.

Cada item deve ter uma conexão visual com algo na página. O propósito básico do

alinhamento é o de unificar e organizar a página. Normalmente, é um alinhamento marcante

que cria uma aparência sofisticada, formal.

O princípio do alinhamento obriga as pessoas a serem mais conscientes: já não se pode

simplesmente pôr as coisas na página nos lugares onde houver espaço. Quando os itens são

alinhados na página, há uma unidade coesa, mais forte. Mesmo quando os elementos

estiverem fisicamente separados uns dos outros, se estiverem alinhados, haverá uma linha

invisível que os liga, tanto em relação aos seus olhos quanto à sua mente.

26

Page 37: Relatorio Abracar@Escola

3.Estudo da Usabilidade

Devemos utilizar apenas um alinhamento de texto por página, ou seja, o texto deve ser todo

alinhado à esquerda, alinhado à direita ou centralizado. Às vezes, é possível utilizar os

alinhamentos à direita e à esquerda na mesma página, mas com uma certa regra.

Quando colocarmos outros itens na página, é importante que cada um deles tenha um

alinhamento visual com outro item da página.

3.1.3. Repetição

O princípio da repetição afirma que algum aspecto do design deve repetir-se no material

inteiro. O elemento repetitivo pode ser uma fonte em negrito, uma linha grossa, algum sinal

de tópico, um elemento do design, algum formato específico, etc. Pode ser qualquer item que

o leitor reconheça visualmente.

O propósito básico da repetição é unificar e acrescentar interesse visual. Não podemos

subestimar o interesse visual de uma página, pois se ela for interessante, a sua leitura será

mais agradável e provavelmente mais lida.

A repetição ajuda a organizar as informações. Ela ajuda a guiar o leitor pelas páginas e a

unificar partes distintas do design. Mesmo que o documento tenha apenas uma página, a

repetição dos elementos estabelece uma continuidade sofisticada. Se criarmos vários

documentos de uma única página que façam parte de um pacote unificado, é extremamente

importante usar a repetição.

3.1.4. Contraste

Segundo o princípio do contraste, se dois objectos não são exactamente do mesmo tipo, então

devem ser visualmente muito diferentes.

Em todas as artes, o contraste é uma poderosa ferramenta de expressão, o meio para

intensificar o significado e, portanto, para simplificar a comunicação.

O contraste é uma contra-força à tendência do equilíbrio absoluto. Ele desequilibra, sacode,

estimula e atrai a atenção.[5]

Os objectivos básicos do contraste são criar interesse sobre uma página e auxiliar na

organização das informações. O leitor deve ser capaz de compreender instantaneamente a

27

Page 38: Relatorio Abracar@Escola

3.Estudo da Usabilidade

maneira através da qual as informações são estruturadas, o fluxo lógico de um item para

outro. Os elementos contrastantes nunca devem confundir o leitor ou criar um foco que não

seja o correcto.

3.2. Perguntas de Heurística

3.2.1. Público-alvo

Este portal é dedicado à comunidade escolar, que abrange alunos, professores, encarregados

de educação, administrativos e funcionários. Serve várias escolas dentro do agrupamento em

questão, e poderá expandir-se a outras comunidades.

3.2.2. Objectivo do site

O objectivo deste portal e motivar a comunidade de ensino a utilizar diariamente um sistema

de gestão de conteúdos, através de um portal, promovendo assim a disseminação, partilha e

acesso à informação entre os vários actores do universo da escola, tais como, os alunos,

professores, encarregados de educação e sociedade em geral.

Pretende-se de certa maneira promover o trabalho colaborativo e a aplicação das novas

tecnologias de informação e comunicação, por toda a comunidade escolar. Este projecto

consiste numa solução on-line, alojada num servidor próprio. A construção deste espaço de

partilha e divulgação de informação está relacionada com a gestão do próprio agrupamento,

bem como o apoio ás actividades desenvolvidas no mesmo.

Os objectivos que deverão estar presentes são:

‒ Dinamizar a comunicação entre os diferentes intervenientes do processo educativo do

agrupamento;

‒ Compilação de conteúdos educativos genéricos;

‒ Informação institucional e promocional;

‒ Plataforma para gestão de conteúdos,

‒ Fomentar a partilha de conteúdos disciplinares;

28

Page 39: Relatorio Abracar@Escola

3.Estudo da Usabilidade

‒ Fomentar a transparência do processo educativo;

‒ Promover a educação para a sociedade do conhecimento;

‒ Promover a literacia digital dos agentes educativos;

‒ Desenvolver um espírito colaborativo entre as escolas do agrupamento;

‒ Aumentar a abertura da escola à comunidade em que se insere;

‒ Fomentar a aplicação das T.I.C. na prática pedagógica dos professores;

‒ Fomentar nos alunos a utilização pedagógica das T.I.C., designadamente a Internet,

como instrumento de aprendizagem;

‒ Promover aprendizagens no âmbito disciplinar independentemente do espaço físico da

escola;

‒ Fomentar o uso educativo do computador;

3.2.3. O que o Público-alvo espera do portal

Pensamos que o público-alvo espera encontrar um portal com funcionalidades que se

adeqúem ao quotidiano deles, quer para professores alunos, administrativos e funcionários.

De certa maneira pensamos que vão querer essencialmente participar activamente nos

conteúdos que o portal suporta, pois são as notícias e os eventos sobre que eles se regem no

dia a dia. Tem que haver também uma motivação acrescida porque várias faixas etárias

(alunos e professores) vão estar a usar este portal, por isso esperam que este portal seja algo

atractivo e que ao mesmo tempo seja capaz de responder a todos os intervenientes.

Falando agora das funcionalidades, na parte que toca às notícias, o público deve querer

percorrer todo o leque de notícias de maneira fácil, de uma maneira orientada em que o

utilizador não se perca à procura da zona que espera ver. Ainda na parte das notícias estas vão

estar desenvolvidas com categorias para que os utilizadores possam passar directamente para

a zona temática pretendida.

Na zona de eventos espera-se dinamismo, pois os professores necessitam das informações

atempadamente. De nada serve inserir um evento de uma reunião, se esse não puder ser visto

29

Page 40: Relatorio Abracar@Escola

3.Estudo da Usabilidade

a tempo de este se realizar, quer dizer que o objectivo falhou. Sendo assim tem que haver uma

certa facilidade em inserir eventos, bem como os divulgar. A questão dos SMS e os e-mails

veio acrescentar uma forte motivação, pois impedem aos utilizadores de estarem sempre

preocupados em ir à escola, ou telefonarem para saber quando há reuniões, permitindo desta

forma minimizar os custos feitos por professores/escolas.

O fórum, uma das funcionalidades mais utilizadas hoje em dia pelos utilizadores na Internet, é

mais um dos componentes que esperamos que vá agradar a comunidade de ensino do

agrupamento de escolas, pois aqui o nível de permissões é mais baixo e será aberto para

todos, havendo assim uma grande variedade de temas que poderão surgir.

A nível da administração pensamos que é essencial que qualquer administrador consiga

reconhecer as funcionalidades disponíveis para a gestão do portal. Espera-se que haja um

processo iterativo na criação de utilizadores, seguidos de cargos, seguidos de órgãos, órgãos

esses que irão facultar um certo número de notícias e eventos. Um administrador espera que a

página inicial se possa alterar, pois poderá haver links que de um ano para o outro que deixam

de fazer sentido, e como tal o administrador espera poder apagar esses links e personalizar a

seu gosto.

3.2.4. A atitude a imprimir ao portal

Com a disponibilização deste portal online, a atitude que este deverá imprimir é ser uma

aplicação Web super dinâmica onde notícias e eventos possam ser inseridos o mais

rapidamente possível.

3.2.5. A sensação a transmitir ao utilizador

A sensação que o site deve transmitir aos utilizadores é a de uma ferramenta necessária, para

se manter actualizado na comunidade onde está inserido. Ao entrar é como que se imaginasse

numa famosa página de notícias online, onde este sabe que vai encontrar algo relacionado

consigo. Este portal deve ir de encontro aos temas mais importantes para a comunidade de

ensino.

30

Page 41: Relatorio Abracar@Escola

3.Estudo da Usabilidade

3.2.6. As cores dominantes

No nosso portal usámos duas cores dominantes, os cinzentos contrastados no fundo branco do

browser e o vermelho cor de vinho, para dar maior ênfase às funcionalidades do utilizador.

Estas cores foram escolhidas entre o orientador da Escola Azeredo Perdigão e os alunos que

desenvolveram o projecto. Em todos os ícones simbolizando as funcionalidades do portal, a

cor vermelha está presente, para que haja uma homogeneidade do design do portal.

Os vários tons de cinzentos remetem para a separação de certos formulários, para que estes

sejam fáceis de distinguir do resto das opções. Para o texto utilizámos quatro cores. A cor

preta simboliza o texto no corpo da notícia. A cor azul remete-nos para links activos. A cor

laranja é usada para alterar a cor azul dos links para que se note uma certa interactividade. Por

fim temos textos, a uma cor cinza clara que denotam alguma informação relativa ao portal.

31

Page 42: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

4. Análise e Requisitos

No início deste capítulo é dada uma visão geral sobre o domínio do ensino no Agrupamento

de Escolas de Abraveses. De seguida são apresentados os requisitos gerais que o projecto

Abraçar@Escola deverá providenciar de forma a suportar os seus objectivos. Identificam-se

dois grupos principais de requisitos:

Os requisitos funcionais, que correspondem aos casos de utilização disponibilizados por um

sistema e representam concretamente as funcionalidades a apresentarem por esse mesmo

sistema.

Os requisitos não funcionais, que correspondem a necessidades comuns que o sistema deverá

satisfazer independentemente das suas funcionalidades.

São depois apresentados os actores envolvidos no sistema, os casos de uso a desenvolver no

âmbito deste trabalho, e por fim é apresentado o modelo de entidade relacionamento que foi

desenvolvido.

4.1. Requisitos Não Funcionais

Requisitos não funcionais têm a ver com aspectos gerais do sistema tais como: desempenho,

robustez, fiabilidade, distribuição, segurança, integração com a Internet, abertura, ou suporte

de standards. Foram identificados neste projecto, os seguintes requisitos não funcionais.

4.1.1. Usabilidade

Pelo facto de grande parte das pessoas que trabalham nas escolas, assim como os próprios

professores, não terem uma preparação significativa para trabalharem com aplicações

informáticas, o Abraçar@Escola terá de apresentar uma interface simples, consistente e fácil

de utilizar. (A possibilidade de envio de avisos de eventos e/ou alertas aos professores por

SMS é disto um exemplo.)

32

Page 43: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

4.1.2. Desempenho e escalabilidade

Tendo em conta o universo significativo de escolas e consequentemente do número de alunos,

professores e encarregados de educação envolvidos, o sistema deverá tratar eficientemente

pedidos em picos de carga da ordem das centenas de acessos ou transacções, nomeadamente

nas épocas de inscrições, matrículas, e avaliações, que é quando vai haver mais notícias e

eventos no portal Abraçar@Escola.

4.1.3. Independência do local e do tipo de acesso

O Abraçar@Escola deverá ser acedido a partir de qualquer cliente Web (e.g., Mozzila,

Microsoft Internet Explorer), independente do fabricante, e a partir de qualquer local

geográfico (e.g., na secretaria da escola, na casa do professor, na casa do aluno),

salvaguardando-se a existência de uma ligação à Internet.

4.1.4. Privacidade e confidencialidade

Apesar da informação gerida pelo sistema de ensino não ser particularmente crítica em termos

do seu conteúdo, o Abraçar@Escola deverá garantir que a privacidade e confidencialidade da

informação seja mantida nos seus respectivos níveis de acesso. Por exemplo, as chaves de

utilizador uma vez criadas, serão encriptadas na base de dados. No caso de um utilizador se

esquecer da chave, este terá que enviar um e-mail para o administrador e será enviado um e-

mail ou um SMS com os dados.

4.1.5. Abertura e integração com outros sistemas

De forma que o Abraçar@Escola possa ser usado e integrado com outros sistemas de

informação (existentes ou futuros) e participante em workflows e processos administrativos à

escala regional e nacional, é importante a definição e exposição de um conjunto essencial de

serviços do Abraçar@Escola de forma aberta, independente do fabricante e da tecnologia, e

acessível através de protocolos e tecnologias comuns da Internet.

33

Page 44: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

4.1.6. Avisos/Alertas segundo múltiplas formas

Conforme tenha sido previamente configurado por e para cada interveniente, o

Abraçar@Escola deverá suportar um mecanismo de avisos e de alertas segundo múltiplas

formas, nomeadamente, por: correio electrónico e SMS.

4.2. Requisitos Funcionais

Identificam-se de seguida e sumariamente os papéis ou funções e respectivas funcionalidades

providenciadas pelo sistema:

• Administrador: Corresponde aos utilizadores responsáveis pela operação e gestão do

Abraçar@Escola. São responsáveis designadamente pela:

▪ Gestão de órgãos, cargos e de utilizadores do Agrupamento de Escolas de

Abraveses;

▪ Gestão e divulgação de módulos aplicativos a disponibilizarem ao longo do

tempo;

▪ Gestão de temas existentes, através dum sistema de gestão de conteúdos, com

criação, alteração de menus e sub menus.

▪ Gestão do módulo das Notícias, em termos de criação, alteração e remoção.

Definição de formatos a inserir nas colunas de Notícias, bem como os ficheiros

que poderão ser inseridos em cada notícia.

▪ Gestão do módulo de Eventos. Para que a informação possa chegar a todos os intervenientes, o Administrador gere o modo como os eventos são mostrados, inseridos, alterados e apagados. Também nesta área os administradores podem enviar SMS ou e-mails para um determinado grupo de utilizadores.

▪ Gestão de Citações inseridas para aparecem aleatoriamente quando se entra no portal Abraçar@Escola.

▪ Gestão de Histórico de intervenções que consiste em registar todas as intervenções feitas pelos utilizadores com acesso à parte de administração, a nível de inserção, remoção de notícias, eventos, cargos e órgãos.

34

Page 45: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

• Utilizadores pertencentes ao Órgão de Notícias: Correspondente a alunos, professores

directores de turma, serviços de secretaria e outros órgãos que lhes sejam atribuídos

permissões para escrever noticias.

• Utilizadores presidentes de Órgãos: Estes utilizadores têm permissões para criar

eventos, alterar e apagar. Estes são responsáveis pela notificação dos eventos, podendo

utilizar as funcionalidades de envio de SMS e e-mails. Para que tal aconteça estes

presidentes, ao criarem um evento, se quiserem convocar utilizadores de um dado órgão,

que estejam associados a esse evento, terão que os seleccionar para estes poderem ser

notificados.

4.2.1. Actores principais

Após uma análise conjunta com o orientador da instituição, foram identificados os vários

actores participantes do sistema educativo do Agrupamento de Escolas de Abraveses. Os

mesmos estão representados na Figura 4-1. Na nossa opinião achamos que não se justifica que

o número de actores numa escola seja como o da escala representada em baixo, mas por uma

questão de igualdade decidimos mostrar todos os actores.

35

Page 46: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-1 Vários Actores intervenientes do projecto Abraçar@Escola

4.2.2. Casos de uso principais

De seguida são apresentados os casos de uso que pertencem aos módulos que foram

desenvolvidos no âmbito deste trabalho.

O primeiros módulos a serem desenvolvidos no nosso trabalho foram os de gestão de

utilizadores, cargos e órgãos. Estes módulos são importantes para perceber o funcionamento

de gestão de informação neste site, visto que estes são os principais componentes nesta

aplicação Web.

36

Page 47: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-2 Casos de Uso - Cargos e Utilizadores

Figura 4-3 Casos de Uso - Criação de Órgãos

O módulo das Notícias, vai ser o que mais interacção vai fazer com o sistema, visto que o

portal usa um tipo de gestão de conteúdos de informação que estará a ser alterada a todas

horas. Neste caso de uso apresentamos os actores principais que vão interagir com o pacote

das notícias, onde é possível desde inserir imagens, ficheiros e links para outras páginas. As

notícias vão estar organizadas por categorias e na página principal vão ser mostradas

conforme forem atribuídas a um certo menu e sub menu.

37

Page 48: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-4 Casos de uso - Gerir Noticias

Com este módulo dos Fóruns de Discussão pretende-se facilitar a comunicação entre os

diferentes utilizadores do sistema, e efectuar de uma forma fácil a partilha e disseminação de

informação entre os mesmos. Visto já existirem vários sistemas com módulos semelhantes a

este no mercado foi efectuada uma pesquisa na Internet na tentativa de se encontrarem

sistemas donde fosse possível retirar algumas ideias sobre a forma de como implementar este

módulo. Depois desta pesquisa decidiu-se basear parte do módulo no projecto

“Aspnetforums”, este é um projecto open-source que implementa uma aplicação para criar e

gerir fóruns de discussão, em particular foi utilizada a camada de apresentação do mesmo e

foram utilizados certos aspectos do modelo do domínio.

Figura 4-5 Casos de uso Fórum

38

Page 49: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-6 Casos de Uso - Eventos

4.3. Modelo Entidade Relacionamento

4.3.1. Diagrama ER

O diagrama de entidade relacionamento, foi o componente que mais tempo nos ocupou no

desenvolvimento deste projecto. Foram várias as intervenções que fizemos neste diagrama,

desde à alteração de campos que assim o justificavam, como a remoção e a inserção de

alguns. Consideramos que este componente é um dos pontos altos no nosso projecto pois não

contávamos com a complexidade de um sistema de ensino em Portugal, e para tal tivemos que

fazer uma grande análise, adiar pontos de verificação dos nossos planeamentos, para que este

mesmo diagrama pudesse ficar de acordo com os objectivos definidos inicialmente. De

seguida na Figura 4-7, vamos poder ver as tabelas e as respectivas ligações que compõem o

sistema de gestão do agrupamento de escolas de Abraveses.

39

Page 50: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-7 Modelo Entidade Relacionamento Abraçar@Escola

A tabela Pessoas, contem a informação relativa a todas as pessoas que têm acesso à área

reservada do portal. Podem ser alunos, encarregados de educação, professores e

administradores do sistema. Um professor, pode ter um ou mais cargos e pertencer a um ou

mais órgãos. Ao fazer parte de um órgão, poderá ser ou não presidente desse órgão e poderá

criar e editar novos eventos, ou apenas visualizar eventos existentes. Relativamente aos

eventos, é registado quem os cria e cada pessoa só pode editar ou remover os eventos

associados a ela própria. O mesmo acontece para as noticias, apenas membros do órgão

notícias podem criar notícias e só podem alterar ou remover as notícias associadas a elas

mesmas. As notícias estão entre ligadas com os menus do site, que são links para as notícias

que os utilizadores criam. A tabela histórico regista alguns pontos específicos de actividade e

regista também intervenções de um administrador perante a criação e remoção de utilizadores,

eventos e notícias.

40

Page 51: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

4.3.2. Tabela Pessoas

Para a tabela tbl_Pessoas, atribuímos como chave primária o campo Cod_Pessoa que será um

número único para cada pessoa que terá registo na base de dados do portal. Os outros campos

têm nomes bastante perceptíveis, à excepção de Nível_Pessoa. Este campo é responsável por

determinar a que nível de backoffice essa pessoa irá pertencer.

O campo Chave_Pessoa regista a chave que o utilizador inseriu encriptada através de uma

função. Os campos Telemovel_Pessoa e Email_Pessoa não são obrigatórios, mas são

essenciais para a notificação de eventos e ou recuperação de dados, por SMS ou e-mail

respectivamente.

A tabela tbl_Pessoas está ligada à tabela tbl_Pessoas_Cargos que por sua vez está ligada à

tabela tbl_Cargos.

Figura 4-8 Constituição de tbl_Pessoas

4.3.3. Relação Pessoas – Pessoas_Cargos – Cargos

A tabela tbl_Pessoas_Cargos é a tabela resultante da ligação N-N entre tbl_Pessoas e

tbl_Cargos, que contém como chaves estrangeiras as chaves primárias das duas tabelas. A

utilização desta tabela irá facilitar a programação a nível de SQL permitindo várias operações

tais como, inserir e eliminar uma pessoa de um determinado cargo, não permitindo alterações.

Para se alterar, deverá primeiro eliminar a atribuição e inserir um novo utilizador num cargo,

para que o relacionamento funcione devidamente. Através destas ligações podemos consultar

os cargos de uma determinada pessoa, pelo campo Nome_Pessoa, e também consultar as

pessoas de um determinado cargo pelo campo Nome_Cargo.

Na tabela tbl_Cargos, temos a chave primária Cod_Cargo que contém um número único para

cada Cargo, o atributo Nome_Cargo que guarda o nome do Cargo e o atributo Unico_Cargo.

41

Page 52: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Este último atributo tem como função reservar cargos em que só existe uma pessoa. São

cargos únicos, como por exemplo, um Coordenador de Departamento é um cargo

desempenhado apenas por uma pessoa do corpo docente. Podem ver um exemplo desta

relação na Figura 4-9.

Figura 4-9 Relação Pessoas – Pessoas_Cargos – Cargos

4.3.4. Relação Pessoas_Cargos – Pessoas_Orgaos - Orgaos

A tabela tbl_Pessoas_Orgaos não tem chave primária, apenas tem como chaves estrangeiras

as chaves estrangeiras da tabela tbl_Pessoas_Cargos, e a chave primária da tabela tbl_Orgaos.

A tabela tbl_Pessoas_Cargos, como já foi referido, contém informação dos cargos a que as

pessoas pertencem.

A tabela tbl_Orgaos contém como chave primária Cod_Orgao que representa um número

único para cada Órgão, o atributo Nome_Orgao que guarda o nome do Órgão e o atributo

Noticia_Orgao determina se é um órgão de noticias ou não, isto é, se pode criar e editar novas

notícias para serem apresentadas no portal Abraçar@Escola principal ou apenas visualizar

notícias. A tabela tbl_Pessoas_Orgaos contém, para além das chaves estrangeiras, o atributo

Presidente_Orgao que vai servir mais tarde para saber qual a pessoa que é Presidente de um

determinado órgão, podendo assim efectuar um maior número de operações.

A tabela tbl_Pessoas_Orgaos guarda a informação relativa a todos os órgãos que uma pessoa

tem e o respectivo cargo que possui nesse órgão. Nesta tabela tem de se verificar a integridade

dos dados visto que cada órgão tem de ter obrigatoriamente um presidente.

42

Page 53: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-10 Relação Pessoas_Cargos – Pessoas_Orgaos - Orgaos

4.3.5. Relação Pessoas_Orgaos – Eventos – Pessoas_Eventos

A tabela tbl_Pessoas_Orgaos contém informação sobre as pessoas e os cargos que

desempenham nesse orgão. A tabela tbl_Eventos contém Cod_Evento como chave primária,

tem como atributos, as chave estrangeiras da tabela tbl_Pessoas_Orgaos, e os atributos que

constituem um evento. Ao ser criado um evento, os dados relativos à descrição do evento são

armazenados na tabela tbl_Eventos e os dados relativos a quem inseriu o evento, de que orgão

e com que cargo, são armazenados na tabela tbl_Pessoas_Eventos. Esta ligação possibilita um

mais fácil acesso à informação e uma programação SQL mais simples. A tabela

tbl_Pessoas_Eventos contém como chaves estrangeiras os atributos Cod_Pessoa, Cod_Orgao,

Cod_Cargo e Cod_Evento.

Figura 4-11 Relação Pessoas_Orgaos – Eventos – Pessoas_Eventos

4.3.6. Relação Pessoas_Orgaos – Noticias

A ligação entre estas tabelas é bastante importante devido a termos definido que só

determinados órgãos, órgãos de notícias, podem criar, editar e remover notícias para

aparecerem na página principal do site. A nível de atributos, a tabela tbl_Noticias tem como

chave primária Cod_Notícia, as chaves estrangeiras da tabela tbl_Pessoas_Orgaos e os

atributos que constituem uma notícia. Ao tentar ser acedida a zona de publicação de notícias,

o sistema verifica se o utilizador pertence ou não a um órgão de notícias. Caso pertença,

43

Page 54: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

selecciona automaticamente esse órgão e um dos vários órgãos a que o utilizador pode

pertencer. Nessa altura o utilizador pode escolher outro cargo, se tiver mais que um cargo, e

publicar a notícia sob esse cargo em vez do cargo anterior.

Figura 4-12 Relação Pessoas_Orgaos – Noticias

4.3.7. Relação Menus – Submenus – Noticias

O funcionamento dos links do site vai ter a particularidade de serem totalmente dinâmicos,

tanto em nível de ordenação como a nível de conteúdo. A tabela tbl_Menus está ligada à

tabela tbl_Submenus para que possamos associar vários Submenus a um Menu específico. A

tabela tbl_Submenus permite ordenar um certo número de links, e por sua vez estes têm uma

ligação com a tabela tbl_Noticias. Ao escolher-se um SubMenu, é visualizada a notícia

através da chave estrangeira adquirida da tabela tbl_Noticias.

Nesta relação tivemos que ter especial atenção de como a fazer, porque ao apagarmos menus

e sub menus sabíamos à partida que estes podiam ter ligações a notícias, então mesmo que

tenhamos que apagar registos da tabela menus e sub menus não vamos ter problemas pois a

tbl_Noticias vai permanecer com os mesmos registos, e assim preservar a integridade dos

dados. Esta relação é fundamental existir para um sistema de gerenciamento de conteúdos, e

como no nosso portal a gestão de conteúdos é um ponto forte, dedicámos especial atenção a

este ponto. Na podemos Figura 4-13 podemos ver que as chaves Cod_Submenus e Cod_Menu

não aparecem na tbl_Noticias de propósito, para se poderem alterar menus e sub menus com

facilidade e rapidez.

44

Page 55: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-13 Relação Menus – Submenus – Noticias

4.3.8. Tabela Históricos

A tabela tbl_Historicos efectua registos de intervenções. Guarda o número do código da

pessoa interveniente e o dia em que essa intervenção ocorreu. Regista também informação

relativa sobre qual o tipo de intervenção que foi feita. Neste projecto apenas vai registar o

código de pessoa que foi criada ou editado ou removido e o mesmo relativamente a eventos e

notícias, à excepção de em vez de registar o código de pessoa, regista o código de evento e de

notícia, respectivamente. Esta tabela também regista os utilizadores que entram e saem do

sistema. Basicamente este módulo serve para que os administradores e administrativos do

agrupamento de escolas de Abraveses tenham informação das acções que estão a ser feitas no

portal ao longo do tempo, podendo em caso de haver algum problema, poderem ter uma

reposta explicativa para dar aos utilizadores.

Figura 4-14 Tabela Históricos

4.3.9. Tabela Citações

A tabela tbl_Citacoes é uma simples tabela com várias citações. As citações irão ser

visualizadas uma de cada vez, e aleatoriamente cada vez que se aceder ao portal. As citações

poderão ser apenas inseridas pelo Administrador. O conteúdo das citações ficará guardado no

campo Citação e será chamado para aparecer num sítio específico da Masterpage.

45

Page 56: Relatorio Abracar@Escola

4.Desenvolvimento e Disposição do Portal

Figura 4-15 Tabela Citações

No fim deste capítulo devemos retirar a importância de fazer uma boa análise de requisitos,

recorrendo a requisitos funcionais, não funcionais e por fim a uma modelação de dados.

O leitor deve ficar com uma ideia geral das componentes que compõem o nosso sistema,

relativamente a cada funcionalidade e os actores intervenientes no sistema. Espera-se que com

a explicação de cada tabela e as várias relações o leitor tenha interiorizado do que realmente a

nossa aplicação Web é regida.

De seguida passaremos para a apresentação gráfica da nossa aplicação, dando a conhecer ao

leitor os vários interfaces com que se pode deparar um utilizador com um determinado nível

de acesso.

46

Page 57: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

5. Desenvolvimento e Disposição do Portal

5.1. Interface Gráfica

A estrutura do nosso portal foi algo que esteve em discussão durante muito tempo. Sofreu bastantes alterações quer a nível de esquema de cores como de stylesheets. Então olhando para a Figura 5-1 que mostra a página inicial do nosso portal podemos ver que há

5.1.1. Página Principal do Portal

Figura 5-1 - Aspecto visual do Portal Abraçar@Escola

A ideia de design deste layout foi concebida por nós e pelo orientador da entidade acolhedora.

Decidimos que desta forma, seria mais apelativa aos utilizadores, e através do seu dinamismo

conseguimos quebrar a monotonia que existe em muitos outros sites. A escolha do

posicionamento dos botões e dos links foi escolhido de acordo com a maioria dos sites para

que o utilizador não se perca no site devido a termos saído dos padrões normais.

47

Page 58: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Tentámos ao máximo fazer da página inicial, uma página apelativa e com várias opções até

mesmo para utilizadores que não possam aceder à área reservada.

5.1.2. Página Notícias

Figura 5-2 Aspecto visual do módulo de Notícias

A página das notícias, tem várias componentes em AJAX o que dá um efeito bastante

apelativo cada vez que se escolhe uma notícia, captando assim a atenção do utilizador

visitante. De momento estas notícias não foram inseridas com imagens, mas quando forem dá

ainda um aspecto mais atractivo, como podemos ver na Figura 5-2.

Ao escolher mais informação sobre uma determinada notícia, pode visualizar-se a foto

relacionada com a notícia e ter acesso a algum ficheiro que possa ter sido anexado pelo autor

da notícia, pretendendo-se desta maneira uma fácil visualização dos conteúdos.

48

Page 59: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

5.1.3. Página Eventos

Figura 5-3 Aspecto visual do módulo de Eventos

A página dos eventos tem o mesmo propósito da página das notícias, mas nesta página apenas

se encontram assuntos relativos à escola. Mais precisamente eventos públicos, devido a

termos essa opção na parte administrativa do site.

A opção de aceder à área reservada está sempre disponível em qualquer das páginas,

facilitando assim o acesso a utilizadores registados.

49

Page 60: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

5.1.4. Página do Fórum

Figura 5-4 - Aspecto Visual do Fórum Abraçar@Escola

O fórum em ASP.NET, é um fórum que contém um template que permite ser alterado a nível

de estética. Foi-nos pedido para adicionarmos o logótipo do projecto num dos cantos

superiores, e mudar a cor predominante do fórum.

50

Page 61: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

5.2. Painel Administrativo

Figura 5-5 Aspecto Visual do Painel Administrativo Abraçar@Escola

Dependendo do nível da pessoa que efectuar login, esta irá ter um backoffice de acordo com

as permissões atribuídas, com maior ou menor número de opções. Apenas os administradores

têm acesso total.

5.2.1. Funcionalidades do Painel Administrativo

Figura 5-6 Ícones situados no topo do Painel de Administração, correspondentes ás funcionalidades

1- Zona de Utilizadores

2- Zona de Cargos

3- Zona de Órgãos

4- Zona de Notícias

5- Zona de Eventos

6- Zona de Citações

7- Zona de Menus

8- Zona de Histórico

51

Page 62: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

5.2.2. Zona de gestão utilizadores

Figura 5-7 Tabela de Utilzadores com acesso

Figura 5-8 - Opções e Datalist de Utilizadores

Nesta zona de administração de utilizadores podemos, pesquisar utilizadores, visualizar todos

os utilizadores, criar um novo utilizador, associar cargos a utilizadores e enviar dados da

conta por e-mail ou SMS para utilizadores. Ao criar-se um novo utilizador, é necessário

preencher o seguinte formulário:

Figura 5-9 Formulário para criação de um utilizador

52

Page 63: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

O administrador deve preencher todos os campos sendo apenas o campo ‘Nome’ obrigatório.

Telemóvel e e-mail serão necessários para receber os dados para poder aceder à área

reservada. Também é essencial que exista uma Chave, mesmo que a chave seja deixada em

branco, o utilizador não pode entrar na área reservada. Esse é o método adoptado para banir

utilizadores se necessário.

O Nível do utilizador representa a sua permissão de acesso aos níveis do backoffice.

Atribuição de cargos por utilizador:

Figura 5-10 Atribuição de Cargos a um certo número de utilizadores

Do lado esquerdo aparecem os cargos a que o utilizador não pertence e do lado direito

aparecem os cargos a que o utilizador já pertence. Para adicionar ou remover o utilizador de

um dos cargos, é só escolher o cargo desejado e carregar na seta que corresponde à direcção,

inserir >, remover <.

53

Page 64: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Envio de dados para utilizadores:

Figura 5-11 Envio de dados por SMS e Correio electrónico aos utilizadores

Do lado esquerdo encontram-se todos os utilizadores disponíveis que podem ser adicionados à

lista do lado direito. Ao estarem na lista do lado direito, significa que ao se carregar num dos

dois botões em baixo, e-mail ou SMS, o(s) utilizador(es) recebe(m) a informação relativa à

sua conta.

5.2.3. Zona de gestão de Cargos

Figura 5-12 Tabela de Cargos

54

Page 65: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Figura 5-13 Opções e Datalist de Cargos

Nesta zona de administração de cargos podemos, pesquisar cargos, visualizar todos os cargos,

criar um novo cargo e associar utilizadores a cargos, como mostra a Figura 5-14.

Ao criar-se um novo cargo, é necessário preencher o seguinte formulário:

Figura 5-14 Preenchimento de um novo cargo

Se for um cargo único é necessário activar a checkbox, não permitindo assim mais do que um

utilizador nesse cargo.

5.2.4. Zona de Gestão de Órgãos

Figura 5-15 Tabela Órgãos

55

Page 66: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Figura 5-16 Opções e Datalist de Órgãos

Nesta zona de administração de órgãos podemos, pesquisar órgãos, visualizar todos os órgãos,

criar um novo órgão e associar utilizadores por órgãos como mostra a Figura 5-16

Ao criar-se um novo órgão, é necessário preencher o seguinte formulário:

Figura 5-17 Criação de um Órgão

É durante a fase de inserção de um novo órgão que decidimos se esse órgão irá ser órgão de

notícias ou não. Ser órgão de notícias implica que todos os membros desse órgão possam criar

notícias e serem publicadas na página inicial do site, como se pode ver na Figura 5-17

56

Page 67: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Atribuição de Utilizadores a Órgãos:

Figura 5-18 Atribuição de Utilizadores a Órgãos

É escolhido o órgão a que se pretende adicionar utilizadores como podemos ver na Figura

5-18, como neste caso apenas estão três utilizadores registados e inscritos no órgão, na lista de

utilizadores disponíveis para adicionar não se encontra disponível nenhum utilizador.

Apenas durante a inserção de membros num órgão é que se pode escolher quem vai ser o

presidente do órgão, como podemos ver na Figura 5-19.

Figura 5-19 Atribuições de Utilizadores a um Orgão

57

Page 68: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

5.2.5. Zona de gestão de notícias

Figura 5-20 Tabela de Notícias

Figura 5-21 Opções e Datalist das Notícias

Nesta zona de administração de notícias podemos, pesquisar notícias, visualizar todas as

notícias e criar uma nova notícia tal como podemos verificar na Figura 5-20 e Figura 5-21.

58

Page 69: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Ao criar-se uma nova notícia, é necessário preencher o seguinte formulário:

Figura 5-22 Preenchimento do formulário Notícias

No preenchimento deste formulário é necessário ter em consideração que uma pessoa pode ter

vários cargos num órgão e pode também pertencer a mais que um órgão. A notícia deve ser

publicada de acordo com o interesse do órgão/cargo. No formulário de inserção de notícias

temos três DropdownLists para inserirmos o órgão, o cargo e o utilizador. É possível anexar

um link para uma página, uma imagem, e um ficheiro, como mostra a Figura 5-22.

5.2.6. Zona de gestão de eventos

Figura 5-23 Tabela de Eventos

59

Page 70: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Figura 5-24 Opções de Datalist de Eventos

Nesta zona de administração de eventos podemos, pesquisar eventos, visualizar todos os

eventos, criar um novo evento e associar utilizadores aos eventos como podemos ver na

Figura 5-23 e na Figura 5-24.

Ao criar-se um novo evento, é necessário preencher o seguinte formulário:

Figura 5-25 Preenchimento do Formulário Eventos

Ao criar-se o evento, apenas é necessário escolher-se o nome do órgão. A verificação de

presidente é efectuada automaticamente. Todos os campos deste formulário são de

preenchimento obrigatório. Se optarmos por inserir um evento não público, esse evento não

será visualizado na página principal do site, conforme mostra a Figura 5-25.

60

Page 71: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Na Figura 5-26 podemos ver a Atribuição de Utilizadores a Eventos:

Figura 5-26 Atribuição de utilizadores a eventos e possibilidade de enviar notificações

Esta opção tem como finalidade efectuar convocatórias para reuniões e outros eventos de

elevada importância. Somente o presidente de um órgão pode criar e convocar utilizadores via

e-mail ou SMS.

61

Page 72: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

5.2.7. Zona de Gestão de Citações

Figura 5-27 Opções da tabela Citações

Nesta zona de administração de citações podemos, pesquisar citações, visualizar todas as

citações e criar uma nova citação como podemos ver na Figura 5-27

Ao criar-se uma nova citação, é necessário preencher o seguinte formulário:

Figura 5-28 Preenchimento de Citações

As citações aparecem aleatoriamente no topo da página principal do site, após a inserção de

várias citações como se pode ver na Figura 5-28.

5.2.8. Zona de gestão de menus e sub menus

Figura 5-29 - Opções de Menus e Sub Menus

62

Page 73: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Nesta zona de administração de menus podemos, ver todos os menus, criar um novo menu,

ordenar menus, ver todos os sub menus, criar um novo sub menu e ordenar os sub menus. Ao

criar-se um menu, esse menu irá fazer parte da página principal na zona de estruturação dos

links, tal como mostra a Figura 5-29.

Figura 5-30 Criação de um novo menu

Ao criar-se um sub menu, esse sub menu irá também fazer parte da página principal e será um link para uma notícia já existente, tal como se pode ver na Figura 5-30.

Figura 5-31 Criação de um Sub menu

5.2.9. Zona de gestão de Históricos

Figura 5-32 Tabela de Históricos

63

Page 74: Relatorio Abracar@Escola

5.Desenvolvimento e Disposição do Portal

Figura 5-33 Opções de Históricos

Nesta zona de administração de históricos podemos ver todos os utilizadores que entraram e

saíram da área reservada.

Também é possível ter um controlo de qual administrador insere, altera e ou remove dados de

um determinado utilizador, como podemos ver na Figura 5-34.

Figura 5-34 Histórico de utilizadores

Figura 5-35 Histórico de Notícias

O histórico das notícias e dos eventos funcionam da mesma forma. O código do administrador

que efectuou uma intervenção (inserção, alteração ou remoção) será registado, assim como o

nome da intervenção e o código da notícia ou evento representados na Figura 5-35 e na Figura

5-36.

Figura 5-36 Histórico de Eventos

64

Page 75: Relatorio Abracar@Escola

6.Conclusões

6. Conclusões

6.1. Validação dos Objectivos Originais

Com este trabalho pretendeu-se atingir um objectivo, dotar o projecto Abraçar@Escola das

funcionalidades necessárias para que os utilizadores finais o pudessem utilizar como um

sistema de gestão de conteúdos dinamicamente alterável.

Os Fóruns de Discussão adicionam ao sistema um mecanismo que torna a comunicação entre

os diferentes intervenientes do sistema mais simples. Possibilitando por parte dos docentes a

partilha de documentos e informações importantes com os alunos e com outros docentes.

6.2. Principais Contribuições

Este trabalho possibilitou que fosse possível adquirir uma grande flexibilidade na adaptação a

novas tecnologias e novas metodologias de trabalho, além disto teve de existir toda uma

adaptação à infra-estrutura que já se encontrava desenvolvida, penso que este factor é

importante para a nossa formação pois fora do meio académico é muito mais provável ter de

se trabalhar com sistemas já existentes em vez de se construírem sistemas de raiz.

6.3. Trabalho Futuro

Visto o sistema já ter grande parte das principais funcionalidades desenvolvidas, outro aspecto

que poderá ser interessante explorar no âmbito do Abraçar@Escola é fundir o nosso trabalho

com outros sistemas escolares já existentes, obtendo um feedback maior por parte dos reais

utilizadores, e verificar se o sistema está alinhado de acordo com as necessidades dos seus

utilizadores. Gostaríamos de continuar a desenvolver mais módulos e serviços que pudessem

contribuir para a gestão do ensino escolar, nomeadamente de questões de avaliação, criação

de pautas, faltas de alunos e professores, entre outros.

65

Page 76: Relatorio Abracar@Escola

6.Conclusões

6.4. Conclusão

No início deste trabalho ocorreram algumas dificuldades em particular na adaptação a uma

infra-estrutura que já se encontrava desenvolvida. Mas com o decorrer do tempo as vantagens

da utilização foram-se tornando óbvias. Após a conclusão deste trabalho o projecto

Abraçar@Escola ficou a funcionar com um conjunto de funcionalidades que suportam uma

boa parte das operações efectuadas por diversos intervenientes na gestão de uma escola.

Em conclusão, pode-se dizer que este trabalho é a realização de mais uma importante etapa de

um projecto ambicioso e de sucesso.

66

Page 77: Relatorio Abracar@Escola

Referências

Referências

[1] Carneiro, R. (Director e Coordenador do Estudo), O Futuro da Educação em Portugal:

Tendências e Oportunidades, Um estudo de reflexão prospectiva, Departamento de

Avaliação Prospectiva e Planeamento do Ministério da Educação, 2001.

[2] Harasim, L. et al. Learning Networks. The MIT Press, 1995.

[3] Hobsbawn, E. On the Edge of the New Century. The New Press, 2000.

[4] Centro de documentação Wikipédia - http://pt.wikipedia.org/wiki/

67

Page 78: Relatorio Abracar@Escola

Bibliografia

Bibliografia

The Non-Designer’s Design Book, Robin Williams, 1994, Peachpit Press.

EVJEN, Bill, HANSELMAN, Scott et al. Professional ASP.NET 2.0, Wiley Publishing, 2006

68

Page 79: Relatorio Abracar@Escola

7.Anexo A

7. Anexo A – Application Code

As imagens seguintes representam vários ficheiros em código VB, aos quais foi necessária a

criação de várias classes para que o código pudesse ser reutilizado, evitando assim várias

duplicações de código ao longo da realização do projecto.

Figura 7-1 Ficheiro clsCalendario.vb

Este ficheiro tem como objectivo traduzir os meses do calendário de número para texto. Como

se pode observar, por exemplo, quando o valor do mês for 8 a função traduz o 8 para Agosto,

obtendo como resultado ‘dia’ de Agosto de ‘ano’. Somente ‘dia’ e ‘ano’ serão representados

numericamente.

69

Page 80: Relatorio Abracar@Escola

7.Anexo A

Figura 7-2 Ficheiro clsCargos.vb – parte 1/3

Nesta primeira parte do ficheiro relativo ao controlo de dados dos cargos. Esta função serve

de apoio à parte da administração para a criação de novos cargos e verificação da sua

existência.

Figura 7-3 Ficheiro clsCargos.vb – parte 2/3

70

Page 81: Relatorio Abracar@Escola

7.Anexo A

Esta função serve para determinar o número de pessoas que existem num cargo, ajudando no

controlo de cargos únicos em que apenas pode existir um utilizador com esse cargo.

Figura 7-4 Ficheiro clsCargos.vb – parte 3/3

Esta função e a anterior complementam-se para efectuar a verificação de cargos únicos.

Figura 7-5 Ficheiro clsCitacoes.vb

A função das citações mostra uma citação aleatória cada vez que se abre o site ou ocorre um

postback.

71

Page 82: Relatorio Abracar@Escola

7.Anexo A

Figura 7-6 Ficheiro clsEmail.vb

Como o próprio nome indica, este ficheiro é relativo ao envio de e-mails. A configuração e

codificação das mensagens que vão ser enviadas encontra-se neste ficheiro.

72

Page 83: Relatorio Abracar@Escola

7.Anexo A

Figura 7-7 Ficheiro clsEncriptar.vb- parte 1/2

Neste ficheiro encontra-se a função que encripta as passwords dos utilizadores. Após a

password ter sido encriptada, é gravada para a base de dados. A encriptação usa uma chave

própria definida por nós que se encontra no ficheiro web.config.

73

Page 84: Relatorio Abracar@Escola

7.Anexo A

Figura 7-8 Ficheiro clsEncriptar.vb- parte 2/2

No resto do ficheiro encontra-se também a função de desencriptar passwords. Funciona do

modo inverso da função encriptar e vai buscar a mesma chave ao ficheiro web.config, caso

contrário a desencriptação não funciona.

74

Page 85: Relatorio Abracar@Escola

7.Anexo A

Figura 7-9 Ficheiro clsEventos.vb – parte 1/8

No ficheiro relativo aos eventos, nesta primeira parte, encontramos a função que através do

código do órgão nos devolve o nome do presidente desse órgão.

75

Page 86: Relatorio Abracar@Escola

7.Anexo A

Figura 7-10 Ficheiro clsEventos.vb – parte 2/8

Esta função tem um funcionamento semelhante à anterior, mas devolve o código da pessoa

que é presidente desse órgão.

Figura 7-11 Ficheiro clsEventos.vb – parte 3/8

76

Page 87: Relatorio Abracar@Escola

7.Anexo A

Esta função recebe como parâmetro o código do órgão e devolve o código do cargo do qual a

pessoa é presidente desse órgão.

Figura 7-12 Ficheiro clsEventos.vb – parte 4/8

Esta função mostra o primeiro registo do cargo de uma determinada pessoa pertencente a um

determinado órgão.

77

Page 88: Relatorio Abracar@Escola

7.Anexo A

Figura 7-13 Ficheiro clsEventos.vb – parte 5/8

Esta função recebe como parâmetro o código de um determinado evento, regista o nome da

pessoa que vai receber o e-mail, o nome do órgão a que pertence, o titulo, local, data de inicio

e descrição do evento que vão ser enviados no e-mail.

78

Page 89: Relatorio Abracar@Escola

7.Anexo A

Figura 7-14 Ficheiro clsEventos.vb – parte 6/8

Esta imagem é a continuação da função anterior que mostra a disposição de como os dados

vão ser enviados por e-mail.

79

Page 90: Relatorio Abracar@Escola

7.Anexo A

Figura 7-15 Ficheiro clsEventos.vb – parte 7/8

Esta função é semelhante à função de enviar e-mails, mas regista o nome da pessoa que vai

receber a SMS e envia somente a informação relativa a titulo, local, dia e hora do evento.

80

Page 91: Relatorio Abracar@Escola

7.Anexo A

Figura 7-16 Ficheiro clsEventos.vb – parte 8/8

Esta função mostra a informação relativa ao último evento inserido.

Figura 7-17 Ficheiro clsHistorico.vb – parte 1/13

No ficheiro relativo ao histórico, a partir desta função é possível registar quem acedeu à área

reservada e a data de entrada é registada automaticamente tendo em conta a hora do servidor.

81

Page 92: Relatorio Abracar@Escola

7.Anexo A

Figura 7-18 Ficheiro clsHistorico.vb – parte 2/13

Esta função é semelhante à anterior, mas regista quando um utilizador sai do sistema e a data

de saída.

82

Page 93: Relatorio Abracar@Escola

7.Anexo A

Figura 7-19 Ficheiro clsHistorico.vb – parte 3/13

Função que regista na tabela tbl_Historico que um determinado utilizador, inseriu na base de

dados outro utilizador.

Figura 7-20 Ficheiro clsHistorico.vb – parte 4/13

83

Page 94: Relatorio Abracar@Escola

7.Anexo A

Função que regista na tabela tbl_Historico que um determinado utilizador, alterou na base de

dados outro utilizador.

Figura 7-21 Ficheiro clsHistorico.vb – parte 5/13

Função que regista na tabela tbl_Historico que um determinado utilizador, eliminou da base

de dados outro utilizador.

84

Page 95: Relatorio Abracar@Escola

7.Anexo A

Figura 7-22 Ficheiro clsHistorico.vb – parte 6/13

Função que regista na tabela tbl_Historico que um determinado utilizador, inseriu na base de

dados uma notícia.

Figura 7-23 Ficheiro clsHistorico.vb – parte 7/13

85

Page 96: Relatorio Abracar@Escola

7.Anexo A

Função que regista na tabela tbl_Historico que um determinado utilizador, alterou na base de

dados uma notícia.

Figura 7-24 Ficheiro clsHistorico.vb – parte 8/13

Função que regista na tabela tbl_Historico que um determinado utilizador, eliminou da base

de dados uma notícia.

86

Page 97: Relatorio Abracar@Escola

7.Anexo A

Figura 7-25 Ficheiro clsHistorico.vb – parte 9/13

Função que regista na tabela tbl_Historico que um determinado utilizador, inseriu na base de

dados um evento.

Figura 7-26 Ficheiro clsHistorico.vb – parte 10/13

87

Page 98: Relatorio Abracar@Escola

7.Anexo A

Função que regista na tabela tbl_Historico que um determinado utilizador, alterou na base de

dados um evento.

Figura 7-27 Ficheiro clsHistorico.vb – parte 11/13

Função que regista na tabela tbl_Historico que um determinado utilizador, eliminou da base

de dados um evento.

88

Page 99: Relatorio Abracar@Escola

7.Anexo A

Figura 7-28 Ficheiro clsHistorico.vb – parte 12/13

Função que devolve o número de intervenções registadas.

Figura 7-29 Ficheiro clsHistorico.vb – parte 13/13

Função que elimina da tabela os registos relativos a uma determinada palavra que entra por

parâmetro.

89

Page 100: Relatorio Abracar@Escola

7.Anexo A

Figura 7-30 Ficheiro clsPessoas.vb – parte 1/8

No ficheiro relativo ao histórico, nesta primeira parte, criamos uma função que recebe como

parâmetro o código da pessoa e devolve o nome da mesma.

Figura 7-31Ficheiro clsPessoas.vb – parte 2/8

90

Page 101: Relatorio Abracar@Escola

7.Anexo A

Esta função recebe como parâmetro o código da pessoa e devolve o nome de utilizador da

mesma.

Figura 7-32 Ficheiro clsPessoas.vb – parte 3/8

Esta função serve de apoio à parte da administração para a criação de novos utilizadores e

verificação da sua existência.

91

Page 102: Relatorio Abracar@Escola

7.Anexo A

Figura 7-33 Ficheiro clsPessoas.vb – parte 4/8

Esta função recebe por parâmetro o código de uma pessoa e devolve o nível de permissão que

essa pessoa tem.

Figura 7-34 Ficheiro clsPessoas.vb – parte 5/8

Esta função recebe por parâmetro o código de uma pessoa e devolve a chave dessa pessoa

desencriptando-a após a ter lido da base de dados.

92

Page 103: Relatorio Abracar@Escola

7.Anexo A

Figura 7-35 Ficheiro clsPessoas.vb – parte 6/8

Esta função recebe por parâmetro o código de pessoa e devolve o e-mail correspondente a

essa pessoa.

Figura 7-36 Ficheiro clsPessoas.vb – parte 7/8

Esta função recebe por parâmetro o código de pessoa e devolve o telemóvel correspondente a

essa pessoa.

93

Page 104: Relatorio Abracar@Escola

7.Anexo A

Figura 7-37 Ficheiro clsPessoas.vb – parte 8/8

Esta função devolve os dados relativos à última pessoa que foi inserida na base de dados.

94

Page 105: Relatorio Abracar@Escola

7.Anexo A

Figura 7-38 Ficheiro clsSms.vb

Este ficheiro é responsável pelo envio de SMS para notificações aos utilizadores. Os dados de

configuração encontram-se neste ficheiro, incluindo a password de acesso que foi rasurada

por motivos de segurança.

95

Page 106: Relatorio Abracar@Escola

7.Anexo A

Figura 7-39 Ficheiro clsMenus.vb– parte 1/2

No ficheiro dos menus, a função devolve a posição relativa dos menus existentes.

96

Page 107: Relatorio Abracar@Escola

7.Anexo A

Figura 7-40 Ficheiro clsMenus.vb– parte 2/2

No ficheiro dos menus, a função devolve a posição relativa dos sub-menus existentes.

97

Page 108: Relatorio Abracar@Escola

7.Anexo A

Figura 7-41 Ficheiro clsNoticias.vb– parte 1/5

No ficheiro das notícias, temos várias funções responsáveis pelos carregamentos tanto de

ficheiros como fotos. Nesta função encontra-se o método para se carregar uma foto para o

servidor. Somente fotos com a extensão jpg ou gif podem ser carregadas para o servidor.

98

Page 109: Relatorio Abracar@Escola

7.Anexo A

Figura 7-42 Ficheiro clsNoticias.vb– parte 2/5

Nesta função encontra-se o método para se carregar um ficheiro para o servidor. Somente

ficheiros com a extensão doc ou pdf podem ser carregados para o servidor.

99

Page 110: Relatorio Abracar@Escola

7.Anexo A

Figura 7-43 Ficheiro clsNoticias.vb– parte 3/5

Esta função é semelhante à de inserir uma foto no servidor, mas neste caso em modo de

edição de notícia.

100

Page 111: Relatorio Abracar@Escola

7.Anexo A

Figura 7-44 Ficheiro clsNoticias.vb– parte 4/5

Esta função é semelhante à de inserir um ficheiro no servidor, mas neste caso em modo de

edição de notícia.

101

Page 112: Relatorio Abracar@Escola

7.Anexo A

Figura 7-45 Ficheiro clsNoticias.vb– parte 5/5

Esta função devolve a informação relativa à última notícia que foi adicionada.

102

Page 113: Relatorio Abracar@Escola

8.Anexo B

8. Anexo B – Scripts da Base de Dados SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Cargos]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Cargos]( [Cod_Cargo] [int] IDENTITY(1,1) NOT NULL, [Nome_Cargo] [nvarchar](100) NULL, [Unico_Cargo] [bit] NULL, CONSTRAINT [PK_tbl_Cargos] PRIMARY KEY CLUSTERED ( [Cod_Cargo] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Orgaos]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Orgaos]( [Cod_Orgao] [int] IDENTITY(1,1) NOT NULL, [Nome_Orgao] [nvarchar](100) NULL, [Noticia_Orgao] [bit] NULL, CONSTRAINT [PK_tbl_Orgaos] PRIMARY KEY CLUSTERED ( [Cod_Orgao] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Menus]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Menus]( [Cod_Menu] [int] IDENTITY(1,1) NOT NULL, [Nome_Menu] [nvarchar](50) NULL, [Ordem_Menu] [int] NULL, CONSTRAINT [PK_tbl_Menus] PRIMARY KEY CLUSTERED ( [Cod_Menu] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON

103

Page 114: Relatorio Abracar@Escola

8.Anexo B

use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Citacoes]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Citacoes]( [Cod_Citacao] [int] IDENTITY(1,1) NOT NULL, [Citacao] [nvarchar](300) NULL, CONSTRAINT [PK_tbl_Citacoes] PRIMARY KEY CLUSTERED ( [Cod_Citacao] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Pessoas]( [Cod_Pessoa] [int] IDENTITY(1,1) NOT NULL, [Utilizador_Pessoa] [nvarchar](10) NULL, [Nome_Pessoa] [nvarchar](100) NULL, [Telemovel_Pessoa] [nvarchar](9) NULL, [Email_Pessoa] [nvarchar](100) NULL, [Chave_Pessoa] [nvarchar](50) NULL, [Nivel_Pessoa] [nvarchar](15) NULL, CONSTRAINT [PK_tbl_Pessoas_1] PRIMARY KEY CLUSTERED ( [Cod_Pessoa] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Historico]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Historico]( [Cod_Historico] [int] IDENTITY(1,1) NOT NULL, [Cod_Pessoa] [int] NULL, [Data_Historico] [datetime] NULL, [Intervencao_Historico] [nvarchar](100) NULL, [NIntervencao] [int] NULL, CONSTRAINT [PK_tbl_Historico] PRIMARY KEY CLUSTERED ( [Cod_Historico] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388;

104

Page 115: Relatorio Abracar@Escola

8.Anexo B

IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Cargos]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Pessoas_Cargos]( [Cod_Pessoa] [int] NOT NULL, [Cod_Cargo] [int] NOT NULL, CONSTRAINT [PK_tbl_Pessoas_Cargos] PRIMARY KEY CLUSTERED ( [Cod_Pessoa] ASC, [Cod_Cargo] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Orgaos]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Pessoas_Orgaos]( [Cod_Pessoa] [int] NOT NULL, [Cod_Cargo] [int] NOT NULL, [Cod_Orgao] [int] NOT NULL, [Presidente_Orgao] [bit] NULL, CONSTRAINT [PK_tbl_Pessoas_Orgaos_1] PRIMARY KEY CLUSTERED ( [Cod_Pessoa] ASC, [Cod_Cargo] ASC, [Cod_Orgao] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Eventos]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Eventos]( [Cod_Evento] [int] IDENTITY(1,1) NOT NULL, [Cod_Pessoa] [int] NOT NULL, [Cod_Cargo] [int] NOT NULL, [Cod_Orgao] [int] NOT NULL, [Titulo_Evento] [nvarchar](100) NULL, [Descricao_Evento] [nvarchar](255) NULL, [Local_Evento] [nvarchar](20) NULL, [DataInicio_Evento] [datetime] NULL, [Publico_Evento] [bit] NULL, CONSTRAINT [PK_tbl_Eventos] PRIMARY KEY CLUSTERED ( [Cod_Evento] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON

105

Page 116: Relatorio Abracar@Escola

8.Anexo B

use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Noticias]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Noticias]( [Cod_Noticia] [int] IDENTITY(1,1) NOT NULL, [Cod_Pessoa] [int] NOT NULL, [Cod_Cargo] [int] NOT NULL, [Cod_Orgao] [int] NOT NULL, [Titulo_Noticia] [nvarchar](100) NULL, [Conteudo_Noticia] [nvarchar](max) NULL, [DataPublicacao_Noticia] [datetime] NULL, [Imagem_Noticia] [nvarchar](100) NULL, [Ficheiro_Noticia] [nvarchar](100) NULL, [Url_Noticia] [nvarchar](255) NULL, [NVisualizacoes_Noticia] [int] NULL, CONSTRAINT [PK_tbl_Noticias] PRIMARY KEY CLUSTERED ( [Cod_Noticia] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Submenus]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Submenus]( [Cod_Submenu] [int] IDENTITY(1,1) NOT NULL, [Cod_Menu] [int] NULL, [Cod_Noticia] [int] NULL, [Nome_Submenu] [nvarchar](50) NULL, [Ordem_Submenu] [int] NULL, CONSTRAINT [PK_tbl_Submenu] PRIMARY KEY CLUSTERED ( [Cod_Submenu] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] END use user5388; SET ANSI_NULLS ON use user5388; SET QUOTED_IDENTIFIER ON use user5388; IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Eventos]') AND type in (N'U')) BEGIN CREATE TABLE [dbo].[tbl_Pessoas_Eventos]( [Cod_Pessoa] [int] NOT NULL, [Cod_Cargo] [int] NOT NULL, [Cod_Orgao] [int] NOT NULL, [Cod_Evento] [int] NOT NULL, CONSTRAINT [PK_tbl_Pessoas_Eventos] PRIMARY KEY CLUSTERED ( [Cod_Pessoa] ASC, [Cod_Cargo] ASC, [Cod_Orgao] ASC, [Cod_Evento] ASC

)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]

106

Page 117: Relatorio Abracar@Escola

8.Anexo B

) ON [PRIMARY] END use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Pessoas_Cargos_tbl_Cargos1]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Cargos]')) ALTER TABLE [dbo].[tbl_Pessoas_Cargos] WITH CHECK ADD CONSTRAINT [FK_tbl_Pessoas_Cargos_tbl_Cargos1] FOREIGN KEY([Cod_Cargo]) REFERENCES [dbo].[tbl_Cargos] ([Cod_Cargo]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Pessoas_Cargos] CHECK CONSTRAINT [FK_tbl_Pessoas_Cargos_tbl_Cargos1] use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Pessoas_Cargos_tbl_Pessoas]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Cargos]')) ALTER TABLE [dbo].[tbl_Pessoas_Cargos] WITH CHECK ADD CONSTRAINT [FK_tbl_Pessoas_Cargos_tbl_Pessoas] FOREIGN KEY([Cod_Pessoa]) REFERENCES [dbo].[tbl_Pessoas] ([Cod_Pessoa]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Pessoas_Cargos] CHECK CONSTRAINT [FK_tbl_Pessoas_Cargos_tbl_Pessoas] use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Pessoas_Orgaos_tbl_Orgaos1]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Orgaos]')) ALTER TABLE [dbo].[tbl_Pessoas_Orgaos] WITH CHECK ADD CONSTRAINT [FK_tbl_Pessoas_Orgaos_tbl_Orgaos1] FOREIGN KEY([Cod_Orgao]) REFERENCES [dbo].[tbl_Orgaos] ([Cod_Orgao]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Pessoas_Orgaos] CHECK CONSTRAINT [FK_tbl_Pessoas_Orgaos_tbl_Orgaos1] use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Pessoas_Orgaos_tbl_Pessoas_Cargos]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Orgaos]')) ALTER TABLE [dbo].[tbl_Pessoas_Orgaos] WITH CHECK ADD CONSTRAINT [FK_tbl_Pessoas_Orgaos_tbl_Pessoas_Cargos] FOREIGN KEY([Cod_Pessoa], [Cod_Cargo]) REFERENCES [dbo].[tbl_Pessoas_Cargos] ([Cod_Pessoa], [Cod_Cargo]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Pessoas_Orgaos] CHECK CONSTRAINT [FK_tbl_Pessoas_Orgaos_tbl_Pessoas_Cargos] use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Eventos_tbl_Eventos]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Eventos]')) ALTER TABLE [dbo].[tbl_Eventos] WITH CHECK ADD CONSTRAINT [FK_tbl_Eventos_tbl_Eventos] FOREIGN KEY([Cod_Pessoa], [Cod_Cargo], [Cod_Orgao]) REFERENCES [dbo].[tbl_Pessoas_Orgaos] ([Cod_Pessoa], [Cod_Cargo], [Cod_Orgao]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Eventos] CHECK CONSTRAINT [FK_tbl_Eventos_tbl_Eventos] use user5388;

107

Page 118: Relatorio Abracar@Escola

8.Anexo B

IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Noticias_tbl_Pessoas_Orgaos]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Noticias]')) ALTER TABLE [dbo].[tbl_Noticias] WITH CHECK ADD CONSTRAINT [FK_tbl_Noticias_tbl_Pessoas_Orgaos] FOREIGN KEY([Cod_Pessoa], [Cod_Cargo], [Cod_Orgao]) REFERENCES [dbo].[tbl_Pessoas_Orgaos] ([Cod_Pessoa], [Cod_Cargo], [Cod_Orgao]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Noticias] CHECK CONSTRAINT [FK_tbl_Noticias_tbl_Pessoas_Orgaos] use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Submenu_tbl_Menus]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Submenus]')) ALTER TABLE [dbo].[tbl_Submenus] WITH CHECK ADD CONSTRAINT [FK_tbl_Submenu_tbl_Menus] FOREIGN KEY([Cod_Menu]) REFERENCES [dbo].[tbl_Menus] ([Cod_Menu]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Submenus] CHECK CONSTRAINT [FK_tbl_Submenu_tbl_Menus] use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Submenus_tbl_Noticias]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Submenus]')) ALTER TABLE [dbo].[tbl_Submenus] WITH CHECK ADD CONSTRAINT [FK_tbl_Submenus_tbl_Noticias] FOREIGN KEY([Cod_Noticia]) REFERENCES [dbo].[tbl_Noticias] ([Cod_Noticia]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Submenus] CHECK CONSTRAINT [FK_tbl_Submenus_tbl_Noticias] use user5388; IF NOT EXISTS (SELECT * FROM sys.foreign_keys WHERE object_id = OBJECT_ID(N'[dbo].[FK_tbl_Pessoas_Eventos_tbl_Eventos1]') AND parent_object_id = OBJECT_ID(N'[dbo].[tbl_Pessoas_Eventos]')) ALTER TABLE [dbo].[tbl_Pessoas_Eventos] WITH CHECK ADD CONSTRAINT [FK_tbl_Pessoas_Eventos_tbl_Eventos1] FOREIGN KEY([Cod_Evento]) REFERENCES [dbo].[tbl_Eventos] ([Cod_Evento]) ON DELETE CASCADE use user5388; ALTER TABLE [dbo].[tbl_Pessoas_Eventos] CHECK CONSTRAINT [FK_tbl_Pessoas_Eventos_tbl_Eventos1] use user5388;

108