INSTITUTO FEDERAL DO PARANÁ GABRIEL DAHLE TIBILLETTI

Transcrição

1 1 INSTITUTO FEDERAL DO PARANÁ GABRIEL DAHLE TIBILLETTI SABT - SISTEMA DE AGENDAMENTO DE BANHO E TOSA PARANAGUÁ 2012

2 1 GABRIEL DAHLE TIBILLETTI SABT - SISTEMA DE AGENDAMENTO DE BANHO E TOSA Trabalho de Conclusão de Curso apresentado ao curso Técnico em Informática Integrado ao Ensino Médio Do Instituto Federal do Paraná como requisito parcial de avaliação Orientador: Wagner Rodrigo Weinert PARANAGUÁ 2012

3 2 RESUMO O sistema proposto, chamado de Sistema de Gerenciamento de Banho e Tosa - SABT envolve uma área com poucos aplicativos específicos, além de contar com pouca informatização do setor no município de Paranaguá, Paraná. Para o desenvolvimento do sistema, utilizou-se de ferramentas de diagramação e desenvolvimento, como a UML e alguns dos seus diagramas para sintetizar as ideias do projeto, uma diagramação para banco de dados, além de um Sistema Gerenciador de Banco de Dados para armazenamento de dados e linguagem de desenvolvimento do sistema em Java. O software foi pensado para ser um aplicativo desktop, possuindo duas partes: a parte do administrador e do funcionário, cujas limitações estão na impossibilidade de poder cadastrar e alterar serviços e outros funcionários. O sistema possui a funcionalidade de gerenciar os dados dos animais, clientes, funcionários e os seus respectivos endereços, serviços além da organização dos horários. Palavras-chaves: Java,UML,Banco de Dados,banho e tosa

4 3 ABSTRACT The proposed system, called Management System Bath and Tosa - SABT involves an area with few specific applications, besides having little computerization of the sector in the city of Paranaguá, Paraná. To develop the systemwas used the development and diagramming tools, such as UML diagrams and some ideas to synthesize the design, a layout for the database, and a System Manager Database for data storage and language development system in Java. The software was designed to be a desktop application, having two parts: the part of the manager and the employee, whose limitations are unable to register and be able to change services and other officials. The system has the capability to manage the data of the animals, clients, employees and their respective addresses, services and the organization of schedules. Keywords: Java,UML, Databases, Bath and Grooming

5 4 LISTA DE SIGLAS API Application Programming Interface AWT Abstract Window Toolkit CPF Cadastro de Pessoa Física IDE Integrated Development Environment JDK Java Development Kit JRE Java Runtime Environment PHP Hypertext Preprocessor SABT Sistema de Agendamento de Banho e Tosa SGBD Sistema Gerenciador de Banco de Dados UML - Unified Modeling Language XML Extensible Markup Language

6 5 LISTA DE FIGURAS Figura 1 - Exemplo de Modelo de Entidade-Relacionamento Figura 2 - Relação de cardinalidade 1: Figura 3 - Relação de cardinalidade 1:N Figura 4 - Relação de cardinalidade N:N Figura 5 - Relação entre tabelas no Diagrama Relacional Figura 6 - Tabela Funcionário Figura 7 - Tabela Cliente Figura 8 - Inclusão de informações no modelo físico Figura 9 - Resultado da inclusão, através das linhas e colunas Figura 10 - FlameRobin Figura 11 - NetBeans IDE Versão Figura 12 - Ator em Diagrama de Caso de Uso Figura 13 - Caso de Uso Figura 14 - Relações entre atores Associação e Generalização/Especialização Figura 15 - Relação entre atores e Caso de Uso Figura 16 - Relação de Inclusão (Include) Figura 17 - Relação de Extensão (Extend) Figura 18 - Relação De Especialização/Generalização Figura 19 - Relação de Generalização/Especialização em diagrama de classes Figura 20 - Relação de Agregação Figura 21 - Relação de composição Figura 22 - Imagens da linha de tempo, criação e destruição de objetos Figura 23 - Condição em UML Diagrama de Sequência Figura 24 - Mensagem Síncrona Figura 25 - Mensagem Assíncrona Figura 26 - Auto-Delegação de mensagens Figura 27 - Astah UML e um diagrama de Caso de Uso Figura 28 - Caso de Uso para realizar as operações essenciais ao sistema Figura 29 - Diagrama de Caso de Uso para agendamento de horários Figura 30 - Relações entre as classes de generalizadas Figura 31 - Relações entre a classe Funcionário e Endereço Figura 32 - Exemplos de diagrama utilizando o modelo DAO e as relações entre as classes Entidade, Interfaces, Persistências e Controle

7 6 Figura 33 - Comparação entre o primeiro e o segundo diagrama Figura 34 - Diagrama de Sequencia do cadastro de um serviço Figura 35 - Diagrama de Sequencia da alteração de um serviço Figura 36 - Modelo Entidade-Relacionamento do sistema Figura 37 - Modelo Relacional do sistema Figura 38 - Tela de Login Figura 39 - Menu principal Figura 40 - Menu principal - Funcionalidades Figura 41 - Cadastrando um endereço com sucesso Figura 42 - Cadastrando um Serviço Figura 43 - Cadastrando um animal Figura 44 - Cadastrando um endereço erroneamente Figura 45 - Janela de relatório de animais por cliente Figura 46 - Janela de cadastro de horários Figura 47 - Janela de exclusão de horários... 66

8 7 LISTA DE EXEMPLOS DE CÓDIGO Exemplo de Código 1 - Construtor determinando o valor de pi (3,14) Exemplo de Código 2 - Classes Funcionário e Cliente Exemplo de Código 3 - Classe Pessoa Exemplo de Código 4 - Polimorfismo Exemplo de Código 5 - Vetor Exemplo de Código 6 - Matriz de 20 linhas por 10 colunas Exemplo de Código 7 - Criação e povoamento de ArrayList Java Exemplo de Código 8 - Exemplo de tratamento de Exceção

9 8 SUMÁRIO 1 INTRODUÇÃO E JUSTIFICATIVA OBJETIVOS OBJETIVO GERAL OBJETIVOS ESPECÍFICOS FUNDAMENTAÇÃO TEÓRICA BANCO DE DADOS Modelo Entidade-Relacionamento Cardinalidades Modelagem lógica (Modelo Relacional) Implementação Linguagem e Sistema Gerenciador de Banco de Dados Funções do Firebird PROGRAMAÇÃO ORIENTADA A OBJETOS Classes, objetos, métodos e atributos Herança Polimorfismo Classes Abstratas Vetores, matrizes e ArrayList Exceções em Java BibliotecasJava História e funcionamento do Java Ambientes de Programação MODELAGEM DE SISTEMAS Diagramas Diagrama de Caso de Uso (Use-Case) Atores e Caso de Uso Relações entre atores e caso de uso Diagrama de Classes Associações nos Diagramas de Classes Diagrama de Sequência Mensagens no Diagrama de Sequência Sobre a UML Astah UML... 40

10 9 4 METODOLOGIA ESTUDO DE VIABILIDADE Requisitos Funcionais Requisitos Não Funcionais Restrições Riscos METODOLOGIAS UTILIZADAS DIAGRAMA DE CASO DE USO (USE-CASE) DIAGRAMA DE CLASSES DIAGRAMA DE SEQUENCIA MODELO ENTIDADE-RELACIONAMENTO MODELO RELACIONAL RESULTADOS LOGIN MENU PRINCIPAL CADASTRANDO UM ENDEREÇO CADASTRANDO UM SERVIÇO CADASTRAR ANIMAL ALTERANDO UM ENDEREÇO RELATÓRIO DE ANIMAIS POR CLIENTE CADASTRANDO UM HORÁRIO EXCLUINDO UM HORÁRIO CONCLUSÂO REFERÊNCIAS... 68

11 10 1 INTRODUÇÃO E JUSTIFICATIVA O ramo de pet shops é um dos mais promissores negócios atualmente, segundo o Blog Pet Rede (2010) em 2009, o Brasil movimento 9,6 bilhões de reais entre pet food (alimentação animal), medicamentos veterinários, serviços, equipamentos e acessórios. O funcionamento de um pet shop não difere muito do tradicional modelo de comércio, com algumas particularidades. Os pets shops atualmente são lojas de comercialização de animais de estimação (como peixes ornamentais, cães e gatos de raça, animais mais exóticos), além de venda de produtos específicos. Alguns Pets shops possuem atendimento de banho e tosa cuja finalidade é proporcionar higiene e beleza ao animal de estimação (geralmente cães e gatos). A informatização do setor existe, a sua presença acontece mais nas lojas das grandes e médias cidades. No município de Paranaguá, no estado do Paraná, vários pets shops possuem o rudimentar método de organizar dados no caderno, sendo burocrático e pouco prático. Alguns estabelecimentos contam com sistemas informatizados de fluxo de caixa e controle de estoque, sendo grande parte composta por softwares proprietários (alguns sendo renovados periodicamente). Atualmente, o ramo de pet shop em Paranaguá se encontra com poucas lojas informatizadas. 2 OBJETIVOS 2.1 OBJETIVO GERAL Desenvolver um sistema que atenda os requisitos de uma agenda para serviços de banho e tosa. 2.2 OBJETIVOS ESPECÍFICOS Serão contemplados certos atributos essenciais para o funcionamento do sistema, como: controle de horários de banho e tosa, de clientes, animais e

12 11 funcionários, cadastro e controle do tipo de serviço que será realizado no estabelecimento. 3 FUNDAMENTAÇÃO TEÓRICA A Fundamentação Teórica é essencial para compreender os conceitos que foram estudados e aplicados na resolução do projeto. No SABT, foram utilizados conceitos referentes à área de planejamento e modelagem de sistemas, de construção e implementação de banco de dados e a realização de todo o código do programa na linguagem Java, seguindo a cartilha da Orientação a Objetos. 3.1 BANCO DE DADOS Segundo Milani (2006, p.312), um banco de dados é uma coleção de dados referentes a um assunto ou propósito específico, com objetivo de organizar os dados de modo a tornar a vida dos usuários do negócio em questão mais prática, precisa, rápida e confiável Modelo Entidade-Relacionamento O planejamento de um banco de dados se inicia com a modelagem conceitual, cujo diagrama é chamado de entidade-relacionamento, que determina quais são as entidades, seus atributos, que são as especificações das entidades, podendo ser simples, compostos (sendo dividido em espécie de sub-atributos ) ou multivalorados (podendo ter vários valores em um atributo). Também há os relacionamentos entre tais tabelas, que são as interações entre elementos de diversas entidades. Um exemplo de Modelo Entidade-Relacionamento básico (Figura 1), com entidades, relacionamentos e atributos, cujos tipos podem ser: simples (Sexo),

13 12 compostos (Endereço rua e bairro) e multivalorados (Telefone). Figura 1 - Exemplo de Modelo de Entidade-Relacionamento Cardinalidades Nesses relacionamentos existem cardinalidades, que são números que determinam quantas relações uma tabela terá com outra, por exemplo: Uma instância da entidade Animal se relacionará com uma única instância da entidade Funcionário, pois apenas um Funcionário atenderá um animal, e tal um animal será atendido por apenas um funcionário. Tal exemplo caracteriza uma relação 1:1 (Figura 2). Figura 2 - Relação de cardinalidade 1:1. Uma entidade Cliente poderá se relacionar com várias instâncias da entidade Animal, e uma instância da entidade Animal se relacionará unicamente com uma instância da entidade Cliente, sendo uma relação 1:N (Figura 3).

14 13 Figura 3 - Relação de cardinalidade 1:N. Uma instância da entidade Serviço poderá ser relacionar com várias instâncias da entidade Funcionário, e vice-versa, pois um funcionário realizará vários serviços. Tais serviços poderão ser realizados por vários funcionários, caracterizando uma relação N:N (Figura 4). Figura 4 - Relação de cardinalidade N:N. Toda entidade possui um atributo identificador cujo valor é único para cada objeto ou instância de uma tabela Modelagem lógica (Modelo Relacional) Além da modelagem conceitual, há a modelagem lógica, cujos conceitos se aproximam do modelo físico, da linguagem SQL. As entidades tornam-se tabelas, cuja finalidade é realizar o armazenamento de dados dos seus atributos, por exemplo: Clientes, Animais, Produtos. Os relacionamentos viram ligações ou tabelas utilizando a passagem de chaves". Os atributos identificadores do diagrama entidade-relacionamento transformam-se em chaves, cuja funcionalidade é de permitir a classificação única

15 14 de cada registro de uma tabela. Existem vários tipos de chaves, sendo as mais utilizadas as Chaves Primária e Estrangeira. Chave Primária: É um atributo único para cada registro de uma tabela, que identifica a entidade, por exemplo: atributo CPF (Figura 5). Chave Estrangeira: É uma chave que é primária em uma tabela (sendo assim indispensável) e está relacionada em outra, caracterizando uma relação entre tabelas, ou seja, de acordo com Mattoso (2002, p.38) a Chave Estrangeira é um atributo (ou vários) usado para referenciar entidades de outras tabelas. Possui valores da chave primária da tabela referenciada. Eis um exemplo de uma relação 1.N entre a tabela Funcionário e Cliente no modelo Lógico (Figura 5). Destaque para a presença da chave primária (Atributo CPF) e clave Estrangeira (Atributo Funcionario_CPF). Figura 5 - Relação entre tabelas no Diagrama Relacional Implementação Após as modelagens conceitual e lógica, há a modelagem física, que se trata da implementação da base de dados. Todas as tabelas, relações (chaves primárias e secundárias) e atributos são passados para a linguagem do sistema gerenciador de banco de dados (Figuras 6 e 7). Para um bom funcionamento de uma base de dados, é essencial que todas as etapas de planejamento estejam coerentes entre si.

16 15 As tabelas contêm linhas e colunas (Figura 9): Linhas (registros ou tuplas) - são as linhas das tabelas e representam objetos do mundo real Colunas (atributos ou campos) - são as colunas das tabelas e representam propriedades das entidades. (Fonte: MATTOSO, 2002, p.37). Figura 6 - Tabela Funcionário. Figura 7 - Tabela Cliente. É possível realizar algumas operações para verificar a confiabilidade do banco de dados, como as operações de inclusão, alteração e exclusão de dados (Figuras 8 e 9). Tais operações podem auxiliar na consistência do banco de dados, se o próprio reproduz fielmente a realidade. Figura 8 - Inclusão de informações no modelo físico.

17 16 Figura 9 - Resultado da inclusão, através das linhas e colunas Linguagem e Sistema Gerenciador de Banco de Dados A linguagem utilizada para a construção e manutenção de bases de dados é a SQL, uma linguagem amplamente difundida e bastante funcional. O Sistema Gerenciador de Banco de Dados que será utilizado é o Firebird, um software gratuito de linguagem SQL e também será utilizado o FlameRobin (Figura 10) para criar e administrar as bases de dados.

18 Funções do Firebird Em alguns bancos de dados, como o Firebird, é possível realizar certas funções (procedures) para consulta e/ou controle de dados, gatilhos (triggers) para testes de validação de informações e visões que correspondem a uma relação virtual, não formando parte do conjunto de relações reais de um Banco de Dados, porém é visível para os usuários como tal. Figura 10 - FlameRobin. 3.2 PROGRAMAÇÃO ORIENTADA A OBJETOS A metodologia de Programação Orientada a Objetos é muito utilizada mercado atualmente. O objetivo do programador, na Orientação a Objetos é determinar os objetos e as relações entre eles, entre classes e métodos.

19 Classes, objetos, métodos e atributos Um programa orientado a objeto possui basicamente quatro tipos de estruturas essenciais para tal paradigma: Classes, Objetos, Métodos e Atributos. Uma classe é algo existente na vida real, representado no programa, por exemplo: Classe Cliente, Classe Animal, Classe Funcionário, Classe Serviço, etc. Um objeto é uma instância de uma classe, ou seja, a classe é o projeto de algo e o objeto é algo existente no sistema. Exemplo: Classe Animal, Animal cachorro, O objeto cachorro é uma instância da classe Animal, tendo as características da classe. As classes possuem algo semelhante a ações ou comportamentos, tais ações são executadas pelos métodos. Um Funcionário pode reservar um serviço para um animal de um cliente através do método reservaservicos(cliente c,animal a) onde c é um objeto da classe Cliente e a é um objeto da classe Animal, sendo passados por parâmetros, Tais comportamentos se chamam métodos e são pertencentes as classes. De acordo com tal contexto, David (2007) afirma: Métodos serão as ações que a Classe poderá realizar. Quando um objeto desta classe receber uma mensagem de algum outro objeto contendo o nome de um método, a ação correspondente a este método será executada. Cada classe possui suas próprias características, chamadas de atributos, exemplo: Classe Cliente. - Nome - Data de Nascimento - Sexo - Cidade Natal Tais atributos podem ser classificados por tipos, como números inteiros, racionais, caracteres ou até vetores/matrizes. Os atributos podem ser inicializados através de construtores, por exemplo, um atributo double chamado pi pode ser inicializado com 3,14 (Exemplo de Código 1). public class exemplo{

20 19 } public pi(){ Double pi = 3,14; } Exemplo de Código 1 - Construtor determinando o valor de pi (3,14) Herança Através das classes, é possível aplicar um conceito chamado de herança, que permite reunir entre duas classes que possuem características semelhantes, uma classe que possui todos os atributos e métodos comuns às duas classes existentes. Exemplo: Cliente e Funcionário são classes distintas, porém semelhantes, pois possuem características e comportamentos semelhantes (Exemplo de Código 2). Public class Cliente{ String nome; String data_nascimento; String cpf; String data_inicio_da_clientela; } public class Funcionário{ String nome; String data_nascimento; String cpf; String login; String senha; Double salário; } Exemplo de Código 2 - Classes Funcionário e Cliente.

21 20 Percebe-se que as classes possuem alguns atributos idênticos, mesmo sendo classes diferentes: Cliente e Funcionário, tais classes podem ser geradas de uma classe que reúne tais atributos que pertencem em comum as duas classes, sendo mais generalizadora, como por exemplo, uma classe Pessoa que reúne atributos em comum das classes Cliente e Funcionário (Exemplo de Código 3). public class Pessoa{ String nome; String data_nascimento; String cpf; } Exemplo de Código 3 - Classe Pessoa. A classe pessoa é a classe de generalização, ou classe-mãe, e as classes Funcionário e Cliente são as classes de especialização, ou classes-filhas. A sintaxe de uma classe-filha é: public class Cliente extends Pessoa{ } A classe Cliente herda todos os atributos e métodos da classe Pessoa, e ainda possui seus próprios atributos e métodos Polimorfismo Através da herança, é possível utilizar um conceito muito importante na orientação a objetos: o Polimorfismo. O Polimorfismo é uma maneira de utilizar um tipo de objeto que pode realizar ações diferentes quando recebe uma mesma mensagem, sendo referenciado de várias maneiras, com métodos cadastrados em classes-mãe que podem aceitar diferentes objetos de classes-filhas. (Exemplo de Código 4).

22 21 public class Programa(){ Public void cadastropessoas(pessoa p){ } } Public Static Void Main(String[] args){ Cliente cliente; Funcionario funcionario; Programa p; p.cadastrapessoa(cliente); p.cadastrapessoa(funcionario); } Exemplo de Código 4 - Polimorfismo. O polimorfismo se dá quando o objeto programa acessa o método cadastrapessoa, passando um objeto da classe Pessoa como parâmetro, na classe Main, o objeto p da classe Programa chama o método cadastrapessoa passando um objeto da classe cliente. Também foi realizada a chamada do método cadastrapessoa, porém passando o objeto funcionário da classe Funcionário. Tal situação é possível, pois cliente e funcionário são objetos diferentes, porém as suas classes derivam de uma mesma classe generalizadora: a classe Pessoa. O método cadastrapessoa apenas admite objetos da classe Pessoa e suas classes-filhas. Como Cliente e Funcionario são filhas da classe Pessoa, é possível realizar o polimorfismo.

23 Classes Abstratas Além das classes normais, existem as classes abstratas, cujo conceito, segundo David (2007) é: Uma classe abstrata é uma classe que representa uma coleção de características presentes em vários tipos de objetos, mas que não existe e não pode existir isoladamente. Em um sistema com as classes Clientes e Funcionários, a classe Pessoa pode ser abstrata, pois geralmente as classes concretas são derivadas de uma determinada classe abstrata, pois em seu conteúdo pode possuir métodos abstratos. A classe Pessoa pode ser qualquer ser humano, sendo uma classe mais generalizada. Já a classe derivada Cliente, é mais perceptível ao sistema, sendo mais clara, específica e delimitada, pois um cliente terá suas próprias características, além das características herdadas da classe Pessoa. A classe Funcionário também terá suas próprias características, sendo a classe Pessoa um molde para cadastrar classes derivadas e concretas, pois a classe abstrata não pode ser instanciada. Os métodos abstratos possuem a característica de obrigar as classes derivadas da classe abstrata a herdarem o método da classe abstrata. As diferenças entre os métodos são perceptíveis através das reescritas realizadas em cada Classe, atendendo as suas características. Exemplo de classe abstrata: public abstract class Pessoa{ }

24 Vetores, matrizes e ArrayList Vetores são estruturas capazes de guardar vários dados, sendo de um tipo de dados específico como int, double ou até de objetos (Exemplo de Código 5). Exemplo: double [] clientes; clientes = new double[40]; clientes[0] = 102; clientes[1] = 1; Exemplo de Código 5 - Vetor. Matrizes são vetores bidimensionais (Exemplo de Código 6), Exemplo: int [][] matriz; matriz[][] = new matriz[20][10]; matriz[10][5] = 40; Exemplo de Código 6 - Matriz de 20 linhas por 10 colunas. As posições das matrizes se referem às linhas e colunas, respectivamente. Já as Arraylist são estruturas de armazenamento de dados, semelhantes a vetores, ao contrário dos vetores e matrizes, a Arraylist possui um tamanho expansível. Segundo a CAELUM (2012, p. 186), uma Arraylist trabalha com um array interno para gerar uma lista. Tal lista é expansível e é possível excluir um dado que situa no meio da lista sem afetar toda a estrutura que armazena os dados (Exemplo de Código 7). Funcionario f1 = new Funcionario(); Cliente c1 = new Cliente(); ArrayList<Pessoa> clients; /*/ Foi criada uma Arraylist específica para Pessoas, porém é possível que uma ArrayList seja não específica, podendo guardar números, caracteres e outros tipos de dados/*/

25 24 clients = new ArrayList<Pessoa>(); clients.add(c1); clients.add(f1); Exemplo de Código 7 - Criação e povoamento de ArrayList Java. Foi criada uma ArrayList sobre a classe Pessoa chamada clients, tal ArrayList armazenará apenas objetos da classe Pessoas e Derivados, como objetos da classe Cliente e Funcionário Exceções em Java Quando o usuário do sistema digita algo errado, ou que não corresponde ao que o sistema pede, por exemplo, um tipo de dado diferente que o sistema exige. Tais situações em que o usuário erre algum tipo de operação do sistema, exemplo: cadastrando um cliente e digita um valor errado (Exemplo de Código 8). Segundo os autores da apostila FJ-11, a CAELUM (2012, p. 124), Uma exceção representa uma situação que normalmente não ocorre e representa algo de estranho ou inesperado no sistema. int numero = 0; System.out.println("Digite um número"); try { numero = 2.5; } catch (NumberFormatException e) { System.out.println("erro de formatação de número: " + e); } Exemplo de Código 8 - Exemplo de tratamento de Exceção. Tal exemplo é um tipo de tratamento de exceção em que o número pedido era para ter sido em formato inteiro, o número solicitado estava em um formato diferente do pedido, em formato de ponto flutuante (sendo mais utilizado o Double no Java). Tal condição, sem o devido tratamento, paralisa o programa sem

26 25 explicações convincentes para o usuário, apenas alguém com experiência em Java entenderia que a exceção seria um NumberFormatException, então a exceção é disparada,sendo enviada uma mensagem dizendo que há um erro de formatação de número. Existem vários tipos de exceção para diversos tipos de situações, como vetores com posições inexistentes, arquivos que não abrem, entre outras. Para o programa funcionar e não parar quando aparece uma mensagem, usa-se um artifício de expressões booleanas (true ou false, ou verdadeiro ou falso), comparando se tal condição é verdadeira para disparar tal exceção e o usuário mesmo corrigi-la BibliotecasJava O Java suporta bibliotecas gráficas para uma melhor visualização do programa, além de permitir uma interação mais eficiente com o usuário, duas dessas bibliotecas são a AWT e a Swing. Segundo a CAELUM(2012): A AWT foi a primeira API para interfaces gráficas a surgir no Java e foi, mais tarde, superada pelo Swing (a partir do Java 1.2), que possui diversos benefícios em relação a seu antecessor. As bibliotecas são oficiais e estão inclusas em qualquer JRE ou JDK, sendo útil a necessidade de um ambiente de desenvolvimento de Java História e funcionamento do Java A linguagem de programação Java surgiu com uma equipe de programadores da Sun Microsystems (Desenvolvedora) em 1992, chefiada por James Gosling, sendo concluído em 1994/1995. Atualmente a linguagem é muito conhecida e difundida na informática, sendo apropriada para iniciantes até pessoas com anos de experiência, devida a sua semelhança de sintaxe com algumas linguagens conhecidas, como a linguagem C e a sua extensa quantidade de bibliotecas das mais diversas finalidades. Um dos objetivos da linguagem Java, além da sua grande versatilidade, servindo de plataforma desde aplicações dentro do

27 26 navegador (applets) é também servir de plataforma de aplicações ao lado do servidor. Segundo a CAELUM (2012, p. 3): Alguns desses problemas foram particularmente atacados porque uma das grandes motivações para a criação da plataforma Java era de que essa linguagem fosse usada em pequenos dispositivos, como tvs, vídeocassetes, aspiradores, liquidificadores e outros. A portabilidade da Linguagem Java é uma das suas maiores características, sendo necessária apenas uma máquina virtual Java, que traduz o código da aplicação para o sistema operacional, sendo desnecessário compilar o código especialmente para Linux ou Windows, por exemplo. Tais códigos da aplicação são convertidos para bytecodes pela máquina virtual. Os bytecodes são códigos de máquina específico,gerados através de um compilador Java, como o javac, os bytecodes possuem esse nome, pois, de acordo com a CAELUM (2012, p. 6) existem menos de 256 códigos de operação dessa linguagem, e cada opcode gasta um byte. Tais bytecodes são traduzidos pela Máquina Virtual, que conversa diretamente com o sistema operacional, sem a necessidade de diálogo entre a aplicação e o Windows, por exemplo. Tais aplicativos são essenciais para que seja possível programar em Java: JRE: Java Runtime Environment, ambiente de execução Java, formado pela JVM e bibliotecas, tudo que você precisa para executar uma aplicação Java. Mas nós precisamos de mais. JVM: Java Virtual Machine, Máquina Virtual Java, tal aplicativo, ao realizar o download, vem acompanhado com o JRE. JDK: Java Development Kit: Os desenvolvedores fazem o download do JDK do Java SE (Standard Edition). Ele é formado pela JRE somado a ferramentas, como o compilador. (Fonte: CAELUM, Curso Java FJ-11, p. 7).

28 27 Graças a sua portabilidade, robustez de linguagem e versatilidade de aplicações e bibliotecas, o Java está consolidado como ferramenta de desenvolvimento de softwares, podendo ser uma boa linguagem para aprendizado, porém o Java é mais recomendado para aplicações de média e grande complexidade com boa capacidade de expansão. Segundo a CAELUM (2012, p.7): O foco da plataforma é outro: aplicações de médio a grande porte, onde o time de desenvolvedores tem várias pessoas e sempre pode vir a mudar e crescer. Não tenha dúvidas que criar a primeira versão de uma aplicação usando Java, mesmo utilizando IDEs e ferramentas poderosas, será mais trabalhoso que muitas linguagens script ou de alta produtividade. Porém, com uma linguagem orientada a objetos e madura como o Java será extremamente mais fácil e rápido fazer alterações no sistema, desde que você siga as boas práticas e recomendações sobre design orientado a objetos Ambientes de Programação É possível programar em Java utilizando o javac, ou o compilador Java instalado no computador, porém tal ferramenta é muito limitada, sendo ineficiente para correção de erros de sintaxe em tempo de desenvolvimento (os erros apenas aparecem no compilador) e de potencial muito reduzido. Existem interfaces que ajudam o programador a criar seus códigos, verificar erros e até concluir a sintaxe que estava sendo digitada pelo tal. Tais interfaces são as IDEs (Integrated Development Environment - Ambiente de Desenvolvimento Integrado), úteis ferramentas de construção de programas. No mercado existem dois IDE populares, o NetBeans e o Eclipse. O IDE escolhido foi o NetBeans (Figura 11), pela suas múltiplas funcionalidades, sendo uma IDE mais completa e utilizada durante o curso de informática. A IDE possui suporte para trabalhar com vários tipos de linguagem de programação, como C/C++, Java, Javascript, PHP, XML, entre outras linguagens. Segundo o site NetBeans.org (2012) O NetBeans IDE é um premiado ambiente de desenvolvimento integrado disponível para Windows, Mac, Linux e Solaris.

29 28 Figura 11 - NetBeans IDE Versão O NetBeans atualmente se encontra na versão 7.1.1, possuindo uma grande comunidade que ajuda no desenvolvimento, contribuindo com sua popularidade. Conforme o site NetBeans.org(2012): O projeto NetBeans consiste em um IDE de código aberto e uma plataforma de aplicativos que permite aos desenvolvedores criar rapidamente aplicativos web, empresariais, móveis e de área de trabalho utilizando a plataforma Java, bem como PHP, JavaScript e Ajax, Groovy e Grails, e C/C++.

30 MODELAGEM DE SISTEMAS A Modelagem de Sistema consiste em etapas de planejamento de softwares, desde as ideias principais, como o levantamento de requisitos até extensos diagramas que mostram as funcionalidades dos componentes do software. Tal artifício utilizado para a compreensão das informações geradas através de conversas com o cliente/usuário é a diagramação em UML (Unified Modeling Language Linguagem de Modelagem Unificada) Diagramas Os diagramas são representações de ideias, conceitos e funcionalidades de certo sistema, constituindo de uma poderosa ferramenta de documentação para planejar um software com segurança e um manual sobre o sistema, sendo aproveitado por futuros desenvolvedores que provavelmente darão manutenção a tal programa. Segundo Lima (2011 p.33), à medida que o desenvolvimento do sistema acontece, são construídos, refinados, e detalhados diversos modelos, cada um referente a uma visão específica. Através desses modelos, são formados os vários diagramas que possuem diferentes versões, e segundo Lima (2011 p.33) são em diferentes níveis de detalhamento, de acordo com a parte interessada ou envolvida no sistema. Apesar de um diagrama representar parcialmente um aspecto do sistema, ele é semanticamente consistente com os demais diagramas de quaisquer outras visões, permitindo rastreabilidade ao longo de todo o projeto Diagrama de Caso de Uso (Use-Case) Um dos diagramas mais utilizados na UML é a diagramação de Caso de Uso, ou Use-Case. Segundo Stadzisz (2002, p.3): O modelo de Casos de Uso foi proposto por I. Jacobson como um instrumento para descrição das intenções ou requisitos para um sistema computacional. O Diagrama de Caso de Uso é essencial para compreender as ideias fundamentais de um software, pois é possível identificar as funcionalidades e os

31 30 usuários que interagem com o sistema. O diagrama possui conceitos que se valem dessa compreensão, como os Atores (Figura 12) e os Casos de Uso (Figura 13) Atores e Caso de Uso Ator: O Ator (Figura 12) é uma das peças fundamentais do diagrama, sendo responsável pelas interações com o sistema através de trocas de mensagens. Os atores podem ser pessoas que acessam o sistema, como por exemplo: Funcionário, ou pessoas que interagem indiretamente, como o cliente que pede a um funcionário para tosar um animal. O ator também pode ser um dispositivo como uma impressora, ou algum hardware/software que conversa com o sistema, como uma placa de modem ou um Sistema de banco de dados. Figura 12 - Ator em Diagrama de Caso de Uso Caso de Uso: Os Casos de Uso (Figura 13) são funcionalidades realizadas pelo sistema, sendo uma ação ou serviço que descreve uma aplicação ou até um uso completo de um software que interage com o programa. Figura 13 - Caso de Uso.

32 Relações entre atores e caso de uso Relações entre Atores: Os atores podem se relacionar entre si. Conforme Stadzisz (2002, p. 5): Os relacionamentos entre eles serão relações externas ao sistema. Embora estas relações possam ser desprezadas, pois não fazem parte do sistema e nem são de conhecimento do sistema, é possível incluí-las no modelo de casos de uso. As relações entre atores (Figura 14) podem ser de associação (sendo um tipo de comunicação) ou de generalização/especialização. A associação entre atores é uma relação em que ocorrem trocas de mensagens de forma uni ou bidirecional. Na relação de generalização/especialização, há um ator mais genérico e um ator mais específico, cujas operações são herdadas do ator genérico, por exemplo: Há um ator chamado funcionário e outro chamado administrador, o administrador é um funcionário, herdando características de tal ator, porém o administrador possui suas próprias características, como um acesso mais exclusivo em certas partes do sistema, por exemplo. Figura 14 - Relações entre atores Associação e Generalização/Especialização.

33 32 Relações entre Atores e Casos de Uso: O ator, como um componente que dialoga com o sistema, solicita certas funcionalidades do sistema através das suas mensagens. Um ator pode acessar diferentes funcionalidades, podendo ter diversos casos de uso associados com um ator (Figura 15). Figura 15 - Relação entre atores e Caso de Uso. Relações entre Casos de Uso: As relações entre caso de uso são estruturais, diferente das comunicações entre atores e caso de uso, pois, conforme Stadzisz (2002, p.6) Isto ocorre porque casos de uso são aplicações completas do sistema e, por consequência, não existe sentido em fazer-se comunicar dois Casos de Uso do sistema. Existem três tipos de relacionamentos entre Casos de Uso: Inclusão (Include), Extensão (Extend) e Generalização/Especialização. O relacionamento de Inclusão (Include Figura 16) é quando um Caso de Uso compõe outro, como se um Caso de Uso possuísse outro Caso de Uso, sendo subcaso. Tal subcaso seria um detalhamento do Caso de Uso que o incluiu, sendo uma decomposição. Outra aplicação da relação de inclusão é de evidenciar partes comuns a dois/mais casos de uso, sendo incluído por mais de um Caso de Uso maior. Figura 16 - Relação de Inclusão (Include).

34 33 O relacionamento de extensão (Extend Figura 17) é quando uma situação pode ocorrer com um Caso de Uso, sendo assim uma extensão que provavelmente seja solicitada pelo Caso de Uso. Para o seu possível uso, é necessária que uma determinada condição seja atingida. Figura 17 - Relação de Extensão (Extend). O relacionamento de Generalização/Especialização entre os Casos de Uso (Figura 18) é semelhante ao relacionamento entre os atores. Tal relacionamento é dado quando há uma função, que é mais genérica e possui outra função que herda suas características, porém é aplicada a casos mais específicos. Figura 18 - Relação De Especialização/Generalização Diagrama de Classes O Diagrama de Classes é um componente essencial da UML, pois é através dele que percebemos quantas classes o sistema terá e quais serão as suas

35 34 funcionalidades e as suas relações entre outras estruturas do programa. Tal relação entre duas classes se chama de Associação e pode ter vários tipos, além da Associação simples: Generalização/Especialização, Agregação e Composição: Associações nos Diagramas de Classes A Relação de Generalização/Especialização é semelhante aos conceitos de Herança abordados anteriormente, sendo representados por uma classe genérica com uma seta para as classes específicas (Figura 19). Figura 19 - Relação de Generalização/Especialização em diagrama de classes. A Relação de Agregação é entendida da maneira que a classe agregada é um componente da classe que agrega, ou seja, faz parte da classe que o agrega (Figura 20). Para excluir uma das classes, é necessário que exclua a classe agregadora, para excluir a classe agregada. Conforme o contexto, Stadzisz (2002, p. 51) define: Elas são consideradas agregações quando se realiza um controle de escopo para os objetos agregados. Desta forma, os objetos agregados deveriam ser criados, acessados e destruídos unicamente pelo objeto que agrega estabelecendo assim laços de agregação. Note que em termos de implementação não existe diferença entre a associação e a agregação por associação.

36 35 Figura 20 - Relação de Agregação. A Relação de Composição (Figura 21) é uma relação em que um objeto compõe o outro, ou seja, pertence a outro, sendo que a sua exclusão implica a remover todos os objetos participantes da composição. De acordo com o contexto, Stadzisz (2002, p. 50) afirma: Uma agregação por composição é uma agregação de fato. Isto significa que realmente é feita a criação ou alocação de um objeto dentro de outro objeto. A alocação do objeto interno é feita estaticamente pela instanciação do objeto. Figura 21 - Relação de composição Diagrama de Sequência O Diagrama de Sequência é uma importante ferramenta de diagramação na UML, pois é através dele que se definirão os relacionamentos entre classes, métodos e atributos, além dos comportamentos dinâmicos entre os objetos (como a comunicação entre eles) durante o tempo de execução do sistema. Tal diagramação é complexa e detalhada, sendo uma etapa que necessita de mais tempo e habilidade para ser realizada.

37 36 Uma das características do diagrama de Sequência é o tempo como um dos fatores determinantes para a construção dos processos. Os objetos são colocados na parte superior do diagrama, em linha. Cada objeto possui uma espécie de linha verticalmente tracejada, que se inicia desde o objeto até a parte inferior do programa, indicando o seu respectivo tempo, se houver um x no final de sua linha tracejada, é porque o tempo de vida do objeto acabou sendo anulado. Se o objeto possuir retângulos na sua linha de vida, significa que está sendo ativado para realizar um processo. Os objetos, como já citado, se comunicam através de mensagens, uma primitiva muito importante no diagrama de Sequência, pois com essas trocas de mensagens que ocorrem os processos do programa, como a chamada de métodos, por exemplo. Figura 22 - Imagens da linha de tempo, criação e destruição de objetos Mensagens no Diagrama de Sequência As mensagens podem possuir três significados: Chamada de Função/Procedimento, Envio de Mensagem e Ocorrência de Evento. Quando uma mensagem é de Chamada de Função, o objeto está solicitando uma determinada função/método em alguma etapa do processo.

38 37 Se ocorrer o Envio de Mensagens, o objeto está se comunicando com outro objeto através do envio explícito de mensagens, sendo uma interação mais direta entre os objetos. Caso a mensagem seja de Ocorrência de Evento, um determinado objeto envia um evento para outro, sendo o padrão normal de interação entre objetos e atores. Segundo Stadzisz (2002, p. 31): um evento é algum acontecimento externo ao software, mas que é a ele notificado, pois lhe diz respeito. Uma mensagem pode ter uma condição para que ocorra um determinado processo, ou até um retorno, caso o processo envolva um método que calcule algo e o usuário necessite de um resultado. Através dessas condições ou laços de repetições, é possível realizar processos diferentes, de acordo com a condição apresentada para o tal. Figura 23 - Condição em UML Diagrama de Sequência. Uma mensagem pode ser síncrona ou assíncrona. Uma mensagem síncrona (Figura 24) é quando a mensagem tem um sincronismo rígido e lógico, entre o objeto que envia a mensagem e o objeto destino. Uma chamada de função é um exemplo clássico de mensagem síncrona, pois o objeto chama um método, espera a execução e a resposta, para depois se desativar ou realizar outro processo.

39 38 Figura 24 - Mensagem Síncrona. Uma mensagem assíncrona (Figura 25) é quando não há uma sincronia de estado entre os objetos, um envio de mensagem assíncrona não contempla a situação do outro objeto, enviando a mensagem e prosseguindo com o processamento sem se importar com o tratamento da mensagem realizado no objeto destino. Figura 25 - Mensagem Assíncrona.

40 39 Um objeto também pode auto delegar mensagens (Figura 26), ou seja: Enviar mensagens para si mesmo, sendo assíncrono ou síncrono. Tal artifício é útil para realizar checagens ou cálculos entre o próprio objeto. Figura 26 - Auto-Delegação de mensagens Sobre a UML A UML (Unified Modeling Language) foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson. Booch, Rumbaugh e Jacobson já haviam desenvolvidos metodologias de modelagem de sistemas, cada um com diferentes soluções para a modelagem. Porém era necessário um modelo que contemplasse vários conceitos e diagramas. O UML foi uma junção dos métodos Booch, OMT (desenvolvida pela empresa General Eletric, onde Rumbaugh trabalhava) e OOSE/Objectory (desenvolvida por Jacobson). Os objetivos da UML são: Planejamento e modelagem de sistemas utilizando conceitos da programação orientada a objetos. executáveis. Estabelecer uma união fazendo dos métodos conceituais, também

41 40 Criar uma linguagem de modelagem interpretável tanto para o programador como para o computador. Com a utilização de vários diagramas, como o de Caso de Uso, Classes, Sequencia Atividade, entre outros. A UML se tornou quase padrão para a notação de vários tipos de diagrama, com ênfase em conceitos orientados a objeto. Uma das facilidades da UML é que pode ser utilizada em vários tipos de sistema, desde que utilize o paradigma orientado a objetos Astah UML Uma das ferramentas mais utilizadas para a realização de projetos em UML é o Astah Community (antigo Jude Community). A versão Community é gratuita e ideal para fins educacionais e atende as diversas necessidades em matéria de UML, porém é mais limitada perante a versão Professional, a mais completa. A empresa desenvolvedora do Astah é a Change Vision. O Astah (Figura 27) possui suporte para UML 2.1, seu manuseio é simples e intuitivo, realizando diversos tipos de diagramas.

42 41 Figura 27 - Astah UML e um diagrama de Caso de Uso.

43 42 4 METODOLOGIA 4.1 ESTUDO DE VIABILIDADE O Estudo de Viabilidade é um documento que possibilita verificar se há reais condições de implementar o software proposto. O estabelecimento que solicitou o SABT necessitava de atualizações de softwares gerenciadores, seja para a parte administrativa ou de agendamento de serviços de banho e tosa. Foi realizada uma entrevista com os donos e funcionários do estabelecimento Aviário Cão Peão. Através desta entrevista, foi possível verificar quais pontos o sistema terá que implementar, além de averiguar qual é a situação atual da empresa (metodologia de trabalho, ambiente). Já está em estudo uma atualização ou até uma troca de sistema gerenciador, pois o software atual, o Aplicativos Comerciais, encontra-se desatualizado (pois a sua versão atual é 2012 e a instalada é de 2009). Devido ao grande tempo que é utilizado no desenvolvimento de um sistema que gerencie um estabelecimento comercial completo (administração de contas, fluxo de caixa, entre outras funcionalidades), o foco do software proposto é essencialmente o banho e tosa. Partes de gerenciamento de clientes, animais, funcionários, tipos de serviços e controle de horários de serviços serão contempladas no desenvolvimento do sistema. O método atual de organização de dados é na agenda de compromissos, sendo que são anotados principalmente o horário, o nome do cliente e do animal e o tipo de serviço. Com o sistema proposto, poderão visualizar todos os clientes, animais e até funcionários que cuidarão do serviço. No serviço de banho e tosa encontra-se apenas um funcionário, sendo o próprio que marca os horários e realiza o serviço de banho e tosa. É viável a implementação do software, pois no máximo adicionaria um computador numa rede local já consolidada. A princípio, o sistema poderia ser instalado apenas no escritório ou no balcão, com a base de dados no escritório, porém, como já foi dito, também é possível aumentar tal rede para adicionar mais uma máquina, que ficaria na seção de banho e tosa, para ficar mais próxima do ambiente e mudar os horários, ou cadastrar algum cliente.

44 Requisitos Funcionais Os Requisitos Funcionais descrevem o comportamento do sistema, suas competências, ou seja, o que o sistema faz. De acordo com os objetivos propostos, os requisitos funcionais são: Dois níveis de acesso: login de administrador (que poderá ver todas as funcionalidades) e de funcionário (não será permitida a criação/manipulação de tipos de serviços). (inclusão e alteração). Gerenciamento de clientes, animais, funcionários, tipos de serviços exclusão de horários). Gerenciamento de horários de atendimento (inclusão, alteração e A possibilidade de poder acrescentar ou diminuir animais em um determinado horário, existente no sistema, sem que interfira em outros horários. Demonstrar estatísticas das operações (Número de animais por dono, de horários por cliente, de horários de atendimento realizados por funcionário) Requisitos Não Funcionais Os Requisitos Não Funcionais são relacionados com o ambiente que o sistema será introduzido, são especificações que o sistema que podem não estar diretamente relacionados com o software em si e sim com a sua relação integrada com os usuários e o ambiente. Sistemas com cores. Funcionar na plataforma Windows XP/Vista/Seven.

45 Restrições HARDWARE: O sistema pode ficar localizado em um, dois ou até três computadores um sendo o servidor, possivelmente localizado no escritório e outro computador que ficaria na parte de banho e tosa, com a função de realizar o agendamento. Também poderia implementar no computador do balcão, para agilizar nas operações de cadastro de clientes/animais, na hora do atendimento ao cliente. SOFTWARE: O Sistema tem o seu foco no agendamento, podendo ter um bom desempenho, pois as suas funcionalidades são além do agendamento, controle de certos dados como os clientes, animais, funcionários, tipos de serviço e horários. AMBIENTE: Não teriam maiores complicações, além de uma possível instalação de um computador na sala de tosa, para operar o SABT. TECNOLOGIA: O Sistema necessitaria apenas das ferramentas Java, de um banco de dados com linguagem SQL (Firebird) e de uma conexão com servidor (já existente) Riscos POLÍTICOS: O sistema não sofre nenhuma influência de alguma lei ou sanção de órgão regulador. TECNOLOGIA: Utilização de um computador de um desempenho modesto e um servidor este último, já existente.

46 45 RECURSOS: O sistema dispensa microcomputadores especiais, com grande poder de processamento ou com requisitos específicos, reduzindo assim, os recursos gastos. A adição de mais uma máquina na rede local do estabelecimento já está sendo planejada, sendo a única despesa que se relaciona com o sistema, porém, tal empecilho não impede a implementação do sistema. HABILIDADE: Com um simples treinamento, o software poderá ser utilizado por funcionários e administradores. REQUISITOS: Não há riscos em relação a requisitos. 4.2 METODOLOGIAS UTILIZADAS As metodologias utilizadas para projetar o sistema são: Modelagem de Sistemas: Tal parte compreende o planejamento e a modelagem de sistemas. O software escolhido para a modelagem de sistemas é o Astah Community, que abrange os diagramas de Caso de Uso, Sequência, Classes, Atividade, entre outros. A versatilidade de tal programa, além da sua facilidade de uso, são atributos suficientes para a escolha do programa para a modelagem. Banco de Dados: Compreende o planejamento (modelagem) e a implementação (parte física) do Sistema Gerenciador de Banco de Dados. O planejamento de Banco de Dados se faz com os softwares chamados BRModelo e DBDesigner. O BRModelo é um programa que permite a realização de Diagramas no modelo Entidade-Relacionamento, tendo uma sintaxe muito simples, além de ser projetado na língua portuguesa. Já o DBDesigner é um programa de fácil manuseio e com tabelas de fácil leitura, que dá suporte ao Diagrama no Modelo Relacional. O SGBD escolhido foi o Firebird, por ser amplamente difundido, e por causa da familiaridade do autor com o SGBD. A Linguagem utilizada é a SQL, por ser a linguagem-padrão de Banco de Dados.

47 46 Programação Orientada a Objetos: Compreende a parte da implementação do software. A linguagem de programação selecionada é a Java, por causa da familiarização do autor a sintaxe, além de ser uma linguagem com grande versatilidade e muito utilizada no mercado de trabalho. A IDE escolhido foi o NetBeans, por ter um suporte maior para realização de Janelas, utilizando a biblioteca Swing, além da familiarização do autor do projeto SABT com a IDE. 4.3 DIAGRAMA DE CASO DE USO (USE-CASE) Diagrama de Caso de Uso: permite idealizar as funcionalidades do sistema e as pessoas que irão utilizar e solicitar tais funcionalidades, que são os casos de uso. Para uma melhor interpretação dos dados, o sistema fora diagramado em duas partes, uma que contempla a parte de inserção dos dados gerais do sistema (Cliente, Funcionário, Animal, e Serviço Figura 28) e outra que contempla a parte de agendamento de horários (Figura 29). Figura 28 - Caso de Uso para realizar as operações essenciais ao sistema.

48 47 Figura 29 - Diagrama de Caso de Uso para agendamento de horários.

49 DIAGRAMA DE CLASSES Diagrama de Classes: Permite ter uma visão básica dos componentes mais essenciais do sistema: classes, atributos e métodos, além das relações entre as classes, na figura 30. O sistema foi projetado seguindo o modelo DAO e possui atributos privados, com todas as classes possuindo métodos Get e Set. Para uma melhor compreensão, o diagrama fora dividido em dois, representados nas Figuras 30 e 31, respectivamente. Figura 30 - Relações entre as classes de generalizadas

50 49 Na Figura 31, o Encontram- se as relações entre as classes Cliente, Funcionário e Endereço. Figura 31 - Relações entre a classe Funcionário e Endereço

51 50 É possível perceber a influência do modelo DAO utilizado no sistema, cuja finalidade é de separar o programa em três partes: Entidade (Localizam-se os atributos, sendo instanciadas como objetos), Controle (Localizam-se os métodos que realizam as operações de controle de uma determinada parte do sistema, como os métodos AdicionarDados() e AlterarDados() e a Persistência (Local onde se realiza a comunicação com o Banco de Dados). As relações entre as classes são perceptíveis no primeiro diagrama. Tais relações se dão entre as Interfaces com as Entidades (Para instanciar objetos relacionados entre as classes) e Controles (Para realizar as operações que envolvem objetos de outras classes). Já as relações com entre as classes de Interface, Controle e Persistência entre si estão representadas na figura 32.

52 51 Figura 32 - Exemplos de diagrama utilizando o modelo DAO e as relações entre as classes Entidade, Interfaces, Persistências e Controle.

53 52 A Figura 33 explica melhor a relação entre o primeiro Diagrama e o Segundo Diagrama, tomando como exemplo as relações entre as classes Funcionário e Endereço. Figura 33 - Comparação entre o primeiro e o segundo diagrama

54 53 5 DIAGRAMA DE SEQUENCIA O Diagrama de Sequência compreende uma sequência de passos lógicos que o sistema realiza. Para facilitar o entendimento dos desenvolvedores em relação ao sistema projetado, é necessária a realização de vários diagramas, que correspondem a várias funcionalidades sendo descritas. Na Figura 34, na próxima página, há um diagrama de sequencia que corresponde à função Cadastro de Serviço, a lógica básica de tal funcionalidade é comum a todas as funções de cadastro do sistema. Já na figura 35, há o diagrama de alteração de serviço, sua lógica também é comum a todas as funcionalidades de alteração de dados do sistema.

55 54 Figura 34 - Diagrama de Sequencia do cadastro de um serviço

56 55 Figura 35 - Diagrama de Sequencia da alteração de um serviço

57 MODELO ENTIDADE-RELACIONAMENTO Modelo Entidade Relacionamento: permitem detectar as tabelas, os seus atributos e as relações que se dá entre as tabelas, o diagrama que compreende o sistema está representado na figura 36. Figura 36 - Modelo Entidade-Relacionamento do sistema.

58 MODELO RELACIONAL Modelo Relacional: define as relações entre tabelas e a passagem de chaves utilizada na construção do banco de dados, o Modelo Relacional, baseado no Modelo Entidade-Relacionamento do sistema, está representado na figura 37. Figura 37 - Modelo Relacional do sistema

59 58 6 RESULTADOS Vários resultados foram obtidos com a implementação do código, um fato curioso é a relativa simplicidade das funcionalidades, inicialmente descritas nos diagramas, torna-se complexa no desenvolver do Sistema. O Sistema mostra-se competente na manipulação dos dados gerais, como clientes, animais, serviços e endereços. Destaque para a parte de agendamento de Horários, considerada mais complexa devida a dificuldade de encontrar uma solução viável para a lógica de manipulação de horários, a solução foi utilizar a API Joda-Time, cuja funcionalidade implica na manipulação e nas operações com o tempo, sejam horas,minutos, segundos. 6.1 LOGIN Ao iniciar o sistema, o usuário se depara com a tela de Login (Figura 38), nela estão dois campos: Login e Senha. Ao digitar os campos corretamente, terá acesso ao menu principal do sistema. Figura 38 - Tela de Login.

60 MENU PRINCIPAL Após a tela de Login, esta se fecha para abrir a tela do menu principal (Figura 39), onde se encontram a parte do Cadastro, alteração, relatórios e a parte de manipulação de horários. Na Figura 40, encontram-se as funcionalidades do sistema. Figura 39 - Menu principal.

61 60 Figura 40 - Menu principal - Funcionalidades 6.3 CADASTRANDO UM ENDEREÇO Tela onde se alteram os endereços (Figura 41), com os atributos Código, Logradouro, CEP, Cidade, Número do Endereço, Bairro, Cidade e Estado, é possível um cliente e um funcionário terem um mesmo endereço. Figura 41 - Cadastrando um endereço com sucesso.

62 CADASTRANDO UM SERVIÇO Tela onde se cadastra um serviço (Figura 42), com os atributos Código, Nome, Preço e Descrição do Serviço. Figura 42 - Cadastrando um Serviço.

63 CADASTRAR ANIMAL Tela onde se cadastra um animal de um cliente no sistema (Figura 43). No caso, os campos disponíveis par a preenchimento são Nome do Animal, Código do Dono, Nome do Dono, Espécie do animal, Raça, Tipo de pelo do animal e sua descrição Figura 43 - Cadastrando um animal.

64 ALTERANDO UM ENDEREÇO Tela onde se altera um endereço de um cliente ou funcionário (Figura 44), no caso, o usuário está tentando alterar erroneamente, esquecendo-se de preencher algum dado ou selecionando um endereço inexistente, será mostrada uma mensagem de erro. Figura 44 - Cadastrando um endereço erroneamente

65 RELATÓRIO DE ANIMAIS POR CLIENTE Tela onde se digita o código ou nome de um cliente para verificar quantos animais ele possui (Figura 45). Figura 45 - Janela de relatório de animais por cliente

66 CADASTRANDO UM HORÁRIO Tela onde se cadastra o horário que se reserva o animal (Figura 46). Aqui se percebe campos como os Códigos do Animal, Funcionário, Nome do Animal, Funcionário, código do serviço, dia em que se reservará o horário, o horário inicial e final. Figura 46 - Janela de cadastro de horários

67 EXCLUINDO UM HORÁRIO Tela onde se exclui o horário, o usuário digita a data que deseja excluir e o horário (Figura 47). Figura 47 - Janela de exclusão de horários