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."