Medic time

___________________________________________________________________________
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..........................................................................16
2.2 DESCRIÇÃO DO SISTEMA ATUAL.......................................................................................16
2.3 DESCRIÇÃO DOS PRINCIPAIS PROBLEMAS.........................................................................17
2.4 DESCRIÇÃO DOS REQUISITOS FUNCIONAIS ........................................................................18
2.5 DESCRIÇÃO DOS REQUISITOS NÃO FUNCIONAIS ................................................................19
3 VISÃO DE CASO DE USO - UML..................................................................................20
3.1. DIAGRAMA DE CLASSES......................................................................................................20
3.2. DEFINIÇÃO DOS ATORES .....................................................................................................21
3.3. LISTA DE CASOS DE USO.....................................................................................................23
3.4. DIAGRAMA DE CONTEXTO ..................................................................................................23
3.5. DIAGRAMA DE CASOS DE USO INDIVIDUAIS ........................................................................25
3.6. DIAGRAMA DE SEQUÊNCIA .................................................................................................30
4 BANCO DE DADOS..........................................................................................................35
4.1 MODELO ENTIDADE RELACIONAMENTO ..........................................................................35
4.1.1 Modelo conceitual do banco de dados .......................................................35
4.2 DICIONÁRIO DOS ATRIBUTOS DAS CLASSES .....................................................................38
4.3 SCRIPT DAS TABELAS .......................................................................................................44
4.4 SELECTS DE ALGUMAS TABELAS......................................................................................51
5 LAYOUT WEB ACESSIBILIDADE...............................................................................55
6 JAVASCRIP.......................................................................................................................56
7 REFERÊNCIAS.................................................................................................................62

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 medicamentos. O

15
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
2.2 DESCRIÇÃO DO SISTEMA ATUAL

17
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.
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.

19
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.

20
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.
Figura 1 –Diagrama de Classe

21
Fonte: elaborado pelos autores.
3.2. DEFINIÇÃO DOS ATORES

22
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

23
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 receita
Dados 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
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).
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á

24
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

25
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
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
8-Sistema envia msg 01:"Cadastro efetuado com sucesso!"

26
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

27
Fluxo Normal
1-AtorMedico solicita alteração dos dados do cadastro
2-Sistema habilita edição de dados
3-AtorMedico informa dados
5-AtorMedico confirma dados e envia
6-Sistema atualiza os dados
7-Sistema envia msg02: "Cadastro alterado com sucesso!"
Fluxo Alternativo
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

28
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

29
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

30
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.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.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).

31
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
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

32
Diagrama de Seqüência 2: Consultar Receita
Figura 10—Diagrama de Seqüência Consultar Receita

33
Diagrama de Sequência 3: Listar Receita
Figura 11— Diagrama de Sequência Listar receita

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.

36
Figura 12 — Modelo Conceitual do banco de Dados

37
4.1.2 Modelo logico do banco de dados
Figura 13 — Modelo Lógico do banco de Dados

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
Quadro 3—Dicionário dos Atributos da Tabela Estado
Quadro 4—Dicionário dos Atributos da Tabela Pessoa
Quadro 5—Dicionário dos Atributos da Tabela Paciente
Nome do Atributo Descrição do Atributo Tipo Tam. PK FK Req.
idCidade Identificador da Cidade Integer - S N S
nomeCidade Nome da Cidade String 100 N N S
idUF Identificador do Estado Integer - N S S
idUF Identificador do Estado Integer - S N S
nomeUF Nome do Estado String 100 N N S
idPessoa Identificador da Pessoa Integer - S N S
nome Nome da Pessoa String 100 N N S
endereco Endereço da Pessoa String 100 N N S
Telefone Telefone da Pessoa String 20 N N S
Bairro Bairro da Pessoa String 50 N N S
numero Numero casa da Pessoa Integer - N N S
idCidade Identificador da Cidade Integer - N S S
cpf Identificador CPF do Paciente Integer - S N S
rg RG do Paciente Integer - N N S
dataNascimento Data Nascimento Paciente Date - N N S
idPessoa Identificador da Pessoa Integer - N S S

39
Quadro 6—Dicionário dos Atributos da Tabela Médico
Quadro 7—Dicionário dos Atributos da Tabela Clinica
Quadro 8—Dicionário dos Atributos da Tabela Trabalha
Quadro 9—Dicionário dos Atributos da Tabela Exame
Quadro 10—Dicionário dos Atributos da Tabela Realiza
crm Identificador do Medico Integer - S N S
Especialidade Tipo de Especialidade String 100 N N S
idPessoa Identificador da Pessoa Integer - N S S
cnpj Identificador CNPJ da Clinica Integer - S N S
razaoSocial Razão Social da clinica String 100 N N S
nomeFantasia Nome Fantasia da Clinica String 100 N N S
ie Inscrição Estadual da Clinica String 30 N N S
site Endereço do Site da Clinica String 50 N N S
idTrabalha Identificador Trabalha Integer - S N S
crm Identificador do Medico Integer - N S S
cnpj Identificador CNPJ da Clinica Integer - N S S
idExame Identificador do Exame Integer - S N S
descricao Descrição do Exame String 100 N N S
idRealiza Identificador Realiza Integer - S N S
idExame Identificador do Exame Integer - N S S
idConsulta Identificador da Consulta Integer - N S S
Resultado Resultado do Exame String 100 N N S

40
Quadro 11—Dicionário dos Atributos da Tabela Consulta
Quadro 12—Dicionário dos Atributos da Tabela Receita
Quadro 13—Dicionário dos Atributos da Tabela Dose
Quadro 14—Dicionário dos Atributos da Tabela Horário
idConsulta Identificador Consulta Integer - S N S
numeroProntuario Numero do Prontuário Integer - N S S
descricao Descrição da Consulta String 100 N N S
dataConsulta Data Consulta Date - N N S
horaConsulta Hora Consulta Date - N N S
dataProximaConsu Próxima Consulta Date - N N S
horaProximaConsu Hora da Próxima Consulta Date - N N S
crm Identificador do Medico Integer - N S S
cpf Identificador CPF do Paciente Integer - N S S
idReceita Identificador Receita Integer - S N S
dataValidade Data da Validade da Receita Date - N N S
descricao Descrição da Receita String 100 N N S
idConsulta Identificador da Consulta Integer - N S S
cpf Identificador CPF Paciente Integer - N S S
idDose Identificador da Dose Integer - S N S
quantidade Quantidade de Dose Integer - N N S
idReceita Identificador da Receita Integer - N S S
idHora Identificador Horário Integer - S N S
quantasHoras Quantas Doses por Hora Integer - N N S

41
Quadro 15—Dicionário dos Atributos da Tabela Possui Horas
Quadro 16—Dicionário dos Atributos da Tabela Medicamento
Quadro 17—Dicionário dos Atributos da Tabela ViaAdministracao
Quadro 18—Dicionário dos Atributos da Tabela Armazenamento
idPossuiHora Identificador Trabalha Integer - S N S
idHora Identificador do Horário Integer - N S S
idDose Identificador da Dose Integer - N S S
lote Numero do Lote Integer - S N S
Nome Nome do Medicamento String 100 N S S
Validade Validade do Medicamento Date - N N S
dataFabricacao Data de Fabricação Date - N N S
numeroRegistro Numero do Registro Integer - N N S
peso Peso do Medicamento Float - N N S
quantidade Quantidade de Medicamento Integer - N N S
substanciaPrincipal Substância Principal String 100 N S S
crf CRF do Medicamento Integer - N S S
sac SAC de atendimento Integer - N N S
duração Tempo de Duração Integer - N N S
idadeUso Idade Adequada para Uso Integer - N N S
idReceita Identificador da Receita Integer - N S S
idViaAdm Identificador Via Administra Integer - N S S
idArmazenamento Identificador Armazenamento Integer - N S S
idClassificacao Identificador da Classificação Integer - N S S
idTarja Identificador da Tarja Integer - N S S
idForma Identificador da Forma Integer - N S S
idViaAdmi Identificador Via Administra Integer - S N S
tipo Descrição Via Administração String 100 N N S
idArmazenamento Identificador Armazenamento Integer - S N S
tipo Descrição do Armazenamento String 100 N N S

42
Quadro 19—Dicionário dos Atributos da Tabela Classificacao
Quadro 20—Dicionário dos Atributos da Tabela Finalidade
Quadro 21—Dicionário dos Atributos da Tabela Possui
Quadro 22—Dicionário dos Atributos da Tabela Reacao
Quadro 23—Dicionário dos Atributos da Tabela Gera
idClassificacao Identificador da Classificação Integer - S N S
tipo Descrição da Classificação String 100 N N S
idFinalidade Identificador da Finalidade Integer - S N S
tipo Descricão da Finalidade String 100 N N S
idPossui Identificador Possui Integer - S N S
idFinalidade Identificador da Finalidade Integer - N S S
lote Identificador do Lote Integer - N S S
idReacao Identificador de Reação Integer - S N S
tipo Descricão da Reação String 100 N N S
idGera Identificador Gera Integer - S N S
idReacao Identificador da Reação Integer - N S S

43
Quadro 24—Dicionário dos Atributos da Tabela Forma
Quadro 25—Dicionário dos Atributos da Tabela Tarja
Quadro 26—Dicionário dos Atributos da Tabela Fabricante
Quadro 27—Dicionário dos Atributos da Tabela Fabrica
idForma Identificador de Forma Integer - S N S
tipo Descrição de Forma String 100 N N S
estado Descrição do Estado String 100 N N S
idTarja Identificador da Tarja Integer - S N S
nome Descrição da Tarja String 100 N N S
cor Cor da Tarja String 100 N N S
idFabricante Identificador Do Fabricante Integer - S N S
nomeFantasia Nome Fantasia da Fabrica String 100 N N S
razaoSocial Razão social da Fabrica String 100 N N S
Endereço Endereço da Fabrica String 100 N N S
cidade Cidade Localizada a Fabrica String 100 N N S
Site Site da Fabrica String 100 N N S
cnpj CNPJ da Fabrica Integer - N N S
ie Inscrição Estadual Fabrica Integer - N N S
idFabrica Identificador Fabrica Integer - S N S
idFabricante Identificador do Fabricante Integer - N S S

44
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
Quadro 29—Script de criação da tabela Cidade
Quadro 30—Script de criação da tabela Pessoa
Quadro 31—Script de criação da tabela Médico
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 )
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

45
Quadro 32—Script de criação da tabela Paciente
Quadro 33—Script de criação da tabela Clinica
Quadro 34—Script de criação da tabela Exame
Quadro 35—Script de criação da tabela Consulta
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)
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,

46
Quadro 36—Script de criação da tabela Horario
Quadro 37—Script de criação da tabela Dose
Quadro 38—Script de criação da tabela Receita
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
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
)
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

47
Quadro 39—Script de criação da tabela Armazenamento
Quadro 40—Script de criação da tabela Via de Administração
Quadro 41—Script de criação da tabela Classificação
Quadro 42—Script de criação da tabela Finalidade
Quadro 43—Script de criação da tabela Reacoes
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,
CREATE TABLE Classificacao (
idClassificacao serial not null PRIMARY KEY,
CREATE TABLE Finalidade (
idFinalidade serial not null PRIMARY KEY,
CREATE TABLE Reacoes (
idReacao serial not null PRIMARY KEY,

48
Quadro 44—Script de criação da tabela Forma
Quadro 45—Script de criação da tabela Fabricante
Quadro 46—Script de criação da tabela Tarja
Quadro 47—Script de criação da tabela Possui Horas
CREATE TABLE Forma (
idFoma serial not null PRIMARY KEY,
estado 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)

49
Quadro 48—Script de criação da tabela Realiza
Quadro 49—Script de criação da tabela Relação Trabalho
Quadro 50—Script de criação da tabela Relação Possui
on update restrict
on delete restrict)
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,

50
Quadro 51—Script de criação da tabela Relação Gera
Quadro 52—Script de criação da tabela Medicamento
idFinalidade int references Finalidade(idFinalidade)
on update restrict
on delete restrict)
CREATE TABLE gera_gera (
idGera serial not null PRIMARY KEY,
idReacao int references Reacoes(idReacao)
on update restrict
on delete restrict,
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

51
Quadro 53—Script de criação da tabela Relação Fabrica
4.4 SELECTS 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.
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)
CREATE TABLE fabrica_fabrica (
idFabrica serial not null PRIMARY KEY,
idFabricante int references Fabricante(idFabricante)
on update restrict
on delete restrict,
on update restrict
on delete restrict)

52
Figura 14— Consultar todos os pacientes, a cidade e o estado.
Figura 15— Consultar de um determinado paciente, a consulta e os exames
solicitados.

53
Figura 16— Consultar de um determinado paciente, a receita, o medicamente, a dose
e o horário solicitados.
Figura 17— Consultar de um determinado medicamento: o fabricante, tarja,
classificação, finalidade, reações, forma, armazenamento e a via administração.

54

55
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
Figura 19—Mapa do Site

56
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
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
},
sexo:{

57
required:true
},
estado:{
required:true
},
cidade:{
required:true
},
site:{
required:true, url:true
},
cep:{
required:true, number:true, maxlength:8, minlength:8
},
tel:{
},
cel:{
},
email:{
required:true, email:true
},
mensagem:{
required:true
}
},
messages:{
nome:{
required: "Digite o seu nome"
},
sexo:{
required: "Informe um sexo"
},
estado:{
required: "Informe um Estado"

58
},
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"
}
}
});
});

59
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!";
return valor;
}

60
$(function() {
$('#slides').slidesjs({
width: 940,
height: 528,
play:{
interval:3000,
auto: true
},
navigation: false
});
});

61
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.

63
VIEIRA, V. M..M.; OHAYON, P. Inovação em fármacos e medicamentos: estado-da-arte no
Brasil e políticas de P&D. 2006. Disponível em:<>Acesso em 08 maio de 2016.

Medic time

Mais conteúdo relacionado

Mais procurados

Semelhante a Medic time

Mais de Vanessa Finoto

Medic time