Engenharia de Software

Engenharia de Software

Primeiro enunciado detalhado do projecto:

Portal OurDocs

ic-es+alameda@mega.ist.utl.pt ic-es+tagus@mega.ist.utl.pt

1

Introdução

O enunciado base do projecto conjunto das disciplinas de Engenharia de Software (ES) e Sis-temas 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 implemen-taçã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 secatribui-çã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 obri-gató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 con-texto 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 Documentpode estar num de três estados possíveis: Draft, Editable ou Approved.

O conceito EditorialDocument representa um documento gerido no contexto de uma EditorialTeame 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 docu-mento mas apenas o User que desempenha o papel de publisher da equipa pode editar o EditorialDocumentou mudar o seu estado para Approved. Qualquer Document no

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.

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 apre-senta 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 do-cumento, 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.

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 stateassociada 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 apre-sentada 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.

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 5.0.

3.1 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

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 extensionsnã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 con-cretizada nas classes de domínio fornecidas é suficiente para satisfazer todos os requisitos descritos na secção 2.

3.2 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:

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 1. 5. 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 2.

8. 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 projecto: o sub-projecto 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.

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 https://dspace.ist.utl.pt/ bitstream/2295/109345/1/ProjSdEsRegrasCVSAlameda.htmle https:// dspace.ist.utl.pt/bitstream/2295/109344/1/ProjSdEsRegrasCVSTagus. htmlpara 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 pro-jecto. 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:

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 nor-mas 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.