Engenharia de Software

Transcrição

1 Engenharia de Software 2 o Semestre de 2006/2007 Primeiro enunciado detalhado do projecto: Portal OurDocs ic-es+alameda@mega.ist.utl.pt ic-es+tagus@mega.ist.utl.pt

2 1 Introdução O enunciado base do projecto conjunto das disciplinas de Engenharia de Software (ES) e Sistemas Distribuídos (SD) tem como contexto a OurDocs, que se propõe fornecer uma solução de gestão documental universal e integrada, utilizando vários serviços de apoio existentes. O sub-projecto da disciplina de ES consiste no desenvolvimento do Portal da OurDocs. Na primeira fase de desenvolvimento do Portal OurDocs assume-se que a base de dados do portal contém todos os dados necessários ao funcionamento deste. Como tal, não existe interacção com entidades externas. Neste enunciado são descritos os requisitos pretendidos para a primeira parte da implementação do Portal da OurDocs, regras de desenvolvimento, entrega e avaliação. 2 Requisitos funcionais da primeira entrega As sub-secções 2.2 a 2.8 descrevem os requisitos funcionais da primeira entrega. A atribuição dos vários requisitos aos sub-grupos é a descrita na secção 3.2. A aplicação deve apresentar mensagens de erro adequadas sempre que tal se revele necessário. Nesta secção as palavras que correspondem a nomes que são de uso obrigatório na solução desenvolvida aparecem formatadas da seguinte forma: palavras obrigatórias. 2.1 Contexto Foi introduzido um novo conceito Document que representa um documento gerido no contexto do Portal OurDocs. Um Document está associado ao User que o criou, e à Team em cujo contexto está a ser editado. Tem ainda associadas a si o conjunto de todas as edições que o seu conteúdo já sofreu (conceito DocumentInformation). Adicionalmente, um Document pode estar num de três estados possíveis: Draft, Editable ou Approved. O conceito EditorialDocument representa um documento gerido no contexto de uma EditorialTeam e acrescenta o estado Published aos estados possíveis. Qualquer Document no estado Draft apenas pode ser manipulado pelo seu criador, que pode alterar o estado para Editable. Um EditorialDocument no estado Editable pode ser lido e editado por qualquer membro da equipa, mas só o seu criador pode mudar o seu estado para Published. No estado Published, qualquer membro da equipa pode ler o documento mas apenas o User que desempenha o papel de publisher da equipa pode editar o EditorialDocument ou mudar o seu estado para Approved. Qualquer Document no 2

3 estado Approved apenas pode ser lido por qualquer membro da equipa. 2.2 Listar Documentos Esta funcionalidade está disponível a partir da opção List documents do menu lateral. Para tal é necessário ter uma equipa seleccionada. O resultado deve ser a lista de documentos associados à equipa seleccionada, apresentando a informação e as opções representadas na figura 1. Figura 1: Interface de funcionalidade Listar Documentos 2.3 Criar Documento A criação de um novo documento deve estar acessível através da opção Create document do do menu lateral. Dado que qualquer documento é criado no contexto de uma dada equipa, é necessário haver uma equipa já seleccionada. Primeiramente deve ser apresentada uma página para criação de um novo documento. No formulário deve ser possível introduzir o título do documento, bem como o seu conteúdo. A restante informação que compõe um documento deve aparecer pré-preenchida, tal como indicado na figura 2. Aquando da submissão deve ser criado um novo EditorialDocument e apresentada a lista de documentos associados à equipa seleccionada. 3

4 Figura 2: Interface de funcionalidade Criar Documento 2.4 Editar Documento Para editar um documento é necessário seleccionar a opção Edit associada ao documento, na listagem de documentos da equipa. Deve ser apresentada uma nova página onde se apresenta o título do documento e apenas se pode introduzir o novo conteúdo do documento (representado na figura 3). De forma a simplificar a edição do conteúdo, este deve ser prépreenchido com o conteúdo actual do documento. Após a alteração deve ser apresentada a lista de documentos associados à equipa. 2.5 Ver Documento A visualização de um documento é possível seleccionando a opção Read associada ao documento, na listagem de documentos da equipa. Deve ser apresentada uma nova página onde se mostra o título do documento, o seu conteúdo, o criador do documento e a equipa a que o documento está associado, bem como o estado actual do documento. Um exemplo desta página é o apresentado na figura 4. 4

5 Figura 3: Interface de funcionalidade Editar Documento 2.6 Actualizar estado do Documento A possibilidade de actualizar o estado de um documento está disponível através da opção Next state associada ao documento, na listagem de documentos da equipa. A alteração de estado deve seguir as regras descritas na sub-secção 2.1. Após a alteração deve ser apresentada novamente a lista de documentos associados à equipa, que já deverá mostrar o novo estado do documento. 2.7 Listar Versões do Documento Para ver as várias versões por que já passou um dado documento é preciso escolher a opção List versions associada ao documento, na listagem de documentos da equipa. Deve ser apresentada uma nova página onde se indica o título do documento, o criador e a equipa a que está associado, bem como o conteúdo de cada uma das versões (começando pela mais antiga), e a opoção de reverter o documento para uma dada versão, tal como representado na figura 5. 5

6 Figura 4: Interface de funcionalidade Ver Documento 2.8 Reverter Documento para uma Versão anterior A reversão de um documento para uma versão anterior só está disponível através da página que lista as versões do documento. Seleccionando a opção Revert associada a uma dada versão do documento, pretende-se que seja criada uma nova versão do documento com o conteúdo da versão seleccionada. Após a reversão, deve ser de novo apresentada a listagem das versões do documento (em que a última versão deve ter o conteúdo igual à versão para que se reverteu o documento. 3 Desenvolvimento A plataforma de desenvolvimento e execução do projecto é J2SE Ponto de partida O desenvolvimento desta primeira fase do projecto Portal deve partir do código fornecido para o efeito na secção Projecto do site da cadeira. No entanto, esse código pode ser alterado livremente pela equipa de acordo com as necessidades de desenvolvimento, desde que as 6

7 Figura 5: Interface de funcionalidade Listar Versões do Documento 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. Antes de começarem o desenvolvimento devem importar o código do qual vão partir para o repositório de CVS disponibilizado. Esta primeira versão do código deve ser etiquetada com a etiqueta INICIO_ES1. Aconselha-se a análise prévia ao código, dado que a funcionalidade concretizada nas classes de domínio fornecidas é suficiente para satisfazer todos os requisitos descritos na secção Divisão de trabalho por sub-grupos Cada grupo de 9 elementos encontra-se subdividido em três sub-grupos de 3 elementos. Cada um destes sub-grupos é responsável pela realização de dois dos sete requisitos indicados na secção 2. A atribuição do trabalho a cada sub-grupo é feita da seguinte forma: O sub-grupo 1 é responsável por realizar os requisitos de Criar Documento e Editar 7

8 Documento, descritos nas secções 2.3 e 2.4. O sub-grupo 2 é responsável por realizar os requisitos Ver Documento e Actualizar Estado do Documento, descritos nas secções 2.5 e 2.6. O sub-grupo 3 é responsável por realizar os requisitos Listar Versões do Documento e Reverter Documento para Versão anterior, descritos nas secções 2.7 e 2.8. O requisito Listar Documentos, descrito na secção 2.2, é responsabilidade de todo o grupo, bem como os aspectos relativos à configuração de persistência das novas classes Document, DocumentInformation e EditorialDocument. A constituição e a identificação de cada um dos sub-grupos é a mesma que é usada na cadeira de Sistemas Distribuídos e segue o seguinte algoritmo: 1. Listar todos os elementos do grupo com número e nome. 2. Ordenar a lista por número crescente (do menor para o maior). 3. Escolher o aluno com menor número. 4. O subgrupo desse aluno é o sub-grupo Retirar os alunos do primeiro subgrupo da lista. 6. Escolher o aluno com menor número dos que restam. 7. O subgrupo desse aluno é o sub-grupo Retirar os alunos do segundo subgrupo da lista. 9. O subgrupo dos alunos que restam é o sub-grupo 3. Todos os grupos devem enviar para o mail da cadeira a sua composição, bem como o trabalho atribuído, para confirmação por parte do corpo docente. 3.3 Coordenação entre a equipa Todos os elementos do grupo vão desenvolver código no mesmo sub-projecto: o subprojecto Portal. Embora o trabalho esteja dividido à partida pelos sub-grupos existirá uma única entrega, i.e., uma única etiqueta, que deverá ser colocada pelo grupo quando todos considerarem que realizaram a respectiva parte. Deste ponto de vista não existe diferença para as entregas seguintes. A única diferença é que, nesta entrega, o trabalho está dividido à partida por cada um dos sub-grupos, enquanto que nas entregas seguintes serão os alunos do grupo a dividir o trabalho entre si da forma que considerarem mais apropriada. Este primeiro enunciado foi elaborado de forma a minimizar as dependências entre o trabalho de cada sub-grupo. No entanto, existem alguns pontos de contacto. Nestes pontos deve ser 8

9 exercido especial cuidado para não limitar nem perturbar o desenvolvimento em equipa. Relembra-se que todo o grupo é uma única equipa de desenvolvimento, pelo que é essencial existir coordenação entre os vários sub-grupos quanto a alterações nesses pontos. Só assim poderão garantir o correcto funcionamento do resultado final. Em particular, chama-se a atenção para os seguintes artefactos que são partilhados pelos vários sub-grupos: Ficheiro de configuração do Hibernate (hibernate.cfg.xml) Ficheiros menu.jsp e JSP de apresentação da listagem de documentos. Ficheiros de definição do estado inicial dos testes de serviço (e ficheiros de resultados esperados directamente relacionados). A base de dados usada pelo projecto (recomendamos a utilização de bases de dados distintas por cada um dos sub-grupos de trabalho). 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"(ver bitstream/2295/109345/1/projsdesregrascvsalameda.html e dspace.ist.utl.pt/bitstream/2295/109344/1/projsdesregrascvstagus. html para a Alameda e para o Tagus, respectivamente). A etiqueta a colocar para indicar a entrega da primeira fase do projecto é ES1. 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 A avaliação desta primeira fase do projecto é composta por duas partes: Visualização do projecto e avaliação dos elementos do grupo. Avaliação posterior do código desenvolvido. A primeira parte é realizada nas aulas de laboratório na semana seguinte à entrega do projecto. Consiste numa demonstração das funcionalidades do projecto e na realização por cada um dos elementos do grupo de um exercício de alteração do projecto. Durante esta primeira avaliação considera-se requisito mínimo o seguinte: 9

10 Um aluno deve ser capaz de, num PC do laboratório, obter o projecto a partir do repositório CVS, efectuar o deploy e apresentar a página inicial do portal num navegador web. Os alunos que não conseguirem cumprir este requisito em 15 minutos têm 0 (zero) nesta entrega. a a A utilização do Eclipse na avaliação é completamente facultativa, pelo que fica ao critério de cada aluno decidir sobre a sua utilização ou não. 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. A nota obtida por cada aluno será a nota atribuída ao sub-grupo na segunda parte da avaliação, afectada pela realização individual da primeira parte da avaliação. FIM DO ENUNCIADO 10