Desenvolvimento das Camadas Lógica e
Persistência do Projeto SIAP-F
Henrique Schaefer
Vitor Ferreira Isaia
Bacharelado em Sistemas de Informação, 2006
Universidade Federal de Santa Catarina
(hique@inf.ufsc.br) (vitofisa@inf.ufsc.br)
RESUMO
No presente trabalho apresenta-se uma solução para as camadas lógica e de persistência para o SIAP-F (Framework de acompanhamento de pedidos). O framework foi projetado para atender desde pequenos negócios até linhas de montagem, fornecendo informações de cada etapa do processo, para acompanhamento via web. Foi utilizada a arquitetura de 3 camadas (apresentação, lógica e persistência), para que a identificação dos papéis dentro do framework ficasse totalmente clara.
PALAVRAS-CHAVE:
Regras de Negócio, Persistência de dados, XML, Java, Hibernate, Acompanhamento de pedidos, Micro e Pequenas Empresas.INTRODUÇÃO
Em várias organizações, a relação entre cliente / empresa se dá da seguinte maneira: o cliente solicita a compra de um produto ou serviço; após isso, o mesmo entra em uma fase de produção (ou
desenvolvimento), para que então o cliente possa receber tal produto (ou serviço).
Para o cliente, é muito importante ter um feedback do status do seu pedido, o que não é possibilitado principalmente em empresas pequenas. Pedidos simples, como uma pizza ou um medicamento, por exemplo, podem facilmente superar o prazo dado, causando um problema quando a pessoa tem um imprevisto, por exemplo.
Atacando estes fatores, pode-se observar que o SIAP-F possui uma grande viabilidade comercial, não existindo no mercado ferramenta semelhante.
OBJETIVO GERAL
O objetivo deste trabalho é o desenvolvimento da Camada Lógica e da Camada de Persistência do Projeto SIAP -F (Sistema de Acompanhamento de Pedidos – Framework), um framework que tem como propósito agilizar o desenvolvimento de sistemas de informação dedicados ao acompanhamento de pedidos. A intenção é capturar e implementar os requisitos
comuns a um sistema de acompanhamento de pedidos no que diz respeito à lógica de negócio e à persistência de dados, fazendo com que o desenvolvimento de novos sistemas com este fim sejam agilizados.
OBJETIVOS ESPECÍFICOS
- Desenvolver uma aplicação como modelo para o framework;
- Desenvolver um framework para sistemas de acompanhamento de pedidos.
METODOLOGIA
Como metodologia foi definida o desenvolvimento de uma aplicação exemplo, para levantar os possíveis requisitos que possam fazer parte do framework.
A aplicação implementa um sistema mais simples de acompanhamento de pedidos, com poucas etapas. Foi desenvolvido um sistema para uma pizzaria, que é composto por 3 etapas para os clientes (pedido efetuado, montando pizza e em entrega), incluindo o cadastro dos mesmos e o gerenciamento dos produtos.
ARQUITETURA
A Arquitetura de Três Camadas foi originada após o advento do modelo cliente-servidor e também dos servidores Web. Esta arquitetura visa subdividir e delegar as tarefas relacionadas de uma aplicação de uma maneira distribuída, buscando se obter maior performance e melhor abrangência. Utilizando esta arquitetura cada camada pode ser desenvolvida de forma independente, dando possibilidades de cada especialista
executar o melhor do seu trabalho, ou seja, cada camada (Apresentação, Lógica e Persistência) pode ser substituída ou novamente implementada sem que as outras camadas sofram alterações.
Fig. 1: SIAP-F: Arquitetura de 3 camadas
Definição das camadas abordadas:
• Camada Lógica: Responsável por abranger a regra de negócio da aplicação e controlar o fluxo de dados, fazendo uso dos dados provenientes da Camada de Apresentação. Esta camada também se comunica com a Camada de Persistência, requisitando serviços de armazenamento de dados ou de busca dos mesmos, para efetuar tratamentos de
acordo com a regra de negócio e repassar as informações para a Camada de Apresentação.
• Camada de Persistência : Camada responsável pelo armazenamento dos dados da aplicação. Somente esta camada comunica-se com o banco de dados.
CAMADA LÓGICA
A Camada Lógica (CL) do framework SIAP -F, como o próprio nome já diz, é responsável por abranger toda e qualquer lógica de negócio relativa ao problema de acompanhar um pedido. Trata as requisições vindas da camada de Apresentação, controlando o fluxo das informações e tratando os possíveis ganchos que forem implementados, comunicando-se com a camada de Persistência para armazenar ou buscar dados.
A CL trata, basicamente, de dois fluxos: o fluxo de registro e o fluxo de acompanhamento, cada um com suas particularidades.
Na etapa de desenvolvimento desta camada, foram identificados os objetos de negócio básicos que fariam parte do escopo de acompanhar um pedido. São eles:
• Cliente: Entidade que realiza o
pedido, portando está diretamente relacionado ao mesmo.
• Produto: Entidade a ser incluída ao
pedido, ou seja, aquilo que é o objeto-alvo a ser acompanhado.
• Pedido: Entidade que representa o
pedido em si, se relaciona ao cliente e ao produto, não existindo jamais um pedido
sem um e somente um produto e um e somente um cliente relacionado.
• Etapa: Entidade que representa a(s)
etapa(s) dentro do processo do pedido.
Além do mapeamento das
entidades do domínio do problema, nesta etapa também foram identificados os objetos que realizam literalmente o controle lógico. Assim, a camada Lógica tem sua complexidade desmembrada em categorias de classes, que são:
• Façade: Nível mais externo da
camada Lógica. Responsável por oferecer todos os serviços disponíveis, definidos na interface ILogicFacade, a ser vista adiante.
• Factory: Responsável por
disponibilizar objetos que implementem a interface
ILogicFacade.
• Configuration: Responsável pela
configuração da camada lógica, realizando a leitura do arquivo siapf-config.xml.
• DTO: Responsável pelo
encapsulamento de dados a serem trafegados entre a camada Lógica e as camadas de apresentação e de persistência.
• Controller: Responsável por
delegar as requisições aos objetos responsáveis, que são, no caso, os objetos Processor.
• Processor: Têm a responsabilidade de processar as requisições, tanto de registro como de acompanhamento,
executando os possíveis ganchos, caso existam.
CAMADA DE PERSISTÊNCIA
A Camada de Persistência (CP) do framework SIAP-F tem um papel muito importante, que é o de armazenar os dados, ou seja, os persistir. O armaze namento dos dados é feito em um banco de dados relacional. Com isso, a técnica de modelagem que foi utilizada aqui é a de entidade-relacionamento. Uma entidade representa um conjunto de dados da realidade modelada. Tais entidades possuem relacionamentos entre si, que significam a associação entre objetos (entidades) de um banco de dados.Assim como a Camada Lógica, a Camada de Persistência também teve suas classes dividas em categorias, que são:
• Façade: Fachada. É a “porta de entrada” da camada de persistência. Possui todos os métodos relevantes com relação à persistência dos dados. Cada método está associado ao objeto responsável pelo verdadeiro processamento a ser feito, devolvendo ou não um resultado. É importante ressaltar que não há nenhuma outra implementação da fachada que não seja a chamada de métodos de outros objetos. No camada de persistência do projeto SIAP-F existe um único facade, chamado de PersistenceFacade, que implementa a interface IPersistenceFacade.
• Factory: Classe com um ou mais métodos que devolvem instâncias de um objeto. O retorno destes métodos é um objeto instanciado que implementa determinada interface, a ser utilizada pelo cliente que utiliza a factory. No
projeto SIAP-F existe uma única factory, chamada de PersistenceFactory, que devolve objetos que implementem a interface IpersistenceFacade, através de um método estático.
• Controller: Classe que realiza a chamada dos métodos do objeto da categoria DAO, a ser visto adiante. Também realiza, antes de tais chamadas, eventuais conversões de objetos.
• DAO: Data Access Object. De acordo com a Sun (responsável pela tecnologia JAVA), o padrão DAO adapta uma API específica de acesso a banco de dados a uma interface genérica de acesso para o cliente. O padrão DAO permite a mudança do mecanismo de acesso ao banco de dados sem implicar em alterações no código que usa os dados. No projeto SIAP-F, as classes que seguem o padrão DAO são aquelas que fazem uso das bibliotecas do Hibernate, a ser detalhado adiante.
• POJO: Plain Old Java Object. Trata-se de objetos Java comum, Trata-sem nenhuma lógica dentro de seu código. Possuem apenas atributos e seus respectivos médotos de acesso (getters e setters). No projeto SIAP-F, as classes POJO são aquelas que estão associadas à tabelas, para a utilização do Hibernate. A estrutura de cada classe corresponde à estrutura da tabela em que a classe está associada.
APLICAÇÃO EXEMPLO
Com o intuito de validar as camadas Lógica e de Persistência do
framework SIAP -F, foi criada uma aplicação exemplo baseada no mesmo, para uma loja de vendas de produtos on-line.
Nesta loja, foi considerada interessante a possibilidade de se obter informações sobre os clientes,
especificamente a respeito dos produtos que os mesmo adquirem. Com isso, no momento em que o cliente realiza um pedido, as informações a respeito dos produtos em que o mesmo pede são
armazenadas em um outro banco de dados, juntamente com as informações do cliente. Desta maneira a loja pode realizar
promoções personalizadas para os seus clientes, de acordo com as áreas de interesse dos mesmos.
Para que tais informações possam ser coletadas, foi realizada a
implementação deste gancho, estendendo a classe
BaseDemandRegistrationProcessor, implementando o método execute(). Dentro deste método, obtém-se o objeto DemandDTO, que possui as
informações (identificadores) do cliente e do produto relacionados ao pedido, para então estas informações serem repassadas ao banco de dados externo, que as
armazenará a realização das promoções mencionadas anteriormente, toda vez que um pedido for realizado.
VIABILIDADE COMERCIAL
O Framework SIAP-F, assim como os demais frameworks tem como grande vantagem o seu reuso. Com isso o desenvolvimento de aplicações fica acelerado, gerando mais resultados em menos tempo e com maior qualidade.O público alvo do SIAP-F são empresas de pequeno e médio porte que não possuem condições de desenvolver ou encomendar o desenvolvimento de um software personalizado, assim como condições de adquirir softwares já prontos, pois estes não atendem somente o
acompanhamento de pedidos e sim em geral a administração completa da empresa.
E é justamente este o grande diferencial do SIAP-F, pois o mesmo prioriza atender primeiramente o acompanhamento de pedidos, obviamente atendendo também caso necessário, outros setores da empresa diretamente associados ao pedido, como por exemplo, o setor de vendas e/ou o de estoque. O SIAP -F está preparado para atender a estes requisitos bastando para isso uma pequena implementação.
CONCLUSÃO
Vemos nas pequenas empresas o grande alvo do SIAP-F, devido à sua simplicidade e ao mesmo tempo eficiência, aliado às vantagens de se poder agregar as particularidades de cada caso.
Na realidade, tudo o que existe no mercado ou está voltado a um caso específico (como o de organizações que desenvolvem seus próprios sistemas, como por exemplo os Correios) ou apenas faz parte de um grande pacote de serviços de controle de uma empresa.
REFERÊNCIAS BIBLIOGRÁFICAS
[1] LARMAN, Craig – Utilizando UML e Padrões – Uma introdução à análise e ao projeto orientado à objetos .[2] ALUR, Deepak; MALK, Dans; CRUPI, Johns – Core J2EE Patterns – Best Practices and Design Strategies. Patience Hall PTR, 2nd Edition, 2003. [3] JBOSS GROUP – The Hibernate Tutoria l
http://www.hibernate.org (acesso: maio de 2005).
[4] MARTIN, Robert C. - Principles, Patterns, and Practices: The Factory Pattern
http://today.java.net/pub/a/today/2005/03/09/f actory.html (acesso: maio de 2005).
[5] SUN MICROSYSTEMS - Design Patterns: Data Access Object
http://java.sun.com/blueprints/patterns/DAO.h tml (acesso: maio de 2005).
[6] FERREIRA, Cleiton. –Tutorial: A Arquitetura de Três Camadas
www.portaljava.com/home/tutoriais/arquit etura_tres_camadas/arquitetura_tres_cama das.pdf (acesso: setembro de 2005).
