UNIMINAS SOFTWARE PARA GESTÃO DE ACADEMIA ALESSANDRO DE SOUZA VITOR EDUARDO ELIAS DE LIMA FILHO RICARDO DA SILVA JORGE

Transcrição

1 UNIÃO EDUCACIONAL MINAS GERAIS S/C LTDA FACULDADE DE CIÊNCIAS APLICADAS DE MINAS Autorizada pela Portaria no 577/2000 MEC, de 03/05/2000 BACHARELADO EM SISTEMAS DE INFORMAÇÃO SOFTWARE PARA GESTÃO DE ACADEMIA ALESSANDRO DE SOUZA VITOR EDUARDO ELIAS DE LIMA FILHO RICARDO DA SILVA JORGE Uberlândia 2008

2 ALESSANDRO DE SOUZA VITOR EDUARDO ELIAS DE LIMA FILHO RICARDO DA SILVA JORGE SOFTWARE PARA GESTÃO DE ACADEMIA Banca Examinadora: Trabalho de Final de curso submetido à como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Msc. Edson Angoti Júnior Uberlândia, 16 de fevereiro de Prof. Carlos Henrique de Barros Prof. Msc. Edson Angoti Júnior (Orientador) Profa. Dra. Kátia Lopes Silva Uberlândia 2008

3 Ao nosso Orientador Prof. Msc. Edson Angoti Júnior pelo incentivo, simpatia e presteza no auxílio às atividades e discussões sobre o andamento deste trabalho. Ao Professor Carlos Henrique de Barros pelo seu espírito devotado e empreendedor na tarefa de multiplicar nossos conhecimentos. Aos demais idealizadores, coordenadores e funcionários da UNIÃO EDUCACIONAL MINAS GERAIS (). Aos nossos colegas de classe que nos ajudaram discutindo nossas idéias. Às nossas famílias pela paciência em tolerar a nossa ausência. E, finalmente, a DEUS pela oportunidade e pelo privilégio que nos foram dados em compartilhar tamanha experiência e, ao freqüentar este curso, perceber e atentar para a relevância de temas que não faziam parte, em profundidade, das nossas vidas.

4 RESUMO Este documento tem por objetivo apresentar para o leitor o Sistema de Gestão de Academia (SGA). Faz parte dele explanação da finalidade do sistema, seu escopo, padrões utilizados para sua construção, especificação de requisitos, regras de negócio, casos de uso, diagrama de entidade e relacionamentos, classes de análise, modelo da arquitetura utilizada, testes realizados e interfaces gráficas como exemplo. Todo o projeto foi desenvolvido com o apoio da Academia Golfinho de Ouro, que é uma empresa especializada na prestação de serviços na área de atividades físicas em geral. O objetivo geral do trabalho consiste da implementação de um sistema que gerencie o funcionamento da academia cadastrando alunos, professores, fornecedores, usuários, classes, turmas, histórico dos alunos, modalidades esportivas, matrículas e planos de pagamento, e ainda que tenha a capacidade de manter tais informações e incorporar funcionalidades de login. Utilizou-se no desenvolvimento a linguagem JAVA enquadrada no padrão de arquitetura de software MVC, associada aos frameworks Struts 2 e Hibernate com Annotations. O primeiro consiste em um framework para criar aplicações robustas baseadas na Web. Já o segundo, é um framework para o mapeamento objetorelacional escrito na linguagem Java que facilita o mapeamento dos atributos entre uma base de dados relacional e o modelo objeto de uma aplicação de forma simples e direta. Além disto foi utilizado também Enterprise JavaBeans (EJB), o JBoss, e o MySql. O primeiro é um modelo de componente padrão do lado do servidor para aplicativos de negócio distribuídos multiplataforma e multiusuário. Já o JBoss é um servidor de aplicação baseado na plataforma J2EE, plataforma de programação multicamadas baseada em componentes executados em um servidor de aplicações (no nosso caso o JBoss). O MySql é o sistema de gestão de banco de dados (SGDB) escolhido por sua facilidade de uso, desempenho e estabilidade, baixa exigência quanto a recursos de hardware, além de ser Software Livre. Também foi utilizado o ambiente de desenvolvimento integrado (IDE) Eclipse Europa e a ferramenta CASE Enterprise Architect. Palavras Chave: MVC, Java, Struts 2, Hibernate, Annotation, Eclipse Europa, Enterprise Java Beans (EJB), JBOSS e MySQL.

5 ABSTRACT This document aims to present to the reader the Sistema de Gestão de Academia (SGA). Part of his explanation of the purpose, scope, standards used for their construction, specification of requirements, business rules, use cases, and diagram of contracting relationships, types of analysis, the architecture model used, tests and graphical interfaces as an example. The entire project was developed with the support of the Academia Golfinho de Ouro, which is a company specialized in providing services in the area of physical activity in general. The general objective of the work consists of implementing a system to manage the operation of registering college students, teachers, suppliers, users, classes, sheet for students, sports, registration and payment plans, and that has the ability to maintain such information and incorporate features to login. It was used in developing the Java language included in standard software architecture of MVC, Struts frameworks associated with the 2 and Hibernate with Annotations. The first consists of a robust framework to create applications based on Web The second is a framework for object-relational mapping written in Java language that facilitates the mapping of attributes from a relational database and object model of an application of a simple and direct. Furthermore it was also used Enterprise JavaBeans (EJB), the JBoss and MySql. The first is a standard component model for server-side business applications for distributed multiuser and multiplatform. But the JBoss application server is based on J2EE platform, multi platform programming based on components implemented in an application server (in our case the JBoss). The MySql is the management system database (SGDB) chosen for its ease of use, performance and stability, low demand on hardware resources, and is Free Software. It was used integrated development environment (IDE) Eclipse Europe and CASE tool Enterprise Architect. Keywords: MVC, Java, Struts 2, Hibernate, Annotation, Eclipse Europa, Enterprise Java Beans (EJB), JBOSS and MySQL.

6 LISTA DE FIGURAS Figura 1 - Gráfico de Fatores que influenciam a experiência na Academia (DELOITTE, 2005)...15 Figura 2 Gráfico de Razões de saída de alunos das academias (DELOITTE, 2005)...16 Figura 3 - Diagrama de Casos de Uso...28 Figura 4 - Detalhe do Caso de Uso CSU Figura 5 - Detalhe do Caso de Uso CSU Figura 6 - Detalhe do Caso de Uso CSU Figura 7 - Detalhe do Caso de Uso CSU Figura 8 - Detalhe do Caso de Uso CSU Figura 9 - Detalhe do Caso de Uso CSU Figura 10 - Detalhe do Caso de Uso CSU Figura 11 - Detalhe do Caso de Uso CSU Figura 12 - Detalhe do Caso de Uso CSU Figura 13 - Detalhe do Caso de Uso CSU Figura 14 - Detalhe do Caso de Uso CSU Figura 15 - Detalhe do Caso de Uso CSU Figura 16 - Detalhe do Caso de Uso CSU Figura 17 - Diagrama de Classes de Negócio...46 Figura 18 - Estereótipos de Classes de Análise...49 Figura 19 - Diagrama de Classe de Análise do Caso de Uso Manter Aluno...60 Figura 20 - Diagrama de Classe de Análise do Caso de Uso Manter Fornecedor...61 Figura 21 - Diagrama de Classe de Análise do Caso de Uso Manter Professor...61 Figura 22 - Diagrama de Classe de Análise do Caso de Uso Manter Cliente...62 Figura 23 - Diagrama de Classe de Análise do Caso de Uso Manter Turma...62 Figura 24 - Diagrama de Classe de Análise do Caso de Uso Realizar Matrícula...63 Figura 25 - Diagrama de Classe de Análise do Caso de Uso Registrar Modalidade Esportiva...63 Figura 26 - Diagrama de Classe de Análise do Caso de Uso Gerar Relatório...64 Figura 27 - Diagrama de Classe de Análise do Caso de Uso Registrar Movimento de Caixa...64 Figura 28 - Diagrama de Classe de Análise do Caso de Uso Registrar Histórico do Aluno...65 Figura 29 - Diagrama de Classe de Análise do Caso de Uso Manter Classe...65

7 Figura 30 - Diagrama de Classe de Análise do Caso de Uso Registrar Contas...66 Figura 31 - Diagrama de Classe de Análise do Caso de Uso Manter Usuário...66 Figura 32 - Diagrama de Sequência Manter Aluno...68 Figura 33 - Diagrama de Sequência Manter Professor...69 Figura 34 - Diagrama de Sequência Manter Fornecedor...70 Figura 35 - Diagrama de Sequência Manter Cliente...71 Figura 36 - Diagrama de Sequência Manter Turma...72 Figura 37 - Diagrama de Sequência Realizar Matrícula...73 Figura 38 - Diagrama de Sequência Registrar Modalidade Esportiva...74 Figura 39 - Diagrama de Sequência Gerar Relatório...75 Figura 40 - Diagrama de Sequência Registrar Movimento de Caixa...76 Figura 41 - Diagrama de Sequência Registrar Histórico do Aluno...77 Figura 42 - Diagrama de Sequência Manter Classe...78 Figura 43 - Diagrama de Sequência Registrar Contas...79 Figura 44 - Diagrama de Sequência Manter Usuário...80 Figura 45 - Primeira versão da tela inicial do domínio Aluno...84 Figura 46 - Componentes definidos para a tela do domínio Aluno...85 Figura 47 - Tela projetada para cadastro do Aluno...86 Figura 48 - Tela projetada para inclusão das Modalidades do Aluno...87 Figura 49 - Resumo do cadastro do Aluno...88 Figura 50 - Sistema de Banco de Dados...89 Figura 51 - Diagrama de sequência...94 Figura 52 Estrutura do DAO...95 Figura 53 - Dominio e mapeamento...95 Figura 54 Cliente.java...98 Figura 55 ClienteDAO.Java...98 Figura 56 - DER - Diagrama de Entidade e Relacionamento Figura 57 Arquitetura do Hibernate (FERNANDES, 2007) Figura 58 - Hibernate.cfg.xml Figura 59 - Mapeamento via XML...105

8 Figura 60 - Mapeamento utilizando Annotations Figura 61 - Tabela tb_classe Figura 62 - Código da tabela tb_classe Figura 63 - Tabela tb_modalidade Figura 64 - Tabela tb_professor Figura 65 - Tabela tb_historico Figura 66 - Tabela tb_modulo Figura 67 - Tabela tb_turma Figura 68 - Tabela tb_plano Figura 69 - Tabela tb_aluno Figura 70 - Tabela tb_grupomodulo Figura 71 - Tabela tb_matricula Figura 72 - Tabela tb_cliente Figura 73 - Tabela tb_fornecedor Figura 74 - Tabela tb_grupo Figura 75 - Tabela tb_usuariogrupo Figura 76 - Tabela tb_receber Figura 77 - Tabela tb_caixa Figura 78 - Tabela tb_pagar Figura 79 - Tabela tb_usuario Figura 80 - Visão da Arquitetura MVC Figura 81 - Encadeamento de Filtros no Struts Figura 82 - Visão do Fluxo de uma Requisição Figura 83 - Tecnologias da plataforma JEE (SUN MICROSYSTEMS, 2009) Figura 84 Fragmento do arquivo Alunos.jsp Figura 85 Diagrama de Pacotes Figura 86 Diagrama de Sequência Figura 87 - Fragmento da Classe AlunoAction.java Figura 88 - Diagrama de Sequencia da Estratégia Bussines Delegate Figura 89 - Fragmento da Classe AlunoBussinesDelegate.java...129

9 Figura 90 - Classe AlunoLocal.java Figura 91 - Fragmento da Classe AlunoBean.java Figura 92 Fragmento da Classe DAOAluno.java...130

10 LISTA DE TABELAS Tabela 1 - Regras de Negócio...30

11 SUMÁRIO 1 INTRODUÇÃO Cenário atual Identificação do problema Objetivos do trabalho Objetivo geral Objetivos específicos Justificativa para a pesquisa Organização do Trabalho ESPECIFICAÇÃO DO PROBLEMA ANÁLISE DO SISTEMA Introdução Requisitos Requisitos Funcionais Requisitos não funcionais Diagrama de Casos de Uso Regras de Negócio Especificação dos Casos de Uso Diagrama de Classes de Negócio Especificação das Classes de Negócio Classes de análise Classes de Fronteira Classes de Controle Classes de Entidade Diagrama de Classes de Análise dos Casos de Uso Diagrama de Classe de Análise do Caso de Uso Manter Aluno Diagrama de Classe de Análise do Caso de Uso Manter Fornecedor...61

12 3.7.3 Diagrama de Classe de Análise do Caso de Uso Manter Professor Diagrama de Classe de Análise do Caso de Uso Manter Cliente Diagrama de Classe de Análise do Caso de Uso Manter Turma Diagrama de Classe de Análise do Caso de Uso Realizar Matrícula Diagrama de Classe de Análise do Caso de Uso Registrar Modalidade Esportiva Diagrama de Classe de Análise do Caso de Uso Gerar Relatório Diagrama de Classe de Análise do Caso de Uso Registrar Movimento de Caixa Diagrama de Classe de Análise do Caso de Uso Registrar Histórico do Aluno Diagrama de Classe de Análise do Caso de Uso Manter Classe Diagrama de Classe de Análise do Caso de Uso Registrar Contas Diagrama de Classe de Análise do Caso de Uso Manter Usuário Comportamento Dinâmico INTERFACE PERSISTÊNCIA DE DADOS Banco de dados Modelagem do banco de dados Dicionário de dados Entidades Atributos Mapeamento Objeto Relacional - MOR Relacionamentos Padrão de persistência DAO (Data Access Object) Diagrama de Entidade e Relacionamento Framework Hibernate Sistema de gerenciamento de academia ARQUITETURA E CÓDIGO Introdução Padrões e Tecnologias Utilizadas Modelo MVC Framework Struts...121

13 6.2.3 Arquitetura JEE Implementação Visão Arquitetural CONCLUSÕES Sugestões para Trabalhos Futuros REFERÊNCIAS BIBLIOGRÁFICAS APENDICE A MAPEAMENTO DE PERSISTÊNCIA APENDICE B CLASSE ALUNOLOCAL APENDICE C CLASSE ALUNOBEAN APENDICE D CLASSE DAOALUNO APENDICE E CLASSE ALUNOACTION APENDICE F CLASSE ALUNOBUSSINESDELEGATE

14 14 1 INTRODUÇÃO 1.1 Cenário atual Atualmente o uso de uma solução tecnológica no mercado de gerenciamento de pequenos negócios é visto apenas como um custo proibitivo no orçamento do negócio e com baixo valor agregado. Conforme pesquisa do Sebrae- SP feita em 2003, no setor de serviços prestados por micro e pequenas empresas a informatização é de 12% a 40% das empresas entrevistadas. Apesar do uso de soluções de softwares não customizadas, como softwares não específicos para gestão ou pacotes de gestão de empresas genéricos, nem sempre estas se adaptam ao modelo de negócio, ou o esforço e custo necessário para tal é inviabilizante. No mercado de fornecimento de serviços de práticas esportivas, que é notoriamente afetado por sazonalidade e motivação pessoal do cliente, no qual normalmente não é possível estabelecer uma garantia da prestação de serviço a médio e longo prazo esta visão se intensifica. A visão de baixo valor agregado atribuída a sistemas de gestão nesse segmento do mercado constitui uma contradição muito grande, visto os riscos e instabilidades inerentes a este modelo de negócio, que poderia se beneficiar sobremaneira de informações gerenciais aderentes para o planejamento estratégico da empresa. Conforme pesquisa da consultoria em gestão de riscos empresariais Deloitte feita em 2005 mais de 40% dos atletas interrompe a atividade nos 12 primeiros meses. Enquanto algumas operadoras possuem programas de acompanhamento introdutório durante até três meses, as atividades regulares de retenção em um período maior têm maior probabilidade de fortalecer o relacionamento ao longo do primeiro ano e posteriormente. (DELOITTE, 2005). Neste setor, de grande saturação de prestadores de serviço, um dos fatores de fidelização dos clientes é ter um relacionamento personalizado e uma boa gerência da qualidade conforme mostra o gráfico na figura 1.

15 15 Figura 1 - Gráfico de Fatores que influenciam a experiência na Academia (DELOITTE, 2005) Mas, ainda segundo a consultoria, boa parte deste quadro poderia ser revertido, conforme o gráfico na figura 2: Com base em uma rotatividade de 50%, e convertendo os dados dos 26% de atletas que se mudaram para uma média anual (que equivale a uma pessoa mudando uma vez a cada 7,7 anos), a quantidade da base de dados de ex-atletas que poderiam ser contatados e possivelmente rematriculados é de aproximadamente 50% no período de um ano (figura 8.). (DELOITTE, 2005).

16 16 Figura 2 Gráfico de Razões de saída de alunos das academias (DELOITTE, 2005) 1.2 Identificação do problema A partir do processo de gerenciamento estabelecido na academia foi feito um estudo das necessidades de automação e melhoria de processos, que atualmente são feitos em forma de planilhas de preenchimento e consolidação manual. De acordo com os dados coletados criou-se um modelo para estas necessidades. A arquitetura utilizada amadureceu buscando sempre a escalabilidade e aderência ao negócio, bem como um foco tecnológico de utilização de padrões de projetos. 1.3 Objetivos do trabalho Objetivo geral Implementar um aplicativo comercial com suporte a Web para a gestão

17 17 de uma academia e escola de natação, visando gerenciar, administrar e armazenar todas as operações realizadas pela empresa Objetivos específicos Levantar os requisitos do sistema; Documentar os Casos de Uso; Analisar o desenvolvimento do projeto; Implementar o aplicativo em camadas; Utilizar a linguagem de programação Java; Implementar o diagrama de classes no nível de projeto; Implementar a camada de apresentação através de Front Controller; Implementar a camada de negócio usando Business Delegate, EJB, isolando a camada de negócios da camada de apresentação; Implementar a camada de persistência utilizando DAO - Data Access Object; Utilizar Hibernate para mapeamento do objeto-relacional; Utilizar Struts Justificativa para a pesquisa O ramo de negócio de academias e escolas de natação exige customização detalhada do software, visto que, devido à relativa simplicidade, muitas empresas utilizam softwares de planilha eletrônica para controlar seus dados financeiros, e fichários manuais para controlar dados cadastrais dos seus alunos. Quando há mais sofisticação, esse tipo de empresa geralmente contrata programadores autônomos para desenvolver aplicações a baixo custo usando Microsoft Access ou algum software livre. Devido a esse problema, estas empresas tornam-se reféns destes profissionais e raramente efetuam algum contrato ou pagamento de mensalidade e/ou manutenção.

18 18 Este tipo de aplicação não possui uma boa portabilidade e sua segurança é deficiente, ocasionando perda e/ou corrupção de dados, visto que, geralmente não são dotadas de definições de nível de segurança por usuário e as rotinas de backup raramente são padronizadas. Com estas deficiências, percebe-se a oportunidade de criar uma aplicação inovadora, que alie as funcionalidades do cliente com os padrões de projeto de desenvolvimento de software mais atuais. É possível seguir as tendências do mercado de software, proporcionando ao cliente um sistema com portabilidade e escalabilidade. A relevância desta pesquisa, em seus aspectos profissionais e científicos, sustenta-se na necessidade de um estudo mais profundo de como pode ser desenvolvido um projeto com utilização de linguagens atuais. Tem-se a oportunidade de desenvolver um projeto utilizando-se a linguagem de programação JAVA, recursos de Engenharia de Software e o armazenamento dos dados da empresa em um banco de dados. Este sistema utiliza tecnologias como Struts, Java Server Pages, Servlets, dentre outras, no desenvolvimento de uma aplicação para Web. Utiliza ainda banco de dados gratuito MySQL e pode ser executada a partir de um Web Browser. 1.5 Organização do Trabalho Este trabalho está disposto em capítulos da seguinte forma: Capítulo 2: Especificação do problema: este capítulo elucida a apresentação do cliente, as necessidades apresentadas, requisitos funcionais e nãofuncionais e regras de negócio levantados em reuniões com o cliente. Capítulo 3: Análise do sistema: este capítulo demonstra o processo de análise e documentação efetuados para início do desenvolvimento da solução, apresenta ainda os diagramas seguindo o padrão da UML Unified Modelage Language. Capítulo 4: Interface: este capítulo apresenta os projetos de interface do

19 19 sistema com o usuário final. Capítulo 5: Persistência de dados: este capítulo apresenta a forma como foi construída a armazenagem dos dados no software, além de discorrer sobre as tecnologias utilizadas e conceitos. Capítulo 6: Arquitetura e código: este capítulo apresenta a forma de construção da solução, os padrões de projeto e frameworks utilizados em sua arquitetura. Capítulo 7: Conclusões: este capítulo demonstra as conclusões que foram obtidas com o projeto. arquivos do projeto. Apendices: os Apendices demonstram os códigos fonte de alguns

20 20 2 ESPECIFICAÇÃO DO PROBLEMA A Academia Golfinho de ouro é uma empresa do ramo de atividades físicas indoor aquáticas e terrestres que oferece alguns produtos diferenciados, como natação para bebês e para pessoas da terceira idade. Atualmente conta com um sistema de gestão, mas ele não atende a todas as necessidades. A principal dificuldade do cliente com o sistema atual é realizar o controle financeiro. Como não funciona muito bem se optou por utilizar planilhas para esta finalidade. O controle das atividades esportivas como acompanhamento do desenvolvimento dos alunos também não é contemplado pelo software legado. Na primeira fase do projeto - levantamento de requisitos - realizamos três entrevistas com os stakeholders (todos os envolvidos com o sistema). Na primeira definimos o escopo e identificamos a necessidade: desenvolver um sistema que fosse capaz de gerir todo o funcionamento da empresa, desde as atividades da academia passando por tarefas administrativas e por movimentação financeira. Na segunda levamos até a Egle, proprietária da empresa e principal envolvida no processo, a primeira versão da documentação para que pudéssemos alinhar o que entendemos ser a real necessidade do projeto e o que realmente era para ser feito, e na terceira, levamos a documentação pronta e revisada para que não restassem dúvidas acerca do que deveria constituir o sistema. Pelo fato de a atividade fim da empresa ser a prestação de serviços de atividades físicas foi pedido pelos responsáveis que déssemos atenção especial aos módulos do sistema que tratam deste aspecto. Atualmente todos os alunos ao ingressarem em qualquer modalidade esportiva são obrigados a passar por uma avaliação física e dela resulta uma ficha com todas as informações necessárias para acompanhamento do desenvolvimento deles. A cada três meses esta avaliação é feita novamente e os dados inseridos na ficha são comparados para medir o desempenho de cada pessoa. O novo sistema contemplará manutenção destes dados e propiciará a geração de diversos tipos de relatórios, o que representa uma enorme vantagem competitiva para a academia, uma vez que será possível gerar vários tipos de relatório para interpretação da evolução do aluno, comparação com dados históricos e outros tipos que se fizerem necessários. O gerenciamento de turmas, classes, planos de pagamento, cadastro de

21 21 alunos, professores, e demais funcionários também fazem parte do escopo deste sistema que tem por objetivo centralizar toda a gestão da empresa de forma centralizada, fácil e ágil, utilizando tecnologias de ponta no desenvolvimento de software para que entreguemos um produto competitivo, que agregará valor ao negócio do cliente e com um custo aceitável.

22 22 3 ANÁLISE DO SISTEMA 3.1 Introdução Na engenharia de sistemas e engenharia de software, análise de requisitos engloba todas as tarefas que lidam com investigação, definição e escopo de novos sistemas ou alterações. Análise de requisitos é uma parte importante do processo de projeto de sistemas na qual o engenheiro de requisitos e o analista de negócio, juntamente com engenheiro de sistema ou desenvolvedor de software, identificam as necessidades ou requisitos de um cliente, sendo que este levantamento pode ser efetuado através de entrevistas com o cliente. Uma vez que os requisitos do sistema tenham sido identificados, os projetistas de sistemas estarão preparados para projetar a solução. É de suma importância a validação dos requisitos levantados com o cliente para garantir que a solução que será projetada atenda às necessidades e expectativas do cliente. O resultado da análise é o enunciado do problema, e o projeto será a sua resolução. Problemas mal enunciados podem até ser resolvidos, mas a solução não corresponderá às expectativas. A qualidade do processo de análise é importante porque um erro de concepção resolvido na fase de análise tem um custo; na fase de projeto tem um custo maior; na fase de implementação maior ainda, e na fase de implantação do sistema tem um custo relativamente astronômico. (WAZLAWICK, 2004, p 21) Além do mais, é nesta fase também que os riscos do projeto são levantados e enumerados. Conforme Fowler e Scott (2000, p 32) você precisa levar em consideração, acima de tudo, os riscos do seu projeto. Que coisas poderiam descarrilhá-lo? Quanto maior o risco, mais atenção você tem que dar a ele. Os riscos podem ser ultimamente classificados em quatro categorias: Riscos de requisitos. Quais são os requisitos do sistema? O grande perigo é você construir um outro sistema, um sistema que não faz o que o cliente

23 23 necessita. Riscos tecnológicos. Quais são os riscos tecnológicos que você tem que enfrentar? Você está selecionando a tecnologia que realmente fará o serviço por você? As várias partes se encaixarão? Riscos de habilidades. Você pode encontrar o pessoal e especialistas de que necessita? Riscos políticos. Existem forças políticas que podem interferir e afetar seriamente o seu projeto? O seu caso pode ter mais riscos, mas os riscos que se encaixam nestas quatro categorias estão quase sempre presentes. 3.1 Requisitos Requisitos Funcionais Os requisitos funcionais especificam as funcionalidades que o sistema deverá contemplar para atender as necessidades do cliente. Funcionários: Os dados essenciais dos funcionários da empresa que deverão ficar registrados no sistema são: CPF, RG, nome, data de nascimento, , endereço completo, telefones fixo e celular, data de admissão, graduação, inscrição no CREF Conselho Regional de Educação Física (para professores), CTPS, PIS/PASEP, número de registro do empregado. Caso o funcionário seja utilizador do sistema, deverá ser cadastrado seu código de usuário (mesmo do funcionário), senha de acesso e nível de permissão. Alunos: Os dados essenciais dos alunos que deverão ficar registrados no sistema são: Nome, CPF, RG, data de nascimento, telefones fixo e celular, , endereço, cliente responsável (quando o aluno possuir idade inferior a 18 anos ou possuir convênio com empresa), status para titular, convênio empresarial,

24 24 status do aluno (matriculado ou inativo), modalidade, forma de pagamento. No ato da matrícula será gerado um código para o aluno, e deverá ser escolhida pelo menos uma modalidade a ser praticada. A matrícula só será efetivada após o pagamento da taxa da mesma e da primeira mensalidade. Histórico: Deverá haver tratamento para histórico de exames médicos, exames de aptidão física, e acompanhamento pedagógico para cada aluno. Deverá ser registrado no histórico o tipo do evento, data do evento, código do aluno e descrição do evento. Fornecedores: Os dados essenciais dos fornecedores que deverão ficar registrados no sistema são: telefones fixo e celular, , endereço completo, contato, ramo de atividade. No caso do fornecedor ser uma pessoa física, deverá constar nome, RG, CPF e data de nascimento. No caso do fornecedor ser uma pessoa jurídica, deverá constar a razão social, nome fantasia, CNPJ e IE. Clientes: Os dados essenciais dos clientes que deverão ficar registrados no sistema são: telefones fixo e celular, , endereço completo, contato. No caso do cliente ser uma pessoa física, deverá constar nome, RG, CPF e data de nascimento. No caso do cliente ser uma pessoa jurídica, deverá constar a razão social, nome fantasia, CNPJ e IE. Usuários: Os dados essenciais dos usuários que deverão ficar registrados no sistema são: nome completo, nome de usuário, senha, nível de permissão e departamento. Classes: A classe é o local físico da academia, onde serão praticadas as aulas. As classes são organizadas de acordo com o horário, a modalidade e sua distribuição durante a semana. Cada classe deve ter um professor responsável, sendo que este deverá efetuar a manutenção da mesma. A classe é organizada independente da ocorrência de alunos vinculados a ela. Turmas: Para se criar uma turma, deverá haver um mínimo de três

25 25 alunos e um professor associados à mesma, e esta turma deve estar associada a uma classe. Os alunos apenas poderão ser inseridos nas turmas se estiverem com status matriculado no cadastro. Relatórios: Os relatórios que deverão ser gerados: o Relatório de alunos cadastrados com opções de filtro por status, data de nascimento, forma de pagamento ou modalidade nos formatos analítico e/ou sintético (apenas total de alunos por filtro); o Relatório de Históricos de alunos com filtros para tipo de histórico e período; o Relatórios de Turmas e Classes com filtros para professor, turma, classe; o Relatórios financeiros de contas a receber, contas a pagar e caixa com opção de filtro. o Relatório de fornecedores com opção de filtro; o Relatório de funcionários com opção de filtro; o Relatório de movimentação de produtos com opção de filtro; o Relatório de itens com estoque mínimo com opção de filtro; o Relatório de produtos com data de validade vencida com opção de filtro; o Gráficos de movimentação financeira e de produtos com opção de filtro; o Relatórios que podem ser exportados para tabelas em Excel em formato txt. Financeiro: A situação financeira do aluno deverá ser controlada, caso o aluno esteja inadimplente, o débito só será quitado mediante o pagamento integral da dívida. Os campos a serem registrados para os movimentos financeiros são: código (gerado automaticamente), tipo do movimento (contas a pagar, contas a

26 26 receber, caixa, cheque), código do fornecedor ou do cliente (aluno), data do movimento, valor, número do documento, status Pago, status Plano Promocional, data do pagamento, valor pago, valor juros/desconto. Em toda movimentação financeira deverá existir a opção de emitir recibo. Atualmente, existem planos de pagamento promocionais com valores diferenciados. Estes planos são passíveis de manutenção a qualquer momento. Para os planos promocionais, ocorrerá multa rescisória, no caso de pagamentos com cheque pré-datado e desistência da atividade, o valor pago não será ressarcido integralmente, o cheque subseqüente à data atual ficará retido a título de multa rescisória. As formas de recebimento são: à vista (em dinheiro, cheque ou cartão de débito), parcelamento em cartão de crédito ou cheque pré-datado. Os boletos bancários não se aplicam aos planos promocionais, somente poderão ser gerados para a matrícula ou pagamento mensal, haverá cobrança da despesa de boleto no valor de R$ 1,20 por boleto emitido. São os planos promocionais: o Mensal: parcelas mensais; o Quadrimestral: dividido em quatro parcelas iguais; o Semestral: dividido em parcela única, 3 ou 6 parcelas; Requisitos não funcionais Os requisitos não funcionais descrevem os atributos do sistema e os atributos do ambiente do sistema. A aplicação deverá ser construída utilizando as seguintes tecnologias: Struts, Hibernate, Tomcat, Servlets, JavaServer Pages, Html Forms, Java Beans, J2EE Design Patterns e o banco de dados MySQL. Deverá ser utilizado o padrão de Projeto MVC (Model-View-Controller) para o desenvolvimento da aplicação WEB.

27 Diagrama de Casos de Uso O Diagrama de Casos de Uso representa a interação entre atores, agentes externos ao sistema, e o sistema. Na Engenharia de Software, um caso de uso (ou use case) é um tipo de classificador representando uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por seqüências de mensagens intercambiáveis entre os sistemas e um ou mais atores. Um Caso de Uso representa uma unidade discreta da interação entre um usuário (humano ou máquina) e o sistema. Um Caso de Uso é uma unidade de um trabalho significante. Cada Caso de Uso tem uma descrição a qual descreve a funcionalidade que irá ser construída no sistema proposto, pode "incluir" outra funcionalidade de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento. Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade máquina que interage com o sistema para executar um significante trabalho. A Figura 3 representa a interação entre o ator usuário e as funcionalidades que ele executará no sistema. Cada uma das funcionalidades será detalhada na seção de Especificação dos Casos de Uso. A atribuição do ator usuário é: operar o sistema. Seu acesso é bastante amplo e ele pode registrar contas, incluir pessoa, realizar matricula, registrar modalidade esportiva, registrar histórico de aluno e registrar informações do aluno, professor, fornecedor, cliente, turma, classe ou usuário.

28 28 Figura 3 - Diagrama de Casos de Uso

29 Regras de Negócio Nome Cadastro de Professores RN- 01 Descrição O cadastro deverá contemplar a informação do CREF (Conselho Regional de Educação Física) para o professor. Nome Efetivação de Matrícula RN- 02 Descrição No ato da matrícula deverá ser escolhida pelo menos uma modalidade a ser praticada. A matrícula só será efetivada após o pagamento da taxa da mesma e da primeira mensalidade. Após a efetivação da matrícula será gerado o código do aluno. Nome Validação de CPF, CNPJ RN- 03 Descrição O CPF, CNPJ somente devem ser inseridos após a validação, caso sejam inválidos, o cadastro deverá ser interrompido. Nome Organização das Classes RN- 04 Descrição Deve existir um professor responsável para cada classe. Nome Mínimo de Alunos por Turmas RN- 05 Descrição Para se criar uma turma deverá haver um mínimo de três alunos. Nome Inclusão de Alunos em Turmas RN- 06 Descrição Os alunos apenas poderão ser inseridos nas turmas se estiverem com status matriculado no cadastro e existirem vagas disponíveis na turma selecionada. Nome Quitação de débitos de Mensalidade e Matrícula RN- 07 Descrição No caso de uma mensalidade anterior em aberto, a mensalidade atual só poderá ser paga caso a mensalidade em aberto seja quitada. Nome Multa Rescisória de Mensalidade e Matrícula RN- 08 Descrição Para os planos promocionais, ocorrerá multa rescisória, no caso de pagamentos com cheque pré-datado e desistência da atividade, o valor pago não será ressarcido integralmente, o cheque subseqüente à data atual ficará retido a título de multa rescisória. Nome Planos de Pagamento de Mensalidade e Matrícula RN- 09 Descrição Atualmente existem planos de pagamento promocionais com valores diferenciados, que são: mensal (parcelas mensais), quadrimestral (dividido em 4 parcelas iguais), semestral (dividido em parcela única, 3 ou 6 parcelas). Estes planos são passíveis de manutenção a qualquer momento. Nome Emissão de recibo de Mensalidade e Matrícula RN- 10 Descrição Em toda movimentação financeira deverá existir a opção de emitir recibo.

30 30 Nome Formas de Recebimento de Mensalidade e Matrícula RN- 11 Descrição As formas de recebimento são: à vista (em dinheiro, cheque ou cartão de débito), parcelamento em cartão de crédito ou cheque pré-datado. Nome Boleto Bancário de Mensalidade e Matrícula RN- 12 Descrição Os boletos bancários não se aplicam aos planos promocionais, somente poderão ser gerados para a matrícula ou pagamento mensal, haverá cobrança da despesa de boleto no valor de R$ 1,20 por boleto emitido. Nome Campos a Serem registrados no Controle Financeiro RN- 13 Descrição Os campos a serem registrados para os movimentos financeiros são: código (gerado automaticamente), tipo do movimento (contas a pagar, contas a receber, caixa, cheque), código do fornecedor ou do cliente (aluno), data do movimento, valor, número do documento, status Pago, status Plano Promocional, data do pagamento, valor pago, valor juros/desconto. Tabela 1 - Regras de Negócio

31 Especificação dos Casos de Uso Para uma melhor compreensão de cada funcionalidade do sistema, detalha-se a seguir a análise realizada de cada caso de uso. Na figura 4 é descrito o processo de manutenção de alunos. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Manter aluno CSU01 Sumário Ator primário: Usuário O usuário realiza a manutenção de um aluno Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações do aluno são alteradas. Fluxo Principal 1. O usuário seleciona Manter aluno. 2. O sistema exibe opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de aluno 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O sistema valida o CPF/CNPJ. 3. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de aluno 1. Caso o usuário selecione Alteração, deverá informar o aluno a ser alterado e alterar os dados desejados. 2. O sistema valida CPF/CNPJ. 3. O caso de uso retorna ao passo 4. Fluxo Exceção [1]: Dados necessários não informados 1. Caso os dados solicitados não sejam informados, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Fluxo Exceção [2]: Aluno não encontrado no banco de dados 1. Caso não seja encontrado o aluno pesquisado o sistema exibe uma mensagem de erro. O caso de uso retorna ao passo 3. Regras de Negócio Associadas RN-03 Figura 4 - Detalhe do Caso de Uso CSU01

32 32 Na figura 5, é descrito o processo de manutenção de um professor. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Manter professor CSU02 Sumário Ator primário: Usuário O usuário realiza a manutenção de um professor Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações do professor são alteradas. Fluxo Principal 1. O usuário seleciona Manter professor. 2. O sistema exibe opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de professor 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O sistema valida CPF/CNPJ e CREF. 3. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de professor 1. Caso o usuário selecione Alteração, deverá informar o professor a ser alterado e alterar os dados desejados. 2. O sistema valida CPF/CNPJ e CREF. 3. O caso de uso retorna ao passo 4. Fluxo Exceção [1]: Dados necessários não informados 1. Caso os dados solicitados não sejam informados, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3 Fluxo Exceção [2]: Professor não encontrado no banco de dados 1. Caso não seja encontrado o professor pesquisado o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Regras de Negócio Associadas RN-01, RN-03 Figura 5 - Detalhe do Caso de Uso CSU02

33 33 Na figura 6, é descrito o processo de manutenção de um fornecedor. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Manter fornecedor CSU03 Sumário Ator primário: Usuário O usuário realiza a manutenção de um fornecedor Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações do fornecedor são alteradas. Fluxo Principal 1. O usuário seleciona Manter fornecedor. 2. O sistema exibe opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de fornecedor 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O sistema valida CPF/CNPJ. 3. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de fornecedor 1. Caso o usuário selecione Alteração, deverá informar o fornecedor a ser alterado e alterar os dados desejados. 2. O sistema valida CPF/CNPJ. 3. O caso de uso retorna ao passo 4. Fluxo Exceção [1]: Dados necessários não informados 1. Caso os dados solicitados não sejam informados, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Fluxo Exceção [2]: Fornecedor não encontrado no banco de dados 1. Caso não seja encontrado o fornecedor pesquisado o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Regras de Negócio Associadas RN-03 Figura 6 - Detalhe do Caso de Uso CSU03

34 34 Na figura 7, é descrito o processo de manutenção de um cliente. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Manter cliente CSU04 Sumário Ator primário: Usuário O usuário realiza a manutenção de um cliente Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações do cliente são alteradas. Fluxo Principal 1. O usuário seleciona Manter cliente. 2. O sistema exibe as opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de cliente 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O sistema valida CPF/CNPJ. 3. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de cliente 1. Caso o usuário selecione Alteração, deverá informar o cliente a ser alterado e alterar os dados desejados. 2. O sistema valida CPF/CNPJ. 3. O caso de uso retorna ao passo 4. Fluxo Exceção [1]: Dados necessários não informados 1. Caso os dados solicitados não sejam informados, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Fluxo Exceção [2]: Cliente não encontrado no banco de dados 1. Caso não seja encontrado o cliente pesquisado o sistema exibe uma mensagem de erro. O caso de uso retorna ao passo 3. Regras de Negócio Associadas RN-03 Figura 7 - Detalhe do Caso de Uso CSU04

35 35 Na figura 8, é descrito o processo de manutenção de uma turma. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Manter turma CSU05 Sumário Ator primário: Usuário O usuário realiza a manutenção de turmas Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações da turma são alteradas. Fluxo Principal 1. O usuário seleciona Manter turma. 2. O sistema exibe as opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de turma 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O sistema solicita a quantidade de alunos da turma. 3. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de turma 1. Caso o usuário selecione Alteração, deverá informar a turma a ser alterada e alterar os dados desejados. 2. O caso de uso retorna ao passo 4. Fluxo Exceção [1]: Professor responsável não informado 1. Caso o professor não seja informado, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Fluxo Exceção [2]: Quantidade de alunos inferior à permitida 1. Caso seja informada uma quantidade inferior a 3 alunos, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Fluxo Exceção [3]: Turma não encontrada no banco de dados 1. Caso não seja encontrada a turma pesquisada o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Regras de Negócio Associadas RN-05, RN-06 Figura 8 - Detalhe do Caso de Uso CSU05

36 36 Na figura 9, é descrito o processo de manutenção de uma matrícula. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Realizar Matrícula CSU06 Sumário Ator primário: Usuário O usuário realiza a matrícula de um aluno. Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações do aluno são cadastradas no sistema e a matrícula é efetuada. Fluxo Principal 1. O usuário seleciona Manter aluno. 2. O sistema exibe as opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada e seleciona a aba Modalidades no cadastro do aluno. 4. O usuário seleciona as modalidades em que o aluno está se matriculando. 5. O sistema registra a matrícula. 6. Caso de uso é encerrado. Fluxo Exceção [1]: Código do aluno não encontrado 1. O aluno deve ser cadastrado antes de ser efetuada sua matrícula. O caso de uso retorna ao passo 2. Fluxo Exceção [2]: Informações incompletas 1. Caso falte alguma informação da matrícula, o sistema emite uma mensagem de erro e o caso de uso retorna ao passo 2. Regras de Negócio Associadas RN-02, RN-09, RN-10, RN-11 Figura 9 - Detalhe do Caso de Uso CSU06

37 37 Na figura 10, é descrito o processo de manutenção de uma modalidade esportiva. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Registrar modalidade esportiva CSU07 Sumário Ator primário: Usuário O usuário realiza o registro de uma nova modalidade esportiva Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: A nova modalidade será incluída no sistema Fluxo Principal 1. O usuário seleciona Registrar modalidade esportiva. 2. O sistema exibe as opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de modalidade 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de modalidade 1. Caso o usuário selecione Alteração, deverá informar a modalidade a ser alterada e alterar os dados desejados. 2. O caso de uso retorna ao passo 4. Fluxo Exceção [1]: Dados incompletos 1. Se as informações não estiverem completas e/ou estiverem incorretas, o caso de uso retorna uma mensagem de erro e volta ao passo 2 Figura 10 - Detalhe do Caso de Uso CSU07 Na figura 11, é descrita a análise efetuada para o desenvolvimento do processo de Geração de Relatórios, que devido à complexidade do processo, não foi implementado no software.

38 38 Nome Gerar Relatório CSU08 Sumário Ator primário: Usuário Geração de relatórios. Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: O relatório selecionado é gerado na tela, impressora ou arquivo. Fluxo Principal 1. O usuário seleciona Gerar relatório; 2. O sistema exibe os relatórios disponíveis e a opção Retornar. 3. O usuário seleciona o relatório ou Retornar. 4. O sistema solicita os dados para filtro por detalhe (analítico ou sintético) 5. O sistema habilita as opções de geração em Gráfico, TXT e Retornar. 6. O caso de uso é encerrado. Fluxo Alternativo [1]: Tipo de opção 1. Caso o usuário selecione Gerar, o caso de uso retorna ao passo Caso o usuário selecione Retornar, o caso de uso retorna ao passo 6 Fluxo Alternativo [2]: Filtro por detalhe 1. Quando aplicável, o sistema habilita a opção Sintético para ser exibido o total de acordo com o filtro, se for desmarcada a opção analítico, o relatório será exibido sem os registros analíticos; 2. O usuário seleciona o filtro e o caso de uso retorna para o passo 5. Fluxo Alternativo [3]: Relatório tipo TXT 1. Caso o usuário solicite um relatório TXT, será apresentado na tela, o relatório, com a opção de Imprimir, Salvar ou Retornar. 2. Caso seja selecionada a opção Salvar, o sistema abre uma tela para ser inserido o nome do arquivo a ser gravado e seu path de destino, grava o arquivo e permanece com o relatório em tela, aguardando a ação do usuário. 3. Caso seja selecionada a impressão, o sistema acessará o Gerenciador de Impressão do sistema operacional e enviará o relatório para a impressora especificada. 4. O caso de uso retorna para o passo 6 Fluxo Alternativo [4]: Relatório tipo Gráfico 1. Quando aplicável, será habilitada a opção Gráfico, o sistema exibirá um gráfico como imagem JPG dos dados do relatório, e exibirá as opções de Salvar, Imprimir ou Retornar. 2. Caso seja selecionada a opção Salvar, o sistema abre uma tela para ser

39 39 inserido o nome do arquivo a ser gravado e seu path de destino, grava o arquivo e permanece com o gráfico em tela, aguardando a ação do usuário. 3. Caso seja selecionada a impressão, o sistema acessará o Gerenciador de Impressão do sistema operacional e enviará o relatório para a impressora especificada. 4. O caso de uso retorna para o passo 6. Fluxo Alternativo [5]: Opção Retornar 1. O caso de uso retorna para o passo 2. Fluxo Exceção [1]: Filtros Inválidos 1. Se na pesquisa, não ocorrerem dados que satisfaçam o filtro, será exibida uma mensagem de erro e retornado para a tela de seleção de relatórios. Figura 11 - Detalhe do Caso de Uso CSU08 Na figura 12, é descrita a análise efetuada para o desenvolvimento do processo de Registro de movimento de caixa, que devido à complexidade do processo, não foi implementado no software. Nome Registrar movimento de caixa CSU09 Sumário Ator primário: Usuário O usuário realiza o registro do movimento de caixa Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: Os dados do caixa são atualizados Fluxo Principal 1. O usuário seleciona Registrar movimento de caixa. 2. O sistema solicita o tipo de operação (Entrada, Saída ou Saldo). 3. O usuário seleciona o tipo de operação. 4. O sistema solicita o tipo de manutenção (Inclusão, Exclusão, Alteração ou Consulta). 5. O usuário informa uma das opções de manutenção. 6. O sistema executa o tipo de manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Tipo de operação 1. Caso seja selecionada a operação de entrada, é registrada uma entrada no caixa; 2. O caso de uso retorna ao passo 3;

40 40 3. Caso seja selecionada a operação de saída, é registrada uma saída no caixa; 4. O caso de uso retorna ao passo 3; 5. Caso seja selecionada a operação de saldo, o sistema solicita o período de apuração de saldo e retorna a informação; 6. O caso de uso retorna ao passo 4; Fluxo Alternativo [2]: Inclusão de movimento 1. Caso seja selecionada a opção Inclusão, o sistema solicita os dados do lançamento; 2. O usuário preenche os dados; 3. O sistema valida os mesmos e solicita a confirmação para impressão do recibo; 4. O caso de uso retorna ao passo 6; Fluxo Alternativo [3]: Alteração de movimento 1. Caso seja selecionada a opção Alteração, o sistema solicita os dados do lançamento a ser pesquisado, após encontrá-lo, abre o lançamento para alteração; 2. O usuário altera os dados necessários e confirma a alteração. 3. O caso de uso retorna ao passo 6; Fluxo Alternativo [4]: Exclusão de movimento 1. Caso seja selecionada a opção Exclusão, o sistema solicita os dados do lançamento a ser pesquisado; 2. O usuário informa os dados; 3. O sistema pesquisa o movimento e, após encontrá-lo, abre o lançamento e solicita a confirmação da exclusão; 4. O caso de uso retorna ao passo 6; Fluxo Alternativo [5]: Consulta de movimento 1. Caso seja selecionada a opção Consulta, o sistema solicita os dados a serem pesquisados; 2. O usuário informa os dados; 3. O sistema pesquisa o lançamento e suas informações serão exibidas; 4. O caso de uso retorna ao passo 6; Fluxo de Exceção [1]: Dados inválidos 1. Se os dados do movimento forem informados incorretamente, o caso de uso retorna uma mensagem de erro e volta ao passo 4 Regras de Negócio Associadas RN-10, RN-11, RN-13 Figura 12 - Detalhe do Caso de Uso CSU09

41 41 Na figura 13, é descrito o processo de manutenção do histórico do aluno. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Registrar histórico do aluno CSU10 Sumário Este caso de uso permite a inserção de eventos (exames médicos, exames de aptidão física e acompanhamento pedagógico) no histórico de um aluno. Ator primário: Usuário Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: Os eventos são inseridos no histórico do aluno Fluxo Principal 1. O usuário seleciona Manter aluno. 2. O sistema exibe as opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada e seleciona a aba Histórico no cadastro do aluno. 4. O usuário efetua a manutenção no histórico do aluno. 5. Caso de uso é encerrado. Fluxo Exceção [1]: Código do aluno não encontrado 1. O aluno deve ser cadastrado antes de ser efetuada a manutenção. O caso de uso retorna ao passo 2. Fluxo Exceção [2]: Informação incorreta 1. Caso haja alguma informação incorreta, o sistema exibe uma mensagem de erro e o caso de uso retorna ao passo 2. Figura 13 - Detalhe do Caso de Uso CSU10

42 42 Na figura 14, é descrito o processo de manutenção de classes. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Manter classe CSU11 Sumário Ator primário: Usuário O usuário realiza manutenção de classes Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações da classe são alteradas. Fluxo Principal 1. O usuário seleciona Manter classe 2. O sistema exibe as opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de classe 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de classe 1. Caso o usuário selecione Alteração, deverá informar a classe a ser alterada e alterar os dados desejados. 2. O caso de uso retorna ao passo 4 Fluxo Exceção [1]: Professor responsável não informado 1. Caso o professor não seja informado, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Fluxo Exceção [2]: Classe não encontrada no banco de dados 1. Caso não seja encontrada a classe pesquisada o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Regras de Negócio Associadas RN-04 Figura 14 - Detalhe do Caso de Uso CSU11

43 43 Na figura 15, é descrita a análise efetuada para o desenvolvimento do processo de Registro de contas, que devido à complexidade do processo, não foi implementado no software. Nome Registrar Contas CSU12 Sumário Ator primário: Usuário O usuário realiza o registro de contas Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: Os dados das Contas são atualizados Fluxo Principal 1. O usuário seleciona Registrar contas. 2. O sistema solicita o tipo de operação (Contas a receber ou Contas a pagar). 3. O usuário seleciona o tipo de operação. 4. O sistema solicita o tipo de manutenção (Inclusão, Alteração, Exclusão, Consulta ou Liquidação). 5. O usuário informa uma das opções de manutenção. 6. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Tipo de operação 1. Se selecionado Contas a receber, serão acessados os dados de Contas a receber, se selecionado Contas a pagar, serão acessados os dados de Contas a pagar. 2. O sistema retorna ao passo 4. Fluxo Alternativo [2]: Inclusão de contas 1. O sistema solicita os dados do documento a ser incluído; 2. O usuário informa dados para inclusão do documento e o caso de uso retorna ao passo 6. Fluxo Alternativo [3]: Exclusão de contas 1. O sistema solicita os dados do documento a ser excluído; 2. O usuário informa dados para identificação do documento; 3. O sistema solicita a confirmação de exclusão e o caso de uso retorna ao passo 6. Fluxo Alternativo [4]: Alteração de contas 1. O sistema solicita os dados do documento a ser alterado; 2. O usuário informa dados para identificação do documento; 3. O sistema efetua a pesquisa e solicita os dados a serem alterados; 4. O usuário altera os dados e o caso de uso retorna ao passo 6.

44 44 Fluxo Alternativo [5]: Consulta de contas 1. O sistema solicita os dados a serem consultados; 2. O usuário informa os dados para identificação do documento; 3. O sistema efetua a pesquisa e o caso de uso retorna ao passo 6. Fluxo Alternativo [6]: Liquidação de contas 1. O sistema solicita os dados do documento a ser liquidado; 2. O usuário informa os dados para identificação do documento; 3. O sistema efetua a pesquisa e solicita a confirmação de liquidação; 4. O sistema solicita a emissão de recibo para a liquidação e o caso de uso retorna ao passo 6. Fluxo de Exceção [1]: Dados inválidos 1. Se os dados do movimento forem informados incorretamente o caso de uso retorna uma mensagem de erro e volta ao passo 2. Regras de Negócio Associadas RN-07, RN- 10, RN-11, RN-12, RN-13 Figura 15 - Detalhe do Caso de Uso CSU12

45 45 Na figura 16, é descrito o processo de manutenção de usuários. Para uma correta manutenção, é necessária a informação dos campos solicitados. Nome Manter usuário CSU13 Sumário Ator primário: Usuário O usuário realiza a manutenção de um usuário Pré-Condição: O usuário com permissões para esta opção estar logado. Pós Condição: As informações do usuário são alteradas. Fluxo Principal 1. O usuário seleciona Manter usuário. 2. O sistema exibe opções Novo, Busca e Alteração. 3. O usuário seleciona a opção desejada. 4. O sistema executa a manutenção e o caso de uso é encerrado. Fluxo Alternativo [1]: Inclusão de usuário 1. Caso o usuário selecione Inclusão, deverá informar os dados solicitados pelo sistema. 2. O caso de uso retorna ao passo 4 Fluxo Alternativo [2]: Busca e Alteração de usuário 1. Caso o usuário selecione Alteração, deverá informar o aluno a ser alterado e alterar os dados desejados. 2. O caso de uso retorna ao passo 4. Fluxo Exceção [1]: Dados necessários não informados 1. Caso os dados solicitados não sejam informados, o sistema exibe uma mensagem de erro, o caso de uso retorna ao passo 3. Fluxo Exceção [2]: Usuário não encontrado no banco de dados 1. Caso não seja encontrado o usuário pesquisado o sistema exibe uma mensagem de erro. O caso de uso retorna ao passo 3. Figura 16 - Detalhe do Caso de Uso CSU13

46 Diagrama de Classes de Negócio O Diagrama de Classes descreve as classes que compõem a estrutura do sistema e suas relações. O diagrama de classes não é somente amplamente usado, mas também o receptáculo para o maior escopo de conceitos de modelagem. Um diagrama de classes descreve os tipos de objetos no sistema e os vários tipos de relacionamento estático que existem entre eles. (FOWLER E SCOTT 2000, p 57) Na Figura 17 é apresentado o diagrama de classes desenvolvido após a análise de requisitos, que será explicado mais detalhadamente no próximo tópico. Figura 17 - Diagrama de Classes de Negócio

47 Especificação das Classes de Negócio Turma Esta classe está relacionada com o caso de uso Manter Turma e tem como responsabilidade definir os atributos para uma turma. Atributos: horário e status. Usuario Esta classe está relacionada com o caso de uso Manter Usuário e tem como responsabilidade definir os atributos para um usuário do sistema. Atributos: Código, CPF, data de inclusão, departamento, endereço, nível de acesso, nome, RG, senha, status e telefone. Plano Esta classe está relacionada com o caso de uso Manter Plano e tem como responsabilidade definir os atributos para os planos definidos no sistema. Atributos: descrição e percentual de desconto. Classe Esta classe está relacionada com o caso de uso Manter Classe e tem como responsabilidade definir os atributos para classes. Atributos: código do professor, local, número de vagas e status. Historico Esta classe está relacionada com o caso de uso Manter Histórico e tem como responsabilidade definir os atributos para definição de Históricos. Atributos: código do aluno, data, ocorrência e tipo. Professor Esta classe está relacionada com o caso de uso Manter Professor e tem como responsabilidade definir os atributos para os professores. Atributos: código, CPF, CREF, data de inclusão, endereço, nome, RG, status e telefone. Matricula Esta classe está relacionada com o caso de uso Realizar Matricula e tem como responsabilidade definir os atributos para a realização de matrículas dos alunos. Atributos: código do aluno, código da matrícula, código da turma, status da matrícula e valor da mensalidade. Fornecedor Esta classe está relacionada com o caso de uso Manter Fornecedor e tem como responsabilidade definir os atributos para os fornecedores do sistema. Atributos: código, CPF_CNPJ, data de inclusão, endereço, razão social, RG_IE, status e telefone.

48 48 Aluno Esta classe está relacionada com o caso de uso Manter Aluno e tem como responsabilidade definir os atributos para os alunos do sistema. Atributos: código do cliente, código do aluno, CPF, data de inclusão, data de nascimento, endereço, nome, RG, status e telefone. Modalidade Esta classe está relacionada com o caso de uso Registrar Modalidade Esportiva e tem como responsabilidade definir os atributos para as modalidades esportivas cadastradas no sistema. Atributos: descrição. Cliente Esta classe está relacionada com os casos de uso Manter Aluno, Manter Cliente, Registrar Movimentação Financeira e tem como responsabilidade definir os atributos para os clientes. Atributos: CPF_CNPJ, data de inclusão, endereço, nome, RG_IE, status, telefone, tipo. MovimentacaoFinanceira Esta classe está relacionada com os casos de uso Registrar Movimento de Caixa e Registrar Contas e tem como responsabilidade definir os atributos das transações financeiras para as classes que os herdam. Atributos: data do movimento, histórico, nome, tipo e valor. Cheque Esta classe está relacionada com o caso de uso Registrar Movimento de Caixa e tem como responsabilidade definir os atributos para transações financeiras efetuadas com cheques. Atributos: banco, conta, data de emissão, data de vencimento, número do cheque, sacado, status e valor. Recibo Esta classe está relacionada com o caso de uso Registrar Movimento de Caixa e tem como responsabilidade definir os atributos para emissão de recibos de pagamento e recebimento efetuados pelo caixa. Atributos: número do recibo. Caixa Esta classe está relacionada com o caso de uso Registrar Movimento de Caixa e tem como responsabilidade definir atributos para o tipo de lançamento do caixa, se o mesmo é credor ou devedor. Atributos: tipo. Contas Esta classe está relacionada com o caso de uso Registrar Contas e tem como responsabilidade definir os atributos para as transações de contas a pagar e contas a receber no sistema. Atributos: data de emissão, data de vencimento, data de pagamento e status. Boleto Esta classe está relacionada com o caso de uso Registrar

49 49 Contas e tem como responsabilidade definir os atributos para os boletos bancários para as transações de contas a pagar e contas a receber. Atributos: banco, desconto, juros, multa, nosso número, sacado e valor total. Relatório Esta classe está relacionada com o caso de uso Gerar Relatório e tem como responsabilidade coletar as informações para filtragem dos dados para geração dos relatórios. Atributos: filtro. 3.6 Classes de análise As classes de análise representam um primeiro modelo conceitual para elementos no sistema que possuam responsabilidades e comportamento. Com o tempo, elas evoluirão para classes e subsistemas no Modelo de Design. As classes de análise são classificadas em: Classes de Fronteira, Controle e Entidade. Figura 18 - Estereótipos de Classes de Análise

50 Classes de Fronteira A classe de fronteira é uma classe usada para modelar a interação entre o ambiente do sistema e seus trabalhos internos. Essa interação envolve transformar e converter eventos, bem como observar mudanças na apresentação do sistema. Representam as interfaces entre o sistema e alguma entidade fora dele Classe de Fronteira do Caso de Uso Manter Aluno Tela de Cadastro de Aluno interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de alunos. Sua função é permitir a entrada de dados para consulta aos alunos cadastrados ou incluir novos no cadastro. Através do nome do aluno, o sistema busca-o no cadastro e exibe seus dados para edição ou consulta, quando não é encontrado o aluno, o sistema exibe a tela para inclusão de um novo Classe de Fronteira do Caso de Uso Manter Professor Tela de Cadastro de Professor interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de professores. Sua função é permitir a entrada de dados para consulta aos professores cadastrados ou incluir novos no cadastro. Através do nome do professor, o sistema busca-o no cadastro e exibe seus dados para edição ou consulta, quando não é encontrado o professor, o sistema exibe a tela para inclusão de um novo Classe de Fronteira do Caso de Uso Manter Fornecedor Tela de Cadastro de Fornecedor interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de fornecedores. Sua função é permitir a entrada de dados para consulta aos fornecedores cadastrados ou incluir novos no cadastro. Através do nome do fornecedor, o sistema busca-o no cadastro e

51 51 exibe seus dados para edição ou consulta, quando não é encontrado o fornecedor, o sistema exibe a tela para inclusão de um novo Classe de Fronteira do Caso de Uso Manter Cliente Tela de Cadastro de Cliente interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de clientes. Sua função é permitir a entrada de dados para consulta aos clientes cadastrados ou incluir novos no cadastro. Através do nome do cliente, o sistema busca-o no cadastro e exibe seus dados para edição ou consulta, quando não é encontrado o cliente, o sistema exibe a tela para inclusão de um novo Classe de Fronteira do Caso de Uso Manter Turma Tela de Cadastro de Turmas interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de turmas. Sua função é permitir a entrada de dados para consulta às turmas cadastradas ou incluir novas no cadastro. Através do nome da turma, o sistema busca-a no cadastro e exibe seus dados para edição ou consulta, quando não é encontrada a turma, o sistema exibe a tela para inclusão de uma nova Classe de Fronteira do Caso de Uso Realizar Matrícula Tela de Cadastro de Matrícula interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de matrículas. Sua função é permitir a entrada de dados para consulta aos alunos matriculados ou incluir novas no cadastro. Através do nome do aluno, o sistema busca-o no cadastro e exibe os dados das matrículas realizadas permitindo sua manutenção.

52 Classe de Fronteira do Caso de Uso Registrar Modalidade Esportiva Tela de Cadastro de Modalidade interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de modalidades esportivas. Sua função é permitir a entrada de dados para consulta às modalidades esportivas cadastradas ou incluir novas no cadastro. Através do nome da modalidade, o sistema busca-a no cadastro e exibe seus dados permitindo sua manutenção. Quando não é encontrada a mesma, é permitida sua inclusão Classe de Fronteira do Caso de Uso Gerar Relatório Tela de Seleção de Relatório interface que realiza a interação entre o usuário e o sistema, com objetivo de seleção de relatório a ser apresentado. Sua função é permitir a escolha do relatório, dos filtros para geração do mesmo e do tipo de saída desejada, que pode ser arquivo texto, planilha ou impressão Classe de Fronteira do Caso de Uso Registrar Movimento de Caixa Tela de Cadastro de Caixa interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de transações financeiras no caixa. Sua função é permitir a entrada de dados para manutenção de lançamentos de entrada e saída de numerário na empresa e apurar o saldo do caixa Classe de Fronteira do Caso de Uso Registrar Histórico do Aluno Tela de Cadastro de Histórico interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de histórico do aluno. Sua função é permitir a entrada de dados para consulta às ocorrências cadastradas ou incluir novas. Através do nome do aluno, o sistema busca-o no cadastro e exibe seus

53 53 dados permitindo sua manutenção. Quando não é encontrado o mesmo, é permitida sua inclusão e do seu histórico Classe de Fronteira do Caso de Uso Manter Classe Tela de Cadastro de Classe interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de classes. Sua função é permitir a entrada de dados para consulta às classes cadastradas ou incluir novas no cadastro. Através do nome da classe, o sistema busca-a no cadastro e exibe seus dados permitindo sua manutenção. Quando não é encontrada a mesma, é permitida sua inclusão Classe de Fronteira do Caso de Uso Registrar Contas Tela de Cadastro de Conta interface que realiza a interação entre o usuário e o sistema, com objetivo de manutenção de transações financeiras no contas a receber e contas a pagar. Sua função é permitir a entrada de dados para manutenção de lançamentos de entrada e saída de dívidas à prazo para recebimento ou pagamento Classe de Fronteira do Caso de Uso Manter Usuário Tela de Cadastro de Usuário interface que realiza a interação entre o usuário e o sistema, com o objetivo de manutenção de usuários. Sua função é permitir a entrada de dados para consulta aos usuários cadastrados ou incluir novos usuários. Através do nome do usuário, o sistema busca-o no cadastro e exibe seus dados permitindo sua manutenção. Quando não é encontrado o mesmo, é permitida sua inclusão Classes de Controle A classe de controle é uma classe usada para modelar um comportamento de controle específico de um ou alguns casos de uso. Como objetos

54 54 de controle (instâncias de classes de controle) geralmente controlam outros objetos, o comportamento de objetos de controle é do tipo coordenador. As classes de controle encapsulam um comportamento específico de caso de uso Classe de Controle do Caso de Uso Manter Aluno ControladorAluno esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Aluno com a classe de entidade Aluno. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Manter Professor ControladorProfessor esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Professor com a classe de entidade Professor. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Manter Fornecedor ControladorFornecedor esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Fornecedor com a classe de entidade Fornecedor. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Manter Cliente ControladorCliente esta classe de controle é utilizada para interligar a

55 55 classe de fronteira Tela de Cadastro de Cliente com a classe de entidade Cliente. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Manter Turma ControladorTurma esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Turma com a classe de entidade Turma. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Registrar Matrícula ControladorMatrícula esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Matrícula com a classe de entidade Matrícula. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Registrar Modalidade Esportiva ControladorModalidade esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Modalidade com a classe de entidade Modalidade. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário.

56 Classe de Controle do Caso de Uso Gerar Relatório ControladorRelatorio esta classe de controle é utilizada para interligar a classe de fronteira Tela de Seleção de Relatório com a classe de entidade Relatório. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Registrar Caixa ControladorCaixa esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Caixa com a classe de entidade Caixa. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Registrar Histórico do Aluno ControladorHistórico esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Histórico com a classe de entidade Histórico. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Manter Classe ControladorClasse esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Classe com a classe de entidade Classe. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário.

57 Classe de Controle do Caso de Uso Registrar Contas ControladorConta esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Conta com a classe de entidade Conta. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classe de Controle do Caso de Uso Manter Usuário ControladorUsuario esta classe de controle é utilizada para interligar a classe de fronteira Tela de Cadastro de Usuário com a classe de entidade Usuario. Sua função é interpretar e modelar o comportamento do usuário do sistema, repassá-lo à classe de entidade, interpretar e modelar o comportamento da classe de entidade e repassá-lo ao usuário Classes de Entidade A classe de entidade é uma classe usada para modelar as informações e o comportamento associado que devem ser armazenados. Os objetos de entidade (instâncias de classes de entidade) são usados para manter e atualizar informações sobre alguns fenômenos, como um evento, uma pessoa ou algum objeto real. Esses objetos geralmente são persistentes, precisando de atributos e relacionamentos durante muito tempo, algumas vezes durante todo o ciclo de vida do sistema. implementados. Representam as classes de persistência dos casos de uso Classe de Entidade do Caso de Uso Manter Aluno Entidade Aluno esta classe de entidades possui atributos referentes ao Aluno, sua atribuição é armazenar os dados pessoais dos alunos cadastrados no software.

58 Classe de Entidade do Caso de Uso Manter Professor Entidade Professor esta classe de entidades possui atributos referentes ao Professor, sua atribuição é armazenar os dados pessoais dos professores cadastrados no software Classe de Entidade do Caso de Uso Manter Fornecedor Entidade Fornecedor esta classe de entidades possui atributos referentes ao Fornecedor, sua atribuição é armazenar os dados pessoais dos fornecedores cadastrados no software Classe de Entidade do Caso de Uso Manter Cliente Entidade Cliente esta classe de entidades possui atributos referentes ao Cliente, sua atribuição é armazenar os dados pessoais dos clientes cadastrados no software Classe de Entidade do Caso de Uso Manter Turma Entidade Turma esta classe de entidades possui atributos referentes à Turma, sua atribuição é armazenar os dados das turmas, como horários e número de alunos, que são formadas para prática das atividades ministradas pela academia Classe de Entidade do Caso de Uso Registrar Matrícula Entidade Matrícula esta classe de entidades possui atributos referentes às matrículas realizadas pelos alunos, sua atribuição é armazenar os dados das matrículas e os alunos relacionados às mesmas cadastradas no software.

59 Classe de Entidade do Caso de Uso Registrar Modalidades Esportivas Entidade Modalidade esta classe de entidades possui atributos referentes às modalidades esportivas, sua atribuição é armazenar os dados das modalidades esportivas ministradas pela academia Classe de Entidade do Caso de Uso Gerar Relatório Entidade Relatório esta classe de entidades possui atributos referentes aos filtros para seleção de relatórios, sua atribuição é armazenar os dados destes filtros para efetuar a busca e seleção dos dados para gerar os relatórios Classe de Entidade do Caso de Uso Registrar Movimento de Caixa Entidade Caixa esta classe de entidades possui atributos referentes ao Caixa, sua atribuição é armazenar os dados dos lançamentos do caixa e do saldo após cada lançamento efetuado Classe de Entidade do Caso de Uso Registrar Histórico Entidade Histórico esta classe de entidades possui atributos referentes ao Histórico, sua atribuição é armazenar os dados das ocorrências registradas para cada aluno cadastrado no software Classe de Entidade do Caso de Uso Manter Classe Entidade Classe esta classe de entidades possui atributos referentes à Classe, sua atribuição é armazenar os dados das classes onde serão ministradas as modalidades esportivas.

60 Classe de Entidade do Caso de Uso Registrar Contas Entidade Contas esta classe de entidades possui atributos referentes às contas a pagar e a receber, sua atribuição é armazenar os dados dos lançamentos de contas a pagar e contas a receber, como seus fornecedores ou clientes, datas e valores Classe de Entidade do Caso de Uso Manter Usuário Entidade Usuário esta classe de entidades possui atributos referentes ao Usuário, sua atribuição é armazenar os dados dos usuários cadastrados no sistema, bem como sua senha e nível de acesso. 3.7 Diagrama de Classes de Análise dos Casos de Uso Os diagramas de classes de análise dos casos de uso demonstram as classes participantes de cada um dos casos de uso do sistema. Para sua representação, foram utilizados os estereótipos de fronteira, controlador e entidade, que seguem abaixo Diagrama de Classe de Análise do Caso de Uso Manter Aluno Figura 19 - Diagrama de Classe de Análise do Caso de Uso Manter Aluno

61 61 Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto aluno Diagrama de Classe de Análise do Caso de Uso Manter Fornecedor Figura 20 - Diagrama de Classe de Análise do Caso de Uso Manter Fornecedor Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto fornecedor Diagrama de Classe de Análise do Caso de Uso Manter Professor Figura 21 - Diagrama de Classe de Análise do Caso de Uso Manter Professor

62 62 Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto professor Diagrama de Classe de Análise do Caso de Uso Manter Cliente Figura 22 - Diagrama de Classe de Análise do Caso de Uso Manter Cliente Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto cliente Diagrama de Classe de Análise do Caso de Uso Manter Turma Figura 23 - Diagrama de Classe de Análise do Caso de Uso Manter Turma

63 63 Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto turma Diagrama de Classe de Análise do Caso de Uso Realizar Matrícula Figura 24 - Diagrama de Classe de Análise do Caso de Uso Realizar Matrícula Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto matrícula Diagrama de Classe de Análise do Caso de Uso Registrar Modalidade Esportiva Figura 25 - Diagrama de Classe de Análise do Caso de Uso Registrar Modalidade Esportiva

64 64 Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto modalidade Diagrama de Classe de Análise do Caso de Uso Gerar Relatório Figura 26 - Diagrama de Classe de Análise do Caso de Uso Gerar Relatório Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto relatório Diagrama de Classe de Análise do Caso de Uso Registrar Movimento de Caixa Figura 27 - Diagrama de Classe de Análise do Caso de Uso Registrar Movimento de Caixa

65 65 Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto caixa Diagrama de Classe de Análise do Caso de Uso Registrar Histórico do Aluno Figura 28 - Diagrama de Classe de Análise do Caso de Uso Registrar Histórico do Aluno Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto histórico Diagrama de Classe de Análise do Caso de Uso Manter Classe Figura 29 - Diagrama de Classe de Análise do Caso de Uso Manter Classe

66 66 Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto classe Diagrama de Classe de Análise do Caso de Uso Registrar Contas Figura 30 - Diagrama de Classe de Análise do Caso de Uso Registrar Contas Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto contas Diagrama de Classe de Análise do Caso de Uso Manter Usuário Figura 31 - Diagrama de Classe de Análise do Caso de Uso Manter Usuário

67 67 Esse diagrama demonstra a interação entre o usuário e o sistema, que recebe as requisições enviadas pelo usuário através da interface, envia-as ao controlador que executa a ação de gerenciar o objeto usuário. 3.8 Comportamento Dinâmico O Diagrama de Sequência é uma das ferramentas UML usadas para representar interações entre objetos de um cenário, realizadas através de operações ou métodos (procedimentos ou funções). Este diagrama é construído a partir do Diagrama de Casos de Usos. Primeiro, se define qual o papel do sistema (Use Cases), depois, é definido como o software realizará seu papel (Sequência de operações). O diagrama de sequência dá ênfase a ordenação temporal em que as mensagens são trocadas entre os objetos de um sistema. Entende-se por mensagens os serviços solicitados de um objeto a outro, e as respostas desenvolvidas para as solicitações.

68 68 Figura 32 - Diagrama de Sequência Manter Aluno O Diagrama de Sequência Manter Aluno demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome do aluno, e o sistema permite a manutenção do aluno escolhido ou insere um novo aluno no cadastro.

69 69 Figura 33 - Diagrama de Sequência Manter Professor O Diagrama de Sequência Manter Professor demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome do professor, e o sistema permite a manutenção do professor escolhido ou insere um novo professor no cadastro.

70 70 Figura 34 - Diagrama de Sequência Manter Fornecedor O Diagrama de Sequência Manter Fornecedor demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome do fornecedor, e o sistema permite a manutenção do fornecedor escolhido ou insere um novo fornecedor no cadastro.

71 71 Figura 35 - Diagrama de Sequência Manter Cliente O Diagrama de Sequência Manter Cliente demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome do cliente, e o sistema permite a manutenção do cliente escolhido ou insere um novo cliente no cadastro.

72 72 Figura 36 - Diagrama de Sequência Manter Turma

73 73 O Diagrama de Sequência Manter Turma demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome da turma, e o sistema permite a manutenção da turma escolhida ou insere uma nova turma no cadastro. Figura 37 - Diagrama de Sequência Realizar Matrícula O Diagrama de Sequência Realizar Matrícula demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome do aluno, e o sistema permite a manutenção da sua matrícula no cadastro.

74 74 Figura 38 - Diagrama de Sequência Registrar Modalidade Esportiva

75 75 O Diagrama de Sequência Registrar Modalidade Esportiva demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome da modalidade esportiva, e o sistema permite a manutenção da mesma ou a inclusão de uma nova no cadastro. Figura 39 - Diagrama de Sequência Gerar Relatório O Diagrama de Sequência Gerar Relatório demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o relatório desejado, e o sistema apresenta os filtros para seleção e o tipo de saída para o relatório parametrizado.

76 76 Figura 40 - Diagrama de Sequência Registrar Movimento de Caixa O Diagrama de Sequência Registrar Movimento de Caixa demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o tipo de transação a ser efetuada no caixa.

77 77 Figura 41 - Diagrama de Sequência Registrar Histórico do Aluno O Diagrama de Sequência Registrar Histórico do Aluno demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome do aluno que terá seu histórico alterado e o sistema apresenta o aluno e permite a manutenção em seu cadastro do histórico.

78 78 Figura 42 - Diagrama de Sequência Manter Classe O Diagrama de Sequência Manter Classe demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome da classe, e o sistema permite a manutenção da classe escolhida ou insere uma nova classe no cadastro.

79 79 Figura 43 - Diagrama de Sequência Registrar Contas

80 80 O Diagrama de Sequência Registrar Contas demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o tipo de transação a ser efetuada no Contas a Receber ou Contas a Pagar. Figura 44 - Diagrama de Sequência Manter Usuário

81 81 O Diagrama de Sequência Manter Usuário demonstra as interações entre o usuário e o sistema. Através desta interação, o usuário informa ao sistema o nome do usuário, e o sistema permite a manutenção do usuário escolhido ou insere um novo usuário no cadastro.

82 82 4 INTERFACE O projeto de interface pode ser considerado a parte mais importante do desenvolvimento do sistema do ponto de vista dos usuários finais. Um software que possui uma interface intuitiva e com comandos fáceis de ser assimilados pelos utilizadores será aprendido em um período de tempo menor e conseqüentemente o custo com treinamento e a ocorrência de problemas ao operar o sistema será menor. Frustração e ansiedade fazem parte da vida diária de muitos usuários de sistemas de informação computadorizados. Eles lutam para aprender a linguagem de comandos ou sistemas de seleção por menu, os quais, presume-se, devem ajudá-los. Algumas pessoas enfrentam casos tão sérios de estado de choque diante de computadores, pavor de terminais ou neurose de redes de computador que evitam usar sistemas computadorizados. (SHNEIDERMAN 1987) Além das questões tecnológicas o projeto de interfaces deve levar em consideração também aspectos humanos dos usuários que irão operar o sistema como o perfil destes usuários, a forma como eles serão treinados a utilizar o sistema, o resultado que eles esperam do sistema, etc. Com base nestas premissas criamos o nosso projeto de interfaces utilizando as tecnologias JSP, Java Script, CSS e HTML que são fáceis de ser assimiladas pelos desenvolvedores e capazes de entregar para o usuário final um ambiente amigável e fácil de manipular, associadas às ferramentas Corel Draw e Photoshop. Java Server Pages (JSP) é uma tecnologia baseada na linguagem de programação Java que roda sobre um Servlet e tem a vantagem da portabilidade de plataforma, o permite a sua execução em outros sistemas operacionais, além daqueles criados pela Microsoft. Esta tecnologia permite ao desenvolvedor de páginas para Internet produzir aplicações que, acessam o banco de dados, manipulam arquivos no formato texto, capturam informações a partir de formulários e captam informações sobre o visitante e sobre o servidor. Java Script é uma linguagem de programação utilizada para atender principalmente as seguintes necessidades: Validação de formulários no lado cliente

83 83 (programa navegador); Interação com a página. Assim, foi feita como uma linguagem de script. Javascript tem sintaxe semelhante a do Java, mas é totalmente diferente no conceito e no uso. Oferece tipagem dinâmica - tipos de variáveis não são definidos; É interpretada, ao invés de compilada; Possui ótimas ferramentas padrão para listagens (como as linguagens de script, de modo geral); Oferece bom suporte a expressões regulares (característica também comum a linguagens de script). CSS (Cascading Style Sheets) é um método utilizado para criação de layouts de páginas Web. Ao invés de criar o layout através do próprio HTML, utilizase o CSS. Às vezes utiliza-se o Java Script associado ao CSS para interpretação de comandos. HTML (HyperText Markup Language) é a linguagem de marcação utilizada para produzir páginas na Web que são interpretados por navegadores. Antes de começarmos a trabalhar no projeto realizamos um estudo acerca das cores, marcas, ícones e quaisquer outros símbolos utilizados para identificar a empresa Golfinho de Ouro. Observamos atentamente o site, alguns folders e outros materiais impressos. Com base no resultado de nossa pesquisa definimos as cores, estilo dos botões, fonte das letras e ícones utilizados na confecção das telas do sistema. Além disto, pensamos também durante a fase de projeto na navegabilidade do sistema. Por este motivo realizamos a segmentação do menu baseada nos domínios que seriam disponibilizados, como os domínios aluno, professor, fornecedor, etc. A seguir alguns exemplos das primeiras telas utilizadas, e a evolução delas. Como se pode notar o tempo todo pensou-se na navegabilidade do sistema e também na disposição estratégica dos elementos das telas desde o primeiro protótipo do projeto de interfaces:

84 84 Figura 45 - Primeira versão da tela inicial do domínio Aluno A figura 45 mostra a primeira versão da tela inicial do domínio Aluno. Aqui ainda não tinha sido definido nenhuma exibição, exceto componentes genéricos como calendário, grade e um terceiro campo a ser definido no futuro. No projeto final estas telas foram removidas.

85 85 Figura 46 - Componentes definidos para a tela do domínio Aluno Na figura 46 já havia se definido componentes importantes para a tela inicial do domínio Aluno como o campo para inclusão de um novo aluno, filtro para busca e listagem dos alunos existentes.

86 86 Figura 47 - Tela projetada para cadastro do Aluno A figura 47 mostra como foi projetada a tela para inclusão de um novo aluno. Quando o operador do sistema selecionasse o campo para incluir um novo aluno na tela inicial seria direcionado para esta tela com os formulários de cadastro, um botão para cancelar o cadastro e outro para confimar.

87 87 Figura 48 - Tela projetada para inclusão das Modalidades do Aluno Na figura 48 foi projetada para a inclusão do aluno em uma turma de acordo com a modalidade esportiva escolhida. Após a confirmação do cadastro do aluno obrigatoriamente o operador do sistema seria redirecionado para esta tela para incluir o aluno em uma turma.

88 88 Figura 49 - Resumo do cadastro do Aluno A figura 49 representa o resumo do cadastro do novo aluno, as modalidades em que ele fora incluído e as opções para cancelar o cadastro ou confirmar e gravar as alterações no banco de dados.

89 89 5 PERSISTÊNCIA DE DADOS 5.1 Banco de dados O termo banco de dados é conceituado como um conjunto de dados, gerenciados por meios informatizados ou não. No sistema desenvolvido, a ênfase é a utilização de um banco de dados informatizado, pois possibilita a reorganização dos dados e a produção de informação. O banco de dados normalmente é mantido e acessado por meio de um software conhecido como Sistema Gerenciador de Banco de dados (SGBD). O primeiro SGBD comercial surgiu no final de 1960 com base nos primitivos sistemas de arquivos disponíveis na época, os quais não controlavam o acesso concorrente por vários usuários ou processos. Os SGBD s evoluíram desses sistemas de armazenamento em disco, criando estruturas de dados com o objetivo de armazenar informações. A Figura 50 apresenta um esquema genérico de um Sistema de Banco de Dados em sua interação com seus usuários. Figura 50 - Sistema de Banco de Dados

90 90 Com o tempo, os SGBD s passaram a utilizar diferentes formas de representação (modelos de dados) para descrever a estrutura das informações contidas em seus bancos de dados. O modelo mais utilizado atualmente é o relacional, modelo este que se baseia no princípio em que todos os dados estão guardados em tabelas e relacionados entre si buscando uma normalização (sem redundância) dos dados. Toda a definição teórica é baseada na lógica de predicados e na teoria dos conjuntos. Este conceito foi criado por Edgar Frank Codd (1970). Na verdade, o modelo relacional foi primeiro descrito teoricamente e a partir daí foi desenvolvido. Até este momento os bancos de dados existentes classificavam-se em hierárquicos, modelos de rede e modelos de listas invertidas. A grande vantagem da utilização de um banco de dados relacional é que ele facilita o acesso aos dados, possibilitando que os usuários utilizem uma grande variedade de abordagens no tratamento das informações. Já em um banco de dados hierárquico, os usuários precisam definir as questões do negócio de maneira especifica, iniciando pela raiz do mesmo. No desenvolvimento do sistema de gerenciamento de academia, após avaliação dos requerimentos de uso do SGBD, foi escolhida a utilização do MY-SQL, por se tratar de um SGBD open source e com boas características de robustez, segurança e desempenho. Rego Jr. define que a persistência de dados consiste no armazenamento confiável e coerente das informações em um sistema de banco de dados (2006, pág.4). Já a persistência de objetos é o armazenamento consistente de objetos de uma aplicação orientada a objetos para que estes existam em diferentes execuções de diferentes aplicações. Atualmente, o padrão vigente nas empresas é o relacional, pois o orientado a objetos ainda possui grandes desvantagens. 5.2 Modelagem do banco de dados Modelagem de Dados é a atividade de criar as estruturas de dados e regras de negócio necessárias para suportar uma área de negócios. Representa um conjunto de requerimentos de informações de negócio. Normalmente é dividida em três perspectivas: Modelagem Conceitual, Modelagem Lógica e Modelagem Física. A primeira é usada como representação de alto nível e considera exclusivamente o

91 91 ponto de vista do usuário criador do dado, a segunda já agrega alguns detalhes de implementação e a terceira demonstra como os dados são fisicamente armazenados. Macoratti (2004) diz que não importa se a aplicação é simples, a correta modelagem dos seus dados irá com certeza tornar a aplicação mais robusta e fácil de manter. As funções básicas da modelagem de dados é representar o ambiente observado, documentar e normalizar, fornecer processos de validação e observar os processos de relacionamento entre os objetos. A modelagem de dados contém alguns conceitos que precisam ser bem entendidos Dicionário de dados Segundo Afonso de Souza (2002, p. 43), dicionário de dados consiste numa lista de dados que são pertinentes para o sistema, sem o dicionário de dados o modelo não pode ser considerado completo, pois este descreve entradas, saídas, composição de depósitos de dados e alguns cálculos intermediários. O dicionário de dados tem o objetivo de deixar claro qualquer informação que seja de valia para o processo de compreensão e unificação de conceitos Entidades Uma Entidade pode ser definida como qualquer coisa do mundo real, abstrata ou concreta, na qual se deseja guardar informações. (Tabela, Arquivo, etc..). Exemplos de entidades: aluno, professor, turma, etc Atributos Um atributo é tudo o que se pode relacionar como propriedade da entidade. (coluna, campo, etc.). Exemplos de atributos: Código do Aluno (Entidade Aluno), Nome do Aluno (Entidade Aluno). Então pode-se fazer as seguintes definições: Atributo obrigatório - é aquele que para uma instância de uma entidade ou relacionamento deve possuir um valor. (NOT NULL) Atributo opcional - É aquele que para uma instância da entidade ou relacionamento pode possuir um valor. (NULL) Podem ser classificados como:

92 92 Atributo Identificador - (#) - Atributo capaz de identificar exclusivamente cada ocorrência de uma entidade. Também conhecido como chave Primária ou Primary Key (PK). Ex: Código do Cliente, Código do Produto, etc. (O símbolo # é usado para representar a chave primária em algumas notações) Chave Candidata - Atributo ou grupamento de atributos que têm a propriedade de identificar unicamente uma ocorrência da entidade. Pode vir a ser uma chave Primária. A chave candidata que não é chave primária também se chama chave Alternativa. Características de uma Chave Primária: NÂO PODE haver duas ocorrências de uma mesma entidade com o mesmo conteúdo na Chave Primária; A chave primária não pode ser composta por atributo opcional, ou seja, atributo que aceite nulo; Os atributos identificadores devem ser o conjunto mínimo que pode identificar cada instância de uma entidade; Não devem ser usadas chaves externas. (Atributos sobre os quais você não tem controle. Ex: CPF); Cada atributo identificador da chave deve possui um tamanho reduzido; Não deve conter informação volátil. Ao criar modelos geralmente temos diversas entidades cada uma com diversos atributos que podem se relacionar entre si. Vamos definir como podem ser estes relacionamentos Mapeamento Objeto Relacional - MOR Mapeamento Objeto relacional é uma técnica de desenvolvimento utilizada para reduzir a impedância da programação orientada aos objetos utilizando bancos de dados relacionais. As tabelas do banco de dados são representadas através de classes e os registros de cada tabela são representados como instâncias das classes correspondentes.

93 Relacionamentos Um relacionamento pode ser entendido como uma associação entre instâncias de Entidades devido a regras de negócio. Normalmente ocorre entre instâncias de duas ou mais Entidades, podendo ocorrer entre instâncias da mesma Entidade (auto-relacionamento). Por que o relacionamento é necessário? Quando existem várias possibilidades de relacionamento entre o par das entidades e se deseja representar apenas um Quando ocorrer mais de um relacionamento entre o par de entidades Para evitar ambiguidade Quando houver auto-relacionamento Para definir o número de ocorrências de uma entidade usamos o conceito de Cardinalidade. A Cardinalidade indica quantas ocorrências de uma Entidade participam no mínimo e no máximo do relacionamento. Cardinalidade Mínima - define se o relacionamento entre duas entidades é obrigatório ou não. Cardinalidade Máxima - define a quantidade máxima de ocorrências da Entidade que pode participar do Relacionamento. Deve ser maior que zero. Agora vamos definir os tipos de cardinalidade quanto ao relacionamento: Cardinalidade UM para UM: No relacionamento Um para Um temos o lado opcional e o lado obrigatório. A chave primária se desloca em direção ao lado opcional. Cardinalidade UM para N: A cardinalidade UM para N leva a chave primária do lado UM para o lado N. Neste caso o atributo recebe o nome de chave estrangeira ou Foreign Key ( FK ). Chave Estrangeira é a chave primária de uma entidade que aparece em outra entidade em virtude do relacionamento. Cardinalidade N para N: A cardinalidade N para N leva para o modelo lógico a necessidade de definição de mais um entidade. Chamamos isto de ASSOCIATIVA.

94 Padrão de persistência DAO (Data Access Object) De acordo com Santos (p. 5) DAO é um dos padrões de projeto utilizados para o mapeamento objeto relacional, assim como o Data Mapper ou o Active Report, todos com a função de persistir objetos em bancos de dados. O DAO permite abstrair e encapsular todo o acesso a uma fonte de persistência e gerencia automaticamente a conexão com a fonte de dados para obter e armazenar os dados, ainda garante a independência do mecanismo de persistência, sendo independente do tipo de repositório de dados. Na figura 51 é apresentado o diagrama de sequencia de um objeto DAO, exemplificando toda a sequencia de acontecimentos na busca e na gravação de um objeto persistente, sendo o Bussiness Object contém a lógica de negócio e requer acesso à origem dos dados para obter ou armazenar dados, o DataAccessObject permite o acesso transparente à origem dos dados, é a classe de mapeamento, o DataSource representa a implementação da origem dos dados e o ValueObject representa um objeto de dados utilizado para transporte dos dados entre as camadas do sistema. Figura 51 - Diagrama de sequência O DAO ainda oferece uma interface comum de acesso a dados e oculta as características de uma implementação específica, fornece métodos genéricos

95 95 para gerenciar informação e para concentrar operações mais comuns (simplificar a interface de acesso). Ainda define uma interface que pode ser implementada para cada nova fonte de dados usada, viabilizando a substituição de uma implementação por outra. DAO s não mantêm estado (stateless), nem cache de dados (lightweight), além de evitar problemas de Threading e Concorrência. A figura 52 mostra a estrutura do DAO. Figura 52 Estrutura do DAO Separação entre classe de domínio e classe de mapeamento, exemplo na figura 53. Figura 53 - Dominio e mapeamento

96 96 Segundo Galhardo (2007, p.21) o DAO tem as como vantagens: Transparência quanto ao mecanismo de persistência, facilita migração para outras implementações, não tem dependência entre classe de domínio e classe de negócio, reduz complexidade do código nos objetos de negócio e tem dependência da fonte de dados em um único ponto, e como desvantagem a escrita de código de mapeamento básico (CRUD Create/Retrieve/Update/Delete). A seguir um exemplo do domínio, escrito em Java,na figura 54. package br.com.sga.site.entidades; // Generated 21/05/ :04:18 import java.util.collection; import java.util.date; import java.util.hashset; import java.util.set; import javax.persistence.column; import javax.persistence.entity; import javax.persistence.fetchtype; import javax.persistence.generatedvalue; import static javax.persistence.generationtype.identity; import javax.persistence.id; import javax.persistence.onetomany; import javax.persistence.table; import javax.persistence.temporal; import javax.persistence.temporaltype; /** * TbCliente generated by = "tb_cliente", catalog = "dbgolfinho") public class Cliente implements java.io.serializable { private Integer cicodigo; private String cinome; private String ciendereco; private String cicpfcnpj; private String cirgie; private String citelefone; private Date cidatainclusao; private String cistatus; private Set tbalunos = new HashSet(0); public Cliente() { public Cliente(String cinome, String ciendereco, String cicpfcnpj, String cirgie, String citelefone, Date cidatainclusao, String cistatus) { this.cinome = cinome; this.ciendereco = ciendereco; this.cicpfcnpj = cicpfcnpj; this.cirgie = cirgie; this.citelefone = citelefone; this.cidatainclusao = cidatainclusao; this.cistatus = = "ci_codigo", unique = true, nullable = false) public Integer getcicodigo() { return this.cicodigo;

97 97 public void setcicodigo(integer cicodigo) { this.cicodigo = = "ci_nome", nullable = false, length = 50) public String getcinome() { return this.cinome; public void setcinome(string cinome) { this.cinome = = "ci_endereco", nullable = false, length = 60) public String getciendereco() { return this.ciendereco; public void setciendereco(string ciendereco) { this.ciendereco = = "ci_cpfcnpj", nullable = false, length = 14) public String getcicpfcnpj() { return this.cicpfcnpj; public void setcicpfcnpj(string cicpfcnpj) { this.cicpfcnpj = = "ci_rgie", nullable = false, length = 20) public String getcirgie() { return this.cirgie; public void setcirgie(string cirgie) { this.cirgie = = "ci_telefone", nullable = false, length = 25) public String getcitelefone() { return this.citelefone; public void setcitelefone(string citelefone) { this.citelefone = "ci_datainclusao", nullable = false, length = 10) public Date getcidatainclusao() { return this.cidatainclusao; public void setcidatainclusao(date cidatainclusao) { this.cidatainclusao = = "ci_status", nullable = false, length = 1) public String getcistatus() { return this.cistatus; public void setcistatus(string cistatus) { this.cistatus = fetch = FetchType.LAZY, public Set gettbalunos() { return this.tbalunos; public void settbalunos(set tbalunos) { this.tbalunos = tbalunos;

98 = CascadeType.ALL, fetch = FetchType.LAZY, mappedby = "Cliente") public Set gettbrecebers() { return this.tbrecebers; public void settbrecebers(set tbrecebers) { this.tbrecebers = = CascadeType.ALL, fetch = FetchType.LAZY, mappedby = "Cliente") public Set gettbcaixas() { return this.tbcaixas; public void settbcaixas(set tbcaixas) { this.tbcaixas = tbcaixas; Figura 54 Cliente.java Na figura 55 é apresentado um exemplo genérico de mapeamento DAO implementado em Java. public class DAOCliente { public void create(cliente c) { Session s = Database.getInstance().getSession(); Transaction tx = s.begintransaction(); session.save(c); tx.commit(); s.close(); public void remove(cliente c) { Session s = Database.getInstance().getSession(); Transaction tx = s.begintransaction(); session.delete(c); tx.commit(); s.close(); public void update(cliente c) { Session s = Database.getInstance().getSession(); Transaction tx = s.begintransaction(); session.saveorupdate(c); tx.commit(); s.close(); //... //Busca por chave primária public Cliente findbyprimarykey(int id) { Session s = Database.getInstance().getSession(); Cliente c = session.get(cliente.class,id); s.close(); return c; // Busca por nome Uso do like public Collection findlikebynome(string nome) { Session s = Database.getInstance().getSession(); Criteria c = s.createcriteria(cliente.class); c.add(expression.like( nome, nome + % )); return c.list(); Figura 55 ClienteDAO.Java

99 Diagrama de Entidade e Relacionamento Diagrama de Entidade e Relacionamento (DER) é um modelo diagramático que descreve o modelo de dados de um sistema com alto nível de abstração. Ele é a principal representação do Modelo de Entidades e Relacionamentos. Sua maior aplicação é para visualizar o relacionamento entre tabelas de um banco de dados, no qual as relações são construídas através da associação de um ou mais atributos destas tabelas. Na figura 56 é mostrado o diagrama de entidade e relacionamento utilizado no desenvolvimento do Sistema de Gerenciamento de Academias. A figura 56 permite uma visão completa do banco de dados criado para o sistema. Os tipos de entidade tais como TB_ALUNO, TB_PROFESSOR e TB_TURMA são mostrados em retângulos, tipos de relacionamento são representados por setas ou linhas, ligando as entidades, definindo a cardinalidade e a chave de ligação entre elas. Os Atributos estão posicionados dentro das entidades, por exemplo, na entidade TB_MODALIDADE existem os seguintes atributos: mo_codigo, mo_nome, mo_status e mo_valor, com a Primary Key definida em mo_codigo.

100 100 Figura 56 - DER - Diagrama de Entidade e Relacionamento

101 Framework Hibernate Para a implementação da persistência de dados, foi utilizado o framework Hibernate, que também é open source. Este framework, escrito em Java para mapeamento objeto relacional, auxilia na persistência, facilitando o mapeamento de atributos/classe e permitindo que dados sejam persistidos como se fossem objetos. O fato de se trabalhar apenas com objetos e não mais com sintaxes SQL, torna o trabalho do programador muito mais simples, pois até mesmo relacionamentos complexos como os NxN podem ser solucionados de maneira simples. A arquitetura do hibernate é formada basicamente por um conjunto de interfaces, a figura 57 apresenta as interfaces mais importantes nas camadas de negócio e persistência. A camada de negócio aparece acima da camada de persistência por atuar como um cliente da camada de persistência. As interfaces são classificadas como: Interface responsável por executar operações de criação, deleção, consulta e atualização no banco de dados: Session, Transaction e Query; Interface utilizada pela aplicação para configurar o Hibernate: Configuration; Interfaces responsáveis por realizar a interação entre os eventos do Hibernate e a aplicação: Interceptor, Lifecycle e ValidTable; Interfaces que permitem a extensão das funcionalidades de e JDBC. mapeamento do Hibernate: UserType, CompositeUserType e IdentifierGenerator. O Hibernate também interage com API s já existentes no Java: JTA, JNDI

102 102 Figura 57 Arquitetura do Hibernate (FERNANDES, 2007) De todas as interfaces apresentadas, as principais são: Session, SessionFactory, Transaction, Query e Configuration. Os sub-tópicos seguintes apresentam uma descrição mais detalhada sobre elas. Session (org.hibernate.session) O objeto Session é aquele que possibilita a comunica ção entre a aplicação e a persistência, através de uma conexão JDBC. É um objeto leve de ser criado, não deve ter tempo de vida por toda a aplicação e não é threadsafe. Um objeto Session possui um cache local de objetos recuperados na sessão. Com ele é possível criar, remover, atualizar e recuperar objetos persistentes. SessionFactory (org.hibernate.sessionfactory) O objeto SessionFactory é aquele que mantém o mapeamento objeto