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 detalhado de ES.Código Base para o 2ª enunciado
O código base para a 2ª entrega está já integrado com um serviço remoto de SD. Como tal para o correcto funcionamento do Portal é necessário lançar também um qualquer serviço de Identidade e registá-lo no serviço de nomes adequado.
É fornecido um serviço Identidade muito simples, com um conjunto de utilizadores e domínios pré-definidos, a ser usado pelos alunos que apenas estão a frequentar esta cadeira (e por qualquer outro que prefira utilizá-lo em detrimento do trabalho em desenvolvimento à disciplina de Sistemas Distribuídos). A informação sobre utilizadores disponíveis está configurada no ficheiro de configuração config/resources/identidade.properties.
Segue-se uma curta descrição dos passos necessários para colocar em funcionamento a aplicação:
- descomprimir os ficheiros Código base, Bibliotecas extra, Serviço Identidade e ImportAnt para o mesmo local
- descomprimir o ficheiro Bibliotecas disponibilizado com o 1º enunciado para o mesmo local do ponto anterior
- no directório SIdentidade_Local
- lançar a aplicação: ant deploy
- publicar a aplicação no serviço de nomes: ant ws-publish
- no directório Portal
- gerar as novas tabelas da base de dados:
ant generate-db-schema
- lançar a aplicação: ant deploy
- gerar as novas tabelas da base de dados:
ant generate-db-schema
- aceder ao Portal (tipicamente em
http://localhost:8080/Portal) e seleccionar o
link "Update Services"
- deve ser encontrado activo o serviço "OurDocs SIdentidade"
Correcção ao código base do 2º enunciado (14-05-2007)
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õem a alterações que possam ter entretanto realizado (classes User e IdentityRemoteService do domínio).
Nova correcção ao código base do 2º enunciado (16-05-2007)
Está disponível uma 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õem 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).
Lógica de negócio na apresentação
No ficheiro
OurDocs/Portal/src/web/ShowVersions.jsp,
as linhas 40-42 e 44 estão a mais. (não devia haver <c:if ...> algum, devendo sempre ser apresentado o botão de
Revert.
Não se deve repetir a lógica de negócio na apresentação. Ou os objectos devolvidos pelo serviço permitem saber directamente se se pode ou não efectuar uma dada operação (neste caso reverter uma versão), ou então é sempre apresentada a operação que poderá não ser aceite quando se tentar executar (neste caso, se o utilizador não tiver as permissões adequadas deve aparecer uma mensagem de erro).
Exemplo de Planeamento
Foi recuperado o projecto ES-2 (https://es.extremeplannerlive.com) com a estrutura da Story "Alterar Criar Documento", bem como exemplos de subdivisão em Tasks e descrição dos Test Cases de aceitação para a story.Para ler o conteúdo deste projecto devem usar-se os seguintes dados:
- Login: ALUNO
- Password: ALUNO
Regras para 2ª entrega do projecto
A 2ª entrega do projecto decompõe-se em dois aspectos: plano de desenvolvimento e código desenvolvido.
O planeamento tem de ser inserido no ExtremePlanner até 6ªFeira dia 18/05/2007.
Os planos com uma data de registo ou alteração de uma
Release,
Iteration,
Story,
Task ou
Test Case posterior ao dia 18/05/2007 não serão avaliados.
É responsabilidade de cada grupo assegurar que o plano de projecto está disponível no ExtremePlanner e que este não sofre alterações depois do dia 18/05/2007.
A monitorização do cumprimento deste requisito será feita com base no registo do histórico das alterações (o ExtremePlanner foi entretanto configurado para o fuso horário de Portugal).
O código desenvolvido deve ser,
obrigatoriamente, entregue via CVS, etiquetando tudo o necessário ao correcto funcionamento do Portal com a etiqueta
ES2.
O não cumprimento deste requisito tem uma penalização de 5% da nota final.
Opcionalmente, podem entregar uma segunda cópia do mesmo código via sistema de submissões do Fénix, mantendo-se a regra de que se o código não tiver sido entregue via CVS terá uma penalização de 5%.
Podem aceder ao sistema de submissões via
Portal do Estudante ->
Submeter ->
Projectos ->
Engenharia de Software ->
Visualizar ficheiros submetidos ->
Submeter ficheiros. Na submissão via Fénix devem submeter apenas o código desenvolvido no âmbito da cadeira, sem os directórios OurDocs/extensions, OurDocs/Portal/libs, OurDocs/Portal/build e OurDocs/Portal/dist e após invocarem o alvo clean.
O projecto será avaliado segundo os seguintes critérios:
- Plano de Projecto
- Análise dos requisitos especificados
- Conformidade das Stories e Tasks com o que foi especificado
- Análise dos Test Cases (aceitação e unitários)
- Funcionalidade do código desenvolvido
- Análise do código desenvolvido
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. Por exemplo, "Apenas o criador pode submeter o seu documento". Desta lógica de negócio devem inferir-se 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á não 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 com 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.
Notas da 1ª entrega
Estão disponíveis as notas da 1ª entrega.Estimativas recebidas
De acordo com os e-mails recebidos as estimativas para o 3º enunciado que vão ser consideradas são:- A0201 - 31/Maio
-
A0102 - 3/Junho
-
A0603 - 2/Junho
- A0504 - 4/Junho
- A0405 - 3/Junho
-
A0806 - 4/Junho
- A0307 - 1/Junho
- A0908 - 2/Junho
-
A0709 - 2/Junho
- A1210 - 2/Junho
-
A1112 - 1/Junho
-
A1513 - 1/Junho
- A1714 - 30/Maio
- A1815 - 31/Maio
- A1916 - 4/Junho
-
A2117 - 2/Junho
- A2018 - 2/Junho
- A2419 - 7/Junho (não enviaram estimativa)