PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II
|
|
- Jerónimo Marreiro Peralta
- 8 Há anos
- Visualizações:
Transcrição
1 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
3 ÍNDICE 1 Introdução Arquitetura do Sistema Padrões de Projeto Descrição dos Diagramas Diagrama de Classes Diagrama de Seqüência Diagrama de Entidade Relacionamento Política e Estratégias de Testes Casos de Teste Figuras...32 Figura 1: Diagrama de Classes...32 Figura : Diagramas de Seqüência...34 Figura 3: Modelagem BD Modelo Lógico Figura 4: Modelagem BD Modelo Conceitual Conclusão Apêndice A: Detalhes dos Casos de Teste Apêndice B: Formulário de Relatório da Equipe Referências Bibliográficas
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. 4
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. 5
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: 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 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 Padrão Singleton O padrão Singleton permite somente uma instância de um objeto. Utilizado para controlar as instâncias dos DAO s. 6
7 4 DIAGRAMAS 4.1 Diagrama de Classes Figura 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 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 7
8 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 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 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. 8
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 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 Regra Factory (Figura 2.2) - O Controlador busca a regra na RegraFactory. - O Controlador executa a regra Mediator (Figura 2.3) - View cria componentes em componentes. - Componentes registra os componentes em Mediator. - Componentes trata o evento em Mediator. 9
10 - Mediator atualiza View em View 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 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 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 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. 10
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 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 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 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. 11
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 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 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 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. As opções de cadastro, remoção, edição e localização das classes JdbcPessoaDAO, 12
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 Diagrama de Entidade Relacionamento Modelo Lógico Figura 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. 13
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. PrecoCusto: campo do tipo double para o preço de custo do produto. 14
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. 15
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. 16
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 Modelo Conceitual Figura 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. Produto: Representa os produtos disponíveis na Farmácia. É composto pelos 17
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. 18
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. Pré-Condição Condições que devem ser cumpridas antes de executar o Caso 19
20 Dados de Teste Passos Notas 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 que serão executados no teste. Destacar algum ponto importante do Caso de Teste. CT 01 Importância Propósito Pré-Condição Dados de Teste Passos Cadastrar funcionário. Alta. O gerente pode Cadastrar funcionários. O usuário deve estar identificado. O usuário deve ser do tipo gerente. 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}. 1- O gerente entra na seção Cadastrar funcionário. 2- O gerente seleciona a permissão (cargo) do funcionário que deseja 20
21 Notas 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. CT 02 Importância Propósito Pré-Condição Dados de Teste Passos Notas Remover funcionário. Alta. O gerente pode Remover funcionário. O usuário deve estar identificado. O usuário deve ser do tipo gerente. O funcionário a ser excluído deve existir. Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}. 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. CT - 03 Editar funcionário. 21
22 Importância Propósito Pré-Condição Dados de Teste Passos Notas Alta. O gerente pode Editar o funcionário. O usuário deve estar identificado. O usuário deve ser do tipo gerente. O funcionário a ser alterado deve existir. Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}. 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. CT 04 Importância Propósito Pré-Condição Dados de Teste Passos Notas Buscar funcionário. Alta O gerente pode Buscar o funcionário. O usuário deve estar identificado. O usuário deve ser do tipo gerente. O funcionário a ser consultado deve existir. Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}. 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. CT 05 Importância Cadastrar produto. Alta 22
23 Propósito Pré-Condição Dados de Teste Passos Notas O gerente e o atendente podem Cadastrar produto. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou atendente. 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}. 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. 23
24 CT 06 Importância Propósito Pré-Condição Dados de Teste Passos Notas Remover produto. Alta O gerente e o atendente podem Remover produto. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou atendente. O produto a ser excluído deve existir. Nome do produto = {nome do produto válido, nome do produto inválido, sem nome do produto}. 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. CT 07 Importância Propósito Pré-Condição Dados de Teste Passos Editar produto. Alta O gerente e o atendente podem Editar produto. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou atendente. O produto a ser alterado deve existir. Nome do produto = {nome do produto válido, nome do produto inválido, sem nome do produto}. 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. 24
25 Notas CT 08 Importância Propósito Pré-Condição Dados de Teste Passos Notas Buscar produto. Alta O gerente e o atendente podem Buscar produto. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou atendente. O produto a ser consultado deve existir. Nome do produto = {nome do produto válido, nome do produto inválido, sem nome do produto}. 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. CT 09 Importância Propósito Pré-Condição Dados de Teste Cadastrar cliente. Alta. O gerente e o caixa podem Cadastrar cliente. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou caixa. 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}. RG = {RG válido, RG inválido, sem RG}. 25
26 Passos Notas 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}. 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. CT 10 Importância Propósito Pré-Condição Dados de Teste Passos Notas Remover cliente. Alta. O gerente e o caixa podem Remover cliente. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou caixa. O cliente a ser excluído deve existir. Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}. 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. 26
27 CT - 11 Importância Propósito Pré-Condição Dados de Teste Passos Notas Editar cliente. Alta. O gerente e o caixa podem Editar cliente. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou caixa. O cliente a ser alterado deve existir. Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}. 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. CT 12 Importância Propósito Pré-Condição Dados de Teste Passos Notas Buscar cliente. Alta O gerente e o caixa podem Buscar cliente. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou caixa. O cliente a ser consultado deve existir. Nome da pessoa = {nome da pessoa válido, nome da pessoa inválido, sem nome da pessoa}. 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. 27
28 CT 13 Importância Propósito Pré-Condição Dados de Teste Passos Notas Realizar Vendas. Alta O gerente e o caixa podem realizar venda. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou caixa. 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}. 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. 28
29 CT 14 Importância Propósito Pré-Condição Dados de Teste Passos Notas Pagamento em dinheiro. Alta O gerente e o caixa podem receber em dinheiro. O usuário deve estar identificado. O usuário deve ser do tipo gerente ou caixa. 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}. 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. CT 15 Importância Propósito Pagamento em cheque. Alta O gerente e o caixa podem receber em cheque. 29
30 Pré-Condição Dados de Teste Passos Notas O usuário deve estar identificado. O usuário deve ser do tipo gerente ou caixa. 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}. 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. CT 16 Importância Identificar-se no sistema. Alta 30
31 Propósito Pré-Condição Dados de Teste Passos Notas O usuário pode ingressar no sistema. O usuário deve existir. O usuário deve ser do tipo atendente, caixa ou gerente. 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}. 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. 31
32 6 FIGURAS Figura 1: Diagrama de Classes 32
33 33
34 Figura 2: Diagramas de Seqüência Figura 2.1: Login Figura 2.2: Regra Factory 34
35 Figura 2.3: Mediator Figura 2.4: Cadastrar Cliente 35
36 Figura 2.5: Editar Cliente Figura 2.6: Localizar Cliente 36
37 Figura 2.7: Remover Cliente Figura 2.8: Cadastrar Funcionário 37
38 Figura 2.9: Editar Funcionário Figura 2.10: Localizar Funcionário 38
39 Figura 2.11: Remover Funcionário Figura 2.12: Cadastrar Produto 39
40 Figura 2.13: Editar Produto Figura 2.14: Localizar Produto 40
41 Figura 2.15: Remover Produto 41
42 Figura 3: Modelo Lógico 42
43 Figura 4: Modelo Conceitual 43
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. 44
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 ). 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 DE12 Data de admissão Inválida Qualquer combinação diferente da 45
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 46
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. DE47 Saldo Gasto Válido Formado por DE21. 47
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. DE66 Código do pagamento Inválido Qualquer combinação diferente da 48
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. 49
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. 50
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% Fernando Martins 51
52 10 REFERÊNCIAS BIBLIOGRÁFICAS (acessado em Julho/2009) PRESSMAN, R. S. Engenharia de Software. 6ª edição. McGraw-Hill,
PROJETO DA DISCIPLINA. PES II Processo de Engenharia de Software II
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
Leia maisEngenharia de Software III
Engenharia de Software III Casos de uso http://dl.dropbox.com/u/3025380/es3/aula6.pdf (flavio.ceci@unisul.br) 09/09/2010 O que são casos de uso? Um caso de uso procura documentar as ações necessárias,
Leia maisSISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária
SISTEMA TYR DIAGRAMAS DE CLASSE E SEQUÊNCIA Empresa: Academia Universitária Cascavel Novembro de 2009 Pedro Patitucci Finamore Daniel Bordignon Cassanelli Marco Antonio da Rosa DIAGRAMAS DE CLASSE E SEQUÊNCIA
Leia maisUniversidade Federal Rural de Pernambuco. Bacharelado em Sistemas de Informação. Disciplina: Análise e Projeto de Sistemas de Informação
Universidade Federal Rural de Pernambuco Bacharelado em Sistemas de Informação Disciplina: Análise e Projeto de Sistemas de Informação Docente: Rodrigo Aluna: Thays Melo de Moraes Diagramas do Projeto
Leia maisSumário. Uma visão mais clara da UML
Instituto Federal de Santa Catarina Câmpus Chapecó Ensino Médio Integrado em Informática Módulo V Unidade Curricular: Engenharia de Software Professora: Lara P. Z. B. Oberderfer Uma visão mais clara da
Leia maisCONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS
MINISTÉRIO DO DESENVOLVIMENTO AGRÁRIO SUBSECRETARIA DE PLANEJAMENTO, ORÇAMENTO E ADMINISTRAÇÃO COORDENAÇÃO-GERAL DE MODERNIZAÇÃO E INFORMÁTICA CONTRA CONTROLE DE ACESSOS E MODULARIZADOR DE SISTEMAS MANUAL
Leia maisESTÁGIO DE DOCÊNCIA II
FUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ Centro de Tecnologia - CTC Departamento de Informática - DIN Programa de Pós-Graduação em Ciência da Computação PCC ESTÁGIO DE DOCÊNCIA II Disciplina: Engenharia
Leia maisInfoMix Tecnologia. Soluções em Tecnologia da Informação. SYSFARM Sistema de Gerenciamento de Farmácias. Documento Requisitos Versão 1.
SYSFARM Sistema de Gerenciamento de Farmácias Documento Requisitos Versão 1.1 Histórico de Revisão Data Versão Descrição Autor 06/09/2009 1.0 Elaboração da para análise da 1º versão Marcos Silva do documento
Leia maisAnálise de Ponto de Função
Complemento para o Curso Análise de Ponto de Função FUNÇÕES DO TIPO DADO O termo Arquivo não significa um arquivo do sistema operacional, como é comum na área de processamento de dados. Se refere a um
Leia maisHistórico da Revisão. Data Versão Descrição Autor
Sistema de Gerenciamento de Loja - SIGEL Documento de Visão Versão 1.0.0 Histórico da Revisão Data Versão Descrição Autor 13/01/2011 0.1 Versão preliminar do levantamento de requisitos funcionais e não
Leia maisBEM-VINDO AO dhl PROVIEW
BEM-VINDO AO dhl PROVIEW Guia de Usuário O DHL PROVIEW COLOCA VOCÊ NO CONTROLE DE SEUS ENVIOS. PROVIEW O DHL ProView é uma ferramenta de rastreamento on-line que permite o gerenciamento dos envios, a programação
Leia maisO Oficina Integrada é um sistema completo para o controle e gerenciamento de oficinas mecânicas. É o primeiro e único software que controla o fluxo
O Oficina Integrada é um sistema completo para o controle e gerenciamento de oficinas mecânicas. É o primeiro e único software que controla o fluxo em sua oficina. O sistema foi desenvolvido para ser utilizado
Leia maisDocumento de Análise e Projeto VideoSystem
Documento de Análise e Projeto VideoSystem Versão Data Versão Descrição Autor 20/10/2009 1.0 21/10/2009 1.0 05/11/2009 1.1 Definição inicial do documento de análise e projeto Revisão do documento
Leia maisConcepção e Elaboração
UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo
Leia maisVersão <1.0> Documento de Requisitos. Documento de Requisitos. Equipe:
Versão Documento de Requisitos Documento de Requisitos Equipe: Bruno Harada (bhhc) Edilson Augusto Junior (easj) José Ivson Soares da Silva (jiss) Pedro Rodolfo da Silva Gonçalves (prsg) Raphael
Leia maisMaterial de Apoio. SEB - Contas a Pagar. Versão Data Responsável Contato 1 05/12/2011 Paula Fidalgo paulaf@systemsadvisers.com
Material de Apoio SEB - Contas a Pagar Versão Data Responsável Contato 1 05/12/2011 Paula Fidalgo paulaf@systemsadvisers.com Conteúdo CONFIGURAÇÃO... 3 Cadastro de Fornecedores... 3 Métodos de Pagamento...
Leia maisModelagem de Software Prof. Flávio de Oliveira Silva, Ph.D.
UML Diagramas Um diagrama é a apresentação gráfica de um conjunto de elementos, onde os vértices são ITENS e os arcos RELACIONAMENTOS UML 2.0 possui os seguintes diagramas: Diagrama de Classes (Class Diagram)
Leia maisManual Administrador - Mídia System
Manual Administrador - Mídia System Logo após cadastrarmos sua Empresa em nosso sistema, será enviado um e-mail confirmando as informações de acesso do Administrador do sistema. Obs: Caso não tenha recebido
Leia maisTarciane Andrade. tarcianeandrade@gmail.com
Tarciane Andrade tarcianeandrade@gmail.com Contexto Análise Passando de casos de uso para diagramas de classes 2 Após a etapa de análise de requisitos, temos documentos de requisitos e os casos de uso
Leia maisCADASTRAMENTO ÚNICO VERSÃO 7.3 INCLUSÃO E MANUTENÇÃO DE USUÁRIOS
CADASTRAMENTO ÚNICO VERSÃO 7.3 INCLUSÃO E MANUTENÇÃO DE USUÁRIOS Para a prefeitura foi definido dois tipos de usuários: Usuário máster e Usuário Final. O cadastramento para acesso ao CadÚnico V7 é feita
Leia maisElaborado por SIGA-EPT. Projeto SIGA-EPT: Manual do Usuário Almoxarifado
Elaborado por SIGA-EPT Projeto SIGA-EPT: Manual do Usuário Almoxarifado Versão Dezembro - 2009 Sumário 1 Introdução 5 1.1 Entrando no sistema e repassando as opções................... 5 1.2 Administração......................................
Leia maisIntrodução Diagramas de Casos de Uso Diagramas de Classes Estoque Fácil
UFCG Introdução Diagramas de Casos de Uso Diagramas de Classes Estoque Fácil Arthur Silva Freire Caio César Meira Paes Carlos Artur Nascimento Vieira Matheus de Araújo Maciel Tiago Brasileiro Araújo Engenharia
Leia maisMANUAL DO GERENCIADOR ESCOLAR WEB
CNS LEARNING MANUAL DO GERENCIADOR ESCOLAR WEB Versão Online 13 Índice ÍNDICE... 1 VISÃO GERAL... 2 CONCEITO E APRESENTAÇÃO VISUAL... 2 PRINCIPAIS MÓDULOS... 3 ESTRUTURAÇÃO... 3 CURSOS... 4 TURMAS... 4
Leia maisRicardo Roberto de Lima UNIPÊ 2008.1 APS-I. Históricos e Modelagem Orientada a Objetos
Históricos e Modelagem Orientada a Objetos Histórico Diversas metodologias e métodos surgiram para apoiar OO. Evolução a partir de linguagens C++ e SmallTalk. Anos 80 Anos 80-90: diversidade de autores.
Leia maisManual Operacional SIGA
SMS - ATTI Julho -2012 Conteúdo Sumário... 2... 3 Consultar Registros... 4 Realizar Atendimento... 9 Adicionar Procedimento... 11 Não Atendimento... 15 Novo Atendimento... 16 Relatórios Dados Estatísticos...
Leia mais2 Diagrama de Caso de Uso
Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa
Leia maisLINGUAGEM DE BANCO DE DADOS
LINGUAGEM DE BANCO DE DADOS Gabriela Trevisan Bacharel em Sistemas de Informação Universidade Federal do Rio Grande Pós-Graduanda Formação Pedagógica de Professores (FAQI) Conceito de BD Um banco de dados
Leia maisUniversidade Paulista
Universidade Paulista Ciência da Computação Sistemas de Informação Gestão da Qualidade Principais pontos da NBR ISO/IEC 12207 - Tecnologia da Informação Processos de ciclo de vida de software Sergio Petersen
Leia maisGuia de Especificação de Caso de Uso Metodologia CELEPAR
Guia de Especificação de Caso de Uso Metodologia CELEPAR Agosto 2009 Sumário de Informações do Documento Documento: guiaespecificacaocasouso.odt Número de páginas: 10 Versão Data Mudanças Autor 1.0 09/10/2007
Leia maisPROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS. Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br
PROGRAMAÇÃO AVANÇADA -CONCEITOS DE ORIENTAÇÃO A OBJETOS Prof. Angelo Augusto Frozza, M.Sc. frozza@ifc-camboriu.edu.br ROTEIRO 1. Conceitos de Orientação a Objetos Introdução O paradigma da POO Classes
Leia maisIF-718 Análise e Projeto de Sistemas
Centro de Informática - Universidade Federal de Pernambuco Especificação de Requisitos do Software Sistema de Gerenciamento de Restaurantes IF-718 Análise e Projeto de Sistemas Equipe: Jacinto Filipe -
Leia maisPROCEDIMENTOS PARA A UTILIZAÇÃO DO SISTEMA DE SOLICITAÇÃO DE ORDEM DE SERVIÇO (SOSI) STI Unesp - Campus Experimental de Ourinhos
PROCEDIMENTOS PARA A UTILIZAÇÃO DO SISTEMA DE SOLICITAÇÃO DE ORDEM DE SERVIÇO (SOSI) STI Unesp - Campus Experimental de Ourinhos 1 SISTEMA DE ORDEM DE SERVIÇO DE INFORMÁTICA Este documento tem o objeto
Leia maisBEM-VINDO AO dhl PROVIEW GUIA RÁPIDO DE USO
BEM-VINDO AO dhl PROVIEW GUIA RÁPIDO DE USO O DHL PROVIEW COLOCA VOCÊ NO CONTROLE DE SEUS ENVIOS. PROVIEW O DHL ProView é uma ferramenta de rastreamento on-line que permite a visibilidade dos envios e
Leia maisConteúdo. Disciplina: INF 02810 Engenharia de Software. Monalessa Perini Barcellos. Centro Tecnológico. Universidade Federal do Espírito Santo
Universidade Federal do Espírito Santo Centro Tecnológico Departamento de Informática Disciplina: INF 02810 Prof.: (monalessa@inf.ufes.br) Conteúdo 1. Introdução 2. Processo de Software 3. Gerência de
Leia maisDPAlmox - Windows MANUAL DO USUÁRIO
- Windows MANUAL DO USUÁRIO DPSISTEMAS www.dpsistemas.com.br 1. Registrando o programa... 3 2. Entrando no programa Login... 5 3. Tela Principal do Sistema... 6 4. Utilizando os botões de navegação...
Leia maisMANUAL DE MOVIMENTAÇÃO WEB POR FORMULÁRIO
Este manual tem o objetivo de orientar o preenchimento do formulário de Movimentação Web disponibilizado na área de Movimentação de beneficiários por formulário que fica na área restrita da empresa no
Leia maisEngenharia de Software I
Engenharia de Software I Curso de Desenvolvimento de Software Prof. Alessandro J de Souza ajdsouza@cefetrn.br 1 Rational Unified Process RUP Fase Elaboração 2 VISÃO GERAL Fase Elaboração. Visão Geral 3
Leia maisUniversidade Federal de Santa Maria Curso de Arquivologia. Disciplina de Banco de Dados Aplicados à Arquivística. Versao 1.
Universidade Federal de Santa Maria Curso de Arquivologia Disciplina de Banco de Dados Aplicados à Arquivística Prof. Andre Zanki Cordenonsi Versao 1.0 Março de 2008 Tópicos Abordados Conceitos sobre Banco
Leia maisConstrutor de sites SoftPixel GUIA RÁPIDO - 1 -
GUIA RÁPIDO - 1 - Sumário Introdução...3 Por que utilizar o Construtor de Sites?...3 Vantagens do Construtor de Sites...3 Conceitos básicos...3 Configuração básica do site...5 Definindo o layout/template
Leia maisConceitos de Banco de Dados
Conceitos de Banco de Dados Autor: Luiz Antonio Junior 1 INTRODUÇÃO Objetivos Introduzir conceitos básicos de Modelo de dados Introduzir conceitos básicos de Banco de dados Capacitar o aluno a construir
Leia maisModelagem de Casos de Uso (Parte 1)
Modelagem de Casos de Uso (Parte 1) Roteiro Introdução Descrição: Sistema de Ponto de Vendas Casos de Usos Atores Fluxo de Eventos Cenários Formato de Documentação de Casos de Uso Diagramas de Casos de
Leia maisDesenvolvimento de um Simulador de Gerenciamento de Memória
Desenvolvimento de um Simulador de Gerenciamento de Memória Ricardo Mendes do Nascimento. Ciência da Computação Universidade Regional Integrada do Alto Uruguai e das Missões (URI) Santo Ângelo RS Brasil
Leia maisNa página que se abre, o usuário informa os seguintes campos (todos obrigatórios):
WebPlan MVC Manual de Operação Ouvidoria O módulo de ouvidoria fornece acesso a beneficiários, prestadores e outras entidades (inclusive que não se relacionam com a operadora) de forma que possam abrir
Leia maisFluxo de trabalho do Capture Pro Software: Indexação de OCR e separação de documentos de código de correção
Este procedimento corresponde ao fluxo de trabalho de Indexação de OCR com separação de código de correção no programa de treinamento do Capture Pro Software. As etapas do procedimento encontram-se na
Leia maisimprimir (http://pje.csjt.jus.br/manual/index.php?title=impressao_oficial_de_justiça&printable=yes)
Page 1 of 30 Impressao Oficial de justiça De PJe - Manual imprimir (http://pje.csjt.jus.br/manual/index.php?title=impressao_oficial_de_justiça&printable=yes) Tabela de conteúdo 1 Manual do Oficial de Justiça
Leia maisApresentação... Nome: Vanderlei Cordeiro Frazão
Apresentação... Nome: Vanderlei Cordeiro Frazão Formação: - Bacharel em Sistemas de Informação (Uniguaçu) - Pós graduação em Docência no Ensino Superior (Uniguaçu) - Licenciatura em Informática (UTFPR)
Leia maisUNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação
SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula
Leia maisSUAP Módulo Protocolo Manual do Usuário DTI DIRETORIA DE TECNOLOGIA DA INFORMAÇÃO SEÇÃO DE PROJETOS, SISTEMAS E PROCESSOS DE NEGÓCIO
SUAP Módulo Protocolo Manual do Usuário DTI DIRETORIA DE TECNOLOGIA DA INFORMAÇÃO SEÇÃO DE PROJETOS, SISTEMAS E PROCESSOS DE NEGÓCIO SUMÁRIO 1. APRESENTAÇÃO... 1 1.1. ACESSO AO SISTEMA... 1 1.2. TELA INICIAL
Leia maisSISTEMA INTEGRADO DE GESTÃO ACADÊMICA
MINISTÉRIO DA EDUCAÇÃO INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO TRIÂNGULO MINEIRO SISTEMA INTEGRADO DE GESTÃO ACADÊMICA MÓDULO PROTOCOLO MANUAL DO USUÁRIO VERSÃO: SETEMBRO/2010 SUMÁRIO Introdução...
Leia mais4 O Workflow e a Máquina de Regras
4 O Workflow e a Máquina de Regras O objetivo do workflow e da máquina de regras é definir um conjunto de passos e regras configuráveis. Ao longo de sua execução, um usuário consegue simplificar o seu
Leia maisSECRETARIA DE ESTADO DA FAZENDA DIRETORIA DE FISCALIZAÇÃO PEDIDO DE USO DE ECF MANUAL DO USUÁRIO VERSÃO 1.0
SECRETARIA DE ESTADO DA FAZENDA DIRETORIA DE FISCALIZAÇÃO PEDIDO DE USO DE ECF MANUAL DO USUÁRIO VERSÃO 1.0 Belém Agosto - 2013 1 SUMÁRIO 1. Introdução... 3 2. Identificação Acesso ao Sistema... 4 3. Painel
Leia maisGerenciamento e Captura de Cheques - Sistec. Manual de Instalação e Importação ÍNDICE 1.INSTALAÇÃO. 1.1 - Instalando o programa
ÍNDICE 1 1.INSTALAÇÃO 1.1 - Instalando o programa 1.2 - Configurando dados do cliente 1.3 - Identificando o leitor de cheques Gerenciamento e Captura de Cheques - Sistec 1.4 - Cadastrando a conta do cliente
Leia maisLevantamento, Análise e Gestão Requisitos. Aula 12
Levantamento, Análise e Gestão Requisitos Aula 12 Agenda Miscelâneas (Parte 3): Gerenciamento dos Requisitos Mutáveis Rastreabilidade de Requisitos Processo de Gestão de Mudanças Requisitos Estáveis e
Leia mais6.1. Inserir... 09 6.2. Consultar... 10 6.3. Listar Todos... 11 6.4. Alterar... 12 7. BENEFÍCIOS... 12
Sumário 1. APRESENTAÇÃO INICIAL... 03 2. EMPRESA... 03 3. UNIDADE... 03 3.1. Consultar... 03 3.2. Listar Todas... 04 4. SETOR... 05 4.1. Consultar... 05 4.2. Inserir... 05 4.3. Listar... 06 5. FUNÇÃO...
Leia maisManual para Transportadoras
Índice 1 Objetivo... 3 2 O Projeto e-suprir... 3 3 Introdução... 3 4 Informações Básicas... 4 4.1 Painel de Controle Compras... 4 5 Acessando o Pedido... 5 6 Digitando o Espelho de Nota Fiscal... 7 6.1
Leia maisUnioeste Universidade Estadual do Oeste do Paraná
Unioeste Universidade Estadual do Oeste do Paraná CENTRO DE CIÊNCIAS EXATAS E TECNOLÓGICAS Colegiado de Informática Curso de Bacharelado em Informática Especificação de Requisitos e Modelagem Orientada
Leia maisManual do Sistema. SMARsa. Módulo WEB
Manual do Sistema SMARsa Módulo WEB Notas da Atualização do Manual Na versão 4.1 deste manual consta: 1º. Aguardando Recebimento: Adicionado o campo de digitação do numero de remessa para o recebimento.
Leia maisAnálise e Projeto Orientado a Objetos. Modelagem de Domínio
+ Análise e Projeto Orientado a Objetos Modelagem de Domínio Introdução 2 n A modelagem do domínio está relacionada à descoberta das informações que são gerenciadas pelo sistema. O resultado dessa investigação
Leia maisMANUAL DE UTILIZAÇÃO SISTEMA DE CADASTRO INTRANET
MANUAL DE UTILIZAÇÃO SISTEMA DE CADASTRO INTRANET I Sumário 1. Objetivo do Documento... 1 2. Início... 1 3. Cadastro de Pessoa Física... 3 3.1. Preenchimentos Obrigatórios.... 4 3.2. Acesso aos Campos
Leia maisQUESTÃO 01 - DIAGRAMA DE SEQUENCIA (CONCEITOS)
Campus Cachoeiro de Itapemirim Disciplina: Análise e Projeto de Sistemas Curso Técnico em Informática Professor: Rafael Vargas Mesquita Bimestre 02 - Avaliação 03 - Assunto: Diagrama de Sequência Aluno:
Leia maisGUIA DE USUÁRIO - GU-
1/22 Revisão 00 de 20//12 1. OBJETIVO Orientar o usuário para a pesquisa e visualização detalhada de todas as ordens de compra emitidas, emitir confirmações de aceite, submeter solicitação de alteração,
Leia mais15/03/2010. Análise por pontos de função. Análise por Pontos de Função. Componentes dos Pontos de Função. Componentes dos Pontos de Função
Análise por pontos de função Análise por Pontos de Função Referência: Manual de práticas de contagem IFPUG Versão 4.2.1 Técnica que permite medir a funcionalidade de um software ou aplicativo, sob a visão
Leia maisApresentação. E&L ERP Sistema Gerencial de Informações. PostgreSQL 8.2/ 8.3. Domingos Martins ES. v. 1.0
Apresentação 1 PostgreSQL 8.2/ 8.3 Domingos Martins ES v. 1.0 2 Introdução: Com a necessidade de agilizar todos os serviços na parte de aquisição de material, tramitação de processo, documentação eletrônica
Leia maisMetodologia e Gerenciamento do Projeto na Fábrica de Software v.2
.:: Universidade Estadual de Maringá Bacharelado em Informática Eng. de Software III :. Sistema de Gerenciamento de Eventos - Equipe 09 EPSI Event Programming System Interface Metodologia e Gerenciamento
Leia maisProjeto de Sistemas I
Instituto Federal de Educação, Ciência e Tecnologia de São Paulo Projeto de Sistemas I Professora: Kelly de Paula Cunha E-mail:kellypcsoares@ifsp.edu.br Requisitos: base para todo projeto, definindo o
Leia maisDocumento de Diagrama de Classes. MC436 Introdução à Engenharia de Software Profª Ariadne Maria Brito Rizzoni Carvalho
Documento de Diagrama de Classes MC436 Introdução à Engenharia de Software Profª Ariadne Maria Brito Rizzoni Carvalho 1. Índice 2. Introdução 3 3. Diagrama de casos de uso simplificado 3 4. Dicionário
Leia maisEngenharia de Requisitos Estudo de Caso
Engenharia de Requisitos Estudo de Caso Auxiliadora Freire Fonte: Engenharia de Software 8º Edição / Ian Sommerville 2007 Slide 1 Engenharia de Requisitos Exemplo 1 Reserva de Hotel 1. INTRODUÇÃO Este
Leia maisDOCUMENTO DE REQUISITOS
1/38 DOCUMENTO DE REQUISITOS GED Gerenciamento Eletrônico de Documentos Versão 1.1 Identificação do Projeto CLIENTE: NOME DO CLIENTE TIPO DO SISTEMA OU PROJETO Participantes Função Email Abilio Patrocinador
Leia maisVoltado para novos usuários, este capítulo fornece uma instrução para edição de Leiaute do SILAS e suas funções.
13. Editor de leiautes Voltado para novos usuários, este capítulo fornece uma instrução para edição de Leiaute do SILAS e suas funções. Neste capítulo uma breve explicação será apresentada sobre a organização
Leia maisEstá apto a utilizar o sistema, o usuário que tenha conhecimentos básicos de informática e navegação na internet.
1. Descrição Geral Este manual descreve as operações disponíveis no módulo VTWEB Client, cuja finalidade é gerenciar cadastros de funcionários, realização de pedidos e controle financeiro dos pedidos.
Leia maisDocumentação de visão: Sistema de Controle de ponto eletrônico para empresas. Documentados por: Halison Miguel e Edvan Pontes
Documentação de visão: Sistema de Controle de ponto eletrônico para empresas Documentados por: Halison Miguel e Edvan Pontes Versão do documento: 1.4 Data de atualização: 04 de Fevereiro de 2012 Histórico
Leia maisCapítulo 1 Conceito Básico
Capítulo 1 Conceito Básico O Forzip é um software de gerenciamento de produção de cartões de identificação, desde pequenas quantidades até volumes industriais, que vem sendo aprimorado constantemente com
Leia maisMÓDULO 5 Movimentações
MÓDULO 5 Movimentações Bem-vindo(a) ao quinto módulo do curso. Agora que você já conhece as entradas no HÓRUS, aprenderá como são feitas as movimentações. As movimentações do HÓRUS são: Requisição ao Almoxarifado:
Leia maisAplicativo web para definição do modelo lógico no projeto de banco de dados relacional
Aplicativo web para definição do modelo lógico no projeto de banco de dados relacional Juarez Bachmann Orientador: Alexander Roberto Valdameri Roteiro Introdução Objetivos Fundamentação teórica Desenvolvimento
Leia maisPAINEL GERENCIADOR DE E-MAILS
Este manual foi criado com o objetivo de facilitar o gerenciamento de suas contas de e-mail. Com ele, o administrador poderá criar e excluir e-mails, alterar senha, configurar redirecionamento de contas,
Leia maisRelatório do GPES. Arquitetura Geral do Framework
Relatório do GPES UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ Relatório referente ao desenvolvimento da arquitetura geral do framework de preço de venda. Realizado no período de 29 de junho de 2010 a 30
Leia maisEspecificação de Requisitos
Projeto/Versão: Versão 11.80 Melhoria Requisito/Módulo: 000552 / Conector Sub-Requisito/Função: Multas Tarefa/Chamado: 01.08.01 País: Brasil Data Especificação: 13/05/13 Rotinas Envolvidas Rotina Tipo
Leia maisGereComSaber. Desenvolvimento de Sistemas de Software. Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática
Universidade do Minho Conselho de Cursos de Engenharia Licenciatura em Engenharia Informática Desenvolvimento de Sistemas de Software Ano Lectivo de 2009/10 GereComSaber Ana Duarte, André Guedes, Eduardo
Leia maisDepartamento de Tecnologia da Informação DTI Coordenadoria de Relacionamento com o Cliente CRC. Treinamento Básico do Correio Eletrônico
Departamento de Tecnologia da Informação DTI Coordenadoria de Relacionamento com o Cliente CRC Treinamento Básico do Correio Eletrônico Brasília Março de 2012 SUMÁRIO 1. Introdução... 3 1.1 Como acessar
Leia maisUNIVERSIDADE ESTADUAL DO AMAZONAS ESPECIALIZAÇÃO EM DESENVOLVIMENTO EM SOFTWARE LIVRE CONCEITOS E PROJETOS DE BANCO DE DADOS E SQL
O trabalho consiste na resolução de um exercício e na confecção de um relatório. 17/10/2005 é o último dia para entrega. O trabalho deverá entregue impresso e o seu conteúdo gravado numa mídia. O formato
Leia maisTestes de Software. Testes de Software. Teste de Validação. Teste de Defeito. Modelo de Entrada e Saída. Modelo de Entrada e Saída
DCC / ICEx / UFMG Testes de Software Testes de Software Eduardo Figueiredo http://www.dcc.ufmg.br/~figueiredo Teste de software buscam por erros ou anomalias em requisitos funcionais e não funcionais Classificação
Leia maisEngenharia de Software na Prática Hélio Engholm Jr.
Engenharia de Software na Prática Hélio Engholm Jr. Novatec Sumário Agradecimentos... 17 Sobre o autor... 18 Prefácio... 19 Capítulo 1 Desenvolvimento de software para o valor de negócios... 20 1.1 Qualidade
Leia maisGRS Gerador de Redes Sistêmicas. (outubro/2004)
116 APÊNDICE A MANUAL DO GRS Universidade Federal do Rio de Janeiro UFRJ Departamento de Ciência da Computação DCC Instituto de Matemática IM / Núcleo de Computação Eletrônica NCE GRS Gerador de Redes
Leia maisCenários do CEL. Acessar ao sistema
Cenários do CEL Acessar ao sistema Permitir que o usuário acesse ao Sistema de Léxicos e Cenários nas seguintes condições: logando-se, quando já estiver cadastrado; ou incluindo usuário independente, quando
Leia maisProcesso de Engenharia de Software II
UNIOESTE - Universidade Estadual do Oeste do Paraná CCET Centro de ciências Exatas e Tecnológicas Colegiado de Ciência da Computação Curso de Bacharelado em Ciência da Computação Processo de Engenharia
Leia maisTOTVS Série 1 Varejo (Simples) - Módulo e-commerce
Novo Módulo disponível no TOTVS S1 Varejo: permissão de utilização através de licença específica. Mesmo não adquirindo a licença de uso do módulo ele continuará presente na tela do usuário. 1 Na opção
Leia maisApesar de existirem diversas implementações de MVC, em linhas gerais, o fluxo funciona geralmente da seguinte forma:
1 Introdução A utilização de frameworks como base para a construção de aplicativos tem sido adotada pelos desenvolvedores com três objetivos básicos. Primeiramente para adotar um padrão de projeto que
Leia maisSistema de Controle. Como entrar no sistema. Tela inicial. Funcionalidades do sistema. Controle de permissões. Menu Aplicativo
Sistema de Controle Logístico de Medicamentos Como entrar no sistema 1 Tela inicial Funcionalidades do sistema Controle de permissões Menu Aplicativo Gerenciador de relatórios 0800 61 2439 siclom@aids.gov.br
Leia maisTreinamento de. Linx Pos
Treinamento de caixa Linx Pos Será instalados no terminal da loja, o ícone, conforme imagem abaixo: Linx POS ÍNDICE Abertura de caixa e leitura X Lançamentos Cancelamento de itens Consulta preços no ato
Leia maisUNIVERSIDADE FEDERAL DO AMAPÁ NÚCLEO DE TECNOLOGIA DA INFORMAÇÃO. Manual de Avaliação de Desempenho Cadastro
UNIVERSIDADE FEDERAL DO AMAPÁ NÚCLEO DE TECNOLOGIA DA INFORMAÇÃO Manual de Avaliação de Desempenho Cadastro UNIFAP MACAPÁ-AP 2013 S U M Á R I O 1 Tela de Login...2 2 Acessando ao submenu cadastro de avaliação
Leia maisAssessoria Técnica de Tecnologia da Informação - ATTI. Projeto de Informatização da Secretaria Municipal de Saúde do Município de São Paulo SISRH
Assessoria Técnica de Tecnologia da Informação - ATTI Projeto de Informatização da Secretaria Municipal de Saúde do Município de São Paulo SISRH Sistema de Gestão de Pessoas Versão 2.0a Manual de Operação
Leia maisGUIA RÁPIDO DE UTILIZAÇÃO DO PORTAL DO AFRAFEP SAÚDE
GUIA RÁPIDO DE UTILIZAÇÃO DO PORTAL DO AFRAFEP SAÚDE INTRODUÇÃO O portal do Afrafep Saúde é um sistema WEB integrado ao sistema HEALTH*Tools. O site consiste em uma área onde os Usuários e a Rede Credenciada,
Leia maisSua mais nova e completa ferramenta
TUTORIAL PORTAL CLIENTE LUCIOS Sua mais nova e completa ferramenta SOLICITE SEU ACESSO PRÉ-REQUISITO NAVEGADOR IE MICROSOFT O Navegador IE - Internet Explore, vem instalado como padrão em qualquer distribuição
Leia maisProf. Raul Sidnei Wazlawick UFSC-CTC-INE. Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010.
Visão Geral do Sistema Prof. Raul Sidnei Wazlawick UFSC-CTC-INE 2010 Fonte: Análise e Projeto de Sistemas de Informação Orientados a Objetos, 2ª Edição, Elsevier, 2010. A fase de concepção do UP consiste
Leia mais