Saga report V0-10 -Professor - files.isec.ptfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Trabalhos de...
55
SAGA-CET Sistema de Apoio à Gestão Administrativa dos Cursos de Especialização Tecnológica Luís Miguel Barata Dias Luís Filipe Freitas de Carvalho Coelho Instituto Superior de Engenharia de Coimbra Departamento de Engenharia Informática e de Sistemas Setembro de 2012
-
Upload
truongkhue -
Category
Documents
-
view
219 -
download
0
Transcript of Saga report V0-10 -Professor - files.isec.ptfiles.isec.pt/DOCUMENTOS/SERVICOS/BIBLIO/Trabalhos de...
SAGA-CET
Sistema de Apoio à Gestão Administrativa
dos Cursos de Especialização Tecnológica
Luís Miguel Barata Dias
Luís Filipe Freitas de Carvalho Coelho
Instituto Superior de Engenharia de Coimbra
Departamento de Engenharia Informática e de Sistemas
Setembro de 2012
ii
SAGA-CET
Sistema de Apoio à Gestão Administrativa
dos Cursos de Especialização Tecnológica
Luís Miguel Barata Dias
Luís Filipe Freitas de Carvalho Coelho
Orientadores
Ana Rosa Pereira Borges (Professora Adjunta do DEIS-ISEC)
Fernanda Maria dos Reis Brito e Rodrigues Correia Barbosa
(Professora Adjunta do DEIS-ISEC)
Francisco Fernando Vasconcelos Barbosa Barros Leite (Assistente Convidado do DEIS-ISEC)
Relatório submetido como requisito parcial para obtenção do grau de licenciado em Engenharia Informática
Instituto Superior de Engenharia de Coimbra
Departamento de Engenharia Informática e de Sistemas
Setembro de 2012
iii
DEDICATÓRIA
Dedicamos este trabalho às nossas famílias, pela inesgotável paciência e apoio ao longo de
todo o curso.
iv
RESUMO
O presente texto é o relatório do trabalho desenvolvido no âmbito da disciplina de Projeto do
curso de Engenharia Informática e tem como finalidade descrever todo o processo que
decorreu desde a análise de requisitos até à implementação da aplicação web Sistema de
Apoio à Gestão Administrativa dos Cursos de Especialização Tecnológica (SAGA-CET).
A aplicação web desenvolvida permite gerir os Cursos de Especialização Tecnológica (CET)
lecionados no Departamento de Informática e de Sistemas do Instituto Superior de Engenharia
de Coimbra.
Pretende-se que esta gestão seja o mais abrangente possível (desde a fase da admissão até ao
final de cada um dos cursos), constituindo um instrumento facilitador da gestão dos processos
administrativos para os diversos formadores e para os seus administradores (administrador,
coordenador, responsáveis de componentes de formação).
Após um longo percurso, considera-se que o resultado final foi, em grande parte, de encontro
aos objetivos inicialmente estipulados.
v
AGRADECIMENTOS
Este trabalho não ficaria completo sem agradecer a todos os que ajudaram a concretizá-lo.
Neste contexto, queremos agradecer aos orientadores deste projeto, a Doutora Ana Rosa
Pereira Borges, a Engenheira Fernanda Maria dos Reis Brito e Rodrigues Correia Barbosa e o
Engenheiro Francisco Fernando Vasconcelos Barbosa Barros Leite, pela sua orientação,
disponibilidade e apoio.
6
Índice
1 Introdução............................................................................................................................ 8
2 Requisitos .......................................................................................................................... 11
2.1 Requisitos Funcionais ................................................................................................ 11
2.2 Requisitos Operacionais ............................................................................................ 17
2.3 Estrutura da Interface com o Utilizador ..................................................................... 18
2.4 Conceção da Interface com o Utilizador .................................................................... 20
3 Tecnologias de Suporte ..................................................................................................... 22
4 Base de dados .................................................................................................................... 25
5 Segurança .......................................................................................................................... 30
6 Visão Geral do Projeto ...................................................................................................... 35
6.1 Arquitetura Física ...................................................................................................... 35
6.2 Arquitetura lógica ...................................................................................................... 36
6.3 Perfis de utilizadores .................................................................................................. 38
7 Exemplos de Utilização ..................................................................................................... 40
8 Melhoramentos futuros ..................................................................................................... 46
9 Conclusões ........................................................................................................................ 47
Anexo A Modelo E-R ............................................................................................................... 51
Anexo B Modelo Físico ............................................................................................................ 52
Anexo C Resumo Requisitos .................................................................................................... 53
7
Índice de Figuras
Figura 1: Estrutura das páginas ................................................................................................ 19
Figura 2: Página de Autenticação ............................................................................................. 20
Figura 3: Página de gestão de cursos ........................................................................................ 21
Figura 4 : Camadas do Entity Data Model .............................................................................. 23
Figura 5: Fluxo da Autenticação baseada em Forms Authentication ....................................... 30
Figura 6: SqlMembershipProvider ........................................................................................... 33
Figura 7: Arquitetura física ..................................................................................................... 36
Figura 8 : Arquitetura geral ...................................................................................................... 37
Figura 9: Permissões por utilizador .......................................................................................... 42
Figura 10: Gestão de Horários .................................................................................................. 44
Figura 11: Preenchimento de sumário ...................................................................................... 45
8
1 Introdução
O presente projeto surge na sequência de uma proposta elaborada no âmbito da unidade
curricular de Projeto do 3º ano curricular da Licenciatura em Engenharia Informática do
Departamento de Engenharia e de Sistemas do Instituto Superior de Engenharia de Coimbra
(DEIS-ISEC). A proposta tem, na sua génese, o diagnóstico de um conjunto de divergências
concretas, que apontava para a necessidade de melhorar a gestão do conjunto de processos
administrativos relativos aos diversos Cursos de Especialização Tecnológica lecionados pelo
DEIS-ISEC.
Os CET (Cursos de Especialização Tecnológica) são cursos de formação pós-secundária, mas
não superior, que atribuem o nível 5 de formação profissional. De acordo com o Decreto-Lei
n.º 88/2006 de 23 de Maio, o CET carateriza-se por ser uma formação técnica de alto nível
mas que não exige domínio dos fundamentos científicos das diferentes áreas em causa.
Contudo, a sua qualificação inclui conhecimentos e capacidades que pertencem ao nível
superior, permitindo assumir, de forma geralmente autónoma ou de forma independente,
responsabilidades de conceção e ou de direção e ou de gestão.
O plano de formação de um CET integra as componentes de formação geral e científica, de
formação tecnológica e de formação em contexto de trabalho. Esse plano compõe-se de
diversas unidades de formação, ou seja, unidades de ensino, com objetivos próprios e cuja
avaliação se traduz numa classificação final. Cada unidade de formação está englobada numa
área de competência específica, por exemplo, línguas estrangeiras ou ciências informáticas.
A gestão das diferentes fases de um Curso de Especialização Tecnológica, desde a admissão
dos candidatos, até ao final do estágio, para um conjunto de formandos com diferentes níveis
de formação secundária, lecionado por um conjunto reduzido de docentes (ou formadores
externos), não é uma tarefa difícil. No entanto, quando se pretende gerir não um, mas um
conjunto de vários cursos, com interligação de um maior numero de docentes (ou formadores
externos) aos diferentes cursos, e para um maior número de formandos, a gestão
administrativa destes cursos começa a ser, relativamente, mais falível, per si, e, como tal,
mais aconselhável a ser efetuada de uma forma mais geral, uniforme e centralizada, evitando-
se assim uma maior probabilidade na existência de inconsistências, perda de informações,
atrasos de comunicação e redundância nos processos administrativos.
9
De modo a minimizar estas divergências, propôs-se o desenvolvimento, de uma forma
evolutiva, de uma aplicação web que permitisse e facilitasse a gestão administrativa do
conjunto de Cursos de Especialização Tecnológica lecionados no DEIS-ISEC. Neste contexto,
este projeto pretendeu atingir os seguintes objetivos:
• Os utilizadores (devidamente autorizados) devem poder interagir com a aplicação web
a partir de qualquer lugar, desde que, para tal, possuam acesso à internet. O acesso e a
gestão administrativa da informação serão diferenciados, tendo em consideração os
diferentes tipos de utilizador que podem interatuar com a aplicação.
• Fazer a gestão de todas as informações referentes às unidades de formação das
diversas componentes dos diferentes cursos.
• Fazer a gestão de toda a informação referente a cada um dos docentes (ou formadores
externos).
• Fazer a gestão de toda a informação referente a cada um dos formandos.
• Apoiar a atribuição das diferentes (aulas das) unidades formação aos docentes (ou
formadores exteriores).
• Produzir documentos; por exemplo, listagem da afetação do serviço docente por curso,
por docente (ou formador exterior), por unidade de formação, listagem dos formandos
por curso.
Enquadrando-se a formação profissional e a experiência curricular de um dos alunos que
desenvolveu este projeto, afigurou-se como muito pertinente a sua realização, potenciando as
mais-valias pessoais para a sua conceção e perspetivando a criação de uma ferramenta
adaptada à prática concreta, exequível e de utilização simplificada.
O documento que se segue está estruturado do seguinte modo. No capítulo 2 é feita uma
descrição da análise de requisitos realizados no início do projeto. No Capítulo 3 descreve-se
resumidamente as várias tecnologias de suporte utilizadas no desenvolvimento deste projeto,
tendo sido dado uma especial atenção à Entity Framework visto ser uma tecnologia nova para
os autores deste projeto. As tecnologias de suporte utilizadas são basicamente todas
disponibilizadas pela empresa Microsoft ao abrigo do acordo entre o ISEC e a Microsoft
(MSDN Academic Alliance Software Center). No capítulo 4 descreve-se de uma forma
resumida os elementos do modelo físico da base de dados. Este modelo e o ER que lhe deu
origem podem ser consultados nos anexos. No capítulo 5 descreve-se os mecanismos de
10
segurança utilizados no desenvolvimento da aplicação Web. No Capitulo 6 dá-se uma visão
geral do projeto, onde se descreve a implementação em três camadas e as vantagens na sua
utilização. No Capitulo 7 é dada uma breve descrição do layout da página principal. No
Capitulo 8 são descritos alguns exemplos de utilização. No Capitulo 9 encontram-se descritos
alguns tópicos propondo algumas alterações e novas funcionalidades que poderiam melhorar a
qualidade da aplicação web desenvolvida. Por fim, no capítulo 10, apresentam-se as
conclusões retiradas durante o desenvolvimento deste projeto.
11
2 Requisitos
2.1 Requisitos Funcionais
A natureza do desenvolvimento de uma aplicação web para a gestão de processos
administrativos não é significativamente diferente da natureza do desenvolvimento de um
outro qualquer tipo de aplicação web. O primeiro objetivo no processo de desenvolvimento de
uma aplicação web é delinear um modelo com o qual se possa descrever adequadamente o
domínio do problema, ou uma parte dele, para o qual a aplicação web é uma solução.
Descrever adequadamente significa que o modelo construído contém um número suficiente e
necessário de elementos que representam, de forma não ambígua, as características do
domínio do problema e que são relevantes para a sua compreensão. A construção, a escolha, a
crítica e o aperfeiçoamento do modelo, com o objetivo de definir de forma não ambígua o que
a aplicação deve ser e fazer, constituem um conjunto de atividades essenciais no seu
desenvolvimento sendo usualmente identificadas, no seu todo, como a fase de compreensão
do problema e identificação, ou a análise, dos seus requisitos.
A importância desta fase está na necessidade de dominar e controlar toda a complexa rede de
pormenores que envolve, em geral, a compreensão de um problema real. De facto, a
necessidade da análise de requisitos torna-se particularmente válida em áreas em que o
conhecimento do domínio do problema é considerado um aspeto crítico. Neste contexto,
mediante o início do programa de trabalhos, a primeira atividade realizada foi a análise de
requisitos da aplicação, estabelecidos por forma a cumprir os objetivos constantes na proposta
de projeto. Vários destes requisitos foram cumpridos, outros foram revistos ao longo das
diversas fases de desenvolvimento da aplicação.
Com base na análise do problema foram identificadas os seguintes grupos de funcionalidades
a implementar:
• Gestão de Formandos.
• Gestão de Utilizadores.
• Gestão de Cursos.
• Gestão de Aulas.
• Gestão de Horários.
12
• Gestão de Estágios.
• Gestão de Avaliações.
• Produção de Relatórios em PDF.
No Anexo C, estão descritas, num conjunto de tabelas, para cada um dos grupos de
funcionalidades a implementar, as funcionalidades específicas a cada um dos grupos e, entre
estas, as que foram implementadas neste projecto.
Ao identificar a estrutura do problema, é igualmente necessário definir uma estrutura para a
sua solução, procurando identificar a melhor resposta (entre várias soluções possíveis) que se
pode definir a partir da estrutura do problema e que comporta um conjunto de opções e
restrições. Em termos gerais, pretende-se que a aplicação web utilize uma arquitetura
cliente/servidor, recorrendo a um servidor de base de dados para aceder/colocar a informação
necessária à utilização da aplicação. Deverá ter um layout simples e agradável e evidenciar na
página principal um conjunto de ligações que permitam o acesso, de forma intuitiva, a todas
as funcionalidades da aplicação. Para permitir futuras evoluções, esta deve estar estruturada
de uma forma modular, permitindo facilmente a adição de novas funcionalidades.
Com este conceito de módulo pretende dizer-se, não que a estrutura desta aplicação funcione
em partes independentes, mas que está estruturada por operações ou grupos de ações,
correlacionados e interdependentes, facilitando a sua consulta e utilização e sendo visível
apenas nos perfis de utilizador autorizados. Cada módulo permite tornar a operação acessível
ao utilizador e manipular os dados das tabelas associadas à ação em causa. Neste pressuposto,
definiram-se os seguintes nove módulos a implementar:
1. Gestão de Formandos
2. Gestão de Utilizadores
3. Gestão de Cursos
4. Gestão de Aulas
5. Gestão de Horários
6. Gestão de Estágios
7. Gestão de Avaliações
8. Produção de Relatórios em PDF
13
1 - Gestão de Formandos
O módulo de gestão de formandos deverá permitir, na mesma página, todas as operações
passíveis de executar relativamente à informação dos formandos:
• Inserir novos formandos.
• Inscrever formandos nas unidades de formação.
• Pesquisar determinada informação relativa aos formandos existentes. Deve permitir a
pesquisa de um formando através de um conjunto variado de padrões de pesquisa (por
exemplo, formandos de determinado CET).
• Após a definição do padrão de pesquisa, deve ser apresentada uma listagem com a
informação dos formandos que satisfazem essas condições.
• Aceder ao registo de determinado formando, a partir da listagem apresentada
anteriormente.
• Permitir o acesso dos formandos a informação do seu interesse (avaliações, faltas,
horários, informações genéricas dos CET.)
• Aceder ao registo do conjunto de faltas dos formandos, em uma ou mais unidades de
formação.
O registo de faltas e avaliações é efetuado nos módulos referentes à gestão de aulas e gestão
de avaliações, respetivamente.
2 - Gestão de Utilizadores
O módulo de gestão de utilizadores deve permitir, na mesma página, todas as operações
passíveis de executar relativamente à informação dos utilizadores. A inserção / edição de
utilizadores tem algumas restrições, dependendo do tipo de utilizador que está a utilizar a
aplicação. Deverá ser possível:
• Criar utilizadores.
• Listar utilizadores.
• Ativar, desativar e desbloquear um utilizador.
14
• Atribuir/alterar o nome de autenticação (login) a um utilizador.
• Definir o tipo de utilizador.
3 - Gestão de Cursos
O módulo de gestão de cursos deve permitir, na mesma página, todas as operações passíveis
de executar relativamente à informação dos cursos. Só o administrador é que poderá criar
CET, assim como a atribuição da coordenação. Todas as tarefas de gestão poderão ser
executadas pelo coordenador e responsáveis de componente, exceto a atribuição dos
responsáveis de componente (só autorizada ao administrador e coordenador).Este módulo
permitirá:
• Inserir um novo CET.
• Atribuir um conjunto de unidades de formação aos CET.
• Atribuir um Coordenador e os diversos responsáveis de área de formação a cada
um dos CET.
• Atribuir formadores às unidades de formação.
• Alterar os dados de um determinado CET.
• Alterar o formador de determinada unidade de formação.
• Criar a calendarização prevista para os CET.
• Inserir interrupções (previstas ou extraordinárias) para os CET.
• Listar informações relativamente aos cursos:
o Formandos existentes.
o Unidades de Formação (com horas já lecionadas e previstas).
o Formadores de determinado CET.
4 - Gestão de Aulas
15
O módulo de gestão de aulas deverá permitir, na mesma página, todas as operações passíveis
de executar relativamente às aulas. Só o formador de cada aula é que poderá inserir ou editar
sumários, bem como marcar e justificar faltas dos formandos. As operações serão:
• Gerar uma folha de sumário, com um conjunto de elementos pré-definidos.
• Escrever o sumário.
• Registar as faltas dos formandos.
• Mostrar o número de horas totais já lecionadas na unidade de formação.
5 - Gestão de Horários
O módulo de gestão de horários deverá permitir, na mesma página, todas as operações
passíveis de serem executadas, relativamente ao horário. A inserção e edição de horários só
serão permitidas aos responsáveis de componente e coordenador dos CET. A gestão de
horários permitirá:
• Inserir e editar horários.
• Definir o intervalo de datas em que os horários estão em vigor.
• Listar o horário, por curso, dentro de determinadas datas.
• Gerar as aulas previstas a partir dos horários inseridos.
6 - Gestão de Estágios
O módulo de gestão de estágios deve permitir, na mesma página, todas as operações passíveis
de serem executadas, relativamente ao estágio. A afetação de formandos em estágios só pode
ser executada pelo responsável dos estágios de cada CET. Deverá ser permitido:
• Registar as informações das empresas de acolhimento.
• Afetar formandos a um estágio.
• Inserir informações relativas a um estágio (datas, horas diárias).
16
7 - Gestão de Avaliações
A aplicação deverá permitir todas as operações a nível de registo e consulta das avaliações
dos alunos. Avaliar um aluno é uma tarefa só acessível ao responsável da unidade de
formação, sendo a consulta permitida a todos os intervenientes em cada CET. No global este
módulo deve permitir:
• Inserir a avaliação formativa e sumativa dos formandos.
• Aprovar/reprovar formandos nas unidades de formação.
• Visualizar as avaliações dos formandos por unidade de formação ou por formando.
8 - Produção de Relatórios em PDF
Os utilizadores deverão ter a possibilidade de exportar para PDF a informação mais pertinente
existente na aplicação, nomeadamente:
• Listagem de formandos por CET.
• Listagem de avaliações dos formandos:
o Por formando.
o Por unidade de formação.
• Relatório com aulas previstas e ministradas:
o Por formador.
o Por CET.
• Listagem das faltas num intervalo de datas:
o Por formando.
o Por unidade de formação.
• Relatório com os horários:
o Por CET.
o Num intervalo de datas.
• Relatório com a folha de sumário, com os elementos já preenchidos.
17
2.2 Requisitos Operacionais
Os requisitos operacionais referem-se à facilidade de uso (usabilidade), confiabilidade,
confidencialidade, integridade, autenticidade e autorização de acesso.
Facilidade de Uso. A aplicação deve ser de uso fácil por parte dos seus utilizadores. A
aplicação só será útil se for de fácil aprendizagem e permitir que a sua utilização seja possível
sem necessidade de recurso a equipamento muito específico. Neste sentido, pretende-se que
esta aplicação seja de fácil aprendizagem e para isso a aplicação deve ter uma interface
simples e intuitiva. Todos os elementos apresentados devem ser claros e a informação
disponibilizada deve ser de fácil leitura. A navegação ao longo das suas diversas
componentes deverá permitir ao utilizador aceder rapidamente a qualquer página da
aplicação.
Confiabilidade – A confiabilidade representa a garantia do correto funcionamento da
aplicação. A aplicação deve funcionar de forma robusta, sem perda de informações, tornando-
se confiável perante os seus utilizadores. Fortemente relacionados com este princípio são os
princípios da confidencialidade e da integridade.
Confidencialidade e Integridade - A confidencialidade é a ausência de divulgação não
autorizada de informação. A integridade diz respeito à ausência de alterações não autorizadas
à aplicação, ou à informação nela existente. A aplicação deve ter a capacidade de detetar e
rejeitar qualquer tentativa de intrusão de agentes externos, ou internos, não autorizados, com o
intuito de modificar a aplicação, ou a informação nela existente, e comprometer os objetivos a
que se destina.
Autenticidade e Autorização de Acesso – A autenticação consiste na validação das
credenciais de um utilizador. Autenticar um indivíduo é o meio pelo qual a identificação de
um utilizador é validada, ou seja, é verificado se o utilizador é quem diz ser. A autorização
consiste em verificar se um utilizador autenticado possui, ou não, acesso a um determinado
recurso. A autorização é um requisito fundamental para que se cumpram os requisitos de
confidencialidade e de integridade do sistema.
18
2.3 Estrutura da Interface com o Utilizador
Para a criação da interface foram seguidas as seguintes linhas orientadoras.
• Não devem existir elementos supérfluos.
• Todas as ações executadas pelos utilizadores devem ser passíveis de serem
revertidas.
• Devem existir avisos para alertar os utilizadores sobre a ação tomada em cada
momento.
• Os nomes dos menus devem ser claros por forma a não gerar ambiguidade
entre os diversos nomes.
• A interação deve ter uma sequência lógica e facilmente entendível, por parte
dos utilizadores.
Tendo como base estas linhas orientadoras, foi elaborado a seguinte estrutura para as diversas
paginas:
19
Figura 1: Estrutura das páginas
A estrutura da página é composta por 7 elementos (Figura 1). Na parte superior (1) encontra-
se o símbolo (logótipo) da aplicação. O menu principal (2) foi colocado no topo da página
para facilitar o acesso às suas diferentes opções. As opções a constar no menu principal vão
diferir por tipo de utilizador. Na parte lateral esquerda (5) é a zona para colocação dos
submenus de cada uma das opções do menu principal. Os menus e submenus devem estar
sempre presentes em cada página, permitindo assim que o utilizador possa navegar
rapidamente entre as diversas páginas.
Existe uma zona reservada (4) para a colocação da informação da opção do menu em que o
utilizador se encontra em cada momento. Para identificar qual o utilizador que está com uma
sessão iniciada, e que também permite ao utilizador sair da aplicação, foi incluída uma zona
específica. Nesta zona (3), o utilizador também poderá editar os seus dados pessoais. A zona
(6) está reservada ao conteúdo relativo a cada página. Por último, a zona (7) está reservada à
informação relativa aos autores e ao nome da aplicação.
Note-se que ao longo das diversas páginas da aplicação a sua estrutura não é alterada: o topo e
o rodapé mantêm-se, existindo alterações nas diversas opções do menu e dos submenus, bem
como do conteúdo central.
20
2.4 Conceção da Interface com o Utilizador
Após a conceção da estrutura da interface com o utilizador, foi elaborado um modelo,
seguindo as linhas orientadoras indicadas na secção 2.3. A fonte de inspiração para o modelo
do layout utilizado na aplicação foi retirado da seguinte página web:
http://www.netdreams.co.uk/index.php/blog/2010/02/18/free-admin-skin-available-for-download/
Embora o modelo citado tenha servido de fonte de inspiração, todos os componentes e folha
de estilos (CSS) utilizadas, foram especificamente construídas para esta aplicação.
Página de Autenticação
Nesta página o utilizador pode introduzir as suas credenciais de autenticação na aplicação e
tem acesso à página de recuperação de palavra-chave.
Figura 2: Página de Autenticação
21
Página Principal
Na página principal foram seguidos os seguintes pressupostos: existe sempre a identificação
da opção do menu principal que foi selecionada pelo utilizador e para o sub-menu essa
identificação é conseguida por um destaque visual dado ao elemento selecionado. Esse
destaque do sub-menu é conseguido através da alteração da cor do fundo, que passa da cor
verde para a cor cinza. Na imagem seguinte é possível verificar que o utilizador selecionou a
opção Gestão do menu principal e que selecionou a opção CURSOS do sub-menu (vertical-
esquerda). Este destaque é de extrema importância para que a interação do utilizador com a
aplicação seja, per si, mais intuitiva. Com base neste modelo de sinalização da interação, o
utilizador é informado, de uma maneira simples e rápida, da zona de trabalho em que se
encontra. Note-se que, o conteúdo central é sempre atualizado com os dados referentes às
opções selecionadas pelo utilizador. Na figura 3 é mostrado, como exemplo de utilização, o
horário preparado para um determinado CET.
Figura 3: Página de gestão de cursos
22
3 Tecnologias de Suporte
Para o desenvolvimento desta aplicação utilizou-se a ferramenta de desenvolvimento Visual
Studio 2010. Optou-se pela utilização da .NET Framework 4 por ser a plataforma mais recente
disponibilizada pela Microsoft. Das ferramentas disponibilizadas pelo ambiente integrado de
desenvolvimento (IDE) utilizou-se a ASP.NET 4, a linguagem de programação C# e CSS2.1 .
Como plataforma de acesso a dados utilizou-se a Entity Framework. Para armazenamento de
dados foi utilizado Microsoft SQL Server 2008 Express Edition e como complemento ao
desenvolvimento da aplicação, foi utilizado o ASP.NET AJAX Control Toolkit.
Visual Studio 2010: O Microsoft Visual Studio 2010 é um Ambiente Integrado de
Desenvolvimento (IDE) que permite o desenvolvimento de aplicações para web, Windows e
Windows phone.
.NET Framework 4: A .NET Framework é a plataforma que oferece a base necessária para
compilar e correr aplicações baseadas na tecnologia. Todo e qualquer código gerado para
.NET pode ser executado em qualquer dispositivo ou plataforma que contenha a Framework.
ASP.NET 4: A ASP.NET é uma plataforma da Microsoft para o desenvolvimento de
aplicações Web. É um componente do IIS que permite através de uma linguagem de
programação integrada na Framework .NET criar páginas dinâmicas.
Linguagem C#: A linguagem C# é uma linguagem de programação orientada por objetos,
criada pela Microsoft, baseada na linguagem C++ e JAVA. É uma linguagem desenvolvida
especialmente para integração na Framework .NET e consequentemente com vantagens ao
nível da integração com as suas outras componentes.
Cascading Style Sheets (CSS): O CSS é uma ferramenta que permite a construção de layouts
dos sites web. O seu principal benefício é promover a separação entre o formato e o conteúdo
de um documento HTML.
Entity Framework: A Entity Framework é uma tecnologia que permite aos programadores
focarem-se mais nos modelos e regras de negócio das suas aplicações e menos nos detalhes
diretamente relacionados com as bases de dados, respetivos acessos e manutenções. Esta
tecnologia permite aos programadores trabalhar com os dados na forma de objetos específicos
23
do domínio, como alunos, cursos, sumários entre outros, sem ser necessário relacioná-los com
as tabelas da base de dados. Não é necessário realizar consultas sobre um schema de uma base
de dados, antes efetua-se consultas sobre um schema que reflete as regras de negócio. Quando
os dados são devolvidos eles já são devolvidos como objetos, não é necessário efetuar
nenhuma conversão. Quando é preciso guardar as alterações na base de dados guardam-se
também os objetos. Na Entity Framework tudo gira em torno de um EDM (Entity Data
Model). A representação do EDM é efetuada através de um ficheiro EDMX que é repartido
por um conjunto de ficheiros XML.
O Entity Data Model (EDM) é definido pelos seguintes arquivos de modelo e mapeamento:
1. Arquivo de definição de schema conceptual (csdl) - define o modelo
conceptual.
2. Arquivo de especificação de mapeamento (msl) - Define o mapeamento entre
os modelos conceptual e de armazenamento.
3. Arquivo de definição de schema de armazenamento (ssdl) - Define o modelo
de armazenamento, também chamado de modelo lógico.
Figura 4 : Camadas do Entity Data Model
(Fonte: http://www.code-magazine.com/article.aspx?quickid=0711051)
24
Existem três tipos de abordagens quando utilizamos Entity Framework 4.0:
1. Database-first, na qual são criadas as nossas entidades (classes) usando uma
base de dados já existente (abordagem seguida pelos autores deste projeto);
2. Model-first, em que é criado o modelo conceptual e, com base nele, é gerado
um script para a criação da base de dados;
3. Code-first, em que é utilizado POCO (Plain Old Code CRL) para criação
manual de toda a lógica de entidades e ligação, não perdendo, no entanto, todas
as vantagens da utilização da Entity Framework.
25
4 Base de dados
Como sistema de gestão de Base dados utilizou-se o Microsoft SQL Server 2008 Express
Edition. É um produto gratuito que utiliza o mesmo motor do SQL Server 2008. Esta edição
tem algumas limitações, pois só suporta no máximo de 50 instâncias na mesma máquina,
estando limitada ao uso de apenas um processador físico, de 1 GB de memória e de 10 GB de
armazenamento, não tendo, contudo, limitações ao nível do número de utilizadores em
simultâneo.
A escolha deste sistema de Gestor de Base de dados por parte dos autores deste projeto deveu-
se também à escolha da plataforma de desenvolvimento utilizada, o Visual Studio. Para
implementação deste projeto aconselha-se a utilização do SQL Server 2008 Web Edition
devido a não ter limitações tão restritivas em termos de utilização de memoria e espaço de
armazenamento.
Desde muito cedo os autores tentaram construir uma base de dados que desse resposta a todas
as necessidades previstas na análise de requisitos. Como auxilio para a construção da base de
dados, foi usada a aplicação Sybase PowerDesigner V15 (versão Trial) para desenhar o
modelo entidade relacionamento (Pode ser consultado no Anexo A). A partir do modelo
entidade relacionamento, usando a mesma aplicação, gerou-se o modelo físico da base de
dados (Pode ser consultado no Anexo B). Este modelo físico é composto por 26 tabelas.
Destas tabelas, todas cujo nome inicia por “aspnet_” foram geradas automaticamente em
virtude da utilização do Membership da plataforma ASP.NET.
Descrição das tabelas utilizadas:
• AREA_COMPETENCIA
Contém as áreas de competência possíveis para os módulos.
• CURSO
Guarda os nomes dos CET.
• CET
Guarda as informações genéricas relativamente a um CET, desde a calendarização até o
horário de funcionamento.
26
• FALTAS
Mantém o registo dos formandos que faltaram às aulas, sendo possível marcar faltas
“parciais” (por exemplo: o aluno faltar á primeira hora e assistir à segunda)
• NOMES_UNIDADE_FORM
Guarda os nomes das unidades de formação que os CET poderão conter.
• UNIDADE_FORM_CET
Mantém o registo das afetações dos NOMES_UNIDADE_FORM aos CET. Poderá dizer-se
que nesta tabela é que estão representadas as unidades de formação, com todas as suas
características, como por exemplo a duração.
• AULA
Guarda todos os dados de determinada aula, incluindo o sumário. Esta tabela tem um campo
(tagAula) que está a “0” ou “1” dependendo se o sumário já foi feito ou não. Não é possível
editar um registo para aulas que vão ocorrer em datas futuras.
• AVALIACAO_FINAL
Guarda a nota do formando obtida na unidade de formação. No caso de ter sido ultrapassado o
número de faltas, o aluno não tem aprovação.
• NOTA_FORMATIVA
Guarda as classificações possíveis que se podem atribuir a cada parâmetro da avaliação
formativa (Não Satisfaz, Satisfaz Pouco, Satisfaz, Satisfaz Bem, Satisfaz Muito Bem). Nesta
tabela não é possível inserir ou alterar registos.
• PARAMETROS_FORMATIVA
Guarda quais os parâmetros existentes para efectuar a avaliação formativa de um a formando
(Aquisição de Conhecimentos, Aplicação dos Conhecimentos, Progressão na Aprendizagem,
Pontualidade e Assiduidade, Interesse e Motivação).
Nesta tabela não é possível inserir ou alterar registos.
• AVALIACAO_FORMAL
Guarda os dados referentes à avaliação formal dos alunos.
27
• HORARIO
Nesta tabela fica registado em que dia da semana, em que horas e em que sala vão ocorrer as
aulas de uma unidade de formação. Também fica registado o formador que irá ministrar esta
aula.
• CALENDARIO_HORARIO
Guarda o período de tempo em que os HORARIOS estão em vigor.
• CANDIDATOS
Guarda os dados pessoais dos alunos. Ao ser inserido um candidato obrigatoriamente tem o
estado “Admitido” relativamente a um CET.
• CANDIDATURA
Armazena a nota de candidatura com que um candidato foi admitido no CET. Um registo só é
inserido se o utilizador preencher a nota de admissão.
• CONTA_EMAIL
Guarda as definições da conta de email que a aplicação utiliza para enviar os credenciais de
acesso aos utilizadores. Esta tabela só tem um registo, podendo ser modificada apenas por um
utilizador que tenha a regra “administrador”.
• EMPRESA
Guarda os dados de entidades de acolhimento dos estágios.
• ESTADO
Contém os estados de um candidato num CET (admitido, não admitido, matriculado, repetente, anulou matricula, concluído, estágio). Esta tabela já está pré-preenchida, não sendo possível inserir novos registos.
• ESTADO_CANDIDATO_CET
Guarda o estado de um aluno relativamente a um CET e a data em que ocorreu (por exemplo:
ao inserir um novo aluno, nesta tabela é inserido um novo registo para esse aluno com o
estado “Admitido” e a data de admissão).
28
• ESTAGIO
Guarda os dados relativamente a um estágio.
• FORMADOR_CET
Guarda as afetações de utilizadores a unidades de formação.
• UNIDADE_FORM_ESTADO
Contém os estados possíveis que um aluno pode ter relativamente a um módulo (“inscrito”,
“aprovado”, “creditação”).
Não é possível alterar ou acrescentar registos nesta tabela.
• INSCRICOES_UNIDADE_FORM
Regista a que módulos o aluno está inscrito e em que estado está a inscrição (estados
possíveis na tabela UNIDADE_FORM_ESTADO)
• INTERRUPCOES
Guarda o registo de interrupções que poderão existir.
• INTERROMPE_EM
Guarda os CET é afetados pelas interrupções existentes na tabela INTERRUPCOES.
• SALAS
Guarda a descrição das salas existentes.
• TIPO_UNIDADE_FORM
Contem os tipos de unidades de formação possíveis: “Geral e específica”, “Tecnológica”,
“Contexto de Trabalho”.
Nesta tabela não é possível inserir ou alterar registos.
• UTILIZADORES
Guarda os dados pessoais de todos os utilizadores da aplicação.
• aspnet_Users
Contém os registos dos utilizadores.
29
• aspnet_Membership
Contém os dados introduzidos pelos utilizadores aquando do registo na aplicação.
• aspnet_Roles
Identifica as regras disponibilizadas pela aplicação
• aspnet_UserInRoles
Identifica as regras de cada Utilizador. Cada utilizador pode ter mais que uma regra.
30
5 Segurança
Segurança é um dos pontos mais importantes no desenvolvimento de aplicações,
especialmente de aplicações web. A segurança em ASP.NET tem dois conceitos essenciais:
Autenticação e Autorização. O processo de autenticação identifica o utilizador e o processo de
autorização é que determina se o utilizador tem acesso, ou não, a determinado recurso
existente na aplicação web.
Autenticação por Forms Authentication
A autenticação implementada na aplicação desenvolvida é baseada em Forms Authentication.
Este tipo de autenticação é baseado em cookies, ou seja, depois de um utilizador estar
autenticado, as suas credenciais são armazenadas em cookies válidos para aquela sessão.
Quando o utilizador não está autenticado e requisita uma página que requer autorização, é
direcionado para a página de autenticação da aplicação.
A seguinte figura ilustra o fluxo da autenticação baseado em Forms Authentication.
Figura 5: Fluxo da Autenticação baseada em Forms Authentication
31
(Fonte: http://www.asp.net/web-forms/tutorials/security/introduction/security-basics-and-asp-net-support-cs)
1. O browser efetua o pedido de uma página .aspx protegida.
2. Se o pedido não contém um cookie válido, o ASP.NET redireciona o pedido para a
página de autenticação (indicada no ficheiro de configuração web.config), onde são
pedidas as credenciais do utilizador.
3. ASP.NET verifica se o pedido contém um cookie de autenticação válido. Se existe,
significa que as credenciais do utilizador já foram verificadas. Então ASP.NET efectua
o teste de autorização, comparando as credenciais contidas no cookie de autorização
recebido no pedido com as regras de autorização existentes no ficheiro web.config.
4. Se a autorização tem sucesso o acesso à página segura é permitido.
5. Se a autorização falha, o utilizador é redirecionando novamente para a página de
autenticação.
De seguida apresenta-se a configuração no arquivo web.config para o modo de autenticação:
Autorização
O ASP.NET inclui duas formas para determinar se um utilizador tem autorização para aceder
a um arquivo ou pasta específica: URL authorization ou File authorization.
A File authorization é activada quando a aplicação está configurada para utilizar Windows
Authentication e a URL authorization quando esta configurada para utilizar Forms
Authentication.
É no ficheiro web.config que se pode permitir ou negar a permissão de aceder a um recurso
URL (ficheiro ou pasta) para um utilizador ou grupos de utilizadores (regras).
<authentication mode="Forms">
<forms name="AppNameCookie"
timeout="10"
requireSSL="false"
cookieless="UseCookies"
loginUrl="login.aspx"
defaultUrl="paginas/home.aspx"/>
</authentication>
32
A autorização, tal como a autenticação, é especificada no arquivo web.config da aplicação. De
seguida apresenta-se a configuração no arquivo web.config dos parâmetros de autorização da
aplicação desenvolvida:
Providers
Na plataforma .Net a autenticação e autorização é implementada pela utilização de Providers.
Os Providers são classes que contêm métodos estáticos que possibilitam a autenticação e
autorização dos utilizadores de uma aplicação. Este tipo de serviço necessita de
armazenamento persistente de dados (por exemplo em bases de dados, ficheiros XML, etc.) e
não comunicam directamente com a camada de acesso a dados, mas sim com o Provider. A
vantagem de utilização de Providers é a não necessidade de escrever código para a gestão de
utilizadores na aplicação, ficando esta responsabilidade para o Provider. Para utilizar os
serviços do Provider basta apenas configurar o ficheiro web.config da aplicação web.
O Provider escolhido para a aplicação foi o SqlMembershipProvider. Por omissão, este
Provider aponta para uma base de dados denominada por ASPNETDB.MDF (colocada na
directoria App_Data, da aplicação). Como se pretende configurar tudo o que é necessário para
utilizar o Membership na base de dados criada para a aplicação, foi necessário recorrer a
ferramenta aspnet_regsql.exe, disponibilizada pela framework.
<location path="paginas/Gerir">
<system.web>
<authorization>
<allow roles="administrador"/>
<allow roles="coordenador"/>
<allow roles="responsavel"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
<location path="paginas/Outros">
<system.web>
<authorization>
<allow roles="Administrador"/>
<deny users="*"/>
</authorization>
</system.web>
</location>
<location path="Styles”>
<system.web>
<authorization>
<allow users="?"/>
</authorization>
</system.web>
</location>
<location path="imagens">
<system.web>
<authorization>
<allow users="?"/>
</authorization>
</system.web>
</location>
33
O modo de funcionamento do Provider é representado na figura seguinte:
Figura 6: SqlMembershipProvider
(Fonte: http://www.asp.net/web-forms/tutorials/security/introduction/security-basics-and-asp-net-support-cs)
1. O utilizador coloca as suas credenciais na página de autenticação.
2. A classe Membership consulta o ficheiro de configuração (web.config) para validar
qual o Provider que deve utilizar.
3. A classe Membership acciona o Provider especificado no ficheiro de configuração.
4. O Provider executa uma interrogação (query) na base de dados para verificar se as credenciais do utilizador são válidas. O resultado desta operação é passado para a classe Membership e, dependendo do valor passado, é permitido o acesso ou não, a aplicação.
34
De seguida apresenta-se a configuração do arquivo web.config para os parâmetros de configuração do Provider:
<membership>
<providers>
<clear/>
<add connectionStringName="ApplicationServices"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="true"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="5"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
applicationName="MyApplication"
35
6 Visão Geral do Projeto
6.1 Arquitetura Física
Um dos requisitos definidos para este projeto era que os seus utilizadores pudessem aceder à
aplicação a partir de qualquer lugar, desde que, para tal possuíssem acesso à internet. Esta
solução traz as seguintes vantagens:
1. Os utilizadores podem aceder de uma forma fácil à aplicação a partir de qualquer
computador pessoal, desde que para isso possuam uma ligação à Internet.
2. Não é necessário instalar nenhuma aplicação nos computadores clientes, somente
necessitam de possuir um browser instalado.
3. Facilita as tarefas de manutenção do sistema, visto que as atualizações são refletidas
para todos os utilizadores.
Para a concretização deste projecto é necessário recorrer a uma infra-estrutura informática
para alojar a aplicação desenvolvida e a base de dados. É necessário um servidor web para
permitir o acesso às páginas ASP.NET e HTML criadas, por parte dos browsers das máquinas
cliente. Como estamos a trabalhar com ferramentas na sua maioria Microsoft, também se
deverá até por uma questão de compatibilidade utilizar o Servidor Web da Microsoft,
chamado IIS (Internet Information Services). Para alojamento da base de dados, também é
necessário um servidor. Este servidor será desnecessário caso a organização onde seja
implementada esta aplicação opte pela colocação do servidor Web e servidor de base de dados
dentro da mesma máquina física. Relativamente ao servidor de base de dados propõem-se a
utilização do SQL Server Web Edition. Na figura seguinte é ilustrado o modelo da arquitetura
física.
36
Figura 7 - Arquitetura física
A arquitetura baseia-se numa arquitetura típica de modelo cliente/servidor onde vários
clientes podem aceder a plataforma em simultâneo. Quando um cliente acede ao servidor web
através de um computador ligado à internet, o servidor web processa esse pedido interagindo
com o sistema gestor de base de dados e posteriormente retorna a informação solicitada ao
cliente.
6.2 Arquitetura lógica
Ao nível da arquitetura lógica, optou-se por uma arquitetura em três camadas. Este padrão de
design de software tem vantagens relativamente a outros padrões assentes nesta arquitetura
cliente/servidor. Neste modelo existe uma separação de camadas, tornando-o mais flexível
pela sua facilidade na reutilização e atualização de código. Além da vantagem anteriormente
descrita, as funcionalidades da camada de negócio e camada de dados podem ser divididas em
classes, promovendo então uma modelação orientada a objetos. Esta modularidade da
aplicação torna-a mais fácil de manter e evoluir.
37
Entidades
Figura 8 - Arquitetura geral
1. Camada de Dados: é a responsável pela ligação com a base de dados e aqui não foi
colocado qualquer validação de dados, apenas o código necessário para acesso aos
dados. Esta camada é responsável por inserir, atualizar, eliminar e consultar os dados
existentes nas tabelas.
2. Camada de negócio: Aqui que foi implementada toda a lógica de negócio. Esta
camada também é utilizada para passagem de informação entre a camada de dados e a
camada de apresentação.
3. Camada de apresentação: Esta camada corresponde a componente de interface com os
utilizadores, interage com a camada de negócio, nunca interage diretamente com a
camada de dados. Nesta camada utiliza-se algum tipo de validação inicial, de forma a
evitar comunicações desnecessárias com o servidor sempre que o utilizador introduz
alguma informação incorreta. Como exemplo: Quando um utilizador, num
38
determinado formulário, introduz uma data inferior a data atual como validade para
um determinado documento.
4. Entidades: Esta camada é transversal a toda a aplicação e é a única camada que é
visível por todas as outras. Esta camada contém todas classes básicas (Ex: Cursos) que
representam a base de dados da aplicação.
6.3 Perfis de utilizadores
A aplicação foi desenvolvida tendo como base a possibilidade de existência dos seguintes
perfis:
Administrador
O Administrador representa a pessoa responsável por coordenar toda a gestão dos CET. Esta
pessoa pode executar todas as tarefas de gestão, sendo as mais importantes as de gerir cursos e
utilizadores. O administrador é o único que pode criar cursos e criar novos utilizadores
administradores. O administrador pode consultar toda a informação relativa aos CET.
Coordenador
Cada CET tem uma pessoa responsável pela sua coordenação. Esta pessoa pode executar
todas as tarefas de gestão relacionadas com a gestão dos CET para os quais é coordenador. O
principal papel de um coordenador será atribuição dos responsáveis de área do CET que é
responsável. O coordenador pode criar utilizadores dos tipos responsável e formador.
Responsável
O responsável representa a pessoa responsável por uma ou varias componentes de cada CET.
Estas componentes podem ser a geral, científica ou formação em contexto de trabalho.
Este tipo de utilizador pode criar utilizadores do tipo formador. Como qualquer um dos
anteriores perfis, este também tem a possibilidade de inserir os alunos admitidos a cada um
dos CET.
39
Formador
O Formador representa a pessoa responsável pela marcação de faltas, escrever sumários e
lançar as notas dos alunos. Pode visualizar toda a informação dos alunos aos quais dá aulas.
Aluno
O perfil de aluno pode visualizar toda a sua informação, tais como os seus dados pessoais, as
suas notas, faltas aos diversos módulos e os horários do seu curso.
40
7 Exemplos de Utilização
Neste capítulo pretende ilustrar-se como utilizar algumas das funcionalidades da aplicação,
tendo sido escolhidos exemplos das que os autores julgam mais relevantes.
Caso 1: Criar um novo CET
Só os administradores podem criar e atribuir a coordenação de CET:
(Menu principal) Gestão->(Submenu)Cursos
Nesta janela surge a lista de todos os CET, sendo possível editar um CET ou, clicando no
botão laranja “*Novo”, introduzir os dados de um novo CET no painel que surge.
No separador “Geral”, escolhe-se o nome do CET que se pretende criar, selecionando um
item da caixa de combinação “CET”. Esta caixa está carregada com a lista de nomes de CET
já existentes. Se for pretendido um nome novo, basta clicar no botão “*novo” e preencher o
pop-up. Quer seja novo ou não, a caixa “Edição” é preenchida automaticamente pela
aplicação.
Ao escolher o nome, no caso de já existir um CET com o mesmo nome que tenha sido criado
anteriormente, surge um pop-up onde se pode “aproveitar” os dados desse CET (por exemplo,
os módulos).
Escolhe-se então o coordenador da aplicação, selecionando um dos nomes existentes na caixa
de combinação “Coordenador”, que está carregada com os nomes de utilizadores da
aplicação (exceto utilizadores do tipo “aluno”).
Se o utilizador clicar em “Ok”, o CET é criado.
Excluindo a atribuição dos responsáveis de componente, (que poderá ser feita pelo
coordenador), a partir desta fase a gestão de todo o CET poderá ser feita pelo coordenador ou
pelos responsáveis de componente.
No separador “Calendário” define-se a calendarização do CET, desde a fase de candidaturas
até à fase dos estágios.
41
No separador “Módulos”, são escolhidos as unidades de formação do CET. Estes itens
poderão já estar pré-preenchidos, no caso de se ter optado por utilizar dados de um CET
anterior no momento da criação do curso.
Clicando no botão “+”, abre-se o painel da unidade de formação. Pode escolher-se um nome
de um módulo, selecionando um dos elementos da caixa de combinação “Módulo”. No caso
de se pretender atribuir um módulo cujo nome ainda não exista, deve clicar-se no botão à
direita da caixa (“*base”). No pop-up, deve preencher-se o nome e o diminutivo pretendido e
clicar em “ok”.
A atribuição da “Área de competência” é executada de forma similar à atribuição do nome do
módulo (se não existir na caixa, deve clicar-se no botão “A.C” e preencher o pop-up).
De seguida, clicando em “Inserir” conclui-se a associação da unidade de formação ao CET.
Nesta fase, é mostrada a janela com a listagem de unidades de formação, na qual é possível
repetir o processo anterior para criar uma nova, ou editar uma já existente.
Só depois da unidade de formação criada é que é possível associar-lhe os formadores e
respetivo responsável.
Editando uma unidade de formação, surge uma janela de edição, já com as opções de
atribuição de formadores e responsável ativas.
Para atribuir formadores, deve clicar-se no botão laranja “*” e escolher um utilizador da lista
apresentada. Ao fazer esta escolha, o sistema adiciona a regra “formador” ao utilizador, se
ainda não a tiver.
Ao clicar em “Ok” no pop-up apresentado, o utilizador escolhido é afeto a essa unidade de
formação.
Só depois de pelo menos um formador estar associado é que é possível atribuir o responsável,
pois a caixa “Responsável” é carregada com os formadores afetos à unidade de formação.
Clicando em “Guardar” são guardadas as alterações.
42
Na imagem seguinte estão representadas as opções que cada tipo de utilizador tem ao
criar/editar um CET
Figura 9: Permissões por utilizador
Caso 2: Inserir horários
Só é permitido inserir horários relativos a um CET, se já estiverem definidas as datas de início
e fim do período letivo, o horário em que vão decorrer as aulas e se a data atual for inferior à
data de fim do período de aulas.
Esta operação pode ser executada pelo administrador, pelo coordenador e pelos responsáveis
de componente.
(Menu principal) Gestão->(submenu) Horários
Escolhendo o curso da lista de cursos disponíveis, a caixa de combinação no topo é carregada
com as datas dos horários existentes para esse CET. Se ainda não houver horários para esse
curso, a caixa de combinação é carregada com a data de início e fim das aulas do CET.
administrador
• Criar novo CET • Atribuir coordenador
coordenador
• Atribuir responsáveis de componente
responsável:
• Dados gerais do CET • Calendarização • Inserir/editar módulos • Inserir/editar formadores
43
Carregando em “Editar”, surge um pop-up com as datas de início e de fim preenchidas de
acordo com o selecionado inicialmente, que podem ser alteradas, garantindo o sistema que
não se alteram horários de datas passadas.
Clicando em “Ok” os botões da tabela desbloqueiam, ficando esta disponível para edição. A
tabela é construída com base no período em que vão ocorrer as aulas (por exemplo: das 16:00
às 23:00).
Carregando no botão verde correspondente ao dia da semana e hora de início pretendidos,
surge um pop-up com os elementos de escolha em caixas de combinação:
• Módulo: caixa carregada com os módulos do CET;
• Formador: caixa carregada com os formadores do módulo escolhido;
• Hora início: depende da linha que está a ser editada. Por exemplo, se foi escolhida a
linha das 18:00, a caixa é preenchida com 18:00 e 18:30.
• Hora fim: depende da hora de início. O valor mínimo é uma hora a mais do que a hora
de início, indo os restantes valores até um máximo de 4 horas, mediante intervalos de
30 minutos.
• Sala: lista de salas existentes. No caso de não existir a sala pretendida, o utilizador
pode acrescentar uma clicando no botão laranja “*”.
Depois de escolhidos os elementos, confirma-se a operação clicando em “Ok”.
Ao fazer alterações nos horários, o sistema vai criando e eliminando aulas, mantendo-se
sempre o registo das aulas previstas para os horários indicados. Estas aulas são geradas com
base no horário introduzido, as interrupções previstas e a duração da unidade de formação em
horas. Por exemplo, se uma unidade de formação com um total de 60 horas for colocada num
horário que tem a validade de 6 meses, mas se nesses 6 meses o total de horas
(correspondentes ao horário) for 100 horas, só são criadas aulas até às 60 horas.
44
Na imagem abaixo ilustra-se a janela de gestão de horários.
Figura 10: Gestão de Horários
Caso 3: inserir um sumário com marcação e justificação de faltas:
Esta é uma ação exclusiva do formador de cada aula, apesar de todos os envolvidos nesse
CET poderem visualizar a totalidade da informação relativa às aulas.
(Menu principal) Sumários
Esta janela tem 2 submenus. O submenu “Todos” dá acesso a todos os cursos e, nessa
sequência, a todas as aulas. O submenu “Meus Sumários” mostra apenas os cursos a que o
utilizador está afeto (e módulos desse utilizador, onde ele pode editar as suas aulas). O
submenu “Meus Sumários” pode assim ser visto como um filtro para aceder apenas às aulas
que o utilizador pode editar.
Ambas as opções permitem filtrar as aulas sob vários critérios para mais facilmente chegar à
opção pretendida:
• Módulo: caixa de combinação que contém todas as unidades de formação pertencentes
ao CET selecionado.
• Seleção: caixa de combinação que permite escolher por períodos temporais (Hoje,
Antigos, Todos e Restantes)
• Formador: caixa de combinação que permite filtrar por formador.
45
Estes filtros são cumulativos. No entanto, se selecionar “Meus Sumários”, o filtro
“Módulos” apenas será carregado com módulos do utilizador, ficando o filtro “Formador”
bloqueado com o nome do utilizador.
Ao clicar no editar da aula pretendida, surge a folha de sumário que contém também a
listagem de alunos para registo de faltas. Para inserir as faltas, existe uma tabela com os
alunos e o número de colunas correspondentes à duração da aula. Existem ainda mais duas
colunas no final da tabela para assinalar se o aluno faltou à aula toda e se a falta é justificada
ou não.
Para uma aula ser considerada sumariada, o utilizador tem obrigatoriamente de escrever algo
no sumário. Quando clicar em “Ok”, esta aula é atualizada e são adicionados os registos das
faltas que sejam marcadas.
Na imagem abaixo, coloca-se um exemplo da janela de preenchimento de sumário:
Figura 11 - Preenchimento de sumário
46
8 Melhoramentos futuros
Embora a aplicação desenvolvida seja ainda uma versão inicial, apresenta desde já um grande
potencial como ferramenta para gestão dos Cursos de especialização tecnológica.
Existem diversas funcionalidades que poderão ser implementadas para melhorar globalmente
a aplicação.
Uma dessas funcionalidades a implementar, e que seria uma mais valia para a aplicação, seria
a importação dos dados dos alunos já seriados directamente dos ficheiros provenientes da
secretaria. Com esta funcionalidade os dados dos alunos são inseridos de forma automática,
reduzindo assim o tempo de carregamento dos dados dos alunos, além de que existe também
uma enorme diminuição da possibilidade de erros no carregamento desses mesmos dados.
Por forma a melhorar a interação formando - formador, deveria existir a possibilidade dos
formandos poderem enviar e-mails directamente da plataforma para os formadores dos
respectivos módulos. O formador também deveria ter possibilidade de enviar mensagens para
todos os formandos de um determinado modulo ou para um formando específico.
A dificuldade que muitos formadores têm em associar os nomes dos formandos a pessoa
poderia ser colmatada com inserção da possibilidade da aplicação permitir a inclusão da foto
de cada formando. Desta forma formadores conseguiriam reconhecer mais facilmente os seus
formandos.
Para uma mais fácil avaliação do estado de cada um dos cursos por parte dos coordenadores e
responsáveis de componente, deveria existir um módulo de estatística que lhes permitisse
consultar em qualquer momento os mais diversos dados estatísticos. Como exemplo, os dados
estáticos a retirar da aplicação poderiam ser: percentagem de aprovações por curso,
percentagem de faltas, médias finais para os diferentes cursos, evolução das notas nas várias
edições de cada CET.
47
9 Conclusões
Este projecto, devido a sua complexidade, mostrou aos autores uma realidade diferente da
sentida durante o percurso académico, onde a complexidade dos trabalhos é menor. Surgiram
algumas dificuldades que serão normais nesta fase, tais como: Gestão de versões,
cumprimento de prazos, divisão de tarefas. Também foram sentidas algumas dificuldades
iniciais em parte das ferramentas utilizadas, mas considera-se que a utilização destas
ferramentas, que não fazem parte do plano de estudos do curso enriquecerá percurso
profissional futuro dos autores.
Este trabalho implicou o desenvolvimento de uma aplicação, desde a fase de levantamento e
análise de requisitos até a sua implementação. Ficou claro que um bom planeamento inicial e
um levantamento de requisitos o mais detalhado possível é essencial para o correcto
desenvolvimento de aplicações.
Ao desenvolver esta aplicação, foi fulcral a realização de uma implementação o mais modular
possível, para que a mesma seja mais facilmente mantida ou melhorada futuramente sem a
necessidade de refazer grande parte do código. Relativamente à escolha das tecnologias web
utilizadas, nomeadamente a framework ASP.NET, considera-se uma decisão correcta porque
permitiu um desenvolvimento célere e eficaz da aplicação.
Foi dada uma especial atenção à interface gráfica da aplicação, por forma a tornar a sua
utilização o mais amigável possível. Considera-se que ficou com um aspecto simples,
moderno e eficiente, faltando todavia alguns pormenores, tais como avisos visuais aos
utilizadores nas tarefas mais demoradas, compatibilização com os diversos browsers do
mercado e ajustes da aplicação a diferentes resoluções de ecrãs.
Nem todos os requisitos iniciais foram cumpridos, mas foi definido como meta implementar
as funcionalidades essenciais para a aplicação poder ser utilizada. Por outro lado, algumas
mudanças foram surgindo ao longo do período de desenvolvimento do projeto, o que levou a
que fossem idealizadas e implementadas soluções não previstas inicialmente. Como em todos
os trabalhos de desenvolvimento, estas aplicações são tarefas inacabadas e abertas a melhorias
e adaptações às necessidades emergentes.
48
49
Referências
Bilal Haidar (2008). Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB. Wrox.
Julia Lerman (2009). Programming Entity Framework Building Data Centric Apps with the ADO.NET Entity Framework. O’Reilly.
Decreto Lei nº 99/2006 de 23 de Maio. Diário da República I Série A.
Microsoft: Building Secure ASP.NET Applications - Authentication, Authorization, and Secure
Communication
http://www.microsoft.com/en-us/download/details.aspx?id=19032
(Verificado a Outubro de 2011)
Microsoft: Asp.Net Web Page – Entity Framework Tutorials
http://www.asp.net/web-forms/tutorials/getting-started-with-ef
http://www.asp.net/web-forms/tutorials/continuing-with-ef
(Verificado a Outubro de 2011)
Modelo de layout do site
http://www.netdreams.co.uk/index.php/blog/2010/02/18/free-admin-skin-available-for-download/
(Verificado a Maio de 2011)
Exemplos vários de código
http://www.codeproject.com
(Verificado regularmente)
Razões para usar o linq
http://www.linhadecodigo.com.br/artigo/2321/dez-razoes-para-adotar-o-linq-nas-aplicacoes-net.aspx
(Verificado a Junho de 2011)
Microsoft: 101 LINQ Samples
http://code.msdn.microsoft.com/101-LINQ-Samples-3fb9811b
(Verificado a Junho de 2011)
Css para AJAX Calendar Extender
http://www.aspdotnet-suresh.com/2010/07/customized-css-styles-for-ajax-calendar.html
(Verificado a Maio de 2011)
Mudar CSS em runtime
http://stackoverflow.com/questions/628115/dynamically-changing-css-style-in-c
(Verificado a Junho de 2011)
Css para ajax TabContainer
http://www.ezineasp.net/post/ASP-Net-AJAX-Tab-Extender-CSS-Class-Styles.aspx
(Verificado a Junho de 2011)
Menus com submenus
http://www.videoaulasbrasil.com.br/tableless/criando-menu-com-submenu-na-horizontal-css-parte-1/
(Verificado a Junho de 2011)
Directrizes de layout HTML
http://msdn.microsoft.com/pt-br/library/95xdeeha(v=vs.90).aspx
(Verificado a Junho de 2011)
50
Vídeos vários sobre asp.net
http://www.asp.net/web-forms/videos
(Verificado regularmente)
Adicionar handler a controlos criados dinamicamente
http://forums.asp.net/t/1286956.aspx/1
(Verificado a Abril de 2012)
Adicionar linhas e colunas dinamicamente
http://msdn.microsoft.com/en-us/library/7bewx260.aspx
(Verificado a Abril de 2012)
Posicionar rodapé
http://maujor.com/tutorial/rodape-embaixo-da-janela.php
(Verificado a Junho de 2011)
Gerar CSS para menus
www.cssmenubuilder.com
(Verificado a Junho de 2011)
51
Anexo A
Modelo E-R
52
Anexo B
Modelo Físico
53
Anexo C
Resumo Requisitos
54
Neste anexo estão descritas, através de um conjunto de tabelas, para cada um dos grupos de
funcionalidades, as funcionalidades específicas identificadas em cada um dos grupos e, entre
estas, as que foram implementadas neste projecto.
Gestão de Formandos Implementação
Inserir novos formandos �
Inscrever formandos nas unidades de formação �
Escolher as unidades de formação em que os formandos são inscritos
�
Listar formandos por CET �
Editar dados do formando �
Visualizar a assiduidade nas unidades de formação �
Visualizar notas dos formandos �
Visualizar estado do formando relativamente ao CET �
Permitir que o formando consulte informação do seu interesse
�
Gestão de Utilizadores Implementação
Criar utilizadores �
Listar utilizadores �
Bloquear/desbloquear utilizadores �
Atribuir/alterar o nome de autenticação (login) a um utilizador.
�
Definir o tipo de utilizador �
Gestão de CET Implementado
Criar novo CET �
Atribuir a calendarização dos CET �
Inserir interrupções previstas ou ocasionais aos CET
Atribuir o coordenador e os diversos responsáveis de área de formação a cada um dos CET
�
Atribuir formadores às unidades de formação �
Alterar os dados dos CET �
Alterar formadores afetos às unidades de formação �
Listar formandos existentes nos CET �
Listar unidades de formação (com horas previstas e já lecionadas)
�
Listar formadores por CET com horas previstas e lecionadas.
�
55
Gestão de Aulas Implementação
Gerar folha de sumário com um conjunto de elementos pré-preenchidos
�
Escrever o sumário �
Registar e justificar faltas dos formandos �
Mostrar o total de horas já lecionadas na unidade de formação
�
Listar aulas utilizando vários critérios �
Gestão de Horários Implementação
Inserir horários �
Editar horários �
Definir em que intervalo de datas os horários estão em vigor
�
Gerar as aulas previstas a partir dos horários inseridos �
Visualizar os horários �
Gestão de Estágios Implementação
Registar as informações das empresas de acolhimento
Criar estágios
Afetar formandos aos estágios
Listar estágios utilizando vários critérios
Gestão das Avaliações Implementação
Inserir as avaliações formativa e sumativa dos formandos.
�
Aprovar/reprovar formandos as unidades de formação. �
Visualizar as avaliações dos formandos por unidade de formação.
�
Produção de Relatórios em PDF Implementação
Listagem de utilizadores. �
