Projeto Farmácia - Parte 1 - Ciência da Computação
Contents
1. o Dados do produto atualizados 21 Caso de Uso 11 Buscar Produto Objetivo Consultar dados de um produto Ator Gerente Atendente Pr condic o O Ator precisa estar logado no sistema Cen rio Prim rio 1 O ator informa o nome do produto a ser consultado 2 Sistema localiza produto e exibe seus dados na tela 3 A consulta finalizada Extens es la Cadastro inexistente Caso de Uso 12 Controle de Clientes Objetivo Controlar os cadastros dos clientes Ator Gerente Caixa Pr condic o O Ator precisa estar logado Cen rio Prim rio 1 Ator clica na aba Controle de Clientes 2 Na aba Controle de Clientes o Gerente escolhe entre Cadastrar Cliente Editar Cliente Remover Cliente ou Buscar Cliente 3 Ator faz as altera es que deseja 4 Ator salva o sistema com os novos dados Extens es 2a Adicionar cliente Caso de uso Cadastrar Cliente lt lt extend gt gt 2b Alterar cliente Caso de uso Editar Cliente lt lt extend gt gt 2c Consultar cliente Caso de uso Buscar Cliente lt lt extend gt gt 2d Excluir cliente Caso de uso Remover Cliente lt lt extend gt gt P s condi o Lista de clientes atualizada Caso de Uso 13 Cadastrar Cliente Objetivo Adicionar novo cliente Ator Gerente Caixa Pr condi o O Ator precisa estar logado no sistema Cen rio Prim rio 1 Ator entra com os dados do cliente Caso de uso Ve2. caso sejam necess rias dos processos e importa o dos dados mais atuais deixando o software pronto para o uso em ambiente de produ o ATO 15 In cio 16 01 10 T rmino 31 01 10 P s implanta o Acompanhamento junto aos usu rios para verifica o de problemas n o eliminados nas fases anteriores e ajustar pontos que n o ficaram satisfat rios 4 METODOLOGIA A metodologia definida por nossa equipe foi o modelo em Cascata O modelo em cascata um modelo de desenvolvimento de software seq encial no qual o desenvolvimento visto como um fluir constante para frente como uma cascata atrav s das fases de an lise de requisitos projeto implementa o integra o testes valida o e manuten o de software Portanto o modelo em cascata move se para a pr xima fase somente quando a fase anterior esta completa e perfeita Desenvolvimento de fases no modelo em cascata s o discretas e n o h pulo para frente para tr s ou sobreposi o entre elas Nossa escolha se fundamenta no motivo que nosso cliente se situa em outra cidade e n o teremos muitos contatos ao longo do processo de desenvolvimento do sistema Outra forte raz o que o sistema n o complexo e possui poucos requisitos funcionais os quais est o bem definidos n o necessitando a ado o de outra metodologia Acreditamos tamb m que se houverem poss veis altera es de requisitos essas ser o m nimas n o resultando em altos custos e
3. ES Baseamos nossa coleta de informag es na entrevista com o propriet rio da Farm cia S o Lucas o Sr Valdir Antonio Stokmann Ele explanou o funcionamento b sico do ambiente organizacional Questionado a respeito dos requisitos do sistema ele exp s as necessidades primordiais para implementag o Tamb m foi dado nfase aos principais problemas encontrados no ambiente de trabalho e o que deve ser feito para que eles possam ser superados Resumidamente as principais d vidas foram 1 Quais as atividades mais comuns no dia a dia de uma Farm cia Vendemos medicamentos e produtos gerais recebemos novos itens pagamos faturas de fornecedores e atendemos nossos clientes da melhor forma poss vel 2 Quais os problemas mais comuns encontrados na organizac o Os precos dos produtos s o marcados em apostilas que recebemos dos fornecedores Os dados dos clientes s o armazenados em fichas e essas s o guardadas em um ficheiro Localizar um determinado produto ou cliente requer tempo coisa que n o agrada o cliente O comprovante de compra feito a m o em um simples bloco com o nome e o endere o da Farm cia 3 O que fazer para super los Seria util ter todas essas informa es digitalizadas economizando assim tempo e espa o dando mais dinamicidade s opera es da Farm cia No caso da venda ao cliente um simples comprovante de compra j seria o suficiente 4 Qual o n vel de capacita o dos funcion rios co
4. Ator verifica se cliente tem cadastro na farm cia Caso de Uso Buscar cliente lt lt include gt gt 2 Ator verifica condi o do cliente 3 Ator finaliza compra Extens es la Caso o cliente n o seja cadastrado feito um novo cadastro Caso de uso Cadastrar cliente lt lt extend gt gt Caso de Uso 21 Realizar Vendas Objetivo Controlar a sa da de produtos vendidos Atores Gerente Caixa Pr Condi o O ator precisa estar logado no sistema Cen rio Prim rio 1 Ator escolhe os produtos 2 Ator define a quantidade de produtos 3 O sistema realiza a venda Caso de Uso Controle de Pagamentos lt lt include gt gt 3 Conclui venda Caso de uso Atualizar estoque lt lt include gt gt Cen rio Secund rio 2a Se houver uma quantidade insuficiente de produtos o sistema alertar o ator P s Condi o 1 Oestoque dever estar atualizado 2 A lista de vendas dever estar atualizada Caso de Uso 22 Atualizar Estoque Objetivo Controlar a sa da de produtos vendidos Atores Gerente Caixa Pr Condi o O ator precisa estar logado no sistema Cen rio Prim rio 1 descontado do estoque atual os produtos que foram vendidos P s Condi o O estoque dever estar atualizado 24 9 DIAGRAMA DE CLASSES E uma modelagem muito til para o sistema pois visa permitir a visualiza o das classes que ir o compor o sistema junto com os respectivos atributos e m todos bem c
5. Produto lt lt extend gt gt 2d Remover produto Caso de uso Remover Produto lt lt extend gt gt P s Condic o Lista de Produtos atualizada Caso de Uso 08 Cadastrar Produto Objetivo Adicionar novo produto Ator Gerente Atendente Pr condi o O Ator precisa estar logado no sistema Cen rio Prim rio 1 O ator entra com os dados do produto Caso de uso Verifica o de Cadastros lt lt include gt gt 2 O ator salva os dados do produto P s condi o Lista de produtos atualizada Caso de Uso 09 Remover Produto Objetivo Excluir um produto do banco de dados do sistema Ator Gerente Atendente Pr condi o O Ator precisa estar logado no sistema Cen rio Prim rio 1 O ator informa o nome do produto a ser exclu do 2 Sistema localiza o produto Caso de Uso Buscar produto lt lt include gt gt 3 Produto exclu do e sistema salvo com a nova configura o Extens es la Cadastro inexistente P s condi o Lista de produtos atualizada Caso de Uso 10 Editar Produto Objetivo Alterar dados do produto Ator Gerente Atendente Caixa Pr condi o O Ator precisa estar logado no sistema Cen rio Prim rio 1 O ator informa o nome do produto a ser alterado 2 Sistema localiza o produto Caso de Uso Buscar produto lt lt include gt gt 3 Produto editado e sistema salvo com a nova configura o Extens es la Cadastro inexistente P s condi
6. Recomenda se Processador de 1000 megahertz ou superior 512 megabytes de mem ria RAM ou superior 14 Disco r gido de 20 ou mais gigabytes Placa de v deo Super VGA 800 x 600 ou de maior resolu o e monitor Unidade de CD ROM ou DVD Teclado e mouse gt Aumenta o Custo gt Melhora a Integridade 5 2 2 4 Quanto Portabilidade RNF 01 Portabilidade Operacionaliza o M quina Virtual JAVA Aceita O sistema dever executar em qualquer plataforma desde que exista uma M quina Virtual JAVA para a plataforma pretendida gt Diminui o Custo 5 2 2 5 Quanto ao Custo RNF 01 Custo Operacionaliza o Tecnologia JAVA Aceita O sistema ser desenvolvido utilizando ferramentas gratuitas o que resultar numa economia significativa n o sendo necess rias aquisi es de softwares para a implementa o gt Favorece a Portabilidade gt Diminui a Performance 15 6 MODELAGEM ORGANIZACIONAL USANDO A T CNICA I A nota o I foi desenvolvida como um m todo de modelagem orientado a agentes centrado na caracter stica intencional dos mesmos A t cnica de modelagem I foca nos relacionamentos entre os atores e suas depend ncias Os atores s o vistos como tendo propriedades intencionais tais como objetivos opini es habilidades e compromissos Os atores dependem uns dos outros para cumprir objetivos realizar tarefas e fornecer recursos Atrav s da cooperag o de outros u
7. faz necess ria em v rios ramos da atividade humana Torna se indispens vel para qualquer organiza o o uso de um sistema informatizado para o controle de seus dados Esse projeto tem como objetivo informatizar o sistema de uma Farm cia criando ferramentas que facilitem o seu trabalho di rio de modo a aprimorar o seu desempenho de maneira geral tal como a diminui o de gastos e tempo mas tamb m permitir a possibilidade de um controle mais eficiente de estoques informa es servi os etc Esperamos cumprir nossas metas e prazos ao longo do ano como descrito na documenta o deste trabalho 2 INTRODU O A empresa escolhida pelo grupo para ter como base do projeto de pr tica de Processo de Engenharia de Software II foi a Farm cia S o Lucas localizada em Capanema PR e tem como propriet rio o Sr Valdir Antonio Stokmann A Farm cia ainda n o possui nenhum sistema de informa o implantado Toda a atividade de opera o como venda controle de estoque arquivo de produtos informa o de funcion rios entre outras s o realizadas manualmente Sendo assim prop e se a implanta o de um sistema que otimize todas as fun es realizadas dentro da empresa Fomos at a Farm cia do Sr Valdir e atrav s de uma longa entrevista chegamos s seguintes conclus es O sistema precisa gerenciar os cadastros de clientes de produtos e de funcion rios da empresa Farm cia necessita ter um controle de estoque e
8. inexistente P s condic o Dados do funcion rio atualizados Caso de Uso 05 Buscar Funcion rio Objetivo Consultar dados de um funcion rio Ator Gerente Pr condi o O Ator precisa estar logado no sistema e ter privil gios de gerente Cen rio Prim rio 1 Gerente informa o nome do funcion rio a ser consultado 2 Sistema localiza funcion rio e exibe seus dados na tela 3 A consulta finalizada Extens es la Cadastro inexistente Caso de Uso 06 Verificac o de Cadastros Objetivo Verificar se registro j existe no banco de dados Ator Gerente Caixa Atendente Pr condi o O Ator precisa estar logado no sistema Cen rio Prim rio 1 O sistema verifica se o registro j est cadastrado 2 Sistema envia a resposta para o ator Caso de Uso 07 Controle de Produtos Objetivo Controlar o estoque de produtos Atores Atendente Gerente 20 Pr condic o O Ator precisa estar logado Cen rio Prim rio 1 O Ator clica na aba Controle de Produtos 2 Na aba Controle de Produtos aparecer o as op es Cadastrar Produto Editar Produto Remover Produto e Buscar Produto 3 O ator faz as altera es que deseja 4 O ator salva o sistema com os novos dados Extens es 2a Cadastrar produto Caso de Uso Cadastrar Produto lt lt extend gt gt 2b Editar produto Caso de Uso Editar Produto lt lt extend gt gt 2c Buscar produto Caso de uso Buscar
9. permitir o cadastro a edig o a remog o e a busca de clientes RF 13 Cadastrar Cliente O sistema deve permitir ao ator incluir cadastros de clientes no banco de dados do sistema a partir dos seguintes dados nome do cliente RG CPF sexo saldo gasto saldo devedor e data de nascimento RF 14 Remover Cliente O sistema deve permitir a exclus o de um cliente do banco de dados do sistema RF 15 Editar Cliente O sistema deve permitir alterag o nos dados do cliente RF 16 Buscar Cliente O sistema deve permitir a consulta do cliente pelo nome 11 RF 17 Controle de Pagamentos O sistema deve aceitar pagamento em cheque ou em dinheiro RF 18 Pagamento em Dinheiro O sistema deve aceitar pagamento em dinheiro somente vista RF 19 Pagamento em Cheque O sistema deve permitir que clientes comprem a prazo utilizando cheque desde que tenham se cadastrado previamente na Farm cia RF 20 Verificar Situac o do Cliente O sistema deve realizar uma verifica o para achar poss veis pend ncias do cliente na Farm cia RF 21 Realizar Vendas O sistema deve permitir que um usu rio escolha os produtos e quantidade dos mesmos e assim realize vendas RF 22 Atualizar Estoque O sistema deve controlar a sa da de produtos que s o vendidos a fim de notificar uma poss vel falta dos mesmos 5 2 Requisitos N o Funcionais Os Requisitos N o Funcionais s o aqueles que expressam como deve ser fei
10. 15 08 09 Implementa o do MVC Model View Controller para as vendas Implementa o do MVC Model View Controller para os pagamentos ATO 09 4 In cio 16 08 09 T rmino 31 08 09 Revis o de todos os m dulos implementados ATO 10 In cio 01 09 09 T rmino 15 09 09 Integra o Os componentes do software separados s o combinados em um todo ATO 11 In cio 16 09 09 T rmino 15 11 09 Teste e Depura o O software investigado a fim de fornecer informa es sobre sua qualidade em relag o ao contexto em que ele deve operar Isso inclui o processo de utilizar o produto para encontrar seus defeitos ATO 12 In cio 01 12 09 T rmino 15 12 09 Pr Implantag o Verificag o dos equipamentos dispon veis desktops licengas banco de dados perif ricos e etc e adequac o ao requerido pelo software Realizag o de testes para verifica o da integridade dos dados e com os funcion rios a fim de verificar se tudo est correto para a implanta o ATO 13 In cio 16 12 09 T rmino 31 12 09 Treinamento Familiariza o dos usu rios com o software Poss vel cria o de grupos de conhecimento ou seja treinamento em conjunto dos funcion rios de um mesmo departamento Os programadores ser o os disseminadores do treinamento para os grupos ATO 414 In cio 01 01 10 T rmino 15 01 10 Implanta o Passagem do software para a produ o Realiza o das altera es na rotina
11. Funcion rios O sistema deve permitir o cadastro a edi o a remo o e a busca de funcion rios RF 02 Cadastrar Funcion rio O sistema deve permitir o cadastro de funcion rio a partir de seus dados pessoais nome RG CPF cargo sal rio data de nascimento data de admiss o nome de usu rio e senha RF 03 Remover Funcion rio O sistema deve excluir o registro do funcion rio especificado RF 04 Editar Funcion rio O sistema deve permitir altera es nos dados do funcion rio escolhido RF 05 Buscar Funcion rio O sistema deve permitir a busca de um funcion rio atrav s de seu nome ou CPF RF 06 Verifica o de Cadastros O sistema deve verificar se um registro de cadastro j existe no banco de dados RF 07 Controle de Produtos O sistema deve permitir o cadastro a edi o a remo o e a busca de produtos 10 RF 08 Cadastrar Produto O sistema deve permitir ao ator incluir produtos farmac uticos no banco de dados do sistema a partir dos seguintes dados nome do produto pre o de custo pre o de venda lote fornecedor quantidade data de fabricag o e data de validade RF 09 Remover Produto O sistema deve permitir a exclus o de um produto do banco de dados do sistema RF 10 Editar Produto O sistema deve permitir alterag o nos dados do produto RF 11 Buscar Produto O sistema deve permitir consulta do produto pelo nome RF 12 Controle de Clientes O sistema deve
12. UNIOESTE Universidade Estadual do Oeste do Paran CCET Centro de Ci ncias Exatas e Tecnol gicas u n loeste Colegiado de Inform tica Universidade Estadual do Oeste do Paran Curso de Bacharelado em Inform tica PROJETO DA DISCIPLINA PES II Processo De Engenharia de Software II CASCAVEL 2009 Alessandro Rodrigo Franco Fernando Luiz Grando Fernando Martins SISTEMA FARM CIA Parte 01 Especificac o de Requisitos e Modelagem Orientada a Objeto Professor Victor Francisco Araya Santander CASCAVEL 2009 NDICE L Motiva o NS 04 2 Introdu o Nr ii 05 exin Mera Di Sd aa DU i 06 Ae Metodolboia iia 09 5 An lise Misi M 10 S L Requisitos FUNCIONAIS isis 10 5 2 Requisttos N O FUNCIONAIS E nut aM e uat viU dul 13 5 2 T Reguisit s d Process ads 13 5 2 1 1 Quanto a Implementa o uu est ree reete e eoe qa Y unes ane et i I5 5 2 2 Requisitos do Produto iii iii eR aera 13 5 2 2 1 Quanto Seguran a dos Dados eese 13 5 2 2 2 Quanto Usabilidade 3 eene 14 5 2 2 3 Quanto Performance ooononcncncnnnnnnnanononononnnncnnnnononononcononnnnnnnnnnos 14 5 2 2 4 Quanto Portabilidade sese 15 5 2 25 2 Quanto 30 Custo aa iii 15 6 Modelagem Organizacional usando a T cnica dg esee 16 6 1 Modelo de Depend ncias Estrat gicas SD concocnnnc
13. an ar este fim O meio geralmente expresso na forma de uma tarefa que incorpora a no o de como fazer alguma coisa Uma liga o de decomposi o de tarefa utilizada para descreve os componentes de uma tarefa Descri o Textual O ator expandido foi o Sistema pois ele a parte central do esquema e prov todas as funcionalidades para os outros atores O principal objetivo do sistema consiste em controlar os cadastros de uma Farm cia Esta tarefa ser composta de v rias partes e Rapidez nos cadastros realizados pelo funcion rio para um maior aproveitamento do tempo e Interface agrad vel aumentando a usabilidade por parte dos funcion rios e Seguran a para o gerente que possui funcionalidades especiais no sistema e Cadastro exclus o consulta e altera o de dados do banco de dados Todas as op es passaram por uma verifica o antes para que n o haja dados duplicados no sistema e para que dados sejam exclu dos erroneamente e Controle de pagamento com op es de pagamento em dinheiro e cheque gt Figura 2 17 7 MODELAGEM NFR FRAMEWORK O modelo foi proposto por Chung et al 2000 Universidade de Toronto Ele fornece uma representa o sistem tica e global dos requisitos n o funcionais tratando os de forma expl cita como metas a serem atingidas e Baseado na an lise qualitativa dos requisitos n o funcionais 7 1 SIG O SIG Softgoal Interdependency Graph representa o inter relaciona
14. ccnonaconanonononononnnnnonnncncnnnnncnnnnnrnnnncrnnncccnnnnno 16 6 2 Modelo de Raz es Estrat gicas SR uester e nen teet eae anta sense eee gea 17 Tae Modelagem NFR Framework 1o ds 18 E e of t tS 18 8 Diagrama de Casos de USO ueteres estet teen eese gu e esa EE NE ga et Pe TYPE a ed nenas 19 8 1 Descri es Textuais dos Casos de Uso 4 eere 19 9 Diasrama deClasses O ita 23 9 1 Descri es Textuais das Classes ans US Li DS a ia a 25 A A Oa tti ep E a da ls 27 Figura 1 Modelo de Depend ncias Estrat gicas SD eee 27 Figura 2 Modelo de Raz es Estrat gicas SR essere 28 Figura 3 SIG Softgoal Interdependency Graph 29 Figura 4 Diagrama de Casos de Uso ausis s at reside een UR Reto santas ando 30 Figura 4 1 Controle de Clientes ua dial 30 Figura 4 2 Controle de Funcion rios id aid pd 30 Figura 4 3 Controle de Pagamento a ideada 31 Figura 4 4 Controle de Produtos ocoooccnnncccconcccnoncononcconnnnncnnnnnonononononononnncnnnncnnonnss 31 Figura 4 5 Controle de Vendas sisse etta sees teste eise Sh Reed dde an 32 Figura o Dia stama de 135888 an 33 MA erc ra 34 12 Apendice A A 33 LS Apendi e B Ncc M esaa 35 14 Referencias Bibliogr ficas ai A A A e EEEE aE 37 1 MOTIVA O z Tendo em vista que atualmente o computador uma ferramenta de trabalho quase que indispens vel a informatiza o de sistemas se
15. e Cadastros 30 Figura 4 3 Controle de Pagamento Pagamento em Dinheiro Y Y lt lt extepl gt gt Gerente Controle de Pagamento Verificar Situac o do Cliente Y N A Y lt lt exend gt gt lt lt include gt N Pd Caixa Pagamento em Cheque Figura 4 4 Controle de Produtos Remover Produto Buscar Produto lt lt include gt 7 ja a 1 A lt lt exgnd gt Editar Produto Atendente s lt lt include gt gt Verificac o de Cadastros 31 Figura 4 5 Controle de Vendas Pagamento em Dinheiro lt lt include gt gt Verificar Situac o do Cliente l include Pagamento em Cheque 32 Figura 5 Diagrama de Classes E Funcionario private int codigo E Produto private String nome Aribulos private Data nascimento E Gerente private int codigo private Data admissao public Caixa private String nome private String fomecedor private String lote private int quantidade private Data fabricacao private Data vencimento private double preco Custo private double precoVenda private String observacao private char tarja private String telefone private String celular private String cpf private String rg private double salario private int sexo private int permissao private String observacao public int adicionaCliente Cliente cliente ient public Funci
16. e tem prioridade exclusiva no cadastro de funcion rios e ainda herda as prioridades do Caixa e do Atendente e Atendente que necessita de usabilidade do sistema para um atendimento gil aos clientes podendo adicionar produtos e criar uma lista de compras do cliente e Caixa que controlar os cadastros de clientes as realiza es de vendas os pagamentos e os 16 cheques e Sistema ter o objetivo de viabilizar as operag es acima gt Figura 1 6 2 Modelo de Raz es Estrat gicas SR O modelo de depend ncia estrat gica mostra somente os relacionamentos externos entre os atores No modelo de raz o estrat gica temos uma representa o e uma racionaliza o mais expl cita sobre os interesses dos atores e de como estes interesses podem ser atendidos ou afetados pelos diversos sistemas No modelo SR temos uma vis o interna dos atores proporcionando um n vel de detalhamento maior do modelo Os elementos intencionais objetivos tarefas recursos e objetivos soft aparecem no modelo SR como elementos internos ligados por relacionamentos meio fim e decomposi o de tarefas Estes relacionamentos proporcionam uma representa o explicita das raz es por tr s das depend ncias entre os atores e quais s o alternativas por tr s dos processos No modelo SR s o introduzidas duas classes de liga es liga es meio fim e decomposi o de tarefas Uma liga o meio fim indica um relacionamento entre um fim e um meio para alc
17. ficiente Quanto ao pagamento realizado no caixa o sistema ter que possuir op es para pagamento em dinheiro e em cheque Este ltimo dever ser autorizado apenas ap s verifica o de pend ncias no estabelecimento O sistema precisa ter boa usabilidade para o f cil aprendizado de novos usu rios seguran a e a confiabilidade dos dados s o requisitos indispens veis para esse projeto Visto isso o sistema possuir uma hierarquia de privil gios entre os usu rios que forem acessar os dados cadastrados na Farm cia O desempenho de grande import ncia ao sistema pois geralmente em uma Farm cia os clientes precisam de atendimento r pido e eficaz Com base nas informa es adquiridas na entrevista elaboramos esse documento que possui a descri o bem detalhada dos requisitos do sistema Nosso projeto ser modelado com base nos seguintes estudos Modelagem Organizacional utilizando a T cnica I diagramas SD e SR a Modelagem NFR Framework grafo SIG Diagrama de Casos de Uso e Diagrama de Classes 3 CRONOGRAMA ATO_01 In cio 02 03 09 T rmino 09 03 09 Discuss o sobre o sistema a ser implementado ATO 02 In cio 10 03 09 T rmino 17 03 09 Obten o do conhecimento sobre o que vai ser desenvolvido ATO 083 In cio 18 03 09 T rmino 25 03 09 Reuni es para escolha da metodologia de engenharia de software adotada ATO 904 In cio 26 03 09 T rmino 30 04 09 E
18. grande perca de tempo N o mediremos esfor os para que como uma forma de avalia o do projeto consigamos lev lo at o pr prio cliente mesmo sabendo que esse m todo de avalia o n o ser frequente tendo em vista a dificuldade de comunica o entre as partes conforme foi citado anteriormente Caso apare am inconvenientes em determinada fase do projeto a manuten o da mesma ser efetuada e quando conclu da ser apresentada novamente ao cliente como forma de garantir a exatid o ao que foi solicitado e para que possamos seguir adiante com o processo de desenvolvimento Visto a baixa experi ncia do grupo de desenvolvimento caso a metodologia acima citada n o se encaixe de maneira eficiente durante o projeto pretendemos adapt la o quanto necess rio Para isso poderemos modificar a id ia para um desenvolvimento mais gil criando itera es adicionais que n o estavam no planejamento inicial 5 AN LISE DE REQUISITOS 5 1 Requisitos Funcionais Os Requisitos Funcionais s o aqueles que descrevem o comportamento do sistema suas a es para cada entrada ou seja aquilo que descreve o que tem que ser feito pelo sistema Devem ser o c rebro do projeto j que descrevem as funcionalidades que o sistema deve dispor Abaixo est o listados e descritos os requisitos funcionais do sistema referenciados da seguinte maneira RF id Nome do Requisito Funcional Descri o RF 01 Controle de
19. licitag o e An lise de Requisitos Realizado junto empresa atrav s de question rio e entrevista profunda e precisa identificando os fatos que comp em os requisitos do sistema de forma a prover o mais correto e mais completo entendimento do que demandado o software ATO 9085 In cio 01 05 09 T rmino 15 05 09 Debate a respeito da linguagem de programa o a ser utilizada e as poss veis tecnologias adicionais ATO 906 In cio 16 05 09 T rmino 01 06 09 Prot tipo N o Funcional Interface gr fica principal ATO 07 In cio 02 06 09 T rmino 16 06 09 Modelagem do banco de dados Modelo L gico e Conceitual ATO 08 In cio 17 06 09 T rmino 19 07 09 Projeto de Software Transforma o dos resultados da An lise de Requisitos em um conjunto de documentos capazes de serem interpretados diretamente pelo programador ATO 909 In cio 01 07 09 T rmino 31 08 09 Implementa o Elabora o e prepara o dos m dulos necess rios para a execu o do sistema ATO 909 1 In cio 01 07 09 T rmino 15 07 09 Implementa o do MVC Model View Controller para os funcion rios Implementa o do MVC Model View Controller para os clientes ATO 09 2 In cio 16 07 09 T rmino 31 07 09 Implementa o do MVC Model View Controller para os produtos Implementa o do MVC Model View Controller para o estoque ATO 09 3 In cio 01 08 09 T rmino
20. m O ou mais cheque o que representa a rela o do mesmo com a classe Cheque Classe Venda Classe que cont m atributos e m todos referentes opera o de venda A mesma se relaciona com um ou mais itens de venda classe Itens Venda outra rela o importante de um para um com a classe Pagamento A classe Venda se relaciona a um cliente e a um caixa Classe Produto Esta classe cont m atributos e fun es referentes aos produtos tais como codigo quantidade tarja pre o etc Um produto est associado com a classe ItemVenda com a cardinalidade um para um Os produtos est o associados com a classe do Gerente que a classe encarregada de controlar os produtos 25 Classe ItemVenda Esta classe cont m os atributos quantidade e produto os quais indicam quantos produtos de um determinado tipo Est relacionado de um para um com a classe Produto e uma outra rela o com a classe Venda podendo ter um ou mais objetos do tipo ItemVenda Classe Cheque Esta classe cont m as caracteristicas para identificar um cheque de um cliente seus atributos s o o n mero do cheque valor n mero da conta e data de validade Esta classe se relaciona com apenas um cliente Classe Pagamento A classe Pagamento cont m os atributos de um pagamento tipoPagamento cheque dinheiro status do pagamento efetuado pendente e o valor Esta classe se associa com um objeto da classe Venda 26 10 FIGURAS Figura 1 Modelo de Depend
21. m ator pode alcan ar objetivos que ser o dif ceis de serem alcan ados sozinho A t cnica I consiste de dois modelos o modelo de Depend ncias Estrat gicas SD Strategic Dependency e o modelo de Raz es Estrat gicas SR Strategic Rationale 6 1 Modelo de Depend ncias Estrat gicas SD O modelo de Depend ncias Estrat gicas uma rede de relacionamentos de depend ncia entre atores O modelo SD foca na captura na estrutura intencional de um processo ou seja na captura das motiva es e inten es por tr s das atividades e fluxos em um processo O modelo consiste numa s rie de n s e links Cada n representa um ator Um ator uma entidade ativa que realiza ag es para atingir determinados objetivos Cada link entre dois atores indica que um ator depende do outro para de alguma forma cumprir algum objetivo O ator que depende de outro chamado de depender e o ator respons vel por cumprir a depend ncia chamado de dependee O objetivo da depend ncia denominado dependum Atrav s da depend ncia o depender capaz de alcan ar objetivos que n o seria capaz de alcan ar sozinho Existem quatro tipos de depend ncias depend ncia de objetivo goal depend ncia de tarefa task depend ncia de recurso resource e depend ncia de objetivo soft soft goal Descri o Textual Em nosso modelo focamos nossa aten o em quatro atores e Gerente que necessita de acesso seguro e qu
22. m rela o Inform tica Os funcion rios possuem o n vel b sico de um usu rio dom stico Quanto mais simples for o sistema melhor vai ser para que eles aprendam r pido 5 Em quais aspectos a informatiza o do sistema ajudaria a empresa Todos nossos registros ficam guardados em ficheiros ou s o apostilas com pre os Uma informatiza o resultaria em ganho de tempo e espa o 6 O que se espera de um software para o gerenciamento de uma Farm cia Nesse caso espera se um controle eficaz de cadastro de dados no sistema com fun es de cadastro altera o exclus o e consulta de dados Espera se ainda que o sistema tenha uma usabilidade de f cil absor o por parte de quem o usa 35 13 AP NDICE B FORMUL RIO DE RELAT RIO DA EQUIPE Descrig o de pap is e contribuig o de cada membro da equipe N o houve uma divisio r gida entre os integrantes da equipe Optamos por um desenvolvimento de projeto progressivo e igualit rio NOME ESFORCO NA EQUIPE 33 3 Alessandro Rodrigo Franco 33 3 Fernando Luiz Grando 33 3 Fernando Martins 36 14 REFER NCIAS BIBLIOGR FICAS http www inf unioeste br victor processolII acessado em Abril 2009 http www inf unioeste br ivonei PesI acessado em Abril 2009 PRESSMAN R S Engenharia de Software 6 edi o McGraw Hill 2006 37
23. mento entre os requisitos n o funcionais O uso do NFR Framework feito atrav s da constru o incremental e interativa de grafos SIG Eles descrevem a interdepend ncia entre softgoals e como eles s o decompostos e Inspirado nas estruturas de rvore e ou para solu o de problemas Descri o Textual Em nosso grafo SIG consideramos os seguintes requisitos n o funcionais e suas respectivas operacionaliza es necess rios para a empresa obter um padr o de qualidade consider vel e Usabilidade Interface Amig vel Teclas de Atalho Livre Acesso s Informa es Ajuda Manual ou Online e Performance Hardware Recomendado e Custo Tecnologia JAVA e Portabilidade M quina Virtual JAVA e Seguran a Integridade Pol tica de Backup Confidencialidade Pol tica de Login e Senha Uso de Criptografia Para maiores detalhes consulte a documenta o da an lise de requisitos em 5 2 Requisitos N o Funcionais localizada na p gina 11 desse mesmo documento gt Figura 3 18 8 DIAGRAMA DE CASOS DE USO O Diagrama de Casos de Uso descreve a funcionalidade proposta para o sistema Segundo Ivar Jacobson Object Oriented Software Engineering A Use Case Driven Approach 1992 podemos dizer que um Caso de Uso um documento narrativo que descreve a seq ncia de eventos de um ator que usa um sistema para completar um processo Um Caso de Uso representa uma unidade discreta da interag o ent
24. ncias Estrat gicas SD Atendente Controle Cadastros Clientes 27 SR es Estrat gicas Modelo de Raz Figura 2 Tes anbal op og eng y m wa Jaqa3ay oyuawebeg 9p ajoquo oJiauuq wa 1aqa3a oueuopunJ 1219 saqua SOJSepe ajoguos saqua Je 0qUO oueuornun J iinpur oneuonuny npxa ayua 1e4a3lg oneuonuny 4e o413u0 aquel Jejnsuo soueuopunJ ap ajoquo E3ueanbac apepilgesn c9 sojnpo4d sjouo5 ousepe gt ap enuazsix3 ARIMA ojnpo4d Aejisuo so3npod pr sonpo4d ap ajoquo IA dcl 28 vA enia eumnbety ppepusuolay SJemp4eH VAVC eibojoua ogSezyn ep enuely apepilqeyiod auu epn g drbpeg ap enyod Ja eBiug 332 4934 abepijenuapijuo oue ap sepa Eyuas a uibo ap EOS saQ euJoJuT opeq sop eSueinbac se 05sady 34417 SIG Softgoal Interdependency Graph Figura 3 29 Figura 4 Diagrama de Casos de Uso Figura 4 1 Controle de Clientes Editar Cliente lt lt include gt gt Verificac o de Cadastros Figura 4 2 Controle de Funcion rios Remover Funcion rio E A extendz 7 s include gt gt Gerente lt lt extend gt gt Editar Funcion rio lt lt include gt Verificac o d
25. ntos Objetivo Controlar as formas de pagamento Ator Caixa Gerente Pr condic o O Ator precisa estar logado Cen rio Prim rio 1 O Ator clica na aba Controle de Pagamento 2 O Ator escolher entre as seguintes op es Cheque ou Dinheiro Extens es 2a Pagamento em cheque Caso de uso Pagamento em cheque lt lt extend gt gt 2b Pagamento em dinheiro Caso de uso Pagamento em dinheiro lt lt extend gt gt P s condi o Pagamento efetuado Caso de Uso 18 Pagamento em Dinheiro Objetivo Receber do cliente em dinheiro Ator Caixa Gerente Pr Condi o O ator precisa estar logado no sistema Cen rio Prim rio 1 Ator informa o valor da compra ao sistema 2 Ator informa valor dado pelo cliente 3 Sistema informa se h necessidade de troco 23 Caso de Uso 19 Pagamento em Cheque Objetivo Receber a compra em cheque Ator Caixa Gerente Pr Condic o O ator precisa estar logado no sistema Cen rio Prim rio 1 Ator informa o valor da compra ao sistema 2 O ator verifica o cadastro do cliente Caso de uso Verificar situac o do cliente lt lt include gt gt 3 Ator informa valor dado pelo cliente 4 Sistema informa se h necessidade de troco Caso de Uso 20 Verificar Situac o do Cliente Objetivo Verificar se cliente tem alguma pend ncia no estabelecimento Ator Caixa Gerente Pr Condic o O ator precisa estar logado no sistema Cen rio Prim rio 1
26. omo mostrar como as classes se relacionam complementam e transmitem informac es entre si gt Figuras 9 1 Descri es Textuais das Classes Classe Funcionario Essa classe representa o funcion rio da Farm cia com os seus atributos do mundo real Possui os m todos para cadastrar editar remover e buscar clientes O atributo permissao fundamental para essa classe atrav s dele sabemos quais opera es o funcion rio pode executar Classe Caixa uma especializa o da classe Funcionario adicionando se os m todos para adicionar remover e modificar clientes realizar vendas e os m todos de pagamentos Um caixa est associado a O ou mais clientes classe Cliente Um caixa pode fazer O ou mais vendas o que reflete sua rela o com a classe Venda Classe Gerente uma especializa o da classe Caixa Adiciona se a classe os m todos adicionar remover e modificar funcion rios e produtos O gerente tem o controle dos produtos ou seja ele se relaciona com a classe Produto com cardinalidade de 1 a N Classe Cliente uma classe onde seus atributos dizem respeito aos dados comuns a todos os indiv duos Inclui tamb m m todos para consultar saldo e contas do indiv duo Um cliente efetua O ou mais compras logo o mesmo esta associado classe Venda A associa o do cliente com a classe Caixa se deve ao fato dO cliente ter que efetuar alguma compra pois a mesma compra feita atrav z de um caixa Um cliente te
27. onario public int getCodigo public Produto public int getCodigo public void set Codigo int val public etNome Ei cliente Ed venda Atributos Atributos private int codigo private Cliente cliente private int sexo private temVenda produtos 1 private int status private Data data private Data nascimento private Data entrada p emen private String telefone private String celular private String cpf private String rg private double saldoGasto private double saldo Devedor Atributos private int tipoPagamento private int status private double valor 1 private String numero private double valor private String conta private Data validade 33 11 CONCLUS O Em busca de um f cil entendimento do funcionamento do sistema utilizamos a T cnica I para elaborar os Modelos de Depend ncias e de Raz es Estrat gicas Para melhor esclarecimento de como satisfazer os requisitos n o funcionais utilizamos a modelagem NFR Framework com o grafo SIG Usamos tamb m ferramentas UML para a construc o do modelo de Casos de Uso e Diagrama de Classes a fim de visualizar as itera es entre os usu rios e o sistema Procuramos atrav s deste documento atender a todos os requisitos necess rios para a satisfa o das necessidades da empresa Esta documenta o nos ajudar e servir de apoio para a implementa o do nosso sistema 34 12 AP NDICE A COLETA DE INFORMAC
28. re um usu rio humano ou m quina e o sistema Um Caso de Uso uma unidade de um trabalho significante Cada Caso de Uso tem uma descrig o da funcionalidade que ir ser constru da no sistema proposto Um Caso de Uso pode usar outra funcionalidade de Caso de Uso ou estender outro Caso de Uso com seu pr prio comportamento Casos de Uso s o tipicamente relacionados a atores Um ator um humano ou entidade m quina que interage com o sistema para executar um significante trabalho gt Figura 4 8 1 Descri es Textuais dos Casos de Uso Caso de Uso 01 Controle de Funcion rios Objetivo Controlar os cadastros dos funcion rios Ator Gerente Pr condi o O Ator precisa estar logado e ter privil gios de gerente Cen rio Prim rio 1 Gerente clica na aba Controle de Funcion rios 2 Na aba Controle de Funcion rios o Gerente escolhe entre Cadastrar Funcion rio Editar Funcion rio Remover Funcion rio ou Buscar Funcion rio 3 Gerente faz as altera es que deseja 4 Gerente salva o sistema com os novos dados Extens es 2a Adicionar funcion rio Caso de uso Cadastrar funcion rio lt lt extend gt gt 2b Alterar funcion rio Caso de uso Editar funcion rio lt lt extend gt gt 2c Consultar funcion rio Caso de uso Buscar funcion rio lt lt extend gt gt 2d Excluir funcion rio Caso de uso Remover funcion rio lt lt extend g
29. rifica o de Cadastro lt lt include gt gt 2 Gerente salva os dados do novo cliente P s condi o Lista de clientes atualizada Caso de Uso 14 Remover Cliente Objetivo Excluir dados do cliente Ator Gerente Caixa Pr condi o O Ator precisa estar logado no sistema Cen rio Prim rio 1 Ator informa o nome do cliente a ser exclu do 2 Sistema localiza o cliente Caso de Uso Buscar cliente lt lt include gt gt 3 Cliente exclu do e sistema salvo com a nova configura o 22 Extens es la Cadastro inexistente P s condic o Lista de clientes atualizada Caso de Uso 15 Editar Cliente Objetivo Alterar dados de um cliente Ator Gerente Caixa Pr condic o O Ator precisa estar logado no sistema Cen rio Prim rio 1 Ator informa o nome do cliente a ser alterado 2 Sistema localiza o cliente Caso de Uso Buscar cliente lt lt include gt gt 3 Cliente editado e sistema salvo com a nova configurac o Extens es la Cadastro inexistente P s condic o Dados do cliente atualizados Caso de Uso 16 Buscar Cliente Objetivo Consultar dados de um cliente Ator Gerente Caixa Pr condic o O Ator precisa estar logado no sistema Cen rio Prim rio 1 Ator informa o nome do cliente a ser consultado 2 Sistema localiza funcion rio e exibe seus dados na tela 3 A consulta finalizada Extens es la Cadastro inexistente Caso de Uso 17 Controle de Pagame
30. rmiss o apropriada gt Prejudica a Performance RNF 02 Integridade Operacionaliza o Pol tica de Backup Aceita O sistema dever garantir a integridade dos dados a partir de uma pol tica de backup gt Aumenta o Custo 13 5 2 2 2 Quanto Usabilidade RNF 01 Usabilidade Operacionaliza o Interface Amig vel Aceita O sistema possuir uma interface gr fica amig vel com informa es e funcionalidades objetivas facilitando a vida do usu rio gt Prejudica a Performance Operacionaliza o Teclas de Atalho Aceita O sistema possuir teclas de atalho para acesso mais r pido aos dados e as funcionalidades mais utilizadas Operacionaliza o Livre Acesso s Informa es Recusada O sistema disponibilizar acesso s informa es sem qualquer tipo de restri es hier rquicas para as mesmas gt Prejudica a Confidencialidade RNF 02 Ajuda Operacionaliza o Manual de Utiliza o Aceita O sistema possuir um manual de utiliza o do software seja ele impresso ou em um sub menu do pr prio software Operacionaliza o Ajuda Online Recusada O sistema disponibilizar um site para suprir qualquer d vida em rela o usabilidade do software gt Aumenta o Custo 5 2 2 3 Quanto Performance RNF 01 Performance Operacionaliza o Hardware Recomendado Indecisa A rapidez de execu o do sistema depender dos recursos do computador utilizado
31. t gt P s condi o Lista de funcion rios atualizada Caso de Uso 02 Cadastrar Funcion rio Objetivo Adicionar novo funcion rio Ator Gerente Pr condi o O Ator precisa estar logado no sistema e ter privil gios de gerente Cen rio Prim rio 1 Gerente entra com os dados do funcion rio Caso de Uso Verifica o de Cadastros lt lt include gt gt 2 Gerente salva os dados do novo funcion rio P s condi o Lista de funcion rios atualizada 19 Caso de Uso 03 Remover Funcion rio Objetivo Excluir dados do funcion rio Ator Gerente Pr condic o O Ator precisa estar logado no sistema e ter privil gios de gerente Cen rio Prim rio 1 Gerente informa o nome do funcion rio a ser exclu do 2 Sistema localiza o funcion rio Caso de Uso Buscar funcion rio lt lt include gt gt 3 Funcion rio exclu do e sistema salvo com a nova configurac o Extens es la Cadastro inexistente P s condic o Lista de funcion rios atualizada Caso de Uso 04 Editar Funcion rio Objetivo Alterar dados de um funcion rio Ator Gerente Pr condic o O Ator precisa estar logado no sistema e ter privil gios de gerente Cen rio Prim rio l Gerente informa o nome do funcion rio a ser alterado 2 Sistema localiza o funcion rio Caso de Uso Buscar funcion rio include 3 Funcion rio editado e o sistema salvo com a nova configurac o Extens es la Cadastro
32. to Em geral se relacionam com padr es de qualidade como confiabilidade performance robustez etc S o muito importantes pois definem se o sistema ser eficiente para a tarefa que se prop e a fazer ou n o Um sistema ineficiente certamente n o ser usado Neles tamb m s o apresentados restri es e especifica es de uso para os requisitos funcionais Segue abaixo a rela o e descri o dos requisitos n o funcionais do sistema conforme o padr o a seguir 12 RNF id Nome do Requisito N o Funcional Operacionaliza o Nome da Operacionaliza o Descri o da Operacionaliza o 5 2 1 Requisitos do Processo Requisitos referentes ao modo de desenvolvimento 5 2 1 1 Quanto a Implementac o Tecnologia JAVA O sistema dever ser implementado na linguagem JAVA 5 2 2 Requisitos do Produto Requisitos referentes s caracter sticas e qualidades 5 2 2 1 Quanto Seguranca dos Dados RNF 01 Confidencialidade Operacionalizac o Pol tica de Login e Senha Aceita O sistema dever garantir a confidencialidade dos dados a partir da implementa o de um sistema de login e senha em que cada funcion rio ter acesso s funcionalidades e aos dados conforme seu cargo gt Prejudica a Usabilidade Operacionaliza o Uso de Criptografia Recusada O sistema utilizar um esquema de criptografia para a prote o dos dados a fim de garantir o acesso exclusivo a quem tenha pe
Download Pdf Manuals
Related Search