Engenharia de Software. Enunciado da Segunda Parte do Projecto

Transcrição

1 LEIC-A, LEIC-T, LETI, MEIC-T, MEIC-A Engenharia de Software 2 o Semestre 2013/2014 Enunciado da Segunda Parte do Projecto 1. Segunda Parte do Projecto ES A segunda parte do projecto consiste na realização de um conjunto de serviços que irão suportar um determinado conjunto de funcionalidades para serem usadas na camada de apresentação. Será também necessário enriquecer a camada de domínio para que suporte os serviços que vão ser criados. Neste enriquecimento é necessário ter em conta todas as regras de negócio indicadas no primeiro enunciado e as que se apresentam neste. Será também necessário concretizar alguns testes aos serviços criados. No desenvolvimento da camada de serviços deve ter em conta que na concretização do serviço de pagamentos da camada de serviços da aplicação, a ligação deste serviço ao serviço externo CHEQUEREFEICAO não é uma preocupação deste trabalho. A concretização deste serviço externo e a sua ligação ao serviço de pagamentos está relacionado com o trabalho a realizar para Sistemas Distribuídos. Nesta segunda parte do projecto, uma vez que o serviço externo CHEQUEREFEICAO ainda não está concretizado, deve ser realizada uma versão do serviço de pagamentos que não depende do serviço externo e que usa a classe RegistaChequeLocal (a disponibilizar pelo corpo docente de Engenharia de Software). A utilização desta abordagem permite desenvolver e testar a aplicação REST e os serviços externos CHEQUEREFEICAO e REGISTOFATURA de forma isolada e independente. Deste forma, na última parte do projecto conjunto apenas será necessário testar a integração da aplicação desenvolvida no contexto de Engenharia de Software com os dois serviços externos desenvolvidos no contexto de Sistemas Distribuidos Novas Regras de Negócio Nesta parte é necessário considerar a concretização das seguintes regras de negócio: Adicionar um prato e quantidade ao tabuleiro de compras do cliente. Esta quantidade pode ser um valor negativo. Caso o cliente não tenha um tabuleiro de compras, então

2 deve ser criado um. Se o prato a adicionar ao tabuleiro de compras já existir no tabuleiro de compras, então apenas se deve actualizar a quantidade do prato no tabuleiro de compras. Se este valor ficar menor ou igual a 0, então o prato deve ser retirado do tabuleiro de compras. Os clientes passam a ter um crédito no portal (designado como saldo). Este valor é utilizado no pagamento de uma compra. O saldo de um cliente é sempre maior ou igual a 0. Realizar uma compra. Do ponto de vista do domínio da aplicação, o acto de compra verifica se o saldo do cliente em causa é superior ao valor do tabuleiro de compras. Se for inferior deve lançar uma excepção. Se for maior ou igual ao valor da compra, então a compra representada pelo tabuleiro de compras é finalizada e o saldo do cliente é actualizado. Caso o cliente não tenha tabuleiro de compras ou este se encontre vazio deve ser lançada outra execpção Serviços a Concretizar As funcionalidades a concretizar na camada de serviço são as seguintes: Adicionar um Item ao Tabuleiro de Compras Adiciona um prato e a respectiva quantidade ao tabuleiro de compras do cliente indicado. Obter Restaurantes Devolve os restaurantes registados. A informação a representar por restaurante é o nome, morada e a classificação do restaurante. Obter Menu Devolve a informação sobre os pratos (nome, calorias, preço e classificação) de um restaurante. Gostar de um prato Regista um gostar de um dado prato por um dado cliente. Actualizar Saldo Recebe um valor e um identificador de cliente e actualiza o saldo do cliente adicionandolhe o valor recebido. Esvaziar Tabuleiro de Compras Esvazia o tabuleiro de compras do cliente indicado. Procurar Pratos por Nome Obtém os pratos registados em restaurantes do portal cujo nome contém uma cadeia de caracteres indicada pelo utilizador. A informação relativa a cada prato deve conter a descrição, preço, classificação, calorias e restaurante que oferece o prato. Regista Pagamento do Tabuleiro de Compras Este serviço recebe como argumento o identificador de um cliente e realiza o pagamento do tabuleiro de compras do cliente tendo em conta o saldo do cliente Pagamento de uma Compra Adicionalmente a estes serviços, é necessário concretizar a funcionalidade efectuar o pagamento de uma compra. Esta funcionalidade recebe a lista de identificadores de cheques de refeição a utilizar no pagamento da compra e o cliente que quer realizar a compra e deve ser concretizada na classe pt.ist.rest.presentationserver.presentationserver. Esta funcionalidade deverá ter o seguinte funcionamento: 2

3 1. Regista os cheques de refeição no serviço CHEQUEREFEICAO e recebe como valor de retorno o valor dos cheques. Se ocorrerem erros durante o registo dos cheques não é feito mais nada; 2. Actualiza o saldo do cliente com os valor dos cheques registados; 3. Regista o pagamento do tabuleiro de compras do cliente; 4. Caso o registo do pagamento decorra sem problemas, então cria uma factura para a compra efectuada através do seviço REGISTOFATURA. Nesta entrega do projecto não é necessário considerar este passo do pagamento do tabuleiro de compras. Esta funcionalidade deve ser concretizada por forma a abstrair se se está a utilizar a versão local ou remota do serviço de pagamentos CHEQUEREFEICAO. Assim não será necessário alterar a concretização desta funcionalidade caso se queira utilizar a versão local ou remota dos serviços CHEQUEREFEICAO e REGISTOFATURA. O corpo docente de ES sugere a aplicação do padrão de desenho Bridge ou Abstract Factory no desenvolvimento deste novo requisito funcional Testes É necessário realizar testes de software, ao nível da camada de serviço, para as seguintes funcionalidades: Esvaziar Tabuleiro de Compras Procurar Pratos por Nome. Adiciona Item ao Tabuleiro de Compras Estado Persistente Inicial da Aplicação Para se poder realizar a visualização da segunda entrega, é necessário ter um cenário de teste inserido no estado persistente da aplicação. O cenário de teste é igual ao definido para a primeira entrega do projecto e deve ser concretizado igualmente na classe pt.ist.rest.restsetup Servidor de Apresentação É necessário concretizar a classe pt.ist.rest.presentationserver.presentationserver que deverá ter o método main com o comportamento semelhante ao descrito no enunciado da primeira parte do projecto de Engenharia de Software. A execução deste método deve ficar atribuída ao target run do ficheiro build.xml e deverá ter o seguinte comportamento: 1. Registar o restaurante com o nome Barriga Cheia e morada Porto, Portugal gerido pelo gestor pp. 2. Listar os utilizadores registados no sistema. 3. Listar os restaurantes registados no sistema. 4. O gestor pp adiciona o prato com a descrição Bitoque ao restaurante Barriga Cheia. 5. Escrever a classificação de todos os restaurantes do portal. 3

4 6. O cliente zeze gosta dos pratos Bitoque, Canja de Galinha e Bacalhau com batatas do restaurante Barriga Feliz. 7. O cliente mariazinha gosta do prato Canja de Galinha do restaurante Barriga Feliz. 8. Escreve novamente a classificação dos restaurantes registados no portal. 9. Adiciona o prato Canja de Galinha do restaurante Barriga Feliz com a quantidade 3 ao tabuleiro de compras do cliente zeze. 10. Adiciona o prato Bacalhau com batatas do restaurante Barriga Feliz com a quantidade 2 ao tabuleiro de compras do cliente zeze. 11. Apresenta o contéudo do tabuleiro de compras dos clientes zeze e mariazinha. Notas: A listagem de todos os utilizadores deve incluir o seu tipo e o valor dos seus atributos (username, nome e password). A listagem de todos os restaurantes deve incluir o nome e morada de cada restaurante seguido do nome, preço e calorias dos pratos do restaurante. Cada uma das acções descritas deve ser feita numa transacção independente. Sempre que possível realize as acções utilizando os serviços existentes. Por exemplo, a acção de gostar deverá ser feita através do serviço com essa funcionalidade. Note que as três últimas acções são novas. As excepções que possam ocorrer durante a execução das acções descritas no método main devem ser tratadas correctamente. 2. Realização da Segunda Parte do Projecto O corpo docente de Engenharia de Software prevê que a realização desta parte do projecto exigirá cerca de 8 horas de trabalho a cada aluno do grupo. Nesta previsão, o corpo docente assume que os alunos já perceberam o funcionamento da camada de serviços a desenvolver, sabem realizar testes de software automáticos e existe um planeamento do projecto por forma a perceber o trabalho a realizar e este trabalho é distribuído pelos vários elementos do grupo. Na realização do projecto, aconselha-se que cada grupo siga o seguinte o planeamento: 1. Ler o enunciado com atenção. 2. Cada elemento do grupo deverá perceber quais as alterações a realizar à estrutura do estado persistente da aplicação. 3. O grupo deve reunir-se e comparar as diferentes alterações ao domínio da aplicação e concluir qual deve ser o novo diagrama de classes UML do domínio da aplicação. Actualizar o ficheiro dml por forma a conter as alterações. 4. Distribuir as novas regras de negócio pelos vários elementos do grupo. O grupo pode ser dividido em sub-grupos de dois elementos e cada par ficará responsável por realizar uma regra de negócio (Pair Programming). 5. Distribuir os serviços a concretizar pelos vários elementos do grupo e definir prazos. A funcionalidade efectuar o pagamento de uma compra deverá ser concretizada na segunda semana. 4

5 6. Distribuir os testes aos serviços por cada sub-grupo. Cada sub-grupo deve ficar respnsável por testar um serviço que não foi concretizado por nenhum dos elementos do sub-grupo. 7. Actualizar a classe pt.ist.rest.presentationserver.presentationserver por forma a realizar as acções, onde seja possível, através dos serviços existentes. 8. Concretizar a funcionalidade efectuar o pagamento de uma compra. Note-se que este planeamento apenas tem a indicação das tarefas a realizar. É da responsabilidade do grupo fazer a distribuição temporal das tarefas pelo tempo disponível para realizar o projecto. Esta distribuição também corresponde a uma tarefa e deve ser a primeira tarefa a realizar pelo grupo e deve ser feita o mais cedo possível Entrega da Segunda Parte do Projecto O prazo de entrega da segunda parte do projecto é até ao início da sexta semana de aulas do grupo de 24 a 28 de Março de O projecto a realizar deve apresentar uma estrutura semelhante à da aplicação PhoneBook com Serviços. O código produzido deve ser guardado no repositório SVN disponibilizado para cada grupo numa directoria chamada rest que deverá ter as sub-directorias trunk, tags e branches. O projecto é entregue através deste repositório que estará alojado no AFS do Técnico que pode ser acedido por svn+ssh através da máquina sigma.tecnico.ulisboa.pt. Cada grupo após ter concretizado esta parte do projecto e ter guardado no seu repositório o código respectivo, deverá criar a tag R_2. Esta tag representará a versão do código produzido para esta parte do projecto que os alunos querem submeter a avaliação. Para facilitar o execução do código entregue, os grupos têm que utilizar os seguintes dados para a definição da ligação à base de dados: username: rest password: r3st base de dados: restdb 2.2. Penalizações Projectos que guardem ficheiros desnecessários no repositório terão uma penalização na nota de 2 a 4 valores. Consideram-se desnecessários os ficheiros.class gerados na compilação das classes Java, os ficheiros _Base.java automaticamente gerados na compilação da DML, ou ficheiros.jar com bibliotecas já existentes no repositório de bibliotecas. Para isso, deverão utilizar a propriedade svn:ignore tal como exposto nas aulas de laboratório. 5