Diego Lí Veira Potapczuk e seu blog

Design Pattern: Abstract Factory

O design pattern abstract factory consiste em uma padrão de projeto destinado a cuidar da criação de famílias de objetos relacionados ou dependentes sem especificar sua verdadeira classe.

Normalmente utilizado quando há uma variável usada para determinar qual objeto instanciar em diversos locais. O objeto abstract factory fica responsável para coordenar a família de objetos que o sistema necessita.

Sem o Abstract Factory aplicado

Com o Abstract Factory aplicado

Referência: SHALLOWAY, Alan; Design Patter Explained (2001).

Design Pattern: Singleton

O Design Pattern Singleton é usado quando existe a necessidade de garantir que exista apenas um determinado número de instâncias de uma determinada classe, normalmente apenas uma instância, dai o nome “Single” + “ton”.

Esse padrão é implementado criando-se um campo estático na classe que irá ter suas instâncias gerenciadas, contendo um objeto do seu próprio tipo, em seguida deve-se tornar privada o construtor da classe, fazendo com que nenhuma instância possa ser criada de forma direta. Em seguida é criado um método público que ficará responsável por entregar as instâncias dessa classe. Você pode optar por criar a instância assim que iniciar sistema, ou apenas quando ela for necessária:

Instanciar ao iniciar o sistema

public class gerenciadorDeClientes {
    private static gerenciadorDeClientes instancia = new gerenciadorDeClientes();

    public gerenciadorDeClientes getInstance(){
        return instancia;
    }

    private gerenciadorDeClientes(){}
}

Instanciar quando necessário

public class gerenciadorDeClientes {
    private static gerenciadorDeClientes instancia = null;

    public gerenciadorDeClientes getInstance(){
        if(instancia == null) {
            instancia = new gerenciadorDeClientes();
        }
        return instancia;
    }

    private gerenciadorDeClientes(){}
}

Diagrama de entidade relacional

Para o desenvolvimento do Sistema de gerenciamento de pousadas, é necessário um meio guardar seus dados, e para isso irá usar um banco de dados relacional. Então precisamos fazer um diagrama entidade relacionamento para ver as entidades que serão necessárias assim como seus relacionamentos, e também é claro para ajudar a normatizar o banco.

Essa é uma das principais partes da disciplina Banco de Dados dentro do projeto, pois após isso ter sido feito corretamente, e de nós termos a estrutura lógica do banco de dados, só irá restar gerar o script de criação do banco e das tabelas.

Protótipo do Gerenciador de Pousadas

Bom, após ter definido os requisitos e o escopo do sistema nós passamos para a etapa da prototipação, onde o objetivo pretendido era um protótipo não funcional das telas do sistema. Essa etapa foi feita de forma iterativa, primeiro com um protótipo feito no Corel que nos deu uma boa base de discussão para como seria o fluxo do sistema, e como ele seria dividido.

Primeira versão do protótipo feito com o Corel Draw

Uma coisa que foi observada com esse protótipo é que apesar da versatilidade do Corel, ele não é uma ferramenta ágil para essa tarefa, alem de que, para se ter um apelo visual no protótipo teria que ser dispendido um grande trabalho na melhoria das interfaces. Por essa razão a equipe resolveu testar a ferramenta Visio da Microsoft. Essa ferramente tem um grande suporte para a criação de interfaces para programas windows, já trazendo diversos componentes usados no dia-a-dia como combo boxes, radio buttons, text fields, frames, scrolls entre outros. Todos com várias opções de customizações.

Segunda versão do protótipo feito com o Visio

Segunda versão do protótipo feito com o Visio

Com o protótipo feito no visio foi possível ter noção de como seria o fluxo de informação dentro do sistema, e de uma melhor verificação das necessidades do mesmo. Após isso foi feito um protótipo já com a interface web que seria usada na versão final do projeto.

Protótipo com o Layout do sistema

Objetivo e Requisitos

O primeiro passo no desenvolvimento do sistema foi a análise do objetivo do sistema, o levantamento dos requisitos funcionais e a descrição dos requisitos, essa etapa é fundamental para alinhar com o cliente aquilo que ele precisa e espera que o sistema faça ou permita fazer, além de já poder definir algumas regras de negócio que o sistema irá necessitar. Essa etapa é melhor desenvolvida por um analista de negócio, que deve ter algum conhecimento prévio sobre o domínio do sistema. Como não tínhamos ninguém com experiência em hospedagem, hotelaria ou pousadas, demos uma pesquisada para ficarmos ciente sobre os principais termos da área e suas peculiaridades.

Objetivo

O objetivo deste software é gerir uma Pousada de pequeno ou médio porte. Deve-se cadastrar os chalés e serviços disponíveis, gerenciar contas de clientes além de fornecer valores finais das contas dos clientes para devida cobrança. O Sistema deve possibilitar o apoio ao controle de reservas e deve possuir em seu banco de dados todos os chalés, itens, usuários, serviços e clientes cadastrados.

Definição de Requisitos Funcionais

1. O sistema deve permitir o cadastro e manutenção dos seus chalés.
Deve ser possível cadastrar os chalés da pousada, os dados que o sistema deve guardar desses chalés são: sua localização, o seu preços para alta estação e baixa estação, quantidade de pessoas que suporta e os itens que possui.

2. O sistema deve permitir o cadastro e manutenção dos serviços da pousada.
Deve ser possível cadastrar os serviços que a pousada oferece a seus clientes, os dados que o sistema deve guardar desses serviços são: nome e preço.

3. O sistema deve permitir o cadastro dos seus clientes.
Deve ser possível cadastrar os clientes da pousada, os dados que o sistema deve guardar são: nome, RG, endereço, bairro, cidade, estado, CEP e data de nascimento.

4. O sistema deve permitir a reserva de chalés pelos para clientes.
Deve ser possível reservar chalés para utilização futura por um cliente, sendo que o período reservado não poderá coincidir com outra reserva ou hospedagem.

5. O sistema deve permitir a hospedagem dos clientes.
Deve ser possível hospedar clientes na pousada, sendo necessário registrar o chalé onde o cliente ira se hospedar, a quantidade de pessoas que o acompanham e o período de sua permanência. No momento da criação dessa hospedagem deve ser checado se não há uma reserva ou hospedagem no mesmo período e com o mesmo chalé. O sistema deve calcular a conta do cliente (diárias + serviços) e também permitir a aplicação de descontos no fechamento da conta.

6. O sistema deve permitir a inserção de serviços utilizados na hospedagem de um cliente
Deve ser possível inserir serviços utilizados por um cliente ou um de seus acompanhantes na conta de hospedagem do cliente. O sistema deve registrar a data e horário da inserção assim como o valor do serviço.

7. O sistema deve permitir gerar o relatório da conta do cliente com todos os valores devidos.
Deve ser possível gerar o relatório mostrando o valor final da conta do cliente e permitir a aplicação de um desconto no fechamento da conta.