implementação de gráficos para análise do perfil - DAINF

UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ
DEPARTAMENTO ACADÊMICO DE INFORMÁTICA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
ANDRESSA CAROLINE PORTES DA CUNHA
MELINA DERALDO DOS SANTOS
IMPLEMENTAÇÃO DE GRÁFICOS PARA ANÁLISE DO PERFIL
EPIDEMIOLÓGICO DE IDOSOS INSTITUCIONALIZADOS EM
CURITIBA
MONOGRAFIA
CURITIBA
2010
II
ANDRESSA CAROLINE PORTES DA CUNHA
MELINA DERALDO DOS SANTOS
IMPLEMENTAÇÃO DE GRÁFICOS PARA ANÁLISE DO PERFIL
EPIDEMIOLÓGICO DE IDOSOS INSTITUCIONALIZADOS EM
CURITIBA
Monografia
Metodologia
apresentada
de
à
Pesquisa
disciplina
do
curso
de
de
Bacharelado em Sistemas de Informação como
requisito parcial para a obtenção de nota.
Orientador: Prof. Dr. Laudelino Cordeiro Bastos
CURITIBA
2010
III
Este trabalho está licenciado sob uma Licença Creative Commons AtribuiçãoUso Não-Comercial-Vedada a Criação de Obras Derivadas 2.5 Brasil. Para ver
uma cópia desta licença, visite http://creativecommons.org/licenses/by-ncnd/2.5/br/ ou envie uma carta para Creative Commons, 171 Second Street,
Suite 300, San Francisco, Califórnia 94105, USA.
IV
LISTA DE FIGURAS
Figura 1 – EXEMPLO GRÁFICO DE GANTT...........................................................19
Figura 2 – ELEMENTOS DO DIAGRAMA DE CASOS DE USO .............................20
Figura 3 – EXEMPLO DE UMA CLASSE DO DIAGRAMA DE CLASSES .............21
Figura
4
–
EXEMPLO
DE
UMA
TABELA
DO
DIAGRAMA
ENTIDADE
REALACIONAMENTO .............................................................................................22
Figura 5 – DIAGRAMA DE CASOS DE USO............................................................38
Figura 6 – DIAGRAMA ENTIDADE RELACIONAMENTO.....................................39
Figura 7 – DIAGRAMA DE CLASSES ......................................................................40
Figura 8 – REPRESENTAÇÃO DA TABELA “INSTITUICAO” NO ORACLE DATABASE
10g EDITION .............................................................................................................61
Figura 9 – TELA INICIAL..........................................................................................61
Figura 10 – ENTIDADES SELECIONADAS .............................................................62
Figura 11 – IDOSO x INSTITUIÇÃO .........................................................................63
Figura 12 – TELA DO GRÁFICO ...............................................................................64
V
LISTA DE GRÁFICOS
Gráfico 1 – GRÁFICO DE GANTT ............................................................................36
Gráfico 2 – BURNDOWN CHART INICIAL .............................................................37
Gráfico 3 – BURNDOWN CHART PARCIAL ...........................................................58
Gráfico 4 – BURNDOWN CHART INICIAL REAVALIADO ...................................59
Gráfico 5 – BURNDOWN CHART FINAL ................................................................60
VI
LISTA DE QUADROS
Quadro 1 – EXEMPLO DE CRONOGRAMA.............................................................18
Quadro 2 – CRONOGRAMA DE ATIVIDADES .......................................................34
VII
LISTA DE TABELAS
Tabela 1 – TIPOS DA LINGUAGEM JAVA ..............................................................25
Tabela 2 – COMPONENTES GRÁFICOS DA INTERFACE......................................27
Tabela 3 – CLASSIFICAÇÃO DOS ARTIGOS DE ACORDO COM O GRAU DE
IMPORTÂNCIA .........................................................................................................30
Tabela 4 – CLASSIFICAÇÃO DOS ARTIGOS DE ACORDO COM A ABORDAGEM DE
PESQUISA .................................................................................................................32
Tabela 5 – DATAS PREVISTAS x DATAS REAIS....................................................56
Tabela 6 – OPÇÕES DA TELA INICIAL ...................................................................62
Tabela 6 – OPÇÕES DA SEGUNDA TELA ...............................................................63
VIII
LISTA DE ABREVIATURAS E SIGLAS
DER
Diagrama Entidade Relacionamento
ILPI
Instituição de Longa Permanência para Idosos
GUI
Interface Gráfica com o Usuário (Graphical User Interface)
MER
Modelo Entidade Relacionamento
SGBD
Sistema Gerenciador de Banco de Dados
SQL
Structured Query Language
UML
Unified Modeling Language
IX
SUMÁRIO
1 INTRODUÇÃO ......................................................................................................11
1.1 Título ......................................................................................................11
1.2 Tema .......................................................................................................11
1.3 Problema .................................................................................................11
1.4 Objeto .....................................................................................................11
1.5 Justificativa .............................................................................................11
1.6 Motivação ...............................................................................................12
1.7 Objetivos.................................................................................................12
1.7.1 Objetivo geral..................................................................................12
1.7.2 Objetivo específico..........................................................................12
1.8 Metodologia ............................................................................................13
1.8.1 Métodos .........................................................................................13
1.9 Estrutura do trabalho ...............................................................................13
2 REVISÃO BIBLIOGRÁFICA...............................................................................15
2.1 Informática em Saúde..............................................................................15
2.2 Processo de Software ...............................................................................16
2.2.1 Planejamento de Software ................................................................18
2.2.1.1 Cronograma e Gráfico de Gantt............................................18
2.2.2 Modelagem do Sistema ....................................................................19
2.2.2.1 Casos de Uso........................................................................20
2.2.2.2 Diagramas de Classes...........................................................21
2.2.2.3 Diagramas Entidade Relacionamento ...................................22
2.2.3 Implementação.................................................................................23
2.2.3.1 Linguagem de Programação Java .........................................23
2.2.3.2 Banco de Dados ...................................................................28
2.2.4 Javadoc ............................................................................................29
2.3 Metodologia da Revisão Bibliográfica .....................................................29
2.4 Resultados e Discussões ..........................................................................30
2.5 Conclusão................................................................................................32
X
3 DESENVOLVIMENTO DA PROPOSTA..............................................................34
3.1 Planejamento de Projeto ..........................................................................34
3.2 Modelagem do Sistema ............................................................................37
3.2.1 Diagrama de Casos de Uso...............................................................37
3.2.2 Diagrama Entidade Relacionamento.................................................38
3.2.3 Diagrama de Classes ........................................................................40
3.3 Implementação ........................................................................................40
3.3.1 Classes de auxílio.............................................................................41
3.3.2 Classes de controle...........................................................................42
3.3.2.1 Classe Ouvinte .....................................................................42
3.3.2.2 Classe ComandosSQL ..........................................................45
3.3.2.3 Classe ConexãoBanco ..........................................................51
3.3.2.4 Classe TelaGráfico................................................................53
4 RESULTADOS E ANÁLISE ..................................................................................56
4.1 Planejamento do Projeto ..........................................................................56
4.1.1 Cronograma e Gráfico de Gantt........................................................56
4.1.2 Burndown Chart...............................................................................58
4.2 Implementação ........................................................................................60
5 CONCLUSÕES E TRABALHOS FUTUROS ......................................................65
6 REFERÊNCIAS BIBLIOGRÁFICAS...................................................................67
7 APÊNDICES ..........................................................................................................71
11
1 INTRODUÇÃO
1.1 Título
Implementação de gráficos para análise do perfil epidemiológico de idosos
institucionalizados em Curitiba.
1.2 Tema
Aplicação de técnicas computacionais tais como o acesso a banco de dados e criação
de interface gráfica na área de gerontologia.
1.3 Problema
Regina Ribas Bueno Pinto (2008), em sua dissertação de mestrado, traçou o perfil
epidemiológico de idosos residentes em casas de longa permanência na cidade de Curitiba,
levantando informações necessárias e armazenando-as em um banco de dados. No entanto,
persiste a ausência de uma estrutura que permita ao usuário visualizar, de modo mais simples
e prático, os dados obtidos, pois, até então, apenas uma consulta direta ao banco de dados
possibilita visualizá-los.
1.4 Objeto
O software que, a partir da seleção de dois atributos referentes aos idosos, é
responsável por resgatar dados em um banco de dados e plotar gráficos.
1.5 Justificativa
Facilitar a atividade dos profissionais que utilizam dados relacionados ao perfil
12
epidemiológico dos idosos, a partir da aplicação de conhecimentos computacionais, tais como
programação utilizando linguagem Java e banco de dados, proporcionando a visualização
gráfica dos dados referentes ao perfil. Desta forma, elimina-se a necessidade dos usuários
aprenderem a manusear ferramentas de banco de dados.
1.6 Motivação
A abrangência da Informática em Saúde, a qual proporciona diversas áreas de estudo
e aplicação, e a inexistência de um software que facilite a interação do usuário com os dados
relativos ao perfil epidemiológico de idosos institucionalizados.
1.7 Objetivos
1.7.1 Objetivo geral
Aperfeiçoar e facilitar a visualização, através de gráficos, das análises dos dados de um
estudo sobre o perfil epidemiológico de idosos residentes em instituições de longa
permanência para idosos na cidade de Curitiba.
1.7.2 Objetivos específicos

Gerar um gráfico de acompanhamento das atividades a serem desenvolvidas
(Burndown Chart) e um cronograma;

Confeccionar diagrama entidade relacionamento (DER);

Instanciar os dados previamente coletados em um banco de dados;

Implementar uma classe que permita realizar consultas dinâmicas ao banco de dados;

Apresentar dados em forma de gráficos.
13
1.8 Metodologia
1.8.1 Métodos
Descrição sequencial do processo de desenvolvimento deste trabalho e definição das
ferramentas de auxílio empregadas. Durante a escolha destas tornou-se imprescindível o fato
de estarem sob a licença de código aberto (open source), definido por OPEN SOURCE
INITIATIVE (04 abr. 2010), como “um método de desenvolvimento de software que se baseia
(…) na transparência do processo”. Isto não significa apenas ter o acesso ao código fonte, mas
acatar alguns critérios, como: redistribuição livre, código fonte incluso, trabalhos derivados
(admitir alterações e trabalhos derivados e autorizar suas distribuições sob os mesmos termos
da licença do software original), integridade do código fonte do autor código (a licença
permite exigir nome ou número diferente para trabalho derivado), distribuição da licença (a
todos a quem o programa é redistribuído, deve-se aplicar os direitos tidos pelo software
original), entre outros (Open Source Initiative, 2010).
1.9 Estrutura do trabalho
O presente trabalho explora, em seus capítulos, uma pesquisa sobre o
desenvolvimento de gráficos em linguagem Java utilizando os dados - instanciados em um
banco de dados - relativos a um perfil epidemiológico de idosos. O primeiro capítulo, a
introdução, está divido de forma a permitir uma melhor visualização do objetivo, problema,
tema, motivação, objeto de estudo e justificativa da pesquisa proposta e a metodologia, a qual
indica quais as ferramentas e como estas deverão ser utilizadas para atingir o objetivo
proposto.
Na Revisão Bibliográfica, segundo capítulo, é apresentada uma descrição
aprofundada do problema previamente definido, a partir de consultas a materiais referentes à
Informática em Saúde, a fim de localizar os pontos críticos que necessitem de uma solução,
além de conceituar o procedimento necessário para o processo de desenvolvimento de um
software.
O capítulo seguinte, Desenvolvimento da Proposta, descreve detalhadamente como
foi concretizada cada etapa necessária à elaboração do software desde o planejamento,
diagramas e especificações, até a implementação das classes que originam o artefato. Em
14
Resultados e Análises, quarto capítulo, são exibidos os dados, informações e consequências
obtidos a partir da aplicação dos métodos adotados, e ainda sua análise de acordo com as
informações abordadas na revisão bibliográfica.
O quinto capítulo, Conclusões e Trabalhos Futuros, compara os resultados obtidos
com os planejados e propõe novas pesquisas na área de Informática em Saúde. Por fim,
Referência Bibliográfica é o capítulo que contém a relação das obras consultadas para a
confecção deste trabalho.
15
2 REVISÃO BIBLIOGRÁFICA
2.1 Informática em Saúde
Blois e Shortliffe (Sociedade Brasileira de Informática em Saúde, 2010) afirmam
que, para aperfeiçoar o armazenamento, recuperação e gerenciamento de informações na área
da saúde, a qual requer informações para a tomada de decisões, existe um campo científico
específico, a Informática em Saúde. De acordo com a Sociedade Brasileira de Infomática em
Saúde (2010), devido “(…) aos avanços nas tecnologias de computação e comunicação, à
crescente convicção de que o conhecimento médico e as informações sobre os pacientes são
ingerenciáveis por métodos tradicionais baseados em papel, e devido à certeza de que os
processos de acesso ao conhecimento e tomada de decisão desempenham papel central na
Medicina moderna”, a Informática em Saúde como disciplina vem se expandindo
consideravelmente.
Desta forma, percebe-se a necessidade de que profissionais da saúde desenvolvam
habilidades as quais permitam ao usuário interagir com ferramentas computacionais que
ofereçam suporte à área médica (LUIS et al., 1995), destacando-se: recuperação e análise de
dados provenientes de bancos de dados, design de banco de dados e tecnologias da web
(LOGAN; PRICE, 2004).
Uma das áreas de atuação da Informática Médica, uma especialidade da Informática
em Saúde, diz respeito aos sistemas de registro médico computadorizado, isto é, ao
desenvolvimento de prontuários eletrônicos (FILHO; XAVIER; ADRIANO, 2001). De acordo
com Filho, Xavier e Adriano (2001, p. 105), a “combinação de computadores, redes de
telecomunicações, informações médicas e dados eletrônicos de pacientes pode melhorar a
qualidade do cuidado com a saúde, da produtividade dos profissionais da saúde, facilitar o
acesso aos serviços disponíveis e reduzir custos administrativos associados à prestação de
serviços”. Desta forma, o prontuário eletrônico minimiza os erros consequentes de uma
prescrição médica mal formulada (BLOMBERG et al., 2009). Dentre as funções do prontuário
eletrônico, destaca-se o suporte à pesquisa, que pode ser: clínica, epidemiológica, para
avaliação da qualidade e pós marketing de observação de medicamentos (UNIFESP Virtual,
2010).
Parte da medicina que trata das epidemias - doenças contagiosas que rapidamente
atacam diversas pessoas de uma mesma região - (XIMENES, 2000), a epidemiologia possui
16
como objeto de interesse de pesquisa um grupo que está em constante crescimento: a
população de terceira idade ou idosos, caracterizada por indivíduos que possuem faixa etária
igual ou superior a 60 anos. No Brasil, a parcela de idosos aumentou praticamente quatro
milhões quando comparada ao ano de 1991. Atualmente, a população de idosos representa
8,6% de um total de 170 milhões de brasileiros, segundo o Censo 2000, realizado pelo
Instituto Brasileiro de Geografia e Estatística. Aliado ao crescimento desta classe está o
aumento da expectativa de vida, que era de 66,03 anos em 1991 e passou a ser 68,55 anos em
2000 (PINTO, 2008).
Os cuidados de longa duração voltados aos idosos com algum nível de dificuldade
para realizar as atividades de rotina e/ou aqueles cuja família é desfavorecida de recursos
financeiros, físicos ou emocionais para atender as necessidades de seu ente, são umas das
novas solicitações que vêm sendo efetuadas ao setor público (DANILOW et al., 2007). De
acordo com a Portaria SEAS nº 2874/2000, Instituições de Longa Permanência para Idosos
(ILPI) (DANILOW et al., 2007) podem oferecer o suporte familiar, financeiro e psicológico
que o idoso necessita (REIS et al., 2005).
A escassez e a importância de informações relativas a idosos institucionalizados
motivaram pesquisas direcionadas a traçar um perfil epidemiológico que contenha dados
concretos em termos de sexo, idade, renda, condições de vida e saúde, enfermidades,
medicamentos utilizados, laços familiares e tempo de permanência na instituição (DANILOW
et al., 2007). Para o desenvolvimento, os pesquisadores selecionaram ILPIs e elaboraram
questionários que, aliados à consulta dos prontuários dos idosos, serviram de fonte para obter
os dados da construção do perfil (DANILOW et al., 2007; PINTO, 2007; SILVA et al., ano).
Estas pesquisas visam contribuir para a criação de programas de atividades preventivas e
terapêuticas (SILVA et al.).
2.2 Processo de software
A elaboração de um software, processo caracterizado por englobar procedimentos
que necessitam de uma visão simultânea e integrada de aspectos técnicos e gerenciais, é uma
tarefa que não deve ser confundida com desenvolver programas para o computador.
(REZENDE, 1997). Para criar o software, é interessante assumir uma metodologia que aborde
este processo por meio de suas etapas (REZENDE, 1997). O Ciclo de Vida de Sistemas
Tradicionais, a mais antiga metodologia de construção de sistemas de informação, subdivide o
17
desenvolvimento de um sistema em blocos formais de estágios, propondo um início, um meio
e um fim (LAUDON, 1999).
Rezende (1997, p. 25) expõe as seguintes etapas do Ciclo de Vida de Sistemas
Tradicionais:

Estudo: sugere reconhecer as atuais deficiências através de entrevista aos
usuários, visando identificar quais aspectos do ambiente estão inadequados, além de definir
objetivos do novo sistema e aprontar o plano de trabalho detalhado (REZENDE, 1997).

Análise de Sistemas: buscando converter as duas entradas principais - a política
do usuário e os encargos do projeto - em uma especificação organizada do projeto, esta etapa
abarca a modelagem do ambiente do usuário. Para isto, elabora-se o modelo indicativo do que
o sistema deve fazer para interagir de forma satisfatória com o ambiente externo, o que inclui
os diagramas e especificações (REZENDE, 1997).

Projeto: Fisher (1990, p. 8) afirma que esta fase mostra “o que construir e como
construir”. Há preocupação com a elaboração de uma adequada hierarquia de módulos de
‘programas’ e interfaces entre estes, para que a especificação detalhada na fase anterior possa
ser implementada (REZENDE, 1997). Fisher (1990, p. 8) conclui que a etapa de projeto
abrange “a decomposição em módulos, definições de estruturas de dados (…) e importantes
definições algorítmicas” (FISHER, 1990, p. 8).

Implementação: segundo Rezende (1997, p. 29), este estágio “inclui a
codificação e a integração dos módulos em um esqueleto”. A codificação é feita a partir da
eleição de uma linguagem de programação conveniente. Ainda nesta etapa ocorre o teste do
esqueleto do sistema, executando o teste do módulo e a integração do sistema (REZENDE,
1997).

Geração do Teste de Aceite: um grupo de casos de testes de aceite é
confeccionado com base na especificação estruturada. Estes testes podem ser de vias normais
- confirmam se o sistema faz, de fato, o esperado para entradas válidas – ou então de vias de
erro - buscam “enganar” o sistema com dados incorretos ou não usuais (REZENDE, 1997).

Garantia da Qualidade: é o teste de aceite, momento em que se observa a
satisfação do usuário no que diz respeito ao atendimento das expectativas (REZENDE, 1997).

Descrição de Procedimentos: descrição da forma com que os usuários irão
interagir com a parte informatizada do novo sistema, isto é, as definições das atividades
operacionais do usuário. Normalmente correspondem ao Manual do Usuário (REZENDE,
1997).
18

Instalação. Atividade final, cujas entradas são o manual do usuário e o sistema
de aceite (REZENDE, 1997).
2.2.1 Planejamento de software
Sommerville (2007, p. 63) afirma que “o gerenciamento de um projeto depende de
um planejamento minucioso do progresso do projeto”. No início do desenvolvimento de um
software deve ser criado um plano que estime estrutura, tamanho, distribuição das funções e o
tempo. Este servirá como um guia à produção do software (SOMERVILLE, 2007).
2.2.1.1 Cronograma e Gráfico de Gantt
O cronograma do projeto determinado no início do processo – como exemplifica o
Quadro 1 – contém a estimativa das tarefas a serem realizadas dentro do espaço de tempo
previsto (PRESSMAN, 1995). As tarefas devem ser separadas cuidadosamente e organizadas
em sequência coerente (SOMERVILLE, 2007). A análise do problema e a especificação,
primeiras tarefas a serem realizadas, auxiliam na definição das atividades que deverão ser
executadas ao longo do processo de criação do projeto e o tempo gasto com cada uma delas
(PRESSMAN, 1995).
Atividades
Data de Início
Data de Término
Atividade 1
10/09/2005
11/10/2005
Atividade 2
15/09/2005
24/09/2010
Quadro 1: Exemplo de Cronograma
Fonte: Autoria Própria
O gráfico de Gantt, ou diagrama de barras, é uma notação gráfica para ilustrar o
cronograma do projeto evidenciando as datas de início e fim do mesmo, como exemplificado
na Figura 1. Auxilia na visualização das atividades paralelas e nas interdependências entre
elas, isto é, aquelas que dependem da finalização de uma tarefa para serem inicializadas
(SOMERVILLE, 2007). Para a produção do gráfico de Gantt relativo ao planejamento das
19
atividades que constituem o presente trabalho, será utilizado o software GanttProject, que está
licenciado sobre um série de licenças de código aberto (Learn GanttProject, 2010).
Figura 1: Exemplo Gráfico de Gantt
Fonte: Autoria Própria
2.2.2 Modelagem do Sistema
Ao construir imóveis, aeronaves, automóveis e até mesmo computadores, torna-se
necessária a elaboração de modelos. Estes servem para detalhar o planejamento a fim de
melhorar a compreensão do que será produzido e auxiliar no gerenciamento do projeto
(RUMBAUGH, 1994).
No desenvolvimento de softwares, a preparação de modelos também possui
fundamental importância para atingir eficiência com o mínimo de desperdício e retrabalho de
software possível (BOOCH; RUMBAUGH; JACOBSON, 2000). Ela fornece uma abstração examina determinados aspectos - capaz de informar os detalhes que compõem o projeto. Para
Booch, Rumbaugh e Jacobson (2000, p. 7) “qualquer projeto será beneficiado pelo uso de
algum tipo de modelagem. (...) A modelagem poderá auxiliar a equipe de desenvolvimento a
visualizar melhor o planejamento do sistema e permitir que o desenvolvimento seja mais
rápido ajudando a construir o item correto”.
A modelagem de um sistema tem por objetivo auxiliar na visualização de como
deverá atuar o software, especificar a estrutura ou o comportamento dele, elaborar um guia de
construção e servir como documentação das decisões (BOOCH; RUMBAUGH; JACOBSON,
2000).
O modelo deverá apresentar uma visão panorâmica do sistema, a fim de facilitar o
20
entendimento de sua complexidade, e ainda possibilitar sua divisão em níveis visando tratar
cada parte separadamente. Evitando, desta forma, ocultar detalhes importantes à edificação do
sistema (BOOCH; RUMBAUGH; JACOBSON, 2000).
Para auxiliar na construção de modelos existe uma linguagem específica, a UML
(Unified Modeling Language). Esta se torna apropriada para demonstrar as funcionalidades de
um sistema em termos de visualização, especificação, construção e documentação (BOOCH;
RUMBAUGH; JACOBSON, 2000).
2.2.2.1 Casos de uso
Com a finalidade de apresentar, durante as fases iniciais de um projeto, os serviços
que um sistema deverá fornecer, o diagrama de casos de uso, que faz parte da UML,
(STADZISZ, 2010) tenta registrar as aplicações nas quais o sistema será empregado, definindo
os requisitos do sistema.
Manifesta, através de atores, as entidades externas - aquelas que interagem
diretamente com o sistema. Os atores podem ser pessoas, softwares, dispositivos ou hardware.
O diagrama ainda descreve cada aplicação do sistema especificando os casos de uso,
responsáveis por representar a interface externa do sistema e todas as transações que unidas
expressam as funcionalidades do sistema (STADZISZ, 2010). A Figura 2 apresenta a forma
como devem ser representados atores, relações e casos de uso em um diagrama de casos de
uso.
Figura 2: Elementos do diagrama de casos de uso
Fonte: Autoria Própria
O diagrama de casos de uso também representa as relações presentes entre atoresatores, casos de uso-atores e casos de uso-casos de uso. As relações entre os atores são
atividades realizadas externamente ao sistema, no entanto as efetuadas entre atores e casos de
uso procedem através de comunicações (trocas de mensagens), pois os atores não possuem
21
conexão direta à estrutura do sistema (STADZISZ, 2010).
Entre casos de uso existem três tipos de relacionamento: os de inclusão, nos quais um
caso de uso agrega outro caso de uso; os de extensão, definido quando um caso de uso menor
necessita, através de uma condição, utilizar serviços de um caso de uso maior; e os de
generalização, que representam um caso de uso que possui funções específicas, mas que
descende de um caso genérico que pode ser aplicado a várias situações (STADZISZ, 2010).
2.2.2.2 Diagramas de Classes
Para a demonstração de um conjunto de classes, interfaces e os relacionamentos que
persistem entre eles, é utilizado o diagrama de classes. Ele é importante não somente para a
visualização, especificação e documentação dos modelos estruturais, como também para
produzir sistemas através da engenharia de produção reversa, a qual “transforma um modelo
em código pelo mapeamento de uma linguagem de implementação” (BOOCH; RUMBAUGH;
JACOBSON, 2000).
As classes são a descrição, de modo genérico, de atributos e comportamentos comuns
para entidades reais, estabelecendo um modelo uniforme para a representação de entidades
semelhantes. Quando as entidades recebem valores específicos para seus atributos, passam a
ser retratadas por objetos (STADZISZ, 2010).
Na UML, as classes são representadas por retângulos com três partições (Figura 3), a
primeira referente à identificação, contendo o nome, o estereótipo (classificador para indicar o
tipo de classe - interface ou controle) e até o pacote do qual faz parte. A segunda partição
discrimina os atributos das classes, a terceira e última apresenta os métodos que pertencem à
classe (STADZISZ, 2010).
Figura 3: Exemplo de uma classe do diagrama de classes
Fonte: Autoria Própria
O diagrama de classes ainda evidência os relacionamentos existentes entre as classes,
sendo que estes podem ser de associação, agregação e generalização. As associações são os
relacionamentos mais comuns, as quais permitem que os objetos de uma determinada classe
22
possam se comunicar com objetos de outras classes. A agregação inclui objetos de uma classe
dentro de objetos de outras classes, isto é, um objeto da classe1 passa a fazer parte do objeto
da classe2. O relacionamento de generalização ocorre quando existe a derivação de uma classe
base, isto é, uma especialização de uma classe mais genérica, para a criação da subclasse que
irá incorporar todos os atributos e métodos da classe mãe e ainda adicionar novos
(STADZISZ, 2010).
2.2.2.3 Diagrama Entidade Relacionamento
O Diagrama Entidade Relacionamento (DER) é a projeção gráfica de uma
modelagem conceitual denominada Modelo Entidade Relacionamento (MER). Guimarães
(2003, p.32) afirma que o MER exprime “os diversos tipos de dados requeridos pela
aplicação, os seus inter-relacionamentos e algumas regras de consistência” sem detalhar a
implementação da base de dados. O DER é constituído por entidades e relacionamentos
(GUIMARÃES, 2003).
As entidades, apresentadas em forma de retângulo, manifestam os objetos ou entes
do mundo real que serão registradas na base de dados. Possuem propriedades específicas
denominadas atributos, os quais têm um nome e valor específico para a entidade
(GUIMARÃES, 2003). Um exemplo da representação de entidades pode ser verificado na
Figura 4.
Figura 4: Exemplo de tabela do diagrama entidade relacionamento
Fonte: Autoria Própria
Os relacionamentos, representados por losangos, são as associações entre uma
entidade e outra, definindo a interdependência entre elas. Eles possuem como características a
cardinalidade ou multiplicidade, a qual indica o número de ocorrências em um
relacionamento, como por exemplo: um funcionário pode pertencer somente a um
23
departamento (1:1), porém um departamento pode ter vários funcionários (1:N)
(GUIMARÃES, 2003).
A ferramenta de código aberto, ERDesigner NG, auxilia na construção do diagrama
entidade relacionamento e será utilizada durante a produção do diagrama referente as
entidades e relacionamentos que compõem o presente trabalho (Project Mongwai best of
breed Open Source, 2010).
2.2.3 Implementação
Visando a tradução da especificação do projeto em alguma forma que o computador
possa traduzir em linguagem de máquina, uma linguagem convencional de programação deve
ser utilizada (PRESSMAN, 1995). Pressman (1995, p. 677) declara que linguagens de
programação “são veículos de comunicação entre os seres humanos e os computadores”. O
mesmo autor ainda afirma que alguns critérios podem ser empregados a fim de auxiliar na
escolha da linguagem de programação para um projeto específico, dentre os quais se
destacam: “a área de aplicação geral, a complexidade computacional e algorítmica, o ambiente
em que o software será executado, considerações de desempenho, o conhecimento da equipe
de desenvolvimento de software” (PRESSMAN, 1995, p. 685).
2.2.3.1 Linguagem de Programação Java
Dentre as linguagens de programação, ressalta-se a linguagem orientada a objetos
Java, projetada especificamente para permitir que desenvolvedores de aplicativos escrevessem
um programa uma vez e depois fossem capazes de executá-lo em qualquer parte na Internet
(The Java Language Specification, 2010).
Um objeto pode ser descrito como um bloco independente de código de computador,
caracterizado por descrever entidades que podem ser concretas ou abstratas (LAUDON;
LAUDON, 1999). Laudon (1999, p. 108) afirma que “cada objeto é uma coleção encapsulada
de dados e operações executadas sobre esses dados”. Esses blocos podem ser utilizados em
muitos sistemas diferentes sem a necessidade de alterar o código do programa (LAUDON;
LAUDON, 1999).
24
De acordo com Deitel (2003, p. 59), a linguagem Java pode ser utilizada “para criar
páginas da Web com conteúdo interativo e dinâmico, para desenvolver aplicativos
corporativos de grande porte, para aprimorar a funcionalidade de servidores da World Wide
Web (…), fornecer aplicativos para dispositivos destinados ao consumidor final e para muitas
outras finalidades”.
Os programas em linguagem Java são constituídos por membros chamados classes
(DEITEL; DEITEL, 2003), responsáveis por especificar um ou mais objetos do mesmo tipo
(ZIVIANI, 2006). Para criar um objeto, é necessário determinar seu tipo e referenciá-lo, isto é,
identificar a qual classe pertence e apelidá-lo, respectivamente, e então criá-lo a partir do
operador new (LINHARES, 2009). Segue um exemplo:
nome_da_classe nome_da_referencia = new nome_da_classe( );
Cada classe possui atributos, os quais definem as características que todos os objetos
pertencentes àquela classe possuem (BOENTE, 2003), além dos métodos, compostos por um
conjunto de instruções – cada uma finalizada por um ponto e vírgula – que definem como este
deve ser executado (BASHAM; SIERRA; BATES, 2005). A sintaxe para declaração de
classes em linguagem Java é a seguinte:
acesso class nomedaclasse
{
//atributos e métodos
}
Onde acesso indica a visibilidade da classe (pública ou sem valor), class indica que é
uma classe e nomedaclasse representa seu nome. “atributos e métodos” é um trecho que não
será compilado, visto que está precedido por duas barras, o que significa que corresponde a
um comentário (BASHAM; SIERRA; BATES, 2005). Os atributos são definidos por meio da
declaração de variáveis, como indica o exemplo:
acesso tipo nome;
Onde acesso define a visibilidade do atributo, tipo indica o que o atributo representa
e nome é a forma de identificar atributo (LINHARES, 2009). A seguir, a tabela 1 – Tipos da
Linguagem Java – demonstra alguns tipos comumente utilizados na linguagem Java para a
declaração de variáveis (BASHAM; SIERRA; BATES, 2005):
25
Tabela 1 - Tipos da Linguagem Java
Tipo
Descrição
Booleano
Verdadeiro ou Falso
Char
Caracteres
Int
Números Inteiros
Double
Números Reais
Array
Vetor de
Variável
Tamanho
Fonte: Autoria Própria.
A definição de métodos ocorre declarando-se o tipo de acesso, o qual define a
visibilidade do método, o tipo de retorno que o método irá fornecer, devendo este ser um tipo
existente na linguagem Java ou void quando não há valor de retorno, o nome do método e,
entre parênteses, os parâmetros, isto é, os dados de entrada que o método precisa para
funcionar, descritos por tipo e nome e separados entre vírgulas (LINHARES, 2009). Uma
melhor visualização pode ser obtida no exemplo a seguir:
acesso tipoderetorno nome (tipo1 p1, tipo2 p2,..., tipoN pN)
{
//código do método
//instrução de retorno
}
Conforme citado, classes, atributos e métodos devem ter seu acesso definido.
Determinar o acesso significa indicar que alguns membros poderão estar visíveis ou não
(neste caso estão encapsulados) a outras classes (LINHARES, 2009). Se o acesso é private, o
membro em questão só é acessível pelos métodos da própria classe no qual foi definido, ao
contrário do acesso public, o qual indica que o membro é acessível por outras classes
(LINHARES, 2009).
Dois métodos destacam-se, sendo um deles o main(), utilizado a fim de que o
programa seja executado, visto que este é o responsável por dar início ao processo
(BASHAM; SIERRA; BATES, 2005), e o outro chamado construtora, o qual é requerido pelo
sistema no momento em que ser cria um objeto (BOENTE, 2003). Este método não possui
valor de retorno (BOENTE, 2003), e pode ter fundamental importância para deixar o objeto
26
pronto para uso no momento em que é criado (LINHARES, 2009). Em Java, a construtora
possui exatamente o mesmo nome da sua classe e é executada no momento em que o objeto é
criado por meio do operador new (LINHARES, 2009).
Existe situações em que pode não ser conceitualmente interessante criar objetos a
partir de uma classe, e para isso, podem-se definir métodos de classe (LINHARES, 2009).
Esses métodos independem da existência de um objeto para serem executados, e podem ser
declarados com a utilização do modificador static:
acesso static tipoderetorno nome
No que diz respeito às classes, a classe de Exceção destaca-se por definir situações de
erro que podem ser localizadas durante a execução do programa (BOENTE, 2003). Para evitar
que o programa finalize devido ao erro, pode-se criar um código para tratar a exceção e desta
forma continuar a execução do programa (BOENTE, 2003). Para isto, pode-se fazer uso das
declarações try e catch, onde a primeira contém o trecho do código no qual poderá ocorrer
uma exceção, enquanto que catch recebe o código que irá manipular a exceção caso esta
venha a ocorrer (BOENTE, 2003).
Dentre os modos dos objetos se relacionarem em um sistema orientado a objetos,
ressalta-se a relação de associação, diferenciada pelo fato de que determinados objetos podem
ter acesso aos métodos de outros objetos. Para isto, se faz necessário que, dentre os atributos
da classe que terá acesso aos outros métodos, seja declarada uma referência para o objeto da
classe com a qual se deseja relacionar (LINHARES, 2009). No que diz respeito ao
relacionamento entre classes, destaque para a herança, a qual possibilita que uma classe utilize
as definições existentes em outra classe sem a necessidade de reescrevê-la (BOENTE, 2003) e
ainda possa adicionar características próprias (LINHARES, 2009). Em Java, a relação de
herança é descrita utilizando a palavra extends no cabeçalho da classe que irá empregar
características de outra classe (a qual está definida no exemplo abaixo como B) e ainda
adicionar suas próprias:
class D extends B
Buscando evitar que o programador tenha necessidade de desenvolver cada pedaço
que será útil na construção de um programa em Java, existem preciosas coleções de classes
denominadas bibliotecas de classes Java, fornecidas tanto por distribuidores de compiladores
quanto por fornecedores independentes de software (DEITEL; DEITEL, 2003). Para serem
utilizados, os pacotes devem ser importados a partir da declaração (BOENTE, 2003):
import NomeDoPacote.NomeDaClasse;
27
Para serem executados, os programas em Java normalmente atravessam cinco fases:
edição, compilação, carga, verificação e execução. A edição, concretizada a partir da
utilização de um programa editor, visa editar um arquivo, isto é, gerar um código fonte
(BOENTE, 2003). Ambientes de Desenvolvimento Integrado (IDEs) Java têm editores
embutidos integrados de forma transparente ao ambiente de programação. Na compilação,
segunda fase, o compilador exprime o programa Java no formato de bytecodes - a linguagem
que o interpretador Java compreende (DEITEL; DEITEL, 2003).
A carga, terceira parte, carrega o programa na memória antes que o mesmo seja
executado. A penúltima etapa, verificação, permite que os bytecodes sejam verificados pelo
verificador de bytecodes, o qual garante a validade dos mesmos e a não violação das restrições
de segurança de Java. Por fim, a execução possibilita que o computador, controlado pela CPU,
interprete o programa e realize a ação especificada (DEITEL; DEITEL, 2003).
Tendo em vista a implementação do software, neste trabalho será utilizado o IDE
NetBeans, de código-fonte aberto, o qual permite desenvolver aplicativos para desktop e Web
em linguagem Java, C/C++, PHP, JavaScript, Groovy e Ruby (Welcome to NetBeans, 2010).
A biblioteca JFreeChart será utilizada para auxiliar na elaboração dos gráficos.
Distribuída sob os termos da licença GNU (GNU Lesser General Public Licence), permite o
desenvolvimento de gráficos de qualidade profissional. Possui uma grande variedade de tipos
de gráficos e suporta vários tipos de saída, tais como componentes Swing do Java, arquivos de
imagem, entre outros (VIKLUND, 2010).
Ainda serão empregadas as bibliotecas Swing e Awt para possibilitar a interação entre
o usuário e o software por meio de interfaces gráficas com o usuário (GUI’s). Esta forma de
interface utiliza botões, ícones, barras e boxes – dispostos em janelas (JFrame) – para
representar operações comuns, o que explica a facilidade no manuseio (LAUDON; LAUDON,
1999). A tabela 2 – Componentes Gráficos da Interface – aponta os componentes que serão
utilizados nas GUIs do presente trabalho (JAVA 2 PLATFORM SE 5.0, 2010):
Tabela 2 - Componentes Gráficos da Interface
Componente
Definição
Button
Botão de clique.
ComboBox
Possui um botão e uma
lista. O usuário pode
selecionar um valor a
partir dessa lista.
28
Fonte: Autoria Própria.
Os componentes da interface gráfica Java aguardam a ocorrência de algum evento
externo e então reagem a esse evento de acordo com a instrução programada, o que significa
dizer que o funcionamento da API gráfica Java é orientado a eventos (LINHARES, 2009).
Quando ocorre um evento, um método especial, actionPerformed, deve ser acionado para que
trate o evento do modo adequado (JAVA 2 PLATFORM SE 5.0, 2010).
2.2.3.2 Banco de Dados
A fim de utilizar os dados com eficácia, é importante organizá-los e estruturá-los,
buscando manter agrupados aqueles que recaem em informações semelhantes. Dentre as
formas existentes de gerenciamento e armazenamento de dados, está o banco de dados,
definido por Laudon (1999, p. 126) como “uma coleção de dados organizados de tal forma
que possam ser acessados e utilizados por muitas aplicações diferentes”.
O Sistema Gerenciador de Banco de Dados (SGBD) é um software responsável por
possibilitar que os dados sejam armazenados em um só lugar, tornando-os disponíveis para
aplicações divergentes. Serve como interface entre o banco de dados comum e diversos
programas aplicativos (LAUDON; LAUDON, 1999). O primeiro SGBD comercial surgiu no
ano de 1960, baseado nos arcaicos sistemas de arquivos existentes na época (TAKAI;
ITALIANO; FERREIRA, 2005). Dentre as vantagens dos sistemas de gerenciamento de
banco de dados estão (LAUDON; LAUDON, 1999):
 Independência dos dados em relação aos programas aplicativos;
 Redução da inconsistência e redundância dos dados;
 Informações com acesso e uso facilitado.
A linguagem de manipulação de dados, componente dos sistemas de gerenciamento
de banco de dados, é responsável por manipular banco de dados, dispondo de recursos que
permitem ao usuário extrair dados do banco de dados, satisfazer solicitações de informações e
desenvolver aplicações. Atualmente, a mais importante linguagem de manipulação de dados é
a Structured Query Language (SQL) (LAUDON; LAUDON, 1999), a qual combina
construtores em álgebra e cálculo relacional. (TAKAI; ITALIANO; FERREIRA, 2005).
Dentre os quatro modelos de banco de dados existentes – modelo hierárquico,
modelo em redes, modelo relacional e modelo orientado a objetos - (TAKAI; ITALIANO;
29
FERREIRA, 2005), destaca-se o relacional, o qual se caracteriza por aumentar a autonomia
dos dados nos SGBDs e fornecer um grupo de funções baseadas na álgebra relacional a fim de
armazenar e recuperar os dados (TAKAI; ITALIANO; FERREIRA, 2005).
Como o próprio nome aponta, o modelo descrito acima é fundamentado na relação tabela. Estas são representadas por uma ou mais colunas, chamadas atributos, responsáveis por
traduzir o tipo de dados a armazenar, e por linhas, nomeadas t-uplas (TAKAI; ITALIANO;
FERREIRA, 2005). A vantagem desse modelo é o fato de que um elemento de uma tabela
pode ser relacionado a qualquer outro em uma tabela diferente, desde que ambas
compartilhem um elemento de dado comum (LAUDON; LAUDON, 1999).
Para fins de armazenamento dos dados utilizados no presente trabalho, a ferramenta
adotada será o Oracle Database 10g Express Edition (Oracle Database XE), uma versão de
banco de dados - cujo código é livre para o desenvolvimento - baseado no código do Oracle
10g Release. Utiliza a linguagem SQL (Structured Query Language) e é uma ferramenta
simples de administrar (Oracle, 2010).
Buscando vincular o software desenvolvido em linguagem Java com o banco de
dados do Oracle Express, será empregada a biblioteca Java Database Connectivity (JDBC).
Ela permite que se estabeleça uma integração com um banco de dados, envio de instruções
SQL
e
o
processamento
dos
resultados
(JDBC
–
Oracle
Wiki.,
2010).
2.2.4 Javadoc
Ferramenta utilizada a fim de elaborar a documentação de pacotes, classes, atributos
e métodos Java em formato HTML, partindo do processamento do código fonte com
comentários em formato adequado (RICARTE, 2010).
2.3 Metodologia da Revisão Bibliográfica
Com o intuito de obter conhecimento sobre a área onde o tema de estudo será
aplicado, foi realizada uma investigação em base de dados de bibliotecas virtuais. Para isto,
foram consultadas as bibliotecas virtuais do SciELo Brasil (http://www.scielo.br), LILACS,
indexado
na
base
de
dados
da
Biblioteca
Virtual
em
Saúde
(BVS
-
http://bvsms.saude.gov.br/php/index.php) e PubMed (http://www.pubmed.com). Também
30
foram examinados os periódicos da Coordenação de Aperfeiçoamento Pessoal de Nível
Superior (CAPES - http://www.capes.gov.br/): International Journal of Medical Informatics;
Artificial Intelligence in Medicine; SAGE Journals Online. Ainda os congressos da Sociedade
Brasileira de Informática em Saúde (SBIS - http://www.sbis.org.br/).
Visando delimitar os materiais a serem pesquisados, foi determinado um grupo de
palavras chaves para efetuar as buscas. As seguintes palavras: asilo, banco de dados, database,
epidemiológico, gráfico, idoso, informática, informática médica, instituição permanência,
instituições, Java, linguagem Java, old, prontuário eletrônico, prontuário computadorizado,
prontuários, registro eletrônico de paciente, saúde, sistema, sistemas computadorizados. Estas
foram inseridas individualmente ou combinadas entre si, cada combinação contendo no
máximo três elementos.
Ao término das consultas foram coletados 40 (quarenta) artigos, os quais sofreram
uma leitura exploratória a fim de agrupá-los de acordo com sua abordagem e classificá-los por
grau importância, recebendo valor: cinco - muita importância e maior relevância para o tema , quatro - importantes -, três – poderiam servir de apoio -, dois – baixa relevância ao tema - e
um - não se enquadram ao tema.
Para conceituar termos utilizados no processo de desenvolvimento do objeto, foram
examinados livros relacionados a tópicos tais como: algoritmos, banco de dados, engenharia
de software, linguagem Java, lógica para computação, entre outros. Wazlawick (2008, p. 28)
defende que “os livros normalmente contêm informação mais completa, didática e bem
amadurecida”, fato que serve de motivação ao uso desta fonte bibliográfica para obter
informações que já estão consolidadas (WAZLAWICK, 2008).
2.4 Resultados e Discussões
A Tabela 3 aponta os 40 artigos angariados distribuídos segundo a classificação que
lhes foi atribuída.
Tabela 3 - Classificação dos artigos de acordo com o grau de importância.
Grau de Importância Número de Artigos
Cinco
3
Porcentagem (%)
10
31
Quatro
16
37,5
Três
11
27,5
Dois
9
22,5
Um
1
2,5
40
100
Total
Fonte: Autoria Própria
Aqueles que receberam valoração um ou dois foram descartados do grupo de artigos
de real importância por motivo de não contribuírem diretamente para o aprofundamento do
tema da pesquisa.
Os artigos agrupados no conjunto de Informática em Saúde receberam valor três na
sua classificação pelo fato de servirem como base para a compreensão da área. Porém,
aqueles que possuem relação com temas tais como perfil epidemiológico, instituições de
longa permanência, banco de dados, em meio a outros, receberam valoração quatro ou cinco.
Características como: banco de dados, linguagem Java e prontuários eletrônicos
presentes nos artigos, justificaram a sua avaliação como grau de importância quatro. Este
grupo destaca-se por assessorar a construção do objeto de estudo.
Artigos cuja abrangência refere-se ao perfil epidemiológico de idosos ou a
instituições de longa permanência para idosos foram avaliados como os de maior
proeminência (valor cinco). Considerando ambos os grupos, dois artigos (DANILOW et al.,
2007; SILVA et al.) obtiveram destaque pelo fato de serem análogos à dissertação de mestrado
realizada por Regina Bueno Ribas Pinto, a qual serve de base à concepção do presente
trabalho.
Percebe-se que, dentre os três artigos, todos os questionários foram validados por
especialistas na área. Apenas um (DANILOW et al., 2007) aplicou o questionário diretamente
aos idosos como forma de obter os dados para análise e tratamento, enquanto os outros dois
(PINTO, 2008; SILVA et al.) preferiram que os responsáveis pelos idosos preenchessem o
conjunto de perguntas. Para armazenamento dos dados, dois optaram pelo uso de banco de
dados (Oracle Express Edition 10g e Access) (PINTO, 2008; SILVA et al.), ao passo que o
outro escolheu utilizar o Microsof Excel 2000 Premium (DANILOW et al., 2007).
A Tabela 4 apresenta os números e porcentagens de artigos que constituem cada
32
bloco de abordagem semelhante. Deve-se observar que um mesmo artigo pode ser
enquadrado em mais de uma abordagem de pesquisa.
Tabela 4 - Classificação dos artigos de acordo com a abordagem de pesquisa.
Abordagem de
Número de
Porcentagem
Pesquisa
Artigos
(%)
Informática em Saúde
8
20
Doenças e Qualidade de Vida
4
10
Domínio da Informática por Profissionais da Saúde
3
7,5
Dificuldades dos Idosos
1
2,5
Quedas de Idosos
3
7,5
Perfil Epidemiológico de Idosos
7
17,5
Instituições de Longa Permanência para Idosos
10
25
Prontuários Eletrônicos
7
17,5
Banco de dados (relacionados às pesquisas em informática em
6
15
1
2,5
saúde)
Java (relacionada às pesquisas em informática em saúde)
Fonte: Autoria Própria
O nome do autor, título, nome do periódico onde foi publicado, a base de dados e as
palavras chaves utilizadas na pesquisa, além dos itens que aborda e a classificação de cada
artigo podem ser visualizados no Apêndice A.
2.5 Conclusão
No decurso da pesquisa sobre Informática em Saúde, verificou-se a importância de
informações para tomada de decisões na área da saúde. Buscando proporcionar dados mais
confiáveis e precisos, vem crescendo o uso da informática nesta especialidade. Devido a isso,
constatou-se a necessidade de que profissionais deste meio possuam aptidão para manusear
33
ferramentas computacionais de apoio à área.
Tentando promover o desenvolvimento desta habilidade, o profissional da
computação deve produzir aplicações simples e de fácil compreensão, para que a
informatização não seja vista como empecilho, mas como uma ferramenta que proporcione
enriquecimentos e favoreça o crescimento no campo da saúde.
34
3 DESENVOLVIMENTO DA PROPOSTA
Para o desenvolvimento do presente trabalho, em primeiro momento, foi realizado
um estudo para tomar conhecimento do problema proposto e estabelecer metas e objetivos.
Desta forma tornou-se possível dividir o processo em três etapas a fim de que o mesmo
pudesse ser concluído dentro do limite imposto pela disciplina Metodologia de Pesquisa. As
fases denominadas planejamento de projeto, modelagem do sistema e implementação serão
descritas nas seções deste capítulo.
3.1 Planejamento de Projeto
A fim de criar um plano para definir as atividades a serem realizadas ao longo do
processo de desenvolvimento deste projeto, elaborou-se um Cronograma – Quadro 2 –, o qual
especifica cada atividade a ser desempenhada.
Data de início
Data limite
Código
Atividades
10/03/2010
17/03/2010
01
Elaborar pré-projeto.
10/03/2010
16/05/2010
02
Pesquisar conteúdo da revisão.
05/04/2010
09/04/2010
03
Estudar DER e relações entre tabelas.
05/04/2010
09/04/2010
04
Estudar biblioteca SQL e plotagem de
gráficos.
28/03/2010
16/05/2010
05
Desenvolver a monografia.
26/04/2010
07/05/2010
06
Implementar classes para leitura dinâmica dos
dados.
07/05/10
19/05/2010
07
Implementar classes para gerar os gráficos.
19/05/2010
21/05/2010
08
Rever monografia.
Quadro 2 – Cronograma de Atividades
Fonte: Autoria Própria
A atividade de código 01, elaborar pré-projeto, baseou-se na primeira pesquisa sobre
o problema proposto com intuito de definir o tema a ser abordado no projeto. A tarefa a
serguir, de código 02, consistiu em realizar um levantamento bibliográfico através de
pesquisas em bases de dados de bibliotecas virtuais, processo este detalhado no capítulo 2,
35
item 2.3.
O estudo do DER e das relações entre tabelas - já definidas no trabalho de
PINTO(2008) -, código 03, propôs-se a compreender as tabelas e suas relações. Neste estágio,
observou-se a vasta possibilidade de combinações existentes para gerar os gráficos, visto que
existem doze (12) tabelas e que uma grande parte dos atributos de uma tabela poderia se
relacionar com atributos de outra tabela para a confecção do gráfico. Desta forma, foram
selecionadas apenas as tabelas “Instituição” e “Idoso” e somente alguns de seus atributos
(“Tipo” e “Sexo, Idade aparente, País nascimento, Estado civil, Número de filhos, Cor,
Escolaridade, Aposentado, Tipo convênio, Outras Instituições, Meses de institucionalização,
Aceitação
instituição,
Escolha
institucionalização,
Motivo
institucionalização”,
respectivamente) para gerar os gráficos.
Em sequência, as tarefas, estudar biblioteca SQL e plotagem de gráficos (código 04),
dedicaram-se ao entendimento das bibliotecas JDBC e JFreeChart (capítulo 2, itens 2.2.3.2 e
2.2.3.1, respectivamente), o que permitiu analisar as funcionalidades que essas bibliotecas
disponibilizam e quais seriam aplicadas na implementação. Assim, durante este período,
decidiu-se que o sistema produziria somente gráficos de colunas (utilizados com maior
frequência para realizar comparações entre grupos, neste caso entre atributos) devido a sua
implementação apresentar-se mais simples.
A tarefa desenvolver monografia – código 05 – consolidou-se em estruturar toda a
pesquisa realizada e os procedimentos adotados para a construção do artefato sugerido no
princípio deste projeto.
A sexta atividade (código 06), implementar classes para leitura dinâmica de dados, é
definida pela construção da classe responsável por realizar a ligação entre a base de dados o
código fonte do software. E a tarefa de código 07, implementar classes para gerar os gráficos,
é a que produz a classe utilizada para a recepção de dados que compõem o gráfico e plotagem
de gráfico em uma interface. Rever monografia (código 08), última atividade, consiste em
revisar e complementar, dentro do possível, o conteúdo já registrado na monografia.
A definição do cronograma possibilitou a criação do gráfico de Gantt (Gráfico 1), o
qual permite melhorar a visualização de início e término das atividades já descritas.
36
Gráfico 1 – Gráfico de Gantt
Fonte: Autoria Própria
37
Em conjunto com a elaboração do cronograma e gráfico de Gantt, realizou-se
também a criação do Burndown Chart inicial (Gráfico 2), o qual, considerando as atividades a
serem desempenhadas e o prazo para entrega final do projeto, previu 85 horas necessárias
para a execução deste trabalho dentro de um período de 60 dias.
Gráfico 2 – BurnDown Chart Inicial
Fonte: Autoria Própria.
3.2 Modelagem do Sistema
Esta etapa caracterizou-se por criar um modelo, através dos padrões de modelagem
descritos no capítulo 2, item 2.2.2, para detalhar o artefato a ser construído, buscando
minimizar as falhas no decorrer do desenvolvimento do software.
3.2.1 Diagrama de Casos de Uso
Para exemplificar a maneira como o sistema deve ser utilizado, o diagrama de casos
de uso a seguir (Figura 5) demonstra que o usuário – o qual tende a pertencer ao grupo dos
38
profissionais da saúde – deverá escolher alguns dos atributos disponíveis no sistema para que,
a partir da verificação dos dados selecionados e da consulta ao banco de dados, a relação entre
os atributos escolhidos seja exibida em forma gráfica.
Figura 5: Diagrama de Casos de Uso.
Fonte: Autoria Própria.
3.2.2 Diagrama Entidade Relacionamento
O diagrama de entidade relacionamento desenvolvido, o qual pode ser verificado na
Figura 6, consistiu em uma alteração realizada na tabela “Instituição” do diagrama já proposto
por PINTO (2008). A entidade “Instituicao” recebeu mais seis atributos: “nome_instituicao”,
“logradouro”, “complemento”, “numero”, “bairro”, e “NR” (número), os quais serviram para
melhorar a identificação da mesma.
39
Figura 6: Diagrama Entidade Relacionamento.
Fonte: Autoria Própria.
Como durante a atividade de código 03, apresentada no cronograma (Quadro 2), foi
estipulada a utilização de somente duas tabelas - “Instituição” e “Idoso” –, o conteúdo
presente nas demais tabelas não será apresentado neste trabalho e seus dados não serão
instanciados no banco de dados.
Analisando o DER, é possível perceber que para um idoso fazer parte do conjunto de
idosos, é necessário que a instituição na qual ele resida esteja contida na tabela “Instituicao”.
Todas as entidades, com exceção da “Instituicao”, possuem o par “cod_instituicao,
cod_idoso” (representa o código da instituição que o idoso pertence e o código do idoso,
respectivamente), o qual é utilizado para buscar uma t-upla específica e, portanto nunca deve
ocorrer sua repetição na mesma tabela. Além disso, se um par fizer parte da tabela “Ortese”,
“Renda”,
“Medicamentos”,
“Habitos_vida”,
“Visita_semanal”,
“Queixas”,
40
“Diagnostico_medico”, “Acomodacoes”, “Atividades” ou “Queda” deve, obrigatoriamente,
referenciar um par já existente em “Idoso”.
O conceito explicado acima será utilizado para realizar a busca na base de dados
quando um usuário desejar gerar um gráfico relacionando atributos de tabelas distintas.
3.2.3 Diagrama de Classes
O diagrama de classe apresentado na Figura 7 serviu de apoio para a implementação
do software. Sua construção após a execução da atividade de código 04 e da modelagem do
sistema permitiu definir quais classes seriam necessárias para a construção do sistema e a
relação existente entre cada uma delas.
Figura 7: Diagrama de Classes.
Fonte: Autoria Própria.
3.3 Implementação
Tendo findado as etapas de modelagem, deu-se início à fase de implementação
(capítulo 2 item 2.2.3), na qual todos os detalhes do modelo projetado foram traduzidos, por
41
meio da linguagem Java (capítulo 2, item 2.2.3.1), para uma forma entendível pelo
computador, visando construir o software. Durante a elaboração do código fonte percebeu-se
que a versão atual do NetBeans IDE (6.8) não localizava, no seu diretório de bibliotecas, os
pacotes referentes a biblioteca JFreeChart, tornando-se necessário utilizar a versão 5.5 do
NetBeans IDE, visto que esta identifica a biblioteca para geração de gráficos. O presente
capítulo descreve as classes que compõem o software, apresentando o código fonte somente
das classes consideradas com maior grau de importância. Para visualizar o código fonte de
todas as classes, consultar CD em anexo.
Logo após o desenvolvimento da implementação tornou-se admissível gerar o
Javadoc (capítulo 2, item 2.2.4) como forma de documentação do código fonte, além da
produção do manual do usuário (capítulo 2, item 2.2), o qual descreve a forma de interação
entre o usuário e o software. Este pode ser consultado no CD em anexo.
3.3.1 Classes de auxílio
Nesta seção serão apresentadas as classes de apoio para a implementação,
caracterizadas por não exercerem função de controle no sistema. A primeira classe,
projetoidoso, é responsável por inicializar o programa, isto é, contém o método main().
Tela1 é a classe que constrói uma interface gráfica, permitindo que o usuário indique,
entre as alternativas disponíveis, duas tabelas dentre as quais deseja construir uma relação.
Essa classe é uma especialização da classe JFrame, e possui dois ComboBox e um Button
como elementos. Cada ComboBox contém o nome de todas as tabelas pertencentes ao banco
de dados, e o Button denominado “OK” permite que a Tela2 se torne visível. Além disso, a
classe possui um objeto que referencia a classe Ouvinte, definida no item 4.2, responsável por
identificar ações realizadas no Button “OK”.
A classe Tela2, herdada de JFrame, estabelece uma interface gráfica que possibilita a
escolha de dois atributos que serão comparados no gráfico. Possui como componentes dois
ComboBox, cujos itens são carregados por meio de um objeto da classe ConexaoBanco, sendo
que o primeiro é composto pelo nome de cada campo presente em uma das tabelas
selecionadas na tela anterior, e o segundo é composto pelo nome de cada campo existente na
outra tabela. Além disso, está incluso o Button “Gerar Gráfico”, responsável por inicializar a
TelaGrafico, o qual está associado a um objeto que referencia a classe ouvinte.
Existem ainda as classes TratamentoString, a qual manipula um string recebido para
42
que fique no formato adequado para sua utilização, e DadosGrafico, caracterizado por reunir
os atributos da entidade gráfico (quantidade, legendaBaixo e legendaBarra) em um único
objeto. Essas classes não serão descritas minuciosamente, visto que servem apenas de apoio
às outras classes.
3.3.2 Classes de controle
Os códigos fonte apresentados abaixo detalham o modo como funcionam as classes
encarregadas por efetuar as ações que definem o funcionamento do sistema.
3.3.2.1 Classe Ouvinte
A classe Ouvinte, responsável por tratar os eventos sofridos pelos botões do sistema,
possui os seguintes atributos:
public JComboBox j1, j2;.
A construtora dessa classe recebe como parâmetro dois ComboBox e inicializa cada
atributo com cada ComboBox recebido.
public Ouvinte (JComboBox jCombo1, JComboBox jCombo2)
{
j1 = jCombo1;
j2 = jCombo2;
}
O método actionPerformed é responsável por identificar a origem de um evento –
que no caso deste software pode ser o Button “OK” ou o Button “Gerar Gráfico” – recebido
como atributo. Independente da fonte do evento, os itens selecionados em cada ComboBox
recebido pela construtora serão captados. Caso a origem seja identificada como proveniente
do Button “OK”, os itens selecionados serão enviados à classe ComandosSQL para dar valor
aos atributos tabela1 e tabela2 e a Tela2 será inicializada. Porém, se a origem do evento
estiver relacionada ao Button “Gerar Gráfico”, os itens seletos, desde que estejam entre os
passíveis de gerar gráfico, serão enviados à classe ComandosSQL para dar valor aos atributos
atributo1 e atributo2 e a TelaGrafico será inicializada. O código fonte da classe Ouvinte pode
ser visualizado a seguir:
class Ouvinte implements ActionListener
43
{
// atributos
public JComboBox j1, j2;
// construtora
public Ouvinte (JComboBox jCombo1, JComboBox jCombo2)
{
j1 = jCombo1;
j2 = jCombo2;
}
public void actionPerformed(ActionEvent e)
{
// origem é o Button que irá receber a fonte do evento
JButton origem = (JButton)(e.getSource());
// Compara a origem recebida com o Button “OK”
if(origem.getText().equals("OK")){
// Se pelo menos um dos itens selecionados nos ComboBox recebidos for
igual
//a vazio, isto é, não houver nada selecionado
if (j1.getSelectedItem().equals("")||j2.getSelectedItem().equals(""))
{
// mensagem de erro
JOptionPane.showMessageDialog(null,"Selecione dois itens!", "ERRO",
0);
return;
}
// se os dois itens forem diferentes de vazio
else{
// se um item selecionado for igual ao outro
if(j1.getSelectedItem().equals(""+j2.getSelectedItem()))
{
// mensagem de erro
JOptionPane.showMessageDialog(null, "Selecione itens diferentes!",
"ERRO", 0);
j1.setSelectedIndex(0);
j2.setSelectedIndex(0);
return;
}
// se um item for diferente do outro
else
{
// Registra o nome das tabelas escolhidas, após estas passarem por
//um processo de tratamento que retira os acentos, para utilizar depois
ComandosSQL.setTabela1(TratamentoString.getEliminarAcentos(""+j1.getSelectedItem()));
ComandosSQL.setTabela2(TratamentoString.getEliminarAcentos(""+j2.getSelectedItem()));
//Carrega a nova janela
Tela2 t2 = new Tela2();
t2.setVisible(true);
}
}
44
}
// Compara a origem recebida com o Button “Gerar Gráfico”
if(origem.getText().equals("Gerar Gráfico")){
// Se pelo menos um dos itens selecionados nos ComboBox recebidos for
// igual a vazio, isto é, não houver nada selecionado
if (j1.getSelectedItem().equals("")||j2.getSelectedItem().equals(""))
{
// mensagem de erro
JOptionPane.showMessageDialog(null,"Selecione dois itens!",
"ERRO", 0);
return;
}
// se os dois itens forem diferentes de vazio
else
// Se pelo menos um item selecionado for igual a um dos atributos que não
//fazem parte do/grupo de atributos com os quais é possível gerar gráfico
{
if(j1.getSelectedItem().equals("DATA
NASCIMENTO")||j1.getSelectedItem().equals("MUNICIPIO NASCIMENTO")||
j1.getSelectedItem().equals("ESTADO
NASCIMENTO")||j1.getSelectedItem().equals("RACA")||j1.getSelectedItem().equals
("PROFISSAO")|| j1.getSelectedItem().equals("PROCEDÊNCIA")||
j2.getSelectedItem().equals("DATA NASCIMENTO")||j2.getSelectedItem().equals
("MUNICIPIO NASCIMENTO")|| j2.getSelectedItem().equals("ESTADO
NASCIMENTO")||j2.getSelectedItem().equals("RACA")||j2.getSelectedItem().equals
("PROFISSAO")|| j2.getSelectedItem().equals("PROCEDÊNCIA"))
{
//mensagem de erro
JOptionPane.showMessageDialog(null, "Opção indisponível!",
"ERRO", 0);
j1.setSelectedIndex(0);
j2.setSelectedIndex(0);
return;
}
//se ambos itens selecionados estiverem no grupo dos atributos com os
//quais é possível elaborar gráficos
else{
// Registra os atributos selecionados.
ComandosSQL.setAtributo1(TratamentoString.getColocarCaracteresEspeciais
(""+j1.getSelectedItem()));
ComandosSQL.setAtributo2(TratamentoString.getColocarCaracteresEspeciais
(""+j2.getSelectedItem()));
// Carrega a nova tela
new TelaGrafico().setVisible(true);
}
}
}
}
}
45
Desta forma, quando ocorrer uma ação em qualquer um dos botões do sistema
Projeto Idoso, a classe Ouvinte irá tratá-la de acordo com o que foi apresentado a cima. A fim
de mostrar outra funcionalidade do sistema, a próxima seção refere-se à classe que estabelece
os comandos que serão realizados no banco de dados.
3.3.2.2 Classe ComandosSQL
Responsável por deter os dados e comandos que serão utilizados durante a busca no
banco de dados, a classe ComandosSQL possui como atributos:
static String tabela1, tabela2, atributo1, atributo2, comando;.
Existem métodos que dão valores aos atributos tabela1, tabela2, atributo1 e
atributo2, além de outros métodos que retornam os valores dessas mesmas variáveis quando
solicitados. O método getTipos recebe o nome da tabela e o respectivo atributo como
parâmetro e retorna o conjunto de opções de busca ao banco de dados que o par oferece. O
retorno deste método é utilizado por outro método, getResultadoBusca, o qual estabelece uma
conexão com o banco de dados e realiza quantas buscas sejam necessárias ao mesmo para
satisfazer todas as opções de busca que o par indicou. Este método retorna um array
redimensionável do tipo DadosGrafico, o qual contém os dados necessários para que, mais
tarde, seja possível gerar o gráfico. O código do método getTipos não está inteiramente
desenvolvido visto que não serão utilizadas todas as tabelas para a confecção dos gráficos no
presente trabalho.
Para melhor compreensão, suponha tabela1 = “Idoso”, tabela2 = “Instituição”,
atributo1 = “Sexo” e atributo2 = “Tipo”. O método getTipos retorna: ["sexo='feminino'”;
"sexo='masculino'"]
para
a
dupla
“Idoso”
e
“Sexo”
e
["tipo='particular'";
"tipo='filantrópica'"] para a dupla “Instituição” e “Tipo”. O método getResultadoBusca irá
retornar um vetor redimensionável com quatro posições, cada uma contendo o resultado da
busca realiza entre todas as combinações possíveis dos resultados de getTipos obtidos para
cada dupla. Uma opção de busca seria, por exemplo, a combinação entre "sexo='feminino'” e
"tipo='particular'”, cujo comando SQL elaborado no método getResultadoBusca seria:
"SELECT count(*)as resultado FROM Idoso, Instituição WHERE Idoso.cod_instituicao =
Instituição.cod_instituicao AND (Idoso.sexo = ‘feminino’) AND (Instituição.tipo =
‘particular’". O código completo da classe ComandosSQL está descrito a seguir:
class ComandosSQL {
46
// atributos
static String tabela1, tabela2, atributo1, atributo2, comando;
// método que dá valor ao atributo tabela1, de acordo com um parâmetro recebido
static void setTabela1(String t1)
{
tabela1 = t1;
}
// método que dá valor ao atributo tabela2, de acordo com um parâmetro recebido
static void setTabela2(String t2)
{
tabela2 = t2;
}
// método que dá valor ao atributo atributo1, de acordo com um parâmetro
//recebido
static void setAtributo1(String a1)
{
atributo1 = a1;
}
// método que dá valor ao atributo atributo2, de acordo com um parâmetro
recebido
static void setAtributo2(String a2)
{
atributo2 = a2;
}
//método que retorna o valor do atributo tabela1
static String getTabela1()
{
return tabela1;
}
//método que retorna o valor do atributo tabela2
static String getTabela2()
{
return tabela2;
}
//método que retorna o valor do atributo atributo1
static String getAtributo1()
{
return atributo1 ;
}
//método que retorna o valor do atributo atributo2
static String getAtributo2()
{
return atributo2 ;
}
static ArrayList <DadosGrafico> getResultadoBusca()
{
// Estabelece uma conexão com o banco de dados
ConexaoBanco cb = new ConexaoBanco();
// Cria um vetor redimensionável para receber o conjunto de comandos de
47
//busca possível para o par tabela1 e atributo1
ArrayList <String> tab_atri_1 = ComandosSQL.getTipos(tabela1, atributo1);
// Cria um vetor redimensionável para receber o conjunto de comandos de
//busca possível para o par tabela2 e atributo2
ArrayList <String> tab_atri_2 = ComandosSQL.getTipos(tabela2, atributo2);
//Cria um vetor redimensionável para receber todos o resultado da busca ao
//banco de dados
ArrayList <DadosGrafico> resposta = new ArrayList <DadosGrafico>();
//Cria um objeto do tipo DadosGrafico
DadosGrafico dg ;
int quantidade;
//Interação que irá repetir de acordo com a quantidade de resultados que a
//busca por comandos envolvendo tabela1 e atributo1 resultou
for(int i=0; i<tab_atri_1.size();i++)
{
//Interação que irá repetir de acordo com a quantidade de resultados que a
//busca por comandos envolvendo tabela2 e atributo2 resultou
for(int j=0; j<tab_atri_2.size(); j++)
{
// a variável quantidade recebe o resultado da busca no banco de dados
//efetuada pelo método select da classe ConexaoBanco
quantidade = cb.select("SELECT count(*)as resultado FROM "+tabela1+","
+tabela2+ " WHERE " +tabela1 + ".cod_instituicao = " + tabela2 +
".cod_instituicao AND ("+tabela1+ "."+tab_atri_1.get(i)+") AND
("+tabela2+"."+tab_atri_2.get(j)+")");
dg =new DadosGrafico();
// armazena a quantidade obtida
dg.setQuantidade(quantidade);
// armazena o nome do atributo2, que será utilizado como legenda no
//gráfico
dg.setLegendaBarra(tab_atri_2.get(j));
// armazena o nome do atributo1, que será utilizado como legenda no
//gráfico
dg.setLegendaBaixo(tab_atri_1.get(i));
//adiciona o trio “quantidade, atributo2, atributo1” no vetor
//redimensionável que será o retorno deste método
resposta.add(dg);
}
}
return resposta;
}
private static ArrayList <String> getTipos(String tabela, String atributo)
{
//Cria um vetor redimensionável que será o retorno do método
ArrayList <String> tipos = new ArrayList<String>();
//Inicia uma sequência de comparações até encontrar qual é a tabela recebida
//como parâmetro
if(tabela.equalsIgnoreCase("instituicao"))
{
48
// quando o nome da tabela é localizado, verifica-se qual é o atributo
//recebido como parêmetro
if(atributo.equalsIgnoreCase("tipo"))
{
// e por fim, quando o atributo é identificado, o vetor de retorno adiciona
//todas as opções de busca quantas existirem
tipos.add("tipo='particular'");
tipos.add("tipo='filantrópica'");
}
}
if(tabela.equalsIgnoreCase("idoso"))
{
if(atributo.equalsIgnoreCase("sexo"))
{
tipos.add("sexo='feminino'");
tipos.add("sexo='masculino'");
}
if(atributo.equalsIgnoreCase("estado_civil"))
{
tipos.add("estado_civil = 'solteiro' OR estado_civil = 'solteira'");
tipos.add("estado_civil = 'casado' OR estado_civil = 'casada'");
tipos.add("estado_civil = 'viúvo' OR estado_civil = 'viúva'");
tipos.add("estado_civil = 'separado' OR estado_civil = 'separada'");
tipos.add("estado_civil is null");
}
if(atributo.equalsIgnoreCase("numero_filhos"))
{
tipos.add("numero_filhos = 0");
tipos.add("numero_filhos >=1 AND numero_filhos < 3");
tipos.add("numero_filhos >=3 AND numero_filhos < 5");
tipos.add("numero_filhos >5");
tipos.add("numero_filhos is null");
}
if(atributo.equalsIgnoreCase("idade_aparente"))
{
tipos.add("idade_aparente >= 60 AND idade_aparente < 70");
tipos.add("idade_aparente >= 70 AND idade_aparente < 80");
tipos.add("idade_aparente >= 80 AND idade_aparente < 90");
tipos.add("idade_aparente > 90");
tipos.add("idade_aparente is null");
}
if(atributo.equalsIgnoreCase("tipo_convenio"))
{
tipos.add("tipo_convenio = 'SUS'");
tipos.add("tipo_convenio != 'SUS' AND tipo_convenio != ''");
tipos.add("tipo_convenio is null");
}
if(atributo.equalsIgnoreCase("meses_institucionalizacao"))
{
49
tipos.add("meses_institucionalizacao < 6"); //menos de 6 meses
tipos.add("meses_institucionalizacao
>=
6
AND
meses_institucionalizacao < 12"); //mais ou 6 meses e menos de 1 ano
tipos.add("meses_institucionalizacao
>=
12
AND
meses_institucionalizacao < 23"); // mais ou 1 ano e menos de 2 anos
tipos.add("meses_institucionalizacao
>=
23
AND
meses_institucionalizacao < 59"); //mais ou 2 anos e menos de 5 anos
tipos.add("meses_institucionalizacao
>=
59
AND
meses_institucionalizacao < 119"); // mais ou 5 anos e menos de 10 anos
tipos.add("meses_institucionalizacao
>=
119
AND
meses_institucionalizacao < 239"); //mais ou 10 anos e menos de 20 anos
tipos.add("meses_institucionalizacao
>=
239
AND
meses_institucionalizacao < 359"); //mais ou 20 anos e menos de 30 anos
tipos.add("meses_institucionalizacao
>=
359");
//mais ou 30 anos
tipos.add("meses_institucionalizacao is null");
}
if(atributo.equalsIgnoreCase("motivo_institucionalização"))
{
tipos.add("motivo_institucionalização = 'dependência'");
tipos.add("motivo_institucionalização
!=
'dependência'
AND
motivo_institucionalização != ''");
tipos.add("motivo_institucionalização is null");
}
if(atributo.equalsIgnoreCase("escolaridade"))
{
tipos.add("escolaridade = '1° grau'");
tipos.add("escolaridade = '2° grau'");
tipos.add("escolaridade = '3° grau'");
tipos.add("escolaridade is null");
}
if(atributo.equalsIgnoreCase("aposentado"))
{
tipos.add("aposentado = 'sim'");
tipos.add("aposentado = 'não'");
tipos.add("aposentado is null");
}
if(atributo.equalsIgnoreCase("outras_instituicoes"))
{
tipos.add("outras_instituicoes = 'sim'");
tipos.add("outras_instituicoes = 'não'");
tipos.add("outras_instituicoes is null");
}
if(atributo.equalsIgnoreCase("escolha_instituicionalizacao"))
{
tipos.add("escolha_instituicionalizacao
=
'idoso'
OR
escolha_instituicionalizacao = 'idosa'");
tipos.add("escolha_instituicionalizacao = 'família'");
tipos.add("escolha_instituicionalizacao
!=
'idoso'
AND
escolha_instituicionalizacao != 'idosa' AND escolha_instituicionalizacao = 'família' AND
50
escolha_instituicionalizacao = ''");
tipos.add("escolha_instituicionalizacao is null");
}
if(atributo.equalsIgnoreCase("pais_nascimento"))
{
tipos.add("pais_nascimento = 'Brasil'");
tipos.add("pais_nascimento != 'Brasil' AND pais_nascimento != ''");
tipos.add("pais_nascimento is null");
}
if(atributo.equalsIgnoreCase("cor"))
{
tipos.add("cor = 'branca'");
tipos.add("cor = 'negra'");
tipos.add("cor is null");
}
if(atributo.equalsIgnoreCase("aceitacao_instituicao"))
{
tipos.add("aceitacao_instituicao = 'sim'");
tipos.add("aceitacao_instituicao = 'não'");
tipos.add("aceitacao_instituicao is null");
}
}
if(tabela.equalsIgnoreCase("renda"))
{
}
if(tabela.equalsIgnoreCase("medicamentos"))
{
}
if(tabela.equalsIgnoreCase("habitos_vida"))
{
}
if(tabela.equalsIgnoreCase("visita_semanal"))
{
}
if(tabela.equalsIgnoreCase("queixas"))
{
}
if(tabela.equalsIgnoreCase("diagnostico_medico"))
{
}
if(tabela.equalsIgnoreCase("acomodacoes"))
{
}
if(tabela.equalsIgnoreCase("atividades"))
{
}
if(tabela.equalsIgnoreCase("quedas"))
{
}
if(tabela.equalsIgnoreCase("ortese"))
51
{
}
return tipos;
}
}
Assim, a classe ComandosSQL é capaz de gerar todos os comandos que serão
enviados ao banco de dados a fim de capturar os dados que respondam as perguntas feitas. A
seção a seguir é destinada a apresentar a classe que realiza a conexão e as consultas ao banco
de dados.
3.3.2.3 Classe ConexãoBanco
A classe ConexãoBanco é responsável por conectar o banco de dados ao sistema e
realizar todas as transações entre o sistema e o banco. Esta possui como atributos:
// con é o atributo responsável por manter a conexão com o banco de dados.
public Connection con
// metadata é o atributo que carrega todos dados referentes ao banco de dados.
public DatabaseMetaData metadata ;
A construtora desta classe é responsável por inicializar os atributos, informando os
dados necessários para a conexão, e realizando o tratamento de exceções que podem ser
geradas durante este processo.
public ConexaoBanco()
{
// Inicia a tentativa de conexão com banco de dados informando o endereço do
banco, o nome de usuário e senha.
try{
Class.forName("oracle.jdbc.driver.OracleDriver");
con
=
DriverManager.getConnection("jdbc:oracle:thin:@127.0.0.1:1521:XE","nomeUsuário","senha");
metadata = con.getMetaData()
}catch(Exception e){
// Caso algum erro seja ocasionado durante a tentativa de conexão, será exibido uma
mensagem de erro.
// informando a mensagem de falha de conexão. Quando este pop up for fechado pelo
usuário o programa será finalizado.
JOptionPane.showMessageDialog(null,"Não foi possível conectar ao Banco de
Dados!\n"+e);
System.exit(0);
}
52
}
O método nomeColunas, ao receber o nome de uma tabela como parâmetro, resgata
do banco de dados, com o auxilio do atributo metadata, o nome de todas as colunas
pertencentes a tabela recebida. Ao buscar esses dados na base ele preocupa-se em tratar as
possíveis exceções que podem ser geradas durante este procedimento.
public ArrayList <String> nomeColunas(String nomeTabela)
{
// Cria um objeto que conterá a lista de colunas da tabela recebida.
ArrayList <String> resposta = new ArrayList<String>();
// Tentativa de busca dos nomes das colunas referentes a tabela de entrada.
try{
//
ResultSet resultSet = metadata.getColumns(null, null, nomeTabela, null);
// Um string de auxilio para receber o nome de coluna a coluna da tabela de
entrada.
String ajuda;
//Pula as duas primeiras colunas que são responsáveis por armazenar o código de
// referência para instituição e idoso em todas as tabelas.
resultSet.next();
resultSet.next();
// A iteração a seguir insere cada nome de coluna, encontrado na tabela de entrada,
na lista de retorno.
while(resultSet.next())
{
// O string de auxilio recebe o nome de cada coluna.
ajuda = resultSet.getString("COLUMN_NAME");
//Retira os caracteres especiais encontrados no nome da coluna para que fiquem
de forma padrão.
ajuda= TratamentoString.getEliminarCaracteresEspeciais(ajuda);
// Adiciona o nome da coluna a lista de retorno.
resposta.add(ajuda);
}
// Retorna um alista com o nome de todas as colunas da tabela recebida como
parâmetro.
return resposta;
}catch(Exception e){
// Se não for possível encontrar a tabela de entrada será exibida uma mensagem de
erro ao usuário. Ao ser fechada, finalizará o programa.
JOptionPane.showMessageDialog(null,"Não foi possível encontrar a tabela
"+nomeTabela+"!");
System.exit(0);
return null;
}
}
53
O método select possui como retorno um inteiro que corresponde ao resultado do
comando recebido como entrada, o qual será executado dentro de uma cláusula de tratamento
de exceção. Desta forma é possível corrigir os possíveis erros decorrentes da execução deste
método em outras classes.
public int select(String comando){
try{
//Cria um objeto para enviar comandos SQL ao banco de dados.
Statement stmt = con.createStatement();
//Este objeto armazena todos os registro encontrados pela busca realizada com o
comando recebido como parâmetro.
ResultSet rs = stmt.executeQuery(comando);
// O primeiro registro deste objeto por padrão apresenta-se vazio, sendo necessário
// pular para o próximo efetuando um comando next().
rs.next();
// Retorna o valor da coluna resultado.
return rs.getInt("resultado");
}
catch (SQLException e)
{
// Caso o comando enviado ao banco de dados possua erros de sintaxe, um pop up
contendo uma mensagem de erros será apresentado ao usuário
// e o retorno desse método será 0, para a identificação deste o erro por outras
classes.
JOptionPane.showMessageDialog(null, "Erro no comando. "+e);
return 0;
}
}
É assim que a classe ConexãoBanco torna possível unir o sistema Projeto Idoso ao
banco de dados que possui os dados referentes aos Idosos Institucionalizados na cidade de
Curitiba. A próxima seção demonstra como transformar os dados obtidos nas consultas em
gráficos.
3.3.2.4 Classe TelaGráfico
A classe TelaGráfico exibe, através de uma interface gráfica, a comparação dos
atributos selecionados na Tela2 por meio de um gráfico. Esta tela apresenta como atributos:
// dataset corresponde aos dados pertencentes ao gráfico a ser plotado.
static DefaultCategoryDataset dataset ;
// dadosGrafico representa uma lista de dados referentes aos atributos selecionados na Tela2
que serão adcionados ao dataset.
static ArrayList <DadosGrafico> dadosGrafico;
54
// gráfico que será plotado na tela.
static JFreeChart grafico;
// O atributo painel contém o gráfico que será exibido.
static ChartPanel painel;
A construtora desta classe inicializa os elementos que a compõem e define algumas
propriedades que a mesma deve possuir:
public TelaGrafico() {
//Entitula a janela de acordo com o nome das tabelas selecionados da Tela1.
super(ComandosSQL.tabela1+ " x "+ComandosSQL.tabela2);
//Determina que ao fechar esta janela o programa continuará executando
normaalmente.
this.setDefaultCloseOperation(JFrame.HIDE_ON_CLOSE);
// Possibilita que a janela seja redimensionábel pelo usuário.
this.setResizable(true);
// Captura a largura e a altura da tela do computador, no qual o programa será
executado.
int largura = (int)(Toolkit.getDefaultToolkit().getScreenSize().getWidth());
int altura = (int)(Toolkit.getDefaultToolkit().getScreenSize().getHeight());
// Define a localização desta janela na tela do computador e largura e altura da mesma.
this.setBounds(largura/2-250, altura/2-400, 800, 600);
// Inicializa o objeto de dados do gráfico.
dataset = new DefaultCategoryDataset();
// Adiciona valores ao dataset.
this.setAdicionarDadosGrafico();
//Inicializa o objeto de gráfico, e o associa ao dataset.
grafico = TelaGrafico.createBarChart(dataset);
//Inicializa ao painel e associa o objeto de gráficos a ele.
painel = new ChartPanel(grafico);
// Adciona o painel aos componentes da janela.
this.setContentPane(painel);
// Reajustar o conteúdo da tela quando ela for redimensionada.
this.pack();
}
O método setAdicionarDadosGráfico é responsável por transferir os valores obtidos
durante a busca ao banco de dados, referentes as tabela e classes previamente selecionadas,
para o dataset, o qual é responsável por armazenar os dados que serão exibidos no gráfico.
private static void setAdicionarDadosGrafico()
{
//Preenche o objeto dadosGráfico com o resultado das da busca realizada noa base de
dados, de acordo com as tabelas e os atribulos selecionados na Tela1 e Tela2 do programa.
dadosGrafico = ComandosSQL.getResultadoBusca();
// A iteração adiciona ao dataset do gráfico todos os dados que foram obtidos pela
busca no banco.
for(int i=0; i<dadosGrafico.size();i++)
{
dataset.addValue(dadosGrafico.get(i).getQuantidade(),
55
TratamentoString.padraoLegenda(""+dadosGrafico.get(i).getLegendaBaixo()),
TratamentoString.padraoLegenda(""+dadosGrafico.get(i).getLegendaBarra()));
}
}
//O método createBarChart recebe os valores do gráfico, define suas características e
retorna um gráfico pronto.
private static JFreeChart createBarChart(CategoryDataset dataset)
{
JFreeChart chart = ChartFactory.createBarChart(
"", //Titulo
"", // Eixo X
"Quantidade de Idosos", //Eixo Y
dataset, // Dados para o grafico
PlotOrientation.VERTICAL, //Orientacao do grafico
true, false, false); // exibir: legendas, tooltips, url
return chart;
}
Através de todos os métodos mencionados a cima, a classe TelaGráfico é capaz de
plotar, em uma interface gráfica, o gráfico referente aos dados que estão armazenados na
estrutura como descrito e explicado no código desta classe.
No capítulo a seguir, Resultados e Análise, serão apresentadas os resultados obtidos
de acordo com a implementação das classes descritas neste capítulo.
56
4 RESULTADOS E ANÁLISE
Ao longo do desenvolvimento do projeto realizou-se uma sequência de atividades –
planejamento do projeto, revisão bibliográfica, modelagem e implementação do sistema –, as
quais, unidas, permitiram que ao término do processo fossem atingidos resultados. Sobre estes
será efetuada uma análise crítica, a qual visa identificar os pontos positivos e negativos
encontrados em cada etapa.
4.1 Planejamento do Projeto
4.1.1 Cronograma e Gráfico de Gantt
O planejamento do projeto incluiu a construção do cronograma de atividades, o qual
está representado no Quadro 2 da página 34.
A Tabela 5 exibe as datas – iniciais e limite – esperadas em comparação com as datas
que cada atividade, referenciada pelo seu código, realmente iniciou e terminou.
Tabela 5 - Datas previstas x Datas reais.
Código da Atividade
Data de início
Data de início
Data limite
prevista
real
prevista
Data de término
01
10/03/2010
12/03/2010
17/03/2010
17/03/2010
02
10/03/2010
12/03/2010
16/05/2010
24/05/2010
03
05/04/2010
01/04/2010
09/04/2010
12/04/2010
04
05/04/2010
02/05/2010
09/04/2010
07/05/2010
05
28/03/2010
26/03/2010
16/05/2010
26/05/2010
06
26/04/2010
07/05/2010
07/05/2010
16/05/2010
07
07/05/2010
07/05/2010
19/05/2010
16/05/2010
08
19/05/2010
16/05/2010
21/05/2010
26/05/2010
Fonte: Autoria Própria.
O Gráfico de Gantt, elaborado com base no cronograma, pode ser visualizado na
57
página 36, Gráfico 1.
A primeira atividade, iniciada na décima semana do Gráfico de Gantt, consistiu na
elaboração da proposta do projeto, a qual foi realizada dentro do prazo estipulado, apresentada
e aprovada no dia 18 de março de 2010. Na mesma semana, também se deu início à pesquisa
sobre o conteúdo da revisão bibliográfica, a qual se estendeu ao longo do projeto pelo fato de
ser uma atividade que auxiliou na compreensão dos conceitos empregados durante o processo.
Ambas as tarefas começaram no mesmo dia, pois a primeira serviu como contato inicial ao
conteúdo que foi aprofundado na segunda atividade.
O estudo do DER e da relação entre as tabelas, planejado para ter início na décima
terceira semana, foi adiantado para a décima segunda semana, quatro dias antes do previsto
por questão de disponibilidade de horas. No entanto, seu término foi prolongado devido à
necessidade de esclarecer alguns conceitos junto à disciplina de Banco de Dados, fazendo
com que fossem dedicados quase três vezes mais dias a esta atividade do que o estipulado
inicialmente.
A quarta atividade, estudar biblioteca SQL e plotagem de gráficos, ocorreu cinco
semanas depois do determinado, o que pode ser justificado pelo fato da pesquisa do conteúdo
da revisão, atividade que ocorria em paralelo, exigir maior dedicação. Porém, este atraso não
prejudicou o andamento do projeto.
O desenvolvimento da monografia, quinta atividade, teve início dois dias antes do
previsto a fim de atender a necessidade de organizar as informações encontradas durante a
pesquisa em um documento. Esta etapa, assim como a pesquisa do conteúdo da revisão,
estendeu-se além da data limite prevista (terminou na vigésima primeira semana), visto que
era necessária para arquitetar as informações coletadas na etapa da pesquisa e para
documentar todas as tarefas desempenhadas ao decorrer do processo.
Embora implementar classes para leitura dinâmica dos dados e classes para gerar os
gráficos, sexta e sétima atividade respectivamente, tenham sido programadas para ocorrer em
sequência, elas aconteceram em paralelo por causa de uma decisão tomada ao longo do
percurso, visto que seria conveniente manipulá-las juntas, isto é, implementá-las em um
mesmo momento. O planejamento previu que as semanas de dezessete a vinte seriam
dedicadas à realização de ambas, porém, com a decisão aplicada, este tempo se reduziu as
semanas dezoito e dezenove, o que representou um ganho de duas semanas.
A oitava e última atividade, rever monografia, iniciada após o término do software e
realizada em conjunto com a atividade desenvolver monografia, teve o objetivo de consertar
eventuais falhas presentes na monografia desenvolvida. Entretanto possam existir erros, os
58
quais podem ser apontados após a entrega deste projeto, dando continuidade a esta etapa.
4.1.2 Burndown Chart
Considerando as atividades a serem desempenhadas e o prazo para entrega final do
projeto, foram previstas 85 horas necessárias para a execução deste dentro de um período de
60 dias. Desta forma, foi possível confeccionar o Burndown Chart inicial (página 36, Gráfico
1), o qual apresenta a linha ideal para a confecção do presente trabalho.
Ao princípio da construção do projeto, uma nova linha passou a ser desenhada no
gráfico, a qual representa o andamento real das atividades realizadas em determinado dia e
tempo, indicando a quantidade de horas/dia empregada e a restante. Por volta da 17º semana
(a qual pode ser visualizada no Gráfico de Gantt), observou-se que a nova linha estava acima
da linha ideal em proporções elevadas (Gráfico 3), fato que chamou atenção, pois essa
situação indica atraso na execução do projeto.
Gráfico 3 – Burndown Chart Parcial.
Fonte: Autoria Própria.
Assim, comparando o andamento do processo com o cronograma, pode-se concluir
59
que as atividades estavam dentro do tempo determinado e que o problema não estava no
decorrer do projeto, mas na previsão mal calculada de dias e horas disponíveis. Esta situação
forçou uma reavaliação a fim de expor as condições mais apropriadas nas quais o Burndown
Chart inicial deveria ter sido elaborado. Esse novo gráfico prevê 77 dias e 77 horas e está
representado pelo Gráfico 4.
Gráfico 4 – Burndown Chart Inicial Reavaliado.
Fonte: Autoria Própria.
Desta forma, a carga horária despendida até a 17º semana foi transposta para o novo
Burndown Chart e este foi adotado até o final do processo, o qual pode ser visualizado no
Gráfico 5.
60
Gráfico 5 – Burndown Chart Final.
Fonte: Autoria Própria.
A análise do Burndown Chart final permitiu observar três pontos críticos. O primeiro
refere-se ao período compreendido entre os dias 10 a 15, o qual sucedeu a elaboração do préprojeto, e representa uma sequência de cinco dias em que não foram realizadas atividades
significativas. De forma análoga, o intervalo entre os dias 30 e 40 tornou-se ocioso devido à
maior ênfase dada ao processo de desenvolvimento da monografia. Entretanto, os dias que
sucederam os dois picos citados foram marcados por um aumento na carga horária de
trabalho, visando compensar o tempo inativo. O último período de destaque corresponde aos
dias 58 a 72, momento em que houve uma maior concentração de esforços para finalizar o
projeto dentro do prazo limite, permitindo que o projeto fosse terminado cinco dias antes do
esperado.
4.2 Implementação
Um exemplo de entidade gerada no Oracle Database 10g Express Edition com os
dados de PINTO (2008) pode ser visualizada na Figura 8, a qual exibe a tabela
“INSTITUICAO”.
61
Figura 8: Representação da tabela “INSTITUICAO” no Oracle Database 10g Express Edition.
Fonte: Autoria Própria.
Ao término da criação do código fonte, este foi compilado, gerando o sistema Projeto
Idoso. A seguir, será apresentado o funcionamento do software, cuja tela inicial pode ser
visualizada na Figura 9.
Figura 9: Tela Inicial.
Fonte: Autoria Própria.
Para exemplificar uma situação de geração de gráfico, foram selecionadas as
entidades “IDOSO” (no primeiro ComboBox) e “INSTITUIÇÃO” (no segundo), conforme
ilustra a Figura 10. Ambos os ComboBoxs apresentam como opção os itens descritos na
Tabela 6: Opções da Tela Inicial.
62
Tabela 6 – Opções da Tela Inicial
Entidade
Idoso
Instituição
Fonte: Autoria Própria.
Caso sejam selecionadas as mesmas alternativas nos dois ComboBox disponíveis, o
clique no botão “OK” fará com que apareça um pop up informando que as entidades
selecionadas nos ComboBox devem ser diferentes. Ao clicar no botão “OK” do pop up,
retornará a tela anterior.
Figura 10: Entidades selecionadas.
Fonte: Autoria Própria.
Após clicar no botão “OK”, a tela da lugar a outra (Figura 11), a qual disponibiliza os
atributos pertencentes a cada entidade selecionada anteriormente. Neste exemplo, serão
utilizados como atributos “SEXO” e “TIPO” (referentes a idoso e instituição,
respectivamente).
63
Figura 11: Idoso x Instituição.
Fonte: Autoria Própria.
A Tabela 7 – Opções da Segunda Tela – indica quais as possibilidades de escolha
oferecidas por cada ComboBox presente na segunda tela.
Tabela 7 – Opções da Segunda Tela
Entidade
Atributos
Idoso
Sexo
Idade Aparente
Data Nascimento
Município Nascimento
Estado Nascimento
País Nascimento
Estado Civil
Número de Filhos
Cor
Raça
Escolaridade
Profissão
Aposentado
Procedência
Tipo de Convênio
64
Outras Instituições
Meses Institucionalização
Aceitação Instituição
Escolha Institucionalização
Motivo Institucionalização
Instituição
Tipo
Fonte: Autoria Própria.
Será possível visualizar o gráfico de barras (Figura 12) após clicar no botão
“GERAR GRÁFICO”.
Figura 12: Tela do Gráfico.
Fonte: Autoria Própria.
O Manual do Usuário deste sistema pode ser consultado no documento
“ManualUsuario”.
65
5 CONCLUSÕES E TRABALHOS FUTUROS
A pesquisa realizada sobre Informática em Saúde aliada ao planejamento do projeto
permitiu a construção do artefato, software Projeto Idoso, o qual atingiu as expectativas
esperadas no início deste projeto. A geração de gráficos realizada pelo programa – a partir dos
dados do perfil epidemiológico de idosos armazenados em uma base de dados – realmente
possibilitou uma melhora na visualização, facilitando a comparação e evitando que o usuário
se obrigue a ter conhecimento sobre ferramentas de banco de dados, neste caso, Oracle
Database 10g Express Edition.
Um fator importante foi a elaboração do gráfico de acompanhamento das atividades
desenvolvidas ao longo do projeto, o qual auxiliou na percepção das tarefas faltantes de
acordo com o tempo que ainda restava, permitindo uma melhor administração da execução
das atividades distribuídas no tempo.
No que diz respeito aos dados previamente coletados por PINTO (2008), o diagrama
entidade relacionamento permitiu analisá-los e, assim, definir as instruções que seriam
enviadas ao banco de dados (instanciado com esses dados) a fim de obter respostas para gerar
os gráficos. A modelagem dos requisitos do sistema auxiliou no desenvolvimento do software,
pois indicou os principais detalhes do programa, minimizando os riscos de erro durante o
processo de implementação. Assim, foi possível gerar gráficos através do programa
construído.
Durante o percurso de desenvolvimento deste trabalho, pode-se observar que
algumas práticas adotadas foram de grande auxílio ao cumprimento do mesmo. Realizar uma
pesquisa em bibliotecas virtuais utilizando um conjunto de palavras chaves foi de grande
importância para encontrar artigos diretamente relacionados ao tema proposto (esta medida
pode ser adotada por quem queira realizar pesquisas como essa) e assim foi possível estipular
as prioridades de acordo com o prazo de término deste trabalho. Outra prática adotada, a de
estimar o tempo necessário de construção do projeto, foi uma das formas de relacionar o
tempo dispensado em cada atividade aumentando o controle sobre quais atividades já haviam
sido realizadas e quais ainda deveriam ser executadas, evidenciando também o grau de
dedicação para cada uma. Também foram realizados encontros frequentes entre os integrantes
da equipe de realização deste projeto, fato que tornou ainda maior o controle de atividades
realizadas e faltantes de acordo com o tempo restante para elaboração do projeto.
No entanto, ainda podem ser efetuadas melhorias sobre o presente projeto, tais como
66
aprofundar a revisão bibliográfica, principalmente no que diz respeito aos sistemas existentes
na área de gerontologia e, assim, adequar a interface do sistema o mais próximo da
necessidade do usuário – profissional da saúde –, além de deixá-la visualmente mais
apresentável, corrigir possíveis erros presentes no atual projeto, proporcionar mais opções de
gráficos a serem gerados (exemplo: barra, pizza, linha, entre outros) e disponibilizar as dez
tabelas não utilizadas para que também possam dar origem a gráficos.
67
6 REFERÊNCIA BIBLIOGRÁFICA
BASHAM, Brian; SIERRA, Kethy; BATES, Bert. Use a cabeça! Servlets & JSp. Tradutor:
Marcelo Soares, Weuler Gonçalves. Rio de Janeiro: Alta Books, 2005.
BLOMBERG, Luciano C.; MOTA, Eduardo G.; DE FIGUEIREDO, José A. P.; RUIZ,
Duncan D. A.. Desenvolvimento de um banco de dados de saúde bucal para administração de
registros clínicos. Revista odonto ciência, v. 24, n. 3, 249-253, jul./set. 2009. Disponível em:
< http://revistaseletronicas.pucrs.br/ojs/index.php/fo/article/view/5189/4506 >. Acesso em: 12
mar. 2010.
BOENTE, Alfredo. Aprendendo a programar em Java 2: orientado a objetos. Rio de
Janeiro: Brasport, 2003.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: guia do usuário. Tradutor:
Fábio Freitas. Rio de Janeiro: Campus, 2000.
DANILOW, Milena Z.; MOREIRA, Ana C. S.; VILLELA, Cecília G.; BARRA, Betânia B.;
NOVAES, Maria R. C. G..; OLIVEIRA, Mirna P. F.. Perfil epidemiológico, sociodemográfico
e psicossocial de idosos institucionalizados do Distrito Federal. Com. Ciências Saúde,
Distrito Federal, v. 18, n. 1, 9-16, fev. 2007. Disponível em: <
http://www.fepecs.edu.br/revista/Vol18_1art01.pdf >. Acesso em: 27 mar. 2010.
DEITEL, M. H.; DEITEL, J. P. Java, como programar. Tradutor: Carlos Arthur Lang
Lisbôa. 4 ed. Porto Alegre: Bookman, 2003.
FILHO, José R.; XAVIER, Jefferson C. B.; ADRIANO, Ana L.. A tecnologia da informação
na área hospitalar: um caso de implementação de um sistema de registro de pacientes. Revista
de Administração Contemporânea, Curitiba, v. 5, n. 1, 105-120, jan./abr. 2001. Disponível
em:
<
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S141565552001000100007&lang=pt >. Acesso em: 12 mar. 2010.
FISHER, Alan S.. CASE: Utilização de Ferramentas para Desenvolvimento de Software.
Tradutor: Info-Rio. Rio de Janeiro: Campus, 1990.
GUIMARÃES, Célio C.. Fundamentos de Bancos de Dados: modelagem, projeto e
linguagem SQL. São Paulo: Editora Unicamp, 2003.
68
LAUDON, Kenneth C.; LAUNDON, Jane P.. Sistema de Informação com Internet.
Tradutor: Dalton Conde de Alencar. 4 ed. Rio de Janeiro: LTC – Livros Técnicos e Científicos
S.A., 1999.
LINHARES, Robson R. *INTRODUÇÃO À ORIENTAÇÃO A OBJETOS:* Notas de
aula*.* Curso de Graduação – Bacharelado em Sistemas de Informação.
Disciplina Fundamentos de Programação I, DAINF/UTFPR, 2009.
LOGAN, Judith R. A.; PRICE, Susan L.. Computer science education for medical
informaticians. International Journal of Medical Informatics, Portland, v. 73, n. 2, p. 139144, mar. 2004. Disponível em: < http://www.ijmijournal.com/article/S1386-5056(03)002004/abstract >. Acesso em: 27 mar. 2010.
LUIS, Margarita A. V.; MOALA, Fernando A.; ÉVORA, Yolanda D. M.; SCOCHI, Carmen
G. S.; RODRIGUES; Rosalina A. P.. Avaliação de uma disciplina de informática por
graduandos de enfermagem. Revista Latino-Americana de Enfermagem, Ribeirão Preto, v.
3,
n.
2,
p.
69-82,
jul.
1995.
Disponível
em:
<
http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0104-11691995000200006
>.
Acesso em: 27 mar. 2010.
MOURA, Arnaldo V.. Especificações em Z: uma introdução. São Paulo: Editora Unicamp,
2001.
PINTO, Regina B. R. Perfil epidemiológico de idosos residentes em instituições de longa
permanência para idosos na cidade de Curitiba, a partir da modelagem de banco de dados.
2008. 153 f. Dissertação (Mestrado em Tecnologia em Saúde) – Pontifícia Universidade
Católica do Paraná, Curitiba, 2008.
PRESSMAN, Roger S.. Engenharia de Software. Tradutor: José Carlos Barbosa dos Santos.
São Paulo: Pearson Education do Brasil, 1995.
REIS, Sandra C. G.. B.; HIGIN, Maria A. S. P.; DE MELO, Hugo M. D.; FREIRE, Maria C.
M.. Condição de saúde bucal de idosos institucionalizados em Goiânia-GO, 2003. Revista
Brasileira de Epidemiologia, São Paulo, v. 8, n. 1, 67-73, mar. 2005. Disponível em: <
http://www.scielo.br/pdf/rbepid/v8n1/08.pdf >. Acesso em: 27 mar. 2010.
REZENDE, Denis A.. Engenharia de Software para Excelência em Sistemas
Empresariais. Curitiba: Apta, 1997.
RUMBAUGH, James. Modelagem e projetos baseados em objetos. Tradutor: Dalton Conde
de Alencar. Rio de Janeiro: Campus, 1994.
69
SILVA, Flávio S. C. da; FINGER, Marcelo; MELO, Ana C. V. de. Lógica para
Computação. São Paulo: Thomson Learning, 2006.
SILVA, Mateus L.; SOARES, Edvaldo; DIAS, Carmen L.; DE OLIVEIRA, Tâmara P..
Retrato do Idoso Institucionalizado: Perfil Epidemiológico.
SOMMERVILLE, Ian. Engenharia de Software. 8 ed. Tradução: Selma Shin Shimizu
Melnikoff, Reginaldo Arakaki, Edílson de Andrade Barbosa. São Paulo: Pearson Addison
Wesley, 2007.
STADZISZ, Paulo C. Projeto de Software usando a UML. 2 versão. Disponível em: <
http://www.etelg.com.br/paginaete/downloads/informatica/apostila2uml.pdf >. Acesso em: 04
abr.2010, 14:10.
TAKAI, Osvaldo K.; ITALIANO, Isabel C.; FERREIRA, João E.. Introdução a Banco de
Dados. São Paulo: DCC-IME-USP, 2005.
WAZLAWICK, Raul S.. Metodologia de Pesquisa para Ciência da Computação. Rio de
Janeiro: Elsevier, 2008.
XIMENES, Sérgio. Minidicionário Ediouro da Língua Portuguesa. 2 ed rev. e ampl.. São
Paulo: Ediouro, 2000.
ZIVIANI, Nivio. Projeto de Algoritmos: com implementações em Java e C++. São Paulo:
Cengage Learning, 2006.
Guia
SERASA
de
orientação
ao
cidadão.
Disponível
<http://www.serasa.com.br/guiaidoso/18.htm >. Acesso em: 15 mar. 2010, 19:50.
em:
Instituto
Brasileiro
de
Geografia
e
Estatística.
<http://www.ibge.gov.br/home/>. Acesso em: 15 mar. 2010, 20:00.
em:
Disponível
Java 2 Platform SE 5.0. <http://java.sun.com/j2se/1.5.0/docs/api/>. Acesso em 18 mai. 2010,
11:43.
JDBC – Oracle Wiki. Disponível em: <http://wiki.oracle.com/page/JDBC>. Acesso em: 16
abr. 2010, 10:05.
70
Learn GanttProject. Disponível em: <http://www.ganttproject.biz/learn#license>. Acesso
em: 01 abr. 2010.
Open Source Initiative. Disponível em: <http://www.opensource.org/>. Acesso em: 04 abr.
2010, 11:17.
Oracle. Disponível em: <http://www.oracle.com/us/products/database/index.html>. Acesso
em: 26 mar. 2010, 18:05.
Project
Mogwai
best
of
breed
Open
Source.
Disponível
em:
<http://mogwai.sourceforge.net/?Welcome:ERDesigner_NG>. Acesso em 16 abr. 2010,
10:10.
RICARTE, Ivan L. M.. Documentação de Código com Javadoc. Disponível em:
<http://www.dca.fee.unicamp.br/cursos/PooJava/javaenv/javadoc.html>. Acesso em: 12 abr.
2010, 11:38.
Sociedade Brasileira de Informática em Saúde. Disponível em: <http://www.sbis.org.br/>.
Acesso em: 27 mar. 2010, 08:54.
The Java Language Specification. Disponível em: <http://java.sun.com/docs/books/jls/>.
Acesso em: 14 abr. 2010, 18:21.
UNIFESP Virtual. Disponível em: <www.virtual.epm.br/>.
13:53.
Acesso em: 28 mar. 2010,
VIKLUND, Andreas. JFreeChart. Disponível em: <http://www.jfree.org/jfreechart/>. Acesso
em: 26 mar. 2010, 18:00.
Welcome to NetBeans. Disponível em: <http://netbeans.org/>. Acesso em 01 abr. 2010.
71
7 APÊNCIDES
Apêndice A: Tabelas contendo o nome do autor, título, nome do periódico onde foi publicado, a base de dados e as palavras chaves
utilizadas na pesquisa, além do assunto que aborda e a classificação de cada artigo encontrado na revisão bibliográfica.
[Continua]
AUTOR
ÁLVARES, 2010
TÍTULO
Ocorrência de quedas em
idosos residentes em
instituições de longa
permanência em Pelotas,
Rio Grande do Sul, Brasil
AMARAL et al., 1996
ANDERSON, 1998
ARAÚJO; MALVEIRA,
2003
BLOMBERG et al.,
2009
BRANDT et al., - ano
Estimativas da taxa de Desenvolvimento de um Perfil epidemiológico dos
Integração de sistemas Saúde e Condições de atraso ao programa de banco de dados de saúde idosos atendidos pelo
Sistema Único de Saúde
imunização: o impacto
bucal para
de informação em
vida do Idoso no
(SUS) em Salgueiro da
implantação
em
um
administração
de
saúde
Brasil
Banco de Dados
registros clínicos
Sertão de Pernambu
NOME DO
PERIÓDICO
Cadernos de Saúde
Pública
Anais do III Fórum
Nacional de Ciência e
Tecnologia em Saúde
Textos Sobre
Envelhecimento
Escola Anna Nery
Revista de
Enfermagem
Revista Odonto
Ciência
Anais da Faculdade de
Medicina da
Universidade Federal de
Pernambuco
BASE DE DADOS
Scielo
Lilacs BVS
Scielo
Lilacs BVS
Lilacs BVS
Lilacs BVS
PALAVRA CHAVE
Idosos, instituições
Prontuário
computadorizado
Saúde, idoso
Informática médica,
banco de dados
Banco de dados;
Prontuários
Perfil, epidemiológico
ITENS QUE
ABORDA
Quedas, Instituição de
Longa Permanência para
Idosos
Informática em Saúde,
Prontuários Eletrônicos
Doenças e Qualidade de
Vida, Perfil
Epidemiológico de Idosos
Informática em Saúde,
Banco de Dados*
Banco de Dados*
Perfil Epidemiológico
de Idosos
CLASSIFICAÇÃO
Quatro
Dois
Quatro
Quatro
Quatro
Três
72
[Continuação]
AUTOR
TÍTULO
NOME DO
PERIÓDICO
CAMPOS NETO et al.,
2003
CARITÁ et al., 2008
Desenvolvimento de
banco de dados para
pesquisa
Implementação e avaliação de
um sistema de gerenciamento
de imagens médicas com
suporte à recuperação baseada
em conteúdo
CARNEIRO et al.,
2007
CASSIANI; GIMENES;
FREIRE, 2002
CASTELLS, 2007
CREUTZBERG et al.,
2007
Modelo teórico y propuesta
para la implementación de
normas de seguridad digital
para resguardo de registros
médicos computarizados
A Instituição de Longa
Permanência para
Idosos e o sistema de
saúde
Revista brasileira de
enfermagem
Córdoba
Revista
Latinoamericana de
Enfermagem
Qualidade de vida,
A prescrição médica
apoio social e
eletrônica em um
depressão em idosos: hospital universitário:
relação com
falhas de redação e
habilidades sociais
opiniões de usuários
Revista da Sociedade
Psicologia: reflexão e
de Cardiologia Estado Radiologia Brasileira
crítica
de São Paulo
BASE DE DADOS
Lilacs BVS
Lilacs BVS
Lilacs BVS
Lilacs BVS
Lilacs BVS
Lilacs BVS
PALAVRA CHAVE
Informática médica,
banco de dados
Linguagem java
Asilo, dados
prontuário
computadorizado
Prontuários
eletronicos
Saúde, idoso,
informática
Prontuários
Eletrônicos
Prontuários
Eletrônicos
Instituições de Longa
Permanência
Quatro
Três
Dois
ITENS QUE
ABORDA
CLASSIFICAÇÃO
Informática em Saúde,
Doenças e Qualidade
Informática em Saúde
Banco de Dados*
de Vida
Quatro
Dois
Dois
73
[Continuação]
AUTOR
CROSS; PALMER;
DANILOW et al., 2007
STEPRHENSON, 2009
TÍTULO
Perfil epidemiológico,
sociodemográfico e
How to design and use
psicossocial de idosos
a research database
institucionalizados do
Distrito Federal
FABRÍCIO; RODRIGUES;
JUNIOR COSTA, 2002
FERREIRA et al, 2007 FERREIRA et al., 2009
FILHO; XAVIER;
ADRIANO, 2001
Programa de atenção
Quedas acidentais em Informatização de um
particularizada ao
idosos
serviço de nutrição
idoso em unidades
institucionalizados
hospitalar
básicas de saúde
A tecnologia da
informação na área
hospitalar: um caso de
implementação de um
sistema de registro de
pacientes
NOME DO
PERIÓDICO
Diagnostic
Histopathology
Comunicação em
Ciências da Saúde
Acta Paulista de
Enfermagem
Revista de
Administração em
Saúde
Saúde e Sociedade
Revista de
Administração
Conteporânea
BASE DE DADOS
Artificial Intelligence
in Medicine
Lilacs BVS
Lilacs BVS
Lilacs BVS
Scielo
Scielo
PALAVRA CHAVE
Old, database
Perfil,
institucionalizado
Asilo, dados
ITENS QUE
ABORDA
Banco de Dados *
Perfil Epidemiológico de
Idosos, Instituições de
Longa Permanência
CLASSIFICAÇÃO
Dois
Cinco
Informática médica, Idoso, saúde, banco de
banco de dados
dados
Quedas, Instituições
Informática em Saúde
de Longa Permanência
Três
Quatro
Saúde; Prontuário
eletrônico
Dificuldadades dos
Idosos
Informática em Saúde
Três
Quatro
74
[Continuação]
AUTOR
FRAIGE, 2007
GAIÃO; ALMEIDA;
HEUKELBACH, 2005
GONÇALVES et al.,
2008
TÍTULO
Prontuário Eletônico do
centro de Atendimento
a Pacientes Especiais:
desenvolvimento e
implementação
Perfil epidemiológico da cárie
dentária, doença periodontal, uso e
necessidade de prótese em idosos
residentes em uma instituição na
cidade de Fortaleza, Ceará
NOME DO
PERIÓDICO
Tese Apresentada a
Universidade de São
Paulo
BASE DE DADOS
Lilacs BVS
Lilacs BVS
Lilacs BVS
PALAVRA CHAVE
saúde, registro
eletrônico
Asilo, dados
Asilo, dados
ITENS QUE
ABORDA
Prontuários
Eletrônicos
CLASSIFICAÇÃO
Três
HAAS; HENRIQUE;
DEMARZO, 2008
INOUYE et al., 2009
Requirements and
Prevalência de quedas Condições ergonômicas Percepção de qualidade
prototyping of a home
em uma unidade básica de de vida do idoso com
em idosos asilados do
saúde recentemente
demência e seu cuidador health care application
município de Rio
informatizada de
familiar: avaliação e based on emerging java
Grande, RS
Florianópolis - SC
correlação
technology
Revista
Revista Brasileira de
Arquivos Catarinenses
Revista Saúde Pública
Latinoamericana de
Epidemiologia
de Medicina
Enfermagem
Lilacs BVS
Lilacs BVS
prontuários eletronicos banco de dados, idoso
Perfil Epidemiológico,
Quedas, Instituições
Doenças e Qualidade
Instituições de Longa
Informática em Saúde
de Longa Permanência
de Vida
Permanência
Quatro
LIND et al., 2002
Três
Três
Dois
International Journal
of Medical
Informatics
International Journal
of Medical
Java, database
Java *
DOIS
75
[Continuação]
AUTOR
LUIS et al., 1995
TÍTULO
Avaliação de uma
disciplina de
informática por
graduandos de
enfermagem
LOGAN; PRICE, 2004
LUZ; MARCONI;
GUIMARÃES
MAGALHÃES; TELESMAGALHÃES; PEGORAROKROOK
MARIN, 2001
Um estudo sobre o uso de
Computer science recursos de informática por
Banco de Dados Sobre
O prontuário
education for medical estudantes de medicina e
Fonetografia
eletrônico
do paciente
enfermagem na Faculdade
informaticians
de Medicina de Marília
MARIN; BOURIE;
SAFRAN, 2000
Desenvolvimento de
um sistema de alerta
para prevenção de
quedas em pacientes
hospitalizados
NOME DO
PERIÓDICO
Revista Latino
Americana de
Enfermagem
International Journal
of Medical
Informatics
Sociedade Brasileira
de Informática em
Saúde
Sociedade Brasileira
de Informática em
Saúde
Revista Paulista de
Enfermagem
Revista Latino
Americana de
Enfermagem
BASE DE DADOS
Scielo Brasil
International Journal
of Medical
Sociedade Brasileira
de Informática em
Sociedade Brasileira
de Informática em
Lilacs BVS
Lilacs BVS
PALAVRA CHAVE
Informática médica,
gráfico
Java, database
Informática médica,
gráfico
Banco de Dados,
software
Registro médico
Saúde, idoso,
informática
Banco de Dados
Prontuários
Eletrônicos
Prontuários
Eletrônicos
Um
Quatro
Dois
ITENS QUE
ABORDA
CLASSIFICAÇÃO
Domínio da Informática Domínio da Informática Domínio da Informática
por Profissionais da
por Profissionais da
por Profissionais da
Saúde
Saúde
Saúde
Quatro
Quatro
Três
76
[Continuação]
MATTOS, 2006
MONTEIRO; BARBOSA;
SIGNORINI, 2007
MOTTA et al., 2001
TÍTULO
Perfil audiométrico de
uma população de
idosos: um estudo
epidemiológico
seccional
Um modelo abstrato em
um processo de crítica:
aplicação aos dados de
uma coorte de pacientes
com Aids
Autorização e controle de
acesso para o prontuário
eletrônico do paciente em
ambientes abertos e
distribuídos: uma proposta de
modelo e arquitetura
NOME DO
PERIÓDICO
Cadernos Saúde
Coletiva
Cadernos Saúde
Coletiva
Revista Brasileira de
Engenharia Biomédica
Health Informatics
Journal
Psicologia em Estudo
Caderno Saúde
Pública
BASE DE DADOS
Lilacs BVS
Lilacs BVS
Lilacs BVS
SAGE Journals Online
Lilacs BVS
Lilacs BVS
registro eletrôncio de
paciente, java
Old, database
Asilo, dados
Asilo, dados
PALAVRA CHAVE
Epidemiologico, idoso, Informática médica,
banco de dados
banco de dados
MOURATIDIS; MANSON;
PHILP, 2003
PAVAN;
MENEGHEL;
JUNGES, 2008
AUTOR
OLIVEIRA et al., 2006
A novel agent-based
Relação entre
system to support the
Mulheres idosas
ansiedade, depressão e
single assessment
enfrentando a
desesperança entre
process of older
institucionalização
grupos de idosos
people
ITENS QUE
ABORDA
Perfil Epidemiológico
de Idosos
Banco de Dados *
Prontuários
Eletrônicos
Informática em Saúde
CLASSIFICAÇÃO
Quatro
Quatro
Dois
Quatro
Doenças e Qualidade
Instituições de
de Vida
Longa Permanência
Três
Três
77
[Conclusão]
AUTOR
PERONDI; SAKANO;
SCHVARTSMAN,
Utilização2008
de um sistema
PINTO, 2008
REIS et al., 2005
SILVA et al.
informatizado de
atendimento em prontosocorro pediátrico com
sistema de escore clínico
de triagem
Perfil epidemiológico de idosos
residentes em instituições de longa
permanência para idosos na cidade
de Curitiba, a partir da modelagem
de banco de dados
Condição de saúde
bucal de idosos
institucionalizados
em Goiânia-GO,
2003
Retrato do Idoso
Institucionalizado:
Perfil
Epidemiológico
NOME DO
PERIÓDICO
Einstein (São Paulo)
-
Revista Brasileira de
Epidemiologia
BASE DE DADOS
Lilacs BVS
-
Revista Brasileira de
Epidemiologia
PALAVRA CHAVE
saúde, registro
eletrônico
-
Longa
TÍTULO
ITENS QUE
ABORDA
CLASSIFICAÇÃO
Perfil
Perfil Epidemiológico,
Instituições de
Epidemiológico,
Informática em Saúde Instituições de Longa
Longa Permanência Instituições de Longa
Permanência
Permanência
Três
Cinco
Quatro
Cinco