Objectivos


O objectivo deste laboratório é:

  • a construção de uma aplicação em camadas utilizando a Fénix Framework;
  • utilização de testes de Software por forma a aumentar a qualidade do projecto.

Contexto


A motivação para uma arquitectura em camadas é que cada camada comunica apenas com as duas camadas a ela adjacentes, diminuindo assim as dependências entre camadas: se uma camada for alterada só terá um eventual impacto em duas camadas, desde que se mantenha a interface das camadas adjacentes.

Seguindo as recomendações de Engenharia de Software, a aplicação a desenvolver deverá apresentar as seguintes camadas:

  • Camada de apresentação: é responsável pela interacção com o utilizador e pela forma como os dados da aplicação são apresentados ao utilizador.
  • Camada de serviços: é a camada que fica entre o a camada de apresentação e a camada de dados.  É responsável por suportar as funcionalidades, a realizar sobre o modelo do domínio da aplicação, que queremos disponibilizar à camada de apresentação. Cada funcionalidade deve ser concretizada como um serviço que irá depois invocar as operações necessárias sobre os objectos relevantes da camada de lógica de negócio. Esta invocação deve acontecer dentro do contexto de uma transacção da Fénix Framework.
  • Camada da lógica de negócio: esta camada representa o domínio da aplicação, concretizando não só a forma como os dados da aplicação são representados e guardados de forma persistente, mas também grande parte da lógica de negócio (e.g., regras de negócio). Esta camada é suportada fundamentalmente pela Fénix Framework.
Para que a camada de apresentação e a camada de lógica de negócio sejam independentes entre si, é necessário ter uma forma de representar os dados manipulados ao nível da camada de apresentação sem utilizar as entidades que descrevem esses dados na camada da lógica de negócio (classes Java geradas pela Fénix Framework após terem sido definidas num ficheiro DML). Para alcançar esta independência, utiliza-se o padrão de desenho Data Transfer Object (DTO). Assim, cada serviço será responsável por transformar os objectos do domínio da aplicação em objectos DTO. Uma classe do domínio pode ser representada através de uma ou mais classes DTO, dependendo do propósito da sua utilização.


Para desenvolver correctamente estas funcionalidades, deve consultar o seguinte FF Tutorial - Service Layer, que explica com mais detalhe como deve ser desenvolvida a camada de serviços. Para tal, o tutorial descreve a implementação de um serviço para a aplicação PhoneBook.

Os testes de software devem ser desenvolvidos utilizando framework de Testes JUnit.

Exercício


O objectivo do exercício a realizar durante a aula consiste em:

  • Concretizar os serviços pedidos para a aplicação PhoneBook. Estes serviços estão descritos no exemplo apresentado em baixo;
  • Adaptar a versão do código que os alunos entregaram, referente à primeira parte do projecto, de forma a ficar de alinhada com a arquitectura de referência introduzida nesta aula;
  • Dar início ao desenvolvimento da segunda parte do projecto, através da implementação de uma funcionalidade pedida no enunciado da 2ª parte do projecto.

Exemplo


A aplicação PhoneBook, que foi introduzida na 2ª aula de laboratório, já foi foi modificada para passar a incluir a concretização da camada de serviços. Deve aceder à versão da aplicação PhoneBook com a tag v2.1: git clone --branch v2.1 https://github.com/tecnico-softeng-distsys-2015/phonebook.git. Esta versão já inclui os seguintes serviços/funcionalidades:

  • Criar uma nova pessoa;
  • Criar um novo contacto para uma pessoa;
  • Remover uma pessoa dado o seu nome;
  • Remover um contacto dado o seu nome e o nome da pessoa a que pertence;

Depois de ter obtido a versão indicada, e ter visto o novo código realizado para concretizar estas funcionalidades e os casos de teste desenvolvidos para testar estes serviços, deve alterar esta versão por forma a incluir os seguintes serviços:

  • Obter todos os contactos existentes para uma dada pessoa;
  • Obter todos as pessoas registadas na aplicação;
  • Importar a agenda de uma pessoa, dado o seu nome;
  • Exportar a agenda de uma pessoa dado o seu nome;
  • Obter todos os contactos de uma pessoa cujo nome do contacto contém uma dada cadeia de caracteres;
Após ter desenvolvido estas funcionalidades pode comparar a sua solução com a solução apresentada na versão com a tag v2.2 da aplicação PhoneBook, a qual já tem concretizado parte destas funcionalidades.

Repare ainda que a classe SetupDomain (presente na versão 2.2) foi alterada, passando agora a utilizar os serviços em vez de aceder directamente à camada de domínio. Assim, esta classe fica independente da forma como o domínio da aplicação PhoneBook foi concretizado. Os restantes serviços deverão ser desenvolvidos fora do âmbito da aula para que os alunos ganhem destreza na concretização de serviços usando por base a arquitectura de referência proposta.