REQUISITOS FUNCIONAIS - INF-Unioeste

Unioeste – Universidade Estadual do Oeste doParanáCENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICASColegiado de Ciências da ComputaçãoCurso de Bacharelado em Ciências da ComputaçãoEspecificação de Requisitos e ModelagemSistema Academia SportLifeHudson João MagalhãesLucas da Silva GrandoCascavel2010

2SUMÁRIO1 MOTIVAÇÃO…………………………………………………………………………. 32 PROBLEMA DA EMPRESA………………………………………………………… 33 CRONOGRAMA……………………………………………………………………… 34 METODOLOGIA ESCOLHIDA................................................................................. 45 REQUISITOS FUNCIONAIS....................................................................................... 56 REQUISITOS NÃO FUNCIONAIS ............................................................................ 76.1 REQUISITOS DE PROCESSO .................................................................................... 76.2 REQUISITOS DO PRODUTO ..................................................................................... 76.3 O GRAFO SIG……………………………………………………………………….. 87 MODELAGEM ORGANIZACIONAL i*................................................................... 97.1 MODELO DE DEPENDÊNCIAS ESTRATÉGICAS.................................................. 107.2 MODELO DE RAZÕES ESTRATÉGICAS................................................................. 118 CASOS DE USO ............................................................................................................ 148.1 REPRESENTAÇÃO DOS CASOS DE USO............................................................... 148.2 DESCRIÇÃO DOS CASOS DE USO.......................................................................... 149 DIAGRAMAS DE CLASSES ....................................................................................... 2210 DIAGRAMAS DE SEQUECIA 2811 DESIGN PATTERN 3012 ARQUITETURA 3213 TESTES 34CONCLUSÃO.................................................................................................................... 45Apêndice A – Coleta de Informações............................................................................... 46

31 INTRODUÇÃO E MOTIVAÇÃOBusca por conhecimento da equipe, no desenvolvimento do aprendizado do uso daengenharia de software para o desenvolvimento de sistemas em geral, atender o cliente quenecessita de um sistema organizacional para controle do caixa, e cadastro dos dados dos alunosproduzindo um sistema de qualidade que gerencie as tarefas de uma academia.O objetivo é diminuir o tempo gasto nos arquivamentos dos dados dos alunos,manutenção do estoque dos produtos e agendar todas das tarefas diárias da academia. Com estesistema poderá resultar na economia de tempo e esforço, gerando também mais segurança erestrição aos dados.abaixo:A empresa a qual o sistema será implantado é a academia Sport Life. Conforme os dadosAcademia Sport LifeRua Visconde do Rio Branco, 3402Vila Tolentino - Cascavel - PRTelefone: +55 (45) 3038-98002 PROBLEMA DA EMPRESAA empresa ainda não possui qualquer tipo de sistema para o controle das atividades,onde por esse motivo há uma perca de tempo preciosa para organizar-se, além de que essecontrole estar sendo feito em arquivos de papel, ocorre frequentemente perda de informação ouaté erro humano na hora de organizar as informações, gerando assim inúmeros transtornos. Estecontrole irá gerenciar as atividades em geral da academia tais como as contas a pagar no dia, e asatividades agendadas, tais como avaliações físicas e aulas pessoais.Há também a necessidade de armazenar todos os dados dos alunos, como as medidas,exames físicos e médicos, mas também principalmente controlar o vencimento da mensalidade.O Sistema proposto irá resolver essas situações para o proprietário, agilizando eorganizando o dia a dia da empresa, além de evita erros graves. E trazendo mais algumasfuncionalidades ao sistema.3 CRONOGRAMA

4DescriçãoPrevisão(Semanas)Datainício1 Treinamento eObtenção dados1 02/072 Telas Iniciais 2 16/073 Cadastro Aluno 1 23/074 Utilização Webcam 1 30/075 Login/ Criptografia 1 06/086 Funcionários/Salários 1 13/087 Usuários 1 20/088 Avaliação 1 27/089 Avaliação + Anaminse 1 04/0910 Modalidades 1 11/0911 Integridade Do BancoDe Dados1 18/0912 Back UP 1 25/0913 Agenda Contatos 1 02/1014 Agenda Tarefas 1 09/1015 Controle Alunos 1 16/1016 Controle Do Acesso 1 23/1017 Abertura E Restriçãodas Mensalidades1 30/1018 Caixa 1 14/1119 Revisão e Testes 2 21/114 METODOLOGIA ESCOLHIDAComo a exigência do mercado de softwares hoje em dia é muito forte, não só em questão

5a qualidade mais também ao tempo de entrega, além da complexidade do sistema que irá serdesenvolvido, prevendo mudanças das especificações durante a produção do projeto e a gestãosendo indispensável para assegurar a qualidade do produto, utilizaremos para o desenvolvimentodo sistema será a metodologia XP.Como a metodologia XP, é uma metodologia para equipes pequenas e médias e que irãodesenvolver software com requisitos vagos e em constante mudança, resolvemos adotar estametodologia. Para isso a estratégia de constante acompanhamento e realização de váriospequenos ajustes durante o desenvolvimento de software.Os quatro valores fundamentais da metodologia XP são: comunicação, simplicidade,feedback e coragem. A partir desses valores, possui como princípios básicos: feedback rápido,presumir simplicidade, mudanças incrementais, abraçar mudanças e trabalho de qualidade.Dentre as variáveis de controle em projetos (custo, tempo, qualidade e escopo), há umfoco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades querepresentem maior valor possível para o negócio. Desta forma, caso seja necessário à diminuiçãode escopo, as funcionalidades menos valiosas serão adiadas ou canceladas.A XP incentiva o controle da qualidade como variável do projeto, pois o pequeno ganhode curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou atéimpedimentos) a médio e longo prazo.5 REQUISITOS FUNCIONAISOs requisitos funcionais descrevem os serviços que o sistema deve oferecer e suas"funções" ao fim do seu desenvolvimento, como devem se comportar a certas entradas, as maisvariadas situações. Os requisitos funcionais que serão apresentados foram estudados e analisadosjuntamente ao filho do dono da empresa. Os seguintes requisitos estão apresentados abaixo.[RF - 01] Cadastrar ProdutoO sistema deverá permitir cadastrar novos produtos com todos os seus atributos. Ocadastro não poderá ser realizado no caso de já existir no estoque um produto com o mesmocódigo de barra ou nome.

6[RF - 02] Remover ProdutoO sistema deverá permitir a exclusão de produtos por nome ou código de barra,viausuários autorizados ( logados ).[RF - 03] Alterar ProdutoO sistema deverá permitir a alteração de um produto já existente no banco de dados.[RF - 04] Consultar ProdutoO sistema deverá permitir a consulta de um produto já existente no banco de dados.[RF – 05] Cadastrar AlunoO sistema deverá cadastrar um Aluno quando necessário e seus dados no banco dedados. Tais com as medidas, vencimento da mensalidade.[RF – 06] Excluir AlunoO sistema deverá possibilitar a exclusão pelo nome do aluno, atualizandoautomaticamente no banco de dados.[RF – 07] Pesquisar AlunoO sistema deverá possibilitar a pesquisa de um aluno já armazenado no banco de dadosdo sistema e disponibilizar a informação para o usuário. Tais com as medidas, vencimento damensalidade e a foto.[RF – 08 ] Alterar AlunoO Sistema deverá possibilitar ao usuário modificações/alterações nas informações jáarmazenadas no sistema.[RF – 09 ] Cadastrar UsuárioO Sistema deverá possibilitar o cadastro de novos usuários para o sistema, cada um comum login e senha distinta.

7[RF – 10 ] Remover UsuárioO Sistema deverá possibilitar a remoção de usuários do sistema, desabilitando-os dequalquer acesso ao sistema.[RF – 11 ] Alterar UsuárioO Sistema deverá possibilitar as alterações na conta de usuários no sistema, modificandosenha ou login se necessário.[RF – 12 ] Pesquisar UsuárioO Sistema deverá possibilitar uma pesquisa sobre as contas de usuários do sistemaexistentes e disponibilizar essas informações.[RF - 13 ] Logar no SistemaTodas as funcionalidades do sistema são acessíveis aos usuários de acordo com seu nívelde privilégio no sistema. Isto é realizado através de um sistema de Login/Senha.[RF - 14 ] Realizar VendaOs funcionários serão permitidos realizar uma venda, o sistema devera possibilitar avenda através do usuário logado.[RF - 15 ] Realizar Avaliação FísicaOs usuários do sistema poderão armazenar no banco de dados, as informações do alunoda academia referente a avaliação física. Como as medidas, peso, altura, etc...[RF - 16 ] Agendar Avaliação FísicaO sistema irá trabalhar como uma agenda de horários, onde o usuário passara asinformações para realizar um agendamento para avaliar o aluno.[RF – 17 ] Registrar Movimentação CaixaO sistema deverá registrar toda movimentação diária do caixa. Como entrada e saída decapita, venda de produto, pagamento de mensalidade.

8[RF - 18] Lembrar Tarefas DiáriasO sistema deverá lembrar o usuário de alguma tarefa agendada para a data atual. Essatarefa pode ser uma conta a pagar, ou qualquer compromisso armazenado.6 REQUISITOS NÃO FUNCIONAIS6.1 REQUISITOS DE PROCESSO[RNF /PROC -01]O sistema deverá ser implementado em Java de modo a ser compatível com o sistemaoperacional Windows.[RNF /PROC -02]código fonte.Será criado um documento contendo um diagrama de classes e informações sobre o[RNF /PROC- 03]Será criado um cronograma detalhado para o processo de desenvolvimento no qualconstem: as atividades a serem desenvolvidas e em que período e com que recursos humanos efísicos serão desenvolvidos o sistema.6.2 REQUISITOS DO PRODUTO* SEGURANÇA[RNF /SEG - 04]Os usuários terão que ter permissão para utilizar algumas funcionalidades do sistema,deverá utilizar do login e senha para manipular estoque dos produtos, e gerencia dosfuncionários.* USABILIDADE

9[RNF /USAB - 05]A interface do sistema será agradável, objetiva e trivial ao usuário. Suas funcionalidadese informações deveram estar bem visíveis e disponíveis.[RNF /USAB - 06]Haverá mensagens de erro do sistema que deverão ser precisas e informativas,apontando sua origem.[RNF /USAB - 07]O Sistema disponibilizará ao usuário um menu "Ajuda", onde trará de forma objetivainformações sobre o sistema e suas demais funções e possíveis duvidas.* DESEMPENHO E CUSTO[RNF /DES- 08]O Sistema usará um banco de dados orientado a objeto, assim garantindo a segurançados dados, mas também agilizando desempenho do sistema. Este banco de dados será o DB4O,por ser um software livre, haverá uma considerável diminuição dos custos.[RNF /DES - 09]Para um melhor desempenho do sistema é recomendada uma máquina razoável. Com osseguintes requisitos mínimos.Processador 1200MHz, 512Mb de Memória, espaço mínimo no HD de 1GB.6.3 O GRAFO SIG (SOFTGOAL INTERDEPENDENCY GRAPHS)Este permite uma visão vertical desde a estratégia de alto nível até o detalhe. Cujoprincipal objetivo é demonstrar que os requisitos não-funcionais reorganizados proporcionamuma visão mais realista do sistema. Através dele podemos verificar o que deve seroperacionalizado para atender determinado requisito e como ele contribui (positivo ounegativamente) para os demais.

Figura 1 – O grafo SIG10

117 MODELAGEM ORGANIZACIONAL i*7.1 MODELO DE DEPENDÊNCIAS ESTRATÉGICASA partir de uma visão macro do modelo nota-se que é composto de seis atores, sendoque a utilização direta do sistema é feita apenas pelos autores gerente e funcionário, essainteração é especificada pelas dependências destes com o ator sistema.Figura 2: Modelo de Dependências Estratégicas (SD)

12O ator funcionário interage com o ator sistema, para isso ele necessita logar no sistema,sendo necessária entrada de usuário e senha. Após logado no sistema ele tem permissão derealizar algumas tarefas: gerência produtos e agendamento, vendas. Todas estas operações paranão impor dificuldade ao usuário na utilização do sistema são necessário que ele tenha uma boausabilidade. Por haver grande fluxo de dados entre os atores, sendo que o sistema tem umadependência de obter dados junto ao funcionário, é necessário que esta comunicação seja feita deforma segura e ágil.O ator gerente pode ser considerado um funcionário especializado, sendo assim elepoderá executar todas as operações de um funcionário “comum”, para isto ele faz uso de umlogin/senha diferenciado. Esta especialização é denotada com a ligação ISA entre os atores.Além das operações “herdadas” do ator funcionário, ele se relaciona com o ator sistemaao fazer uso das funções: gerenciar funcionário, gerenciar caixa, estas sendo essenciais aofuncionamento da organização.Para que o sistema seja rápido, com dados íntegros e confiáveis ele dependera daqualidade do sistema gerenciador de banco de dados.7.2 MODELO DE RAZÕES ESTRATÉGICASO modelo SR (figura 3), complementa o modelo SD de forma a compreender e modelarde maneira mais detalhada as razões associadas com cada ator e suas dependências.Percebem-se pela expansão do ator sistema, a tarefa logar é necessário que usuárioforneça um login e senha. Já as operações com produtos, agendamentos e funcionários têm asmesmas subdivisões, que são: cadastrar, modificar, remover e consultar.

Figura 3: Modelo de Razões Estratégica (SR)13

148 CASOS DE USO8.1 REPRESENTAÇÃO DOS CASOS DE USOFigura 4, Casos de Uso.8.1 DESCRIÇÃO DOS CASOS DE USO[Caso de uso 001]: Controlar MensalidadeDescrição: O Sistema deverá fazer o controle de todas as mensalidades dos alunos.Atores envolvidos: Usuário do sistema e aluno.Pré-condição: Apenas usuários com acesso ao sistema poderão controlar as mensalidades.Nenhuma mensalidade vencida poderá ser alterada ou excluída sem autorização do gerente.

15Pós-condição: Redireciona o Sistema a operação desejada.Cenário Principal de Sucesso:1. O caso de uso é iniciado quando o usuário entra com o login e senha.2. O usuário escolhe a opção controle de mensalidades.3. O sistema levará o usuário a uma tela onde encontrará todas as mensalidades ativas. Emostrará o status de cada. “Ok”, “Vencida”, “Aberta”.4. O usuário seleciona o aluno na lista. E caso o usuário escolha PAGAMENTO, osistema remete para tela de pagamento da mensalidade. Cenário Secundário4.1. Caso o usuário escolha a opção Alterar Mensalidade no passo 3, o sistemaredireciona-o ao Caso de uso Alterar Mensalidade .4.2. Caso o usuário escolha a opção Excluir Mensalidade no passo dois, o sistemaremete ao Caso de uso Excluir Mensalidade .[Caso de uso 002]: Alterar MensalidadeDescrição: O Sistema deverá alterar dados da mensalidade do aluno.Atores envolvidos: Usuários com acesso privilegiado. Gerentes.Pré-condição Usuário deve estar logado no sistema e ter realizado o Caso de Uso ControlarMensalidade.Cenário Principal de Sucesso:1. O Sistema apresenta os dados pessoais sobre o aluno a qual a mensalidade foiselecionada.2. O usuário altera os dados pretendidos.3. O sistema válida os dados. E mostra mensagem de sucesso.Cenário Secundário:3.1. Caso ocorra algum erro na validação dos dados, será exibido mensagem de erro.[Caso de uso 003]: Excluir MensalidadeDescrição: O Sistema deverá excluir a mensalidade do aluno.Atores envolvidos: Usuários com acesso privilegiado. Gerentes.

16Pré-condição Usuário deve estar logado no sistema e ter realizado o Caso de Uso ControlarMensalidade.Cenário Principal1. O Sistema apresentara uma mensagem de Confirmação.2. O usuário confirma a mensagem.3. O Sistema excluirá a mensalidade e todas as ocorrências do mesmo no sistema, então odesconectará do sistema.Cenário Secundário2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso GerenciarMensalidade.[Caso de uso 004] Agendar AvaliaçãoDescrição: O Sistema deverá mostrar quais as datas e horários disponíveis para agendamento daavaliação do aluno.Atores envolvidos: Usuário do sistema.Pré-condição: O usuário devera estar logado no sistema. E o horário solicitado estar vago.Pós-Condições: Retorno da condição do agendamento, agendamento realizado com sucesso ouerro.Cenário Principal de Sucesso:1. O sistema apresenta todas as datas e horários vagos.2. O usuário deverá selecionar o horário para o possível agendamento.3. O usuário submete os dados do aluno para validação.4. O sistema valida os dados e retorna mensagem de sucesso.Cenário Secundário:4.1. O sistema aborta a validade dos dados e retorna mensagem de erro, e volta à tela dehorários.[Caso de uso 005] Agendar TarefaDescrição: O Sistema deverá agendar qualquer tarefa ou compromisso solicitado pelo usuário.

17Atores envolvidos: Usuário do sistema.Pré-condição: O usuário devera estar logado no sistema. E o horário solicitado estar vago.Pós-Condições: Retorno da condição do agendamento, agendamento realizado com sucesso ouerro.Cenário Principal de Sucesso:1. O sistema apresenta todas as datas e horários vagos.2. O usuário deverá selecionar o horário para o possível agendamento.3. O usuário submete os dados necessários para agendamento.4. O sistema valida os dados e retorna mensagem de sucesso.Cenário Secundário:4.1. O sistema aborta a validade dos dados e retorna mensagem de erro, e volta à tela decompromissos.[Caso de uso 006]: Controle CaixaDescrição: O Sistema deverá fazer o controle de todas as movimentações diárias do caixa.Atores envolvidos: Usuário do sistema.Pré-condição: Apenas usuários com acesso ao sistema poderão controlar a movimentação docaixa. Todas as movimentações são registradas, para relatar ao gerente.Pós-condição: Redireciona o Sistema a operação desejada.Cenário Principal de Sucesso:1. O caso de uso é iniciado quando o usuário entra com o login e senha.2. O usuário escolhe a opção caixa.3. O sistema levará o usuário a uma tela onde aparecerão todas as movimentaçõesrealizadas até o momento. Entrada e saída do caixa. Podendo escolher algumas opções.4. O usuário seleciona a opção fechar caixa. Cenário Secundário4.1. Caso o usuário escolha a opção saída no passo 4, o sistema redireciona-o ao Caso deuso Saída do Caixa .4.2. Caso o usuário escolha a opção Excluir Mensalidade no passo dois, o sistemaremete ao Caso de uso Entrada do Caixa .

18[Caso de uso 007] Saída do CaixaDescrição: O Sistema deverá registrar e atualizar a retirada de capital do caixa.Atores envolvidos: Usuários do sistema.Pré-condição Usuário deve estar logado no sistema e ter realizado o Caso de Uso Controle CaixaCenário Principal1. O Sistema apresentara uma janela com a descrição e valor da retirada.2. O usuário confirma os dados.3. O Sistema validará a retirada, e a movimentação do caixa será registrada. O sistemaexibirá uma mensagem de sucesso.Cenário Secundário2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso ControleCaixa.[Caso de uso 008] Entrada do CaixaDescrição: O Sistema deverá registrar e atualizar a entrada de capital do caixa.Atores envolvidos: Usuários do sistema.Pré-condição Usuário deve estar logado no sistema e ter realizado o Caso de Uso Controle CaixaCenário Principal1. O Sistema apresentara uma janela com a descrição, valor da entrada e o tipo(mensalidade, venda de produto ou entrada capital).2. O usuário confirma os dados.3. O Sistema validará a entrada, e a movimentação do caixa será registrada. O sistemaexibirá uma mensagem de sucesso.Cenário Secundário2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso ControleCaixa.[Caso de uso 009]: Contas a Pagar

19Descrição: O Sistema deverá exibir todas as contas a serem pagas em data determinada.Atores envolvidos: Usuário do Sistema.Pré-condição Usuário deve estar logado no sistema. E o caixa da empresa possuir capital.Cenário Principal de Sucesso:1. O caso de uso é iniciado quando o usuário solicita o lembrete das contas do dia.2. O usuário poderá visualizar em uma janela todas as contas do dia.3. O usuário pode selecionar a conta a ser paga, registrando a retirada do caixa, Casode Uso Saída Caixa Cenário Secundário:3.1 O sistema não valida a retirada do caixa. Mostrando mensagem de erro, ou falta decapital.[Caso de uso 010]: Controle AcessoDescrição: O Sistema deverá controlar a entrada de todas as pessoas na empresa.Atores envolvidos: Gerente, funcionário, alunoPré-condição: O sistema deverá estar logado e funcionando. Os atores envolvidos deverão estarcadastrados no Banco de Dados.Cenário Principal de Sucesso:1. O ator envolvido submete sua impressão biométrica ao leitor.2. O sistema deverá pesquisar as informações para liberação.3. O sistema valida os dados e entrada permitida.Cenário Secundário:3.1. O sistema retorna erro. Não encontrou registros biométricos solicitados. Ou aluno bloqueadodevido a falta de pagamento da mensalidade.[Caso de uso 011] Fechar CaixaDescrição: O Sistema deverá finalizar o caixa diário, mostrando todas as movimentações e saldofinal.

20Atores envolvidos: GerentePré-condição: O sistema deve estar logado com usuário com privilégios de gerente. O caixadeverá estar aberto no dia e houver alguma movimentação.Cenário Principal de Sucesso:Cenário Principal1. O Sistema apresentara uma janela com a descrição de todos os registros do caixa.2. O usuário confirma os dados. E solicita fechamento.3. O Sistema validará a entrada, e a movimentação do caixa será registrada. O sistemaexibirá uma mensagem de sucesso.Cenário Secundário2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso ControleCaixa.[Caso de uso 012]: Logar no SistemaDescrição: O usuário devera entrar com seus dados: login e senha. O Sistema deverá permitiracesso ao conteúdo do software se somente se os dados estiverem corretos.Atores envolvidos: Gerente e Funcionário.Pré-condição O usuário já devera possuir seu cadastro no sistema.Cenário Principal de Sucesso:1. O caso de uso é iniciado com a tela de login e senha.2. O usuário devera entrar com seus dados.3. O sistema busca no banco de dados se os dados estão corretos4. O sistema será iniciado, liberando os privilégios de acordo com o privilegio dousuário. Exibe mensagem de sucesso.Cenário Secundário:4.1 O sistema retorna a mensagem de erro, ou login inválido.[Caso de uso 013]: Realizar VendaDescrição: O usuário entrara com alguns dados do aluno em seguida os códigos e quantidades

21dos produtos da venda.Atores envolvidos: Gerente e FuncionárioPré-condição O usuário já devera estar logado no sistema.Cenário Principal de Sucesso:1. O caso de uso é iniciado com a solicitação de venda de produto.2. O usuário devera entrar com os dados do cliente.3. O usuário da inicio a venda, passando os códigos dos produtos e a quantidade.4. O sistema retorna uma espécie de nota fiscal, com o valor total da venda.[Caso de uso 014]: Gerar RelatórioDescrição: O usuário solicita ao sistema um relatório do dia.Atores envolvidos: Usuário do sistemaPré-condição O usuário já devera estar logado no sistema.Cenário Principal de Sucesso:1. O caso de uso é iniciado com a solicitação da geração do relatório.2. O usuário aceitar a mensagem de confirmação.3. O sistema gerará um documento com todos os registros do caixa, e a inscrição denovos alunos.4. O sistema retorna esse documento para impressão.Cenário Secundário:2.1 Caso não confirme a mensagem de geração do relatório, o sistema será redirecionadoa tela inicial.9 DIAGRAMAS DE CLASSESUm diagrama de classes é uma representação da estrutura e relações das classes queservem de modelo para objetos. É uma modelagem muito útil para o sistema, define todas asclasses que o sistema necessita possuir e é a base para a construção dos diagramas decomunicação e estados.Logo abaixo é apresentado o diagrama de classes do sistema, e uma breve descrição decada classe segue abaixo.

22Figura 5 – Representação Diagrama de ClassesPRODUTOEsta classe representa os produtos estocados na empresa e cadastrados no sistema. Seusatributos são id, Descrição e Quantidade, junto com seus custos, Preço de venda e preço decompra, que serão necessários para o cadastro do produto no sistema e futura utilização dosdados, seus métodos são set e get que serão utilizados para a inserção e alteração dos atributos,possibilitando também que outras classes chamem esses métodos se necessários.ProdutoDescriçãoClasse responsável por encapsular os atributos do objetoProduto e pela criação das funções de manipulação das mesmas(camada modelo).Atributosnome: Stringdescricao: StringResponsável pelo armazenamento de informação referente aonome do produto.Responsável pelo armazenamento de informação referente adescrição do produto

23medida: Stringfabricante: StringId: intquantidade: doublepreco: doubleestoquemin: doubleOperaçõesgetNome(): StringsetNome(n: string):voidgetID(): intgetDescricao():StringsetDescricao(d:String):voidgetFabricante():StringsetFabricante(r:String): voidgetQuantidade():doublesetQuantidade(q:double): voidgetEstoqueMIN():doublesetEstoqueMIN(q:double): voidgetValor(): doublesetValor(q: double):voidgetUnidadeMedida():StringsetUnidadeMedida(q:String): voidResponsável pelo armazenamento de informação referente aotipo de medida do produto.Responsável pelo armazenamento de informação referente aofabricante do produto.Responsável pelo armazenamento de informação referente aonumero de identificação do produto.Responsável pelo armazenamento de informação referente aquantidade do produto.Responsável pelo armazenamento de informação referente aopreço do produto.Responsável pelo armazenamento de informação referente aquantidade mínima permitida no estoque.Retorna o valor do variável referente ao nome do produto.Seta o nome (altera o valor da variável referente ao nome doProduto).Retorna o valor da variável referente ao identificador doProduto.Retorna o valor da variável referente a descrição do produtoSeta a descricao (altera o valor da variável referente a descriçãodo produto).Retorna o valor da variável referente ao fabricante do produtoSeta o fabricante (altera o valor da variável referente aofabricante do produto).Retorna o valor da variável referente a quantidade do produtoSeta a quantidade (altera o valor da variável referente aquantidade do produto).Retorna o valor da variável referente a quantidade mínina deproduto permitida em estoque.Seta a quantidade (altera o valor da variável referente aquantidade do produto).Retorna o valor da variável referente ao valor do produto.Seta o preco (altera o valor da variável referente ao valor doproduto).Retorna o valor da variável referente a unidade de medida doproduto.Seta a medida (altera o valor da variável referente a unidade demedida do produto).PESSOA

24Classe referente aos atores do sistema. Seu objetivo principal é fornecer dados as classesque à herdam. Com seus atributos Nome, Telefone, Endereço, CPF, Idade. Possui todos osmétodos sets e gets. Assim implementados para manipulação desses atributos. Esta classe nosistema é utilizada pra gerenciar a agenda de contatos da empresa.PessoaDescriçãoClasse responsável por encapsular os atributos do objeto Pessoa epela criação das funções de manipulação das mesmas (camadamodelo).Atributosnome: Stringtelefone: Stringcell: Stringtipo: StringRG: Stringcpf: StringID: intendereco: StringOperaçõesPessoa()Pessoa(no: String,te: String, id: int)Pessoa(no: String,te: String, r: String,cp: String, t: String,end: String, id: int):getID(): intsetID(ID: int): voidsetNome(nome:String): voidgetNome(): StringsetTelefone(telefone: String):voidgetTelefone():StringResponsável pelo armazenamento de informação referente aonome da pessoa.Responsável pelo armazenamento de informação referente aotelefone da pessoaResponsável pelo armazenamento de informação referente aotelefone da pessoaResponsável pelo armazenamento de informação referente aotipo da pessoa ( gerente , funcionário ou cliente) .Responsável pelo armazenamento de informação referente ao RGda pessoaResponsável pelo armazenamento de informação referente aoCPF da pessoaResponsável pelo armazenamento de informação referente aidentificação da pessoa.Responsável pelo armazenamento de informação referente aquantidade mínima permitida no estoque.DestrutorConstrutorConstrutorRetorna o valor da variável referente ao identificador da pessoa.Seta o ID (altera o valor da variável referente a identificação dapessoa).Seta o nome (altera o valor da variável referente ao nome dapessoa).Retorna o valor da variável referente ao nome da pessoaSeta o telefone (altera o valor da variável telefone da pessoa).Retorna o valor da variável referente ao telefone da pessoa.

25setCell(telefone:String): voidgetCell(): StringsetRG(r: String):voidgetRG(): StringsetCPF(c: String):voidgetCPF (): StringsetTipo(t: String):voidgetTipo(): StringSeta a quantidade (altera o valor da variável referente aquantidade do produto).Retorna o valor da variável referente ao telefone da pessoa.Seta RG (altera o valor da variável referente ao RG da pessoa).Retorna o valor da variável referente ao RG da pessoa.Seta o cpf (altera o valor da variável referente ao cpf da pessoa).Retorna o valor da variável referente ao CPF.Seta a “tipo de pessoa” (altera o valor da variável referente aotipo de pessoa).Retorna o valor da variável referente ao tipo da pessoa (gerente,vendedor ou cliente).FUNCIONÁRIOEsta classe representa os funcionários da empresa cadastrados no sistema. Seus atributossão apenas o Login que será atribuído pelo gerente e Senha, esses dados são necessários paraefetuar o cadastro do funcionário no sistema. Esta classe também possui atributos necessáriospara gerenciar guardar algumas informações do Funcionário, como Cargo e Salário. Também sãodisponíveis métodos para possibilitar o gerenciamento e manipulação dos seus dados.FuncionárioDescriçãoClasse responsável por encapsular os atributos do objetoFuncionário, herda os atributos da Classe Pessoa, mas possuimais algumas informações úteis ao sistema (camada modelo).AtributosID: IntCPF: StringSalario: DoubleCargo: StringArmazena o identificador do funcionário, ligando com suarespectiva tabela de informações da classe Pessoa.Responsável pelo armazenamento de informação referente aoCPF do funcionárioResponsável pelo armazenamento de informação referente aosalário do funcionárioResponsável pelo armazenamento de informação referente aoCargo do funcionário ( gerente , funcionário geral ou secretária) .ALUNOClasse que herda atributos da classe Pessoa, esta classe refere-se aos alunos matriculadosna academia e que estão ativos no sistema, ou seja, mensalidade em dia. Possui atributos para

26gerenciar o acesso do aluno a academia, também para o controle da mensalidade. Esta classe éassociada a classe de Acesso e Mensalidade. Com isso podemos controlar as ações do alunodentro da academia.AlunoDescriçãoClasse responsável por encapsular os atributos do objeto Aluno,herda os atributos da Classe Pessoa, mas possui mais algumasinformações úteis ao sistema (camada modelo).AtributosID: IntData: DateSexo: DoubleArmazena o identificador do Aluno, ligando com sua respectivatabela de informações da classe Pessoa.Responsável pelo armazenamento de informação referente aodata de nascimento do alunoResponsável pelo armazenamento de informação referente aosexo do alunoACESSOClasse que depende de Alunos, para poder gerenciar o acesso do aluno as dependências daacademia. Esta é muito utilizada para evitar inadimplências. E restringir o acesso de pessoas nãodevidamente não registradas ao interior da sala de musculação. Esse controle será feito através deuma catraca eletrônica.AcessoDescriçãoClasse responsável por encapsular os atributos do objeto Acesso,herda os atributos da Classe Funcionário, porém armazena asinformações necessárias para conseguir acesso ao sistema.(camada modelo).AtributosID: IntLogin: StringSenha: DoubleArmazena o identificador do Funcionário, ligando com suarespectiva tabela de informações da classe Funcionario.Responsável pelo armazenamento de informação referente aologin do usuário do sistema.Responsável pelo armazenamento de informação referente asenha necessária para logar no sistema.MENSALIDADEEsta reserva os dados dependentes do aluno, para controlar as mensalidades da academia.Ela guarda todas as datas de pagamento, o dia do vencimento, e o valor da mensalidade a ser

27paga pelo aluno.MensalidadeDescriçãoAtributosID: IntDataUltimo: DataDataVenc: DataClasse responsável por encapsular os atributos do objetoMensalidade, guarda as informações das mensalidades pagaspelo aluno.Armazena o identificador do Aluno, ligando com sua respectivatabela de informações da classe Aluno.Responsável pelo armazenamento de informação referente aultima data que foi paga a mensalidade.Armazena a data do vencimento da mensalidade do aluno.MEDIDAClasse que depende da classe aluno para poder armazenar dados referentes às medidas doaluno, podendo comparar assim a evolução da sua avaliação física no decorrer do tempo. Estaclasse armazena todos os dados utilizados pela academia para avaliar um aluno.AcessoDescriçãoClasse responsável por encapsular os atributos do objetoMedidas, herda os atributos da Classe aluno. Essa classe modelatodas as informações referente as medidas do aluno.AtributosID: IntDate : dateBraco: doubleTórax : doublePeso: doubleAbdomem: doublePerna: DoubleArmazena o identificador do Aluno, ligando com sua respectivatabela de informações da classe Aluno.Salva a data da realização das medidas.Guarda as informações da medida do braço do aluno.Guarda as informações da medida do torax do aluno.Guarda as informações da medida do peso do aluno.Guarda as informações da medida do abdomem do aluno.Guarda as informações da medida da perna do aluno.TAREFAUma classe utilizada pelo sistema para poder armazenar dados no banco de dados, paracontrolar uma espécie de agenda diária. Contendo todos os compromissos agendados, e podendoavisar ao usuário do sistema quando esse compromisso estiver por vencer. Compreende seusatributos em Data, Hora, Descrição do evento ou compromisso.

28DescriçãoClasse responsável por encapsular os atributos do Objeto tarefa epela criação das funções de manipulação das mesmas( camadamodelo).Atributosnome: String Referente ao nome da tarefa definida pelo usuário.D: int Responsável pelo armazenamento de informação referente ao diado mês.M: int Responsável pelo armazenamento de informação referente aomês do ano.A: int Responsável pelo armazenamento de informação referente aoano.H: int Responsável pelo armazenamento de informação referente a horapara realização da tarefaMin: intResponsável pelo armazenamento de informação referente aosminutos para completar o horário de realização da tarefafone: String Responsável pelo armazenamento de informação referente aoId: intOperaçõesTarefa()TarefagetID(): intsetID(n: int): voidgetDia(): intsetDia(n: int): voidgetMes(): voidsetMes(n: int): intgetAno(): voidsetAno(n: int): intgetHora(): intsetHora(n: int): voidgetMin(): intsetMin(n: int): voidgetNome(): StringSetNome(n: String):voidgetfone(): Stringsetfone(n: String):voidtelefone do cliente onde será realizada a obraResponsável pelo armazenamento de informação referente aonumero de identificação da obra.Retorna o ID da tarefa.Seta o ID (altera o valor da variável id).Retorna o valor da variável referente ao dia da tarefa.Seta o D (altera o valor da variável referente ao dia da tarefa).Retorna o valor da variável referente ao Mês da tarefa.Seta o M (altera o valor da variável referente ao Mês da tarefa).Retorna o valor da variável referente ao Ano da tarefa.Seta o A (altera o valor da variável referente ao Ano da tarefa).Retorna o valor da variável referente a hora da tarefa.Seta o H (altera o valor da variável referente a hora da tarefa).Retorna o valor da variável referente aos minutos da tarefa.Seta o Min (altera o valor da variável referente aos minutos datarefa).Retorna o valor da variável referente ao nome da tarefa.Seta o nome (altera o valor da variável referente ao nome datarefa).Seta o fone (altera o valor da variável referente ao fone datarefa).

29CAIXAClasse utilizada pelo sistema, para gerenciar o caixa diário da empresa. Com todos asentradas e saídas de capital do caixa. Podendo no final do dia apenas solicitar ao sistema o

30fechamento do caixa, e conferindo se os saldos finais batem. Esta classe também é muitoimportante para poder ter uma real visão do rendimento da academia.CaixaDescriçãoClasse responsável por encapsular os atributos do objeto Caixa,armazena os movimentos de entrada e saída de capitaldiariamente da empresa.AtributosID: IntDate : dateDinheiro: doubleCheque : doubleCartao: doubleArmazena o identificador do Caixa;Salva a data da realização da abertura do caixa;Guarda as informações da referente ao montante de dinheiro queestá disponível em caixa.Guarda as informações da referente ao montante de cheque queestá disponível em caixa.Guarda as informações da referente ao montante de capital queentrou por forma de cartão e que está disponível em caixa.10 DIAGRAMAS DE SEQÜÊNCIASDIAGRAMA DE SEQÜÊNCIA ADICIONAR ALUNO / PRODUTOFigura 3: Diagrama de seqüência adicionar aluno /produto.Diagrama representa a seqüência e os devidos passos para adicionar um produto, um aluno e aspassagens de parâmetros indicadas pelo símbolo “(*)”.Como utilizamos a arquitetura MVC começamos pela visão, onde o usuário passa os dados para osistema com o intuito de adicionar um produto ou uma obra. A partir daí o sistema executa ospassos para completar a adição, seguindo pelo controlador, chegando ao modelo. Na camada demodelo, são carregados os produtos ou obras cadastrados no banco de dados, em seguida é criado

31o novo objeto produto ou obra e todos os itens são reinseridos no banco de dados. Assimretornando até a visão o resultado sucesso ou falha da operação.DIAGRAMA DE SEQÜÊNCIA ALTERAR PRODUTO / OBRAFigura 4: Diagrama de seqüência alterar produto / aluno.Diagrama representa a seqüência e os devidos passos para alterar um produto ou aluno e aspassagens de parâmetros indicadas pelo símbolo “(*)”.Como utilizamos a arquitetura MVC começamos pela visão, onde o usuário passa os dados para osistema com o intuito de alterar um produto ou uma obra já cadastrado. A partir daí o sistemaexecuta os passos para completar a alteração, seguindo pelo controlador, chegando ao modelo.Na camada de modelo, são carregados os produtos ou obras cadastrados no banco de dados, emseguida é localizado o produto ou obra a ser alterado, alteram-se os dados e todos os itens sãoreinseridos no banco de dados. Assim retornando até a visão o resultado sucesso ou falha daoperação.DIAGRAMA DE SEQÜÊNCIA EXCLUIR PRODUTO / ALUNO

32Figura 4: Diagrama de seqüência excluir produto / obra.Diagrama representa a seqüência e os devidos passos para excluir um produto ou obra e aspassagens de parâmetros indicadas pelo símbolo “(*)”.Como utilizamos a arquitetura MVC começamos pela visão, onde o usuário passa os dados para osistema com o intuito de excluir um produto ou uma obra já cadastrado. A partir daí o sistemaexecuta os passos para completar a exclusão, seguindo pelo controlador. Em seguida é localizadoo produto ou obra a ser excluído, excluem-se o produto ou obra desejada e o banco de dados éatualizado. Assim retornando até a visão o resultado sucesso ou falha da operação.11 DESIGN PATTERNExistem alguns critérios para que uma solução torne-se um padrão:1. Devem descrever e justificar as soluções para problemas concretos e bem definido, i.e.,não são estratégias ou princípios de implementação;2. As soluções descritas devem estar comprovadas, i.e., devem ter sido previamenteexperimentadas e testadas;3. O problema tratado por um padrão deve ocorrer em diferentes contextos, ou seja, se asolução não tem aplicação em diferentes situações, então não é um padrão;4. Usualmente os padrões de projeto descrevem relações entre os conceitos, mecanismos eestruturas existentes nos sistemas;5. Os padrões de projeto devem ser capazes de capturar a evolução e o aprimoramento dassoluções, assim como equilibrar os pontos fortes e fracos encontrados, sendo assim, não sãosoluções óbvias ou triviais;6. Os padrões devem ser utilizados em conjunto com outros padrões, compondo umalinguagem de padrões.

33Existem patterns para quase todo tipo de situação, alguns exemplos dos que utilizamos:DAO é o nome de um pattern que padroniza sua conexão com a base de dados, FAÇADE é umpattern que padroniza a disponibilização dos métodos das entidades do seu sistema.Para desenvolvermos o diagrama de classes nos baseamos em um dos vários padrões deprojetos, escolhemos o padrão "Builder", pois permite a separação da construção de um objetocomplexo da sua representação, de forma que o mesmo processo de construção possa criardiferentes representações. Segundo o livro "Design Patterns: Elements of Reusable Object-Oriented Software", contém os seguintes elementos:• director — constrói um objeto utilizando a interface do builder;• builder — especifica uma interface para um construtor de partes do objetoproduto;• concrete builder — define uma implementação da interface builder, mantém arepresentação que cria e fornece interface para recuperação do produto;• product — o objeto complexo em construção. Inclui classes que definem as parteconstituintes.Figura 1: Exemplo BuilderBasicamente visamos desenvolver algumas características desse padrão de projeto doponto de vista que um processo possa criar diferentes representações, um exemplo disso seria anossa classe Venda que representar uma venda de algum produto ou a venda de uma obra.É importante notar que os padrões não resolverá todos os seus problemas, mas constituem umaferramenta extra muito útil nas situações do dia-a-dia, e certamente facilitará a vida de quem osconhece.12 ARQUITETURAUtilizamos a arquitetura MVC que visa basicamente separar os dados (model) da interface(view), assim alterando a interface não prejudica em nada a manipulação de dados, e estespoderão ser reorganizados sem alterar a interface. Esta arquitetura trabalha na separação dastarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interação com outilizador, Introduzindo um componente entre os dois: o controlador (controller).

34É exatamente isto que queremos para o nosso sistema a separação desses fatores, pois diferentesinterfaces poderão acessar os mesmos dados, funcionando como uma "mascara" apenas.Com isso obtemos um sistema mais organizado e muito mais fácil resolver problemas emigrações com essas especificações do que em um sistema sem arquitetura.13 TESTESPara avaliar os casos de testes utilizamos o método da caixa preta "Particionamento deequivalência" pois divide o domínio de entrada de um programa em classe de dados a partir dasquais os casos de teste podem ser derivados. O particionamento de equivalência procura definirum caso de teste que descubra classes de erros, assim reduzindo o número total de casos de testeque devem ser resolvidos o que facilita o desempenho do desenvolvimento do sistema tendo emvista que nossa equipe utiliza metodologia ágil XP. Baseia-se numa avaliação de classes deequivalência para uma condição de entrada. Uma classe de equivalência representa um conjuntode estados válidos ou inválidos para condições de entrada. Alem disso faremos verificaçõesperiódicas no código do sistema para tentar evitar possíveis erros de implementação e focar aimplementação correta dos requisitos.Estão descritos os possíveis testes manuais realizados no sistema em sua etapa de teste,expressado em um formato detalhado de como realizaros casos de testes, estes casos de testes são baseados nos casos de uso e nos requisitos do sistema.CT - 01TarefaImportânciaObjetivoPré-CondiçãoDados doTesteCadastrar um Aluno.Essencial.Cadastrar um aluno no sistema.Usuário logado no sistema.ID = identificador válido {Id do produto, Integer >0 e único}Nome = nome válido { Nome do produto, String não nula}Telefone = valor válido { String não nula, Length > 9}DescriçãoCenário Principal:1. Após o usuário passar os dados do aluno.2. O sistema deverá validar todas as informações3. Retorno de mensagem de sucesso.4. Sistema será redirecionado a tela principal.Cenário Secundário:1. Após o sistema verificar os dados do aluno;2. O sistema retornará uma mensagem de erro;3. A operação ficará em espera até corrigir os erros ou

35Forçar saída do sistema.ResultadosFluxo Principal: Aluno cadastrado com sucesso.Fluxo Alternativo 1: Algum campo inválido ou vazio: O sistemaindica que se encontra o erro.CT - 02TarefaImportânciaObjetivoPré-CondiçãoDados doTesteAlterar dados de um aluno.Essencial.Gerenciar as informações do aluno no sistema.Usuário logado no sistema.ID = identificador válido {Id do produto, Integer >0 e único}Nome = nome válido { Nome do produto, String não nula}Telefone = valor válido { String não nula, Length > 9}DescriçãoResultadosCenário Principal:1. Após o usuário alterar os dados do aluno.2. O sistema deverá validar todas as informações3. Retorno de mensagem de sucesso.4. Sistema será redirecionado a tela principal.Cenário Secundário:1. Após o sistema verificar os dados do aluno;2. O sistema retornará uma mensagem de erro;3. A operação ficará em espera até corrigir os erros ouForçar saída do sistema.Fluxo Principal: Alteração do aluno já cadastrado.Fluxo Alternativo 1: Algum campo inválido ou vazio: O sistemaindica que se encontra o erro.CT - 03TarefaImportânciaCadastrar um produto.Essencial.

36ObjetivoPré-CondiçãoDados doTesteCadastrar um produto no sistema.Usuário logado no sistema.ID = identificador válido {Id do produto, Integer >0 e único}Nome = nome válido { Nome do produto, String não nula}Valor = valor válido {Valor do produto, Double > 0,00}Fabricante = nome válido { Nome do fabricante, String nãonula}QuantidadeTotal = valor válido{Valor da quantidade, Double >0,00}Estoque Mínimo = valor válido{Valor da quantidade_minima,Double > 0,00}DescriçãoResultadosCenário Principal:1. Após o usuário passar as informações do produto.2. O sistema deverá validar todas as informações3. Retorno de mensagem de sucesso.4. Sistema será redirecionado a tela principal.Cenário Secundário:1. Após o sistema verificar os dados do produto;2. O sistema retornará uma mensagem de erro;3. A operação ficará em espera até corrigir os erros ouForçar saída do sistema.Fluxo Principal: Produto cadastrado.Fluxo Alternativo 1: Algum campo inválido ou vazio: O sistemaindica que se encontra o erro.CT - 04TarefaImportânciaObjetivoPré-CondiçãoDados doTesteGerenciar produto.Importante.Procura por produtos já cadastrados e exibi suas informações natela, permiti modificações em qualquer campo de informaçãoalém de exclusão do produto.Produto deve estar cadastrado no sistema e o usuário deveestar devidamente logado de acordo com seu privilégio nosistema.ID = identificador válido {Id do produto, Integer >0 e único}

37Nome = nome válido { Nome do produto, String não nula}Valor = valor válido {Valor do produto, Double > 0,00}Fabricante = nome válido { Nome do fabricante, String nãonula}QuantidadeTotal = valor válido{Valor da quantidade, Double >0,00}Estoque Mínimo = valor válido{Valor da quantidade_minima,Double > 0,00}DescriçãoCenário Principal:1. Após o usuário alterar os dados do produto.2. O sistema deverá validar todas as informações3. Retorno de mensagem de sucesso.4. Sistema será redirecionado a tela principal.Cenário Secundário:1. Após o sistema verificar os dados do produto;2. O sistema retornará uma mensagem de erro;3. A operação ficará em espera até corrigir os erros ouForçar saída do sistema.ResultadosFluxo Principal: Produto alterado ou excluído.Fluxo Alternativo 1: Algum campo inválido ou vazio ou: Osistema indicara que se encontra o erro.Fluxo Alternativo 2: Produto inexistente: O sistema indicara queo produto não consta cadastrado no sistema.CT - 05TarefaImportânciaObjetivoPré-CondiçãoDados doTesteAgendar Tarefa.Essencial.Agendar uma Tarefa no sistema.Usuário logado no sistema.Ano = ano válido { >2000 }Mês = mês válido { 1 à 12}Dia = dia válido { 1 à 30}

38Hora = hora válida { 0 à 23}Tarefa = tarefa válida {Nome da tarefa, String não nula}Descrição1. O usuário inicia o menu Tarefas;2. O usuário escolhe o item "Agendar Tarefa" do menu;3. O sistema abre uma janela com um calendário, onde com umduplo clique em uma data abrirá uma janela de agendamento;4. O usuário preenche os campos obrigatórios;5. Após o preenchimento desses campos o usuário submete aação;6. Será retornado a mensagem de Erro ou sucesso;ResultadosFluxo Principal: tarefa agendada.Fluxo Alternativo 1: campo tarefa vazio: o sistema indicara pormeio de aviso para o usuário especificar a tarefa agendada.CT - 06TarefaImportânciaObjetivoPré-CondiçãoDados doTesteGerenciar Tarefa.Importante.Gerenciar uma tarefa já agendada no sistema.Tarefa já agendada no sistema.Ano = ano válido { >2000 }Mês = mês válido { 1 à 12}Dia = dia válido { 1 à 30}Hora = hora válida { 0 à 23}Tarefa = tarefa válida {Nome da tarefa, String não nula}Descrição1. O usuário inicia o menu Tarefas;2. O usuário escolhe o item "Agendar Tarefa" do menu;3. O sistema abre uma janela com um calendário, onde com umclique em uma data atualizará a tabela de tarefas;4. O usuário seleciona a tarefa para modificar/excluir;5. Se excluir, apenas a mensagem de confirmação;6. Se alterar, uma janela com os dados atuais, onde o usuário

39faz a modificação;7. Mensagem retorno Falha/Sucesso.ResultadosFluxo Principal: Gerenciamento das tarefas já cadastradas.CT - 07TarefaImportânciaObjetivoPré-CondiçãoDados doTesteCadastro de funcionárioEssencial.Cadastrar um funcionário no sistema, para que este possa tersuas informações tais como salário e comissões gerenciadospelo sistema.Usuário logado no sistema e este usuário ser um gerente, ouadministrador do sistema.Nome = nome válido { Nome da funcionário, String não nula}Telefone = telefone válido { Numero do telefone, String Length>7}CPF = CPF válido {Numero do CPF, String Length > 9}Cargo = Cargo válido { Nome do cargo, String não nula}Salário = Salário válido{ Salário Real, double > 0,00 }Descrição1. O usuário inicia o menu Gerencia;2. O usuário escolhe o item Controle de funcionários;3. O sistema abre uma janela com a listagem de todas osfuncionários cadastrados no sistema;4. O usuário deve clicar no botão Novo Funcionário;5. Abrirá uma janela com campos de informação;6. Preencha os campos obrigatórios e submeta a ação;7. Será retornado a mensagem de Erro ou sucesso;ResultadosFluxo Principal: Funcionário cadastrado.CT - 08

40TarefaImportânciaObjetivoPré-CondiçãoDados doTesteGerencia de funcionárioEssencial.Gerencia dos funcionário no sistema, para que este possa tersuas informações tais como salário e comissões gerenciadospelo sistema.Usuário logado no sistema e este usuário ser um gerente, ouadministrador do sistema.Nome = nome válido { Nome da funcionário, String não nula}Telefone = telefone válido { Numero do telefone, String Length>7}CPF = CPF válido {Numero do CPF, String Length > 9}Cargo = Cargo válido { Nome do cargo, String não nula}Salário = Salário válido{ Salário Real, double > 0,00 }Descrição1. O usuário inicia o menu Gerencia;2. O usuário escolhe o item Controle de funcionários;3. O sistema abre uma janela com a listagem de todas osfuncionários cadastrados no sistema;4. O usuário deve Selecionar na tabela o funcionário que desejamodificar ou excluir;5. O sistema enviará uma mensagem de confirmação;6. Se sua opção foi modificar aparecera uma janela com oscampos de informação do funcionário então pode altera-los esubmeta a ação;7. Será retornado a mensagem de Erro ou sucesso;ResultadosFluxo Principal: Funcionário Excluído/Modificado..CT - 9TarefaImportânciaCadastro de UsuárioEssencial.

41ObjetivoPré-CondiçãoDados doTesteCadastrar um usuário no sistema, sómente cadastrado seu logine senha um funcionário se tornará usuário e poderá utilizar osistema.Usuário logado no sistema, e este usuário ser um gerente.Nome = nome válido { Nome da funcionário, String não nula}User = nome de usuário válido { Usuário válido, String Length >2}Senha = Senha válida {Senha válida, String Length > 5}Tipo = Tipo válido {Tipo de Login, String=“Gerente ouVendedor”}Descrição1. O usuário inicia o menu Gerencia;2. O usuário escolhe o item Controle de Usuário;3. O sistema abre uma janela com alguns campos a serpreenchidos4. O usuário deve preencher todos os campos pois sãoobrigatórios5. Se o funcionário ainda não cadastrado, clique no botão “...”este abrirá uma janela com os dados para um novo funcionário.6. Preencha os campos obrigatórios e selecione o funcionáriocorrespondente a este login;7. Será retornado a mensagem de Erro ou sucesso;ResultadosFluxo Principal: usuário cadastrado.CT - 10TarefaImportânciaObjetivoPré-CondiçãoDados doTesteGerencia de UsuárioEssencial.Gerencia dos Usuário no sistema, garantir integridade esegurança do sistema.Usuário logado no sistema, e este usuário ser um gerente.User = nome de usuário válido { Usuário válido, String Length >2}Senha = Senha válida {Senha válida, String Length > 5}Descrição1. O usuário inicia o menu Gerencia;

422. O usuário escolhe o item Controle de Usuário;3. O sistema abre uma janela com alguns campos a serpreenchidos4. O usuário deve preencher os campos de login e senha edepois clicar no botão alterar;5. Se usuário e senha válido, então será liberado a modicar ologin no sistema;6. Será retornado a mensagem de Erro ou sucesso;ResultadosFluxo Principal: Alterar login do funcionário;

43CONCLUSÃOEste documento tem como meta fornecer uma modelagem para o sistema propostoinicialmente: um sistema de apoio à empresa, academia de ginástica e musculação SportLife. Estamodelagem baseada em orientação a objetos tornou o processo de desenvolvimento do softwaremais ágil, prático e de melhor entendimento a todos os membros da equipe, pois todos os passosforam seguidos por dicas e informações do cliente.Assim, com esta documentação foram esclarecidos e objetivados todos os requisitosnecessários para a satisfação da empresa-cliente.

44Apêndice A – Coleta de InformaçõesAo identificar a necessidade de um sistema para gerenciamento da academia A coleta deinformações baseou-se em entrevistas com o dono da empresa a academia SportLife, o senhorAlain Camargo. A partir do primeiro contato, explanou o funcionamento básico do ambienteorganizacional da empresa. Já nas demais entrevistas, foram necessárias algum questionamentosobre a realidade da empresa.Os tópicos abordados nestes questionários foram:- Descrição do processo realização das tarefas;- Atividades mais freqüentes na academia;- Formas de registros atuais;- Alocação e recursos;- Funcionamento em geral da academia.Tendo em vista o bom aproveitamento dos questionários, e levando em consideraçãotodas as colocações impostas pelo senhor Alain, quanto aos demais instrutores da academia.Assim podemos nos basear em quais requisitos necessários para o desenvolvimento eimplantação do sistema na empresa.

45Apêndice B.1 -Como o sistema exigiu da equipe algumas melhoras nos feedbacks, tais como alteração dastelas. Melhor gerenciamento da barra de menus. Isso trouxe em alguns esforços não previstos nocronograma. E também algumas das iterações do sistema, não foram seguidas conforme previstas nocronograma do projeto. Pois a necessidade do cliente nos fez rever algumas das etapas e antecipa-lasdeixando as previstas como segundo plano.Temos isso não visto na questão de LOGIN DO SISTEMA que era uma etapa prevista para adata de 06/08, mas foi antecipado para as primeiras etapas para poder controlar o fluxo dos usuáriosque já usavam a versão beta do sistema.Uma outra etapa antecipada foi CONTROLE DO CAIXA, pois temos a necessidade que ocliente já gostaria de ir usando o sistema para poder ter o controle das mensalidades de todos alunos,e tendo isto em vista, o sistema necessitaria de um controle do caixa para poder cumprir esse requisitodo cliente.2 -Com a implantação do sistema e seu uso diário, tivemos muita dificuldade em conseguirque o DB4O, se mantivesse estável. Houve muitas quebras de informações e também aperformance do sistema já estava ficando comprometida. Com essas dificuldades foi sugeridomigrar todo o banco de DB4O para PostGress. O PostGress apresento uma melhor performance eé considerado um SGBD mais confiável. Como essas mudanças surgiram no meio do caminho doprojeto, houve um atraso considerável no cronograma, mas garantimos uma qualidade melhor dosistema em si. Veja o anexo do novo cronograma.

46Anexo CronogramaDescriçãoPrevisão(Semanas)Datainício1 Treinamento eObtenção dados1 02/072 Telas Iniciais 2 16/073 Cadastro Aluno 1 23/074 Utilização Webcam 1 30/075 Login/ Criptografia 1 06/086 Funcionários/Salários 1 13/087 Usuários 1 20/088 Avaliação 1 27/089 Avaliação + Anaminse 1 04/0910 Modalidades 1 11/0911 Integridade Do BancoDe Dados1 18/0912 Back UP 1 25/0913 Agenda Contatos 1 02/1014 Agenda Tarefas 1 09/1015 Controle Alunos 1 16/1016 Controle Do Acesso 1 23/1017 Abertura E Restriçãodas Mensalidades1 30/1018 Caixa 1 14/1119 Migração do SGBD ParaPostGress2 21/1120 Revisão e Testes 2 05/12

47FORMULÁRIO DO RELATÓRIO DA EQUIPENome Contribuição AssinaturaHudson João Magalhães 50% _____________________________________Lucas da Silva Grando 50% _____________________________________