Java SE: Aprendendo o padrão MVC

Este artigo é direcionado a iniciantes em programação que já aprenderam lógica de programação e conseguem implementar algoritmos simples na linguagem Java. A partir desse ponto deve-se aprender a modelar sistemas maiores de maneira profissional. Atualmente isso é feito através da modelagem Orientada a Objetos, utilizando, por exemplo, a UML (Unified Modeling Language).

A atividade de modelagem de um sistema consiste em transformar as necessidades definidas pelos clientes, documentadas nos requisitos do sistema, em uma série de representações desses requisitos e das estruturas de software que deverão ser implementadas para atendê-los. É comum construirmos o Diagrama de Casos de Uso para representar os requisitos do sistema, incluindo sua documentação para indicar os cenários de utilização. Em seguida construímos o Diagrama de Classes, que representa a estrutura do sistema em termos das entidades que ele deve manipular. Outro diagrama muito importante é o de Sequência. O objetivo de se construir esse diagrama é o de validar se as classes estão adequadas para suportar todas as interações previstas nos Casos de Uso e consequentemente revisar e melhorar o diagrama de classes. A construção de outros diagramas pode ser necessária dependendo do tipo de sistema, sua complexidade e seu tamanho, no entanto, os três considerados básicos são: casos de uso, classes e sequência.

Mesmo considerando apenas o diagrama de classes, sabemos que aprender a modelar quando ainda temos pouca experiência com desenvolvimento de software (principalmente com programação) não é tarefa fácil. E fica ainda mais difícil quando não conseguimos visualizar como aquele modelo que acabamos de construir vai ser transformado efetivamente em código. Este artigo pretende reduzir a distância entre a modelagem e a implementação, mostrando como um diagrama de classes é transformado em código.

Estudo de Caso: Sistema Bancário Simples

Vamos trabalhar sobre um exemplo para entender o processo de transformação do projeto do sistema representado em um diagrama de classes para o código fonte. Escolhemos para tanto um Sistema Bancário simples, uma vez que ele possui requisitos amplamente conhecidos. Basicamente teremos o cadastro de clientes e suas contas no banco, que podem ser dos tipos comum ou especial. Além disso, serão suportadas operações de depósito e saque sobre as contas do banco.

Veja a seguir a lista mais detalhada de requisitos:

· O sistema deve permitir que clientes fossem cadastrados, incluindo seu nome e e-mail;

· O sistema deve permitir que clientes possuíssem contas no banco. Cada cliente pode ter várias contas, e pode também não ter nenhuma conta criada;

· Cada conta do banco deve pertencer a um único cliente, não sendo permitidas contas conjuntas;

· As contas são divididas em dois tipos: comum e especial;

· As contas do tipo comum possuem um saldo e sobre elas é possível realizar saques e depósitos. Saques que venham a superar o valor do saldo da conta não são autorizados;

· As contas especiais possuem um saldo e um limite, e sobre elas é possível realizar saques, depósitos e modificação do limite da conta. Saques que superem o valor do saldo acrescido do valor do limite não são autorizados.

Não foi considerado, entre muitas outras coisas, que o sistema bancário deveria incluir vários bancos e que transferências de valores podem ser realizadas entre contas de bancos diferentes. No nosso exemplo temos modelado apenas um banco e as contas de seus clientes. Esse pequeno conjunto de requisitos levou à construção do diagrama de classes apresentado na Figura 1.

Figura 1. Diagrama de Classes do Sistema Bancário (Criado utilizando ASTAH – Community Edition).

O diagrama enfatiza a camada Model, composta pelas classes Cliente, Conta, ContaComum e ContaEspecial, sendo apresentados os seus atributos, os principais métodos e as associações entre classes. As duas outras camadas, Controller e View, estão apresentadas de forma resumida através dos estereótipos Control e View. Essa é a representação típica da arquitetura de um sistema organizado em três camadas, como a que é utilizada no padrão MVC (Model-View-Controller).

Ainda considerando o diagrama da Figura 1, alguns detalhes são importantes de se destacar sobre as classes da camada Model. A classe Cliente é bem simples, possuindo apenas dois atributos, o nome e o e-mail. A classe Conta é uma classe abstrata que contém atributos e métodos que são comuns entre os tipos de contas manipulados pelo sistema. Ela é abstrata porque nunca teremos nenhuma conta cadastrada no banco que não seja ou comum ou especial. Portanto, essa classe não será instanciada diretamente, sempre teremos instâncias de classes derivadas dela.

As classes ContaComum e ContaEspecial, por sua vez, fornecem as implementações e atributos específicos para cada um dos tipos de conta que podem ser manipuladas no nosso sistema bancário. Observe que ContaEspecial tem um atributo a mais para lidar com a definição do limite de crédito do cliente.

Essas são as classes da camada Model apresentadas em detalhes. Assim já temos um diagrama de classes que pode suportar o início da implementação. Em uma situação real, seria importante também fazer protótipos de telas da aplicação e revisar a lista de requisitos para verificar se as telas e a camada de controle vão suportar a implementação de todos os requisitos.

Implementação da Camada Model

Mesmo no nosso sistema bancário simplificado podemos ter um grande número de clientes cadastrados, cada um com várias contas. É natural se imaginar que essas informações estariam armazenadas em um banco de dados e não residindo exclusivamente em memória. A implementação da camada Model deve, portanto, suportar o carregamento de informações do banco de dados para objetos em memória e vice- ...