LEIC-A, LEIC-T, LETI, MEIC-T, MEIC-A Engenharia de Software 2 o Semestre 2013/2014 Enunciado da Quarta Parte do Projecto 1. Introdução Nesta parte final do projecto de ES e SD pretende-se: Estender a solução desenvolvida até ao momento com novas funcionalidades, o que pode provocar alterações em todas as camadas da aplicação desenvolvida até agora. Aplicar a metodologia SCRUM na gestão do trabalho desenvolvido por cada grupo. Realização de testes de software. Os grupos que estão a fazer ES e SD: Estender a solução para suportar as versões remotas dos serviços externos CHEQUE- REFEICAO e REGISTOFATURA desenvolvidas no contexto da cadeira de Sistemas Distribuídos. Os grupos que estão a fazer apenas ES: Realização da funcionalidade Apresentar dados de um cliente. 2. Aplicação das técnicas de teste e factorização Na segunda e terceira parte do projecto foram realizados dois serviços de procura, um que procura os pratos cujo nome contém uma dada cadeia de caracteres e outro que procura os pratos que são de um determinado tipo. Os dois serviços têm algumas semelhanças mas isto não está a ser tido em conta na concretização dos dois serviços. Aplique técnicas de refactorização que lhe permitem melhorar o desenho destes dois serviços. Escreva um documento que indique como foram aplicadas as técnicas de refactorização e teste para melhorar o desenho da sua aplicação no que diz respeito à procura de pratos. O documento deve apresentar o código inicial e final das classes de procura. Este documento
não deverá passar as três páginas, deverá estar no formato pdf e deverá ser colocado na subdirectoria info dentro do trunk do projecto rest. 3. Novos Requisitos Funcionais Os novos requisitos funcionais a concretizar são os seguintes: Por forma a tornar mais atractivo o portal e assim conseguir ter um maior número de clientes a realizar compras, o portal tem um preço máximo por prato. Os novos pratos que são adicionados aos restaurantes do portal têm que ter um preço menor ou igual a este preço máximo. O valor deste preço máximo pode ser alterado a qualquer momento. Os pratos antigos que tenham um preço superior ao novo preço máximo continuam a constar do menu dos restaurantes respectivos. Dado que o portal vai ser a entidade responsável por passar uma factura para cada compra realizada no portal, o portal deverá ter um número de identificação fiscal (NIF) e um nome. Procura Prato Disponibilizar na interface gráfica a funcionalidade Procura Prato, a qual deverá apresentar a informação dos pratos que obedeçam ao critério especificado pelo cliente (procura por tipo ou por substring). Mostra os Dados do Cliente Activo Apresenta os dados sobre um cliente: nome, morada, email e saldo. Esta funcionalidade deve ser feita apenas pelos grupos que só estão a realizar Engenharia de Software. Efectuar Pagamento de uma Compra É necessário actualizar a lógica de negócio da aplicação para se poder passar facturas às compras efectuadas pelos clientes do Portal. Esta alteração é descrita com detalhe na secção 3.1. Esta funcionalidade deve ser actualizada para passar a invocar o serviço externo REGISTOFATURA. No caso de ocorrer uma excepção durante a execução deste serviço externo numa dada funcionalidade da aplicação desenvolvida, deve ser lançada a excepção RegistaFacturaException (a definir por cada grupo). 3.1. Emissão de Facturas Cada compra efectuada por um cliente deverá ficar associada à informação que constitui uma factura. Uma factura tem a data de emissão, o identificador da factura, e caso o cliente pretenda, o NIF do cliente. O identificador de factura é um par composto por um número de série e número de sequência. A factura deverá ainda ser capaz de representar a seguinte informação: o valor total da factura; o IVA da factura; o NIF e nome da entidade emissora da factura, que neste caso é o portal; e a lista dos vários itens que compõem a factura. Cada item será representado pelo nome do prato, quantidade e preço total do item (quantidade multiplicado por preço unitário do prato). 2
Não é obrigatório criar uma nova entidade no estado persistente da aplicação para representar uma factura. A classe Compra já tem acesso a parte da informação que diz respeito a uma factura e pode ser alterada para guardar a restante informação. Esta informação é necessária para o registo das compras efectuadas no portal no serviço externo REGISTOFATURA. Para suportar este novo requisito vai ser necessário alterar o portal por forma a que sempre que é feito uma compra através do portal, este registe a factura correspondente no serviço externo REGISTOFATURA. Tendo em conta o comportamento do serviço externo REGISTOFATURA, o portal terá que manter uma série de facturas ainda não utilizadas. Sempre que é feita uma compra no portal, o portal deverá emitir uma factura ainda não utilizada da sua série de facturas. A factura emitida ficará associada à compra realizada e deverá ser registada no serviço externo REGISTOFATURA através do método comunicarfactura. Sempre que o portal precise emitir uma factura e já tenha esgotado todas as facturas da sua série de facturas ou não tenha nenhuma série de facturas, o portal terá que ir pedir uma nova série de facturas ao serviço externo REGISTOFATURA através do método pedirserie. Consulte a secção de Perguntas e respostas de Sistemas Distribuídos (http://disciplinas.tecnico. ulisboa.pt/leic-sod/2013-2014/labs/proj/faq.html) onde são dados mais detalhes relativos ao funcionamento deste serviço externo. Por forma a poder testar o código do portal independentemente dos serviços externos CHE- QUEREFEICAO e REGISTOFATURA (os quais poderão ainda não estar totalmente codificados), devem ser utilizados a versão local destes serviços externos, RegistaChequeLocal e RegistoFacturaLocal (a disponibilizar pelo corpo docente de Engenharia de Software). Tal como indicado na segunda parte do projecto de Engenharia de Software, a solução utilizada para invocar estes serviços externos deverá abstrair se se está a utilizar a versão local ou distribuída dos serviços externos CHEQUEREFEICAO e REGISTOFATURA. Assim não será necessário alterar a concretização desta funcionalidade caso se queira utilizar a versão local ou distribuída dos serviços externos. 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. Quando o portal funcionar de forma correcta com a versão local destes serviços poderá então testar a integração do portal com os dois serviços externos desenvolvidos no contexto de Sistemas Distribuidos e caso haja erros no funcionamento do portal então muito possivelmente a origem dos erros estará na integração realizada desde que esta versão dos serviços externos tenha sido testada previamente. Esta estratégia de integração incremental é muito utilizada em sistemas complexos em que primeiro se testam os vários componentes do sistema de forma isolada e depois realiza-se a integração dos vários componentes em várias fases. Desta forma conseguemse isolar os erros. Se o sistema deixar de funcionar numa das fases de integração a fonte mais provável do erro é a integração dos componentes que foi realizada nesta fase. 3
4. Testes Deverão ser efectuados testes de software utilizando as frameworks JUnit e JMockit (http: //code.google.com/p/jmockit). Os testes de software a realizar são os seguintes: Grupos que estão a fazer ES e SD: Cada subgrupo deverá realizar pelo menos um teste de software. Cada teste de software concretizado deverá mostrar o correcto funcionamento de uma situação relevante do serviço externo concretizado pelo subgrupo e que esteja relacionada com os requisitos indicados no enunciado do 2º projecto de SD. Grupos que estão a fazer apenas ES: É necessário testar duas situações específicas da funcionalidade pagamento de uma compra por forma a verificar que esta funcionalidade tem o comportamento esperado nestas duas situações. As situações a testar são as seguintes: o serviço externo CHEQUEREFEICAO lança a excepção InvalidPayedException e o serviço externo REGISTOFATURA lança a excepçãototaisincoerentes_exception. 5. Gestão de Projecto Durante a execução do projecto deve ser seguida a metodologia SCRUM. Para isso, cada grupo deverá criar uma cópia da folha de cálculo abaixo indicado disponível no Google Docs. Esta deve ser renomeado com o nome do repositório do grupo (C-ES-SD-SD). A folha Check dessa folha de cálculo deve ser actualizada com os nomes dos membros do grupo. https://docs.google.com/spreadsheet/ccc?key=0ap20n6n1tm2hddy0rha4v2frevlnzk9zv19ja0ztcve&pli Cada grupo tem que enviar, o mais cedo possível, um e-mail para o endereço de e-mail da cadeira de ES ( leic-es@ist.utl.pt ES Alameda e leict-es@disciplinas.ist.utl.pt ES Taguspark). Os grupos que estão em modo ES + SD têm também que enviar este email para o endereço de e-mail da cadeira de SD. O e-mail a enviar tem que ter o assunto SCRUM do grupo C-ES-SD-SD (onde C-ES-SD-SD deve substituído pelo nome do repositório do grupo) onde indicam o link para a versão da folha de cálculo do grupo que será utilizada para realizar a gestão do projecto aplicando a metodologia SCRUM. O não envio deste e-mail em tempo útil corresponderá a uma avaliação de 0 (zero) da componente de gestão de projecto. Esta folha deve ser actualizada regularmente pelo grupo para refletir a aplicação do SCRUM na gestão do projecto a realizar: No início do projecto, cada grupo deve indicar as histórias que vai concretizar. As histórias deverão ser indicadas na folha Product Backlog. Poderá também utilizar a folha Board para representar esta informação. No início de cada sprint, cada grupo deve indicar o planeamento do sprint. Este planeamento é representado na folha correspondente ao sprint em questão. Por exemplo para o primeiro sprint deverá utilizar a folha 1st Sprint. No planeamento é indicado o Sprint Backlog, apresentado as várias histórias e respectivas tarefas que vão ser concretizadas durante o sprint. Para cada tarefa é necessário indicar a sua categoria, quem é responsável 4
por fazer a tarefa e a estimativa para concretizar a tarefa. É ainda necessário actualizar a folha Availability Estimate, em que cada elemento do grupo deverá indicar o número de horas que tem disponível para trabalhar para o projecto de ES e SD para os vários dias do sprint em causa. Semanalmente, no início de cada sprint, cada grupo deve também produzir, um documento de texto com a retrospectiva do sprint anterior, onde indicam o que correu bem e de acordo com o planeado e o que correu mal ou conduziu a atrasos. Esse documento deverá ser colocado na sub-directoria info dentro do trunk do projecto rest. No fim de cada dia, cada aluno deve indicar o trabalho realizado. Na folha Actual Spent Time, cada aluno deverá indicar o número de horas que trabalhou para o projecto nesse dia. Na folha correspondente ao sprint em causa, cada aluno deve indicar, na coluna correspondente ao dia em causa, as horas que ainda faltam para terminar cada uma das tarefas a que está atribuído. Uma componente da nota desta parte do projecto de ES dependerá da qualidade da gestão do projecto aplicada pelo grupo. Esta componente valerá 6 valores. A folha de cálculo com o resultado da aplicação do SCRUM à gestão do projecto será consultado várias vezes durante cada Sprint pelos docentes das aulas de laboratório para aferir da qualidade da aplicação da metodologia SCRUM na gestão semanal do trabalho do grupo. 5
6. Estado inicial da Aplicação Relativamente ao estado persistente inicial da aplicação é necessário considerar as seguintes actualizações: O preço máximo dos pratos é 7 euros. Os clientes mariazinha, zeze, bruno e carlos têm como número de identificação fiscal (NIF) 1111, 2222, 3333 e 4444, respectivamente. O portal passa também a ter um NIF, que deverá ser utilizado nas facturas passadas pelo portal relativamente às compras feitas pelos clientes do portal. Assim, o portal tem o NIF 1234 e nome PortalRest. Tal como nas entregas anteriores, cada grupo deverá concretizar uma classe que deverá ter o método main que terá como responsabilidade a inserção dos dados relativos ao cenário de teste na base de dados. A execução deste método deve ficar atribuída ao target populate do ficheiro Ant build.xml. 7. Entrega da Quarta Parte do Projecto O prazo de entrega da quarta parte do projecto é o dia 14 de Maio de 2014 às 20h00. 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_4. 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 7.1. 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. Ficheiros gerados automaticamente pelo GWT também devem ser ignorados e não devem ser mantidos no repositório de cada grupo. Só os ficheiros necessários para a execução do código em eclipse (.classpath e.project, por exemplo) ou que não são gerados automaticamente é que devem devem ser incluídos no repositório. Grupos que tenham realizado dois projectos distintos, um para executar em modo local para ES e outro para executar em modo distribuído para SD, em vez de terem tudo integrado num único projecto que se pode executar nos dois modos, terão também uma penalização na nota. 6