CURSO DE SISTEMAS DE INFORMAC
¸ ˜
AO
Rodrigo Pim Silva
Software para extrapola¸
c˜
ao alom´
etrica na
posologia e c´
alculo de exigˆ
encias
energ´
eticas para animais selvagens usando
a tecnologia m´
ovel Java Micro Edition
(CLDC 1.1/MIDP 2.0/Floggy 1.3)
VILA VELHA - ES 2009
Software para extrapola¸
c˜
ao alom´
etrica na
posologia e c´
alculo de exigˆ
encias
energ´
eticas para animais selvagens usando
a tecnologia m´
ovel Java Micro Edition
(CLDC 1.1/MIDP 2.0/Floggy 1.3)
Trabalho de conclus˜ao de curso apresentado ao Centro Universit´ario Vila Velha como re-quisito parcial para obten¸c˜ao do grau de Ba-charel em Sistemas de Informa¸c˜ao.
Orientador:
Prof. Msc. Cristiano Biancardi
VILA VELHA - ES 2009
Software para extrapola¸
c˜
ao alom´
etrica na
posologia e c´
alculo de exigˆ
encias
energ´
eticas para animais selvagens usando
a tecnologia m´
ovel Java Micro Edition
(CLDC 1.1/MIDP 2.0/Floggy 1.3)
BANCA EXAMINADORA
Prof. Msc. Cristiano Biancardi Centro Universit´ario Vila Velha
Orientador
Prof. Msc. Sandro Tonini da Silva Centro Universit´ario Vila Velha
Prof. Msc. Susileia Abreu Centro Universit´ario Vila Velha
Trabalho de conclus˜
ao de curso
aprovado em 2009.
renovando minhas for¸
cas a cada manh˜
a e concedendo o discernimento
necess´
ario, para que esta minha etapa da vida pudesse ser conquistada.
Aos meus pais pelo esfor¸
co, dedica¸
c˜
ao e compreens˜
ao, em todos os
momentos vividos nestes quatro anos que se passaram - amo vocˆ
es. A
minha amada e querida esposa, por sua compreens˜
ao e at´
e mesmo, alguns
momentos de incompreens˜
ao; aos meus filhos, que mesmo sendo
pequeninos, visualizaram a jornada do pai demonstrando orgulho e
aprecia¸
c˜
ao. Por fim, a todos os meus amigos, pelo incentivo, coopera¸
c˜
ao e
apoio nesta etapa, em que, com a gra¸
ca de Deus, est´
a sendo vencida.
Agrade¸co a Deus, pois sempre me guiou e guardou meus passos para que continuasse andando, mesmo que `as vezes trope¸cando, mas sempre reconhecendo, e com Sua for¸ca, se reerguendo. `A minha amada m˜ae (Maria Auxiliadora Pim Silva) pelo carinho, amor, ternura, dedica¸c˜ao e compreens˜ao. Ao meu amado pai (Joel Souza Silva) por todos os ensinamentos, pelo exemplo de homem justo, pela prote¸c˜ao e apoio em todos os momen-tos de minha vida. Ao meu cuidadoso, espontˆaneo, e literalmente grande irm˜ao, pelos momentos de apoio, ajuda e incentivo. A minha irm˜a, a ca¸cula da fam´ılia, pelo tempo gasto com assuntos que eu deveria ter corrido atr´as. Obrigado pelo apoio. A minha es-posa e filhos, por terem suportado estes quatro anos, estando sempre presentes em minha vida e acompanhando meu progresso. Ao meu professor e orientador Cristiano Biancardi pela ajuda e dedica¸c˜ao para que este trabalho fosse conclu´ıdo com sucesso e a todos os professores da UVV que participaram da minha forma¸c˜ao acadˆemica. A todos os meus amigos, pelos direcionamentos, conselhos e pelos momentos de descontra¸c˜ao que aliviaram o estresse. A todos os colegas de trabalho, com os quais, tive o privil´egio de compartilhar id´eias e discutir assuntos que agregaram novos conhecimentos atrav´es do racioc´ınio l´ogico e fus˜ao de id´eias. Incluo aqui os colegas de turma, onde tantos iniciaram, e t˜ao poucos chegaram e esta etapa final. Chego ao final destes quatro anos um homem mudado, cada vez menos “sonolento”, feito de coisas diferentes de quando comecei. E sinto que melho-rei. Conhecimento e cren¸ca chegaram a um n´ıvel maior de maturidade, e tudo devo aos presentes neste agradecimento, sendo o maior deles, Deus. Obrigado a todos!
que em v˜ao, que sentar-se fazendo nada at´e o final. Eu prefiro na chuva caminhar, que em dias tristes em casa me esconder. Prefiro ser feliz, embora louco, que em conformidade viver ...”
Lista de Figuras Lista de Tabelas Resumo 1 Introdu¸c˜ao p. 15 1.1 Motiva¸c˜ao . . . p. 16 1.2 Justificativa . . . p. 17 1.3 Objetivo . . . p. 18
1.4 Descri¸c˜ao dos Cap´ıtulos . . . p. 18
2 Referencial Te´orico p. 20
2.1 O Paradigma Orientado a Objetos - OO . . . p. 20 2.2 An´alise Orientada a Objetos - OOA . . . p. 21
2.3 Projeto Orientado a Objetos - OOD . . . p. 21
2.4 Linguagem de Modelagem Unificada - UML . . . p. 23
2.5 Padr˜oes de Projeto . . . p. 25
2.5.1 Padr˜ao MVC . . . p. 26
2.6 O estudo da alometria visando a extrapola¸c˜ao de f´armacos . . . p. 27
2.7 A Plataforma de Desenvolvimento Java . . . p. 31
2.7.1 Breve Hist´orico . . . p. 32
2.7.4 M´aquina Virtual Java . . . p. 33
2.8 Java para dispositivos m´oveis - JME . . . p. 34
2.8.1 Configura¸c˜ao e perfil . . . p. 35
2.8.1.1 Configura¸c˜oes . . . p. 35
2.8.1.2 Perfis . . . p. 36
2.8.2 Persistindo dados localmente - API RMS . . . p. 36
2.8.2.1 Floggy - Framework de persistˆencia . . . p. 37
2.8.3 Acesso `a rede . . . p. 39 2.8.3.1 Servi¸cos remotos . . . p. 39
3 Levantamento de Requisitos p. 40
3.1 Requisitos Funcionais do Software . . . p. 40
3.2 Casos de Uso . . . p. 41
3.2.1 Descri¸c˜ao do Ator . . . p. 42 3.2.2 Descri¸c˜ao dos Casos de Uso . . . p. 43
3.3 Requisitos N˜ao-Funcionais . . . p. 48
4 Especifica¸c˜ao de An´alise p. 50
4.1 Diagrama de Classes . . . p. 50
4.2 Dicion´ario de Dados . . . p. 51 4.3 Modelagem de Intera¸c˜oes . . . p. 53
4.4 Transi¸c˜ao de Estados . . . p. 57
5 Propostas Tecnol´ogicas p. 59
5.1 Contagem de Pontos por fun¸c˜ao . . . p. 59
5.2 Composi¸c˜ao da equipe de Desenvolvimento . . . p. 61 5.3 Ferramentas . . . p. 61
5.3.2 Desenvolvimento na plataforma Java . . . p. 61
5.4 Aplica¸c˜ao de pontos por fun¸c˜ao . . . p. 62
6 Especifica¸c˜ao de Projeto p. 63
6.1 Arquitetura do Sistema . . . p. 63
6.1.1 Camada de Apresenta¸c˜ao . . . p. 64 6.1.2 Camada de Comunica¸c˜ao . . . p. 64
6.1.3 Camada de Neg´ocio/Modelo . . . p. 65
6.1.4 Camada de persistˆencia . . . p. 65
6.2 Distribui¸c˜ao dos Pacotes . . . p. 65
6.2.1 Diagrama de Classe do Modelo . . . p. 65
6.2.2 Diagrama de Classe da Vis˜ao . . . p. 67
6.2.3 Diagrama de Classe do Controle . . . p. 69
6.3 Pacote Utilit´ario . . . p. 71 6.3.1 JME - C´alculos exponenciais fracion´arios . . . p. 72
6.3.2 JME - Arredondamento matem´atico . . . p. 72
6.3.3 Acesso a Arquivos . . . p. 73
6.4 Estrutura dos dados . . . p. 73
6.5 Persistˆencia . . . p. 77
6.6 Revis˜ao dos diagramas de seq¨uˆencia . . . p. 80
6.7 Diagrama de componentes . . . p. 82
6.8 Diagrama de Implanta¸c˜ao . . . p. 83
6.9 Mapa de navegabilidade e Telas do prot´otipo . . . p. 83
7 Seguran¸ca p. 90
Anexo p. 97
.1 Manual do usu´ario . . . p. 97
.1.1 Instala¸c˜ao . . . p. 97
.1.2 Utiliza¸c˜ao . . . p. 100
.1.2.1 Importando os dados . . . p. 100 .1.2.2 Extrapolando um medicamento . . . p. 101
1 A Pirˆamide de projeto OO. (PRESSMAN, 2002) . . . p. 22
2 Fluxo do processo de OOD. (PRESSMAN, 2002) . . . p. 24
3 Exemplo de Tabela(TME) . . . p. 28 4 Estudo de caso - Extrapola¸c˜ao Alom´etrica . . . p. 29
5 C´alculo da dose . . . p. 30
6 C´alculo da freq¨uˆencia . . . p. 31
7 Solu¸c˜ao do problema apresentado na figura 4 . . . p. 31
8 Arquitetura das plataformas Java. (MUCHOW, 2001) . . . p. 35
9 Pilha de APIs. (PAULA, 2006) . . . p. 36
10 Vis˜ao geral do funcionamento do Floggy. (LUGON; ROSSATO; MOREIRA,
2008, p.27) . . . p. 38
11 Diagrama de casos de uso . . . p. 42
12 Modelo de classes do dom´ınio do problema . . . p. 50
13 Diagrama de sequˆencia Importar dados . . . p. 54
14 Diagrama de sequˆencia Limpar base de dados . . . p. 55 15 Diagrama de sequˆencia Listar Especies . . . p. 55
16 Diagrama de sequˆencia Extrapolar Medicamento . . . p. 56
17 Diagrama de sequˆencia Converter dose . . . p. 56
18 Diagrama de estados - Objeto Aplicacao . . . p. 57
19 Diagrama de estados - Extrapolacao . . . p. 58
20 Contagem dos Pontos por Fun¸c˜ao . . . p. 60
23 Diagrama de pacotes - Padr˜ao MVC . . . p. 65
24 Diagrama de classes - Modelo . . . p. 66
25 Diagrama de classes - Vis˜ao . . . p. 68
26 Diagrama de classes - Controle . . . p. 70
27 Diagrama de classes - Pacote Utilit´ario . . . p. 71
28 Diagrama de classes persistentes da aplica¸c˜ao . . . p. 77
29 Listagem exemplo de classes persistente - Floggy . . . p. 78
30 Listagem exemplo de opera¸c˜oes com o gerenciador de persistˆencia - Floggy p. 79 31 Diagrama de seq¨uˆencia revisado - UC01-Importar Dados . . . p. 80
32 Diagrama de seq¨uˆencia revisado - UC06-Extrapolar Medicametno . . . p. 81
33 Diagrama de seq¨uˆencia revisado - UC07-Converter Dose . . . p. 82
34 Diagrama de componentes da aplica¸c˜ao . . . p. 82
35 Diagrama de implanta¸c˜ao da aplica¸c˜ao . . . p. 83
36 Mapa de Navegabilidade da aplica¸c˜ao . . . p. 84
37 Tela do dispositivo exibindo a aplica¸c˜ao Veterin´aria . . . p. 84
38 Tela principal da aplica¸c˜ao . . . p. 85
39 Tela principal da aplica¸c˜ao - menu de comandos . . . p. 85 40 Tela de listagem de esp´ecies . . . p. 85
41 Tela de extrapola¸c˜ao alom´etrica . . . p. 86
42 Tela de listagem de medicamentos . . . p. 86
43 Tela de extrapola¸c˜ao alom´etrica - lista suspensa de grupos de esp´ecies . p. 86
44 Tela de extrapola¸c˜ao alom´etrica - lista suspensa de esp´ecies filtrada pela
escolha do grupo . . . p. 87
45 Tela de extrapola¸c˜ao alom´etrica - formul´ario preenchido . . . p. 87
48 Tela de convers˜ao de dose . . . p. 88
49 Tela de convers˜ao de dose - resultado calculado . . . p. 88
50 Tela principal da aplica¸c˜ao - Limpar base . . . p. 89
51 Tela de informa¸c˜ao de chave de seguran¸ca . . . p. 89
52 Tela de confirma¸c˜ao . . . p. 89
53 P´agina inicial do site do projeto alometria m´ovel . . . p. 90
54 P´agina de cadastro de usu´arios . . . p. 91
55 P´agina de login . . . p. 91 56 P´agina de boas vindas . . . p. 91
57 P´agina de download da aplica¸c˜ao - link validado para usu´arios cadastrados p. 92
58 Download do software AlometriaMovel . . . p. 97
59 Localizando a pasta Veterinaria no aparelho . . . p. 98
60 Conte´udo da pasta Veterinaria . . . p. 99
61 Tela inicial da aplica¸c˜ao AlometriaMovel . . . p. 99
62 Menu de op¸c˜oes . . . p. 100
63 Chave de seguran¸ca . . . p. 100
64 Extrapolar um medicamento . . . p. 101 65 Resultados . . . p. 101
1 Valores de constantes em rela¸c˜ao a diferentes grupos taxonˆomicos . . . p. 28
2 Descri¸c˜ao UC01 - Importar Dados . . . p. 44
3 Descri¸c˜ao UC02 - Limpar base de dados . . . p. 45 4 Descri¸c˜ao UC03 - Listar esp´ecies . . . p. 45
5 Descri¸c˜ao UC04 - Listar grupos de esp´ecies . . . p. 46
6 Descri¸c˜ao UC05 - Listar medicamentos . . . p. 46
7 Descri¸c˜ao UC06 - Extrapolar medicamento . . . p. 47
8 Descri¸c˜ao UC07 - Converter Dose . . . p. 47
9 Equipe de Desenvolvimento . . . p. 61
10 Estrutura de um Record Store . . . p. 74
11 Elementos de dados da classe Especie . . . p. 75
12 Elementos de dados da classe GrupoEspecie . . . p. 75 13 Elementos de dados da classe Medicamento . . . p. 75
14 Elementos de dados da classe GrupoMedicamento . . . p. 75
15 Elementos de dados da classe MedicamentoDosagem . . . p. 76
16 Elementos de dados da classe MedicamentoToxico . . . p. 76
A alometria ´e um ramo da biologia que estuda rela¸c˜oes de escala tendo diferentes conceitos observados, sendo que este trabalho, destina esfor¸cos para o estudo da alome-tria interespec´ıfica, que se refere ao mesmo tipo de fenˆomeno entre esp´ecies relacionadas de perto. A falta de uma ferramenta que facilite a execu¸c˜ao de c´alculos que utilizam a alometria para extrapolar medicamentos para animais selvagens, onde muitas vezes desconhece-se at´e mesmo sua fisiologia, torna o exerc´ıcio desta atividade, dif´ıcil e muitas vezes impreciso. O problema identificado aqui ´e o de como proporcionar um modo para que os profissionais desta ´area consigam executar tais tarefas com agilidade, precis˜ao e confiabilidade, mesmo que ele esteja em locais remotos desprovidos de material de apoio e consulta. Com o advento da mobilidade, este tipo ferramenta come¸ca a fazer parte da rotina, n˜ao s´o dessas pessoas, mas de profissionais de v´arias ´areas de atua¸c˜ao. Assim, o desenvolvimento de um software para dispositivos m´oveis capaz de realizar o c´alculo de doses, freq¨uˆencia de aplica¸c˜ao de f´armacos e necessidades energ´eticas para animais selvagens ´e o objetivo central deste trabalho. Com a utiliza¸c˜ao de pr´aticas consolidadas da engenharia de software e uma intera¸c˜ao constante e direta com os profissionais da medicina veterin´aria, objetiva-se a realiza¸c˜ao deste trabalho como um projeto de pes-quisa financiado pela FUNADESP(UVV), com a participa¸c˜ao do Mestrado em Medicina Veterin´aria e os cursos de Ciˆencia da Computa¸c˜ao e Sistemas de Informa¸c˜ao do Centro Universit´ario Vila Velha.
Palavras-chave: Alometria. Extrapolar. CLDC. MIDP. JME. Java. Mobilidade. Dispositivo.
1
Introdu¸
c˜
ao
A crescente demanda encontrada por m´edicos veterin´arios, principalmente aqueles que trabalham em campo (no habitat do animal) ou mesmo em zool´ogicos, no que diz respeito ao atendimento de animais selvagens, aponta para uma condi¸c˜ao irrevog´avel no exerc´ıcio de seu trabalho: ter uma ferramenta de aux´ılio na execu¸c˜ao de c´alculos para a extrapola¸c˜ao alom´etrica de f´armacos na posologia e freq¨uˆencia, permitindo um tratamento eficaz e sem margens de erro, no atendimento cl´ınico de animais selvagens.
A extrapola¸c˜ao alom´etrica interespec´ıfica ´e um m´etodo que permite, atrav´es do co-nhecimento das taxas metab´olicas de dois diferentes vertebrados, extrapolar matemati-camente para um deles (animal alvo), doses de medicamentos indicadas para o outro (animal modelo), para o qual j´a foram feitos estudos laboratoriais de experimenta¸c˜ao farmacocin´etica e farmacodinˆamica. N˜ao s˜ao poucos os passos para obter tais resultados.
Baseados nesta premissa propomos o desenvolvimento de um programa (software) para c´alculo de exigˆencias energ´eticas, doses e freq¨uˆencia de administra¸c˜ao de f´armacos para animais selvagens por meio da extrapola¸c˜ao alom´etrica interespec´ıfica.
Segundo Sedgwick (in Fowler, 1993), o princ´ıpio alom´etrico usa uma escala de parˆ ame-tros fisiol´ogicos comparando animais de v´arios tamanhos, sendo esta mesma escala usada para parˆametros farmacocin´eticos. A absor¸c˜ao, distribui¸c˜ao e elimina¸c˜ao de muitos f´ arma-cos administrados ao animal envolvem processos fisiol´ogicos, compat´ıveis com a escala alom´etrica. Em resumo, os efeitos dos f´armacos usados em um determinado animal podem ser extrapolados para o uso em outros animais atrav´es de c´alculos aritm´eticos.
Desde o in´ıcio de 2009, atrav´es de um projeto de pesquisa financiado pela FUNADESP (UVV), o Mestrado em Medicina Veterin´aria e os cursos de Ciˆencia da Computa¸c˜ao e Sis-temas de Informa¸c˜ao do Centro Universit´ario Vila Velha, est˜ao desenvolvendo um sistema com caracter´ısticas completas, auxiliando n˜ao s´o na extrapola¸c˜ao, mas tamb´em servindo de ferramenta de tomada de decis˜ao baseando-se em uma base de conhecimento alimen-tada pelos sucessos e fracassos nos diagn´osticos e tratamentos realizados. Os envolvidos
est˜ao trabalhando de forma cooperativa levantando, organizando, analisando, projetando e desenvolvendo os requisitos de forma a garantir qualidade em todo o processo de desen-volvimento. Este est´a se finalizando como uma ferramenta desktop e tende a migrar para o ambiente Web. Tal sistema ser´a implantado no hospital veterin´ario e disponibilizado gratuitamente para aqueles veterin´arios que tenham interesse em utiliz´a-lo. Contudo, esta ´e uma solu¸c˜ao que atende somente aos veterin´arios que se encontram no hospital vete-rin´ario, estando aqueles que fazem o atendimento em locais remotos ainda sofrendo com o dilema da necessidade de efetuar os c´alculos de extrapola¸c˜ao por conta pr´opria. Assim um sistema desenvolvido para dispositivos m´oveis poder´a fazer uso da base de conhecimentos da aplica¸c˜ao desktop, tendo como foco principal a extrapola¸c˜ao alom´etrica de f´armacos e necessidades energ´eticas, podendo ser utilizado em qualquer lugar que o usu´ario estiver.
Hoje em dia podemos afirmar que os dispositivos m´oveis fazem parte da rotina dos seres humanos. Acessar informa¸c˜oes a partir de v´arios lugares do globo terrestre, j´a ´e realidade para um percentual de pessoas que a cada dia cresce mais. Smartphones, celulares, pagers, handhelds e palmtops fazem parte do dia-a-dia dessas pessoas.
1.1
Motiva¸
c˜
ao
A realiza¸c˜ao dos c´alculos de extrapola¸c˜ao alom´etrica de f´armacos na posologia e neces-sidades energ´eticas para animais selvagens, demandam algum tempo e bastante aten¸c˜ao. Em situa¸c˜oes emergenciais o progn´ostico depende de a¸c˜oes r´apidas, escolha adequada do f´armaco e principalmente o c´alculo correto da dose. Para m´edicos veterin´arios que atuam nas cl´ınicas de grandes e pequenos animais h´a uma extensa literatura e estudos com os mais diversos f´armacos e sempre, numa emergˆencia, o paciente ser´a de uma esp´ecie bas-tante conhecida. Para veterin´arios que atuam na cl´ınica e cirurgia de animais selvagens a situa¸c˜ao ´e muito diferente, pois numa situa¸c˜ao emergencial pode-se receber uma esp´ecie para a qual n˜ao se tem nenhum estudo at´e mesmo sobre a fisiologia da esp´ecie.
Assim sendo, este projeto viabiliza-se por possibilitar de forma r´apida o c´alculo de dosagem e freq¨uˆencia de aplica¸c˜ao de f´armacos e necessidades energ´eticas para animais sel-vagens que se encontram em locais desprovidos de literaturas ou computadores, bastando o veterin´ario estar com seu “celular no bolso”.
Com um dispositivo m´ovel, por exemplo, um veterin´ario que est´a atuando em campo, ao encontrar um animal selvagem ter´a em m˜aos informa¸c˜oes que ir˜ao auxili´a-lo no trata-mento do animal, assim como, para medic´a-lo. Bastando para isto estar de posse de seu
dispositivo m´ovel.
1.2
Justificativa
O n´umero total de esp´ecies de vertebrados amea¸cados de extin¸c˜ao chega a mais de dez mil (10.000), destas, aproximadamente um quarto s˜ao esp´ecies de mam´ıferos, um oitavo s˜ao esp´ecies de aves e um ter¸co s˜ao esp´ecies de anf´ıbios. A velocidade da perda de biodiversidade est´a aumentando e pode tornar-se maior `a medida que os ecossistemas tornam-se afetados pelas mudan¸cas clim´aticas devido ao aquecimento global (Cockrem, 2005).
Como enumerado por Soul´e (1986), as seis principais classes de interferˆencia humana que contribuem para a degrada¸c˜ao da diversidade biol´ogica s˜ao:
1. a perda de habitat;
2. a fragmenta¸c˜ao dos habitats;
3. a super explora¸c˜ao dos recursos naturais;
4. a introdu¸c˜ao de esp´ecies ex´oticas e doen¸cas;
5. a polui¸c˜ao do ar, do solo e da ´agua;
6. as mudan¸cas clim´aticas.
Devido a estes fatores, nos ´ultimos anos, a ocorrˆencia de atendimento veterin´ario a ani-mais selvagens tem aumentado, tanto pela press˜ao antr´opica, que faz com que esp´ecimes de vida-livre avancem para as cidades, como pelo h´abito de manuten¸c˜ao de esp´ecies sil-vestres e ex´oticas em cativeiro.
Qualquer que seja a origem, estes animais chegam at´e o m´edico veterin´ario com sua sa´ude comprometida, na maioria das vezes em elevado n´ıvel de estresse, sendo ne-cess´arias interven¸c˜oes imediatas, tomadas de decis˜oes r´apidas para que se possa melhorar o progn´ostico para o indiv´ıduo.
A cl´ınica e cirurgia em animais selvagens constituem ´areas das mais desafiadoras da Medicina Veterin´aria, pois muitas vezes o cl´ınico e o cirurgi˜ao se deparam com esp´ecies para as quais n˜ao h´a informa¸c˜oes como, por exemplo, valores de parˆametros normais para
an´alises sang¨u´ıneas, h´abitos alimentares e doses e freq¨uˆencias para a administra¸c˜ao de f´armacos.
Assim, todo recurso que possa dar mais agilidade no manejo de um animal selvagem trar´a vantagens tanto para o paciente quanto para o m´edico veterin´ario.
1.3
Objetivo
Dentro deste cen´ario, objetiva-se o desenvolvimento de um software para dispositivos m´oveis (focando nos aparelhos celulares e/ou smartphones j´a existentes no mercado), possibilitando o c´alculo de doses, freq¨uˆencia de aplica¸c˜ao de f´armacos e necessidades energ´eticas para os animais selvagens atendidos em locais remotos ou mesmo onde n˜ao se disp˜oem de literatura ou sistemas de computadores como ´e o caso do Hospital Veterin´ario do Centro Universit´ario Vila Velha (UVV).
Os objetivos espec´ıficos do trabalho s˜ao:
• Criar um site para o projeto, para registro dos usu´arios e downloads da aplica¸c˜ao;
• Disponibilizar informa¸c˜oes sobre dosagem e freq¨uˆencia de medicamentos a serem administradas em animais selvagens, baseando-se no m´etodo apresentado;
• Disponibilizar atrav´es do site do projeto, arquivos de atualiza¸c˜ao para a aplica¸c˜ao atualizar sua base de conhecimento.
1.4
Descri¸
c˜
ao dos Cap´ıtulos
Nos cap´ıtulos que seguem ser˜ao apresentados:
Cap´ıtulo 2. Conceitos de engenharia de software, paradigma de desenvolvimento orientado a objetos e projeto orientado a objetos com UML e design patterns (padr˜oes de projeto). Um estudo da alometria tratando pontualmente da extra-pola¸c˜ao de f´armacos para animais alvos (selvagens), com base no conhecimento j´a adquirido em cuja fisiologia de animais modelos, j´a foi estudada e testada com o f´armaco em quest˜ao.
Cap´ıtulos 2 e 6. A tecnologia utilizada para o desenvolvimento do prot´otipo da aplica¸c˜ao, discutindo os pontos que levaram ao uso do Java Micro Edition para
implementa¸c˜ao de uma solu¸c˜ao para o problema apresentado, bem como apresentar uma vis˜ao geral sobre persistˆencia de dados e o seu uso em dispositivos m´oveis;
Cap´ıtulos 3, 4 e 6. O levantamento dos requisitos de software, sua especifica¸c˜ao de analise, de projeto, bem como ferramentas e politicas utilizadas no desenvolvi-mento e implementa¸c˜ao da aplica¸c˜ao;
Cap´ıtulos 5. Apresenta as propostas tecnol´ogicas estudadas;
Cap´ıtulos 6 e 8. Implementa¸c˜ao de um prot´otipo, resultados obtidos, discuss˜oes e extens˜oes do trabalho.
Cap´ıtulo 7. M´etodos e pol´ıticas que asseguram a integridade dos dados e garantem um n´ıvel aceit´avel de seguran¸ca no decorrer de todo o ciclo de utiliza¸c˜ao da aplica¸c˜ao.
2
Referencial Te´
orico
Este cap´ıtulo trata dos conceitos usados neste projeto, tornando mais claro os aspectos de todo o clico de desenvolvimento deste trabalho.
Visando as melhores pr´aticas de desenvolvimento de software, disciplinas da engenha-ria de software s˜ao aplicadas neste projeto objetivando resultados de qualidade n˜ao s´o na forma de desenvolver, mas tamb´em no total atendimento dos anseios e das necessidades do cliente.
2.1
O Paradigma Orientado a Objetos - OO
A abordagem orientada a objetos ainda n˜ao ´e adotada por completo, fato que pode ser visto facilmente nas empresas que est˜ao no mercado. Uma abordagem completa implica em toda uma vis˜ao orientada a objetos, e n˜ao apenas o mero emprego de uma programa¸c˜ao orientado a objetos. Edward Berard, citado por Pressman(2002, p.532), menciona isso quando afirma:
“Os benef´ıcios da tecnologia orientada a objetos s˜ao ampliados se ela ´e adotada no in´ıcio e ao longo de todo o processo de engenharia de software.”
Todos que optam por esta tecnologia devem avaliar seu impacto em todo o processo de engenharia de software, pois a vis˜ao orientada a objetos exige da engenharia de software um abordagem evolutiva. Para este projeto foram adotados a an´alise orientada a objetos e projeto orientado a objetos. Foi tamb´em adotata a engenharia de requisitos (PRESSMAN, 2002, p.250), de modo a manter um mecanismo adequado para entender o que o cliente deseja, analisar as necessidades, avaliar a exeq¨uibilidade, negociar uma solu¸c˜ao razo´avel, validar a especifica¸c˜ao e administrar os requisitos `a medida em que eles s˜ao transformados num sistema em opera¸c˜ao.
2.2
An´
alise Orientada a Objetos - OOA
A OOA (object-oriented analysis) ´e a primeira atividade t´ecnica que realizada como parte da engenharia de software OO. Coad e Yourdon, citado por Pressman(2002, p.559), consideram alguns aspectos ao escreverem:
“A OOA ´e baseada em conceitos que aprendemos primeiro no jardim da infˆ an-cia: objetos e atributos, classes e membros, todo e partes. Por que levamos tanto tempo para aplicar esses conceitos `a an´alise e `a especifica¸c˜ao de sistemas de informa¸c˜ao ´e uma suposi¸c˜ao de cada um...”
Construir software sem ter um entendimento razo´avel do sistema implicaria em uma s´erie de conseq¨uˆencias negativas para o projeto. Por isso o uso da OOA para o forneci-mento de um modo concreto de representar o entendiforneci-mento dos requisitos e depois testar esse entendimento contra a percep¸c˜ao do cliente.
O objetivo ´e desenvolver um modelo que descreve como o software funciona para satisfazer um conjunto de requisitos definidos pelo cliente. O modelo de analise OO ´e composto de representa¸c˜oes gr´aficas ou baseadas em linguagem que definem os atributos, relacionamentos e comportamentos das classes, bem como comunica¸c˜ao interclasses e um gr´afico do comportamento da classe ao longo do tempo.
Os artefatos gerados nesta etapa do projeto definiram as classes (objetos) que repre-sentam o problema a ser resolvido, o modo pelo qual as classes se relacionam e interagem umas com as outras, o funcionamento interno (atributos e opera¸c˜oes) dos objetos e os mecanismos de comunica¸c˜ao (mensagens) que permitem a eles trabalharem juntos.
2.3
Projeto Orientado a Objetos - OOD
A OOD (object-oriented design) transforma o modelo de an´alise criado, num modelo de projeto que serve como documento para a constru¸c˜ao do software. Contudo, o servi¸co do projetista de software pode ser complicado. Gamma, um dos Gang Of Four1, citado
por Pressman(2002, p.589), fornece um panorama razoavelmente preciso de OOD quando afirma:
1Nome pelo qual ficaram reconhecidos os autores do famoso livro Design Patterns: Elements of
“Projetar software orientado a objetos ´e dif´ıcil e projetar software reus´avel orientado a objetos ´e ainda mais dif´ıcil. Vocˆe precisa encontrar objetos perti-nentes, fator´a-los em classes na granularidade adequada, definir interfaces de classes e hierarquias de heran¸ca, e estabelecer rela¸c˜oes-chave entre elas. Seu projeto deve ser espec´ıfico para o problema em m˜aos, mas deve ser tamb´em geral o suficiente para atender a problemas e requisitos futuros. Vocˆe tamb´em precisa evitar reprojeto, ou pelo menos minimiz´a-lo. Projetistas experientes em orienta¸c˜ao a objetos v˜ao dizer-lhe que um projeto reus´avel e flex´ıvel ´e dif´ıcil, ou imposs´ıvel, de obter “direito” da primeira vez. Antes que um projeto seja acabado, eles em geral tentam reus´a-lo v´arias vezes, modificando-o sempre.”
A natureza singular do projeto orientado a objetos est´a na capacidade de se construir sistemas sobre quatro importantes conceitos de projeto de software: abstra¸c˜ao, oculta-mento da informa¸c˜ao, independˆencia funcional e modularidade. Observe na Figura 1, onde estes conceitos se encaixam na pirˆamide de OOD.
Figura 1: A Pirˆamide de projeto OO. (PRESSMAN, 2002)
A pirˆamide de projeto objetiva exclusivamente o projeto de um produto ou sistema espec´ıfico. ´E importante destacar que na funda¸c˜ao desta pirˆamide temos o projeto de objetos do dom´ınio, onde a aplica¸c˜ao de padr˜oes de projeto ´e not´oria. Mais adiante ser´a mostrado a importˆancia da aplica¸c˜ao de padr˜oes. Os objetos de dom´ınio desempenham um papel-chave na constru¸c˜ao da infra-estrutura do sistema OO, fornecendo suporte para as atividades de interface homem/computador, gest˜ao de tarefas e gest˜ao de dados.
2.4
Linguagem de Modelagem Unificada - UML
A popularidade das tecnologias de objetos fez com que d´uzias de m´etodos de OOA e OOD proliferassem no fim dos anos 80 e durante os anos 90. Cada um deles introduziu um processo para a an´alise de um produto ou sistema, um conjunto de diagramas que evoluiu a partir do processo, e uma nota¸c˜ao que permitiu ao engenheiro de software criar modelos de an´alise de um modo consistente. Esses m´etodos estabeleceram a funda¸c˜ao da nota¸c˜ao, heur´ısticas de projeto e modelos modernos (PRESSMAN, 2002).
Durante uma d´ecada, Grady Booch, James Rumbaugh e Ivar Jacobson colaboraram para combinar as melhores caracter´ısticas de seus m´etodos individuais de an´alise e projeto orientados a objetos num m´etodo unificado. O resultado chamado de linguagem de mo-delagem unificada (unified modeling language, UML), tornou-se amplamente usado pela ind´ustria (BOOCH; RUMBAUGH; JACOBSON, 1999).
A UML permite ao engenheiro de software expressar em modelo de an´alise usando uma nota¸c˜ao de modelagem, que ´e regulada por um conjunto de regras sint´aticas, semˆanticas e pragm´aticas. Em UML, um sistema ´e representado usando cinco diferentes vis˜oes, que descrevem o sistema a partir de perspectivas distintas e diferentes. Cada vis˜ao ´e definida por um conjunto de diagramas. As seguintes vis˜oes s˜ao apresentadas em UML na fase de an´alise:
Vis˜ao do modelo do usu´ario: Representa a vis˜ao do sistema a partir da perspectiva do usu´ario (atores). O caso de uso ´e a abordagem escolhida para a vis˜ao do modelo do usu´ario.
Vis˜ao do modelo estrutural: Dados e funcionalidades, isto ´e, estrutura est´atica (clas-ses, objetos e relacionamentos) ´e modelada.
Vis˜ao do modelo comportamental: Aqui s˜ao representados os aspectos dinˆamicos do sistema, assim como intera¸c˜oes ou colabora¸c˜oes entre os v´arios elementos estruturais descritos no modelo do usu´ario e modelo estrutural.
Vis˜ao do modelo de implementa¸c˜ao: Apresenta a forma como os aspectos estrutu-rais e comportamentais do sistema devem ser constru´ıdos.
Vis˜ao do modelo do ambiente: Aspectos estruturais e comportamentais do ambiente devem ser representados.
Na fase de projeto a UML ´e organizada em duas principais atividades: projeto do sistema e projeto de objetos. No projeto do sistema, o principal objetivo ´e representar a arquitetura do software, focalizando na defini¸c˜ao de “subsistemas” com o objetivo macro de se obter reuso da implementa¸c˜ao em projetos futuros. O projeto de objetos em UML ´e estendido para considerar o projeto das interfaces com o usu´ario, gest˜ao de dados no sistema e gest˜ao de tarefas no subsistemas que foram especificados.
Figura 2: Fluxo do processo de OOD. (PRESSMAN, 2002)
Observe na figura 2, o fato do processo ser evolutivo, ou seja, os artefatos gerados em cada etapa est˜ao continuamente sendo refinados conforme a necessidade ou alterados caso aja a elicita¸c˜ao de novos requisitos.
Os modelos constru´ıdos neste projeto fizeram uso dos seguintes diagramas da UML:
(Na fase de an´alise)
• Diagrama de casos de uso;
• Diagrama de classes (conceitual); • Diagrama de pacotes;
(Na fase de projeto) • Diagrama de classes; • Diagrama de pacotes; • Diagrama de seq¨uˆencia; • Diagrama de estados;
2.5
Padr˜
oes de Projeto
Em qualquer ´area de atua¸c˜ao, os melhores projetistas tˆem uma habilidade incomum de ver padr˜oes que caracterizam um problema e padr˜oes correspondentes que podem ser combinados para criar uma solu¸c˜ao. De acordo com os autores da Gang Of Four, uma defini¸c˜ao para Design patterns seria:
“Descri¸c˜ao de objetos de comunica¸c˜ao e classes que s˜ao customizados para resolver um problema geral de design em um contexto particular.”
Um projetista que est´a familiarizado com tais padr˜oes pode aplic´a-los imediatamente a problemas de projeto sem ter que redescobri-los. A utiliza¸c˜ao de patterns traz, dentre muitos outros, os seguintes benef´ıcios para o software:
Aumento do reuso: Cria¸c˜ao de uma solu¸c˜ao gen´erica para determinado problema, de forma que esta solu¸c˜ao de projeto possa ser reaproveitada em outros projetos caso se repita. Quanto maior for a abstra¸c˜ao, maior ser´a o n´ıvel de reuso em outros projetos.
Melhora na documenta¸c˜ao: Uma das caracter´ısticas mais fortes em Design Patterns ´
e que eles s˜ao bem documentados. Um pattern ´e composto por v´arias partes, todas estas bem documentadas para mostrar como ele faz aquilo que se prop˜oe, sob qual contexto ele ´e utilizado e quais as conseq¨uˆencias da utiliza¸c˜ao do mesmo. Sendo eles bem documentados, se um sistema os utilizar, conseq¨uentemente estar´a agregando tamb´em toda esta documenta¸c˜ao.
Facilita a manuten¸c˜ao: A manuten¸c˜ao ´e um processo que consome uma grande quan-tidade de tempo e recursos no ciclo de vida do software. Uma das maneiras de se minimizar esta etapa (a manuten¸c˜ao) ´e fazendo bem as etapas anteriores. Para isto recomenda-se que n˜ao se deva poupar tempo quando se est´a projetando um software, bem como alocar um bom tempo para elabora¸c˜ao de uma boa e completa documenta¸c˜ao do mesmo. A utiliza¸c˜ao de Design Patterns no processo de produ¸c˜ao de software contribui para minimizar o esfor¸co com manuten¸c˜ao no futuro. Como visto anteriormente, um dos pontos fortes de um “pattern” ´e a sua documenta¸c˜ao. Existem v´arios Design patterns j´a documentados hoje em dia e dispon´ıveis para serem utilizados em projetos de software.
Aumenta a qualidade do software: Sendo um pattern a documenta¸c˜ao da melhor t´ecnica que pode ser utilizada para resolver um determinado problema, ´e certo que isto tudo agregado `as qualidades mencionadas anteriormente, trazendo uma melhor qualidade para o software.
Faz-se o uso dos seguintes design patterns (do tipo GoF - Gang Of Four) neste projeto:
Fa¸cade: Padr˜ao de projeto do tipo estrutural. um objeto que disponibiliza uma interface para uma grande quantidade de funcionalidades de uma API2.
Singleton: Este padr˜ao garante a existˆencia de apenas uma instˆancia de uma classe, mantendo um ponto global de acesso ao seu objeto.
Existem v´arios outros tipos de design patterns, como aqueles do tipo GRASP. Como n˜ao s˜ao aplicados neste projeto, est´a fora do escopo falar sobre eles.
2.5.1
Padr˜
ao MVC
A decis˜ao de escolha por um padr˜ao de desenvolvimento, ocorre pelos benef´ıcios tra-zidos e tamb´em desejados em um determinado projeto. O padr˜ao MVC3, considera a divis˜ao de um sistema em camadas para que este seja mais port´avel e modific´avel, ou seja, uma mudan¸ca em uma camada mais baixa que n˜ao afete sua interface com outras camadas, n˜ao implicar´a em mudan¸cas nas camadas mais altas, e vice-versa. Uma camada de software ainda pode ser reutilizada em outros projetos de software que necessitem das funcionalidades j´a existentes nessa camada, bastando para isso que seja acessado sua inter-face solicitando seus servi¸cos. Desenvolvimento em camadas observa os quesitos facilidade de manuten¸c˜ao, baixo acoplamento e o reuso de c´odigo fonte evitando retrabalhos.
Neste padr˜ao s˜ao apresentadas trˆes camadas de software sendo elas:
Camada de modelo Composta de classes que implementam as entidades da aplica¸c˜ao respons´aveis por manter a base de dados armazenados, e tamb´em classes que im-plementam regras de neg´ocio.
2Application Programming Interface (ou Interface de Programa¸c˜ao de Aplicativos) ´e um conjunto de
rotinas e padr˜oes estabelecidos por um software para a utiliza¸c˜ao das suas funcionalidades por programas aplicativos que n˜ao querem envolver-se em detalhes da implementa¸c˜ao do software, mas apenas usar seus servi¸cos. Fonte: Wikip´edia.
Camada de vis˜ao Composta por classes que disponibilizam a visualiza¸c˜ao dos dados pelos usu´arios do sistema;
Camada de Controle Composta por classes que implementam a forma como os dados do modelo ser˜ao acessados para a realiza¸c˜ao das computa¸c˜oes necess´arias, gerenci-ando as tarefas desempenhadas pelo sistema e tamb´em validando os dados proveni-entes da camada de apresenta¸c˜ao.
2.6
O estudo da alometria visando a extrapola¸
c˜
ao de
f´
armacos
Alometria ´e um ramo da biologia que estuda rela¸c˜oes de escalas entre diversas formas de vida. Atualmente distingue-se quatro conceitos distintos de alometria:
• alometria ontogen´etica, que se refere ao crescimento relativo dos indiv´ıduos.
• alometria filogen´etica, que se refere a raz˜oes de crescimento distintas em linhagens.
• alometria intraespec´ıfica, que se refere a indiv´ıduos adultos dentro de uma esp´ecie ou para uma dada popula¸c˜ao local.
• alometria interespec´ıfica, que se refere ao mesmo tipo de fenˆomeno entre esp´ecies relacionadas de perto (Gould 1966).
Como j´a mostrado na introdu¸c˜ao desta disserta¸c˜ao, o conceito usado por este projeto ´e o da alometria interespec´ıfica. Para tal estudo devemos observar as taxas utilizadas no processo de extrapola¸c˜ao, que s˜ao as TMB (taxa metab´olica basal) e TME (taxa metab´olica espec´ıfica). Tais taxas j´a se encontram organizadas em extensas tabelas (veja figura 3) com o objetivo de facilitar a consulta das mesmas. No entanto n˜ao ´e um processo ainda eficaz. Para n˜ao fazer com que o sistema efetua uma leitura destas tabelas, o que seria mais complexo e de baixa performance, foi adotado o modelo matem´atico que calcula essas taxas e com isso em alguns passos extrapolar o medicamento por meio de f´ormulas que veremos mais detalhadamente na seq¨uˆencia.
Figura 3: Exemplo de Tabela(TME)
A extrapola¸c˜ao inicia-se pelo c´alculo da taxa metab´olica basal (TMB) que ´e o peso metab´olico elevado a 0,75 e multiplicado por uma constante. Tal constante ´e espec´ıfica para um determinado grupo de animais, a uma temperatura corp´orea central espec´ıfica conforme demonstrado na tabela 1.
GRUPO CONSTANTE TEMPERATURA Passeriformes 129 42◦C N˜ao passeriformes 78 40◦C Mam´ıferos Placent´arios 70 37◦C Marsupiais e Edentatas 49 35◦C R´epteis 10 37◦C
Tabela 1: Valores de constantes em rela¸c˜ao a diferentes grupos taxonˆomicos
A taxa metab´olica basal(TMB) pode ser expressa em quilocalorias e indica a energia m´ınima necess´aria para manter um organismo vivo com determinado peso, j´a que esta ´e a energia produzida por ele em uma situa¸c˜ao de repouso em um ambiente termo neutro.
A taxa metab´olica espec´ıfica(TME) ´e o peso metab´olico elevado a -0,25 e multiplicado pela mesma constante da TMB. ´E expresso em quilocalorias/Kg/dia. Indica a energia m´ınima produzida por um animal num dia para cada quilograma de seu peso.
Usualmente a TMB ´e utilizada para o c´alculo das necessidades energ´eticas e dosagens. A TME para calcular a freq¨uˆencia da medica¸c˜ao.
Veja agora um exemplo de extrapola¸c˜ao fazendo o uso de f´ormulas que s˜ao as regras de neg´ocio deste sistema.
Vamos analisar o seguinte cen´ario:
Figura 4: Estudo de caso - Extrapola¸c˜ao Alom´etrica
Observe os campos com a “?”. O objetivo e descobrir estes valores. Para isso vejamos as f´ormulas:
T M B = KxM0,75 (2.1) , onde K ´e a constante do grupo ao qual o animal pertence, e M ´e seu peso.
T M E = KxM−0,25 (2.2) , onde K ´e a constante do grupo ao qual o animal pertence, e M ´e seu peso.
A TME de um animal ainda pode ser calculada usando sua TMB, uma vez que j´a tenha sido calculada. Desta forma ter´ıamos a seguinte f´ormula:
T M E = T M B
M (2.3)
, onde M ´e seu peso.
Agora que as f´ormulas s˜ao conhecidas, vamos proceder com a descoberta dos valores desejados pela extrapola¸c˜ao alom´etrica.
De acordo com nosso estudo de caso temos que o peso do c˜ao ´e de 10kg. O me-dicamento a ser extrapolado (Cloranfenicol) possui uma freq¨uˆencia de administra¸c˜ao de 12/12hs e dose de 30mg/kg para este animal.
Primeiramente, deve-se descobrir a TMB do c˜ao e em seguida a TMB do papagaio. Depois a dose total do c˜ao, ou seja 300mg (30mg para cada um de seus 10kg), ´e dividade por sua TMB. Neste momento temos um valor que podemos chamar de “Fator dose mo-delo”. Multiplicando este valor pela TMB do papagaio temos a dose total de cloranfenicol, baseando-se na dose total do c˜ao, a ser ministrada no papagaio. Dividindo a dose total do papagaio pelo seu peso em quilogramas temos dose em mg/kg. Veja a situa¸c˜ao da figura 5.
Figura 5: C´alculo da dose
Agora, o pr´oximo passo ´e descobrir a TME de ambos os animais. Para isso basta dividir a TMB de cada animal pelo peso do respectivo animal. Lembrando que a TMB ´e a quantidade de energia para manter o organismo vivo e a TME energia m´ınima produzida pelo animal para cada quilograma de seu peso, por isso a divis˜ao da TMB pelo peso. Com isso temos a situa¸c˜ao da figura 6.
Figura 6: C´alculo da freq¨uˆencia
Diante dos fatos, podemos enfim completar os campos faltantes em nosso caso de estudo conforme visto na figura 7.
Figura 7: Solu¸c˜ao do problema apresentado na figura 4
Desta forma temos todos os passos necess´arios para efetuar o c´alculo da extrapola¸c˜ao alom´etrica de animais modelos (que j´a possuem medicamentos conhecidos e testados), para animais alvos (que n˜ao s˜ao conhecidos pela medicina veterin´aria).
2.7
A Plataforma de Desenvolvimento Java
Java ´e uma linguagem de programa¸c˜ao orientada a objeto criada na d´ecada de 90 por desenvolvedores da Sun Microsystems. (Wikip´edia org, 2009b) Liderados por James Gosling, decidiram criar uma maneira diferente do que era convencional na ´epoca. Ao inv´es de gerar c´odigo nativo para determinado sistema operacional, o compilador gera um c´odigo intermedi´ario denominado bytecode, que por sua vez ´e interpretado por outro programa
que ficou conhecido como M´aquina Virtual Java ou JVM (Java Virtual Machine). Java ´e a principal linguagem da plataforma Java apesar de n˜ao ser a ´unica.
Este trabalho ´arduo visou tornar a linguagem um padr˜ao de desenvolvimento pelo fato da possibilidade de criar uma m´aquina virtual para a arquitetura desejada, e ent˜ao executar uma aplica¸c˜ao em qualquer dispositivo que a possua.
2.7.1
Breve Hist´
orico
Em janeiro de 1995 com o crescimento da Internet, a rede interativa que eles pre-cisavam estava pronta e se estabelecendo. Surge ent˜ao a primeira vers˜ao de Java antes chamado de Oak. (Wikip´edia org, 2009b) A tecnologia Java foi projetada para se mover por meio das redes de dispositivos heterogˆeneos, redes como a Internet. Agora aplica¸c˜oes poderiam ser executadas dentro dos browsers nos Applets Java e tudo seria disponibili-zado pela Internet instantaneamente. Foi o est´atico HTML4 dos browsers que promoveu a
r´apida dissemina¸c˜ao da dinˆamica tecnologia Java. Com isso o n´umero de usu´arios cresceu rapidamente, grandes fornecedores de tecnologia, como a IBM5 anunciaram suporte para
esta tecnologia.
Java continuou crescendo e hoje ´e uma referˆencia no mercado de desenvolvimento de software. Java tornou-se popular pelo seu uso na Internet e hoje possui seu ambiente de execu¸c˜ao presente em Web browsers, mainframes, SOs, celulares, palmtops e cart˜oes inteligentes, entre outros.
2.7.2
Padroniza¸
c˜
ao
Em 1997 a Sun Microsystems tentou submeter a linguagem a padroniza¸c˜ao pelos ´
org˜aos ISO/IEC e ECMA, mas acabou desistindo (Wikip´edia org, 2009b). Java ainda ´e um padr˜ao de fato, que ´e controlado atrav´es Java Community Process (JCP org, 2009). Em 13 de Novembro de 2006, a Sun Microsystems lan¸cou a maior parte do Java como Software Livre sob os termos da GNU General Public License (GPL) (MundoJava com, 2006). Em 8 de Maio de 2007 a Sun Microsystems finalizou o processo, tornando praticamente todo o c´odigo Java como software de c´odigo aberto, menos uma pequena por¸c˜ao da qual a Sun Microsystems n˜ao possui direitos autorais.
4HTML (acrˆonimo para a express˜ao inglesa HyperText Markup Language, que significa Linguagem de
Marca¸c˜ao de Hipertexto) ´e uma linguagem de marca¸c˜ao utilizada para produzir p´aginas na Web. Fonte: Wikip´edia.
5International Business Machines (IBM) ´e uma empresa norte-americana voltada para a ´area de
2.7.3
Principais Caracter´ısticas
A linguagem Java foi projetada com os seguintes objetivos (Wikip´edia org, 2009b):
• Orienta¸c˜ao a objeto - Baseado no modelo de Smalltalk e Simula67;
• Portabilidade - Independˆencia de plataforma - “write once, run anywhere” (escrever uma vez, executar em qualquer lugar);
• Recursos de Rede - Possui extensa biblioteca de rotinas que facilitam a coopera¸c˜ao com protocolos TCP/IP, como HTTP e FTP;
• Seguran¸ca - Pode executar programas via rede com restri¸c˜oes de execu¸c˜ao;
Podemos destacar outras vantagens apresentadas pela linguagem (Wikip´edia org, 2009b):
• Sintaxe similar a Linguagem C/C++.
• Facilidades de Internacionaliza¸c˜ao - Suporta nativamente caracteres Unicode;
• Simplicidade na especifica¸c˜ao, tanto da linguagem como do ambiente de execu¸c˜ao (JVM);
• ´E distribu´ıda com um vasto conjunto de bibliotecas (ou APIs);
• Possui facilidades para cria¸c˜ao de programas distribu´ıdos e multitarefa (m´ultiplas linhas de execu¸c˜ao num mesmo programa);
• Desaloca¸c˜ao de mem´oria autom´atica por processo de coletor de lixo (garbage col-lector);
• Carga Dinˆamica de C´odigo - Programas em Java s˜ao formados por uma cole¸c˜ao de classes armazenadas independentemente e que podem ser carregadas no momento de utiliza¸c˜ao.
2.7.4
M´
aquina Virtual Java
Programas Java n˜ao s˜ao traduzidos para linguagem de m´aquina, como outras lin-guagens estaticamente compiladas. Ao inv´es disso um compilador dinˆamico gera uma representa¸c˜ao intermedi´aria, chamada bytecodes (Wikip´edia org, 2009b).
´
E essa caracter´ıstica que faz com que os os programas Java sejam independentes de plataforma, executando em qualquer sistema que possua uma JVM. Cada opcode6 tem o tamanho de um byte, o que originou o nome bytecode.
Os bytecodes produzidos pelos compiladores Java podem ser usados num processo de engenharia reversa para a recupera¸c˜ao do programa-fonte original. Esta ´e uma carac-ter´ıstica que atinge em menor grau todas as linguagens compiladas. No entanto j´a existem hoje tecnologias que “embaralham” e at´e mesmo criptografam os bytecodes praticamente impedindo a engenharia reversa (Wikip´edia org, 2009b).
2.8
Java para dispositivos m´
oveis - JME
A plataforma Java se caracteriza pelo objetivo de sempre executar em diferentes dispositivos. Esta caracter´ıstica fez com que este projeto fizesse uso da tecnologia Java voltada para dispositivos m´oveis denominada Java ME ou JME (Java Micro Edition), ou ainda J2ME (Java 2 Micro Editon) que ocorre devido a vers˜ao do Java na ´epoca em que criaram a plataforma. Esta tecnologia come¸cou a ocorrer em 1999, quando a Sun Microsystems (detentora da plataforma Java) se uniu a Motorola (Grande fabricante de dispositivos m´oveis) para definir uma simplifica¸c˜ao da linguagem e da m´aquina virtual para terminais com limita¸c˜ao de processamento e mem´oria. (Sun Microsystems; Motorola, 2006)
Devido a esta simplifica¸c˜ao, foi necess´ario ent˜ao definir diferentes plataformas de java que iriam ter como alvo diferentes tipos de hardwares. Estas divis˜oes na plataforma ocorreram a partir da vers˜ao 2 da linguagem: J2SE, J2EE e J2ME. Essas divis˜oes s˜ao chamadas por alguns de ambientes de desenvolvimento. No entanto, h´a quem as denomine profile, plataforma, vers˜ao, entre outros. Mais tarde foi definida tamb´em uma plataforma para desenvolver aplica¸c˜oes para cart˜oes inteligentes (SmartCard). (PAULA, 2006)
´
E importante ressaltar que, a partir de 2006, passou-se a utilizar uma nova nomen-clatura para essas plataformas. O n´umero 2 foi retirado das siglas que as representam. Assim, estas passaram a ser JEE, JSE e JME.
Quatro plataformas foram definidas:
• Java EE ou JEE (Java Enterprise Edition) - Tem como alvo servidores com muita
6Em Ciˆencia da Computa¸c˜ao, um Opcode ´e um peda¸co de uma instru¸c˜ao da linguagem de m´aquina
que especifica a opera¸c˜ao a ser executada. O termo ´e uma abrevia¸c˜ao de Operation Code (C´odigo de Opera¸c˜ao). Fonte: Wikip´edia.
mem´oria e capacidade de processamento;
• Java SE ou JSE (Java Standard Edition) - Tem como alvo os computadores pessoais.
• Java ME ou JME (Java Micro Edition) - Tem como alvo dispositivos que usualmente possuem mem´oria e processamento limitados;
• JavaCard - tem como alvo programar para SmartCard (cart˜oes inteligentes).
Figura 8: Arquitetura das plataformas Java. (MUCHOW, 2001)
2.8.1
Configura¸
c˜
ao e perfil
Observe na figura 8 que na plataforma JME existem dois conceitos definidos: Confi-gura¸c˜ao e perfil. A configura¸c˜ao esta associada a m´aquina virtual e determina as classes b´asicas do Java que est˜ao dispon´ıveis para o terminal. O perfil est´a associado a um tipo ou uma classe de terminais e define as APIs espec´ıficas desta fam´ılia de terminais, ou seja, possibilitar a implementa¸c˜ao de aplica¸c˜oes que estejam de acordo com as caracter´ısticas dos dispositivos computacionais.
2.8.1.1 Configura¸c˜oes
Duas configura¸c˜oes foram definidas e especificadas separadamente. A primeira cha-mada de CLDC (JCP org, 2002b) - Connected Limmited Device Configuration (Confi-gura¸c˜ao para Terminais Conectados e Limitados) est´a associada a uma m´aquina virtual (Sun Microsystems, 2001) tamb´em limitada chamada de KVM (kilobyte virtual machine). A outra configura¸c˜ao ´e chamada de CDC (JCP org, 2003a) - Connected Device Configuration (Configura¸c˜ao para Terminais Conectados) e ´e bem similar ao que est´a dispon´ıvel no JSE.
2.8.1.2 Perfis
O primeiro perfil especificado foi exatamente o que estabelece o modelo de aplica¸c˜ao e as APIs para o mundo dos telefones celulares. Ele ´e chamado de MIDP (JCP org, 2002a) - Mobile Infomation Device Profile (Perfil para Terminais M´oveis de Informa¸c˜ao). Este perfil definiu:
1. Um modelo de aplica¸c˜ao chamado de MIDlet e bem similar ao Applet;
2. APIs para acesso `a tela do telefone;
3. APIs de acesso `a rede;
4. APIs para salvar dados localmente no telefone;
5. Um mecanismo e um protocolo para baixar, instalar e rodar aplica¸c˜oes nos celulares;
Outros perfis foram definidos posteriormente, mas o MIDP continua sendo `a base de todo o desenvolvimento para os telefones celulares que ´e feito at´e os dias atuais (PAULA,
2006). A figura 9 apresenta uma pilha de APIs em um telefone que ´e conhecida comumente por Java ME.
Figura 9: Pilha de APIs. (PAULA, 2006)
Milh˜oes de telefones j´a foram lan¸cados desde 2001 e Java se tornou a principal tecno-logia para desenvolvimento de aplica¸c˜oes nos telefones celulares (Wikip´edia org, 2009c).
2.8.2
Persistindo dados localmente - API RMS
Cada dispositivo m´ovel mant´em uma ´area da mem´oria para o armazenamento de da-dos. Diante deste fato o perfil MIDP fornece uma API para a persistˆencia de dados nos
dispositivos (Sun Microsystems, 2006). Esta API ´e conhecida como Record Management System (Sistema de Gerenciamento de Registros), ou RMS. Como o pr´oprio nome evi-dencia, trata-se de uma persistˆencia baseada em registros, que por sua vez s˜ao agrupados em pequenas tabelas conhecidas como record store.
Diferente de uma banco de dados convencional, em que os dados s˜ao estruturados em campos (ou colunas), o RMS fornece uma estrutura de armazenamento simples, em que tudo ´e tratado como array de bytes e identificado por uma chave inteira ´unica (ID). Cabe ao desenvolvedor, portanto, a codifica¸c˜ao de toda a l´ogica respons´avel por gerar e interpretar o conte´udo de um registro, ou seja, um array de bytes. Processo este tamb´em conhecido como serializa¸c˜ao.
Al´em da serializa¸c˜ao, existem outros aspectos relacionados ao RMS que ficam sob responsabilidade do desenvolvedor, como a cria¸c˜ao, exclus˜ao, abertura e fechamento de record stores e o controle de inclus˜ao, altera¸c˜ao, exclus˜ao e busca dos objetos.
Codificar a persistˆencia dos dados com a API de RMS muitas vezes n˜ao ´e uma escolha, mas sim a ´unica op¸c˜ao. Isso porque existem pouqu´ıssimos bancos de dados e frameworks de persistˆencia para tecnologia JME/MIDP. Quando existem, estes s˜ao propriet´arios ou destinados a determinados dispositivos (LUGON; ROSSATO; MOREIRA, 2008). Devido a
compatibilidade com diversos tipos de dispositivos, a API de RMS ´e simples e funcio-nal. Entretanto, dependendo da complexidade da aplica¸c˜ao que se deseja desenvolver, a codifica¸c˜ao e manuten¸c˜ao do c´odigo de persistˆencia utilizando o RMS podem tornar-se extremamente trabalhosas.
2.8.2.1 Floggy - Framework de persistˆencia para tecnologia JME/MIDP
O Floggy ´e um framework open source de persistˆencia de objetos para aplica¸c˜oes JME/MIDP, compat´ıvel com as configura¸c˜oes CLDC 1.0 E 1.1. Seu principal objetivo ´e abstrair do desenvolvedor os detalhes de persistˆencia inerentes ao RMS.
´
E um projeto 100% brasileiro, atualmente liderado por Priscila Lugon, Thiago Ros-sato e Thiago Le˜ao Moreira (LUGON; ROSSATO; MOREIRA, 2008). Surgiu em 2005 como trabalho de conclus˜ao de curso pela UFSC - Universidade Federal de Santa Catarina, por´em somente no segundo semestre de 2007 ´e que foi lan¸cada a primeira vers˜ao oficial, junto com o seu site (Floggy org, 2005). ´E distribu´ıdo sob a licen¸ca Apache 2.0, e pode ser utilizado sem custo em qualquer tipo de aplica¸c˜ao.
Framework: este m´odulo ´e respons´avel por fornecer ao desenvolvedor acesso `a API de persistˆencia de dados. O framework ´e representado por um arquivo que possui apenas 6kb. Este precisa ser empacotado junto com a aplica¸c˜ao.
Weaver: este m´odulo ´e respons´avel por analisar o c´odigo-fonte da aplica¸c˜ao e adicio-nar, por meio da altera¸c˜ao do bytecode, o c´odigo de persistˆencia `as classes identificadas como persistentes. Este processo ocorre entre a fase de compila¸c˜ao do c´odigo-fonte e a pr´e-verifica¸c˜ao das classes. Estes processos s˜ao apresentados na figura 10, que mostra de forma resumida, uma vis˜ao geral do funcionamento do Floggy.
Figura 10: Vis˜ao geral do funcionamento do Floggy. (LUGON; ROSSATO; MOREIRA, 2008, p.27)
No in´ıcio do processo, os arquivos-fontes s˜ao compilados (javac) e transformados em arquivos de classe (bytecode). Estes arquivos s˜ao analisados pelo m´odulo Weaver, que gera e adiciona, por meio de altera¸c˜ao do bytecode, o c´odigo de persistˆencia `as devidas classes, identificadas por uma interface de marca¸c˜ao cujo nome ´e “Persistable” e fica localizada no pacote net.source.floggy.persistence. Posteriormente, as classes passam pelo processo de pr´e-verifica¸c˜ao (preverify) e s˜ao empacotadas em um ´unico arquivo Java (.jar) junto com as bibliotecas necess´arias e o m´odulo Framework. No pr´oximo passo, o arquivo Java (.jar) ´e instalado e executado no dispositivo. Durante a execu¸c˜ao da aplica¸c˜ao, as opera¸c˜oes
de persistˆencia s˜ao gerenciadas pelo Floggy, que por sua vez utiliza os record stores para armazenar os objetos.
2.8.3
Acesso `
a rede
Poder desenvolver aplica¸c˜oes que fa¸cam uso da rede de dados ´e uma das principais motiva¸c˜oes de MIDP. Para facilitar o desenvolvimento desse tipo de aplica¸c˜ao, o mais natural seria utilizar as mesmas APIs j´a dispon´ıveis em Java SE no MIDP, mas isso n˜ao pode ser feito devido a natureza dos telefones celulares.
As redes de celular s˜ao inst´aveis e tamb´em v´arios modelos de celular n˜ao suportam TCP/IP7, apenas WAP8, enquanto que as APIs do Java.net partem do princ´ıpio que TCP/IP est´a sempre dispon´ıvel (PAULA, 2006, p.31). Para se adaptar a esse novo ambi-ente, o MIDP, definiu uma nova API para HTTP9 e tamb´em n˜ao obrigou os terminais a
suportarem sockets, apenas HTTP e HTTPS (o mesmo que HTTP, por´em com acr´escimo de criptografia) s˜ao obrigat´orios.
2.8.3.1 Servi¸cos remotos
Conex˜oes HTTP s˜ao estabelecidas a todo instante na internet, por´em o processo n˜ao se limita a criar conex˜oes. Ent˜ao ap´os a conex˜ao estabelecida, ´e necess´ario agora enviar um objeto para o servidor e receber os objetos de resposta. Usualmente em Java SE, isso ´e feito serializando os objetos (explicado no item 2.8.2 p´agina 37).
No entanto, n˜ao ´e poss´ıvel fazer o mesmo em Java ME, pois as classes respons´aveis por este papel n˜ao s˜ao implementadas na plataforma JME (PAULA, 2006, p.32). Uma solu¸c˜ao para este problema seria implementar uma estrutura de serializa¸c˜ao de objetos espec´ıfica para cada aplica¸c˜ao. Isso pode ser feito incluindo m´etodos para serializar e deserializar em cada classe de neg´ocio do sistema.
7O TCP/IP ´e um conjunto de protocolos de comunica¸c˜ao entre computadores em rede (tamb´em
chamado de pilha de protocolos TCP/IP). Seu nome vem de dois protocolos: o TCP (Transmission Control Protocol - Protocolo de Controle de Transmiss˜ao) e o IP (Internet Protocol - Protocolo de Interconex˜ao). Fonte: Wikip´edia.
8WAP (sigla para Wireless Application Protocol; em portuguˆes, Protocolo para Aplica¸c˜oes sem Fio)
´e um padr˜ao internacional para aplica¸c˜oes que utilizam comunica¸c˜oes de dados digitais sem fio (Internet m´ovel), como por exemplo o acesso `a Internet a partir de um telefone m´ovel. Fonte: Wikip´edia.
9O HyperText Transfer Protocol (ou o acrˆonimo HTTP; do inglˆes, Protocolo de Transferˆencia de
Hipertexto) ´e um protocolo de aplica¸c˜ao respons´avel pelo tratamento de pedidos e respostas entre cliente e servidor na World Wide Web. Fonte: Wikip´edia.
3
Levantamento de Requisitos
Para o desenvolvimento do trabalho foi feito um levantamento dos requisitos e an´alise das funcionalidades seguindo metodologias s´olidas da engenharia de software apresentadas no cap´ıtulo 2, definindo as caracter´ısticas que o sistema deve ter.
3.1
Requisitos Funcionais do Software
Ser˜ao apresentadas as principais caracter´ısticas deste software no que diz respeito a sua camada de neg´ocios, detalhando as funcionalidades que atingem diretamente a espectativa dos usu´arios deste sistema, que no caso, s˜ao os m´edicos veterin´arios que lidam com animais selvagens.
Este sistema ir´a interagir com uma base de dados alimentada por uma aplica¸c˜ao desktop, que estar´a funcionando na cl´ınica veterin´aria e que possui (em parte) o mesmo objetivo desta aplica¸c˜ao, tendo como diferencial a mobilidade.
Os principais requisitos funcionais s˜ao apresentados a seguir:
• Possibilidade de importar(persistir) os dados no dispositivo m´ovel;
• Possibilidade de listar grupos de esp´ecies de animais;
• Possibilidade de listar as esp´ecies de animais;
• Possibilidade de listar os medicamentos;
• Possibilidade de realizar a extrapola¸c˜ao alom´etrica de um determinado medica-mento;
• Possibilidade de realizar a convers˜ao da dose em miligramas para mililitros;
A op¸c˜ao de importa¸c˜ao dever´a persistir informa¸c˜oes do arquivo de dados, gerado a partir da aplica¸c˜ao desktop, no dispositivo m´ovel.
A op¸c˜ao de listar as esp´ecies visa a simples aferi¸c˜ao de quais esp´ecies est˜ao cadastradas no dispositivo e em que grupo de esp´ecies se encontram.
A op¸c˜ao de listar medicamentos visa a simples aferi¸c˜ao de quais medicamentos e suas informa¸c˜oes como dosagem, freq¨uˆencia e concentra¸c˜ao, est˜ao cadastrados no dispositivo.
A op¸c˜ao de extrapolar medicamento permite calcular dose e freq¨uˆencia, por meio da extrapola¸c˜ao alom´etrica, e descobrir qual a dose de um determinado medicamento e em que freq¨uˆencia deve ser administrado em um animal selvagem ou silvestre.
A op¸c˜ao de converter uma dose visa permitir que o veterin´ario em casos espec´ıficos posso ministrar uma dose em mililitros em animais que seria dif´ıcil a ingest˜ao de substˆ an-cias s´olidas.
A op¸c˜ao de limpar base de dados visa excluir todos os dados persistidos pela op¸c˜ao importar dados. Eventualmente ser´a utilizada para a realiza¸c˜ao de uma nova importa¸c˜ao com dados atualizados pela aplica¸c˜ao desktop.
3.2
Casos de Uso
Pode-se dizer que um caso de uso ´e um “documento narrativo que descreve a seq¨uencia de eventos de um ator que usa um sistema para completar um processo” (JACOBSON,
1992).
Um caso de uso ´e uma t´ecnica de modelagem usada para descrever o que um novo sis-tema deve fazer. Ele ´e constru´ıdo atrav´es de um processo interativo no qual as discuss˜oes entre o cliente e os desenvolvedores do sistema conduzem a uma especifica¸c˜ao do sistema da qual todos est˜ao de acordo.
Os casos de usam tˆem por objetivo:
• Decidir e descrever os requisitos funcionais do sistema;
• Fornecer uma descri¸c˜ao clara e consistente do que o sistema deve fazer;
• Permitir descobrir os requisitos funcionais das classes e opera¸c˜oes do sistema;
Como j´a informado no cap´ıtulo anterior, a UML ser´a utilizada para demonstrar as modelagens do sistema, para uma melhor compreens˜ao de suas fun¸c˜oes e caracter´ısticas.
Na UML o modelo de casos de uso consiste de diagramas de casos de uso que mostram os atores, os casos de uso e seus relacionamentos.
Na figura 11 temos o diagrama de casos de uso da aplica¸c˜ao. Observe que temos a proje¸c˜ao dos requisitos funcionais da aplica¸c˜ao de forma clara e de f´acil compreens˜ao de nossos fornecedores de requisitos.
Figura 11: Diagrama de casos de uso
3.2.1
Descri¸
c˜
ao do Ator
Ator Veterin´ario: ´E respons´avel por executar as tarefas gerais do sistema, como ex-trapolar um f´armaco, importar dados ou converter dosagens.
3.2.2
Descri¸
c˜
ao dos Casos de Uso
A descri¸c˜ao dos casos de usos apresenta uma forma simples de expor as funcionali-dades de um sistema computacional, assim como o diagrama de casos de uso da UML, concedendo ao cliente a oportunidade de ter maior grau de certeza e compreens˜ao ao validar as fun¸c˜oes desejadas por ele para um sistema de informa¸c˜ao. E tamb´em permite um melhor aproveitamento de tempo nas fases de projeto, implementa¸c˜ao e testes visto que as regras de neg´ocio estar˜ao sempre `a disposi¸c˜ao da equipe desenvolvedora atrav´es dos documentos espec´ıficos de cada caso de uso.
Segue agora a descri¸c˜ao dos casos de uso vistos no diagrama apresentado na figura 11, conforme a seguinte ordem:
1. UC01 - Importar dados;
2. UC02 - Limpar base de dados;
3. UC03 - Listar esp´ecies;
4. UC04 - Listar grupos de esp´ecies;
5. UC05 - Listar medicamentos;
6. UC06 - Extrapolar medicamento;
UC01-IMPORTAR DADOS
Sumario: Ator realiza a importa¸c˜ao de dados atualizados pela aplica¸c˜ao desktop para o dispositivo m´ovel.
Ator: Veterin´ario.
Pr´e-condi¸c˜oes: O usu´ario ter baixado o arquivo de atualiza¸c˜ao no site do projeto. Risco: M´edio.
Prioridade: Alta. 1. Fluxo B´asico:
1.1. O ator escolhe a op¸c˜ao importar dados. 1.2. O sistema solicita a chave de seguran¸ca. 1.3. O ator informa a chave de seguran¸ca.
1.4. O sistema exibe mensagem de confirma¸c˜ao informando que todos os dados ser˜ao sobrescritos.
1.5. O ator confirma a mensagem.
1.6. O sistema exibe mensagem de sucesso. 1.7. O ator confirma a mensagem.
2. Fluxos alternativos: (A1) - Base j´a atualizada.
2.1 Caso o arquivo de atualiza¸c˜ao j´a tenha sido persistido no dispositivo ser´a emitida uma mensagem de aviso informando que todos os dados ser˜ao sobrescritos.
2.2. O ator confirma mensagem. 2.3. O sistema realiza a opera¸c˜ao. 2.4. Este caso de uso se encerra. (A2) - Nega¸c˜ao de sobrescrita.
2.5. Caso o ator n˜ao confirme a mensagem de sobrescrita, retorna a tela inicial da aplica¸c˜ao.
2.6. Este caso de uso se encerra. - Fluxo de exce¸c˜oes
-(E1) - Inexistˆencia do Arquivo de atualiza¸c˜ao.
2.7. Caso n˜ao exista o arquivo de atualiza¸c˜ao, ser´a emitida uma mensagem de erro informando. O processo ´e totalmente desfeito.
(E2) - Chave de seguran¸ca inv´alida.
2.8. Caso a chave de seguran¸ca digitada seja inv´alida, ´e exibida uma mensagem de erro informando.
2.9. Retorna a tela inicial da aplica¸c˜ao. 2.10. Retorna a tela inicial da aplica¸c˜ao.
(E2) - Inconsistˆencia no Arquivo de atualiza¸c˜ao.
2.11. Caso exista inconsistˆencia no arquivo de atualiza¸c˜ao, ser´a emitida uma mensagem de erro informando. O processo ´e totalmente desfeito.
2.12. Retorna a tela inicial da aplica¸c˜ao.
P´os-condi¸c˜ao: Base de dados atual persistida no dispositivo m´ovel. Tabela 2: Descri¸c˜ao UC01 - Importar Dados
UC02-LIMPAR BASE DE DADOS
Sumario: Ator realiza a exclus˜ao definitiva de todos os dados armazenados no dispositivo m´ovel.
Ator: Veterin´ario.
Pr´e-condi¸c˜oes: n˜ao se aplica.
Risco: M´edio. — Prioridade: Baixa. 1. Fluxo B´asico:
1.1. O ator escolhe a op¸c˜ao Limpar base. 1.2. O sistema solicita a chave de seguran¸ca. 1.3. O ator informa a chave de seguran¸ca. 1.4. O sistema exibe mensagem de confirma¸c˜ao. 1.5. O ator confirma a mensagem.
1.6. O sistema exibe mensagem de sucesso. 1.7. O ator confirma a mensagem.
1.8. Este caso de uso se encerra. 2. Fluxos alternativos: - Fluxo de exce¸c˜oes
-(E1) - Chave de seguran¸ca inv´alida.
2.3. Caso a chave de seguran¸ca digitada seja inv´alida, ´e exibida uma mensagem de erro informando.
2.4. Retorna a tela inicial da aplica¸c˜ao.
P´os-condi¸c˜ao: Base do dispositivo m´ovel totalmente esvaziada. Tabela 3: Descri¸c˜ao UC02 - Limpar base de dados UC03 - LISTAR ESP´ECIES
Sumario: Ator realiza a consulta das esp´ecies de animais armazenadas no dispositivo m´ovel.
Ator: Veterin´ario.
Pr´e-condi¸c˜oes: n˜ao se aplica.
Risco: Baixo. — Prioridade: M´edia. 1. Fluxo B´asico:
1.1. O ator escolhe a op¸c˜ao Listar esp´ecies.
1.2. O sistema exibe a listagem de todas as esp´ecies armazenadas no dispositivo m´ovel.
1.3. O ator visualiza a lista. 1.4. Este caso de uso se encerra. 2. Fluxos alternativos: - Fluxo de exce¸c˜oes
-(E1) - Inexistˆencia de esp´ecies para listar.
2.3. Caso n˜ao exista esp´ecies a serem listadas, ser´a emitida uma mensagem de erro informando.
2.4. Retorna a tela inicial da aplica¸c˜ao.
P´os-condi¸c˜ao: Lista de todas as esp´ecies armazenadas no dispositivo m´ovel consultada.
UC04-LISTAR GRUPOS DE ESP´ECIES
Sumario: Ator realiza a consulta dos grupos de esp´ecies de animais armazenadas no dispositivo m´ovel.
Ator: Veterin´ario.
Pr´e-condi¸c˜oes: n˜ao se aplica. Risco: Baixo.
Prioridade: M´edia. 1. Fluxo B´asico:
1.1. O ator escolhe a op¸c˜ao listar grupos de esp´ecies.
1.2. O sistema exibe a listagem de todos os grupos de esp´ecies armazenadas no dispositivo m´ovel.
1.3. O ator visualiza a lista. 1.4. Este caso de uso se encerra. 2. Fluxos alternativos: - Fluxo de exce¸c˜oes
-(E1) - Inexistˆencia de grupos de esp´ecies para listar.
2.3. Caso n˜ao existam grupos de esp´ecies a serem listadas, ser´a emitida uma mensagem de erro informando.
2.4. Retorna a tela inicial da aplica¸c˜ao.
P´os-condi¸c˜ao: Lista de todos os grupos de esp´ecies armazenadas no dispositivo m´ovel consultada.
Tabela 5: Descri¸c˜ao UC04 - Listar grupos de esp´ecies UC05-LISTAR MEDICAMENTOS
Sumario: Ator realiza a consulta de todos os medicamentos armazenadas no dispositivo m´ovel.
Ator: Veterin´ario.
Pr´e-condi¸c˜oes: n˜ao se aplica. Risco: Baixo.
Prioridade: M´edia. 1. Fluxo B´asico:
1.1. O ator escolhe a op¸c˜ao listar medicamentos.
1.2. O sistema exibe a listagem de todos os medicamentos armazenadas no dispositivo m´ovel.
1.3. O ator visualiza a lista. 1.4. Este caso de uso se encerra. 2. Fluxos alternativos: - Fluxo de exce¸c˜oes
-(E1) - Inexistˆencia de medicamentos para listar.
2.3. Caso n˜ao existam medicamentos a serem listados, ser´a emitida uma mensagem de erro informando.
2.4. Retorna a tela inicial da aplica¸c˜ao.
P´os-condi¸c˜ao: Lista de todos os medicamentos armazenadas no dispositivo m´ovel consultada.
