2 Projeto Detalhado
A arquitetura de software do sistema baseia-se em uma combinação dos estilos de Modelo de domínio e Padrão Camada de Serviço com a intenção de tornar a aplicação mais organizada e fácil manutenção. Inicialmente, três partições principais foram definidas para o sistema, procurando-se preservar a divisão em camadas do padrão MVC. Cada uma dessas camadas, por sua vez, está disposta da seguinte forma: Camada de Interface com Usuário (View), Camada de Lógica de Negócio (Control) e Camada de Persistência (Model). A Figura 3 mostra a arquitetura proposta.
O projeto deve ser fortemente orientado a baixo acoplamento e alta coesão, primando pela melhor separação de responsabilidades. Todo o projeto deverá ser feito utilizando uma arquitetura separada em camadas conforme apresentado como requisito não funcional, onde cada camada conterá apenas os algoritmos relacionados à sua responsabilidade.
A camada de View (Interface) deve conter apenas as lógicas de telas, validações de campos, acionamentos de comandos, códigos para design de interface etc. A camada de Controle deve conter as lógicas de autenticação, auditoria, manutenção de usuários, lógicas não relacionadas a interfaces gráficas, regras de negócio, dados (comandos SQL ou para utilização de mecanismos de persistência ORM) e segurança. A camada de modelo conterá os objetos mapeados para a implementação contendo seus atributos e métodos para interação dos objetos.
Nesta seção descrevemos objetivamente as tecnologias utilizadas na primeira parte do desenvolvimento do projeto.
O sistema em questão trata-se de um Sistema de Informação e levando em consideração suas características, optamos por escolher as seguintes tecnologias:
| Ferramenta | Tipo |
|---|---|
| Java | Linguagem,de Programação |
| PostgreSQL | Banco,de Dados Relacional |
| JPA | API,de Persistência |
| JDBC | API,de Persistência |
| Hibernate | Frameworks de Mapeamento objeto/relacional |
| Driver | Driver API-Nativo |
| Java,Swing | API,de Interface Gráfica |
Como o sistema não será nosso, mas sim do Corpo de Bombeiros Militar do Espírito Santo - CBMES, optamos por utilizar uma linguagem já utilizada dentro da corporação, para assim facilitar manutenção que será aplicada pelos mesmos.
Optamos pelo PostgreSQL pelo mesmo motivo que optamos pelo JAVA, facilitar a manutenção por parte da CBMES. Além de ser um banco bem robusto e ser open source.
JPA é uma especificação de Persistência da plataforma Java, para persistir as classes java em bancos de dados relacionais. Java Persistence API. Usaremos ela para facilitar a utilização do banco em Java.
JDBC é um conjunto de classes e interfaces (API) escritas em Java que fazem o envio de instruções SQL para qualquer banco de dados relacional. O JDBC será usado por nós por ser uma API de baixo nível e servir de base para a API JPA de mais alto nível.
Hibernate é um framework de mapeamento objeto/relacional que implementa as funcionalidades da JPA. Usaremos esse framework para simplificar o desenvolvimento.
O driver API-Nativo traduz as chamadas JDBC para as chamadas da API cliente do banco de dados usado. Como a Ponte JDBC-ODBC. Será usado por nós para para conectar e interagir com a base de dados (sdro) desenvolvida por nós.
O Swing é um framework que disponibiliza um conjunto de elementos gráficos para ser utilizado na plataforma Java.
O acesso ao sistema será liberado somente para pessoas autorizadas, nesta tela o usuário poderá entrar com seu login e senha para ter acesso ao sistema.
Tela que é mostrada logo após fazer um login, a partir dela é possível acessar todas a outras funções acessado a barra de menus na parte superior da tela.
Tela onde é listada todas as Unidade, ao clicar em uma das unidades você é redirecionado para a tela de Cadastrar/Alterar/Excluir Unidades.
Nessa tela será realizado o cadastro de uma unidade, o usuário entrará com os dados da unidade e em seguida terá que adicionar um Comandante e Subcomandante, que serão os responsáveis pela Unidade. Nesta tela também é feita a alteração dos dados da Unidades.
Nessa tela será realizado o cadastro das viaturas de uma Unidade, o usuário entrará com os dados do veículo e ao clicar em salvar o veículo será cadastrado.
Nesta tela será possível visualizar uma listagem de Viaturas, e ao clicar em uma das Viaturas os dados aparecerão abaixo, e assim sendo possível editar esses dados e salvá-los.
Nessa tela será possível cadastrar os materiais de uma Unidade, o usuário entrará com os dados do equipamento e ao clicar em salvar ele será cadastrado no sistema.
Tela onde será feita a edição de equipamentos. Na barra “Pesquisar” será digitado o nome do equipamento, na listagem abaixo ele será selecionado e assim podendo editá-lo ou excluí-lo.
Nessa tela será realizada a criação de um SCO, o usuário entrará com os dados do SCO e logo em seguida deverá adicionar os recursos na área “Adicionar recursos”.
Nessa tela será realizado o cadastro das Equipes, o usuário entrará com os dados e ao clicar em salvar a Equipa será cadastrada.
Tela onde será feita a edição de Equipe. Na barra “Pesquisar” será digitado o nome da Equipe, na listagem abaixo ele será selecionado e assim podendo editá-lo ou excluí-lo.
Tela onde é feita a alocação das viaturas, partindo da lista de viaturas, e os equipamentos disponíveis para determinada viatura.
De acordo com GAMMA (1998), MVC consiste em três tipos de objetos que compõem camadas bem definidas: Modelo (Model) é o objeto da aplicação, responsável por implementar a lógica da regras de negócio tal qual o armazenamento persistente. Visão (View) é camada que compõe a apresentação do sistema para o usuário. RUBY (2009) define o controlador (Controller) conduz a aplicação recebendo eventos do mundo externo, interagindo com o modelo e exibe uma visão apropriada.
GAMMA (1998) salienta que MVC desacopla visões e modelos estabelecendo um protocolo de subscrição/notificação entre eles. A visão deve assegurar que sua aparência reflita o estado do modelo, ao passo que, sempre que houver alterações nos dados do modelo, o mesmo notifica a visão que depende desses dados, de forma que essa visão possa se atualizar. Essa abordagem permite que sejam criadas diferentes visões para um mesmo modelo sem necessidade de alterá-lo, sendo esse um importante aspecto ao se tratar de aplicações web que, em sua maioria, são destinadas à utilização em múltiplas plataformas que podem demandar diferentes tratamentos de interface, enquanto preservam o mesmo modelo em um único servidor remoto ou em bases distribuídas.
Segundo um artigo publicado pela Oracle em 2002, o DAO gerencia a conexão com a fonte de dados para obter e armazenar dados. O DAO implementa o mecanismo de acesso necessário para trabalhar com a fonte de dados. A fonte de dados pode ser um armazenamento persistente, um serviço externo, um repositório, ou um serviço de negócios. O componente de negócios que depende do DAO usa a interface mais simples exposta pelo DAO. O DAO oculta completamente os detalhes de implementação da fontes de dados. Isso permite que o DAO se adapte a diferentes esquemas de armazenamento sem afetar seus clientes ou componentes de negócios. Essencialmente, a DAO atua como um adaptador entre o componente e a fonte de dados.
Segundo GAMMA (1998), o objetivo do Singleton "Garantir que uma classe tenha somente uma instância e fornece um ponto global de acesso para a mesma". Com o uso do padrão garantimos que só teremos uma instância de um determinada classe.