Modelo de TCC - dmedicamentos

jockeyropeInternet και Εφαρμογές Web

2 Φεβ 2013 (πριν από 4 χρόνια και 6 μήνες)

517 εμφανίσεις



F
ACULDADE DE
T
ECNOLOGIA
R
OGACIONISTA

C
URSO
S
UPERIOR DE
D
ESENVOLVIMENTO DE
S
ISTEMAS

DM
EDICAMENTOS

S
OFTWARE PARA
G
ERENCIAMENTO DA
D
ISTRIBUIÇÃO DE
M
EDICAMENTOS

A
UTOR
:

A
LESSANDRO DE
S
OUZA
Q
UEIROZ

M
ONOGRAFIA DE
C
ONCLUSÃO DE
C
URSO

Orientador: Fábio Caldas

Brasíl
ia,
10

de
dezembro

de 2007.




A
LESSANDRO DE
S
OUZA
Q
UEIROZ

DM
EDICAMENTOS

Projeto Final de Graduação, sob a orientação
do Prof. Fábio Caldas, avaliado por Banca
Examinadora do Curso de Desenvolvimento
de Sistemas da Faculdade Rogacionista e
constitui requisit
o para a obtenção do título de
Tecnólogo em Desenvolvimento de Sistemas.



Autoria:

Alessandro de Souza Queiroz

Título:

DMedicamentos


Software para Gerenciamento da Distribuição de Medicamentos

Projeto Final de Graduação, sob a orientação
do Prof. Fábio Ca
ldas, avaliado por Banca
Examinadora do Curso de Desenvolvimento
de Sistemas da Faculdade Rogacionista e
constitui requisito para a obtenção do título de
Tecnólogo em Desenvolvimento de Sistemas.

Os componentes da banca de avaliação, abaixo listados,

cons
ideram este trabalho aprovado.


Nome

Titulação

Assinatura

Instituição

1





2





3





Data da aprovação:

____ de _____________________ de ________.


Dedico este trabalho a minha esposa,
Priscila, que durante todos esses anos de
curso sofreu com a mi
nha ausência.

Dedico também a meus pais, que
esperam por este momento há anos.



AGRADECIMENTOS

Agradeço especial
mente

a Deus que me
deu forças para concluir este curso.



RESUMO

DMedicamentos é um sistema cujo principal objetivo é informatizar o processo de
distribuição de medicamentos d
a Prefeitura Municipal de Alexânia,
visando principalmente
um maior controle dos

medicamentos. Para atingir este objetivo, o sistema força uma
melhoria no processo e proporciona uma tomada de decisão mais afinada por parte dos

servidores.

O software foi modelado utilizando
conceitos da UML, com diagramas de caso de
uso, seqüência, atividade, entre outros. Todo o projeto é
Orienta
do

a Objetos, aproveitando
seus
benefícios
. A tecnologia
escolhida para o desenvolvimento

foi
Ruby O
n Rails
.

Como
banco de dados, foi escolhido o MySQL, por ser um banco gratuito, e por int
e
grar bem com o
Rails.



Palavras
-
chave
:

Ruby On Rails, UML
,
MySQL,
Distribuição, E
s
toque.



ABSTRACT

DMedicamentos is a system whose main goal is to computerize the pro
cess of

distribution of
medicines in Prefecture of Alexânia
, targeting mainly the economy of medicines. To achieve
this goal, the sy
s
tem will force an improvement in the process and provides a decision
-
making
more refined on the part of servers.

The softwa
re gone model by concepts of UML, with di
a-
grams of use cases, sequence, activity, and others.

The software was modeled using concepts
of UML, with use case diagrams, sequence, activity, among others. The entire project is O
b-
ject Oriented, enjoying its bene
fits. The technology chosen for the development was Ruby On
Rails. As the database was chosen MySQL, to be free, and to integrate well with Rails.



Keywords:

Ruby On Rails, UML, MySQL
, Distribution, Inve
n
tory.



SUMÁRIO
1

Introdução

................................
................................
................................
............

5

1.1

Motivação

................................
................................
................................
.....................

5

1.2

Empresa ou Organização Interessada

................................
................................
..........

5

1.3

Estrutura da Organização

................................
................................
.............................

6

1.4

Histórico do Sistema Existente
................................
................................
......................

7

1.5

Problemas Diagnosticados

................................
................................
...........................

7

1.6

Usuários do Sistema

................................
................................
................................
.....

8

2

Ob
jetivos

................................
................................
................................
..............

9

2.1

Objetivo Geral

................................
................................
................................
...............

9

2.2

Objetivos Específicos

................................
................................
................................
....

9

3

Pro
posta do Sistema

................................
................................
.........................

10

3.1

Descrição do Processo Atual

................................
................................
......................

10

3.2

Descrição do Sistema Proposto

................................
................................
..................

10

3.3

Resultados Esperados

................................
................................
................................
.
11

3.4

Restrições do Sistema Proposto

................................
................................
..................
11

3.5

Recursos Necessários para Exec
ução

................................
................................
........

12

3.5.1

Recursos de Hardware

................................
................................
................................
..............

12

3.5.2

Recursos de Software

................................
................................
................................
................

13

3.5.3

Recursos Humanos
................................
................................
................................
....................

13

3.5.4

Resumo dos Recursos

................................
................................
................................
...............

14

3.6

Relação Custo x Benefício

................................
................................
..........................

14

3.7

Áreas Afetadas pelo Sistema

................................
................................
......................

14

4

Planejamento do Projeto

................................
................................
...................

15

4.1

Plano do Processo de Desenvolvim
ento

................................
................................
.....

15

4.1.1

Ciclo de Vida do Projeto

................................
................................
................................
.............

15

4.1.2

Documentos do Projeto

................................
................................
................................
..............

17

4.2

Plano de Acompanhamento

................................
................................
........................

18



4.2.1

Marcos e Pontos de Controle

................................
................................
................................
.....

18

4.2.2

Métodos de Acompanhamento e Controle

................................
................................
.................

18

4.2.3

Análise e Gerência de Riscos

................................
................................
................................
....

19

4.3

Cronograma

................................
................................
................................
................

21

5

Embasamento

teórico, Metodologia e Tecnologia Adotada

...........................

22

5.1

Embasamento Teórico

................................
................................
................................

22

5.1.1

Orientação a objetos

................................
................................
................................
..................

22

5.1.2

Modelagem relacional

................................
................................
................................
................

24

5.1.3

Ajax

................................
................................
................................
................................
............

25

5.1.3.1

Aplicações Web Tradicionais x Aplicaç
ões Ajax

................................
................................

26

5.1.3.2

Como usar Ajax em uma aplicação web

................................
................................
............

27

5.2

Metodologia

................................
................................
................................
................

27

5.3

Tecnologia Adotada

................................
................................
................................
.....

28

5.3.1

Ruby On Rails

................................
................................
................................
............................

28

5.3.1.1

Composição do Rails

................................
................................
................................
.........

29

5.3.1.2

The Rails Cycle

................................
................................
................................
..................

31

5.3.2

MySQL

................................
................................
................................
................................
.......

31

5.3.2.1

Características

................................
................................
................................
...................

32

6

Especificação dos Requisitos do Sistema

................................
......................

33

6.1

Problemas e Oportunidades

................................
................................
.......................

33

6.1.1

Problemas

................................
................................
................................
................................
..

33

6.1.2

Oportunidades

................................
................................
................................
............................

34

6.2

Requisitos do Software

................................
................................
...............................

34

6.3

Req
uisitos Suplementares

................................
................................
..........................

36

6.4

Restrições técnicas

................................
................................
................................
.....

36

7

Modelos de Casos de Uso

................................
................................
................

37

7.1

Casos de Uso

................................
................................
................................
.............

37

7.2

Descrição dos atores

................................
................................
................................
..

38

7.3

Diagrama de Casos de Uso

................................
................................
........................

39

7.4

Descrição dos Casos de Uso

................................
................................
......................

40

7.4.1

Manter pessoas

................................
................................
................................
..........................

40

7.4.2

Manter medicamentos
................................
................................
................................
................

42

7.4.3

Manter médicos

................................
................................
................................
..........................

44

7.4.4

Manter usuários

................................
................................
................................
.........................

46

7.4.5

Efetuar login

................................
................................
................................
...............................

48

7.4.6

Distribuir medicamentos
................................
................................
................................
.............

50

7.4.7

Imprimir ticket

................................
................................
................................
.............................

52

8

Leva
ntamento de Classes

................................
................................
.................

53



8.1

Diagrama Geral de Classes

................................
................................
........................

53

8.2

Descrição das Classes e Atributos

................................
................................
..............

54

8.2.1

Médico

................................
................................
................................
................................
........

54

8.2.2

Pessoa

................................
................................
................................
................................
.......

55

8.2.3

Usuário

................................
................................
................................
................................
.......

56

8.2.4

Distribuicao
................................
................................
................................
................................
.

57

8.2.5

Medicamento

................................
................................
................................
..............................

58

9

Modelos de Análise

................................
................................
...........................

59

9.1

Manter pessoas

................................
................................
................................
..........

59

9.2

Manter medicamentos

................................
................................
................................

63

9.3

Manter médicos

................................
................................
................................
..........

67

9.4

Manter usuários

................................
................................
................................
..........

71

9.5

Efetuar login

................................
................................
................................
................

74

9.6

Distribuir medicamentos e Imprimir ticket
................................
................................
....

76

10

Modelagem de Dados

................................
................................
......................

79

10.1

Modelo lógico

................................
................................
................................
............

79

10.2

Relações normalizad
as

................................
................................
.............................

79

10.3

Dicionário de Dados

................................
................................
................................
..

80

10.4

Diagrama físico

................................
................................
................................
.........

84

10.5

S
cripts

................................
................................
................................
.......................

84

11

Interfaces

................................
................................
................................
..........

88

11.1

Manter pessoas

................................
................................
................................
.........

88

11.2

Manter me
dicamentos

................................
................................
...............................

90

11.3

Manter médicos

................................
................................
................................
.........

91

11.4

Manter usuários

................................
................................
................................
........

93

11.
5

Efetuar login

................................
................................
................................
..............

94

11.6

Distribuir medicamentos

................................
................................
............................

95

12

Considerações finais

................................
................................
.......................

97


1

LISTA DE TABELAS

Tabela 1


Usuário #1 do sistema

................................
................................
...............................

8

Tabela 2


Usuário #2 do sistema

................................
................................
...............................

8

Tabela 3


Usuário #3 do sistema

................................
................................
...............................

8

Tabela 4


Recursos de hardware

................................
................................
.............................

12

Tabela 5


Recursos de software

................................
................................
..............................

13

Tabela 6


Recursos humanos

................................
................................
................................
..

13

Tabela 7


Resumo dos recursos

................................
................................
..............................

14

Tabela 8


Atividades

do ciclo de vida do projeto

................................
................................
...

17

Tabela 9


Documentos gerados

................................
................................
...............................

17

Tabela 10


Marcos e pontos de controle

................................
................................
.................

18

Tabela 11


Risco #1

................................
................................
................................
................

19

Tabela 12


Risco #2

................................
................................
................................
................

19

Tabela 13


Risco #3

................................
................................
................................
................

20

Tabela 14


Risco #4

................................
................................
................................
................

20

Tabela 15


Problema #1

................................
................................
................................
..........

33

Tabela 16


Problema #2

................................
................................
................................
..........

33

Tabela 17


Problema #3

................................
................................
................................
..........

33

Tabela 18


Problema #4

................................
................................
................................
..........

34

Tabela 1
9


Oportunidade #1

................................
................................
................................
...

34

Tabela 20


Requisito #1

................................
................................
................................
..........

34

Tabela 21


Requisito #2

................................
................................
................................
..........

34

Tabela 22


Requisito #3

................................
................................
................................
..........

35

Tabela 23


Requisito #4

................................
................................
................................
..........

35

Tabela 24


Requisito #5

................................
................................
................................
..........

35

Tabela 25


Requisito #6

................................
................................
................................
..........

35


2

Tabela 26


Requisito #7

................................
................................
................................
..........

35

Tabela 27


Requisito #8

................................
................................
................................
..........

36

Tabela 28


Restrição #1

................................
................................
................................
..........

36

Tabela 29


Restrição #2

................................
................................
................................
..........

36

Tabela 30


Caso
de Uso #1

................................
................................
................................
.....

37

Tabela 31


Caso de Uso #2

................................
................................
................................
.....

37

Tabela 32


Caso de Uso #3

................................
................................
................................
.....

37

Tabela 33


Caso de Uso #4

................................
................................
................................
.....

38

Tabela 34


Caso de Uso #5

................................
................................
................................
.....

38

Tabela 35


Caso de Uso #6

................................
................................
................................
.....

38

Tabela 36


Caso de Uso #7

................................
................................
................................
.....

38

Tabela 37


Ator #1

................................
................................
................................
..................

38

Tabela 38


Ator #2

................................
................................
................................
..................

38

Tabela 39


Ator #3

................................
................................
................................
..................

39

Tabela 40


Atributos da classe Médico

................................
................................
...................

54

Tabela 41


Atri
butos da classe Pessoa

................................
................................
....................

55

Tabela 42


Atributos da classe Usuário

................................
................................
..................

56

Tabela 43


Atributos da classe Distribuicao

................................
................................
...........

57

Tabela 44


Atributos da classe Medicamento

................................
................................
.........

58

Tabela 45
-

Dicionário de dados

................................
................................
...............................

80




3

LISTA DE ILUSTRAÇÕES

Ilustração 1


Modelo cascata

................................
................................
................................
...

16

Ilustração 2
-

Cronograma

................................
................................
................................
........

21

Ilustr
ação 3
-

O ciclo do Ruby on Rails.

................................
................................
...................

31

Ilustração 4
-

Diagrama de Casos de Uso

................................
................................
.................

39

Ilustração 5
-

Diagrama geral de classes

................................
................................
...................

53

Ilustração 6


Classe Médico

................................
................................
................................
....

54

Ilustração 7


Classe Pessoa

................................
................................
................................
.....

55

Ilu
stração 8


Classe Usuário

................................
................................
................................
...

56

Ilustração 9


Classe Distribuicao

................................
................................
............................

57

Ilustração 10


Classe Medicamento

................................
................................
........................

58

Ilustração 11


Caso de Uso Manter pessoas
-

resolução

................................
.........................

59

Ilustração 12


Caso de Uso Manter pessoas
-

diagrama de seqüência (cadastrar)

..................

59

Ilustração 13


Caso de Uso Manter pessoas
-

diagrama de seqüência (alterar)

......................

60

Ilustração 14


Caso de Uso Manter pessoas
-

diagrama de s
eqüência (deletar)
......................

61

Ilustração 15


Caso de Uso Manter pessoas
-

diagrama de atividades
................................
....

62

Ilustração 16


Caso de Uso Manter
medicamentos
-

resolução

................................
..............

63

Ilustração 17


Caso de Uso Manter medicamentos
-

diagrama de seqüência (cadastrar)

.......

63

Ilustração 18



Caso de Uso Manter medicamentos
-

diagrama de seqüência (alterar)

...........

64

Ilustração 19


Caso de Uso Manter medicamentos
-

diagrama de seqüência (deletar)

...........

65

Ilustração 20


Caso de Uso Manter medicamentos
-

diagrama de atividades

.........................

66

Ilustração 21


Caso de Uso Manter médicos
-

resolução

................................
........................

67

Ilustração 22


Caso de Uso Manter médicos
-

diagrama de seqüência (cadastrar)

.................

67

Ilustração 23


Caso de Uso Manter médicos
-

diagrama de seqüência (alterar
)

.....................

68

Ilustração 24


Caso de Uso Manter médicos
-

diagrama de seqüência (deletar)

....................

69

Ilustração 25


Caso de Uso Manter médicos
-

diagrama de atividades

................................
..

70


4

Ilustração 26


Caso de Uso Manter usuários
-

resolução

................................
........................

71

Ilustração 27


Caso de Uso Manter usuári
os
-

diagrama de seqüência (cadastrar)

.................

71

Ilustração 28


Caso de Uso Manter usuários
-

diagrama de seqüência (alterar)

.....................

72

Ilust
ração 29


Caso de Uso Manter usuários
-

diagrama de seqüência (deletar)

....................

72

Ilustração 30


Caso de Uso Manter usuários
-

diagrama de atividades

................................
..

73

Ilustração 31


Caso de Uso Efetuar login
-

resolução

................................
.............................

74

Ilustração 32


Caso de Uso Efetuar login
-

diagrama de seqüência

................................
........

7
4

Ilustração 33


Caso de Uso Efetuar login
-

diagrama de atividades

................................
.......

75

Ilustração 34


Caso de Uso Distribuir medicamentos / Imprimir ticket
-

resolução

...............

76

Ilustração 35


Caso de Uso Distribuir medicamentos / Imprimir ticket
-

diagrama de
seqüência

................................
................................
................................
................................
..

77

Ilustração 36


Caso de Uso Distribuir medicamento
s / Imprimir ticket
-

diagrama de
atividades

................................
................................
................................
................................
..

78

Ilustração 37


Modelo lógico do banco de dados
................................
................................
....

79

Ilustração 38


Modelo físico

do banco de dados

................................
................................
.....

84

Ilustração 39


Interface Manter pessoas

................................
................................
..................

88

Ilustração 40


Interface Cadastrar pessoa

................................
................................
................

89

Ilustração 41


Interface Alterar pessoa

................................
................................
....................

89

Ilustração 42


Interface Manter medicamentos

................................
................................
.......

90

Ilustração 43


Interface Cadastrar medicamento

................................
................................
.....

90

Ilustração 44


Interface Alterar medicamento

................................
................................
.........

91

Ilustração 45


Interface Manter médicos

................................
................................
.................

91

Ilustração 46


Interface Cadastrar médico

................................
................................
..............

92

Ilustração 47


Interface Alterar médico

................................
................................
..................

92

Ilustração 48


Interface Manter usuários

................................
................................
.................

93

Ilustração 49


Interface Cadastrar usuário

................................
................................
..............

93

Ilustração 50


Interface Alterar usuário

................................
................................
..................

94

Ilustração 51


Interface Efetuar login

................................
................................
.....................

94

Ilustração 52


Inte
rface Distribuir medicamentos

................................
................................
...

95

Ilustração 53


Interface Histórico

................................
................................
............................

96



5

1

INTRODUÇÃO

1.1

Motivação

Ao olhar de perto

a realidade da Prefeitura Municipal de Alexânia
e conversando com
alguns servidores, p
ô
de
-
se observar algumas deficiências

no processo de
distribuição de
medicamentos, coord
e
nada pela Secretaria de Saúde.

A oportunidade de desenvolver um aplicativo

que melhore o processo de distribuição de
medicamentos,

e conseqüentemente po
s
sa estar aumentando a qualidade de vida da população
motivou ba
s
tante.


Além disso, através de uma avaliação no mercado, percebe
-
se que outras prefeituras
também possuem a mesma deficiência. Sendo assim, a chance de
las

serem atraídas

pelo
software seria alta.

Outro fator
decisivo
foi a tecnologia escolhida. Em todo o projeto será utilizado Ruby on
Rails, uma tecnologia nova que está se difundindo no mercado. Segundo uma pesquisa
internacional realizada pela Evans Data, que entrevistou

400 desenvolvedores, Ruby já é
utilizado por mais de 15% de programadores brasileiro e cerca de 33% tem intenção de adotá
-
la até 2008
. (MACHADO, 2007).

1.2

Empresa ou Organização Interessada

O município de Alexânia está situado em uma posição estratégia para
o desenvolvimento
econômico da região. A 60 km de Brasília e 120 km de Goiânia, Alexânia hoje tem uma
população com um pouco mais de 22.287 habitantes, de acordo com o IBGE (2005).


6

A Prefeitura Municipal,
que tem como atual prefeito Ronaldo Fernandes de Qu
eiroz e
vice
-
prefeito Cláudio, é o
principal empregador do município, possui
ndo

600 funcionários
efetivos, sendo 150 destinados a tr
a
balhar na área de saúde.

De acordo com a secretária de Saúde, Dra. Janaína, 20% da população procura ajuda da
Secretaria de

Saúde para adquirir os med
i
camentos receitados pelos médicos.

1.3

Estrutura

da Organização

Ocorreu uma Reforma Administrativa no dia 26 de Abril de 2005, com a aprovação da
Lei 784/2.005, deixando a estrutura administrativa da prefeitura
com as seguintes subd
ivisões
:



GABINETE DO PREFEITO
-

GABIN



SECRETARIA DA INDÚSTRIA E COMÉRCIO
-

SIC



SECRETARIA DE URBANISMO, HABITAÇÃO E OBRAS PÚBL
I
CAS
-
SEHOP



SECRETARIA DE GOVERNO E ADMINISTRAÇÃO
-

S
E
GOV



SECRETARIA DE SAÚDE
-

SEMS



SECRETARIA DA AÇÃO SOCIAL E CIDADANIA
-

S
E
ASC



SECRETARIA DE FINANÇAS E PLANEJAMENTO
-

SFP



SECRETARIA DE TRANSPORTES E SERVIÇOS PÚBLICOS
-

S
E
TRAN



SECRETARIA DA AGRICULTURA E ABASTECIMENTO
-

SEAGRI



SECRETARIA DA JUVENTUDE, ESPORTES E LAZER
-

SEJEL



SECRETARIA DE TURISMO, CULTURA E MEIO AMBIENTE
-

SEMACT



SECRETARIA DA EDUCAÇÃO
-

SEDUC



SUB
-
PREFEITURA DO DISTRITO DE OLHOS D’ÁGUA


SUB

O DMedicamentos irá afetar a Secretaria de Saúde e indiretamente a Secretaria da Ação
Social e Cidadania, que poderá usar o histórico de medic
a
mentos recebidos pelas pessoas pa
ra
algum tipo de análise.


7

1.4

Histórico do Sistema Existente

A Prefeitura de Alexânia utiliza sistemas de informática para automatizar os setores de
RH, Almoxarifado, Protocolo, Estoque, Compras, entre outros, porém a
tualmente não existe
nenhum sistema que ate
nda a Secretaria de Saúde na distribuição de medicamentos. Em uma
pesquisa de mercado, foram avaliados poucos softwares similares. A ma
i
oria dos sistemas são
para controle de medicamentos juntamente com o controle de caixa, estoque,
etc.
,
normalmente volta
do para atividades comerciais. Nenhum software
adequado
ao controle da
distribuição de medicamentos para uma prefeitura foi e
n
contrado.

1.5

Problemas Diagnosticados

Em reunião com a secretária de Saúde do município,
foram

apontadas

as

falhas e onde
um software

poderia ajudar a melhorar o processo. Foi acordado que toda a equipe da
Secretaria de Saúde estaria à disposição, para que fosse feita a análise de requisitos e testes do
sof
t
ware. Após a entrega do software e comprovada a sua eficiência, será feito uma p
roposta
para a possível venda do sistema.



Ineficiência no controle de estoque.

Não é feito nenhum tipo de controle de estoque,
acarretando uma série de problemas: excesso de medicamentos em um posto de distribuição e
escassez em outro; falta de uma previsã
o de co
m
pras; além de outros.



Ausência de histórico

de distribuição
.

Não há como obter um histórico dos
medicamentos adquiridos pela pessoa no momento em que ela está solicitando, já que
todo o

histórico é registrado em um livro praticamente impossível de
fazer uma pesquisa
em longo
prazo

insta
n
taneamente
.



Uso de má fé do cidadão.

É fácil uma pessoa solicitar o mesmo medic
a
mento em postos
de distribuição diferentes ao mesmo tempo. Há pessoas que os vendem; utilizam
posteriormente sem nenhum co
n
trole; receit
am amigos com estes medicamentos; etc.



Descontinuidade no tratamento.
As pessoas que recebem um medicame
n
to geralmente
não voltam na data certa para buscar mais medicamentos para dar continuidade ao tratamento;


8

1.6

Usuários do Sistema

Tabela
1



Usuário
#
1 do sistema

Usuár
io
#
1

Atendente

Descrição

Responsável por efetuar a distribuição do
medicamento no sistema

Interesses

Executar sua função do modo mais rápido,
obtendo um bom resultado

Envolvimento no projeto

Responsável por testar
o sistema

Representante

Roberta Monteiro


Tabela
2



Usuário
#
2 do sistema

Usuário
#
2

Administrador

Descrição

Responsável por definir onde será implementado
o sistema; acompanhar a devida utilização do
sistema; analisar relatóri
os

Interesses

Otimizar o processo de distribuição de
medicamentos, economizando recursos
destinados à Secretaria, dando condições de
trabalhar com outros projetos

Envolvimento no projeto

Ficou responsável por passar as informações e
documentação necessár
ia ao projeto.

Representante

Secretária de Saúde, Dra. Janaína


Tabela
3



Usuário
#
3 do sistema

Usuário
#
3

Prefeito

Descrição

Responsável por monitorar e avaliar a qualidade
do novo software/processo

Interesses

Otimizar o pro
cesso de distribuição de
medicamentos, economizando recursos do
município e uma boa impressão por parte

cidadãos pelo novo processo implementado

Envolvimento no projeto

Responsável por avaliar os custos do projeto e a
aprovação do mesmo

Representante

Pre
feito, Ronaldo Queiroz



9

2

OBJETIVOS

2.1

Objetivo Geral

Este projeto tem por objetivo o desenvolvimento de software para gerenciamento da
distribuição de medicamentos à c
o
munidade.

2.2

Objetivos Específicos

Entre os objetivos específicos desse projeto estão:



Control
ar o estoque.

Utilizar um controle de estoque simples armazenando somente a
quantidade de medicamento.



Manter histórico da distribuição.

Manter um histórico por pessoa de todos os
medicamentos solicitados.



Emitir

ticket.
Emissão de ticket para quem solicit
ou um medicamento, com a data de
retorno para solicitação de novos medicamentos para dar cont
i
nuidade ao tratamento.



Facilitar o contato com o cidadão.
Impressão de uma lista com o nome e telefone das
pessoas, filtrada por tratamento, que precisam retornar

para adquirir novos medicamentos para
dar continuidade ao tr
a
tamento.


10

3

PROPOSTA DO SISTEMA

3.1

Descrição do Processo Atual

Atualmente, a distribuição dos medicamentos é feita de forma totalmente manual. O
cidadão, de posse da receita médica, solicita o medica
mento em um dos postos de distribuição
espalhados no município. A atendente entrega o medicamento, e anota em um livro de
registros. É entregue a quantidade suficiente para duas semanas de consumo. Após esse
período, o cidadão retorna ao posto de distribui
ção e solicita novamente. O livro de registros
serve bas
i
camente para ter um controle dos medicamentos distribuídos, mas não serve para
um controle de estoque.

3.2

Descrição

do Sistema Proposto

Após a implementação do sistema, todo o processo de distribuição s
erá i
n
formatizado.

Quando o cidadão for a um posto de distribuição solicitar um medicamento, o atendente
irá preencher um cadastro dele, com suas informações pessoais. O atendente informará quais
os medicamentos desejados com base na receita emitida pelo m
édico. O sistema então
automaticamente efetuará a baixa no estoque emitindo um ticket com a data de retorno, se
houver. Dessa forma, o histórico do cidadão vai sendo criado, e no momento em que ele
retornar, será possível visu
a
lizá
-
lo.


11

3.3

Resultados Esperado
s

Após a implantação do sistema, espera
-
se que:



Eficiência no controle de estoque.

O sistema irá controlar o e
s
toque dos medicamentos,
podendo avaliar quando será necessário repor o estoque, entre outros.



Otimização no processo de distribuição
.

No momento
da e
n
trega será possível detectar
fraudes através do histórico da pessoa, uma vez que esse histórico será baseado em dados de
qualquer posto de distribuição, já que o sistema será onl
i
ne.



Diminuição do desperdício.

Uma vez que o processo de distribuição é
otimizado,
juntamente com um controle de estoque, a diminuição do desperdício irá ocorrer como
conseqüência.



Continuidade
nos tratamentos.
Através de um ticket emitido, ou de co
n
tato por parte da
Secretaria de Saúde, o cidadão será lembrado de que precisa
dar continu
i
dade ao tratamento.

3.4

Restrições do Sistema Proposto

Há duas solicitações
da Secretaria de Saúde
que serão implementadas em versões futuras
do sistema:



Registrar a foto do cidadão que está solicitando um medicame
n
to.



Ao efetuar o cadastramento da

pessoa, localizar em um sistema externo (Software do
Ministério da Saúde) através do número do Cartão do SUS todo o cadastro, e já mesclá
-
lo no
cadastro do DM
e
dicamentos.


12

3.5

Recursos Necessários para Execução

3.5.1

Recursos de Hardware

Tabela
4



Recursos de hardware

Especificação

Qtd

Valor Unitário

Total já
investido

Total a investir

Servidor:

Processador INTEL CORE 2
DUO E6750, memória de
2GB DDR2, HD de 250 GB
SATA2, monitor de 17’’,
teclado e mouse

1

R$ 2.450,00

R$ 2.450,00

-

Estação

de trabalho:

Processador INTEL
PENTIUM 4 3 GHZ,
memória de 1GB DDR2, HD
de 160 GB SATA, monitor de
17’’, teclado e mouse

6

R$ 1.400,00

-

R$ 8.400,00

No
-
break 1,5 Kva

1

R$ 569,00

R$ 569,00

-

Estabilizador 1 Kva

6

R$ 69,00

-

R$ 414,00

Switch

3

R$ 174,00

-

R$ 522,00

Cabo UTP categoria 5

60 m

R$ 2,00 o m.

-

R$ 120,00

Conector RJ
-
45

18

R$ 0,95

-

R$ 17,10

Caixa para conector

3

R$ 12,00

-

R$ 36,00

TOTAL GERAL

R$ 3.019,00

R$ 9.509,10

Fonte: CTIS


Brasília
-
DF. Em: 6/11/2007


13

3.5.2

Recursos de Software

Todo o pro
jeto será desenvolvido utilizando software
livre
:

Tabela
5



Recursos de software

Software

Valor

Linux

R$ 0,00

Eclipse for Rails Development

R$ 0,00

Apache

R$ 0,00

Ruby On Rails

R$ 0,00

MySQL

R$ 0,00

Jude

R$ 0,00

TOTAL GERAL

R$ 0,00

3.5.3

Recursos Humanos

Tabela
6



Recursos humanos

Especialista

Prazo

Salário hora

Custo Total

Analista de suporte técnico

40 horas

R$ 20,21

R$ 808,40

Administrador de banco de dados

80 horas

R$ 18,94

R$ 1.515,20

Analista pr
ogramador

40
0 horas

R$ 21,45

R$
8
.
580
,00

Total sem encargos

R$
10
.
903,6
0

Encargos sociais, fiscais e trabalhistas (K = 1,0)

R$
10
.
903,6
0

Total com encargos sociais, fiscais e trabalhistas

R$
21
.
807,2
0

Fontes: InfoOnline (ht
9
tp://info.abril.com.br/carre
ira/salarios.shl em 6/11/2007)

K =

Coeficiente de Obrigações Sociais, Fiscais e Trabalhistas: (INSS patronal, FGTS,
PIS, Provisão para 13 o salário, Provisão para férias e Provisão para rescisão)


14

3.5.4

Resumo dos Recursos

Tabela
7



Res
umo dos recursos

Recursos

Total já
investido

Total a investir

TOTAL

Hardware

R$ 3.019,00

R$ 9.509,10

R$ 12.528,10

Software

-

-

-

Humanos

-

R$
21
.
807,2
0

R$
21
.
807,2
0

TOTAL GERAL

R$ 3.019,00

R$
31
.3
16
,30

R$
34
.
335,3
0

3.6

Relação Custo x Benefício

De acordo
com estudos da Secretaria de Saúde, atualmente
são

desperdiçado
s

R$
15.000,00 todo mês com medicamento. Com a implantação do projeto e a conseqüente
redução do desperdício, estima
-
se que em
três

meses já h
a
veria retorno do valor investido.

3.7

Áreas Afetadas p
elo Sistema

Basicamente, as unidades de distribuição deverão ser afetadas pelo DMedicamentos. A
implantação será gradual. Primeiro será i
m
plantado em somente um posto de distribuição e
sem controle de estoque. Então será analisado o impacto e como o sistem
a e o processo de
distribuição se comportam. Após a co
n
clusão da implantação em uma unidade e tudo estando
ocorrendo bem (sistema e processo), será implantado nos outros postos de distribuição
definidos pelo cliente o software juntamente com o controle de
estoque.

Os funcionários que utilizarão o sistema receberão treinamento após a implantação e
,

durante um curto período
,

toda a utilização do sistema será monitor
a
da.


15

4

PLANEJAMENTO DO PROJ
ETO

4.1

Plano do Processo de Desenvolvimento

4.1.1

Ciclo de Vida do Projeto

Como

o DMedicamentos é um projeto acadêmico dividido em duas fases (projeto e
software), o modelo de ciclo de vida que melhor se adapta é o mod
e
lo em cascata.

O modelo de ciclo de vida de cascata foi o primeiro modelo a ser conhecido em
engenharia de software
e está na base de muitos ciclos de vida utilizados hoje em dia.
Até
meados da década de 1980 foi o único modelo com aceitação geral.

Este consiste basicamente num modelo linear em que cada passo deve ser completado
antes que o próximo passo possa ser inici
ado. Por exemplo, a anál
i
se de requisitos deve ser
completada antes que o desenho do sistema possa ser iniciado. Os nomes dados a cada passo
variam, assim como varia a definição exata de cada um deles, mas basicamente o ciclo de vida
começa com a análise d
e requisitos movendo
-
se de seguida para a fase de desenho,
codificação, impleme
n
tação, teste e finalmente manutenção do sistema.


16


Ilustração
1



Modelo cascata

De acordo com Pressman

(1995)
,
pode haver alguns problemas:

1.

Os pro
jetos reais raramente seguem o fluxo
seqüencial

que o modelo propõe. Alguma
iteração sempre ocorre e traz
probl
e
mas

na
aplicação

do paradigma.

2.

Muitas vezes é difícil para o cliente declarar todas as exigências explicitamente. O
ciclo de vida clássico exige

isso e tem dificuldade de acomodar a incerteza natural que
existe no começo
de muitos

projetos.

3.

O cliente deve ter paciência. Uma versão de trabalho do programa não estará
disponível até um ponto tardio do cronograma do projeto. Um erro
nesse ponto
, se nã
o
for detectado até que o programa de trabalho seja r
e
visto, pode ser desastroso.


17

Foram observadas as seguintes atividades:

Tabela
8



Atividades do ciclo de vida do projeto



Atividades

01

Estudo da viabilidade

02

Levantament
o e Especificação de Requisitos

03

Avaliação dos Riscos (identificação dos requisitos críticos)

04

Prototipação de telas do sistema

05

Elaboração do Diagrama de Classes

06

Elaboração do Diagrama de Casos de Uso

07

Especificação dos Casos de Uso

08

Di
agrama de Realização dos Casos de Uso

09

Diagrama de
Seqüências

10

Diagrama

de Atividades

11

Modelo de Entidade e Relacionamento

12

Modelo Físico do Sistema

13

Codificação

14

Teste do Software

15

Entrega do produto

4.1.2

Documentos do Projeto

Ao longo do

projeto, serão

gerados
os seguintes
documentos:

Tabela
9



Documentos gerados

N.º

Ciclo

Documento Gerado

1

Proposta de Projeto

Proposta de Trabalho

2

Planejamento do Projeto

Análise de Risco

3

Levantamento de Requisitos

Especi
ficação de requisitos

4

Análise

Diagrama de Classes, Diagrama de Casos de Uso,
Descrição dos Casos de Uso (especificação,
diagrama de realização, diagrama de seqüência,
diagrama de atividades), Modelo de Entidade e
Relacionamento, Modelo Físico do Sistem
a,
Protótipo das telas

5

Codificação

Código fonte documentado, Arquivos executáveis



18

4.2

Plano de Acompanhamento

4.2.1

Marcos e Pontos de Controle

M
arcos geralmente
são

pontos do projeto em que algo significativo é alcançado ou
concluído. De acordo com Heldman

(20
06)
, os clientes ou pessoal de gerência podem ex
i
gir
que certas entregas sejam feitas dentro de prazos definidos. Se isso for acordado, elas
geralmente ficam sacramentadas e muito
difíceis

de alterar, convertendo
-
se, portanto, em
restrições.

Tabela
10



Marcos e pontos de controle

N.º

Resultado a ser produzido

Data prevista

1

Proposta de Projeto

25/08/2007

2

Planejamento do Projeto

08/09/2007

3

Levantamento de Requisitos

15/09/2007

4

Análise

08/12/2007

5

Codificação

01/03/2007

6

Testes

10/03/2007

7

Implantação

20/03/2007


4.2.2

Métodos de Acompanhamento e Controle

Assim que a programação é estabelecida, inicia
-
se a atividade de monitoração e controle.
Cada tarefa anotada no programa será rastreada
, juntamente com a verificação de
cada marco
.
Se a tarefa não acompanhar a programação, deverá determinar o impacto do não
-
cumprimento
dos prazos sobre os marcos de referência intermediários do projeto e a data de entrega global.


19

4.2.3

Análise e Gerência de Riscos

“O futuro é nossa preocupação


quais riscos poderiam fazer com que o projeto de
software saísse torto? A mudança é nossa preocupação


como as mudanças nos
requisitos do cliente, nas tecnologias de desenvolvimento, nos computadores de
destino e em todas as demais entidades ligadas ao
projeto afetarão o sucesso global e
o cumprimento do cronograma? Por fim, devemos nos envolver com as escolhas


quais métodos e ferramentas devemos usar, quantas pessoas devem ser envolvidas,
quanta ênfase sobre a qualidade é suficiente.”

(PRESSMAN, 1995,

p. 131)

O DMedicamentos possui os seguintes riscos:


Tabela
11



Risco
#
1

Risco
#
1

Possível atraso no p
razo de entrega

Categoria do Risco

Média

Descrição

O prazo de entrega do software é definido em acordo com o cliente

Impacto
s

Cliente pode querer não cumprir com parte do pagamento; Reputação
da empresa fica distorcida; Aumento do custo do projeto

Indicadores

Com base no cronograma é possível avaliar se será possível cumprir
com o prazo de entrega ou não

Estratégia de Diminui
ção

Cumprimento fiel do cronograma

Plano de Contingência

Aumento da carga de trabalho


Tabela
12



Risco
#
2

Risco
#
2

Falha na especificação dos requisitos

Categoria do Risco

Alta

Descrição

A especificação dos requisitos é funda
mental para um bem
-
sucedido
desenvolvimento de software

Impactos

Aumento do custo do projeto; Não cumprimento do prazo de entrega

Indicadores

Durante a codificação, ao apresentar o andamento do projeto ao usuário
final

Estratégia de Diminuição

Elaboraçã
o de protótipos de tela; Validação junto ao cliente de todos os
requisitos definidos

Plano de Contingência

Revisão do escopo e do cronograma de atividades



20

Tabela
13



Risco
#
3

Risco
#
3

Pouco conhecimento da tecnologia Ruby On R
ails

Categoria do Risco

Alta

Descrição

Ruby On Rails é uma tecnologia nova no mercado, e poucos ainda há
poucos profissionais
capacitados

Impactos

Não cumprimento do prazo de entrega

Indicadores

Dificuldade e atraso na fase de codificação

Estratégia d
e Diminuição

Contratação de pessoal qualificado; Oferecer cursos aos profissionais

Plano de Contingência

Contratação de consultoria; Reforço da equipe


Tabela
14



Risco
#
4

Risco
#
4

Desinteresse por parte do cliente

Categoria do

Risco

Baixa

Descrição

É possível que o cliente desista da compra do sistema

Impactos

Prejuízo para o projeto

Indicadores

Sentimento de distância por parte do cliente

Estratégia de Diminuição

Deixar bem claro para o cliente a relação custo/benefício do

software

Plano de Contingência

Procura por novos clientes


21

4.3

Cronograma



Ilustração
2

-

Cronograma


A Codificação, Testes e Implantação serão
contemplados

na s
e
gunda fase do projeto.


22

5

EMBASAMENTO TEÓRICO,

METODOLOGIA E
TECNOLO
GIA ADOTADA

5.1

Embasamento Teórico

5.1.1

Orientação a objetos

Um objeto é uma entidade do mundo real que tem uma identidade. Objetos podem
representar entidades concretas (um arquivo no meu computador, uma bicicleta) ou entidades
conceituais (uma estratégia de jogo
, uma política de escalonamento em um sistema
operacional). Cada objeto ter sua identidade significa que dois objetos são distintos mesmo
que eles apresentem exatamente as mesmas
caracter
í
sticas
.

Embora objetos tenham existência própria no mundo real, em t
ermos de linguagem de
programação um objeto necessita
de
um mecanismo de identificação. Esta identificação de
objeto deve ser única, uniforme e independente do conteúdo do objeto. Este é um dos
mecanismos que permite a criação de col
e
ções de objetos, as qu
ais são também objetos em si.

A estrutura de um objeto é representada em termos de atributos. O comportamento de um
objeto é representado pelo conjunto de operações que podem ser executadas sobre o objeto.
Objetos com a mesma estrutura e o mesmo comportame
nto são agrupados em classes. Uma
classe é uma abstração que descreve propriedades importantes para uma aplicação e
simplesmente ignora o resto.

Cada classe descreve um conjunto (possivelmente infinito) de objetos individuais. Cada
objeto é dito ser uma in
stância de uma classe. Assim, cada instância de uma classe tem seus

23

próprios valores para cada atributo, mas dividem os nomes dos atributos e métodos com as
outras instâncias da classe. Implicitamente, cada objeto contém uma referência para sua
própria cla
sse


em outras palavras, ele sabe o que ele é.

Polimorfismo significa que a mesma operação pode se comportar de forma diferente em
classes diferentes. Por exemplo, a operação move quando aplicada a uma janela de um
sistema de interfaces tem um comportamen
to distinto do que quando aplicada a uma peça de
um jogo de xadrez. Um método é uma implementação específica de uma operação para
certa

cla
s
se.

Polimorfismo também implica que uma operação de uma mesma classe pode ser
implementada por mais de um método. O
usuário não precisa saber quantas implementações
existem para uma operação, ou explicitar qual método deve ser utilizado: a linguagem de
programação deve ser capaz de selecionar o método correto a partir do nome da operação,
classe do objeto e argumentos p
ara a operação. Desta forma, novas classes podem ser
adicionadas sem necessidade de modificação de código já existente, pois cada classe apenas
define os seus m
é
todos e atributos.

No mundo real, alguns objetos e classes podem ser descritos como casos espec
iais, ou
especializações, de outros objetos e classes. Por exemplo, a classe de computadores pessoais
com processador da linha 80x86 é uma especializ
a
ção de computadores pessoais, que por sua
vez é uma especialização de computadores. Não é desejável que tu
do que já foi descrito para
computadores tenha de ser repetido para computadores pessoais ou para computadores
pessoais com process
a
dor da linha 80x86.

Herança é o mecanismo do paradigma de orientação a objetos que permite compartilhar
atributos e operaçõe
s entre classes baseada em um relacionamento hierárquico. Uma classe
pode ser definida de forma genérica e depois refinada sucessivamente em termos de
subclasses ou classes deri
vadas. Cada subclasse incorpora

ou herda

todas as propriedades de
sua superclas
se (ou classe base) e adiciona suas propriedades únicas e particulares. As
propriedades da classe base não precisam ser repetidas em cada classe derivada. Esta
capacidade de fatorar as propriedades comuns de diversas classes em uma superclasse pode
reduzir

drasticamente

a repetição de código em um projeto ou programa, sendo uma das
principais vantagens da
a
bordagem de orientação a objetos.


24

5.1.2

Modelagem relacional


Modelo

relacional para gerência de bancos de dados (SGBD) é um modelo de dados
baseado em lógica
de predicados e na teoria de conjuntos.

Historicamente ele é o sucessor do modelo hierárquico e do modelo em rede. Estas
arquiteturas antigas são até hoje utilizadas em alguns
data centers

com alto volume de dados,
onde a migração é inviabilizada pelo cust
o que ela demandaria; existem ainda os novos
modelos baseados em orientação ao objeto, que na maior parte das vezes são encontrados
como kits de construção de SGBD, ao invés de um SGBD propriamente dito.

O modelo relacional foi o primeiro modelo de banco d
e dados formal. Somente depois
seus antecessores, os bancos de dados hierárquicos e em rede, passaram a ser também
descritos em linguagem formal.

O modelo relacional foi inventado pelo Dr. Ted Codd e
subseqüentemente

mantido e
aprimorado por Chris Date e H
ugh Darwen como um modelo geral de dados. No Terceiro
Manifesto (1995) eles mostraram como o modelo relacional pode ser estendido com
características de orientação a objeto sem co
m
prometer os seus princípios fundamentais.

A linguagem padrão para os bancos
de dados relacionais, SQL, do inglês
S
tructured
Q
uery
L
anguage
, é apenas vagamente remanescente do modelo matemático. Atualmente ela é
adotada, apesar de suas restrições, porque ela é antiga e muito mais popular que qualquer
outra li
n
guagem de banco de dad
os.

A principal proposição do modelo relacional é que todos os dados são representados
como relações matemáticas, isto é, um subco
n
junto do produto Cartesiano de n conjuntos. No
modelo matemático (diferentemente do SQL), a análise dos dados é feita em uma
lógica de
predicados de dois valores (ou seja, sem o valor nulo); isto significa que existem dois
possíveis valores para uma proposição: verdadeira ou falsa. Os dados são tratados pelo cálculo
r
e
lacional ou álgebra relacional.

O modelo relacional permite a
o projetista criar um modelo lógico consistente da
informação a ser armazenada. Este modelo lógico pode ser refinado através de um processo de
norm
a
lização. Um banco de dados construído puramente baseado no modelo relacional estará
inteiramente normalizado
. O plano de acesso, outras implementações e detalhes de operação

25

são tratados pelo sistema
SGDB
, e não devem ser refletidos no modelo lógico. Isto se
contrapõe à prática comum para
SGDB
s SQL nos quais o ajuste de desempenho
freqüentemente

requer mudanças
no modelo lógico.

Os blocos básicos do modelo relacional são o domínio, ou tipo de dado. Uma tupla é um
conjunto de atributos que são ordenados em pares de domínio e valor. Uma relvar (variável
relacional) é um conjunto de pares ordenados de domínio e nome

que serve como um
cabeçalho para uma relação. Uma relação é um conjunto desordenado de tuplas. Apesar destes
co
n
ceitos matemáticos, eles correspondem basicamente aos conceitos tradicionais dos bancos
de dados. Uma relação é similar ao conceito de tabela e

uma tupla é similar ao conceito de
linha.

O princípio básico do modelo relacional é o princípio da informação: toda informação é
representada por valores em relações. A
s
sim, as relvars não são relacionadas umas às outras
no momento do projeto. Entretanto,

os projetistas utilizam o mesmo domínio em vários
relvars, e se um atributo é dependente de outro, esta dependência é garantida através da
integridade referencial.

5.1.3

Ajax

A
World Wide Web
, com
parado com aplicativos desktop, eram lent
a
s e inflexíveis. De
qua
lquer forma, pessoas gostavam de aplicativos web porque eles eram convenientemente
disponíveis de qualquer lugar em qualquer computador que tenha um navegador. Então a
Microsoft criou o XMLHttpRequest no Internet Explorer 5, que permitiu Javascript do lado

do n
a
vegador comunicar com o servidor web em
background
, sem requerer que o navegador
mostre uma nova página web. Isto fez possível
desenvolver

aplicações web mais responsáveis.

Mozilla também implementou XMLHttpRequest em seus nav
e
gadores, assim como a A
pple
(no navegador Safari) e Opera.

XMLHttpRequest tem sido um dos melhores segredos
escondidos
da Web. Desde que foi
criado em 1998, poucos sites tinham usado todo o seu p
o
tencial, e muitos desenvolvedores
nunca o usavam. O Google iniciou a muda
n
ça quando

lançou uma série de aplicações web
com novas interfaces utilizando XMLHttpRequest. O mais impressionante deles é o Google

26

Maps, o qual possibilita ao usuário a ilusão de ser possível navegar por um infinito mapa em
uma pequena janela.

Enquanto o Google us
ou o XMLHttpRequest demonstrando que uma alta melhora na
interface para aplicações web é possível, foi Jesse James Garreett, em 18 de fevereiro, que
finalmente deu a essa técnica um novo nome usável: Ajax (Asynchronous JavaScript and
XML). Esse foi o ponto
. Sem conhecer a tecnologia, a indústria de software estava esperando
por algo, e o novo nome Ajax veio como uma alavanca. A adoção da nova tecnologia foi
muito rápida e teve uma adaptação universal.

5.1.3.1

Aplicações Web Tradicionais x Aplicações Ajax

A essência

de uma aplicação Ajax ser
á examinada pelo caso de uso: inserindo um novo
item em uma lista.

Uma típica interface do usuário exibe a lista atual em uma página web seguido de um
campo de pesquisa na qual o usuário pode digitar o texto de um novo item. Quand
o o usuário
clicar no botão “Criar Novo Item”, o aplicativo realmente cria e insere o novo item na lista.

Neste ponto, uma aplicação web tradicional envia o valor do campo para o servidor. O
servidor então age sobre os dados (normalmente atualizando uma ba
se de dados) e responde
enviando de volta uma nova página web que exibe uma lista atualizada, que contém agora o
novo item. Dessa forma é
utilizada

uma grande quantidade de banda, porque a maior parte da
nova página é exatamente a mesmo que a antiga. O des
empenho deste aplicativo web
piora a
medida que a lista começa a ficar comprida.

Em contraste, uma aplicação web Ajax envia o campo de pesquisa para o servidor
em
background e atualiza somente a parte
afetad
a

da
atual página

localmente
. Isso aumenta
drasti
camente a capacidade de resposta do usuário e faz sentir muito mais como um
a

apl
i
cação

desktop
.

Ajax é t
udo

sobre usabilidade
,
mas como qualquer técnica ou tecnologia,
é possível usá
-
la

bem ou mal.


27

5.1.3.2

Como usar Ajax em uma aplicação web

A forma difícil para u
sar Ajax em seu aplicativo web é escrever seu próprio JavaScript
que diretamente usa os objetos XMLHttpRequest da API. Ao fazer isso, você tem de lidar
com as particularid
a
des de cada navegador.

Uma maneira mais simples é usar uma das várias bibliotecas Ja
vaScript que fornecem
serviços de qualidade e escondem as diferenças entre os navegadores. Bibliotecas como o
DWR, Prototype, S
a
jax, e Ajax.NET são todos uma boa escolha.

5.2

Metodologia


“P
esquisa qualitativa é basicamente aquela que busca entender um fenômen
o
específico em profundidade. Ao invés de estatísticas, regras e outras generalizações,
a qualitativa trab
a
lha com descrições, comparações e interpretações.

A pesquisa qualitativa é mais participativa e, portanto, menos controlável. Os
participantes da pes
quisa podem direcionar o rumo da pesquisa em suas interações
com o pesquisador
”.

(OLIVEIRA, 2007)

Na pesquisa qualitativa o pesquisador procura reduzir a distância entre a teoria e os
dados, entre o contexto e a ação, usando a lógica da compreensão dos fen
ômenos pela sua
descrição e interpretação. As experiências pessoais do pesquisador são elementos importantes
na análise e compreensão dos fenômenos estudados. A pesquisa qualitativa tem as seguintes
c
a
racterísticas:



O pesquisador observa os fatos sob a óp
tica de alguém interno à organização.



A pesquisa busca uma profunda compreensão do contexto da situação.



A pesquisa enfat
i
za o processo dos acontecimentos, isto é, a seqüência dos fatos ao longo
do tempo.



O enfoque da pesquisa é mais desestruturado, não há

hipóteses fortes no início da
pesquisa. Isso confere à pesquisa bastante flexibilidade.



A pesquisa geralmente emprega mais de uma fonte de dados.

Para o levantamento dos dados na Prefeitura Municipal de Alexânia, foram utilizadas
pesquisas qualitativas,
com o objetivo de entender o funcionamento do processo de
distribui
ção de medicamentos.


28

No inicio do projeto, foi feito uma pesquisa com a secretária de Saúde, Dra. Jana
í
na, para
buscar uma compreensão inicial do sistema, e extrair alguns requisitos primár
ios.
Posteriormente, o Sr. Ronaldo Queiroz, prefeito de Alex
â
nia, foi entrevistado, juntamente
com outros três funcionários.

5.3

Tecnologia Adotada

As principais tecnologias adotadas para a execução do projeto são Ruby On Rails para a
parte de desenvolv
imento,

e o banco de dados MySQL
.

5.3.1

Ruby On Rails

Ruby on Rails é um framework web criado pela empresa 37signals escrito na linguagem
Ruby e teve sua primeira versão no início de 2004, meses depois o site 43things feito em
Rails

suportava alguns milhões de page
-
vie
ws por dia. Hoje o Rails está na versão 1.2 e já conta
com milhares de sistemas desenvolvidos entre eles o Twitter,

uma aplicação em Rails que
suporta mais de 10 mil requisições por segundo.


Neste momento a Sun finaliza o suporte completo ao Ruby e ao
Ruby on Rails na
JVM
. A

Microsoft caminha na mesma direção e já su
rgem diversos frameworks Java,
Net e
PHP seguindo a idéia do Rails, porém implementar um framework semelhante o Rails sem
uma linguagem dinâmica fica bastante difícil, por exemplo, o Active
Record, os mecanismos
de persistência do Rails, em Java talvez a forma mais simples seja escrevendo um clas
s
loader.


Antes de conhecer melhor Ruby on Rails ou simplesmente Rails ou ROR, é importante
deixar claro que a filosofia do Rails b
a
seia
-
se no pri
ncípio de Paretto conhecido como 80/20,
ou seja, 80% dos problemas demandam 20% do tempo para serem resolvidos.


Diferente de várias plataformas Java que tentam ser solução para todos os problemas,
o Rails se propõe a resolver da melhor forma possível
os 80%. Na tentativa de abraçar tanto
desenvolvimento web quanto de componentes distr
i
buídos, o J2EE acaba não resolvendo nem
uma coisa nem outra. O Rails se propõe a resolver bem os problemas do desenvolvimento
web, partindo do princípio de que a maioria
dos projetos não tem a necessidade de tecnologias
como EJB.


29

5.3.1.1

Composição do Rails

Os Rails é composto por diversos componentes que podem ser agrupados da seguinte
forma:



Frameworks criados para ser parte do Rails



Módulos da linguagem Ruby



Módulos mistos que
fazem parte do Ruby, mas são melhorados no Rails.



Conjuntos de scripts que agilizam o desenvolvimento

A seguir são apresentados os principais componentes do Rails:

ActiveRecord



Implementação do design pattern de mesmo nome, é a parte responsável
pelo m
odel e pela persistência. Boa parte da produtividade do Rails se deve ao ActiveRecord

ActionPack (View + Controller)



Junto com o ActiveRecord o ActionPack completa a
implementação do MVC. O ActionPack é composto pelo A
c
tiveView e pelo ActiveController
q
ue como os próprios nomes indicam são re
s
ponsáveis pelas camadas de visão e controle.

ActionMailer



É raro um aplicativo web que não faça uso de envio de e
-
mail. Este
pacote permite a aplicação enviar, receber e
-
mails além de vim preparado com testes para

essas
a
ções.

ActonWebService



Componente responsável por facilitar a criação de webservices.

ActionSupport



Pacotes responsável po
r

gerenciar logs, plugins, dependências, cachê e
outras funcionalidades que não são o f
o
co do frameworks, mas dão suporte p
ar as demais.

Testes



O Rails já vem preparado para fazer testes funcionais e testes unitários. Os teste
s

unitários fazem uso de uma biblioteca
do

Ruby e os testes funcionais fazem parte do
ActiveController.

Scripts



O Rails por possui uma série de scrip
ts que agilizam o desenvolvimento, eles
permitem criar um aplicação, criar classes de domínio, criar controladores, criar um cruds sem
precisar escrever código entre outras possibilid
a
des.

WEBRick



Servidor WEB utilizado principalmente em ambiente de d
e
se
nvolvimento.


30

Rake



Equivalente ao Make em C ou a um ANT em Java. Faz parte da linguagem Ruby.


31

5.3.1.2

The Rails Cycle


Ilustração
3

-

O ciclo do Ruby on Rails
.

Fonte: http://wiki.rubyonrails.com/rails/pages/UnderstandingRailsMVC

5.3.2

My
SQL

O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a
linguagem SQL (Structured Query Language
-

Linguagem de Consulta Estruturada) como
interface. É atualmente um dos bancos de dados mais populares, com mais de 10 milhões de
in
st
a
lações pelo mundo.

Entre os usuários do banco de dados MySQL estão: NASA, Friendster, Banco Bradesco,
Dataprev HP, Nokia, Sony, Lufthansa, U.S Army, US.
Federal Reserve Bank, Associated
Press, A
l
catel, Slashdot, Cisco Systems e outros
.


32

5.3.2.1

Características



P
ortabilidade (suporta praticamente qualquer plataforma atual)



Compatibilidade (existem drivers ODBC, JDBC e .NET e módulos de interface para
diversas linguagens de programação, como Delphi, Java, C/C++, Python, Perl, PHP e Ruby)



Excelente desempenho e esta
bilidade;



Pouco exigente quanto a recursos de hardware;



Facilidade de uso;



É um Software Livre;



Suporte a vários tipos de tabelas (como MyISAM e InnoDB), cada um e
s
pecífico para um
fim;



Faltam alguns recursos quando comparados como outros banco de dados, c
omo o
PostgreSQL.


33

6

ESPECIFICAÇÃO DOS RE
QUISITOS DO SISTEMA

6.1

Problemas e Oportunidades

6.1.1

Problemas

Tabela
15



Problema
#
1

Problema
#
1

Ausência de histórico

O que afeta

Secretaria de Saúde

Qual é o impacto

Não é possível acompanhar a
freqüência

com que a pessoa utiliza de
recursos da prefeitura

A Solução

Manter em banco de dados o histórico por pessoa


Tabela
16



Problema
#
2

Problema
#
2

Uso de má fé do cidadão

O que afeta

Secretaria de Saúde

Qual é o impac
to

Desperdício de medicamentos

A Solução

Integrar o sistema em uma única base de dados


Tabela
17



Problema
#
3

Problema
#
3

Controle de estoque ineficiente

O que afeta

Secretaria de Saúde

Qual é o impacto

Desperdício

de medicam
entos

A Solução

Implantar um controle de estoque ao sistema



34

Tabela
18



Problema
#
4

Problema
#
4

Descontinuidade no tratamento

O que afeta

Secretaria de Saúde e o próprio cidadão

Qual é o impacto

Com isso ocasiona um maior ret
orno do cidadão aos hospitais
municipais, já que ele não conclui
u

o tratamento, ocasionando em um
novo tratamento e
conseqüentemente

mais desperdício

A Solução

Emitir um ticket para lembrar o cidadão e um possível contato


6.1.2

Oportunidades

Tabela
19



Oportunidade
#
1

Oportunidade
#
1

Gerenciamento de usuários

Qual é o impacto

Gerenciar os usuários do sistema implica em uma maior segurança com
as informações.

A Solução

Implantar um controle de login


6.2

Requisitos do Software

Tabela
20



Requisito
#
1

Requisito
#
1

Manter pessoas

Descrição

Manter um cadastro de pessoas, com opções para pesquisar, adicionar,
alterar e excluir.

Problema ou
oportunidade que gerou

P1, P2 e P4


Tabela
21



R
equisito
#
2

Requisito
#
2

Manter medicamentos

Descrição

Manter um cadastro de medicamentos, com opções para pesquisar,
adicionar, alterar e excluir.

Problema ou
oportunidade que gerou

P1, P2, P3 e P4



35

Tabela
22



Requisito
#
3

Re
quisito
#
3

Manter médicos

Descrição

Manter um cadastro de médicos, com opções para pesquisar, adicionar,
alterar e excluir.

Problema ou
oportunidade que gerou

P1


Tabela
23