Engenharia de Software 2º Semestre de 2006/2007 Terceiro enunciado detalhado do projecto: Portal OurDocs ic-es+alameda@mega.ist.utl.pt ic-es+tagus@mega.ist.utl.pt
1. Introdução O terceiro enunciado do projecto do Portal OurDocs tem por base a estrutura do plano de projecto definida no segundo enunciado. O plano deve detalhar os novos requisitos funcionais, bem como as implicações/alterações ao nível do código a desenvolver. Os requisitos deverão ser descritos usando a nomenclatura do Extreme Programming e as Tasks com os prefixo definidos no segundo enunciado. As Tasks do tipo Design (D) têm de incluir como resultado da sua execução uma especificação da interface. Associados a cada Story apenas pode haver Tasks do tipo: Domain Model Design (D-DML); Domain Model Implementation and Testing (I-DML+T); Presentation Design and Testing (D-PL+T); Presentation Layer Implementation (I-PL); Thin Service and Data Layers Implementation and Testing (I-TL+DL+T). O plano de projecto deverá ser gerido através da ferramenta ExtremePlanner, disponível online no endereço https://es.extremeplannerlive.com. Tal como no exemplo apresentado, o projecto deverá ter apenas uma Release e uma Iteration, onde serão descritas todas as Stories. Note-se que uma Story pode ter várias Tasks do mesmo tipo desde que seja possível haver trabalho em paralelo, por exemplo, a implementação de 2 JSPs de um caso de uso. Neste exemplo, deverá depois haver uma Task de integração dos JSPs. Como a ferramenta ExtremePlanner não permite relacionar os Test Cases (aceitação, unitários e integração) com as respectivas Tasks deverá ser adoptada a mesma nomenclatura de prefixos para facilitar a identificação das associações aquando da análise/validação dos testes. Os Test Cases deverão ter uma estrutura padronizada com a seguinte informação: Descrição resumo do objectivo do teste; Cenário instanciação de um dos cenários da história, com dados de teste específicos; Resultado Esperado breve descrição do resultado esperado; Mensagem de Erro tipo de mensagem de erro a apresentar na interface JSP. O desenvolvimento da terceira fase do projecto Portal OurDocs deve partir do código desenvolvido para a segunda entrega, alterado de modo a responder aos requisitos especificados na secção 2. As alterações devem respeitar a arquitectura definida para o projecto e que foi apresentada nas aulas de laboratório. Pag. 2 de 7
2. Requisitos da 3ª entrega 2.1 Estimativa Até às 20h de 29 de Maio os grupos têm que estimar a duração do desenvolvimento. A data estimada deve ser enviada para o endereço de correio electrónico da disciplina, tendo o assunto "Estimativa-<inicial-do-campus><grupo-sd><grupo-es>". Será enviada uma confirmação. Se não receberem confirmação, a estimativa não foi recebida. O corpo docente assegura que confirmará até às 19:45 todas as estimativas recebidas até às 19:30. No dia seguinte a estimativa de cada um dos grupos será publicada na página da cadeira. Para os grupos que não enviem estimativa será considerada como data estimada o dia limite da entrega. As horas da estimativa correpondem às 23:59 do dia indicado, ou seja, uma estimativa para 1 de Junho quer dizer que pretendem entregar até às 23:59 de 1 de Junho. 2.2 Contexto Estender a solução do segundo enunciado de forma a que: a) Um documento possa ser constituído por um conjunto variável de partes b) Um documento possa ser classificado de acordo com 3 palavras chave Um documento possui um título (Title) e é composto por partes. Tal como indicado na, uma Secção (Section) de um documento corresponde a um componente constituído por um titulo e parágrafo(s) (Paragraphs), podendo conter várias (sub)secções também elas constituídas por um título e parágrafo(s). Não existe limite no número de subsecções encaixadas. Existem duas outras partes especificas designadas por Resumo (Abstract) e Conclusão (Conclusions) que apresentam o título pré-definido como resumo e conclusões respectivamente. O resumo não pode possuir subsecções. Para cada uma das partes é guardada a versão, à qual é associado um número de versão. Assim sendo, um documento, num dado momento, é igual à junção da versão mais recente de cada uma das partes. Cada uma das partes de um documento pode ser revertida para uma versão anterior. O documento é identificado por um número único de documento. O Título apenas pode ser alterado pelo criador (sempre um Editor) nos estados DRAFT, e EDITABLE e pelo editor (Publisher) no estado SUBMITTED. O comportamento para as restantes partes é igual ao definido anteriormente. Com o objectivo de flexibilizar o numero de partes que um documento pode conter, sugere-se implementar o documento usando o padrão de desenho Composite, de modo a permitir ao utilizador adicionar dinamicamente novas partes ou sub-partes a um documento. Quando um documento é aprovado deve ser classificado de acordo com 1 a 3 palavras chave que são disponibilizdas. O conjunto de palavras chave segue a estrutura do CORDIS, http://cordis.europa.eu/fp6/fp6keywords.htm, e deve ser possível retirar ou adicionar novas Pag. 3 de 7
palavras chave ao conjunto pré-definido. Não é possível editar uma palavra chave. O sistema não deve autorizar retirar uma palvra chave se esta já se encontra a classificar um documento. As palavras chave estão numa estrutura hierárquica pelo que na visualização do documento deve-se apresentar as palavras chave atribuídas ao documento e todas as que estão na hierarquia acima delas. Quando o sistema se inicia é necessário garantir que estão disponíveis as palvras chave descritas em http://cordis.europa.eu/fp6/fp6keywords.htm. Apenas utilizadores que sejam editores (Publisher) de um pelo menos um Team podem criar ou retirar palavras chave. De seguida apresenta-se a estrutura de um documento formatado (como ele deve surgir quando se selecciona ler documento na lista de documentos). Figure 1- Exemplo da estrutura de um documento formatado. Cada um dos elementos do documento é apresentado como um link que envia para uma página de gestão dessa parte. Essa página fornece as seguintes funcionalidades consoante o tipo da parte associada ao link: Título Documento editar o título, criar um secção (que passará a ser a 1ª do documento), listar as versões do título do documento Pag. 4 de 7
Resumo criar um parágrafo (que passará a ser o 1º do resumo) Palavras Chave editar a lista de palavras chave (nesta lista é possível associar e desassociar palavras chave ao documento) Secção editar o título da secção, criar um parágrafo da secção (que passará a ser o 1º da secção), criar uma secção (que passará a ser a secção seguinte da secção actual), criar uma subsecção (que passará a 1ª subsecção da secção actual), listar as versões do título da secção, apagar a secção (que apaga também todos os seus parágrafos e todas as suas subsecções) Parágrafo editar parágrafo, criar um parágrafo (que passará a ser o parágrafo seguinte ao actual), listar as versões do parágrafo Conclusões criar um parágrafo (que passará a ser o 1º das conclusões), criar uma subsecção (que passará a 1ª subsecção das conclusões) Note-se que não é possível reverter partes apagadas e que a lista de documentos apenas disponibiliza as funcionalidades ver e alterar estado do documento. 3. Desenvolvimento A plataforma de desenvolvimento e execução do projecto é J2SE 5.0. 3.1 Ponto de partida O trabalho a desenvolver deve partir do código do Portal desenvolvido por cada grupo durante a segunda fase do projecto. Em particular, assume-se que todas as alterações efectuadas desde a etiqueta ES2 correspondem ao trabalho desenvolvido na terceira fase do projecto. Tal como nas fases anteriores, o código base do Portal pode ser alterado livremente pela equipa de acordo com as necessidades de desenvolvimento, desde que as alterações respeitem a arquitectura que foi definida para o projecto e que foi apresentada nas aulas de laboratório. Os ficheiros fornecidos no directório import-ant e no directório extensions não podem ser alterados. 3.2 Conselhos e informações úteis As aulas de laboratório até à entrega serão apenas para apoio ao projecto. A ausência de alunos com dúvidas após meia-hora do início da aula implica o fim da aula de apoio. Leiam com muita atenção a secção de requisitos. Esta secção contém muito mais informação do que pode parecer numa primeira leitura. Tenham especial cuidado em respeitar o que é pedido no enunciado e não em implementar o que vos parecer mais adaptado à realidade ou mais interessante de realizar. Se encontrarem mais do que uma possível interpretação para algum requisito apresentado, devem esclarecê-lo junto do cliente (corpo docente), via fórum da cadeira ou presencialmente nas aulas de laboratório e no horário de dúvidas de projecto. Aconselha-se bom senso e simplicidade na implementação. Qualquer decisão terá de ser justificável. Pag. 5 de 7
Sempre que possível devem tirar partido das características da arquitectura. Por exemplo, as validações de dados serem efectuadas, sempre que possível, utilizando validadores do Stripes; não reutilizar excepções em contextos em que a sua semântica é diferente da original; utilizar os métodos marshal() e unmarshal() para transformação de dados entre a camada de apresentação e a camada fina de serviços; o tratamento de excepções ao nível da apresentação ser feito por configuração das mensagens a apresentar. 4. Entrega A entrega do trabalho é realizada através do repositório de CVS seguindo as regras descritas no documento "Utilização do CVS no projecto" existente na secção Projecto da página da disciplina. Os planos de projecto com uma data de registo ou alteração de uma Release, Iteration, Story, Task ou Test Case posterior à data da entrega do software no CVS 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 desse dia. A etiqueta a colocar para indicar a entrega da 3ª fase projecto é ES3. O alvo build deve efectuar as operações necessárias para produzir uma aplicação que possa ser instalada num servidor web, isto é, o resultado de efectuar ant build deve ser o ficheiro Portal.war no directório dist. 5. Avaliação O aspecto gráfico (imagens, cores, tipos de fonte) não será tido em conta para a avaliação do projecto, desde que a interface seja uniforme e respeite os requisitos deste enunciado. A avaliação desta terceira fase do projecto é composta por duas partes: Visualização do projecto e discussão com os elementos do grupo. Avaliação posterior do plano de projecto e do código desenvolvido. A primeira parte é realizada na semana seguinte à entrega do projecto, em horário a marcar. Consiste numa demonstração das funcionalidades do projecto e numa discussão oral com todos os elementos do grupo acerca do trabalho realizado, a arquitectura e consequências de efectuar alterações ao código. Todos os alunos do grupo devem ser capazes de efectuar uma alteração a qualquer parte do código do projecto e colocar o projecto a executar com essa alteração. Durante esta primeira avaliação o grupo deve ser capaz de obter o projecto a partir do repositório de CVS e de o colocar a funcionar, com todos os serviços remotos necessários, nos PCs do laboratório. A segunda parte da avaliação é realizada posteriormente pelo corpo docente e consiste na avaliação do projecto do ponto de vista da correcção da solução e do cumprimento das normas de utilização da arquitectura, bem como do plano de projecto definido e sua execução. A nota obtida por cada aluno será a nota atribuída ao grupo na segunda parte da avaliação, afectada pela sua discussão oral. Durante a discussão do projecto, todos os elementos do grupo têm de saber como fazer qualquer parte do projecto, embora não tenham Pag. 6 de 7
necessariamente de saber os detalhes da implementação realizada pelos colegas. 5.1 Cálculo do Bónus Será aplicado um bónus à nota final da entrega, segundo a seguinte fórmula: Dado que: DATA FINAL = 6/Junho DATA INÍCIO = 28/Maio DATA FINAL - DATA ENTREGA (DATA FINAL DATA INÍCIO ) + DATA ESTIMADA DATA ENTREGA resulta que o bónus é calculado da seguinte forma: Exemplos: 6/Junho - DATA ENTREGA 10 + DATA ESTIMADA DATA ENTREGA Um grupo que entregue durante o dia 28/Maio tem 50% de bónus: 6/Junho - 28/Maio 10 10 + 28/Maio 28/Maio 10 = 50% Um grupo que entregue durante o dia 6/Junho tem 0% de bónus independentemente da data estimada: 6/Junho - 6/Junho 10 + DATA ESTIMADA 6/Junho 0 = 50% Um grupo que entregue durante o dia 1/Junho, tendo estimado a entrega dia 01/Junho, tem 25% de bónus: 6/Junho 1/Junho 5 10 + 1/Junho 1/Junho 10 = 25% Um grupo que entregue durante o dia 31/Maio, tendo estimado a 1/Junho, tem 27,3% de bónus: 6/Junho 31/Maio 6 10 + 1/Junho 31/Maio 11 = 27,3% Um grupo que entregue durante o dia 2/Junho, tendo estimado a 01/Junho, tem 18,2% de bónus: 6/Junho 2/Junho 4 10 + 1/Junho 2/Junho 11 = 18,2% entrega dia entrega dia FIM DO ENUNCIADO Pag. 7 de 7