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.
O formato como a especificação de casos de uso foi apresentada nesta tabela é uma sugestão. Existem vários templates diferentes que podem ser utilizados para este
fim. De qualquer forma, o importante é descrever os requisitos do sistema com um maior grau de detalhamento, permitindo um melhor entendimento do problema e oferecendo melhores mecanismos para as etapas seguintes do processo de desenvolvimento. Neste formato utilizado, vale a pena observar:
• Nome do caso de uso: deve conter o mesmo nome do caso de uso que está no diagrama em questão e que será detalhado;
• Descrição: um resumo da utilidade do caso de uso;
• Ator envolvido: é o ator quem executa o caso de uso, o mesmo do diagrama de casos de uso. Em determinadas situações, pode haver mais de um ator envolvido;
• Interação entre o ator e o sistema: descreve os passos envolvidos na realização do caso de uso, evidenciando as responsabilidades do ator e do sistema, num processo interativo;
• Exceções: indicam situações onde, primordialmente, o tratamento de erros deve ser efetuado;
• Alternativas: indicam situações opcionais que podem ocorrer durante o cenário que está sendo descrito pelo caso de uso;
• Regras de Negócio: são as regras impostas para a utilização do caso de uso, definidas pelo domínio da aplicação;
• Requisitos de Interface com o Usuário: descrevem características que devem ser implementadas na interface com o usuário.
A partir da definição dos requisitos, pode-se passar para a fase seguinte de modelagem, incluindo as etapas de Análise e Projeto, discutidas na próxima seção.
Modelagem do sistema
A análise envolve a modelagem do problema propriamente dito, sem se preocupar com características computacionais, enquanto o projeto se preocupa com a transformação da análise em algo que possa ser implementado, ou seja, envolvendo restrições e características computacionais.
Durante a etapa de Análise utilizando a UML, é recomendado que seja construído o diagrama de classes, conforme pode ser visto na Figura 2. Na utilização da ferramenta Jude, deve-se primeiro criar um pacote chamando-o de “entity”, que conterá as classes de domínio do modelo.
Figura 2. O Diagrama de Classes.
Neste diagrama observa-se a presença de uma classe para cada elemento identificado do domínio da aplicação, como Cliente, Frete e Cidade, cada um contendo seus atributos específicos. O sinal de “-” que precede cada atributo representa que o mesmo é encapsulado, ou seja, protegido das demais classes, somente podendo ser modificado pela própria classe. Este é um conceito importante da orientação a objetos, chamado encapsulamento, e deve ser respeitado. A última divisão das classes apresenta seus métodos, que são normalmente públicos (representado pelo sinal
“+”), estando disponíveis para quaisquer outras classes.
As classes ainda estão relacionadas através de uma linha simples orientada, representando uma Associação com navegabilidade unidirecional. Desta forma, um Cliente está associado a vários Fretes, enquanto um Frete é obrigatoriamente
de um único Cliente. Em função da navegabilidade, a classe Frete terá um ponteiro para a classe Cliente, mas a classe Cliente não terá uma lista de objetos da classe Frete. Este tipo de restrição é comum de ser feita, simplificando a construção do sistema e diminuindo o acoplamento entre as classes. Leitura análoga pode ser feita entre as classes Frete e Cidade.
Este diagrama não tem por objetivo ser exaustivo na utilização dos elementos de modelagem de um diagrama de classes, mas sim subsidiar a construção da aplicação de exemplo.
Normalmente se utiliza de um desenvolvimento incremental e iterativo quando se desenvolve software orientado a objetos. Desta forma, é comum construir este diagrama inicialmente em mais alto nível de abstração, detalhando-o posteriormente. Além disso, nesta fase de análise, percebe-se que a preocupação é relativa apenas com os elementos do domínio, não importando, por enquanto, classes de interface e persistência (armazenamento) de objetos, que são preocupações da fase de projeto.
Na construção deste diagrama de classes, iniciantes em desenvolvimento OO normalmente mostram maior dificuldade na identificação dos métodos, mais do que classes, atributos e relacionamentos. Além disso, o diagrama de classes, apesar de muito importante para o desenvolvimento de aplicações orientadas a objetos, não possui o detalhamento necessário para a codificação de cada um dos casos de uso identificados. A construção dos diagramas de seqüência, um (ou mais de um) para cada caso de uso do sistema, além de ajudar na identificação dos métodos das classes, também detalha o funcionamento de cada caso de uso, numa visão orientada a objetos. A Figura 3 apresenta o diagrama de seqüência para o caso de uso
CadastrarFrete.
Figura 3. O Diagrama de Seqüência para o caso de uso CadastrarFrete.
Percebe-se que o diagrama de seqüência retrata a interação entre o ator e o sistema, conforme descrito na especificação do caso de uso em questão, como exemplificado na Tabela 1, evidenciando a chamada de mensagens entre as classes. Na primeira linha do diagrama aparecem as classes e objetos envolvidos no caso de uso, possuindo uma linha perpendicular que representam suas linhas de tempo. As setas indicam chamadas de métodos e devem respeitar a linha do tempo de cada objeto/classe. Observa-se ainda que, quando um novo objeto é instanciado, a mensagem chega na lateral da caixa que representa a classe, como acontece com o serviço que instancia um novo objeto da classe Frete. Este diagrama também foi construído em nível mais alto de abstração, podendo ser refinado posteriormente.
Esta etapa de Análise é responsável pela construção dos modelos que representam o domínio da aplicação, sem a preocupação com restrições ou características computacionais. Isto é responsabilidade da etapa de Projeto, descrita a seguir.
Projeto do sistema
O projeto considera as características computacionais da aplicação e, para este estudo de caso, definiu-se utilizar a linguagem Java com a IDE de desenvolvimento NetBeans em sua versão 5.0, com o kit de desenvolvimento da Sun versão 5.0. Será ainda utilizado o banco de dados relacional MySQL para a persistência dos objetos e, para o mapeamento objeto-relacional será utilizado o framework Hibernate (maiores informações podem ser obtidas nos endereços descritos na seção Links no fim do artigo).
O framework Hibernate tem o propósito de atuar como intermediário entre o modelo orientado a objetos e o modelo relacional, uma vez que atualmente os bancos de dados relacionais são o padrão de mercado, necessitando assim de uma solução de mapeamento objeto-relacional. A Figura 4 apresenta um diagrama de classes apresentando o projeto do sistema considerando suas características computacionais. Atributos e métodos foram omitidos para simplificar o entendimento do diagrama.
Figura 4. Diagrama retratando o projeto do sistema.
Este diagrama apresenta apenas as classes que serão implementadas neste estudo de caso, considerando interface com o usuário e persistência de objetos. Assim, apresenta a classe de interface com o usuário (JanelaCadastrarFrete), que terá uma referência para a classe FreteHiberateDAO, responsável pela persistência dos objetos da classe Frete, utilizando DAO (ver Nota 1) através do framework Hibernate. Esta classe está associada à outra chamada ConnectDB, responsável por fazer a conexão com o banco de dados MySQL, além de configurar o acesso via Hibernate. A classe FreteHibernateDAO depende das três classes de domínio, uma vez que é responsável por persistir objetos do tipo Frete, e associá-los a objetos do tipo Cliente e Cidade.
No caso de construção da aplicação completa, surgiriam outras classes responsáveis pela persistência das demais classes de domínio.
Nota 1. DAO (Data Access Object)
DAO (Data Access Object) é um padrão de projeto (design pattern) que tem por objetivo separar a lógica de acesso dos dados da lógica do negócio, provendo operações CRUD (Create, Read, Update, Delete) para fontes de dados.
Definida a forma de implementação da aplicação, podese passar para a etapa da implementação propriamente dita, descrita a seguir.
Implementação do sistema
Após terminados os processos de análise e projeto, inicia-se a etapa de implementação do sistema. Deverá ser criado um diretório chamado “transportadora” em qualquer lugar da árvore de diretórios da máquina. Dentro deste, criar um subdiretório chamado “src”, que é o diretório que armazenará os códigos fontes da aplicação.
Criação do banco de dados
Como primeiro passo, em função da utilização de uma abordagem objeto-relacional, torna-se necessária a modelagem e construção de um banco de dados
relacional. Para isso, a Figura 5 apresenta o modelo de dados a ser utilizado neste
estudo de caso, construído com a ferramenta CASE DBDesigner, com o objetivo de gerar o script de criação para o SGBD MySQL.
...
