Regras de Inscrição
Constituição de Grupos
O projecto é realizado em grupos de 9 alunos. Por forma a permitir a divisão de trabalho e uma avaliação o mais independente possível entre as disciplinas de SD e ES, existem regras na constituição dos grupos, que os alunos têm que seguir.
Os 9 elementos de cada grupo têm de ser todos do mesmo tipo:
- Alunos inscritos apenas em SD;
- Alunos inscritos apenas em ES;
- Alunos inscritos em SD e ES.
O processo de constituição dos grupos deverá ser o seguinte:
- Constituir um conjunto de 3 alunos todos do mesmo tipo;
- Constituir um grupo de 9 alunos com base em 3 conjuntos de 3 alunos todos do mesmo tipo;
- Escolher o turno de laboratório de ES para o grupo de 9;
- Escolher o turno de laboratório de SD para o grupo de 9.
Em resumo, os alunos têm que trabalhar com colegas nas mesmas condições de inscrição e que frequentam o mesmo turno de laboratório. Não serão aceites grupos que não respeitem as regras de constituição enunciadas.
Alunos com inscrição por regularizar
Todos os alunos têm que estar inscritos no sistema Fénix nas disciplinas que pretendem realizar. Para quem se encontra em situação irregular, é possível inscrever-se oficiosamente indo ao "Portal do Estudante" e seleccionando a opção "Turmas". Deve ler com atenção a parte final onde se refere "escolher disciplinas extra-inscrição". Ao seguir essa ligação é possível proceder à inscrição na disciplina (sem valor oficial, apenas para efeitos de inscrição em avaliações e agrupamentos).
Inscrição de Grupos nos turnos de laboratório
Cada grupo de 9, constituído segundo as regras anteriormente enunciadas, deve em seguida inscrever-se nos turnos de laboratório das disciplinas que pretende realizar.
A inscrição de um grupo num turno é realizada no sistema Fénix. Para tal devem usar a funcionalidade Inscrição em Grupo disponível no Portal do Estudante. Para os grupos de alunos inscritos simultaneamente em SD e ES, é necessário garantir que o grupo tem a mesma constituição nos turnos das duas disciplinas. Serão eliminadas as inscrições de grupos que não respeitem esta regra.
Alunos que não conseguem constituir Grupo
Os alunos que não conseguem constituir grupo nas condições exigidas devem inscrever-se num de três grupos auxiliares:
- Sem grupo (apenas SD);
- Sem grupo (apenas ES);
- Sem grupo (SD e ES).
Esta inscrição tem dois propósitos:
- Permitir a um aluno saber quem se encontra na mesma situação, o que lhe permite contactar outros colegas com quem possa constituir grupo.
- Garantir ao aluno que terá um grupo para realizar o projecto pois, se necessário, os alunos nestes grupos serão agrupados pelo corpo docente, após o fim das inscrições.
ATENÇÃO: Alunos que não se inscrevam num grupo não poderão realizar o projecto.
Enunciado base
Está disponível o enunciado base do projecto conjunto de SD e ES.Enunciado base
Está disponível o enunciado base do projecto conjunto de SD e ES.Regras de utilização de CVS
Em anexo encontram-se as regras de utilização de CVS que devem seguir ao longo do desenvolvimento do projecto conjunto de SD e ES.1º Enunciado
Está disponível o 1º enunciado detalhado de ES.
A constituição e a identificação de cada um dos sub-grupos segue as mesmas regras da cadeira de Sistemas Distribuídos (também descritas no enunciado).
Consultem com atenção as regras de utilização do repositório de CVS e a forma como deve ser efectuada a entrega.
O trabalho a desenvolver deve partir do código base fornecido. Devem obter a versão mais recente do ImportAnt da sua página oficial. Os restantes ficheiros usados nas aulas de laboratório não devem ser utilizados. Cada grupo é responsável por colocar no seu módulo do repositório CVS os ficheiros na estrutura pedida.
De modo a que todos os alunos possam aprender com as dúvidas dos colegas, as dúvidas de projecto devem ser colocadas no fórum da cadeira, onde serão respondidas pelo corpo docente. Assim, dúvidas de projecto não serão respondidas por e-mail.
Como representar colecções em JSP
O documento
Seleccionar um elemento de uma colecção exemplifica três formas distintas de apresentar uma colecção de elementos, e invocar operações tendo em conta o elemento seleccionado. Não sendo as únicas formas possíveis, são as consideradas mais úteis para o projecto desta cadeira.
Cada uma das formas terá as suas vantagens e desvantagens, dependendo do requisito que se pretenda satisfazer, pelo que caberá a cada um decidir a que melhor se adequa às necessidades.
Correcção ao código base do 1º enunciado
Estão disponíveis correcções para permitir fazer testes de serviço que verificam o estado de Document, EditorialDocument e DocumentInformation.
As correcções acrescentam ainda o tratamento de excepções que estavam em falta, relacionadas com a gestão de utilizadores de uma equipa.
Aconselha-se a confirmação prévia de que os ficheiros actualizados não se sobrepõe a alterações que possam ter entretanto realizado (nenhum dos ficheiros actualizados precisaria à partida de ser modificado para a solução deste enunciado).
2º Enunciado
Está disponível o 2º Enunciado.
O código base código base para a 2ª entrega.
O Serviço de Identidade para ser usado por quem não está a fazer SD (ou não quer ficar dependente do código realizado em SD).
O ImportAnt inclui a versão mais recente do ImportAnt.
As novas bibliotecas necessárias para a invocação remota dos serviços de SD. É um complemento às extensões da 1ª entrega.
Para tudo funcionar integrado:
- descomprimir os quatro zips para o mesmo sítio.
- descomprimir o extensions.zip da 1ª entrega para o mesmo sítio usado em 1.
- no directório SIdentidade_Local, lançar a aplicação e publicá-la no serviço de nomes: ant deploy ws-publish
- no directório Portal, lançar a aplicação e gerar a BD: ant generate-db-schema deploy
- aceder a http://localhost:8080/Portal e seleccionar o link "Update Services" (deve aparecer a verde o serviço "OurDocs SIdentidade"
- logins válidos u1@alameda.pt a u4@alameda.pt (passwords a1 a a4) e u1@tagus.pt a u4@tagus.pt (passwords t1 a t4)
Estão disponíveis correcções para que o Portal se comporte correctamente quando introduzem uma identidade inválida no formulário de login (identidade sem o símbolo "@").
Aconselha-se a confirmação prévia de que os ficheiros actualizados não se sobrepõe a alterações que possam ter entretanto realizado (classes User e IdentityRemoteService do domínio).
Está disponível uma nova
correcção
para que os testes de serviço disponibilizados se comportem correctamente.
Aconselha-se a confirmação prévia de que os ficheiros actualizados não se sobrepõe a alterações que possam ter entretanto realizado (classe RemoteService do domínio, e ficheiros /OurDocs/Portal/ build.xml e /OurDocs/Portal/config/tests/Portal.xml).
3º Enunciado
Está disponível o 3º enunciado detalhado de ES.
O trabalho a desenvolver deve partir do código desenvolvido como solução do 2º enunciado. Devem obter a versão mais recente do ImportAnt da sua página oficial.
Até às 20h de dia 29/Maio deve ser enviado um e-mail com a estimativa do grupo (ver enunciado para mais informação)
O planeamento desta entrega deve ser feito numa nova Release (chamada 3a-entrega), com uma única Iteration (chamada iteracao-unica).
Nota: Alterações a qualquer parte do planeamento da 2ª entrega invalida a sua avaliação e são da exclusiva responsabilidade do grupo.
Planeamento no 3º Projecto
Algumas notas sobre como fazer planeamento no 3º projecto:
- Identificar claramente a lógica de negócio no domínio na tarefa de D-DML+T. Por exemplo, "Apenas o criador pode submeter o seu documento". Desta lógica de negócio deve-se inferir casos de teste de domínio ( todos os casos de teste de domínio devem estar relacionados com alguma regra de lógica de negócio). Adicionalmente cada regra de lógica de negócio deve corresponder a métodos de validação.
- De uma forma sistemática, identificar os cenários secundários: um por cada negação de uma pré-condição. Mas atenção que se a sequência de écrans impedir chegar lá nao vale a pena descrevê-lo. Por exemplo, não interessa descrever o cenário de criação do documento, em que o utilizador tenta criar um documento numa equipa a que não pertence pois a interface proibe isso. Esta informação deve sim ser usada para descrever lógica de negócio no domínio de forma a que uma excepção seja lançada se alguém tentar saltar para o link directamente.
- Os casos de uso não necessitam de ser descritos a partir do login. Indiquem na pré-condição que já se encontram num determinado ponto da interface no início do caso de uso.
- Os casos de teste de aceitação devem estar explicitamente relacionados as pré-condições do caso de uso. Os valores de entrada do caso de teste deve corresponder a valores que tornam as pré-condições verdadeiras ou falsas (usar classes de valores, como explicado na aula teórica).
- Os casos de teste devem indicar explicitamente os dados de entrada e os resultados esperados.