Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Artigo da SQL Magazine 36 - Desenvolvendo uma aplicação OO em Java com Hibernate
Artigo da SQL Magazine - edição 36.

Clique aqui para ler todos os artigos desta edição
Desenvolvendo uma aplicação OO em Java com Hibernate
Dos requisitos à implementação
O paradigma da orientação a objetos para desenvolvimento de sistemas é, sem dúvida, uma tecnologia que veio para ficar e está cada vez mais difundida e utilizada entre os desenvolvedores de software.
Entretanto, ainda existem muitas dúvidas sobre como utilizar de forma eficiente este paradigma, passando pela fase de levantamento de requisitos, análise, projeto, codificação e testes. Uma outra dúvida comum, e extremamente importante neste contexto, é como realizar a persistência (armazenamento) dos objetos, uma vez que os bancos de dados relacionais ainda são o padrão de mercado e, a princípio, incompatíveis com a tecnologia de objetos.
Neste sentido, este artigo tem por objetivo a construção de uma aplicação orientada a objetos passando, seqüencialmente, pelas principais etapas de um processo de desenvolvimento tradicional, como Levantamento de Requisitos, Análise, Projeto e Codificação.
A partir da descrição de um problema real, serão construídos alguns diagramas da UML (Unified Modeling Language), como os diagramas de casos de uso, classes e de seqüência, implementando o projeto com a linguagem Java e o framework Hibernate, para mapeamento objetorelacional no banco de dados MySQL.
Definição dos requisitos
O estudo de caso abordado neste artigo considera um fragmento de um sistema para uma Transportadora. Para esta versão simplificada do sistema, devem ser considerados os seguintes requisitos:
• O sistema deve permitir ao Funcionário cadastrar Clientes, contendo os dados: nome, endereço e telefone;
• O sistema deve permitir ao Funcionário cadastrar Cidades, que representam os lugares abrangidos pela empresa de transportes e contêm o nome da cidade, o estado a que pertence, e o valor para a taxa de entrega;
• O sistema deve permitir ao Funcionário cadastrar Fretes, contendo um código, uma descrição, o peso total, um cliente e a cidade de destino, não podendo haver um frete sem os dados citados. Cada frete deve ter ainda o seu valor, que deve ser calculado
através do peso multiplicado por um valor fixo, acrescido da taxa de entrega da cidade de destino.
A Figura 1 apresenta o diagrama de casos de uso para estas funcionalidades.
Figura 1. O Diagrama de Casos de Uso.
Desta forma, percebe-se que o diagrama de casos de uso, definido na linguagem UML, é um dos primeiros artefatos a serem construídos, logo após a identificação dos requisitos do sistema. Cada cenário de utilização será representado por um caso de uso (uma elipse no diagrama), e cada participante é chamado de ator, indicando quem executa aquele cenário no contexto do sistema. Os diagramas UML que serão apresentados ao longo deste artigo foram criados com a ferramenta CASE Jude Community (ver endereço da ferramenta na seção Links).
O diagrama de casos de uso é importante para dar uma visão geral das funcionalidades do sistema, mas não apresenta detalhamento suficiente para o entendimento total do problema, nem mesmo para estimativas relativas a tempo e custo de desenvolvimento. Desta forma, uma estratégia comum, apesar de não descrita formalmente na UML, é construir especificações mais detalhadas para cada
um dos casos de uso do sistema. A Tabela 1 apresenta a especificação do caso de uso CadastrarFrete. Os demais casos de uso também deveriam ser especificados de maneira análoga.
Tabela 1. Caso de Uso CadastrarFrete.
"
Este é um post disponível para assinantes MVPou para quem possui Créditos DevMedia. Clique aqui para saber mais!



