Engenharia de software web

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

22

Figura 1 –Diagrama de Classe

Fonte: elaborado pelos autores.

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


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


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


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


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


28

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

29


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


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


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

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


33

Diagrama de Seqüência 2: Consultar Receita

Figura 10—Diagrama de Seqüência Consultar Receita


34

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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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


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

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


Quadro 30—Script de criação da tabela Pessoa


Quadro 31—Script de criação da tabela Médico


Quadro 32—Script de criação da tabela Paciente


Quadro 33—Script de criação da tabela Clinica


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


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


Quadro 35—Script de criação da tabela Consulta


Quadro 36—Script de criação da tabela Horario


Quadro 37—Script de criação da tabela Dose


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


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


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


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,


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,


47

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)

on update restrict

on delete restrict)

48

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


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


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,


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


Quadro 53—Script de criação da tabela Relação Fabrica


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.


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)

51

Figura 15— Consultar de um determinado paciente, a consulta e os exames

solicitados.


Figura 16— Consultar de um determinado paciente, a receita, o medicamente, a

dose e o horário solicitados.



52

Figura 17— Consultar de um determinado medicamento: o fabricante, tarja,

classificação, finalidade, reações, forma, armazenamento e a via administração.


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


Figura 19—Mapa do Site


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


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:{


},

cel:{


},

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

});

});


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.

http://www.les.inf.puc-rio.br/wiki/images/7/7f/Aula1-diagrama_classes.pdf

http://www.les.inf.puc-rio.br/wiki/images/7/7f/Aula1-diagrama_classes.pdf

http://www.facom.ufu.br/.../Parte7%20-%20Diagrama%20de%20Classes.pptx

http://www.facom.ufu.br/.../Parte7%20-%20Diagrama%20de%20Classes.pptx

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.

Engenharia de software web

Software

Transcript of Engenharia de software web