Unioeste – Universidade Estadual do Oeste do
Paraná
CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS
Colegiado de Ciências da Computação
Curso de Bacharelado em Ciências da Computação
Especificação de Requisitos e Modelagem
Sistema Academia SportLife
Hudson João Magalhães
Lucas da Silva Grando
Cascavel
2010
2
SUMÁRIO
1 MOTIVAÇÃO………………………………………………………………………….
2 PROBLEMA DA EMPRESA…………………………………………………………
3 CRONOGRAMA………………………………………………………………………
4 METODOLOGIA ESCOLHIDA.................................................................................
3
3
3
4
5 REQUISITOS FUNCIONAIS.......................................................................................
6 REQUISITOS NÃO FUNCIONAIS ............................................................................
6.1 REQUISITOS DE PROCESSO ....................................................................................
6.2 REQUISITOS DO PRODUTO .....................................................................................
6.3 O GRAFO SIG………………………………………………………………………..
7 MODELAGEM ORGANIZACIONAL i*...................................................................
7.1 MODELO DE DEPENDÊNCIAS ESTRATÉGICAS..................................................
7.2 MODELO DE RAZÕES ESTRATÉGICAS.................................................................
8 CASOS DE USO ............................................................................................................
5
7
7
7
8
9
10
11
14
8.1 REPRESENTAÇÃO DOS CASOS DE USO...............................................................
8.2 DESCRIÇÃO DOS CASOS DE USO..........................................................................
9 DIAGRAMAS DE CLASSES .......................................................................................
10 DIAGRAMAS DE SEQUECIA
11 DESIGN PATTERN
12 ARQUITETURA
13 TESTES
CONCLUSÃO....................................................................................................................
Apêndice A – Coleta de Informações...............................................................................
14
14
22
28
30
32
34
45
46
3
1 INTRODUÇÃO E MOTIVAÇÃO
Busca por conhecimento da equipe, no desenvolvimento do aprendizado do uso da
engenharia de software para o desenvolvimento de sistemas em geral, atender o cliente que
necessita de um sistema organizacional para controle do caixa, e cadastro dos dados dos alunos
produzindo 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 este
sistema poderá resultar na economia de tempo e esforço, gerando também mais segurança e
restrição aos dados.
A empresa a qual o sistema será implantado é a academia Sport Life. Conforme os dados
abaixo:
Academia Sport Life
Rua Visconde do Rio Branco, 3402
Vila Tolentino - Cascavel - PR
Telefone: +55 (45) 3038-9800
2 PROBLEMA DA EMPRESA
A 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 esse
controle estar sendo feito em arquivos de papel, ocorre frequentemente perda de informação ou
até erro humano na hora de organizar as informações, gerando assim inúmeros transtornos. Este
controle irá gerenciar as atividades em geral da academia tais como as contas a pagar no dia, e as
atividades 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 e
organizando o dia a dia da empresa, além de evita erros graves. E trazendo mais algumas
funcionalidades ao sistema.
3 CRONOGRAMA
4
Descrição
1
Treinamento e
Obtenção dados
Previsão
(Semanas)
Data
início
1
02/07
2
Telas Iniciais
2
16/07
3
Cadastro Aluno
1
23/07
4
Utilização Webcam
1
30/07
5
Login/ Criptografia
1
06/08
6
Funcionários/Salários
1
13/08
7
Usuários
1
20/08
8
Avaliação
1
27/08
9
Avaliação + Anaminse
1
04/09
10
Modalidades
1
11/09
11
Integridade Do Banco
De Dados
1
18/09
12
Back UP
1
25/09
13
Agenda Contatos
1
02/10
14
Agenda Tarefas
1
09/10
15
Controle Alunos
1
16/10
16
Controle Do Acesso
1
23/10
17
Abertura E Restrição
das Mensalidades
1
30/10
18
Caixa
1
14/11
19
Revisão e Testes
2
21/11
4 METODOLOGIA ESCOLHIDA
Como a exigência do mercado de softwares hoje em dia é muito forte, não só em questão
5
a qualidade mais também ao tempo de entrega, além da complexidade do sistema que irá ser
desenvolvido, prevendo mudanças das especificações durante a produção do projeto e a gestão
sendo indispensável para assegurar a qualidade do produto, utilizaremos para o desenvolvimento
do sistema será a metodologia XP.
Como a metodologia XP, é uma metodologia para equipes pequenas e médias e que irão
desenvolver software com requisitos vagos e em constante mudança, resolvemos adotar esta
metodologia. Para isso a estratégia de constante acompanhamento e realização de vários
pequenos 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á um
foco explícito em escopo. Para isso, recomenda-se a priorização de funcionalidades que
representem maior valor possível para o negócio. Desta forma, caso seja necessário à diminuição
de 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 ganho
de curto prazo na produtividade, ao diminuir qualidade, não é compensado por perdas (ou até
impedimentos) a médio e longo prazo.
5 REQUISITOS FUNCIONAIS
Os 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 mais
variadas situações. Os requisitos funcionais que serão apresentados foram estudados e analisados
juntamente ao filho do dono da empresa. Os seguintes requisitos estão apresentados abaixo.
[RF - 01] Cadastrar Produto
O sistema deverá permitir cadastrar novos produtos com todos os seus atributos. O
cadastro não poderá ser realizado no caso de já existir no estoque um produto com o mesmo
código de barra ou nome.
6
[RF - 02] Remover Produto
O sistema deverá permitir a exclusão de produtos por nome ou código de barra,via
usuários autorizados ( logados ).
[RF - 03] Alterar Produto
O sistema deverá permitir a alteração de um produto já existente no banco de dados.
[RF - 04] Consultar Produto
O sistema deverá permitir a consulta de um produto já existente no banco de dados.
[RF – 05] Cadastrar Aluno
O sistema deverá cadastrar um Aluno quando necessário e seus dados no banco de
dados. Tais com as medidas, vencimento da mensalidade.
[RF – 06] Excluir Aluno
O sistema deverá possibilitar a exclusão pelo nome do aluno, atualizando
automaticamente no banco de dados.
[RF – 07] Pesquisar Aluno
O sistema deverá possibilitar a pesquisa de um aluno já armazenado no banco de dados
do sistema e disponibilizar a informação para o usuário. Tais com as medidas, vencimento da
mensalidade e a foto.
[RF – 08 ] Alterar Aluno
O Sistema deverá possibilitar ao usuário modificações/alterações nas informações já
armazenadas no sistema.
[RF – 09 ] Cadastrar Usuário
O Sistema deverá possibilitar o cadastro de novos usuários para o sistema, cada um com
um login e senha distinta.
7
[RF – 10 ] Remover Usuário
O Sistema deverá possibilitar a remoção de usuários do sistema, desabilitando-os de
qualquer acesso ao sistema.
[RF – 11 ] Alterar Usuário
O Sistema deverá possibilitar as alterações na conta de usuários no sistema, modificando
senha ou login se necessário.
[RF – 12 ] Pesquisar Usuário
O Sistema deverá possibilitar uma pesquisa sobre as contas de usuários do sistema
existentes e disponibilizar essas informações.
[RF - 13 ] Logar no Sistema
Todas as funcionalidades do sistema são acessíveis aos usuários de acordo com seu nível
de privilégio no sistema. Isto é realizado através de um sistema de Login/Senha.
[RF - 14 ] Realizar Venda
Os funcionários serão permitidos realizar uma venda, o sistema devera possibilitar a
venda através do usuário logado.
[RF - 15 ] Realizar Avaliação Física
Os usuários do sistema poderão armazenar no banco de dados, as informações do aluno
da academia referente a avaliação física. Como as medidas, peso, altura, etc...
[RF - 16 ] Agendar Avaliação Física
O sistema irá trabalhar como uma agenda de horários, onde o usuário passara as
informações para realizar um agendamento para avaliar o aluno.
[RF – 17 ] Registrar Movimentação Caixa
O sistema deverá registrar toda movimentação diária do caixa. Como entrada e saída de
capita, venda de produto, pagamento de mensalidade.
8
[RF - 18] Lembrar Tarefas Diárias
O sistema deverá lembrar o usuário de alguma tarefa agendada para a data atual. Essa
tarefa pode ser uma conta a pagar, ou qualquer compromisso armazenado.
6 REQUISITOS NÃO FUNCIONAIS
6.1 REQUISITOS DE PROCESSO
[RNF /PROC -01]
O sistema deverá ser implementado em Java de modo a ser compatível com o sistema
operacional Windows.
[RNF /PROC -02]
Será criado um documento contendo um diagrama de classes e informações sobre o
código fonte.
[RNF /PROC- 03]
Será criado um cronograma detalhado para o processo de desenvolvimento no qual
constem: as atividades a serem desenvolvidas e em que período e com que recursos humanos e
fí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 dos
funcionários.
* USABILIDADE
9
[RNF /USAB - 05]
A interface do sistema será agradável, objetiva e trivial ao usuário. Suas funcionalidades
e 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 objetiva
informaçõ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ça
dos 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 os
seguintes 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. Cujo
principal objetivo é demonstrar que os requisitos não-funcionais reorganizados proporcionam
uma visão mais realista do sistema. Através dele podemos verificar o que deve ser
operacionalizado para atender determinado requisito e como ele contribui (positivo ou
negativamente) para os demais.
10
Figura 1 – O grafo SIG
11
7 MODELAGEM ORGANIZACIONAL i*
7.1 MODELO DE DEPENDÊNCIAS ESTRATÉGICAS
A partir de uma visão macro do modelo nota-se que é composto de seis atores, sendo
que a utilização direta do sistema é feita apenas pelos autores gerente e funcionário, essa
interação é especificada pelas dependências destes com o ator sistema.
Figura 2: Modelo de Dependências Estratégicas (SD)
12
O 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 de
realizar algumas tarefas: gerência produtos e agendamento, vendas. Todas estas operações para
não impor dificuldade ao usuário na utilização do sistema são necessário que ele tenha uma boa
usabilidade. Por haver grande fluxo de dados entre os atores, sendo que o sistema tem uma
dependência de obter dados junto ao funcionário, é necessário que esta comunicação seja feita de
forma segura e ágil.
O ator gerente pode ser considerado um funcionário especializado, sendo assim ele
poderá executar todas as operações de um funcionário “comum”, para isto ele faz uso de um
login/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 sistema
ao fazer uso das funções: gerenciar funcionário, gerenciar caixa, estas sendo essenciais ao
funcionamento da organização.
Para que o sistema seja rápido, com dados íntegros e confiáveis ele dependera da
qualidade do sistema gerenciador de banco de dados.
7.2 MODELO DE RAZÕES ESTRATÉGICAS
O modelo SR (figura 3), complementa o modelo SD de forma a compreender e modelar
de 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ário
forneça um login e senha. Já as operações com produtos, agendamentos e funcionários têm as
mesmas subdivisões, que são: cadastrar, modificar, remover e consultar.
13
Figura 3: Modelo de Razões Estratégica (SR)
14
8 CASOS DE USO
8.1 REPRESENTAÇÃO DOS CASOS DE USO
Figura 4, Casos de Uso.
8.1 DESCRIÇÃO DOS CASOS DE USO
[Caso de uso 001]: Controlar Mensalidade
Descriçã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.
15
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 controle de mensalidades.
3. O sistema levará o usuário a uma tela onde encontrará todas as mensalidades ativas. E
mostrará o status de cada. “Ok”, “Vencida”, “Aberta”.
4. O usuário seleciona o aluno na lista. E caso o usuário escolha PAGAMENTO, o
sistema remete para tela de pagamento da mensalidade. <<include>>
Cenário Secundário
4.1. Caso o usuário escolha a opção Alterar Mensalidade no passo 3, o sistema
redireciona-o ao Caso de uso Alterar Mensalidade <<extends>>.
4.2. Caso o usuário escolha a opção Excluir Mensalidade no passo dois, o sistema
remete ao Caso de uso Excluir Mensalidade <<extends>>.
[Caso de uso 002]: Alterar Mensalidade
Descriçã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 Controlar
Mensalidade.
Cenário Principal de Sucesso:
1. O Sistema apresenta os dados pessoais sobre o aluno a qual a mensalidade foi
selecionada.
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 Mensalidade
Descrição: O Sistema deverá excluir a mensalidade do aluno.
Atores envolvidos: Usuários com acesso privilegiado. Gerentes.
16
Pré-condição Usuário deve estar logado no sistema e ter realizado o Caso de Uso Controlar
Mensalidade.
Cenário Principal
1. 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 o
desconectará do sistema.
Cenário Secundário
2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso Gerenciar
Mensalidade.
[Caso de uso 004] Agendar Avaliação
Descrição: O Sistema deverá mostrar quais as datas e horários disponíveis para agendamento da
avaliaçã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 ou
erro.
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 de
horários.
[Caso de uso 005] Agendar Tarefa
Descrição: O Sistema deverá agendar qualquer tarefa ou compromisso solicitado pelo usuário.
17
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 ou
erro.
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 de
compromissos.
[Caso de uso 006]: Controle Caixa
Descriçã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 do
caixa. 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ções
realizadas até o momento. Entrada e saída do caixa. Podendo escolher algumas opções.
4. O usuário seleciona a opção fechar caixa. <<include>>
Cenário Secundário
4.1. Caso o usuário escolha a opção saída no passo 4, o sistema redireciona-o ao Caso de
uso Saída do Caixa <<extends>>.
4.2. Caso o usuário escolha a opção Excluir Mensalidade no passo dois, o sistema
remete ao Caso de uso Entrada do Caixa <<extends>>.
18
[Caso de uso 007] Saída do Caixa
Descriçã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 Caixa
Cenário Principal
1. 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 sistema
exibirá uma mensagem de sucesso.
Cenário Secundário
2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso Controle
Caixa.
[Caso de uso 008] Entrada do Caixa
Descriçã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 Caixa
Cenário Principal
1. 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 sistema
exibirá uma mensagem de sucesso.
Cenário Secundário
2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso Controle
Caixa.
[Caso de uso 009]: Contas a Pagar
19
Descriçã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, Caso
de Uso Saída Caixa <<extend>>
Cenário Secundário:
3.1 O sistema não valida a retirada do caixa. Mostrando mensagem de erro, ou falta de
capital.
[Caso de uso 010]: Controle Acesso
Descrição: O Sistema deverá controlar a entrada de todas as pessoas na empresa.
Atores envolvidos: Gerente, funcionário, aluno
Pré-condição: O sistema deverá estar logado e funcionando. Os atores envolvidos deverão estar
cadastrados 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 bloqueado
devido a falta de pagamento da mensalidade.
[Caso de uso 011] Fechar Caixa
Descrição: O Sistema deverá finalizar o caixa diário, mostrando todas as movimentações e saldo
final.
20
Atores envolvidos: Gerente
Pré-condição: O sistema deve estar logado com usuário com privilégios de gerente. O caixa
deverá estar aberto no dia e houver alguma movimentação.
Cenário Principal de Sucesso:
Cenário Principal
1. 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 sistema
exibirá uma mensagem de sucesso.
Cenário Secundário
2.1 Caso o usuário negue a confirmação, o sistema voltara ao Caso de Uso Controle
Caixa.
[Caso de uso 012]: Logar no Sistema
Descrição: O usuário devera entrar com seus dados: login e senha. O Sistema deverá permitir
acesso 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 corretos
4.
O sistema será iniciado, liberando os privilégios de acordo com o privilegio do
usuá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 Venda
Descrição: O usuário entrara com alguns dados do aluno em seguida os códigos e quantidades
21
dos produtos da venda.
Atores envolvidos: Gerente e Funcionário
Pré-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ório
Descrição: O usuário solicita ao sistema um relatório do dia.
Atores envolvidos: Usuário do sistema
Pré-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 de
novos 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á redirecionado
a tela inicial.
9 DIAGRAMAS DE CLASSES
Um diagrama de classes é uma representação da estrutura e relações das classes que
servem de modelo para objetos. É uma modelagem muito útil para o sistema, define todas as
classes que o sistema necessita possuir e é a base para a construção dos diagramas de
comunicação e estados.
Logo abaixo é apresentado o diagrama de classes do sistema, e uma breve descrição de
cada classe segue abaixo.
22
Figura 5 – Representação Diagrama de Classes
PRODUTO
Esta classe representa os produtos estocados na empresa e cadastrados no sistema. Seus
atributos são id, Descrição e Quantidade, junto com seus custos, Preço de venda e preço de
compra, que serão necessários para o cadastro do produto no sistema e futura utilização dos
dados, 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.
Produto
Descrição
Atributos
nome: String
descricao: String
Classe responsável por encapsular os atributos do objeto
Produto e pela criação das funções de manipulação das mesmas(
camada modelo).
Responsável pelo armazenamento de informação referente ao
nome do produto.
Responsável pelo armazenamento de informação referente a
descrição do produto
23
medida: String
fabricante: String
Id: int
quantidade: double
preco: double
estoquemin: double
Operações
getNome(): String
setNome(n: string):
void
getID(): int
getDescricao():
String
setDescricao(d:
String):void
getFabricante():
String
setFabricante(r:
String): void
getQuantidade():
double
setQuantidade(q:
double): void
getEstoqueMIN():
double
setEstoqueMIN(q:
double): void
getValor(): double
setValor(q: double):
void
getUnidadeMedida():
String
setUnidadeMedida(q:
String): void
PESSOA
Responsável pelo armazenamento de informação referente ao
tipo de medida do produto.
Responsável pelo armazenamento de informação referente ao
fabricante do produto.
Responsável pelo armazenamento de informação referente ao
numero de identificação do produto.
Responsável pelo armazenamento de informação referente a
quantidade do produto.
Responsável pelo armazenamento de informação referente ao
preço do produto.
Responsável pelo armazenamento de informação referente a
quantidade 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 do
Produto).
Retorna o valor da variável referente ao identificador do
Produto.
Retorna o valor da variável referente a descrição do produto
Seta a descricao (altera o valor da variável referente a descrição
do produto).
Retorna o valor da variável referente ao fabricante do produto
Seta o fabricante (altera o valor da variável referente ao
fabricante do produto).
Retorna o valor da variável referente a quantidade do produto
Seta a quantidade (altera o valor da variável referente a
quantidade do produto).
Retorna o valor da variável referente a quantidade mínina de
produto permitida em estoque.
Seta a quantidade (altera o valor da variável referente a
quantidade 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 do
produto).
Retorna o valor da variável referente a unidade de medida do
produto.
Seta a medida (altera o valor da variável referente a unidade de
medida do produto).
24
Classe referente aos atores do sistema. Seu objetivo principal é fornecer dados as classes
que à herdam. Com seus atributos Nome, Telefone, Endereço, CPF, Idade. Possui todos os
métodos sets e gets. Assim implementados para manipulação desses atributos. Esta classe no
sistema é utilizada pra gerenciar a agenda de contatos da empresa.
Pessoa
Descrição
Atributos
nome: String
telefone: String
cell: String
tipo: String
RG: String
cpf: String
ID: int
endereco: String
Operações
Pessoa()
Pessoa(no: String,
te: String, id: int)
Pessoa(no: String,
te: String, r: String,
cp: String, t: String,
end: String, id: int):
getID(): int
setID(ID: int): void
setNome(nome:
String): void
getNome(): String
setTelefone
(telefone: String):
void
getTelefone():String
Classe responsável por encapsular os atributos do objeto Pessoa e
pela criação das funções de manipulação das mesmas (camada
modelo).
Responsável pelo armazenamento de informação referente ao
nome da pessoa.
Responsável pelo armazenamento de informação referente ao
telefone da pessoa
Responsável pelo armazenamento de informação referente ao
telefone da pessoa
Responsável pelo armazenamento de informação referente ao
tipo da pessoa ( gerente , funcionário ou cliente) .
Responsável pelo armazenamento de informação referente ao RG
da pessoa
Responsável pelo armazenamento de informação referente ao
CPF da pessoa
Responsável pelo armazenamento de informação referente a
identificação da pessoa.
Responsável pelo armazenamento de informação referente a
quantidade mínima permitida no estoque.
Destrutor
Construtor
Construtor
Retorna o valor da variável referente ao identificador da pessoa.
Seta o ID (altera o valor da variável referente a identificação da
pessoa).
Seta o nome (altera o valor da variável referente ao nome da
pessoa).
Retorna o valor da variável referente ao nome da pessoa
Seta o telefone (altera o valor da variável telefone da pessoa).
Retorna o valor da variável referente ao telefone da pessoa.
25
setCell(telefone:
String): void
getCell(): String
setRG(r: String):
void
getRG(): String
setCPF(c: String):
void
getCPF (): String
setTipo(t: String):
void
getTipo(): String
Seta a quantidade (altera o valor da variável referente a
quantidade 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 ao
tipo de pessoa).
Retorna o valor da variável referente ao tipo da pessoa (gerente,
vendedor ou cliente).
FUNCIONÁRIO
Esta classe representa os funcionários da empresa cadastrados no sistema. Seus atributos
são apenas o Login que será atribuído pelo gerente e Senha, esses dados são necessários para
efetuar o cadastro do funcionário no sistema. Esta classe também possui atributos necessários
para gerenciar guardar algumas informações do Funcionário, como Cargo e Salário. Também são
disponíveis métodos para possibilitar o gerenciamento e manipulação dos seus dados.
Funcionário
Descrição
Atributos
ID: Int
CPF: String
Salario: Double
Cargo: String
Classe responsável por encapsular os atributos do objeto
Funcionário, herda os atributos da Classe Pessoa, mas possui
mais algumas informações úteis ao sistema (camada modelo).
Armazena o identificador do funcionário, ligando com sua
respectiva tabela de informações da classe Pessoa.
Responsável pelo armazenamento de informação referente ao
CPF do funcionário
Responsável pelo armazenamento de informação referente ao
salário do funcionário
Responsável pelo armazenamento de informação referente ao
Cargo do funcionário ( gerente , funcionário geral ou secretária) .
ALUNO
Classe que herda atributos da classe Pessoa, esta classe refere-se aos alunos matriculados
na academia e que estão ativos no sistema, ou seja, mensalidade em dia. Possui atributos para
26
gerenciar 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 aluno
dentro da academia.
Aluno
Descrição
Atributos
ID: Int
Data: Date
Sexo: Double
Classe responsável por encapsular os atributos do objeto Aluno,
herda os atributos da Classe Pessoa, mas possui mais algumas
informações úteis ao sistema (camada modelo).
Armazena o identificador do Aluno, ligando com sua respectiva
tabela de informações da classe Pessoa.
Responsável pelo armazenamento de informação referente ao
data de nascimento do aluno
Responsável pelo armazenamento de informação referente ao
sexo do aluno
ACESSO
Classe que depende de Alunos, para poder gerenciar o acesso do aluno as dependências da
academia. Esta é muito utilizada para evitar inadimplências. E restringir o acesso de pessoas não
devidamente não registradas ao interior da sala de musculação. Esse controle será feito através de
uma catraca eletrônica.
Acesso
Descrição
Atributos
ID: Int
Login: String
Senha: Double
Classe responsável por encapsular os atributos do objeto Acesso,
herda os atributos da Classe Funcionário, porém armazena as
informações necessárias para conseguir acesso ao sistema.
(camada modelo).
Armazena o identificador do Funcionário, ligando com sua
respectiva tabela de informações da classe Funcionario.
Responsável pelo armazenamento de informação referente ao
login do usuário do sistema.
Responsável pelo armazenamento de informação referente a
senha necessária para logar no sistema.
MENSALIDADE
Esta 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
27
paga pelo aluno.
Mensalidade
Descrição
Atributos
ID: Int
DataUltimo: Data
DataVenc: Data
Classe responsável por encapsular os atributos do objeto
Mensalidade, guarda as informações das mensalidades pagas
pelo aluno.
Armazena o identificador do Aluno, ligando com sua respectiva
tabela de informações da classe Aluno.
Responsável pelo armazenamento de informação referente a
ultima data que foi paga a mensalidade.
Armazena a data do vencimento da mensalidade do aluno.
MEDIDA
Classe que depende da classe aluno para poder armazenar dados referentes às medidas do
aluno, podendo comparar assim a evolução da sua avaliação física no decorrer do tempo. Esta
classe armazena todos os dados utilizados pela academia para avaliar um aluno.
Acesso
Descrição
Atributos
ID: Int
Date : date
Braco: double
Tórax : double
Peso: double
Abdomem: double
Perna: Double
Classe responsável por encapsular os atributos do objeto
Medidas, herda os atributos da Classe aluno. Essa classe modela
todas as informações referente as medidas do aluno.
Armazena o identificador do Aluno, ligando com sua respectiva
tabela 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.
TAREFA
Uma classe utilizada pelo sistema para poder armazenar dados no banco de dados, para
controlar uma espécie de agenda diária. Contendo todos os compromissos agendados, e podendo
avisar ao usuário do sistema quando esse compromisso estiver por vencer. Compreende seus
atributos em Data, Hora, Descrição do evento ou compromisso.
28
Descrição
Atributos
nome: String
D: int
M: int
A: int
H: int
Min: int
fone: String
Id: int
Operações
Tarefa()
Tarefa
getID(): int
setID(n: int): void
getDia(): int
setDia(n: int): void
getMes(): void
setMes(n: int): int
getAno(): void
setAno(n: int): int
getHora(): int
setHora(n: int): void
getMin(): int
setMin(n: int): void
getNome(): String
SetNome(n: String):
void
getfone(): String
setfone(n: String):
void
Classe responsável por encapsular os atributos do Objeto tarefa e
pela criação das funções de manipulação das mesmas( camada
modelo).
Referente ao nome da tarefa definida pelo usuário.
Responsável pelo armazenamento de informação referente ao dia
do mês.
Responsável pelo armazenamento de informação referente ao
mês do ano.
Responsável pelo armazenamento de informação referente ao
ano.
Responsável pelo armazenamento de informação referente a hora
para realização da tarefa
Responsável pelo armazenamento de informação referente aos
minutos para completar o horário de realização da tarefa
Responsável pelo armazenamento de informação referente ao
telefone do cliente onde será realizada a obra
Responsável pelo armazenamento de informação referente ao
numero 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 da
tarefa).
Retorna o valor da variável referente ao nome da tarefa.
Seta o nome (altera o valor da variável referente ao nome da
tarefa).
Seta o fone (altera o valor da variável referente ao fone da
tarefa).
29
CAIXA
Classe utilizada pelo sistema, para gerenciar o caixa diário da empresa. Com todos as
entradas e saídas de capital do caixa. Podendo no final do dia apenas solicitar ao sistema o
30
fechamento do caixa, e conferindo se os saldos finais batem. Esta classe também é muito
importante para poder ter uma real visão do rendimento da academia.
Caixa
Descrição
Atributos
ID: Int
Date : date
Dinheiro: double
Cheque : double
Cartao: double
Classe responsável por encapsular os atributos do objeto Caixa,
armazena os movimentos de entrada e saída de capital
diariamente da empresa.
Armazena o identificador do Caixa;
Salva a data da realização da abertura do caixa;
Guarda as informações da referente ao montante de dinheiro que
está disponível em caixa.
Guarda as informações da referente ao montante de cheque que
está disponível em caixa.
Guarda as informações da referente ao montante de capital que
entrou por forma de cartão e que está disponível em caixa.
10 DIAGRAMAS DE SEQÜÊNCIAS
DIAGRAMA DE SEQÜÊNCIA ADICIONAR ALUNO / PRODUTO
Figura 3: Diagrama de seqüência adicionar aluno /produto.
Diagrama representa a seqüência e os devidos passos para adicionar um produto, um aluno e as
passagens 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 o
sistema com o intuito de adicionar um produto ou uma obra. A partir daí o sistema executa os
passos para completar a adição, seguindo pelo controlador, chegando ao modelo. Na camada de
modelo, são carregados os produtos ou obras cadastrados no banco de dados, em seguida é criado
31
o novo objeto produto ou obra e todos os itens são reinseridos no banco de dados. Assim
retornando até a visão o resultado sucesso ou falha da operação.
DIAGRAMA DE SEQÜÊNCIA ALTERAR PRODUTO / OBRA
Figura 4: Diagrama de seqüência alterar produto / aluno.
Diagrama representa a seqüência e os devidos passos para alterar um produto ou aluno e as
passagens 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 o
sistema com o intuito de alterar um produto ou uma obra já cadastrado. A partir daí o sistema
executa 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, em
seguida é localizado o produto ou obra a ser alterado, alteram-se os dados e todos os itens são
reinseridos no banco de dados. Assim retornando até a visão o resultado sucesso ou falha da
operação.
DIAGRAMA DE SEQÜÊNCIA EXCLUIR PRODUTO / ALUNO
32
Figura 4: Diagrama de seqüência excluir produto / obra.
Diagrama representa a seqüência e os devidos passos para excluir um produto ou obra e as
passagens 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 o
sistema com o intuito de excluir um produto ou uma obra já cadastrado. A partir daí o sistema
executa os passos para completar a exclusão, seguindo pelo controlador. Em seguida é localizado
o 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 PATTERN
Existem 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 previamente
experimentadas e testadas;
3.
O problema tratado por um padrão deve ocorrer em diferentes contextos, ou seja, se a
soluçã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 e
estruturas existentes nos sistemas;
5.
Os padrões de projeto devem ser capazes de capturar a evolução e o aprimoramento das
soluções, assim como equilibrar os pontos fortes e fracos encontrados, sendo assim, não são
soluções óbvias ou triviais;
6.
Os padrões devem ser utilizados em conjunto com outros padrões, compondo uma
linguagem de padrões.
33
Existem 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 é um
pattern 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 de
projetos, escolhemos o padrão "Builder", pois permite a separação da construção de um objeto
complexo da sua representação, de forma que o mesmo processo de construção possa criar
diferentes representações. Segundo o livro "Design Patterns: Elements of Reusable ObjectOriented 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 a
representação que cria e fornece interface para recuperação do produto;
•
product — o objeto complexo em construção. Inclui classes que definem as parte
constituintes.
Figura 1: Exemplo Builder
Basicamente visamos desenvolver algumas características desse padrão de projeto do
ponto de vista que um processo possa criar diferentes representações, um exemplo disso seria a
nossa 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 uma
ferramenta extra muito útil nas situações do dia-a-dia, e certamente facilitará a vida de quem os
conhece.
12 ARQUITETURA
Utilizamos 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 estes
poderão ser reorganizados sem alterar a interface. Esta arquitetura trabalha na separação das
tarefas de acesso aos dados e lógica de negócio, lógica de apresentação e de interação com o
utilizador, Introduzindo um componente entre os dois: o controlador (controller).
34
É exatamente isto que queremos para o nosso sistema a separação desses fatores, pois diferentes
interfaces 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 e
migrações com essas especificações do que em um sistema sem arquitetura.
13 TESTES
Para avaliar os casos de testes utilizamos o método da caixa preta "Particionamento de
equivalência" pois divide o domínio de entrada de um programa em classe de dados a partir das
quais os casos de teste podem ser derivados. O particionamento de equivalência procura definir
um caso de teste que descubra classes de erros, assim reduzindo o número total de casos de teste
que devem ser resolvidos o que facilita o desempenho do desenvolvimento do sistema tendo em
vista que nossa equipe utiliza metodologia ágil XP. Baseia-se numa avaliação de classes de
equivalência para uma condição de entrada. Uma classe de equivalência representa um conjunto
de estados válidos ou inválidos para condições de entrada. Alem disso faremos verificações
periódicas no código do sistema para tentar evitar possíveis erros de implementação e focar a
implementaçã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 realizar
os casos de testes, estes casos de testes são baseados nos casos de uso e nos requisitos do sistema.
CT - 01
Tarefa
Cadastrar um Aluno.
Importância
Essencial.
Objetivo
Cadastrar um aluno no sistema.
Pré-Condição
Usuário logado no sistema.
Dados
Teste
ID = identificador válido {Id do produto, Integer >0 e único}
do
Nome = nome válido { Nome do produto, String não nula}
Telefone = valor válido { String não nula, Length > 9}
Descrição
Cenário Principal:
1.
2.
3.
4.
Após o usuário passar os dados do aluno.
O sistema deverá validar todas as informações
Retorno de mensagem de sucesso.
Sistema será redirecionado a tela principal.
Cenário Secundário:
1.
2.
3.
Após o sistema verificar os dados do aluno;
O sistema retornará uma mensagem de erro;
A operação ficará em espera até corrigir os erros ou
35
Forçar saída do sistema.
Resultados
Fluxo Principal: Aluno cadastrado com sucesso.
Fluxo Alternativo 1: Algum campo inválido ou vazio: O sistema
indica que se encontra o erro.
CT - 02
Tarefa
Alterar dados de um aluno.
Importância
Essencial.
Objetivo
Gerenciar as informações do aluno no sistema.
Pré-Condição
Usuário logado no sistema.
Dados
Teste
ID = identificador válido {Id do produto, Integer >0 e único}
do
Nome = nome válido { Nome do produto, String não nula}
Telefone = valor válido { String não nula, Length > 9}
Descrição
Cenário Principal:
1.
2.
3.
4.
Após o usuário alterar os dados do aluno.
O sistema deverá validar todas as informações
Retorno de mensagem de sucesso.
Sistema será redirecionado a tela principal.
Cenário Secundário:
1.
2.
3.
Após o sistema verificar os dados do aluno;
O sistema retornará uma mensagem de erro;
A operação ficará em espera até corrigir os erros ou
Forçar saída do sistema.
Resultados
Fluxo Principal: Alteração do aluno já cadastrado.
Fluxo Alternativo 1: Algum campo inválido ou vazio: O sistema
indica que se encontra o erro.
CT - 03
Tarefa
Cadastrar um produto.
Importância
Essencial.
36
Objetivo
Cadastrar um produto no sistema.
Pré-Condição
Usuário logado no sistema.
Dados
Teste
ID = identificador válido {Id do produto, Integer >0 e único}
do
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ão
nula}
QuantidadeTotal = valor válido{Valor da quantidade, Double >
0,00}
Estoque Mínimo = valor válido{Valor da quantidade_minima,
Double > 0,00}
Descrição
Cenário Principal:
1.
2.
3.
4.
Após o usuário passar as informações do produto.
O sistema deverá validar todas as informações
Retorno de mensagem de sucesso.
Sistema será redirecionado a tela principal.
Cenário Secundário:
1.
2.
3.
Após o sistema verificar os dados do produto;
O sistema retornará uma mensagem de erro;
A operação ficará em espera até corrigir os erros ou
Forçar saída do sistema.
Resultados
Fluxo Principal: Produto cadastrado.
Fluxo Alternativo 1: Algum campo inválido ou vazio: O sistema
indica que se encontra o erro.
CT - 04
Tarefa
Gerenciar produto.
Importância
Importante.
Objetivo
Procura por produtos já cadastrados e exibi suas informações na
tela, permiti modificações em qualquer campo de informação
além de exclusão do produto.
Pré-Condição
Produto deve estar cadastrado no sistema e o usuário deve
estar devidamente logado de acordo com seu privilégio no
sistema.
Dados
Teste
ID = identificador válido {Id do produto, Integer >0 e único}
do
37
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ão
nula}
QuantidadeTotal = valor válido{Valor da quantidade, Double >
0,00}
Estoque Mínimo = valor válido{Valor da quantidade_minima,
Double > 0,00}
Descrição
Cenário Principal:
1. Após o usuário alterar os dados do produto.
2. O sistema deverá validar todas as informações
3. 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 ou
Forçar saída do sistema.
Resultados
Fluxo Principal: Produto alterado ou excluído.
Fluxo Alternativo 1: Algum campo inválido ou vazio ou: O
sistema indicara que se encontra o erro.
Fluxo Alternativo 2: Produto inexistente: O sistema indicara que
o produto não consta cadastrado no sistema.
CT - 05
Tarefa
Agendar Tarefa.
Importância
Essencial.
Objetivo
Agendar uma Tarefa no sistema.
Pré-Condição
Usuário logado no sistema.
Dados
Teste
Ano = ano válido { >2000 }
Mês = mês válido { 1 à 12}
Dia = dia válido { 1 à 30}
do
38
Hora = hora válida { 0 à 23}
Tarefa = tarefa válida {Nome da tarefa, String não nula}
Descrição
1. 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 um
duplo 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 a
ação;
6. Será retornado a mensagem de Erro ou sucesso;
Resultados
Fluxo Principal: tarefa agendada.
Fluxo Alternativo 1: campo tarefa vazio: o sistema indicara por
meio de aviso para o usuário especificar a tarefa agendada.
CT - 06
Tarefa
Gerenciar Tarefa.
Importância
Importante.
Objetivo
Gerenciar uma tarefa já agendada no sistema.
Pré-Condição
Tarefa já agendada no sistema.
Dados
Teste
Ano = ano válido { >2000 }
Mês = mês válido { 1 à 12}
Dia = dia válido { 1 à 30}
do
Hora = hora válida { 0 à 23}
Tarefa = tarefa válida {Nome da tarefa, String não nula}
Descrição
1. 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 um
clique 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
39
faz a modificação;
7. Mensagem retorno Falha/Sucesso.
Resultados
Fluxo Principal: Gerenciamento das tarefas já cadastradas.
CT - 07
Tarefa
Cadastro de funcionário
Importância
Essencial.
Objetivo
Cadastrar um funcionário no sistema, para que este possa ter
suas informações tais como salário e comissões gerenciados
pelo sistema.
Pré-Condição
Usuário logado no sistema e este usuário ser um gerente, ou
administrador do sistema.
Dados
Teste
Nome = nome válido { Nome da funcionário, String não nula}
do
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ção
1. 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 os
funcioná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;
Resultados
CT - 08
Fluxo Principal: Funcionário cadastrado.
40
Tarefa
Gerencia de funcionário
Importância
Essencial.
Objetivo
Gerencia dos funcionário no sistema, para que este possa ter
suas informações tais como salário e comissões gerenciados
pelo sistema.
Pré-Condição
Usuário logado no sistema e este usuário ser um gerente, ou
administrador do sistema.
Dados
Teste
Nome = nome válido { Nome da funcionário, String não nula}
do
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ção
1. 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 os
funcionários cadastrados no sistema;
4. O usuário deve Selecionar na tabela o funcionário que deseja
modificar ou excluir;
5. O sistema enviará uma mensagem de confirmação;
6. Se sua opção foi modificar aparecera uma janela com os
campos de informação do funcionário então pode altera-los e
submeta a ação;
7. Será retornado a mensagem de Erro ou sucesso;
Resultados
Fluxo Principal: Funcionário Excluído/Modificado..
CT - 9
Tarefa
Cadastro de Usuário
Importância
Essencial.
41
Objetivo
Cadastrar um usuário no sistema, sómente cadastrado seu login
e senha um funcionário se tornará usuário e poderá utilizar o
sistema.
Pré-Condição
Usuário logado no sistema, e este usuário ser um gerente.
Dados
Teste
Nome = nome válido { Nome da funcionário, String não nula}
do
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 ou
Vendedor”}
Descrição
1. 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 ser
preenchidos
4. O usuário deve preencher todos os campos pois são
obrigatórios
5. 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ário
correspondente a este login;
7. Será retornado a mensagem de Erro ou sucesso;
Resultados
Fluxo Principal: usuário cadastrado.
CT - 10
Tarefa
Gerencia de Usuário
Importância
Essencial.
Objetivo
Gerencia dos Usuário
segurança do sistema.
Pré-Condição
Usuário logado no sistema, e este usuário ser um gerente.
Dados
Teste
User = nome de usuário válido { Usuário válido, String Length >
2}
do
no
sistema,
garantir
integridade
Senha = Senha válida {Senha válida, String Length > 5}
Descrição
1. O usuário inicia o menu Gerencia;
e
42
2. O usuário escolhe o item Controle de Usuário;
3. O sistema abre uma janela com alguns campos a ser
preenchidos
4. O usuário deve preencher os campos de login e senha e
depois clicar no botão alterar;
5. Se usuário e senha válido, então será liberado a modicar o
login no sistema;
6. Será retornado a mensagem de Erro ou sucesso;
Resultados
Fluxo Principal: Alterar login do funcionário;
43
CONCLUSÃO
Este documento tem como meta fornecer uma modelagem para o sistema proposto
inicialmente: um sistema de apoio à empresa, academia de ginástica e musculação SportLife. Esta
modelagem baseada em orientação a objetos tornou o processo de desenvolvimento do software
mais ágil, prático e de melhor entendimento a todos os membros da equipe, pois todos os passos
foram seguidos por dicas e informações do cliente.
Assim, com esta documentação foram esclarecidos e objetivados todos os requisitos
necessários para a satisfação da empresa-cliente.
44
Apêndice A – Coleta de Informações
Ao identificar a necessidade de um sistema para gerenciamento da academia A coleta de
informações baseou-se em entrevistas com o dono da empresa a academia SportLife, o senhor
Alain Camargo. A partir do primeiro contato, explanou o funcionamento básico do ambiente
organizacional da empresa. Já nas demais entrevistas, foram necessárias algum questionamento
sobre 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ção
todas 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 e
implantação do sistema na empresa.
45
Apêndice B.
1Como o sistema exigiu da equipe algumas melhoras nos feedbacks, tais como alteração das
telas. Melhor gerenciamento da barra de menus. Isso trouxe em alguns esforços não previstos no
cronograma. E também algumas das iterações do sistema, não foram seguidas conforme previstas no
cronograma do projeto. Pois a necessidade do cliente nos fez rever algumas das etapas e antecipa-las
deixando as previstas como segundo plano.
Temos isso não visto na questão de LOGIN DO SISTEMA que era uma etapa prevista para a
data de 06/08, mas foi antecipado para as primeiras etapas para poder controlar o fluxo dos usuários
que já usavam a versão beta do sistema.
Uma outra etapa antecipada foi CONTROLE DO CAIXA, pois temos a necessidade que o
cliente 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 requisito
do cliente.
2-
Com a implantação do sistema e seu uso diário, tivemos muita dificuldade em conseguir
que o DB4O, se mantivesse estável. Houve muitas quebras de informações e também a
performance do sistema já estava ficando comprometida. Com essas dificuldades foi sugerido
migrar 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 do
projeto, houve um atraso considerável no cronograma, mas garantimos uma qualidade melhor do
sistema em si. Veja o anexo do novo cronograma.
46
Anexo Cronograma
Descrição
1
Treinamento e
Obtenção dados
Previsão
(Semanas)
Data
início
1
02/07
2
Telas Iniciais
2
16/07
3
Cadastro Aluno
1
23/07
4
Utilização Webcam
1
30/07
5
Login/ Criptografia
1
06/08
6
Funcionários/Salários
1
13/08
7
Usuários
1
20/08
8
Avaliação
1
27/08
9
Avaliação + Anaminse
1
04/09
10
Modalidades
1
11/09
11
Integridade Do Banco
De Dados
1
18/09
12
Back UP
1
25/09
13
Agenda Contatos
1
02/10
14
Agenda Tarefas
1
09/10
15
Controle Alunos
1
16/10
16
Controle Do Acesso
1
23/10
17
Abertura E Restrição
das Mensalidades
1
30/10
18
Caixa
1
14/11
19
Migração do SGBD Para
PostGress
2
21/11
20
Revisão e Testes
2
05/12
47
FORMULÁRIO DO RELATÓRIO DA EQUIPE
Nome
Hudson João Magalhães
Lucas da Silva Grando
Contribuição
Assinatura
50%
_____________________________________
50%
_____________________________________