Post on 11-Apr-2017
___________________________________________________________________________Faculdade de Tecnologia de Jales
LUIZ ROBERTO REINOSO
VANESSA FINOTO
MedicTime:
Sistema de controle de medicamento
Trabalho Interdisciplinar
Disciplinas Envolvidas: Engenharia de Software para Web, Banco de Dados e Internet,
Acessibilidade e Programação de Sítios e Internet
Professores envolvidos: Fabiana P. Masson Caravieri, Lígia Rodrigues Prete, Maria Betânia,
Cristiano Pires Martins.
Jales
2016
SUMÁRIO
1 INTRODUÇÃO..................................................................................................................14
2 LEVANTAMENTO DE REQUISITOS...........................................................................16
2.1 DESCRIÇÃO DOS OBJETIVOS DO SISTEMA.........................................................................162.2 DESCRIÇÃO DO SISTEMA ATUAL......................................................................................162.3 DESCRIÇÃO DOS PRINCIPAIS PROBLEMAS.........................................................................172.4 DESCRIÇÃO DOS REQUISITOS FUNCIONAIS.......................................................................172.5 DESCRIÇÃO DOS REQUISITOS NÃO FUNCIONAIS...............................................................18
3 VISÃO DE CASO DE USO - UML..................................................................................20
3.1. DIAGRAMA DE CLASSES.....................................................................................................203.2. DEFINIÇÃO DOS ATORES....................................................................................................213.3. LISTA DE CASOS DE USO....................................................................................................223.4. DIAGRAMA DE CONTEXTO.................................................................................................233.5. DIAGRAMA DE CASOS DE USO INDIVIDUAIS.......................................................................243.6. DIAGRAMA DE SEQUÊNCIA.................................................................................................31
4 BANCO DE DADOS..........................................................................................................36
4.1 MODELO ENTIDADE RELACIONAMENTO..........................................................................364.1.1 Modelo conceitual do banco de dados.......................................................36
4.2 DICIONÁRIO DOS ATRIBUTOS DAS CLASSES....................................................................394.3 SCRIPT DAS TABELAS.......................................................................................................454.4 SELECTS DE ALGUMAS TABELAS.....................................................................................53
5 LAYOUT WEB ACESSIBILIDADE...............................................................................56
6 JAVASCRIP.......................................................................................................................57
7 REFERÊNCIAS.................................................................................................................63
1 INTRODUÇÃO
Desde o início do século passando, o Brasil vem passando por algumas mudanças no
modelo de assistência à saúde (COLOMBO, 2004). Dentro deste contexto surgem os avanços
da tecnologia na área da saúde como forma de melhorar a Assistência Medica e Farmacêutica
para que a população disponha de serviços de qualidade (VIEIRA; OHAYON, 2006).
A Indústria Farmacêutica (IF) se destaca no mercado como umas das mais lucrativas
no mundo (TEXEIRA, 2014). Criar produtos de qualidade e inovador é essencial para a
sobrevivência das empresas. Por isso o uso contaste de investimento em pesquisas como a
biotecnologia vem crescendo cada vez mais (VIEIRA; OHAYON, 2006). Além da
biotecnologia alguns estudos vêm avaliando o comportamento dos pacientes em relação ao
uso dos medicamentos (PANIZ, 2009).
De acordo com Silva et al (2007) algumas pessoas imaginam que os medicamentos
são utilizados somente para tratar e curar as doenças. Embora isso aconteça muitas vezes, os
remédios podem ser utilizados com outras finalidades. Brasil (1973) define medicamento
como produtos farmacêuticos obtidos ou fabricados, com finalidade profilática, curativa,
paliativa ou para fins de diagnóstico. Já para OMS (1984) medicamento é toda substância
contida em um produto farmacêutico empregado para modificar ou explorar sistemas
fisiológicos em benefício da pessoa que utiliza.
O conhecimento do paciente sobre o uso correto do medicamento é somente medido
pela capacidade de nomear ou pelas reações adversas do produto (DIDONE, 2015). Um
pesquisador conhecido Delgado (2008) realizou uma pesquisa numa determinada farmácia na
Espanha com 1240 paciente, nessa pesquisa percebeu-se que 66% dos entrevistados não
possuía nenhum tipo de conhecimento sobre medicamentos.
No Brasil Silva (2000) edificou que mais da metade da população são totalmente
leigas sobre como administrar corretamente os medicamentos. Para o autor as pessoas
consomem os remédios de maneira incorreta e exagerada, sendo que a maior razão desse uso
irracional, é por não compreender o que está escrito na receita, assim ingerindo doses erradas
de remédios e em horários não indicados (PANIZ, 2009).
Segundo a OMS - Organização Mundial da Saúde (2012) mais de 50% de todos os
medicamentos são prescritos incorretamente. E mais de 50% de todos os países não oferecem à
população informações para conscientizar o uso racional dos medicamentos. A situação tende a
ser pior em países que estão em desenvolvimento.
O presente estudo possui como objetivo o desenvolvimento de um sistema web que
auxilie os pacientes de determinadas clínicas a controlar e administrar o uso racional dos
15
medicamentos. O sistema terá a função de controlar o horário, quantidade, nomes, função e seus
efeitos colaterais. Todas as informações serão fornecidas por médicos.
16
2 LEVANTAMENTO DE REQUISITOS
O levantamento de requisitos é a fase inicial da Engenharia de Requisitos (PAIM,
2013). Nessa fase a comunicação entre clientes, usuários e especialistas de domínio é
necessária, pois através dessa iteração que o analista consegue conhecer a organização, os
processos, as necessidades e a deficiências dos sistemas de software atuais do cliente assim
oferecendo possibilidades de melhorias (KOTONYA; SOMMERVILLE, 1998).
Pode se dizer que o levantamento de requisitos é responsável por suprir as
necessidades do cliente e usuário, no caso as pessoas que necessitam do sistema (PAIM,
2013). Muitos sistemas são retardados devido a sua forma ineficaz em seu levantamento de
requisitos, e como consequência disso o sistema chega a morrer durante seu percurso.
(MELLO, 2010).
Existem várias formas e técnicas de se fazer o levantamento de requisitos, através
destas formas o analista consegue obter informações sobre o que o cliente ou usuário deseja
do software (DANRESA, 2012). Para que o sistema seja bom é preciso um levantamento de
requisitos bem apurado, específico, direto e com precisão, desta maneira se conseguirá obter o
resultado desejado.
2.1 DESCRIÇÃO DOS OBJETIVOS DO SISTEMA
A ideia inicial é criar um sistema que ajudem os pacientes de uma determinada
clinica medica a gerenciar e controlar a dosagem e o horário de cada remédio que serão
utilizados. A clínica vai disponibilizar esse sistema ao seu cliente, sendo que o médico será
responsável por alimentar o sistema com informações do nome do remédio, horário que
paciente deve tomar e a quantidade da dose do medicamento. O sistema oferecerá
informações da próxima consulta e também o médico poderá tirar dúvidas com seus clientes.
O software terá como base as informações do paciente, do médico e dos remédios
consumidos. Nesse sistema será realizado o controle da quantidade do medicamento, o
horário do uso de cada um, o nome do medicamento, as reações colaterais, para qual
tratamento que serve e o horário da próxima consulta.
Esse sistema será disponível na web para que o médico possa fornecer as
informações para alimentar o sistema. O paciente acompanhará através da web ou poderá
instalar um aplicativo no smartphone. Através desse software aproximação entre paciente e
médicos será continua e ajudará os especialistas estudar mais sobre o comportamento do
cliente
17
2.2 DESCRIÇÃO DO SISTEMA ATUAL
Para o controle de medicamento existem alguns aplicativos para smartphone, porém
são softwares que oferecem apenas alerta em relação ao horário do medicamento. Todos esses
aplicativos existentes, os dados são fornecidos pelos pacientes e não pelo médico. As pessoas
que utilizam podem fornecer informações errada e o mais perigoso alguns pacientes usa o
sistema para controlar os remédios sem prescrição medica.
Provavelmente poucas pessoas conhecem esse tipo de aplicativos. Sendo que a forma
de administrar os medicamentos e da maneira antiga, ou seja, papel e caneta. No papel são
escritos o nome do remédio e horário para ser tomado, no final o papel é pregado na geladeira
como se fosse um bilhete a ser lembrado.
2.3 DESCRIÇÃO DOS PRINCIPAIS PROBLEMAS.
Os bilhetes com informações escritas sobre os remédios podem sumir, voar,
rasgar e manchar, se a pessoa não lembrar das informações ficará perdida ao tentar se
medicar.
O bilhete pode ter vários nomes de remédio escrito deixando o cliente confuso
de qual deverá utilizar.
O aplicativo de alerta pode não funcionar como, por exemplo, se a bateria do
celular acabar e não for carregado o celular vai desligar e alerta não tocará.
As informações dos aplicativos que existem na web são fornecidas pelo usuário
e não pelo médico podendo o cliente colocar dados errados.
As letras que os médicos escrevem nas receitas são difícil de compreender
As bulas além de ter letras muito pequenas, as descrições são técnicas e poucas
pessoas consegue entender.
A falta de comunicação entre paciente e médico. Muitas pacientes têm medo de
perguntar ou falar alguma coisa errada na frente do médico.
18
2.4 DESCRIÇÃO DOS REQUISITOS FUNCIONAIS
o Cadastro de pacientes: O sistema deverá permitir o cadastro de novos
pacientes. Caso já exista o cadastro da pessoa, uma mensagem de erro deve ser exibida.
o Pesquisar pacientes: O sistema possibilitará pesquisar informações sobre o
paciente. Além de seu cadastro para agendamento de consultas ou exames.
o Alterações pacientes: Informações como endereço e telefone podem sofrer
alterações, o sistema deverá dar suporte para essas mudanças.
o Cadastro de remédios: O sistema disponibilizará informações sobre remédios
e o médico poderá receita-lo por meio de seu cadastro. O cadastro de remédios deve ser feito
pelos administradores do site.
o Pesquisar remédios: O paciente poderá pesquisar sobre todos os remédios que
está sendo utilizado por ele.
o Alterar remédios: O médico poderá fazer alterações no medicamento
receitado ao paciente, o sistema terá que possibilitar essas alterações. Alterações em
informações sobre os remédios também são visíveis, portanto deverá ser implementado.
o Remoção de remédios: A remoção de um medicamento pode se dar ao fato de
sua proibição pela lei. Deverá ser feita pelos responsáveis do site.
o Cadastro das consultas: A consulta será marcada pela assistente ou secretaria.
Se o cadastro do paciente já existir é só pesquisar e marcar, se não o cadastro deverá ser feito
pela funcionária e então a consulta poderá ser marcada.
o Pesquisar consultas: Depois de ter uma consulta marcada o paciente e o
médico poderão ver as informações sobre ela, como data e hora.
o Remarcar consultas: As alterações nas informações de data e hora, em
relação a consulta são necessárias, pois imprevistos podem ocorrer tanto para o médico
quanto para o paciente.
o Desmarcar consultas: Em último caso quando remarcar não for possível, o
software deverá oferecer uma alternativa que é a de desmarcar a consulta.
o Cadastro dos médicos: O médico deverá ter o cadastro para oferecer aos
pacientes as funcionalidades do sistema.
19
o Pesquisar sobre os médicos: Informações relevantes ao relacionamento
médico paciente deverão ser disponibilizadas no site. O médico e suas informações deverão
ser encontrados através de pesquisa.
o Remover médicos: O cadastro do médico deverá existir ainda, porem ele não
será mais associado a uma clínica. Poderá ser reativado.
2.5 DESCRIÇÃO DOS REQUISITOS NÃO FUNCIONAIS
Segurança: O software somente será acessado pelos pacientes que são cliente
da clínica. Essas pessoas vão ter senha e login para entrar no sistema.
Usabilidade: Desenvolver um sistema fácil e básico onde qualquer pessoa que
entrar no sistema consiga entender e interpretar todos os mecanismos. O sistema precisa
apresentar uma interface objetiva, amigável e de fácil acessibilidade, isto é, suas informações,
funcionalidades e características deverão estar bem visíveis e disponíveis.
Confiabilidade: Quando ocorrer alguns eventos inesperados por exemplos um
erro no sistema e o usuário acabar perdendo as informações digitadas o sistema tem de ser
capaz de se recuperar das falhas, sem que haja perda de dados. As mensagens de erro
produzidas pelo sistema deverão ser informativas e precisas, apontando o fator de origem e os
procedimentos a serem seguidos após sua ocorrência. O sistema deve fornecer facilidades
para a realização de backups dos arquivos do sistema.
Desempenho: Desenvolver um sistema que não seja lento, que não consome
muito espaço do computador e não demora em executar e processar os dados assim evitando
crítica dos futuros clientes. O sistema deverá ser capaz de suportar uma quantidade de acessos
simultâneos.
Disponibilidade: O software estará disponível em qualquer horário, ou seja, 24
horas por dia. Quando houver manutenção será enviado uma mensagem ao usuário
informando, porém, a manutenção será breve para não atrapalhar o cliente. O sistema será
capaz de suportar uma grande quantidade de usuário simultaneamente.
21
3 VISÃO DE CASO DE USO - UML
3.1. DIAGRAMA DE CLASSES
Segundo Guedes (2009) o diagrama de classe é o mais importante da UML onde é
definido como será a estrutura de um sistema. No modelo de classe são identificados os
objetos que descrevem o ambiente, contendo os atributos e métodos que relacionam e trocam
informação entre si, cada um deles possui uma importante função.
Os Atributos definem as características do software, nesta parte também se decide a
visibilidade e quais elementos poderão acessar essas informações. Já os métodos são ações
que vão ter no sistema (UFPR, 2012).
Todas as classes têm uma relação (associação) que é o que faz a ligação de uma
classe com a outra, segundo Facom (2014) as associações são as representações dos
relacionamentos formados pelos objetos na execução do sistema, e elas são representadas por
linhas que ligam uma classe na outra. Também nas classes é necessário colocar as
Multiplicidades que vão limitar a quantidade de objetos que podem ser associados a outros
objetos (UFPR, 2012).
O Diagrama de Classe é um elemento muito importante em um processo de
montagem de software, pois, nele você vai ter o esboço do que você quer ou pretende criar, e
vai ser nele que estará explicado o que o seu cliente realmente quer que o programa faça
(PUC-RIO, 2013).
A figura 1 apresenta um modelo de classe de negócios proposto para o sistema.
Percebe-se que médico, paciente, medicamento, consulta e receita são interligados entre si
formando uma malha de informações que desempenham o papel fundamental no
funcionamento do sistema e por esse motivo são consideradas as classes principais.
O diagrama possui duas composições entre classe sendo clínica e medico surgindo a
classe trabalha, a outra ligação é entre exame e consulta. A classe mais importante para o
desenvolvimento do projeto é a classe receita e medicamento, sendo que é esse que vai definir
o funcionamento do MedicTime, pode-se observar na figura que existem várias classes
interligando-se ao medicamento como por exemplo receita, fabricante, forma, reação,
classificação, tarja, finalidade, armazenamento e via de administração.
23
3.2. DEFINIÇÃO DOS ATORES
Os atores na UML representam algo ou alguém que interagem com o sistema. Um
ator pode somente fornecer ou receber informações (PIMENTEL; 2015). Os papéis dos
usuários de um produto são modelados através dos atores. Cada ator representa numa classe
de usuários.
Os atores modelam os papéis e não as pessoas dos usuários, por exemplo, o mesmo
usuário físico pode agir como gerente, gestor de estoque ou gestor de compras. Pode-se
também definir atores não humanos, para modelar outros sistemas que devam interagir como
o produto em questão: por exemplo, o sistema financeiro. Quando á grande números de atores
esses devem ser agrupados formando atores genéricos que são ligados por relacionamentos de
herança.
A figura abaixo representa os responsáveis pela funcionalidade do sistema o ator
medico é responsável pelas ações do sistema como cadastrar, alterar, pesquisar, listar e pela
movimentação de tudo que acontece com o sistema. O ator paciente somente tem acesso a
alguns dados sendo que esse ator não pode remover cadastrar e nem alterar.
Figura 2 — Atores responsável pelo sistema
Fonte: elaborado pelos autores.
24
3.3. LISTA DE CASOS DE USO
No quadro 1 temos a lista de casos de usos que são considerados os mais
importantes para existência do MedicTime, pois é através da receita que surge as informações
dos medicamentos, da quantidade de dose que usuário vai utilizar e as informações do
paciente, ou seja a classe receita é o elo para outras classes. No quadro está especificado as
descrições de cada caso de uso, como será as entradas dos dados e resposta de sucesso.
Quadro 1 – Lista de Casos de Uso
Nº Descrição do Caso de Uso Entrada Caso de Uso Resposta
01 Médico cadastra receitaDados da receita (paciente, medicamento e dose).
Cadastrar Receita Msg01
02 Médico altera receita Altera dados da receita Alterar Receita Msg02
03 Médico remove receita Dados pelo código Remover Receita Msg03
04 Médico consulta receita Consulta dados pelo código ou nome.
Consultar Receita
Dados Completos da Receita
05 Médico lista receita Lista dados pelo código ou nome.do paciente Listar Receita
Dados Completos da Receita
Fonte: elaborado pelos autores.
3.4. DIAGRAMA DE CONTEXTO
No Diagrama de Contexto serão mostradas as relações definidas do sistema para com
o meio ambiente, mostrando assim um único processo, ele pode ser considerado um caso
especial nos diagramas correspondendo a um nível superior, pois, apresenta uma visão geral
sobre as principais funções do sistema (SOARES, 2014).
O diagrama de contexto mostra uma ideia mais clara sobre o fluxo de informações do
sistema analisados e elementos externos, e delimita quais atividades serão de responsabilidade
do sistema e as que não serão. Também neste diagrama é mostrada uma ideia geral do sistema
por recursos visuais, que podem ser facilmente entendidos pelos usuários (CARVALHO,
2013).
25
Para que o diagrama de contexto possa ser construído serão necessários alguns
pontos importantes, tais como o processo aonde representa o sistema, as entidades externas
nas haverá uma relação do sistema como as pessoas, organizações e outros sistemas, troca de
dados e informações do sistema e o exterior, o fluxo dos dados e uma interface que liga o
sistema com o ambiente (SOARES, 2014). A figura 2 mostra as ações que os atores podem
efetuar e apresenta uma visão geral sobre as principais funções do sistema.
Figura 3 — Diagrama de Contexto
Fonte: elaborado pelos autores.
26
3.5. DIAGRAMA DE CASOS DE USO INDIVIDUAIS
Nas figuras 4 até 8, são apresentados os casos de uso abordados no desenvolvimento
do sistema.
Caso de Uso 01: Cadastrar Receita
Ator: Medico
Figura 4 — Caso de Uso Cadastrar Receita
Fonte: elaborado pelos autores.
Fluxo Normal
1-AtorMedico solicita cadastrar receita
2-Sistema busca dados (nomePaciente, medicamento, dose)
2.1-Sistema aciona listar Medicamento
2.2-Sistema aciona listar Doce
2.3-Sistema aciona listar Paciente
3-Sistema exibe formulário com os dados
4-AtorMedico informa dados que falta
5-Sistema valida dados informados
6-AtorMedico confirma e envia dados
7-Sistema grava dados no banco de dados
27
8-Sistema envia msg 01:"Cadastro efetuado com sucesso!"
Fluxo Alternativo
2-Sistema busca dados (nomePaciente, medicamento, dose)
2.1-Sistema não encontra dados
2.2- Sistema exibe msg 01: "Dados não encontrados”
2.3- Sistema retorna ao item 1
5- Sistema valida dados informados
5.1-Sistema identifica campos vazios ou incorretos
5.2-Sistema envia msg 01:"Campos vazios ou incorretos!"
5.3- Sistema retorna ao item 4.
7-Sistema grava dados no banco de dados
7.1-Sistema identifica erro ao gravar ou falha de conexão com bancos de dados
7.2-Sistema exibe msg 01: "Erro ao gravar dados ou falha de conexão!"
7.3. Sistema retorna ao item 6.
Caso de Uso 02: Alterar Receita
Ator: Medico
Figura 5 — Caso de Uso Alterar Receita
Fonte: elaborado pelos autores.
28
Fluxo Normal
1-AtorMedico solicita alteração dos dados do cadastro
2-Sistema habilita edição de dados
3-AtorMedico informa dados
4-Sistema valida dados informados
5-AtorMedico confirma dados e envia
6-Sistema atualiza os dados
7-Sistema envia msg02: "Cadastro alterado com sucesso!"
Fluxo Alternativo
4-Sistema valida dados informados
4.1-Sistema identifica erros ou campos vazios
4.2-Sistema envia msg 02:"Erros ou campos vazios"
4.3- Sistema retorna ao item 3.
6-Sistema atualiza os dados
6.1-Sistema identifica erros na conexão e/ou atualização com banco de dados
6.2-Sistema envia msg 02: "Erros de conexão e/ou atualização com Banco de Dados"
6.3-Sistema retorna ao item 5
Caso de Uso 03: Remover Receita
Ator: Medico
Figura 6— Caso de Uso Remover Receita
29
Fonte: elaborado pelos autores.
Fluxo Normal
1-AtorMedico solicita remoção cadastro
2-Sistema exibe msg 03: "Deseja remover este cadastro"
3-AtorMedico confirma remoção
4-Sistema remove cadastro do banco de dados
5-Sistema envia msg 04:"Cadastro removido com sucesso!"
Fluxo Alternativo
3-AtorMedico confirma remoção
3.1-Caso AtorMedico não confirma remoção, sistema retorna ao Caso de Uso
"Consultar Receita"
4-Sistema remove cadastro do banco de dados
4.1-Sistema identifica erros ou falhas de conexão com banco de dados
4.2-Sistema envia msg 04:"Erros ou falha de conexão com banco de dados!'
4.3-Sistema retorna ao item 1
Caso de Uso 04: Consultar Receita
Ator: Medico
Figura 7 — Caso de Uso Consultar Receita
30
Fonte: elaborado pelos autores.
Fluxo Normal
1-AtorMedico solicita consulta dos dados da receita selecionada
2-Sistema busca dados referentes ao código ou nome informados.
3-Sistema exibe dados completos da receita
4-Caso AtorMedico deseja alterar dados da receita sistema aciona caso de uso
Alterar Receita
4-Caso AtorMedico deseja remover dados da receita sistema aciona caso de uso
Remover Receita
Fluxo Alternativo
2-Sistema busca dados referentes ao código ou nome informados.
2.1-Sistema identifica erros ao acessar banco de dados
2.2-Sistema exibe msg 05: "Erros ao acessar Banco de Dados"
2.3-Sistema retorna ao item 1.
Caso de Uso 05: Listar Receita
Ator: Medico
Figura 8 — Caso de Uso Listar Receita
31
Fonte: elaborado pelos autores.
Fluxo Normal
1-AtorMedico solicita listagem de receita
2-Sistema exibe página de pesquisa de receita e solicita dados (codigos,
nomePaciente, nomeMedicamento, quantidadeDose).
3-AtorMedico informa dados da receita
4-Sistema busca dados informados no banco de dados
5-Sistema retorna listagem da receita
6-Caso AtorMedico deseja consultar dados de uma receita, sistema aciona caso de
uso Consultar Receita
Fluxo Alternativo
4-Sistema busca dados informados no banco de dados
4.1- Sistema não localiza dados informados
4.1.1 -Sistema envia msg 06:"Dados informados não localizados! Informe
novamente".
4.1.2-Sistema retorna ao item 3.
4-Sistema busca dados informados no banco de dados
4.2-Sistema identifica erros ao conectar com banco de dados
4.2.1-Sistema envia msg 06:"Erro ao conectar com Banco de dados"
4.2.2 Sistema retorna ao item 3.
3.6. DIAGRAMA DE SEQUÊNCIA
No Diagrama de Sequências são representadas como o próprio nome já diz a
sequência dos processos executados dentro do software, ele descreve de uma maneira simples
como ocorre a interação entre os objetos dentro do sistema através de mensagens mostrando
cada reação de operações ou métodos (SILVA, 2010).
Ele determina a sequência dos processos que ocorrem dentro de cada Caso De Uso,
ou seja, ele dispara as reações na ordem que os objetos são envolvidos para que assim seja
completa a realização de cada Caso De Uso (SENAC,2008).
O Diagrama Enfatiza o tempo de sequência e a participação dos objetos com suas
linhas de vida, podemos também dizer que ele mostra o relacionamento entre os objetos das
32
classes, o usuário solicita alguma ação no sistema e após essa solicitação o sistema executa e
retorna algum tipo de resposta na tela para o usuário (PUC-RIO,2014).
Ele é representado por caixas que representam os objetos definidos no diagrama de
classes, por linhas verticais que representam a linha de vida de cada objeto desde o ponto de
seu nascimento em diante até mesmo a sua morte e as mensagens que indica a interação entre
os objetos (SILVA, 2010).
Objetos: Não é exigida a ordem dos objetos, pois assim torna o diagrama mais
legível.
Linhas De Vida: Representa tanto a ativação como a desativação dos objetos,
também a criação e a destruição deles.
Mensagens: É a interação dos objetos entre si, o que foi pedido, o que foi
executado (PUC-RIO, 2014).
As figuras 9 até 11 representam os diagramas de sequencias do projeto onde estão os
cincos mais importantes como cadastrar o parceiro, cadastrar produção, pesquisar contato,
alterar produto e calcular o preço da venda.
Diagrama de Sequência 1: Cadastrar Receita
Figura 9—Diagrama de Sequência Cadastrar Receita
Fonte: elaborado pelos autores.
33
Diagrama de Seqüência 2: Consultar Receita
Figura 10—Diagrama de Seqüência Consultar Receita
Fonte: elaborado pelos autores.
34
Diagrama de Sequência 3: Listar Receita
Figura 11— Diagrama de Sequência Listar receita
Fonte: elaborado pelos autores.
35
4 BANCO DE DADOS
Um banco de dado é uma entidade na qual possível armazenar dados de formas
estruturadas e com a menor redundância. Os dados podem ser utilizados por programas e por
usuários diferentes (KIOSKEA, 2014).
O Banco de dado é projetado de acordo com a necessidade do usuário, por exemplo,
imagina um sistema de agenda telefônica as informações como nome, endereço e telefone
serão armazenadas num determinado banco que não necessita de tanta complexidade, mas se
fosse para uma agência bancaria que possuem vários dados de milhares de cliente essas
informações devem está guardada não banco de dado seguro e que suporta grande
movimentação, ou seja, o tamanho e a complexibilidade do BD vão depender das
necessidades dos usuários. (GEREMIA, 2010).
Para o desenvolvimento do sistema foi utilizado como banco de dado o PostgreSQL
que é Sistema de Gerenciamento de Banco de Dados Objeto Relacional (SOLGATE, 2005)
que possuem uma interface gráfica amigável, e uma ferramenta de fácil entendimento e de
ótima utilidade.
4.1 MODELO ENTIDADE RELACIONAMENTO
O DER é o elemento essencial do processo de análise do sistema onde faz uma
investigação de uma forma bem estruturada e sucinta, desta maneira pode ser definido de uma
maneira conceitual e lógica a representação das entidades (PONTES, 2012).
Ele conserva os conceitos genéricos da base que são usados na abstração de uma
realidade à sua descrição, a entidade é independente por estar ligada à outros objetos do
Banco de Dados, a associação tem o objetivo de ligar as entidades sendo que cada uma delas
ocupam um “papel” (UFPR, 2014)
4.1.1 Modelo conceitual do banco de dados
Nesta seção é apresentada a modelagem conceitual do banco de dados para a
aplicação proposta. Na Figura 19 ilustra o diagrama DER que descreve os requisitos de dados
da aplicação, onde cada entidade possui seu id que o identifica unicamente. No DER possui
uma herança onde classe mãe é a Pessoa e as Classes filhas médico e paciente.
37
4.1.2 Modelo logico do banco de dados
Figura 13 — Modelo Lógico do banco de Dados
Fonte: elaborado pelos autores.
38
4.2 DICIONÁRIO DOS ATRIBUTOS DAS CLASSES
Nos quadros 2 até 27 mostram os dados que compõem o Banco de Dados onde estão
definidas em tipo de dicionários as descrições de cada coluna, o tipo de variável, o tamanho, se é
primary key ou foreign key e o requerimento, ou seja, se é not null ou não.
Quadro 2—Dicionário dos Atributos da Tabela Cidade
Fonte: elaborado pelos autores.
Quadro 3—Dicionário dos Atributos da Tabela Estado
Fonte: elaborado pelos autores.
Quadro 4—Dicionário dos Atributos da Tabela Pessoa
Fonte: elaborado pelos autores.
Quadro 5—Dicionário dos Atributos da Tabela Paciente
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.cpf Identificador CPF do Paciente Integer - S N Srg RG do Paciente Integer - N N SdataNascimento Data Nascimento Paciente Date - N N SidPessoa Identificador da Pessoa Integer - N S S
Fonte: elaborado pelos autores.
Quadro 6—Dicionário dos Atributos da Tabela Médico
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idCidade Identificador da Cidade Integer - S N SnomeCidade Nome da Cidade String 100 N N SidUF Identificador do Estado Integer - N S S
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idUF Identificador do Estado Integer - S N SnomeUF Nome do Estado String 100 N N S
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idPessoa Identificador da Pessoa Integer - S N Snome Nome da Pessoa String 100 N N Sendereco Endereço da Pessoa String 100 N N STelefone Telefone da Pessoa String 20 N N SBairro Bairro da Pessoa String 50 N N Snumero Numero casa da Pessoa Integer - N N SidCidade Identificador da Cidade Integer - N S S
39
Fonte: elaborado pelos autores.
Quadro 7—Dicionário dos Atributos da Tabela Clinica
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.cnpj Identificador CNPJ da Clinica Integer - S N SrazaoSocial Razão Social da clinica String 100 N N SnomeFantasia Nome Fantasia da Clinica String 100 N N Sie Inscrição Estadual da Clinica String 30 N N Ssite Endereço do Site da Clinica String 50 N N S
Fonte: elaborado pelos autores.
Quadro 8—Dicionário dos Atributos da Tabela Trabalha
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idTrabalha Identificador Trabalha Integer - S N Scrm Identificador do Medico Integer - N S Scnpj Identificador CNPJ da Clinica Integer - N S S
Fonte: elaborado pelos autores.
Quadro 9—Dicionário dos Atributos da Tabela Exame
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idExame Identificador do Exame Integer - S N Sdescricao Descrição do Exame String 100 N N S
Fonte: elaborado pelos autores.
Quadro 10—Dicionário dos Atributos da Tabela Realiza
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idRealiza Identificador Realiza Integer - S N SidExame Identificador do Exame Integer - N S SidConsulta Identificador da Consulta Integer - N S SResultado Resultado do Exame String 100 N N S
Fonte: elaborado pelos autores.
Quadro 11—Dicionário dos Atributos da Tabela Consulta
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idConsulta Identificador Consulta Integer - S N SnumeroProntuario Numero do Prontuário Integer - N S Sdescricao Descrição da Consulta String 100 N N S
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.crm Identificador do Medico Integer - S N SEspecialidade Tipo de Especialidade String 100 N N SidPessoa Identificador da Pessoa Integer - N S S
40
dataConsulta Data Consulta Date - N N ShoraConsulta Hora Consulta Date - N N SdataProximaConsu Próxima Consulta Date - N N ShoraProximaConsu Hora da Próxima Consulta Date - N N Scrm Identificador do Medico Integer - N S Scpf Identificador CPF do Paciente Integer - N S S
Fonte: elaborado pelos autores.
Quadro 12—Dicionário dos Atributos da Tabela Receita
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idReceita Identificador Receita Integer - S N SdataValidade Data da Validade da Receita Date - N N Sdescricao Descrição da Receita String 100 N N SidConsulta Identificador da Consulta Integer - N S Scpf Identificador CPF Paciente Integer - N S S
Fonte: elaborado pelos autores.
Quadro 13—Dicionário dos Atributos da Tabela Dose
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idDose Identificador da Dose Integer - S N Squantidade Quantidade de Dose Integer - N N SidReceita Identificador da Receita Integer - N S S
Fonte: elaborado pelos autores.
Quadro 14—Dicionário dos Atributos da Tabela Horário
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idHora Identificador Horário Integer - S N SquantasHoras Quantas Doses por Hora Integer - N N S
Fonte: elaborado pelos autores.
Quadro 15—Dicionário dos Atributos da Tabela Possui Horas
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idPossuiHora Identificador Trabalha Integer - S N SidHora Identificador do Horário Integer - N S SidDose Identificador da Dose Integer - N S S
Fonte: elaborado pelos autores.
Quadro 16—Dicionário dos Atributos da Tabela Medicamento
41
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.lote Numero do Lote Integer - S N SNome Nome do Medicamento String 100 N S SValidade Validade do Medicamento Date - N N SdataFabricacao Data de Fabricação Date - N N SnumeroRegistro Numero do Registro Integer - N N Speso Peso do Medicamento Float - N N Squantidade Quantidade de Medicamento Integer - N N SsubstanciaPrincipal Substância Principal String 100 N S Scrf CRF do Medicamento Integer - N S Ssac SAC de atendimento Integer - N N Sduração Tempo de Duração Integer - N N SidadeUso Idade Adequada para Uso Integer - N N SidReceita Identificador da Receita Integer - N S SidViaAdm Identificador Via Administra Integer - N S SidArmazenamento Identificador Armazenamento Integer - N S SidClassificacao Identificador da Classificação Integer - N S SidTarja Identificador da Tarja Integer - N S SidForma Identificador da Forma Integer - N S S
Fonte: elaborado pelos autores.
Quadro 17—Dicionário dos Atributos da Tabela ViaAdministracao
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idViaAdmi Identificador Via Administra Integer - S N Stipo Descrição Via Administração String 100 N N S
Fonte: elaborado pelos autores.
Quadro 18—Dicionário dos Atributos da Tabela Armazenamento
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idArmazenamento Identificador Armazenamento Integer - S N Stipo Descrição do Armazenamento String 100 N N S
Fonte: elaborado pelos autores.
Quadro 19—Dicionário dos Atributos da Tabela Classificacao
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idClassificacao Identificador da Classificação Integer - S N Stipo Descrição da Classificação String 100 N N S
Fonte: elaborado pelos autores.
Quadro 20—Dicionário dos Atributos da Tabela Finalidade
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idFinalidade Identificador da Finalidade Integer - S N Stipo Descricão da Finalidade String 100 N N S
42
Fonte: elaborado pelos autores.
Quadro 21—Dicionário dos Atributos da Tabela Possui
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idPossui Identificador Possui Integer - S N SidFinalidade Identificador da Finalidade Integer - N S Slote Identificador do Lote Integer - N S S
Fonte: elaborado pelos autores.
Quadro 22—Dicionário dos Atributos da Tabela Reacao
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idReacao Identificador de Reação Integer - S N Stipo Descricão da Reação String 100 N N S
Fonte: elaborado pelos autores.
Quadro 23—Dicionário dos Atributos da Tabela Gera
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idGera Identificador Gera Integer - S N SidReacao Identificador da Reação Integer - N S Slote Identificador do Lote Integer - N S S
Fonte: elaborado pelos autores.
Quadro 24—Dicionário dos Atributos da Tabela Forma
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idForma Identificador de Forma Integer - S N Stipo Descrição de Forma String 100 N N Sestado Descrição do Estado String 100 N N S
Fonte: elaborado pelos autores.
Quadro 25—Dicionário dos Atributos da Tabela Tarja
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idTarja Identificador da Tarja Integer - S N Snome Descrição da Tarja String 100 N N Scor Cor da Tarja String 100 N N S
Fonte: elaborado pelos autores.
43
Quadro 26—Dicionário dos Atributos da Tabela Fabricante
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idFabricante Identificador Do Fabricante Integer - S N SnomeFantasia Nome Fantasia da Fabrica String 100 N N SrazaoSocial Razão social da Fabrica String 100 N N SEndereço Endereço da Fabrica String 100 N N Scidade Cidade Localizada a Fabrica String 100 N N SSite Site da Fabrica String 100 N N Scnpj CNPJ da Fabrica Integer - N N Sie Inscrição Estadual Fabrica Integer - N N S
Fonte: elaborado pelos autores.
Quadro 27—Dicionário dos Atributos da Tabela Fabrica
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.idFabrica Identificador Fabrica Integer - S N SidFabricante Identificador do Fabricante Integer - N S Slote Identificador do Lote Integer - N S S
Fonte: elaborado pelos autores.
4.3 SCRIPT DAS TABELAS
Nesse tópico o Quadro 28 até 53 será abordado os scripts do banco de dado, que é
utilizados para desenvolvimento e para comunicação do sistema, onde através desses scripts é
possível realizar cadastro, pesquisas e remover dados.
Quadro 28—Script de criação da tabela Estado
Fonte: elaborado pelos autores.
Quadro 29—Script de criação da tabela Cidade
CREATE TABLE Estado (
idUF serial not null PRIMARY KEY,
nomeUF varchar(100) not null )
CREATE TABLE Cidade (
idCidade serial not null PRIMARY KEY,
nomeCidade varchar(100) not null,
idUF int references Estado (idUF)
on update restrict
on delete restrict )
44
Fonte: elaborado pelos autores.
Quadro 30—Script de criação da tabela Pessoa
Fonte: elaborado pelos autores.
Quadro 31—Script de criação da tabela Médico
Fonte: elaborado pelos autores.
Quadro 32—Script de criação da tabela Paciente
Fonte: elaborado pelos autores.
Quadro 33—Script de criação da tabela Clinica
Fonte: elaborado pelos autores.
CREATE TABLE Pessoa (
idPessoa serial not null PRIMARY KEY,
nome varchar(100) not null,
telefone varchar(20) not null,
endereco varchar(100) not null,
bairro varchar(50) not null,
numero int not null,
idCidade int references Cidade (idCidade) on update restrict
on delete restrict )
CREATE TABLE Medico (
crm serial not null PRIMARY KEY,
especialidade varchar(100) not null,
idPessoa int references Pessoa(idPessoa) on update restrict
on delete restrict)
CREATE TABLE Paciente (
cpf serial not null PRIMARY KEY,
rg int not null,
dataNascimento Date not null,
idPessoa int references Pessoa(idPessoa) on update restrict
on delete restrict)
CREATE TABLE Clinica (
cnpj serial not null PRIMARY KEY,
razaoSocial varchar(100) not null,
nomeFantasia varchar(100) not null,
ie varchar(30) not null,
site varchar(50) not null)
45
Quadro 34—Script de criação da tabela Exame
Fonte: elaborado pelos autores.
Quadro 35—Script de criação da tabela Consulta
Fonte: elaborado pelos autores.
Quadro 36—Script de criação da tabela Horario
Fonte: elaborado pelos autores.
Quadro 37—Script de criação da tabela Dose
Fonte: elaborado pelos autores.
CREATE TABLE Exame (
idExame serial not null PRIMARY KEY,
descricao varchar(100) not null)
CREATE TABLE Consulta (
idConsulta serial not null PRIMARY KEY,
numeroPontuario int not null,
descricao varchar(100) not null,
dataConsulta date not null,
horaConsulta Date not null,
dataProximaConsu Date not null,
horaProximaConsu Date not null,
crm int references Medico(crm)
on update restrict
on delete restrict,
cpf int references Paciente(cpf)
on update restrict
on delete restrict )
CREATE TABLE horario (
idHora serial not null PRIMARY KEY,
quantidadeHora int not null)
CREATE TABLE Dose (
idDose serial not null PRIMARY KEY,
quantidade int not null,
idReceita int references Receita(idReceita)
on update restrict
on delete restrict
)
46
Quadro 38—Script de criação da tabela Receita
Fonte: elaborado pelos autores.
Quadro 39—Script de criação da tabela Armazenamento
Fonte: elaborado pelos autores.
Quadro 40—Script de criação da tabela Via de Administração
Fonte: elaborado pelos autores.
Quadro 41—Script de criação da tabela Classificação
Fonte: elaborado pelos autores.
Quadro 42—Script de criação da tabela Finalidade
Fonte: elaborado pelos autores.
Quadro 43—Script de criação da tabela Reacoes
Fonte: elaborado pelos autores.
CREATE TABLE Receita (
idReceita serial not null PRIMARY KEY,
dataValidade Date not null,
descricao varchar(100) not null,
idConsulta int references Consulta (idConsulta)
on update restrict
on delete restrict,
cpf int references Paciente(cpf)
on update restrict
on delete restrict)
CREATE TABLE Armazenamento (
idArmazenamento serial not null PRIMARY KEY,
tipo varchar(100) not null)
CREATE TABLE ViaAdministracao (
idViaAdm serial not null PRIMARY KEY,
tipo varchar(100) not null)
CREATE TABLE Classificacao (
idClassificacao serial not null PRIMARY KEY,
tipo varchar(100) not null)
CREATE TABLE Finalidade (
idFinalidade serial not null PRIMARY KEY,
tipo varchar(100) not null)
CREATE TABLE Reacoes (
idReacao serial not null PRIMARY KEY,
tipo varchar(100) not null)
47
Quadro 44—Script de criação da tabela Forma
Fonte: elaborado pelos autores.
Quadro 45—Script de criação da tabela Fabricante
Fonte: elaborado pelos autores.
Quadro 46—Script de criação da tabela Tarja
Fonte: elaborado pelos autores.
Quadro 47—Script de criação da tabela Possui Horas
Fonte: elaborado pelos autores.
CREATE TABLE Forma (
idFoma serial not null PRIMARY KEY,
estado varchar(100) not null,
tipo varchar(100) not null)
CREATE TABLE Fabricante (
idFabricante serial not null PRIMARY KEY,
nomeFantasia varchar(100) not null,
razaoSocial varchar(100) not null,
endereco varchar(100) not null,
cidade varchar(100) not null,
site varchar(100) not null,
cnpj int not null ,
ie int not null)
CREATE TABLE Tarja (
idTarja serial not null PRIMARY KEY,
cor varchar(100) not null,
nome varchar(100) not null)
CREATE TABLE PossuiHora_PossuiHora (
idPossuiHora serial not null primary key,
idHora int references Horario(idHora)
on update restrict
on delete restrict,
idDose int references Dose(idDose)
on update restrict
on delete restrict)
48
Quadro 48—Script de criação da tabela Realiza
Fonte: elaborado pelos autores.
Quadro 49—Script de criação da tabela Relação Trabalho
Fonte: elaborado pelos autores.
Quadro 50—Script de criação da tabela Relação Possui
Fonte: elaborado pelos autores.
Quadro 51—Script de criação da tabela Relação Gera
CREATE TABLE realiza_realiza (
idRealiza serial not null PRIMARY KEY,
resultado varchar(100) not null,
idConsulta int references Consulta(idConsulta)
on update restrict
on delete restrict,
idExame int references Exame(idExame)
on update restrict
on delete restrict
)
CREATE TABLE Relacao1_Trabalha (
idTrabalha serial not null PRIMARY KEY,
crm int references Medico(crm)
on update restrict
on delete restrict,
cnpj int references Clinica(cnpj)
on update restrict
on delete restrict)
CREATE TABLE possui_possui (
idPossui serial not null PRIMARY KEY,
lote int references Medicamento(lote)
on update restrict
on delete restrict,
idFinalidade int references Finalidade(idFinalidade)
on update restrict
on delete restrict)
49
Fonte: elaborado pelos autores.
Quadro 52—Script de criação da tabela Medicamento
CREATE TABLE gera_gera (
idGera serial not null PRIMARY KEY,
idReacao int references Reacoes(idReacao)
on update restrict
on delete restrict,
lote int references Medicamento(lote)
on update restrict
on delete restrict)
CREATE TABLE Medicamento (
lote serial not null PRIMARY KEY,
nome varchar(100) not null,
validade Date not null,
dataFabricacao Date not null,
numeroRegistro int not null,
Peso float not null,
quantidade int not null,
substanciaPrincipal varchar(100) not null,
crf int not null,
sac int not null,
duracao int not null,
idadeUso int not null,
idReceita int references Receita(idReceita)
on update restrict
on delete restrict,
idViaAdm int references ViaAdministracao(idViaAdm)
on update restrict
on delete restrict,
idArmazenamento int references Armazenamento(idArmazenamento)
on update restrict
on delete restrict,
idClassificacao int references Classificacao(idClassificacao)
on update restrict
on delete restrict,
idTarja int references Tarja(idTarja)
on update restrict
on delete restrict,
idFoma int references Forma(idFoma)
on update restrict
on delete restrict)
50
Fonte: elaborado pelos autores.
Quadro 53—Script de criação da tabela Relação Fabrica
Fonte: elaborado pelos autores.
4.4 S
E
L
E
C
T
S
DE ALGUMAS TABELAS
Nesse tópico o Quadro 54 até 57 será abordado os select de algumas tabelas do banco
de dado, que é utilizados para obter as consultas das tabelas mais importante do sistema.
Figura 14— Consultar todos os pacientes, a cidade e o estado.
Fonte: elaborado pelos autores.
CREATE TABLE fabrica_fabrica (
idFabrica serial not null PRIMARY KEY,
idFabricante int references Fabricante(idFabricante)
on update restrict
on delete restrict,
lote int references Medicamento(lote)
on update restrict
on delete restrict)
51
Figura 15— Consultar de um determinado paciente, a consulta e os exames
solicitados.
Fonte: elaborado pelos autores.
Figura 16— Consultar de um determinado paciente, a receita, o medicamente, a
dose e o horário solicitados.
Fonte: elaborado pelos autores.
Fonte: elaborado pelos autores.
52
Figura 17— Consultar de um determinado medicamento: o fabricante, tarja,
classificação, finalidade, reações, forma, armazenamento e a via administração.
Fonte: elaborado pelos autores.
54
5 LAYOUT WEB ACESSIBILIDADE
A figura abaixo é o layout do MedicTime, sendo que é um site com acessibilidade
onde qualquer pessoa não importando sua dificuldade consegue navegar e conhecer um pouco
sobre o sistema. O site possui os botões de contraste para pessoas que possui daltonismo, a
barra de acessibilidade que torna fácil a navegação numa determinada pagina.
Figura 18— Pagina Principal do Site
Fonte: elaborado pelos autores.
Figura 19—Mapa do Site
Fonte: elaborado pelos autores.
55
6 JAVASCRIP
Na figura abaixo representa o login do sistema MedicTime, sendo que é nessa parte
que usuário paciente entrará com o seu e-mail ou nome e a senha. Se os dados forem corretos
então o sistema aparecerá para que o paciente consiga consultar os dados sobre o
medicamento.
Figura 20 — Login do Sistema MedicTime
Fonte: elaborado pelos autores.
Quadro 54—Formulário do Sistema MedicTime
No quadro abaixo temos o script do formulário usado no sistema MedicTime. Nesse
formulário temos informações para que o paciente possa responder.
$(document).ready( function() {
$("#form").validate({
rules:{
nome:{
required:true
},
56
sexo:{
required:true
},
estado:{
required:true
},
cidade:{
required:true
},
site:{
required:true, url:true
},
cep:{
required:true, number:true, maxlength:8, minlength:8
},
tel:{
required:true, number:true, maxlength:10, minlength:10
},
cel:{
required:true, number:true, maxlength:11, minlength:11
},
email:{
required:true, email:true
},
mensagem:{
required:true
}
},
messages:{
nome:{
required: "Digite o seu nome"
},
sexo:{
required: "Informe um sexo"
57
},
estado:{
required: "Informe um Estado"
},
cidade:{
required: "Informe uma cidade"
},
site:{
required: "Digite o site",
url: "Digite um site válido"
},
cep:{
required: "Digite o CEP",
number: "Digite um CEP válido",
maxlength: "Digite um CEP válido",
minlength: "Digite um CEP válido"
},
tel:{
required: "Digite o telefone",
number: "Digite um telefone válido",
maxlength: "Digite um telefone válido",
minlength: "Digite um telefone válido"
},
cel:{
required: "Digite o celular",
number: "Digite um celular válido",
maxlength: "Digite um celular válido",
minlength: "Digite um celular válido"
},
email:{
required: "Digite o seu e-mail para contato",
email: "Digite um e-mail válido"
},
mensagem:{
required: "Digite a mensagem"
}
58
}
});
});
function cidadesp(){
document.getElementById('cidade').innerHTML = '<option value="Fernandopolis"> Fernandópolis </option> <option value="Sao Jose do Rio Preto"> São José do Rio Preto </option> <option value="São Paulo" > São Paulo </option>';
}
function cidademg(){
document.getElementById('cidade').innerHTML = '<option value="Rio de Janeiro" > Rio de Janeiro </option> <option value="Niterói" > Niterói </option> <option value="Nova Friburgo" >Nova Friburgo </option>';
}
function checarRadio(name){
var obj_resultado = document.getElementById('resultado');
var resposta = "";
var resp = document.getElementsByName(name);
for (var i = 0; i < resp.length; i++) {
if (resp[i].checked) {
return resp[i].value;
}
}
return 'Não foi respondida!';
}
function checarCheck(name) {
var checks = document.getElementsByName(name);
var valor = "";
for (var i = 0; i < checks.length; i++) {
if (checks[i].checked) {
valor += checks[i].value+", ";
}
}
if(valor == "")
valor = "Não respondido!";
59
return valor;
}
$(function() {
$('#slides').slidesjs({
width: 940,
height: 528,
play:{
interval:3000,
auto: true
},
navigation: false
});
});
Fonte: elaborado pelos autores.
60
CONCLUSÃO
A criação do sistema MedicTime é viável tanto pelo lado das clinicas e dos
pacientes, pois é inovador e oferece uma alternativa para ajudar os pacientes a controlar os
medicamentos de forma correta e segura. O sistema possui como diferencial dos outros
existentes a participação primordial do médico que será responsável para alimentar o sistema
assim evitando que os pacientes façam o uso sem o acompanhamento de um profissional da
área.
62
7 REFERÊNCIAS
BRASIL. Lei n. 5991, 17/12/1973. Dispõe sobre o controle sanitário do comércio de drogas, medicamentos, insumos farmacêutico e correlatos, e dá outras providências. Diário Oficial da União de 21/12/1973. Seção 1, pt. 1, p. 12182.
COLOMBO D. Padrão de prescrição de medicamentos nas Unidades de Programa de Saúde da Família de Blumenau. Rev Bras Ciênc Farm 2004;40(4).
DANRESA. Principais técnicas de levantamento de requisitos de sistemas: principais técnicas de levantamento de requisitos de sistemas. 2012. Disponível em:<http://www.danresa.com.br/fabrica-de-software/index.php/principais-tecnicas-de-levantamento-de-requisitos-de-sistemas/>. Acesso em: 08 maio 2016.
DELGADO, P.G. Conocimiento del paciente sobre sus medicamentos. 2008. 304f. Tese (Doutorado em Farmácia) – Universidade de Granada, Espanha, 2008.
DIDONE, T. V. N. Idosos: o que conhecem sobre os medicamentos prescritos que utiliza? 2015. 132f. Dissertação (Mestrado em fármaco e Medicamentos) – Universidade de São Paulo, São Paulo, 2015.
FACOM. Diagrama de Classe. 2014. Disponível em:<www.facom.ufu.br/.../Parte7%20-%20Diagrama%20de%20Classes.pptx>.Acesso em : 23 fev. 2014.
GUEDES, G. UML 2 –Uma Abordagem Prática. São Paulo: Novatec, 2009.
MELLO. L, C, S. Levantamento de Requisitos. 2010. Disponível em:< http://www.ice.edu.br/TNX/encontrocomputacao/artigos->. Acesso em: 09, maio. 2016.
ORGANIZAÇÃO MUNDIAL DE SAÚDE. Comitê de expertos en uso de medicamentos esenciales. Informe. Ginebra, 1984
PANIZ, M. V. Acesso a medicação em população assistida por diferentes modelos de atenção básica na regiões sul e nordeste do Brasil. 2009. 223f. Tese (Doutorado em Ciências) – universidade Federal de Pelotas, Rio Grande do Sul, 2009. PUC-RIO. UML: Diagrama de Classes. 2013. Disponível em: <http://www.les.inf.puc-rio.br/wiki/images/7/7f/Aula1-diagrama_classes.pdf>. Acesso em: 01 abr. 2011.
SILVA, P. V. O uso de medicamentos na atenção básica em Londrina, PR. 2004, 114f. Dissertação (Mestrado em Saúde Pública) - Universidade Estadual de Londrina, Paraná, 2004.
TEIXEIRA, A. A indústria Farmacêutica no Brasil: Um estudo do impacto socioeconômico dos medicamentos genéricos. 2014. 83f. Monografia (Bacharel em Ciências Econômicas) - Universidade Estadual Paulista, São Paulo, 2014.
UFPR. UNIVERSIDADE FEDERAL PARANÁ. Diagrama de Classe. 2012 .Disponível em:<http://www.inf.ufpr.br/silvia/ESNovo/UML/pdf/ModeloConceitualAl.pdf>. Acesso em: 22 fev. 2014.