Modelagem de um sistema Farmacia-Muhongo
Introducão
A evolução e a globalização do comércio propiciaram uma série de benefícios aos homens, mas também diversos problemas. Para controlar e gerir as farmacias, então, surge o Sistema de Informação (SI), cujo objetivo é auxiliar os profissionais farmaceuticos na obtenção de informações de cada cliente. A maior vantagem da utilização de um SI é poder proporcionar melhor atendimento e tratamento de problemas de saúde dos pacientes, obtendo maior controle e rapidez nas informações necessárias. A farmácia Muhongo localiza se no cazenga vende produtos fármacos e outros produtos como cosméticos e alimentos industrializados para Clientes Particulares e Personalizados.
Conforme Sabbatini (2000) : “isso efetivamente centralizará o prontuário médico em um único lugar da rede e permitirá que profissionais de saúde e o próprio cliente possam acessá-lo de qualquer ponto do mundo [...]”.
De acordo com Furuie (2002), a disponibilização de um prontuário de sistema de gestão de farmácias, que apresente de forma integrada todas as informações relevantes dos clientes tem sido a principal meta das equipes de informática de grandes farmácias em todo o mundo.
Situação problemática
A Farmácia Muhongo ainda não possui nenhum sistema de informação implantado. Toda a atividade de operação como cadastro de clientes personalizados, a 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 mesma.
Descrição do problema
Na farmácia Muhongo o atendimento dos seus clientes é feito de forma manual, o que causa muita perda de informação,desorganização e demora, impedindo assim um trabalho eficiente. Sempre que chega um cliente na farmácia Muhongo há uma ligeira dificuldade em encontrar a localização exacta dos fármacos, e mesmo quando este é encontrado, há dificuldades em vender este fármaco pois nem sempre o farmacêutico sabe os novos preços actualizados na farmácia tão pouco a origem e a qualidade dos fármacos, já que os preços variam de acordo com a origem do fármaco. Como existe um regime de turno na farmácia logo o farmacêutico que entra no dia seguinte depois da sua folga, fica desactualizado sobre as novas actualizações como novos preços, novos produtos, os clientes reclamam da demora porque enquanto um dos farmacêutico consulta o único livro de anotações que eles têm na farmácia o outro espera até que a consulta termina para começar a consultar. Quando faz-se um atendimento personalizado (cliente personalizado) o farmacêutico deve anotar o nome do cliente,a data, hora, os medicamentos que este requisitou e fazer uma copia da receita medica do cliente. Na maior parte das vezes quando o farmacêutico esquece de fazer as devidas anotações a cobrança é mal feita resultando assim em perda de valores monetários e consequentemente prejuízo. Para clientes particular somente é necessário o nome completo e a receita.
Problema Ciêntifico
O sistema precisa gerenciar os cadastros de clientes personalizados, de produtos e de funcionários da farmacia. A Farmácia Muhongo necessita ter um controle de estoque eficiente. O sistema precisa ter boa usabilidade, para o fácil aprendizado de novos usuários. A 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.
Objecto de estudo
Controlar o cadastro de clientes personalizados, a venda de produtos farmacos para os clientes personalizados e particulares bem como o atendimento dos mesmos.
Campo de acção
Controlo no atendimento e cadastramento dos clientes e a venda dos produtos farmacos e outros.
Hipótese
Quanto aos clientes, o sistema terá que possuir opções para cliente personalizado, e cliente particular e e também poderá melhorar a demora no atendimento dos clientes.
Objectivo Geral
Desenvolver um sistema para o controlo de vendas de produtos farmacos para clientes personalizados e particulares e Analisar o processo de atendimento permitindo para que haja um atendimento eficaz.
Objectivos especificos
Fazer um estudo preliminar do sistema automatizado para o controlo no atendimento de clientes.
Desenhar uma base de dados com toda a informação necessaria dos clientes, produtos e vendas para garantir o controlo a diferentes serviços.
METODOLOGIA
A metodologia definida pelo nosso grupo 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, desenho, implementaçã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. 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 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.
Fluxos de requisitos
Definir o que o sistema deve fazer, para o qual são identificadas as capacidades e limitações impostas necessários.
· Registrar os clientes.
· Localizar produto.
· Vender produto.
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:
Processo seleciona produtos farmácos
Requisito funcional1- O sistema deve buscar produto.
Requisito funcional2- O sistema deve adicionar para a venda.
Requisito funcional3- O sistema deve visualizar produto.
Requisito funcional4- O sistema deve alterar a quantidade de produto.
Requisito funcional5- O sistema deve exibir nome do produto farmaco, quantidade, preço, total a pagar.
Processo seleciona realiza venda
Requisito funcional1- O sistema deve identificar cliente.
Requisito funcional2- O sistema deve registrar cliente.
Requisito funcional3- O sistema deve permitir o cliente selecionar opção de pagamento.
Requisito funcional4- O sistema deve controlar a saída de produtos que são vendidos, a fim de notificar uma possível falta dos mesmos.
Requisito funcional5- O sistema deve registrar nome, data, hora, produto e quantidade ao confirmar a solicitação.
Processo seleciona clientes
Requisito funcional1- O sistema deve permitir o cadastro, a edição, a remoção, a gravação de clientes.
Requisito funcional2- O sistema deve permitir ao usuario incluir cadastros de clientes no banco de dados do sistema, a partir dos seguintes dados: nome , morada, telefone, sexo, data.
Requisito funcional3- O sistema deve permitir a identificação de tipo de cliente.
Requisito funcional4- O sistema deve pemitir apenas cadastrar clientes personalizados.
Requisitos não funcionais
Os Requisitos Não-Funcionais são aqueles que expressam como deve ser feito. Em geral se relacionam com padrões de qualidade como: confiabilidade, eficiência, 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:
1-Confiabilidade: o sistema deve garantir que a actualização de dados será feita de forma atômica e imediata, sempre com registro histórico.
2- Eficiência: o sistema deve responder a qualquer inclusão, alteração e exclusão em tempo apropriado.
O sistema deve garantir que as actualizações dinâmicas de informação única nao deve execeder o tempo apropriado.
Descrição dos casos de uso
Caso de uso1: Cadastar cliente
Objectivo: Adicionar novo cliente
Actor: Administrador
Pré-condições: O actor precisa estar logado no sistema.
O actor entra com os dados do cliente.
O actor escolherá as seguintes opções: “cliente particular” ou “cliente personalizado”.
O actor salva os dados do cliente.
Pós-condição: Lista de clientes actualizada.
Fluxo normal de eventos:
Acções do actor: entrar na tela de cadastro cliente.
Acções do sistema: Carregar a tela com o formulario.
Acções do actor: Informar os dados necessários no formulário e concluir operação.
Acções do sistema: Validar dados do formulário e armazenar os dados na base de dados.
Caso de uso2: Inserir produto.
Objectivo: Adicionar novo produto.
Actor: Gerente.
Pré-condições: O actor precisa estar logado no sistema.
O actor entra com os dados do produto.
O actor salva os dados do produto.
Pós-condições: Lista de produtos actualizadas.
Fluxo normal de eventos:
Acções do actor: entrar na tela de inserir produto.
Acções do sistema: Carregar a tela com o formulario.
Acções do actor: Informar os dados necessários no formulário e concluir operação.
Acções do sistema: Validar dados do formulário e armazenar os dados na base de dados.
Caso de uso3: Controlar stock
Objectivo: Controlar a quantidade de produto no stock.
Actor: Gerente.
Pré-condições: O actor precisa estar logado no sistema.
O actor clica em controle de stock.
O actor faz as alterações que deseja.
O actor salva o sistema com novos dados.
Pós-condição: Lista de quantidade de produto no stock actualizada.
Fluxo normal de eventos:
Acções do actor: entrar na tela controlar stock.
Acções do sistema: Carregar a tela com o formulario.
Acções do actor: Informar os dados necessários no formulário e concluir operação.
Acções do sistema: Validar dados do formulário e armazenar os dados na base de dados.
Caso de uso4: Registrar vendas.
Objectivo: Controlar a saída de produtos vendidos.
Actor: Farmaceutica, gerente.
Pré-condição: O actor precisa estar logado no sistema.
O actor escolhe os produtos.
O actor define a quantidade de produto.
O sistema registra a venda.
Se houver uma quantidade insuficiente de produtos o sistema alertará o actor.
Pós-condição: O stock deverá estar actualizado.
A lista de vendas deverá estar actulizada.
Fluxo normal de eventos:
Acções do actor: entrar na tela registrar vendas.
Acções do sistema: Carregar a tela com o formulario.
Acções do actor: Informar os dados necessários no formulário e concluir operação.
Acções do sistema: Validar dados do formulário e armazenar os dados na base de dados.
Diagrama de caso de uso do negócio da Farmacia Muhongo
Diagrama de caso de uso do sistema Farmácia Muhongo
Diagrama de actividade de Solicitar atendimento
Regras do negócio
1- Quando o cliente finalizar a solicitação o sistema deve identificar o tipo de cliente.
2- Quando o cliente finalizar a solicitação e o cliente não for cadastrado o sistema deve permitir cadastrar o cliente.
3- Quando o cliente finalizar a solicitação o sistema deve selecionar o tipo de pagamento.
4- Quando o cliente confirmar a compra do produto o sistema deve enviar uma mensagem de confirmação.
Fluxo de trabalho análise
Neste fluxo de trabalho as atividades é realizada para cada caso de uso. Encontrar classes de análise e distribuir comportamento dos casos de uso entre estas, para cada classe, descrever suas responsabilidades, atributos e associações.
Descrição do caso de uso cadastrar cliente
O administrador do sistema poderá cadastrar um novo cliente. Para efetuar esse cadastro serão necessários o nome, morada, telefone, sexo, data do respectivo cliente. Será exibida na tela:
- Uma mensagem de confirmação;
- Ou uma mensagem de erro caso o cliente já exista.
Diagrama de classes do análise Cadastrar cliente
Diagrama de sequência de Cadastrar cliente
Descrição do caso de uso Remover cliente
O administrador do sistema poderá remover cliente da base de dados. Para efetuar a remoção será necessário o nome do cliente a ser removido. Será exibida na tela:
- Uma mensagem de confirmação;
- Ou uma mensagem de erro caso o cliente não exista.
Diagrama de sequência Remover cliente
Descrição do caso de uso editar cliente
O administrador do sistema poderá editar os dados de um cliente existente na base de dados. Para efetuar a alteração será necessário buscar o cliente informando seu nome, e em seguida, alterar o dado desejado. Será exibida na tela:
- Uma mensagem confirmando a alteração;
- Ou uma mensagem de erro caso o cliente não exista.
Diagrama de sequência editar cliente
Diagrama de classes do análise Registrar cliente
Descrição do caso de uso Registrar Vendas
O administrador do sistema poderá cadastrar uma nova venda na base de dados. Para efetuar este cadastro, serão necessários o nome do cliente associado à venda, o total_vendas, tipo_pagamento e a data em que foi efetuada a venda. Será exibida na tela:
- Uma mensagem de confirmação;
- Uma mensagem de erro caso o cliente não exista;
- Ou uma mensagem de erro caso a venda já exista.
Diagrama de sequência Registrar Vendas
Diagrama de pacotes da Farmácia Muhongo
O Diagrama de pacotes, ou diagrama de módulos, definido pela UML descreve os pacotes ou pedaços do sistema divididos em agrupamentos lógicos mostrando as dependências entre estes, ou seja, pacotes podem depender de outros pacotes.
Diagrama de classes persistentes
Diagrama de classes do sistema da Farmácia Muhongo
Conclusão
Em busca de um fácil entendimento do funcionamento do sistema, utilizamos a técnica para elaborar os Modelos de Dependências e de Razões Estratégicas. Para melhor esclarecimento de como satisfazer os requisitos não-funcionais, usamos também ferramentas UML para a construção do modelo de Casos de Uso, Diagrama de actividade, Diagrama de classes do analise, Diagrama de sequênci, Diagrama de pacotes, Diagrama de classes persistentes, 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. Esta documentação nos ajudará e servirá de apoio para a implementação do nosso sistema.
REFERÊNCIAS BIBLIOGRÁFICAS
http://www.inf.unioeste.br/~victor/processoII/ (acessado em Junho/2015)
http://www.inf.unioeste.br/~ivonei/PesI/ (acessado em Junho/2015)
PRESSMAN, R. S. E
