UNIOESTE - Universidade Estadual do Oeste do Paraná CCET - Centro de Ciências Exatas e Tecnológicas Colegiado de Informática
Curso de Bacharelado em Informática
PROJETO DA DISCIPLINA
PES II – Processo de Engenharia de Software II
CASCAVEL 2009
2 Alessandro Rodrigo Franco
Fernando Luiz Grando Fernando Martins
SISTEMA - FARMÁCIA
Parte 02 - Projeto Orientado a Objetos
Professor: Victor Francisco Araya Santander
CASCAVEL 2009
3 ÍNDICE
1 – Introdução ...04
2 – Arquitetura do Sistema ...05
3 – Padrões de Projeto ...06
4 – Descrição dos Diagramas ...07
4.1 – Diagrama de Classes ...07
4.2 – Diagrama de Seqüência ...09
4.3 – Diagrama de Entidade Relacionamento ...13
5 – Política e Estratégias de Testes ...19
5.1 – Casos de Teste ...19
6 – Figuras ...32
Figura 1: Diagrama de Classes ...32
Figura 2.1 – 2.15: Diagramas de Seqüência ...34
Figura 3: Modelagem BD – Modelo Lógico ...………...…...42
Figura 4: Modelagem BD – Modelo Conceitual ...43
7 – Conclusão ...44
8 – Apêndice A: Detalhes dos Casos de Teste ...45
9 – Apêndice B: Formulário de Relatório da Equipe ...51
4 1 – INTRODUÇÃO
Um sistema consistente, confiável e de fácil uso depende muito de um projeto que seja bem elaborado. Inicialmente será definida a arquitetura de software, que consiste dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares. Após isso mostraremos quais Padrões de Projeto (Design Patterns) serão usados. Eles descreverão soluções para problemas recorrentes no desenvolvimento do sistema. A modelagem UML será utilizada e mostrada nos Diagramas de Classe, de Seqüência e de Estados. Por fim, mostraremos a modelagem do Banco de Dados e as estratégias que serão usadas para os testes.
Pretende-se, então, através desse projeto especificar toda a documentação necessária para a fase de implementação do sistema.
5 2 – ARQUITETURA DO SISTEMA
A arquitetura de um sistema consiste dos componentes de software, suas propriedades externas, e seus relacionamentos com outros softwares.
2.1 – MVC (Model View Controller)
O âmago da arquitetura do nosso sistema está em 3 camadas (Model View Controller) distintas, cada uma com suas funções descritas a seguir:
Model:
Nesta camada está o coração da aplicação, nela estarão implementadas todas as classes responsáveis pelo o que a aplicação irá fazer (classes de armazenamento, manipulação e geração dos dados). Nesta camada teremos implementados 3 padrões de projeto (explicados no item 3).
View:
Nesta camada estão as classes que só se preocupam em exibir as informações, desta forma, alterações nesta camada não afetarão a manipulação de dados.
Nesta camada teremos implementado 1 padrão de projeto chamado de Mediator. Neste padrão toda a comunicação entre objeto é encapsulada com um objeto mediator, reduzindo a dependência entre os objetos que estão se comunicando.
Controller:
Nesta camada estão implementadas as classes que determinarão o fluxo da View servindo como uma camada intermediária entre a camada View e a camada Model.
A arquitetura foi escolhida caso o cliente queira outros visualizadores no futuro, e usando o mesmo modelo será fácil mantê-lo, testá-lo e atualizá-lo. Outra vantagem é que a aplicação se torna escalável. A principal vantagem é que é possível ter o desenvolvimento em paralelo para o modelo, visualizador e controle, pois são independentes.
6 3 – PADRÕES DE PROJETO
Os padrões de projeto de software descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências. Em nosso sistema utilizaremos os seguintes padrões de projeto:
3.1 - Padrão DAO
O padrão Data Acess Object (DAO) permite maior capacidade e flexibilidade ao conceito de entidade através da abstração do mecanismo de persistência da aplicação. Este padrão será utilizado na persistência de todos os modelos.
3.2 - Padrão Factory
O padrão Factory fornece uma interface para a criação de famílias de objetos correlatos ou dependentes sem a necessidade de especificar a classe concreta destes objetos. Este padrão de projeto será utilizado nas regras de cada modelo, e na criação dos DAO.
3.3 - Padrão Singleton
O padrão Singleton permite somente uma instância de um objeto. Utilizado para controlar as instâncias dos DAO´s.
7 4 – DIAGRAMAS
4.1 – Diagrama de Classes Figura 1.
4.1.1 - Interface DAO
Todas as classes que serão armazenadas no Banco de Dados, deverão implementar a interface DAO. Os métodos são:
-public boolean cadastrar(Object o): Este método deve implementar a inserção do objeto na base de dados.
-public boolean remover(Object o): Este método deve implementar a remoção do objeto na base de dados.
-public boolean editar(Object o): Este método deve implementar a edição do objeto na base de dados.
-public boolean localizar(Object o): Este método deve implementar a localização de objetos semlhantes na base de dados.
4.1.2 - Classes Abstratas
Essas classes implementam a interface DAO, no entanto não implementam os métodos da interface DAO. Os atributos necessários são o atributo de conexão com o banco de dados, o atributo de para execução de comando SQL e o atributo DAO estático para o padrão Singleton, são elas as classes: FuncionárioDAO LoginDAO PessoaDAO ChequeDAO VendaDAO ProdutoDAO ClienteDAO PagamentoDAO
8 4.1.3 - Classes que implementam os acessos a base de dados usando o sistema gerenciador de banco de dados JDBC
Essas classes são uma extensão das classes abstratas descritas acima e implementam o acesso a base de dados utilizando o sistema gerenciador de banco de dados JDBC. Sendo que os construtores das classes criarão uma conexão no banco de dados para à instância da classe. Os métodos da interface DAO são implementados e o método public DAO getInstancia utilizado para que haja apenas uma instância da classe ativa (padrão Singleton). São estas as classes:
JdbcFuncionárioDAO JdbcLoginDAO JdbcPessoaDAO JdbcChequeDAO JdbcVendaDAO JdbcProdutoDAO JdbcClienteDAO JdbcPagamentoDAO 4.1.4 - DAOFactory
É a fábrica dos DAO’s, padrão Factory, nela o parâmetro BANCO indica o SGBD que está sendo utilizado. Os métodos servem para retornar os DAO’s e são abstratas.
4.1.5 - JdbcDAOFactory
É uma extensão da DAOFactory onde as funções da DAOFactory são implementadas para o sistema gerenciador de banco de dados JDBC. Os métodos são:
-public Connection criaConexao(): Este método cria e retorna a conexão com a base de dados.
-public JdbcClienteDAO getClienteDAO(): Este método retorna uma instância da classe ClienteDAO.
9 -public JdbcPessoaDAO getPessoaDAO(): Este método retorna uma instância da classe PessoaDAO.
-public JdbcFuncionarioDAO getFuncionarioDAO(): Este método retorna uma instância da classe FuncionarioDAO.
-public JdbcProdutoDAO getProdutoDAO(): Este método retorna uma instância da classe ProdutoDAO.
-public JdbcVendaDAO getVendaDAO(): Este método retorna uma instância da classe VendaDAO.
-public JdbcChequeDAO getChequeDAO(): Este método retorna uma instância da classe ChequeDAO.
-public JdbcPagamentoDAO getPagamentoDAO(): Este método retorna uma instância da classe PagamentoDAO.
-public JdbcLoginDAO getLoginDAO(): Este método retorna uma instância da classe LoginDAO.
4.2 – Diagrama de Seqüência
4.2.1 – Login (Figura 2.1)
- O Controlador busca a regra login funcionário na RegraFactory. - O Controlador executa a regra login funcionário.
- A RegraLoginFuncionario pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o login da fabrica JDBC. - Login concluído.
4.2.2 - Regra Factory (Figura 2.2)
- O Controlador busca a regra na RegraFactory. - O Controlador executa a regra.
4.2.3 – Mediator (Figura 2.3)
- View cria componentes em componentes.
- Componentes registra os componentes em Mediator. - Componentes trata o evento em Mediator.
10 - Mediator atualiza View em View.
4.2.4 – Cadastrar Cliente (Figura 2.4)
- O Controlador busca a regra cadastrar cliente na RegraFactory. - O Controlador executa a regra cadastrar cliente.
- A regra cadastrar cliente pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o ClienteDAO da fabrica JDBC. - Cadastra o cliente.
4.2.5 – Editar Cliente (Figura 2.5)
- O Controlador busca a regra editar cliente na RegraFactory. - O Controlador executa a regra editar cliente.
- A regra editar cliente pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o ClienteDAO da fabrica JDBC. - Edita o cliente.
4.2.6 – Localizar Cliente (Figura 2.6)
- O Controlador busca a regra localizar cliente na RegraFactory. - O Controlador executa a regra localizar cliente.
- A regra localizar cliente pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o ClienteDAO da fabrica JDBC. - Localiza o cliente.
4.2.7 – Remover Cliente (Figura 2.7)
- O Controlador busca a regra remover cliente na RegraFactory. - O Controlador executa a regra remover cliente.
- A regra remover cliente pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o ClienteDAO da fabrica JDBC. - Remove o cliente.
11 4.2.8 – Cadastrar Funcionário (Figura 2.8)
- O Controlador busca a regra cadastrar funcionário na RegraFactory. - O Controlador executa a regra cadastrar funcionário.
- A regra cadastrar funcionário pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o FuncionarioDAO da fabrica JDBC. - Cadastra o funcionário.
4.2.9 – Editar Funcionário (Figura 2.9)
- O Controlador busca a regra editar funcionário na RegraFactory. - O Controlador executa a regra editar funcionário.
- A regra editar funcionário pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o FuncionarioDAO da fabrica JDBC. - Edita o funcionário.
4.2.10 – Localizar Funcionário (Figura 2.10)
- O Controlador busca a regra localizar funcionário na RegraFactory. - O Controlador executa a regra localizar funcionário.
- A regra localizar funcionário pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o FuncionarioDAO da fabrica JDBC. - Localiza o funcionário.
4.2.11 – Remover Funcionário (Figura 2.11)
- O Controlador busca a regra remover funcionário na RegraFactory. - O Controlador executa a regra remover funcionário.
- A regra remover funcionário pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o FuncionárioDAO da fabrica JDBC. - Remove o funcionário.
12 4.2.12 – Cadastrar Produto (Figura 2.12)
- O Controlador busca a regra cadastrar produto na RegraFactory - O Controlador executa a regra cadastrar produto.
- A regra cadastrar produto pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o FuncionarioDAO da fabrica JDBC. - Cadastra o produto.
4.2.13 – Editar Produto (Figura 2.13)
- O Controlador busca a regra editar produto na RegraFactory. - O Controlador executa a regra editar produto.
- A regra editar produto pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o FuncionarioDAO da fabrica JDBC. - Edita o produto.
4.2.14 – Localizar Produto (Figura 2.14)
- O Controlador busca a regra localizar produto na RegraFactory. - O Controlador executa a regra localizar produto.
- A regra localizar produto pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o FuncionarioDAO da fabrica JDBC. - Localiza o produto.
4.2.15 – Remover Produto (Figura 2.15)
- O Controlador busca a regra remover produto na RegraFactory. - O Controlador executa a regra remover produto.
- A regra remover produto pega a fabrica JDBC em DAOFactory. - DAOFactory cria a fabrica JDBC.
- Pega o ProdutoDAO da fabrica JDBC. - Remove o produto.
13 JdbcChequeDAO, JdbcVendaDAO, JdbcPagamento é idêntico ao das classes JdbcFuncionárioDAO, JdbcClienteDAO e JdbcProdutoDAO que foram descritas neste item, e representadas através das Figuras 2.1 até 2.15 mostradas no item 6.
4.3 – Diagrama de Entidade Relacionamento
4.3.1 - Modelo Lógico Figura 3.
4.3.1.1 – Descrição do Modelo Lógico
Pessoa. Na tabela pessoa temos a chave CPF e RG que realiza a identificação de cada pessoa. A tabela pessoa tem a seguinte composição:
CPF: campo do tipo varchar com até 12 caracteres para o CPF da pessoa.
RG: campo do tipo varchar com até 32 caracteres para o RG da pessoa.
Nome: campo do tipo varchar com até 128 caracteres para o nome da pessoa.
Telefone: campo do tipo varchar com até 12 caracteres com o telefone da pessoa.
Nascimento: campo do tipo data para a data de nascimento da pessoa.
Sexo: campo do tipo inteiro com 1 caracter para o sexo da pessoa.
Celular: campo do tipo varchar com até 12 caracteres com o telefone celular da pessoa.
Cliente. Na tabela Cliente temos a chave CodigoCliente que serve para a identificação do cliente, e as chaves CPF e RG que são herdadas da tabela pessoa. A tabela cliente tem a seguinte composição:
CPF: campo do tipo varchar com até 12 caracteres para o CPF do cliente.
RG: campo do tipo varchar com até 32 caracteres para o RG do cliente.
Status: campo do tipo inteiro com até 11 caracteres para o status do cliente na farmácia.
SaldoGasto: campo do tipo double para a quantidade gasta pelo cliente.
CodigoCliente: campo do tipo inteiro com até 10 caracteres para o código de identificação do cliente.
14
SaldoDevedor: campo do tipo double para o que o cliente deve na farmácia.
Entrada: campo do tipo data para a data de cadastro do cliente.
Funcionário. Na tabela Funcionário temos a chave CodigoFuncionario que realiza a identificação do funcionário e as chaves estrangeiras que são herdadas da tabela pessoa. A tabela funcionário tem a seguinte composição:
CPF: campo do tipo varcchar com até 12 caracteres para o CPF da pessoa.
RG: campo do tipo varchar com até 32 caracteres para o RG da pessoa.
Admissao: campo do tipo data para a data de início das atividades do funcionário na farmácia.
Permissao: campo do tipo inteiro com até 11 caracteres para o tipo privilégios de cada funcionário.
Observação: campo do tipo varchar com até 128 caracteres para a observação sobre o funcionário.
Salário: campo do tipo double para o salário do funcionário.
CodigoFuncionario: campo do tipo inteiro com até 10 caracteres para o código de identificação do funcionário.
Data. Data da realização da operação. A tabela data tem a seguinte composição:
Dia: dia com 2 dígitos.
Mês: mês com 2 dígitos.
Ano: ano com 4 dígitos.
Produto. Na tabela Produto temos a chave com o CodigoProduto e o Nome que serve para identificação do produto. A tabela produto tem a seguinte composição:
Nome: campo do tipo varchar com até 32 caracteres para o nome do produto.
CodigoProduto: campo do tipo inteiro com até 10 caracteres para o código do produto.
Lote: campo do tipo varchar com até 32 caracteres para o lote do produto.
DataFabricacao: campo do tipo data para a data de fabricação do produto.
DataVencimento: campo do tipo data para a data de validade do produto.
15
PrecoVenda: campo do tipo double para o preço de venda do produto.
Fornecedor: campo do tipo varchar com até 32 caracteres para o nome do fornecedor do produto.
Tarja: campo do tipo inteiro com até 11 caracteres para o tipo da tarja do produto.
Observação: campo do tipo varchar com até 128 caracteres para a observação sobre o produto.
Quantidade: campo do tipo inteiro com até 11 caracteres para a quantidade de produtos.
Venda. Na tabela Venda temos a chave com o CodigoVenda que identifica a venda. Podemos rastrear qual cliente fez a compra, qual funcionário realizou a venda e qual a forma de pagamento utilizada, através das chaves estrangeiras CodigoCliente, CodigoFuncionario e CodigoPagamento. A tabela Venda tem a seguinte composição:
CodigoVenda: campo do tipo inteiro com até 10 caracteres para o código de identificação de venda.
CodigoCliente: campo do tipo inteiro com até 10 caracteres para o código de identificação de cliente.
CodigoFuncionario: campo do tipo inteiro com até 10 caracteres para o código de identificação de funcionário.
CodigoPagamento: campo do tipo inteiro com até 10 caracteres para o código de identificação de pagamento.
Data: campo do tipo data para data da venda.
Valor: campo do tipo double para o valor da venda.
Cheque. No cheque temos a chave como a conta do cliente e número do cheque. Isso garante a unicidade do registro. Depois podemos rastrear em qual venda, pagamento ou qual cliente emitiu o cheque através das chaves estrangeiras CodigoVenda, CodigoPagamento e CodigoCliente. A tabela cheque tem a seguinte composição:
Conta: campo do tipo varchar com até 45 caracteres para a conta a que o cheque está vinculado.
16
Número: campo do tipo varchar com até 45 caracteres para o número do cheque.
CodigoPagamento: campo do tipo inteiro com até 10 caracteres para o código de pagamento.
CodigoVenda: campo do tipo inteiro com até 10 caracteres para o código de venda.
CodigoCliente: campo do tipo inteiro com até 10 caracteres para o código do cliente.
Validade: campo do tipo data para a validade do cheque.
Valor: campo do tipo double para o valor do cheque.
Pagamento. No pagamento temos a chave CodigoPagamento que identifica o pagamento e através de CodigoVenda podemos rastrear de qual venda foi o pagamento.
CodigoPagamento: campo do tipo inteiro com até 10 caracteres par ao código de pagamento.
CodigoVenda: campo do tipo inteiro com até 10 caracteres para o código de venda.
Status: campo do tipo inteiro com até 11 caracteres para o status de pagamento.
Tipo: campo do tipo inteiro com até 11 caracteres para o tipo de pagamento.
Data: campo do tipo data para a data do pagamento.
Valor: campo do tipo double para o valor do cheque.
Login. No login temos as chaves login e senha que são necessárias para a identificação do funcionário no sistema.
- Login: campo do tipo varchar com até 32 caracteres para o nome de usuário do funcionário.
- Senha: campo do tipo varchar com até 32 caracteres para a senha do usuário.
- CodigoFuncionario: campo do tipo inteiro com até 10 caracteres para o código de identificação de funcionário.
17 Relacionamentos “um-para-um” Cheque – Venda; Venda – Pagamento; Cheque – Pagamento. Funcionário – Login. Relacionamentos “um-para-muitos” Pessoa – Cliente; Pessoa – Funcionário; Cliente – Cheque; Cliente – Venda; Funcionário – Venda; Funcionário – Produto. 4.3.2 - Modelo Conceitual Figura 4.
4.3.2.1 – Descrição Modelo Conceitual
Pessoa. Representa um cliente ou funcionário da farmácia e é composta pelos seguintes atributos: CPF, RG, Nome, Telefone, Nascimento, Sexo, Celular.
Venda. Representa a venda de produtos na farmácia com os seguintes atributos: CodigoVenda, Data, Valor.
Cliente. Representa um cliente que fez alguma compra na farmácia e é composto pelos seguintes atributos: Status, SaldoGasto, CodigoCliente, SaldoDevedor, Entrada.
Funcionário. Representa um funcionário da farmácia e é composto pelos seguintes atributos: Admissao, Permissao, Observacao, Salario, CodigoFuncionario.
Pagamento. Representa um pagamento realizado por um cliente e é composto pelos seguintes atributos: Status, Tipo, Valor, CodigoPagamento, Data.
Cheque. Representa o cheque para realizar o pagamento e é composto pelos seguintes atributos: Validade, Valor, Numero, Conta.
18 seguintes atributos: PrecoVenda, DataVencimento, Observação, Nome, Quantidade, Lote, Tarja, DataFabricação, CódigoProduto, PreçoCusto, Fornecedor.
ItensVenda: Representa os itens selecionados durante uma determinada venda.
Composto pela quantidade de itens selecionados.
Data: Representação da data, composto por: dia, mês e ano.
Login: Representa a identificação do funcionário no sistema, através dos seguintes
atributos: login e senha.
Relacionamentos “um-para-um”.
Pagamento – Venda: Um pagamento recebe o valor de uma venda realizada Venda – ItensVenda: Uma venda contém os itens vendidos.
Cheque – Pagamento: Um cheque efetua um pagamento. Funcionário – Login: Um funcionário efetua um login.
Relacionamentos “um-para-muitos”.
Funcionário – Produto: Um funcionário tem o controle de zero ou mais produtos Funcionário – Venda: Um funcionário efetua zero ou mais vendas.
Cliente – Pagamento: Um cliente efetua zero ou mais pagamentos.
Cliente – Cheque: Um cliente submete zero ou mais cheques para realizar o pagamento. ItensVenda – Produto: A lista de ItensVenda é composta por um ou mais produtos.
19 5 – POLÍTICA E ESTRATÉGIAS DE TESTES
A atividade de teste de software é um elemento crítico da garantia de qualidade de software e representa a última revisão de especificação, projeto e codificação. Não é incomum que uma organização de software gaste 40% do esforço de projeto total em teste. Alguns casos dos quais dependam vidas humanas (por exemplo, controle de vôo), pode custar de 3 a 5 vezes mais que todos os outros passos de engenharia de software juntos.
Objetivos da Atividade de Teste:
1) A atividade de teste é o processo de executar um programa com a intenção de descobrir um erro.
2) Um bom caso de teste é aquele que tem uma elevada probabilidade de revelar um erro ainda não descoberto.
3) Um teste bem-sucedido é aquele que revela um erro ainda não descoberto.
Existem muitas maneiras de se testar um software. Os casos de teste foram desenvolvidos a partir da técnica Caixa-Preta, também chamada de teste funcional, orientado a dado ou orientado a entrada e saída. A técnica de Caixa Preta avalia o comportamento externo do componente de software, sem se considerar o comportamento interno do mesmo (MYERS, 2004).
Dados de entrada são fornecidos, o teste é executado e o resultado obtido é comparado a um resultado esperado previamente conhecido. Como detalhes de implementação não são considerados, os casos de teste são todos derivados da especificação, mais precisamente dos Casos de Uso Funcionais do documento de Especificação de Requisitos e Análise Orientada a Objetos.
5.1 – Casos de Teste
Formato do Caso de Teste.
- Os dados detalhados dos Casos de Teste se encontram no Apêndice A.
Identificador do Caso de Teste Título do Caso de Teste.
Importância Importância do Caso de Teste (Alta, média, baixa). Propósito Descrição do que se espera testar com o Caso de Teste.
20 de Teste.
Dados de Teste Variáveis e seus possíveis valores que serão usados no Caso de Teste. Especificados da seguinte forma = {correto, incorreto, nenhum}.
Passos Passos que serão executados no teste.
Notas Destacar algum ponto importante do Caso de Teste.
CT – 01 Cadastrar funcionário. Importância Alta.
Propósito O gerente pode Cadastrar funcionários. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Código do funcionário = {código do funcionário válido, código do funcionário inválido, sem código do funcionário}.
Permissão = {permissão válida, permissão inválida, sem permissão}. Data de nascimento = {data válida, data inválida, sem data}.
Data de admissão = {data válida, data inválida, sem data}. Telefone = {telefone válido, telefone inválido, sem telefone}. Celular = {celular válido, celular inválido, sem celular}. CPF = {CPF válido, CPF inválido, sem CPF}.
RG = {RG válido, RG inválido, sem RG}.
Salário = {salário válido, salário inválido, sem salário}. Sexo = {sexo válido, sexo inválido, sem sexo}.
Observação = {observação válida, observação inválida, sem observação}. Nome de usuário = {nome de usuário válido, nome de usuário inválido, sem nome de usuário}.
Senha = {senha válida, senha inválida, sem senha}. Passos 1- O gerente entra na seção Cadastrar funcionário.
21 criar, são elas: 0 (atendente), 1 (caixa), 2 (gerente).
3- O gerente adiciona os seguintes dados para Cadastrar o funcionário: nome do funcionário, RG, CPF, salário, data de nascimento, data de admissão, nome de usuário, senha, sexo.
4- O sistema adiciona um código para o funcionário.
5- O gerente adiciona opcionalmente os seguintes dados: telefone, celular, observação.
6- O gerente confirma o envio das informações.
7- O sistema informa a adição de um novo funcionário.
8- O gerente entra na seção Buscar funcionário e verifica que o funcionário foi cadastrado.
Notas
CT – 02 Remover funcionário. Importância Alta.
Propósito O gerente pode Remover funcionário. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente. O funcionário a ser excluído deve existir.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Passos 1- O gerente ingressa na seção Remover funcionário. 2- O gerente digita o nome do funcionário a ser excluído. 3- O gerente confirma a exclusão do funcionário.
4- O sistema informa a exclusão do funcionário.
5- O gerente ingressa na seção Buscar funcionário e verifica que o funcionário não existe.
Notas
22 Importância Alta.
Propósito O gerente pode Editar o funcionário. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente. O funcionário a ser alterado deve existir.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Passos 1- O gerente ingressa na seção Editar funcionário. 2- O gerente digita o nome do funcionário a ser alterado. 3- O gerente confirma a alteração do funcionário.
4- O sistema informa a alteração do funcionário.
5- O gerente ingressa na seção Buscar funcionário e verifica que o funcionário foi alterado.
Notas
CT – 04 Buscar funcionário. Importância Alta
Propósito O gerente pode Buscar o funcionário. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente.
O funcionário a ser consultado deve existir.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Passos 1- O gerente ingressa na seção Buscar funcionário.
2- O gerente digita o nome do funcionário a ser consultado. 3- O gerente realiza a consulta ao funcionário.
Notas
CT – 05 Cadastrar produto. Importância Alta
23 Propósito O gerente e o atendente podem Cadastrar produto.
Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou atendente.
Dados de Teste Nome do produto = {nome do produto válido, nome do produto inválido, sem nome do produto}.
Código do produto = {código do produto válido, código do produto inválido, sem código do produto}.
Fornecedor = {fornecedor válido, fornecedor inválido, sem fornecedor}. Lote = {lote válido, lote inválido, sem lote}.
Quantidade de produtos = {quantidade de produtos válida, quantidade de produtos inválida, sem quantidade de produtos}.
Data de fabricação = {data de fabricação válida, data de fabricação inválida, sem data de fabricação}.
Data de vencimento = {data de vencimento válida, data de vencimento inválida, sem data de vencimento}.
Preço de custo = {preço de custo válido, preço de custo inválido, sem preço de custo}.
Preço de venda = {preço de venda válido, preço de venda inválido, sem preço de venda}.
Observação = {observação válida, observação inválida, sem observação}. Tarja = {tarja válida, tarja inválida, sem tarja}.
Passos 1- O usuário entra na seção Cadastrar produto.
2- O usuário adiciona os seguintes dados para Cadastrar o produto: nome do produto, fornecedor, lote, quantidade de produtos, data de fabricação, data de vencimento, preço de custo, preço de venda, tarja. 3- O sistema adiciona um código para o produto.
4- O usuário adiciona opcionalmente os seguintes dados: observação. 5- O usuário confirma o envio das informações.
6- O sistema informa a adição de um novo produto
7- O usuário ingressa na seção Buscar produto e verifica que o produto foi cadastrado.
24 CT – 06 Remover produto.
Importância Alta
Propósito O gerente e o atendente podem Remover produto. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou atendente. O produto a ser excluído deve existir.
Dados de Teste Nome do produto = {nome do produto válido, nome do produto inválido, sem nome do produto}.
Passos 1- O usuário ingressa na seção Remover produto. 2- O usuário digita o nome do produto a ser excluído. 3- O usuário confirma a exclusão do produto.
4- O sistema informa a exclusão do produto.
5- O usuário ingressa na seção Buscar produto e verifica que o produto não existe.
Notas
CT – 07 Editar produto. Importância Alta
Propósito O gerente e o atendente podem Editar produto. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou atendente. O produto a ser alterado deve existir.
Dados de Teste Nome do produto = {nome do produto válido, nome do produto inválido, sem nome do produto}.
Passos 1- O usuário ingressa na seção Editar produto. 2- O usuário digita o nome do produto a ser alterado. 3- O usuário confirma a alteração do produto.
4- O sistema informa a alteração do produto.
5- O usuário ingressa na seção Buscar produto e verifica que o produto foi alterado.
25 Notas
CT – 08 Buscar produto. Importância Alta
Propósito O gerente e o atendente podem Buscar produto. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou atendente. O produto a ser consultado deve existir.
Dados de Teste Nome do produto = {nome do produto válido, nome do produto inválido, sem nome do produto}.
Passos 1- O usuário ingressa na seção Buscar produto.
2- O usuário digita o nome do produto a ser consultado. 3- O usuário realiza a consulta ao produto.
Notas
CT – 09 Cadastrar cliente. Importância Alta.
Propósito O gerente e o caixa podem Cadastrar cliente. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou caixa.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Código do cliente = {código do cliente válido, código do cliente inválido, sem código do cliente}.
Sexo = {sexo válido, sexo inválido, sem sexo}.
Data de nascimento = {data válida, data inválida, sem data}. Telefone = {telefone válido, telefone inválido, sem telefone}. Celular = {celular válido, celular inválido, sem celular}. CPF = {CPF válido, CPF inválido, sem CPF}.
26 Saldo gasto = {saldo gasto válido, saldo gasto inválida, sem saldo gasto}.
Saldo devedor = {saldo devedor válido, saldo devedor inválido, sem saldo devedor}.
Passos 1- O usuário entra na seção Cadastrar cliente.
2- O usuário adiciona os seguintes dados para Cadastrar o cliente: nome do cliente, CPF, RG, saldo gasto, saldo devedor, data de nascimento, sexo.
3- O sistema adiciona um código para o cliente.
4- O usuário adiciona opcionalmente os seguintes dados: telefone, celular, observação.
5- O usuário confirma o envio das informações. 6- O sistema informa a adição de um novo cliente.
7- O usuário entra na seção Buscar cliente e verifica que o cliente foi cadastrado.
Notas
CT – 10 Remover cliente. Importância Alta.
Propósito O gerente e o caixa podem Remover cliente. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou caixa. O cliente a ser excluído deve existir.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Passos 1- O usuário ingressa na seção Remover cliente. 2- O usuário digita o nome do cliente a ser excluído. 3- O usuário confirma a exclusão do cliente.
4- O sistema informa a exclusão do cliente.
5- O usuário ingressa na seção Buscar cliente e verifica que o cliente não existe.
27 CT - 11 Editar cliente.
Importância Alta.
Propósito O gerente e o caixa podem Editar cliente. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou caixa. O cliente a ser alterado deve existir.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Passos 1- O usuário ingressa na seção Editar cliente. 2- O usuário digita o nome do cliente a ser alterado. 3- O usuário confirma a alteração do cliente.
4- O sistema informa a alteração do cliente.
5- O usuário ingressa na seção Buscar cliente e verifica que o cliente foi alterado.
Notas
CT – 12 Buscar cliente. Importância Alta
Propósito O gerente e o caixa podem Buscar cliente. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou caixa. O cliente a ser consultado deve existir.
Dados de Teste Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}.
Passos 1- O usuário ingressa na seção Buscar cliente.
2- O usuário digita o nome do cliente a ser consultado. 3- O usuário realiza a consulta ao cliente.
28 CT – 13 Realizar Vendas.
Importância Alta
Propósito O gerente e o caixa podem realizar venda. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou caixa.
Dados de Teste Código da venda = {código da venda válido, código da venda inválido, sem código da venda}.
Data da venda = {data da venda válida, data da venda inválida, sem data da venda}.
Valor da venda = {valor da venda válido, valor da venda inválido, sem valor da venda}.
Dados do funcionário = {dados do funcionário válidos, dados do funcionário inválidos, sem dados do funcionário}.
Dados do pagamento = {dados do pagamento válidos, dados do pagamento inválidos, sem dados do pagamento}.
Dados do cliente = {dados do cliente válidos, dados do cliente inválidos, sem dados do cliente}.
Dados do produto = {dados do produto válidos, dados do produto inválidos, sem dados do produto}.
Quantidade de itens na venda = {quantidade de itens na venda válida, quantidade de itens na venda inválida, sem quantidade de itens na venda}. Passos 1- O usuário ingressa na seção Venda.
2- O usuário informa os dados do produto e a quantidade de itens na venda.
3- O usuário informa os dados do pagamento.
4- Caso o pagamento seja em cheque, o usuário verifica os dados do cliente e informa os dados do cheque.
5- O sistema informa o valor da venda.
6- O sistema inclui os dados do funcionário para a venda. 7- O sistema informa a data da venda.
8- O sistema adiciona um código para a venda. 9- O usuário realiza a venda.
29 CT – 14 Pagamento em dinheiro.
Importância Alta
Propósito O gerente e o caixa podem receber em dinheiro. Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou caixa.
Dados de Teste Dados da venda = {dados da venda válidos, dados da venda inválidos, sem dados da venda}.
Status do pagamento = {status do pagamento válido, status do pagamento inválido, sem status do pagamento}.
Código do pagamento = {código do pagamento válido, código do pagamento inválido, sem código do pagamento}.
Data do pagamento = {data do pagamento válida, data do pagamento inválida, sem data do pagamento}.
Tipo de pagamento = {tipo de pagamento válido, tipo de pagamento inválido, sem tipo de pagamento}.
Valor do pagamento = {valor do pagamento válido, valor do pagamento inválido, sem valor do pagamento}.
Passos 1- O usuário ingressa na seção Pagamento em dinheiro.
2- O sistema informa os dados da venda e o valor do pagamento. 3- O usuário informa o tipo de pagamento, em dinheiro.
4- O usuário informa o status do pagamento. 5- O sistema informa a data do pagamento.
6- O sistema adiciona um código para o pagamento. 7- O sistema realiza o pagamento.
Notas
CT – 15 Pagamento em cheque. Importância Alta
30 Pré-Condição O usuário deve estar identificado.
O usuário deve ser do tipo gerente ou caixa.
Dados de Teste Dados da venda = {dados da venda válidos, dados da venda inválidos, sem dados da venda}.
Dados do cliente = {dados do cliente válidos, dados do cliente inválidos, sem dados do cliente}.
Código do pagamento = {código do pagamento válido, código do pagamento inválido, sem código do pagamento}.
Data do pagamento = {data do pagamento válida, data do pagamento inválida, sem data do pagamento}.
Status do pagamento = {status do pagamento válido, status do pagamento inválido, sem status do pagamento}.
Tipo de pagamento = {tipo de pagamento válido, tipo de pagamento inválido, sem tipo de pagamento}.
Valor do pagamento = {valor do pagamento válido, valor do pagamento inválido, sem valor do pagamento}.
Dados do cheque = {dados do cheque válidos, dados do cheque inválidos, sem dados do cheque}.
Passos 1- O usuário ingressa na seção Pagamento em cheque.
2- O sistema informa os dados da venda e o valor do pagamento. 3- O usuário informa o tipo de pagamento, em cheque.
4- O sistema verifica os dados do cliente. 5- O usuário informa o status do pagamento. 6- O usuário informa os dados do cheque. 7- O sistema informa a data do pagamento.
8- O sistema adiciona um código para o pagamento. 9- O sistema realiza o pagamento.
Notas
CT – 16 Identificar-se no sistema. Importância Alta
31 Propósito O usuário pode ingressar no sistema.
Pré-Condição O usuário deve existir.
O usuário deve ser do tipo atendente, caixa ou gerente.
Dados de Teste Nome de usuário = {nome de usuário válido, nome de usuário inválido, sem nome de usuário}.
Senha = {senha válida, senha inválida, sem senha}. Passos 1- O usuário ingressa na seção de Login.
2- O sistema informa o nome de usuário. 3- O usuário informa a senha.
4- O usuário confirma o envio das informações.
5- O sistema informa que o usuário realizou login com sucesso.
6- O usuário verifica que se encontra na seção apropriada, conforme seu nível de privilégio no sistema.
32 6 – FIGURAS
34 Figura 2: Diagramas de Seqüência
Figura 2.1: Login
35 Figura 2.3: Mediator
36 Figura 2.5: Editar Cliente
37 Figura 2.7: Remover Cliente
38 Figura 2.9: Editar Funcionário
39 Figura 2.11: Remover Funcionário
40 Figura 2.13: Editar Produto
41 Figura 2.15: Remover Produto
42 Figura 3: Modelo Lógico
43 Figura 4: Modelo Conceitual
44 7 – CONCLUSÃO
Esperamos que todas as necessidades para a fase de implementação e testes sejam atendidas com as informações que foram detalhadas nesse documento.
45 8 – APÊNDICE A
Detalhes dos dados de entrada (DE) dos Casos de Teste:
Dados
Id. Nome Tipo Especificação
DE01 Nome de usuário Válido Formado por caracteres alfanuméricos, com um tamanho máximo de 32 caracteres. DE02 Nome de usuário Inválido Qualquer combinação diferente da
especificação em DE01.
DE03 Senha Válida Formado por caracteres alfanuméricos,
com um tamanho máximo de 32 caracteres.
DE04 Senha Inválida Qualquer combinação diferente da
especificação em DE03.
DE05 Nome da pessoa Válido Formado por caracteres alfanuméricos, com um tamanho máximo de 32 caracteres. DE06 Nome da pessoa Inválido Qualquer combinação diferente da
especificação em DE05.
DE07 Permissão Válida Formado por um caracter numérico. Pode ser do tipo: 0 (atendente), 1 (caixa), 2 (gerente).
DE08 Permissão Inválida Qualquer combinação diferente da
especificação em DE07.
DE09 Data de nascimento Válida Formada por 10 caracteres, no formato de data: dd/mm/aaaa, onde ‘dd’ é o dia (intervalo numérico 01-31), ‘mm’ o mês (intervalo numérico 01-12), e ‘aaaa’ o ano (intervalo numérico 0000-9999).
DE10 Data de nascimento Inválida Qualquer combinação diferente da especificação em DE09.
DE11 Data de admissão Válida Formada por DE09
46 especificação em DE09.
DE13 Telefone Válido Formado por caracteres alfanuméricos, com um tamanho máximo de 12 caracteres.
DE14 Telefone Inválido Qualquer combinação diferente da
especificação em DE13.
DE15 Celular Válido Formado por DE13.
DE16 Celular Inválido Qualquer combinação diferente da
especificação em DE13.
DE17 CPF Válido Formado por 11 caracteres numéricos.
DE18 CPF Inválido Qualquer combinação diferente da
especificação em DE17.
DE19 RG Válido Formado por caracteres alfanuméricos,
com um tamanho máximo de 32 caracteres.
DE20 RG Inválido Qualquer combinação diferente da
especificação em DE19.
DE21 Salário Válido Formado por caracteres numéricos e uma vírgula, no formato de moeda. Precisão double (64 bits).
DE22 Salário Inválido Qualquer combinação diferente da
especificação em DE21.
DE23 Sexo Válido Formado por um caracter numérico. Pode ser do tipo: 0 (feminino), 1 (masculino).
DE24 Sexo Inválido Qualquer combinação diferente da
especificação em DE23.
DE25 Observação Válida Formado por caracteres alfanuméricos, com um tamanho máximo de 128 caracteres.
DE26 Observação Inválida Qualquer combinação diferente da especificação em DE25.
DE27 Nome do produto Válido Formado por caracteres alfanuméricos, com um tamanho máximo de 32 caracteres. DE28 Nome do produto Inválido Qualquer combinação diferente da
47 especificação em DE27.
DE29 Fornecedor Válido Formado por DE27.
DE30 Fornecedor Inválido Qualquer combinação diferente da especificação em DE27.
DE31 Lote Válido Formado por DE27.
DE32 Lote Inválido Qualquer combinação diferente da
especificação em DE27.
DE33 Quantidade de produtos Válida Formada por caracteres numéricos, com um tamanho máximo de 9 caracteres. DE34 Quantidade de produtos Inválida Qualquer combinação diferente da
especificação em DE33. DE35 Data de fabricação Válida Formada por DE09.
DE36 Data de fabricação Inválida Qualquer combinação diferente da especificação em DE09.
DE37 Data de vencimento Válida Formada por DE09.
DE38 Data de vencimento Inválida Qualquer combinação diferente da especificação em DE09.
DE39 Preço de custo Válido Formado por DE21.
DE40 Preço de custo Inválido Qualquer combinação diferente da especificação em DE21.
DE41 Preço de venda Válido Formado por DE21.
DE42 Preço de venda Inválido Qualquer combinação diferente da especificação em DE21.
DE43 Status do cliente Válido Formada por um caracter numérico. Pode ser do tipo: 0 (cliente sem dívidas), 1 (cliente com dívidas).
DE44 Status do cliente Inválido Qualquer combinação diferente da especificação em DE43.
DE45 Data de entrada Válida Formada por DE09.
DE46 Data de entrada Inválida Qualquer combinação diferente da especificação em DE09.
48 DE48 Saldo Gasto Inválido Qualquer combinação diferente da
especificação em DE21.
DE49 Saldo devedor Válido Formado por DE21.
DE50 Saldo devedor Inválido Qualquer combinação diferente da especificação em DE21.
DE51 Tarja Válida Formada por um caracter numérico. Pode ser do tipo: 0 (sem tarja), 1 (tarja vermelha), 2 (tarja preta).
DE52 Tarja Inválida Qualquer combinação diferente da
especificação em DE51. DE53 Código do funcionário Válido Formado por DE33.
DE54 Código do funcionário Inválido Qualquer combinação diferente da especificação em DE33.
DE55 Código do produto Válido Formado por DE33.
DE56 Código do produto Inválido Qualquer combinação diferente da especificação em DE33.
DE57 Código do cliente Válido Formado por DE33.
DE58 Código do cliente Inválido Qualquer combinação diferente da especificação em DE33.
DE59 Código da venda Válido Formado por DE33.
DE60 Código da venda Inválido Qualquer combinação diferente da especificação em DE33.
DE61 Data da venda Válida Formada por DE09.
DE62 Data da venda Inválida Qualquer combinação diferente da especificação em DE09.
DE63 Status do pagamento Válido Formada por um caracter numérico. Pode ser do tipo: 1 (pagamento efetuado), 2 (pagamento não efetuado).
DE64 Status do pagamento Inválido Qualquer combinação diferente da especificação em DE63.
DE65 Código do pagamento Válido Formado por DE33.
49 especificação em DE33.
DE67 Data do pagamento Válida Formada por DE09
DE68 Data do pagamento Inválida Qualquer combinação diferente da especificação em DE09.
DE69 Tipo de pagamento Válido Formada por um caracter numérico. Pode ser do tipo: 0 (em dinheiro), 1 (em cheque). DE70 Tipo de pagamento Inválido Qualquer combinação diferente da
especificação em DE69. DE71 Valor do pagamento Válido Formado por DE21.
DE72 Valor do pagamento Inválido Qualquer combinação diferente da especificação em DE21.
DE73 Número do cheque Válido Formado por caracteres alfanuméricos, com um tamanho máximo de 45 caracteres. DE74 Número do cheque Inválido Qualquer combinação diferente da
especificação em DE73. DE75 Número da conta Válido Formado por DE73.
DE76 Número da conta Inválido Qualquer combinação diferente da especificação em DE73.
DE77 Valor do cheque Válido Formado por DE21.
DE78 Valor do cheque Inválido Qualquer combinação diferente da especificação em DE21.
DE79 Data de validade do cheque Válida Formada por DE09
DE80 Data de validade do cheque Inválida Qualquer combinação diferente da especificação em DE09.
DE81 Dados do funcionário Válido Formado por DE05, DE07, DE09, DE11, DE13, DE15, DE17, DE19, DE21, DE23, DE25, DE53.
DE82 Dados do funcionário Inválido Qualquer combinação diferente da especificação em DE81.
DE83 Dados do cliente Válido Formado por DE05, DE09, DE13, DE15, DE17, DE19, DE23, DE43, DE47, DE49, DE57.
50 DE84 Dados do cliente Inválido Qualquer combinação diferente da
especificação em DE83.
DE85 Dados do produto Válido Formado por DE25, DE27, DE29, DE31, DE33, DE35, DE37, DE39, DE41, DE51, DE55.
DE86 Dados do produto Inválido Qualquer combinação diferente da especificação em DE85.
DE87 Dados da venda Válido Formado por DE59, DE61, DE81, DE89, DE83, DE95.
DE88 Dados da venda Inválido Qualquer combinação diferente da especificação em DE87.
DE89 Dados do pagamento Válido Formado por DE63, DE65, DE67, DE69, DE71, DE87.
DE90 Dados do pagamento Inválido Qualquer combinação diferente da especificação em DE89.
DE91 Quantidade de Itens na Venda Valida Formado por DE33.
DE92 Quantidade de Itens na Venda Inválida Qualquer combinação diferente da especificação em DE33.
DE93 Dados do cheque Válido Formado por DE73, DE75, DE77, DE79, DE87, DE89, DE83.
DE94 Dados do cheque Inválido Qualquer combinação diferente da especificação em DE01.
DE95 Valor da venda Válido Formado por DE21.
DE96 Valor da venda Inválido Qualquer combinação diferente da especificação em DE21.
51 9 – APÊNDICE B
FORMULÁRIO DE RELATÓRIO DA EQUIPE
Descrição de papéis e contribuição de cada membro da equipe:
- Não houve uma divisão rígida entre os integrantes da equipe. Optamos por um desenvolvimento de projeto progressivo e igualitário.
NOME % ESFORÇO NA EQUIPE
______________________________ 33,3%
Alessandro Rodrigo Franco
______________________________ 33,3%
Fernando Luiz Grando
______________________________ 33,3%
52 10 – REFERÊNCIAS BIBLIOGRÁFICAS
http://www.inf.unioeste.br/~victor/processoII/ (acessado em Julho/2009) PRESSMAN, R. S. Engenharia de Software. 6ª edição. McGraw-Hill, 2006.
