Documento de Projeto de Sistema 1 IFES / Serra Projeto: Gerenciador de Pelada - Oasis Registro de Alterações: Versão Responsável Data Alterações 0.1 Eduardo Rigamonte, Geann Valfré, João Paulo Miranda, Pietro Christ 0.2 Eduardo Rigamonte, Geann Valfré, João Paulo Miranda, Pietro Christ 06/12/2012 Criação do documento 05/02/2013 Alteração do documento 1. Introdução Este documento apresenta o documento de projeto do sistema Gerenciador de Pelada - Oasis. Este documento está organizado da seguinte forma: a seção 2 apresenta a plataforma de software utilizada na implementação do sistema; a seção 3 discute os requisitos não funcionais (atributos de qualidade), com ênfase naqueles considerados condutores da arquitetura, e as táticas utilizadas para tratá-los; a seção 4 apresenta o projeto da arquitetura de software; por fim, a seção 5 apresenta o projeto dos componentes da arquitetura. 2. Plataforma de Implementação O sistema em questão trata-se de um Sistema de Informação e apresenta as seguintes características: Envolve grande quantidade de dados e a sua gerência deve ser feita usando um banco de dados; Usuários acessam os dados concorrentemente via Web; Há uma grande quantidade de interfaces com o usuário; Levando-se em consideração essas características, decidiu-se implementar o sistema Gerenciador de Peladas usando a linguagem de programação Java, o banco de dados relacional PostgreSQL, a API JPA com o framework de mapeamento objeto-relacional EclipseLink e a linguagem JSP + Servlet para desenvolvimento de interfaces gráficas para web. 3. Atributos de Qualidade e Táticas
Na Tabela 2 são listados os atributos de qualidade considerados condutores da arquitetura e as táticas a serem utilizadas para tratá-los. Categoria Requisitos Não Funcionais Considerados Condutor da Arquitetura Tática Manutenibilidade RNF04 Sim Uso de um intermediário para isolar o mecanismo de persistência de dados. Separar a interface com o usuário do restante da aplicação. Uso de um intermediário para tratar as requisições da interface. Usabilidade RNF02 Sim Prover ao usuário uma interface amigável e de fácil aprendizado. Serão utilizadas técnicas de seleções na interface para facilitar o uso do sistema para o usuário. Registro unificado de informações que são trabalhadas em conjunto. Portabilidade RNF01 Não Uso da linguagem Java com mecanismos capazes de rodar nos sistemas operacionais Windows e Linux. Possibilitar o uso em qualquer navegador de internet. Tabela 2 Atributos de Qualidade e Táticas Utilizadas. 4. Arquitetura de Software A arquitetura de software do sistema baseia-se em uma combinação dos estilos em partições e camadas. Visando ao desenvolvimento com reuso, foi reutilizado o Utilitário Persistência (utilitariopersistencia) e o Utilitário Notificação. Este compõe o pacote Utilitário (utilitario). A Figura 1 mostra a arquitetura proposta.
Figura 1 Arquitetura de Software. As partições mostradas na Figura 1, por sua vez, estão organizadas em três camadas, a saber: Camada de Interface com o Usuário (ciu), Camada de Lógica de Negócio (cln) e Camada de Gerência de Dados (cgd). A Camada de Interface com o Usuário (ciu), por sua vez é formada pelo Componente de Controle de Interação (cci) e pelo Componente de Interface Humana (cih). Por fim, a Camada de Lógica de Negócio (cln) é formada pelos seguintes componentes: Componente de Gerência de Tarefas (cgt) e Componente de Domínio do Problema (cdp). 5. Projeto dos Componentes da Arquitetura Conforme discutido anteriormente, a arquitetura de software do sistema baseia-se na combinação de camadas e partições. Inicialmente, para cada subsistema identificado na fase de análise, foi definida uma partição. O sistema, por sua vez, está organizado em três
camadas: Camada de Lógica de Negócio, Camada de Interface com o Usuário e Camada de Gerência de Dados. A seguir o projeto desses componentes é apresentado. 5.1 Sistema OASIS 5.1.1 Camada de Lógica de Negócio Para organizar a camada de lógica de negócio deste sistema, foi escolhido o padrão Camada de Serviço. Sendo assim, essa camada é dividida em dois componentes: Componente de Domínio do Problema (cdp) e Componente de Gerência de Tarefas (cgt). Esse padrão utiliza um componente para tratar a lógica de aplicação (o cgt), o qual recebe as requisições da interface, e um componente para tratar os conceitos do domínio do problema, advindos do modelo conceitual estrutural elaborado na fase de análise (o cdp). A seguir, o projeto desses dois componentes é apresentado. 5.1.1.1 Componente de Domínio do Problema (CDP) A Figura 2 apresenta o diagrama de classes do CDP do sistema Oasis. Figura 2 Diagrama de Classes do CDP do sistema Oasis Foi introduzido o tipo enumerado StatusPelada com o fim de prover um grupo fechado de dados, para evitar erros de entradas de dados e padronizar o sistema. Na classe Jogador o atributo timetorce foi transformada em classe, visando uma busca mais eficiente. 5.1.1.2 Componente de Gerência de Tarefas (CGT) No projeto do CGT, optou-se por criar classes gerenciadoras que abrangessem casos de uso que possuíssem fortes relacionamentos. Os aspectos relevantes para o agrupamento foram: deixar o controlar peladas junto com o enviar notificações, pois ambos quase sempre serão feitos no mesmo momento; deixar o confirmar presença e o cadastrar jogador juntos,
pois estão no mesmo contexto; os outros casos de uso ficaram com um componente de gerência próprio. A Tabela A sumariza as relações existentes entre as classes do CGT e os casos de uso por elas tratados. Tabela A Classes do CGT e Casos de Uso. Classe AplControlarPelada AplControlarGrupos AplCadastrarJogador Casos de Uso Enviar Notificação, Confirmar Presença, Controlar Pelada Controlar Grupos Cadastrar Jogador Uma vez que o projeto do CGT está fortemente relacionado ao projeto da interface com o usuário, foi elaborado um único diagrama de classes, mostrando as classes do CGT e do CIU, o qual é mostrado na Figura 3. 5.1.2 Camada de Interface com o Usuário Para organizar a camada de interface com o usuário, foi adotado o padrão Modelo- Visão-Controlador (MVC). Sendo assim, essa camada possui classes de visão, mostradas no diagrama da Figura 3 com o estereótipo de classes de fronteira (<<boundary>>) da UML, e classes de controle de interação, mostradas no diagrama da Figura 3 com o estereótipo de classes controladoras (<<control>>) da UML.
Figura 3 - Diagrama de Classes (parcial) do CIU do Sistema Oasis. Foi decidido utilizar três classes controladoras de interação fazendo a ligação entre as classes de visão e as classes gerenciadoras de tarefa (modelo no padrão MVC) AplControlarGrupos, AplControlarPelada, AplCadastrarJogador e AplPrincipal. O login no sistema será efetuado na página principal, e assim que o usuário for autenticado, o sistema deverá liberar as funcionalidades correspondentes daquele usuário. 5.1.3 Camada de Gerência de Dados A persistência dos objetos deste subsistema é realizada em um banco de dados relacional, utilizando o framework de persistência EclipseLink. A figura 4 apresenta o diagrama de classes da Camada de Gerência de Dados (cgd) do Sistema Oasis. A Figura 4 mostra o projeto do Componente de Gerência de Dados para o sistema Oasis.
Figura 4 CGD do Sistema Oasis 5.2 Camada de Gerência de Dados A persistência dos objetos deste sistema é realizada em um banco de dados relacional, utilizando o framework de persistência EclipseLink, sendo desejável isolar os impactos da tecnologia de bancos de dados sobre o sistema. Assim, optou-se por adotar o Padrão DAO e foi utilizado o utilitariopersistencia, apresentado na Figura 11, que já trata vários dos aspectos desse padrão. Como mostra a figura, a classe DAOJPA possui uma referência à interface EntityManager que é instanciada pelo framework Spring em tempo de execução, usando a API JPA com EclipseLink. Além disso, as classes de domínio (cdp) a serem persistidas devem herdar da classe ObjetoPersistente, que provê identificadores únicos para os objetos (ids) a serem usados para mapear objetos em memória com as correspondentes linhas das tabelas. Figura 5 Diagrama de Classes do utilitariopersistencia.
Além disso foi utilizada a ferramenta SQL Power Architect para descrever o modelo relacional. A figura 6 mostra o diagrama relacional do banco de dados do sistema Oasis Figura 6 Modelo relacional.