SGBD20092010 - Trabalho de Programação - Enunciado Final

SGBD20092010: Trabalho de programação - enunciado final
Sistemas Gestores de Bases de Dados

◄ IrIrpara...
para... ►
Moodle ► SGBD20092010 ► Recursos ► Trabalho de programação - enunciado final
Trabalho de programação - GEMA (GEstão de Modelos de

Avaliação)
Introdução
Este trabalho consiste na implementação de uma aplicação de suporte à gestão dos modelos de avaliação,
definidos pelo regulamento de avaliação da UMa.
O regulamento de avaliação da UMa foi recentemente alterado e está em em vigor desde o início deste ano
lectivo, obrigando os docentes a definir, para cada unidade curricular (disciplina) sob a sua responsabilidade,
um esquema de avaliação respeitando um dos 4 modelos definidos pelo regulamento. Cada modelo impõe
restrições em termos dos tipos de componentes de avaliação (teórica, prática, ...), bem como os tipos de
elementos (frequências, trabalhos, ...) permitidos e número máximo dos mesmos.
Um aspecto importante deste processo de gestão é assegurar o cumprimento de uma das regras
fundamentais do regulamento, que é a proibição de haver dois elementos de avaliação de um certo ano
curricular de um curso com data para o mesmo dia.
Neste momento, o processo é realizado manualmente e de forma pouco eficiente, usando como base
ficheiros Excel preenchidos por cada docente, cuja informação é consolidada manualmente (para verificar a
existência de colisões) pelo colégio universitário.
Com esta aplicação pretende-se que o processo de definição dos esquemas de avaliação e verificação de
colisões de elementos de avaliação ocorra de forma mais automatizada.
A melhor aplicação desenvolvida pelos alunos será eventualmente usada, experimentalmente, para a gestão
dos modelos de avaliação do 2º semestre de 2009/2010 e, após período experimental, reutilizada e
integrada no SIDOC (Serviço de Informação dos Docentes) pelo GDAI (Gabinete de Desenvolvimento de
Aplicações Informáticas).
O esquema relacional da BD está disponível num ficheiro MWB do MySQL Workbench (MSWB) aqui. O ficheiro
SQL gerado a partir do esquema e pronto a importar para o XAMPP está aqui (ATENÇÃO: antes de realizar a
importação, fazer um find and replace no código SQL de "Gxx" por "Gab" em que ab é o número interno do
grupo). O esquema desenhado resultou da interacção com o colégio universitário e o GDAI, de modo a
permitir o máximo de flexibilidade futura e integração com a actual base de dados suportando o SIDOC. O
esquema é para ser escrupulosamente respeitado sendo que todos os grupos não poderão realizar alterações
ao mesmo. Este trabalho consiste apenas em programação de scripts PHP para concretizar as aplicações
pretendidas, contendo formulários e instruções SQL para inserção e visualização de dados.
No entanto, caso seja, por parte dos alunos, detectada alguma falha ou inconsistência no esquema definido,
http://moodle.dme.uma.pt/mod/resource/view.php?id=1051[07-01-2010 15:24:18]
ou observada uma possível melhoria do esquema para torná-lo mais eficaz ou flexível, deve ser colocado um
post no fórum do trabalho de programação, para que a sugestão possa ser avaliada, podendo levar a
eventual alteração do esquema base.
Clicando nas tabelas no MSWB, é possível visualizar os comentários criados para a tabela e para os atributos,
que explicam a razão de ser da tabela ou do atributo e como se relacionam com outras tabelas e/ou
atributos. Atributos óbvios (como ids) não têm comentários. A leitura atenta dos comentários é fundamental
para o esquema relacional ser bem interiorizado e percebida a lógica de relacionamento das entidades em
que os vários componentes da aplicação GEMA irão basear-se, o que por sua vez é essencial para que a
programação seja intuitiva e eficaz.
A aplicação GEMA é dividida em dois componentes principais com os nomes:
GEMA Docentes
GEMA Colegio
Cada componente é subdividida em sub-componentes, implementadas em cada ficheiro php.
Os ficheiros que implementam o primeiro componente têm de ser colocados numa pasta com nome
docentes e os que implementam o segundo numa pasta com nome colegio.
Seguem-se o conjunto de funcionalidades a implementar em cada componente. Para cada funcionalidade é

especificado o comportamento esperado da aplicação GEMA e dadas instruções ou dicas para a sua
implementação em PHP+SQL.
De acordo com o progresso demonstrado pelos alunos nas próximas duas semanas, será publicado um
enunciado final (logo após a segunda entrega intercalar), sendo seleccionadas quais as componentes que
terão de ser necessaria e completamente implementadas para obtenção de nota mínima, sendo também
especificados os requisitos para obtenção de patamares de nota mais elevados, até à nota máxima.
Em relação às componentes da aplicação GEMA, para cada sub-componente, usar como título e cabeçalho da
página HTML a string "GEMA - " seguida pelo nome do componente, por exemplo "Docentes" e pelo nome da
sub-componente. Por exemplo, no processo de inserir elemento de avaliação, a barra de título do browser
(tags <title></title>)e o cabeçalho da página HTML visualizada (tags <h1></h1>) devem mostrar:
GEMA - Docentes - Inserir elemento de avaliação
Gema Docentes
Login
Ficheiro docentes/login.php
Página inicial: o docente insere num formulário o seu email e password e submete.
Caso não estejam correctos (instruções PHP que executam query que consulta na BD o email e password
associado e verifica se corresponde à inserida) é mostrada a página incial de login com uma mensagem
informando que ou email ou a password estão errados.
Caso o email e password estejam correctos, iniciar uma sessão (de modo a manter-se sempre os dados do
docente e apenas os dados de avaliação sobre a sua responsabilidade poderem ser alterados) e invocar o
processo de listar UCs.
Listar UCs
Ficheiro docentes/listar_ucs.php
Verifica se existe um docente na respectiva variável de sessão (se não existir redirecciona para a página de
login) e mostra uma tabela com as UCs pelas quais o docente é responsável (ciclo em PHP para construir uma
tabela em HTML, listando os dados previamente obtidos numa query).
À frente de cada UC (na célula à sua direita) aparece, uma ligação que permite aceder ao processo de editar
esquema de avaliação dessa UC. Cada ligação invoca a edição do respectivo esquema pois aponta para o
ficheiro docentes/editar_esquema.php passando, pelo método GET, o ID da UC cujo esquema vai ser
editado.
Editar esquema de avaliação
Ficheiro docentes/editar_esquema.php
É verificado se a sessão contém informação do docente e se o vector GET contém o ID da UC cujo esquema
deve ser editado. Se a primeira destas condições não for satisfeita é feito um redireccionamento para a página
de login e se a segunda não for satisfeita é feito redireccionamento para a página listar_ucs
Se ambas as condições forem satisfeitas o id da UC é adicionado a uma variável de sessão, bem como o id do
modelo adoptado.
Se a UC ainda não tiver um modelo associado (query do tipo COUNT que consulta tabela esq_aval procurando
tuplo com id da UC e devolve 0), tem de aparecer um formulário que mostra o texto "Modelo de Avaliação a
adoptar" e, à frente, numa caixa de selecção do tipo "drop-down menu" os modelos disponíveis e um botão de
submissão com o texto "Escolher este modelo". Este botão invoca novamente o ficheiro editar_esquema.php
em que o mesmo deve, no início, detectar se o vector POST está a receber a submissão do modelo. Caso seja
esse o caso, deve ser inserido o respectivo tuplo na tabela esq_aval.
Havendo um modelo escolhido para esta UC (tuplo na tabela esq_aval), o componente editar_esquema realiza
o seguinte output: (exemplificado para o modelo do tipo C)
INÍCIO DE OUTPUT
Docente: Pedro Campos
Unidade curricular: Sistemas Operativos
Modelo adoptado: C (máximo de elementos permitidos: 10)
Opções:
1. [Inserir elemento de avaliação]

2. [Editar esquema de avaliação] (com opções de eliminar ou alterar elemento e atribuir, editar ou remover
notas mínimas de componentes ou conjuntos de elementos)
3. [Alterar modelo adoptado] (atenção: toda a informação entretanto associada ao esquema desta UC será
eliminada)
FIM DE OUTPUT
Nota: INÍCIO DE OUTPUT e FIM DE OUTPUT não fazem parte do output, são só para delimitar claramente o
mesmo.
Os dados no output que estão a negrito têm de ser consultados na BD.
A opção 1 é uma ligação para o componente docentes/inserir_elemento.php
A opção 2 é uma ligação para o componente docentes/visualizar_esquema.php
A opção 3 é uma ligação para o componente docentes/alterar_modelo.php
As três opções anteriores enviam o ID do esquema através do método GET
Inserir elemento de avaliação
Ficheiro docentes/inserir_elemento.php
Repetir funcionalidade de verificação de UC e docente como nas componentes anteriores e, adicionalmente,

verificar se vector GET contém id de esquema. Caso não tenha, redireccionar para editar_esquema. Caso
tenha, adicionar o id a uma variável de sessão.
Mostrar um formulário para o utilizador indicar os vários atributos de um elemento de avaliação. O atributo
esq_aval_id está na respectiva variável de sessão logo não é pedido ao utilizador. Seguem-se instruções para
cada atributo:
Tipo de elemento de avaliação
usar drop-down menu que mostra como opções os nomes da tabela tipo_elem_aval (cujos values
das opções serão ids desta tabela)
bastará uma consulta simples à tabela e um único ciclo
Tipo de componente
usar drop-down menu que mostra como opções os nomes da tabela tipo_comp (cujos values das
opções serão ids desta tabela)
bastará uma consulta simples à tabela e um único ciclo
Conjunto de elementos ao qual será associado o elemento
usar drop-down menu que mostra como opções os conjuntos definidos para o modelo adoptado tal
como especificados com a tabela conj_elem.
cada opção tem de ser uma string com o formato: Conjunto 1 (Máximo: 8) Trabalho, Defesa,
Relatório, Prova oral
serão necessários dois ciclos, cada um com uma consulta à BD, um para as várias opções (os
vários conjuntos) e um dentro de cada opção para se obter os vários tipos permitidos para cada
conjunto
os values das opções deverão ser o id do conjunto (e não o número do conjunto mostrado no
campo anterior, o qual deve ser obtido com uma variável PHP que conta o número de iterações do
ciclo)
Data
usar caixa de input simples ou esta solução ou qualquer uma outra parecida (o formato da data a
inserir pelo script PHP tem que ser convertida para o formato do MySQL: YYYY-MM-DD)
Hora
usar caixa de input simples, colocar à frente da caixa indicação de que este parâmetro é opcional
Peso
usar caixa de input simples, colocando à frente da caixa o símbolo % (1 a 50, com possibilidade de
duas casas decimais)
Nota mínima
usar caixa de input simples, colocar à frente da caixa indicação de que este parâmetro é opcional e
para usar um ponto como separador decimal
Recurso
usar radio buttons com duas alternativas (exclusivas) Sim e Não (cujos values das opções deverão
ser S ou N)
Observações
usar uma textarea para introdução de observações (a introduzir na tabela elem_obs)
Este elemento é defesa do elemento:
usar drop-down menu que mostra, como opções, uma lista dos elementos associados à UC actual
(excepto do tipo defesa), sendo mostrado o tipo de elemento seguido da data de realização do
mesmo entre parêntesis. Indicar que este campo é opcional.
Botão Submeter
A submissão volta a invocar este ficheiro sendo que, no início do mesmo, deverá haver algum if que verifica
(variável POST) se estamos no estado de submissão de um elemento. Ao ser invocada a submissão, há um
passo de validação, em que é verificado se a data, hora e peso estão a respeitar os formatos especificados. Se
não estiverem, volta a ser apresentado o formulário (com os campos já preenchidos com os dados recebidos)
e com uma mensagem especificando o campo que tem de ser corrigido. Se todos os campos estiverem OK, é
apresentada uma lista com os dados do elemento prestes a ser inserido para o utilizador confirmar e um botão
com a palabra Inserir. Esta lista deve ser um formulário com todos os campos "hidden", à excepção do botão
de Inserir. Este formulário invoca novamente o mesmo ficheiro que passa então à inserção dos dados
relevantes nas várias tabelas, usando-se uma transacção de modo a garantir a atomicidade dos INSERTS.
Visualizar esquema de avaliação
Ficheiro docentes/visualizar_esquema.php
Repetir funcionalidade de verificação de UC e docente como nas componentes anteriores e, adicionalmente,

verificar se vector GET contém id de esquema. Caso não tenha, redireccionar para editar_esquema.
É mostrado o output das três primeiras linhas da componente editar_esquema, seguindo-se o seguinte
output (novamente exemplificado para o modelo C):
INÍCIO DE OUTPUT
Trabalhadores estudantes: Estão sujeitos às mesmas regras que os alunos normais para todos os elementos
Conjuntos Componente Elementos

de a que pode
elementos pertencer
definidos e cada
respectivos elemento
tipos de
elementos
permitidos
no
conjunto e
quantidade
máxima
Conjunto 1 Prática Elemento Componente Data Hora Peso Nota Possibilidade Observação
(Máximo: 8) adoptado atribuída Mínima de recuparar
[atribuir em recurso
nota
Trabalho Prática 2009- - 20% - Não - [editar]
mínima]
Out- [apagar]
Trabalho,
31
Defesa,
Defesa Prática 2009- - 15% - Não Algumas [editar]
Relatório,
(do Nov- defesas [apagar]
Prova oral
elemento 15 poderão
de 2009- ocorrer no
Out-31) dia seguinte
Prova oral Prática 2009- 09h00 15% 10 Não Só de [editar]
Nov- manhã [apagar]
30
Conjunto 2 Prática Este conjunto não tem elementos de avaliação associados

(Máximo: 2)
[atribuir
nota
mínima]
Prova
Prática
Conjunto 3 Teórica, Elemento Componente Data Hora Peso Nota Possibilidade Observação
(Máximo: 3) Teórico- adoptado atribuída Mínima de recuparar
Nota prática, em recurso

mínima: 9,5 Prática
Projecto Teórico- 2009- - 25% 10 Sim - [editar]
[editar nota
prática Dez- [apagar]
mínima]
10
[remover
Projecto Prática 2010- - 25% - Não - [editar]
nota
Jan- [apagar]
mínima]
15
Projecto,
Defesa
A componente Prática tem nota mínima de 8 [editar nota mínima] [remover nota mínima]
A componente Teórica não tem nota mínima atribuída [atribuir nota mínima]
A componente Teórico-prática não tem nota mínima atribuída [atribuir nota mínima]
FIM DE OUTPUT
Notas:
A informação do trabalhador estudante é para ser obtida da tabela modelo

Sugestão de pseudo-algoritmo para construir tabela:
Output de tabela HTML, com o cabeçalho especificado acima
Consulta, para o modelo adoptado, dos conjuntos associados (tabelas modelo e conj_elem) e
Ciclo 1: para cada conjunto (usar função foreach do php):
iniciar linha de tabela e dentro da linha realizar:
output da 1ª coluna:
output da string conjunto, seguido do número do conjunto (usar variável que conta o número de
iterações do ciclo), seguido da indicação do máximo de elementos permitidos (atributo do actual
conjunto)
Ciclo 2: para o actual conjunto, consultar os tipos de elementos permitidos no conjunto (tabelas
conj_elem, tipo_elem_aval e conj_tipo_elem) e realizar output dos tipos, separados por vírgulas
Ciclo 3: para o actual conjunto, consultar as componentes a que pode pertencer cada elemento
associado a este conjunto e realizar output dos tipos, separados por vírgulas
Caso não hajam elementos associados a este conjunto (para a actual UC, consultar tabelas
elem_aval e conj_elem, com uma query usando COUNT, testando se é igual a zero) realizar
output da frase "Este conjunto não tem elementos de avaliação associados".
Caso hajam elementos, realizar uma consulta para obter a lista de elementos deste conjunto
(colocar num vector/matriz) e realizar output de nova tabela HTML com cabeçalho como
especificado acima e
Ciclo 4: para cada elemento, fazer output de uma linha, colocando em cada coluna o valor dos
atributos do elemento como especificado acima
fechar linha de tabela
Os pontos acima são suficientes para se considerar que esta componente (visualizar_esquema) foi
implementada com sucesso, sendo os pontos abaixo - relativos a notas mínimas e apagar e editar elementos -
incluídos nas respectivas componentes não obrigatórias para nota mínima de 10 valores.
Cada ligação [apagar] aponta para o ficheiro docentes/apagar_elem.php (passando por GET o id do
elemento) que por sua vez mostra uma página a pedir confirmação ao utilizador para a remoção do
respectivo elemento. Após confirmação é realizado o DELETE necessário (verificar se a funcionalidade de
CASCADE funciona) e indicado se houve sucesso ou não na operação, sendo mostrada uma ligação para
voltar a visualizar o esquema.
Cada ligação [editar] aponta para o ficheiro docentes/editar_elem.php (passando por GET o id do
elemento) que por sua vez mostra uma página idêntica à da sub-componente inserir_elemento mas já
preenchida com os valores do respectivo elemento, sendo possível editar os mesmos sendo o
comportamento idêntico ao da operação de inserir.
Na coluna dos conjuntos de elementos, as ligações:
[atribuir nota mínima] apontam para o ficheiro docentes/n_min_conj_atrib.php (passando por
GET o id do conjunto de elementos) que por sua vez mostra uma página onde é possível colocar,
numa caixa de input simples, a nota mínima (mostrar ao utilizador o formato a usar). Após
submissão, validar se está a ser usado um ponto, realizar o INSERT necessário e mostrar se a
operação ocorreu com sucesso ou insucesso, mostrando uma ligação para voltar a visualizar o
esquema.
[editar nota mínima] apontam para o ficheiro docentes/n_min_conj_edit.php (passando por GET
o id do conjunto de elementos) com um comportamento idêntico ao do ponto anterior, com a
diferença de aparecer pré-preenchido o respectivo valor.
[remover nota mínima] apontam para o ficheiro docentes/n_min_conj_remov.php (passando por
GET o id do conjunto de elementos) que por sua vez mostra uma página com a nota mínima
atribuída e a pedir confirmação ao utilizador se deseja mesmo eliminar esta nota mínima. Em caso
de confirmação é realizado o DELETE necessário e mostrado o sucesso ou insucesso da operação,
seguido de uma ligação para voltar a visualizar o esquema.
Após output da tabela realizar novo ciclo que realiza o output de eventuais notas mínimas atribuídas a
um tipo de componente em que as ligações relativas a nota mínima para componentes têm um
comportamento idêntico aos do ponto anterior, sendo que nos nomes dos ficheiros é para usar comp em
vez de conj.
Alterar modelo adoptado
Ficheiro docentes/alterar_modelo.php
É perguntado ao utilizador se quer realmente alterar o modelo adoptado, relembrando que toda a informação
do esquema de avaliação actualmente associada à UC será eliminada. Em caso de confirmação, realizar os
DELETE necessários (confirmar funcionamento dos CASCADE) nas respectivas tabelas e informar do sucesso
ou insucesso da operação, apresentando, em caso de sucesso, um formulário que mostra o texto "Modelo de
Avaliação a adoptar" e, à frente, numa caixa de selecção do tipo "drop-down menu" os modelos disponíveis e
um botão de submissão com o texto "Escolher este modelo". Este botão invoca o ficheiro
editar_esquema.php em que o mesmo deve, no início, detectar se o vector POST está a receber a submissão
do modelo. Caso seja esse o caso, deve ser inserido o respectivo tuplo na tabela esq_aval.
Gema Colégio
Editar Modelo de Avaliação
Ficheiro colegio/editar_modelo.php
Caso não haja nenhum id de modelo na sessão ou no vector GET, mostra uma tabela com os modelos
definidos (com colunas mostrando os vários atributos da respectiva tabela) e uma coluna com uma ligação
para editar um certo modelo (passando pelo método GET o id do modelo).
Caso haja um id de modelo no vector de GET mas não na respectiva variável de sessão, adicionar esse ID a
uma variável de sessão e fazer output com o seguinte formato:
Edição do modelo A
Conjuntos de Tipos de elementos Componentes a que podem Máximo de Opções

elementos permitidos no conjunto pertencer elementos do conjunto elementos
Conjunto 1 Frequência Teórica, Teórico-prática 3 [Editar]

[Apagar]
Conjunto 2 Miniteste, Trabalho, Defesa, Teórica, Teórico-prática 5 [Editar]
Relatório, Prova oral [Apagar]
[Adicionar Conjunto]
Notas:
O número de conjunto na primeira coluna não é o id do conjunto, mas apenas o valor de uma variável
contando as iterações do ciclo de output da tabela.
Caso o modelo não tenha conjuntos associados, aparece apenas a ligaçao [Adicionar Conjunto].
As ligações [Editar] e [Apagar] passam, por método GET, o ID do conjunto.
A ligação [Editar] invoca o ficheiro colegio/conj_mod_editar.php passando por método GET o id do
conjunto,
A ligação [Apagar] invoca o ficheiro colegio/conj_mod_apagar.php passando por método GET o id do
conjunto, o qual por sua vez vai mostrar os dados do conjunto e o modelo a qual pertence, perguntando por
confirmação da eliminação deste conjunto. Em caso afirmativo é feito os DELETEs necessários. Em caso
negativo volta à página editar_modelo.
A ligação [Adicionar Conjunto] invoca o ficheiro colegio/conj_mod_criar.php o qual por sua vez mostra um
drop-down menu para ser indicado o máximo de elementos do conjunto a ser criado (opções possíveis: 1 a 9),
seguida de um botão com o nome "Criar conjunto". Ao carregar-se no botão é mostrada uma página de
confirmação e em caso de confirmação é realizado o respectivo INSERT e depois mostrada uma ligação para
voltar à edição de modelo.
Editar Conjunto de elementos de Modelo de Avaliação
Ficheiro colegio/conj_mod_editar.php
Verifica se há um id de modelo na variável de sessão, se não houver mostra mensagem de erro e ligação para
voltar à página de editar modelo.
Verifica se há um id de conjunto no vector de GET, se não houver volta à página de editar modelo. Se houver,
faz output das seguintes tabelas com o seguinte formato:
Edição de conjunto do Modelo A

Máximo de elementos permitido neste conjunto: 3 [Alterar máximo]
Tipos de elemento permitidos no conjunto opção

Miniteste [Apagar]
Trabalho [Apagar]
Defesa [Apagar]
Relatório [Apagar]
Prova oral [Apagar]
[Adicionar tipo de elemento]
Notas para esta tabela:
As ligações [Apagar] apontam para o ficheiro colegio/conj_mod_tipo_elem_remov.php que recebe por GET
os ids do conjunto e do tipo de elemento e realiza o DELETE necessário. Antes do DELETE é pedida
confirmação ao utilizador e após o DELETE é mostrado mensagem de sucesso ou insucesso na operação, com
uma ligação para voltar à edição do conjunto (passando por GET o id do conjunto).
A ligação [Adicionar tipo de elemento] aponta para o ficheiro colegio/conj_mod_tipo_elem_adic.php que

recebe por GET o id do conjunto e mostra um drop-down onde é possível seleccionar um dos vários tipos
ainda não associados ao conjunto (ou seja será necessário uma query usando, por exemplo, NOT IN) e um
botão com o nome "Adicionar". Ao carregar-se no botão é mostrada página de confirmação e, após realização
do INSERT necessário, é mostrada ligação para voltar à edição do conjunto (passando por GET o id do
conjunto).
A ligação [Alterar máximo] aponta pra o ficheiro colegio/conj_mod_editar_max.php que recebe por GET o
id do conjunto e mostra um drop-down idêntico ao do ficheiro conj_mod_criar.php, com um botão que ao
ser carregado leva à realização do respectivo UPDATE, sendo depois mostrada uma ligação para voltar à
edição do conjunto (passando por GET o id do conjunto).
Tipos de componente a que podem pertencer elementos do conjunto opção

Teórica [Apagar]
Teórico-prática [Apagar]
[Adicionar tipo de componente]
Notas para esta tabela:
Implementar um comportamento idêntico ao definido para a tabela anterior, em que, nos nomes dos ficheiros,
em vez de elem é para usar comp.
[Voltar à edição de modelo]
Notas:
Se o conjunto não tiver tipos associados a cada tabela é mostrado só o cabeçalho da mesma
A ligação [Voltar à edição de modelo] aponta para o respectivo ficheiro.
Listar colisões
Ficheiro colegio/listar_colisoes.php
Para cada curso e para cada ano curricular, gerar uma lista de colisões entre elementos de avaliação de
disciplinas diferentes desse mesmo ano marcados para o mesmo dia, seguindo o formato da seguinte tabela:
Curso Ano Datas elementos a colidir e dados das UCs e docentes

curricular
Licenciatura em 3 2010-01- UCs Elementos Docentes Emails
Engenharia 14 Sistemas Gestores de Bases Frequência David daveiro@uma.pt
Informática [resolver de Dados [alterar data] Aveiro
colisão]
Sistemas Operativos [alterar Projecto Pedro pcampos@uma.pt
data] Campos
Engenharia 17 Sistemas de Apoio à Frequência David daveiro@uma.pt
Informática [resolver Decisão [alterar data] Aveiro
colisão]
Engenharia de Requisitos Projecto Pedro pcampos@uma.pt
[alterar data] Campos
Engenharia Civil 23 Sistemas Gestores de Oral David daveiro@uma.pt
[resolver Semáforos [alterar data] Aveiro
colisão]
Sistemas Escavadores Frequência Pedro pcampos@uma.pt
[alterar data] Campos
Notas:
As ligações [resolver colisão] apontam para a sub componente resolver_colisao, passando por GET os ids dos
elementos.
As ligações [alterar data] apontam para a sub componente alterar_data_elem_uc, passando por GET o ID do
elemento
À semelhança da sub componente visualizar_esquema, para construir esta tabela, será necessário
aninhamento de ciclos, cada um com uma ou mais queries SQL e com output de tabelas dentro de células da
tabela principal (por exemplo a célula à frente de 2010-01-14 contém uma tabela com 3 linhas e 4 colunas).
Resolver colisão entre elementos de avaliação
Ficheiro colegio/resolver_colisao.php
É gerada uma tabela contendo 7 colunas (uma para cada dia da semana) e, em cada célula, aparece a data
seguida de ":" seguindo-se:
caso o dia tenha elementos marcados, a lista de elementos de UCs (do mesmo ano curricular do mesmo
curso dos ids recebidos no vector GET) marcada para esse dia, separados por ponto e vírgula
caso contrário, a expressão "livre!" seguida da frase "Alterar para esta data a [UC1] [UC2]". Em que UC1
e UC2 são ligações para o ficheiro colegio/alterar_data_elem_uc.php sendo passado por GET o id do
elemento da respectiva UC e a data do respectivo dia.
segunda- terça- quarta- quinta-feira sexta-feira sábado domingo

feira feira feira
... ... ... ... ... ... ...
... ... ... ... ... ... ...
... ... ... 2009-01-14: Sistemas 2009-01-15: ... ...
Gestores de Bases de livre!
Dados (Frequência) Alterar para esta
data o elemento
da [UC1] [UC2].
... ... ... ... ... 2009-01-23: UC1 - Sistemas ...
Gestores de Semáforos (Oral); UC2
- Sistemas Escavadores
(Frequência)
... ... ... ... ... ... ...
... ... ... ... ... ... ...
... ... ... ... ... ... ...
Esta tabela mostra as linhas respectivas a N semanas atrás e à frente da semana onde ocorre a colisão e tem
por objectivo dar uma visão das melhores alternativas de escolha de uma nova data para uma das UCs a
colidir
O valor padrão de N é 3.
N tem de ser um parâmetro definido num único local no código, de modo que possa ser possível alterá-
lo facilmente para aumentar ou diminuir a "visão" das marcações na vizinhança da colisão.
Uma possibilidade é aparecer uma opção de drop-down antes da tabela onde é possível mudar o valor
de N e, ao carregar num botão, a página volta a ser invocada com o novo valor de N.
Na tabela acima é apresentado apenas um exemplo de cada uma das três possibilidades (dia livre, dia só com
uma marcação, dia com colisão) sendo que na implementação a tabela terá de estar totalmente preenchida.
Alterar data de elemento de avaliação
Ficheiro colegio/alterar_data_elem_uc.php
Caso não seja recebido no vector GET uma data, aparece uma caixa de input para o utilizador seleccionar a
nova data para o elemento da UC recebido por GET. Caso seja recebido no GET, além da UC, um valor de
data este passo de seleccção não é realizado.
É perguntado ao utilizador se confirma a alteração do elemento em questão para a data indicada. Carregando
no botão de confirmação é indicado se a operação ocorreu com sucesso ou não, sendo mostrado uma ligação
para voltar ao componente de listar colisões.
Inicializar semestre
Ficheiro colegio/inicializar_semestre.php
Seguem-se um conjunto de opções que deverão ser listadas ao ser executada esta sub-componente
Backup
Caso existam dados na BD, realizar backup, sendo que, através de PHP deverá ser exportado todo o
conteúdo da BD (estrutura e dados) para um ficheiro a ser descarregado para o PC do utilizador
Limpar dados de UCs e elementos de avaliação
Realizar TRUNCATE table (esvaziar) em todas as tabelas excepto as que guardam os dados dos modelos
de avaliação (modelo, conj_elem, conj_tipo_elem, tipo_elem_aval, conj_tipo_comp, tipo_comp)
Importar dados de UCs
Apresentação de um formulário para realização de upload de um ficheiro SQL (dados exportados do
SIDOC)
para obter o ficheiro SQL, simular exportação de dados do SIDOC, criando (usando phpmyadmin ou
um script PHP) um ficheiro SQL com INSERTS com dados das tabelas docente,
docente_resp_ed_ec, ed_uc, ed_uc_curso, curso
Inicializar docentes
Gerar passwords aleatórias para cada docente e enviar email para cada docente com a sua password
informando que pode fazer login na GEMA
seguir instruções para configuração de envio de emails aqui (para Windows) ou aqui (para Linux)
usar o servidor SMTP da UMa (realizar testes só com endereços da UMa, por exemplo do domínio
max.uma.pt)
parâmetros para a mensagem:
remetente: colegiouniversitario@uma.pt
assunto: password para login no programa de Gestao de Modelos de Avaliacao
texto da mensagem: Caro/a $nome_docente,##1 LINHA EM BRANCO##pode desde já
realizar login na aplicação de Gestão de Modelos de Avaliação acedendo ao endereço
especificado na comunicação anterior e usando como nome de login o seu endereço de email
e como password: $password##1 LINHA EM BRANCO##Saudações Académicas,##1 LINHA
EM BRANCO##O colégio universitário
Observações
As Notas: não são para constar do output, são só especificação de comportamento.
Ler com atenção a secção abaixo sobre o registo de trabalho, prazos e regras de entrega
Tendo em conta o esquema relacional
As tabelas acima de esq_aval são para ser preenchidas manualmente no phpMyAdmin com exemplos
suficientes para testar a aplicação.
As tabelas modelo, conj_elem, tipo_comp, tipo_elem_aval, conj_tipo_comp e conj_tipo_elem são
também para serem preenchidas manualmente no phpMyAdmin usando informação da ficha de modelos
de avaliação disponível aqui.
Criar e reutilizar funções declaradas num ficheiro comum, por exemplo: comum.php, onde pode estar uma
função que verifica se a variável de sessão contém informação do docente e se não tiver redirecciona para a
página de login. Todos os ficheiros php na pasta docentes devem começar com esta verificação.
Os ficheiros relativos a componentes que executam várias funções, devem ter uma estrutura com vários if e
else, que verificam certas variáveis de modo a avançar para uma certa parte do processo, cuidado com as
verificações para não se saltarem passos sem querer ou se executarem passos que não deveriam ser
executados!
Quando uma tabela contiver no comentário: "ESPECIFICAR O CONJUNTO DE ATRIBUTOS QUE SÃO CHAVE
ESTRANGEIRA COMO SENDO UNIQUE" o SQL final do trabalho tem de conter esta restrição (o MySQL
Workbench não possibilita a especificação da cláusula UNIQUE).
Valores atribuídos às funcionalidades implementadas com sucesso
10 valores (Funcionalidades mínimas obrigatórias)
docentes/login.php
docentes/listar_ucs.php
docentes/editar_esquema.php
docentes/inserir_elemento.php
docentes/visualizar_esquema.php
colegio/listar_colisoes.php
colegio/alterar_data_elem_uc.php
As funcionalidades à frente não são obrigatórias para nota mínima.
1 valor
docentes/apagar_elem.php
docentes/editar_elem.php
docentes/alterar_modelo.php
2 valores
docentes/n_min_conj_atrib.php
docentes/n_min_conj_edit.php
docentes/n_min_conj_remov.php
docentes/n_min_comp_atrib.php
docentes/n_min_comp_edit.php
docentes/n_min_comp_remov.php
3 valores
colegio/editar_modelo.php
colegio/conj_mod_criar.php
colegio/conj_mod_editar_max.php
colegio/conj_mod_apagar.php
colegio/conj_mod_editar.php
colegio/conj_mod_tipo_elem_remov.php
colegio/conj_mod_tipo_elem_adic.php
colegio/conj_mod_tipo_comp_remov.php
colegio/conj_mod_tipo_comp_adic.php
2 valores
colegio/resolver_colisao.php
2 valores
colegio/inicializar_semestre.php
Registo de trabalho, prazos e regras para entregas

De forma semelhante ao trabalho de modelação, o trabalho de programação tem a obrigatoriedade de entrega
de relatórios de trabalho intercalares até à entrega do relatório final.
Tendo em conta que:
até à época complementar, tirando este trabalho, resta apenas a 3ª frequência,
a data de entrega do relatório final é a 19 de Janeiro (daqui a 7 semanas)
haverão 2 semanas de férias, e
é reservada uma semana para estudo para a frequência,
é exigido, para este trabalho, a realização de um mínimo equivalente a 4 semanas de trabalho, em que devem
ser dedicadas, por cada aluno, pelo menos as 10h de trabalho semanais previstas por disciplina. Isto significa
que cada aluno deverá dedicar a este trabalho, pelo menos, um total de 40h. Como a natureza deste trabalho
facilita a divisão de tarefas, é exigido que pelo menos 75% do trabalho de cada aluno seja feito
individualmente. Assim espera-se que cada aluno realize, pelo menos, 30h de trabalho individual e 10h em
grupo, o que implica um total de, pelo menos, 100h de trabalho que terão de estar registados no relatório
final.
De modo a facilitar o planeamento de carga do trabalho dos alunos de cada grupo com as várias disciplinas, o
trabalho poderá ser dividido pelos elementos do grupo de forma a concentrar, para cada um, o respectivo
trabalho nas datas mais convenientes. No entanto, é obrigatório que, até à primeira entrega intercalar, cada
aluno trabalhe, pelo menos, 8h.
Cada grupo tem de realizar o registo de trabalho numa folha de cálculo num Google Spreadsheet realizando
um upload para o Google Docs do ficheiro disponível aqui.
O ficheiro disponibilizado tem entradas a exemplificar a satisfação do mínimo de trabalho para a primeira
entrega intercalar (8h de trabalho de cada aluno, sendo 2h em grupo).
Antes do upload é necessário renomear o ficheiro substituindo o XX pelo número do grupo e alterando os
números de aluno (internos) para os do grupo em questão. Após o upload realizado por um dos
elementos do grupo é necessário o mesmo ser partilhado em modo de edição com os restantes membros
do grupo e também com o docente (usar este endereço: daveiro@gmail.com).
As entradas dos segmentos de trabalho são para ser colocadas no respectivo spreadsheet por ordem
sequencial temporal do trabalho efectivamente realizado, sendo as entradas de trabalho individual
colocadas pelo respectivo aluno.
Para a informação do cabeçalho ficar sempre fixa, usar a opção de "congelar linhas de cabeçalho"
bastando para isso clicar no quadradinho com riscas cinzentas diagonais logo acima do número 1 (da
linha 1) e arrastar a divisória até encontrar-se entre a linha 7 e 8 como mostra este screenshot.
Prazos de entrega
Intercalares
RT 12 - 12/Dezembro - 23h59 (obrigatória)
RT 14 - 9/Janeiro - 23h59 (opcional - bónus de 1 valor caso todos os alunos do grupo tenham realizado
um mínimo de 20h de trabalho)
Final
RT 15 - 19/Janeiro - 23h59
Regras para o relatório
Cada relatório intercalar a ser entregue (seguindo o template disponibilizado) tem apenas de ter uma cópia
dos segmentos de trabalho realizados, exceptuando o final, cujo formato será oportunamente anunciado.
Regras para a entrega
Junto com a mensagem de e-mail, respeitando o assunto definido nas regras de entrega dos RTs e, contendo
em anexo o relatório de acordo com o template (seguir o formato das tabelas do Google Spreadsheet), tem
de ser enviado um ficheiro, com o mesmo nome, mas extensão .zip, contendo os ficheiros php codificados,
bem como um ficheiro sql contendo todo o código de criação das tabelas e dados já existentes
(Export/Dump da BD).
Última alteração: Terça, 5 Janeiro 2010, 17:19
Nome de utilizador: André Sousa. (Sair)

<> <>

SGBD20092010 - Trabalho de Programação - Enunciado Final

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

SGBD20092010 - Trabalho de Programação - Enunciado Final

Transféré par

Droits d'auteur :

Formats disponibles

SGBD20092010: Trabalho de programação - enunciado final

Sistemas Gestores de Bases de Dados

Moodle ► SGBD20092010 ► Recursos ► Trabalho de programação - enunciado final

Trabalho de programação - GEMA (GEstão de Modelos de

A aplicação GEMA é dividida em dois componentes principais com os nomes:

Cada componente é subdividida em sub-componentes, implementadas em cada ficheiro php.

Seguem-se o conjunto de funcionalidades a implementar em cada componente. Para cada funcionalidade é

GEMA - Docentes - Inserir elemento de avaliação

Editar esquema de avaliação

1. [Inserir elemento de avaliação]

Inserir elemento de avaliação

Repetir funcionalidade de verificação de UC e docente como nas componentes anteriores e, adicionalmente,

Visualizar esquema de avaliação

Repetir funcionalidade de verificação de UC e docente como nas componentes anteriores e, adicionalmente,

Conjuntos Componente Elementos

Conjunto 2 Prática Este conjunto não tem elementos de avaliação associados

Nota prática, em recurso

A informação do trabalhador estudante é para ser obtida da tabela modelo

Alterar modelo adoptado

Editar Modelo de Avaliação

Conjuntos de Tipos de elementos Componentes a que podem Máximo de Opções

Conjunto 1 Frequência Teórica, Teórico-prática 3 [Editar]

Editar Conjunto de elementos de Modelo de Avaliação

Edição de conjunto do Modelo A

Tipos de elemento permitidos no conjunto opção

Notas para esta tabela:

A ligação [Adicionar tipo de elemento] aponta para o ficheiro colegio/conj_mod_tipo_elem_adic.php que

Tipos de componente a que podem pertencer elementos do conjunto opção

Notas para esta tabela:

[Voltar à edição de modelo]

Curso Ano Datas elementos a colidir e dados das UCs e docentes

Resolver colisão entre elementos de avaliação

segunda- terça- quarta- quinta-feira sexta-feira sábado domingo

Alterar data de elemento de avaliação

Valores atribuídos às funcionalidades implementadas com sucesso

10 valores (Funcionalidades mínimas obrigatórias)

As funcionalidades à frente não são obrigatórias para nota mínima.

Registo de trabalho, prazos e regras para entregas

Regras para o relatório

Regras para a entrega

Última alteração: Terça, 5 Janeiro 2010, 17:19

Nome de utilizador: André Sousa. (Sair)

Vous aimerez peut-être aussi