TCC A importancia da informatização no gerenciamento de uma associação de doadores de sangue
85
0 UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS – UNIPAC FACULDADE REGIONAL DO ALTO SÃO FRANCISCO CURSO DE SISTEMAS DE INFORMAÇÃO AGUINALDO ALVES PINTO BRUNO AMARANTE COUTO REZENDE DOUGLAS ALEXANDRE DA SILVA JÚNIO GERALDO DOS SANTOS A IMPORTÂNCIA DA INFORMATIZAÇÃO NO GERENCIAMENTO DE UMA ASSOCIAÇÃO DE DOADORES DE SANGUE BOM DESPACHO/MG NOVEMBRO – 2009
description
Monografia do curso de Sistemas de Informação Unipac
Transcript of TCC A importancia da informatização no gerenciamento de uma associação de doadores de sangue
0
UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS – UNIPA C
FACULDADE REGIONAL DO ALTO SÃO FRANCISCO
CURSO DE SISTEMAS DE INFORMAÇÃO
AGUINALDO ALVES PINTO
BRUNO AMARANTE COUTO REZENDE
DOUGLAS ALEXANDRE DA SILVA
JÚNIO GERALDO DOS SANTOS
A IMPORTÂNCIA DA INFORMATIZAÇÃO NO
GERENCIAMENTO DE UMA ASSOCIAÇÃO DE
DOADORES DE SANGUE
BOM DESPACHO/MG
NOVEMBRO – 2009
1
UNIVERSIDADE PRESIDENTE ANTÔNIO CARLOS – UNIPAC
FACULDADE REGIONAL DO ALTO SÃO FRANCISCO
CURSO DE SISTEMAS DE INFORMAÇÃO
AGUINALDO ALVES PINTO
BRUNO AMARANTE COUTO REZENDE
DOUGLAS ALEXANDRE DA SILVA
JÚNIO GERALDO DOS SANTOS
A IMPORTÂNCIA DA INFORMATIZAÇÃO NO
GERENCIAMENTO DE UMA ASSOCIAÇÃO DE
DOADORES DE SANGUE
Monografia apresentada ao Curso de Sistemas de Informação da Universidade Presidente Antônio Carlos – UNIPAC, como requisito a obtenção do título de Bacharel em Sistemas de Informação, sob a orientação do Prof. Esp. Mateus Aparecido dos Santos.
BOM DESPACHO/MG
NOVEMBRO – 2009
2
AGUINALDO ALVES PINTO
BRUNO AMARANTE COUTO REZENDE
DOUGLAS ALEXANDRE DA SILVA
JÚNIO GERALDO DOS SANTOS
A IMPORTÂNCIA DA INFORMATIZAÇÃO NO
GERENCIAMENTO DE UMA ASSOCIAÇÃO DE
DOADORES DE SANGUE
Monografia apresentada à Universidade Presidente Antônio Carlos – UNIPAC, como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação.
BANCA EXAMINADORA
Orientador Prof.º Esp. Mateus Aparecido dos Santos
Universidade Presidente Antônio Carlos – UNIPAC
Avaliador Prof.º Ms. Eduardo Cardoso Melo
Universidade Presidente Antônio Carlos – UNIPAC
Avaliador Prof.º Esp. Edmilson Ferreira da Silva
Universidade Presidente Antônio Carlos – UNIPAC
Aprovada em______/______/______
3
À Rodrigo Martins Pagliares
4
AGRADECIMENTO
Agradecemos a Deus, nossa força constante.
Às nossas famílias, pela compreensão, carinho e apoio.
À Margarida Lelis e todos os funcionários da ADSBD, pelo incansável apoio.
Aos amigos e colegas pela paciência.
Aos nossos professores, Mateus, Tânia, João, Edmilson, Eduardo, Alessandro, Henrique, Wellington, Cristiano, Rodrigo, Bete, Gustavo, Elton, Samir, Elídio, Tchesco, Humberto e Alexandre pelos ensinamentos e amizade.
As namoradas pela compreensibilidade.
Por fim, a nossa “querida sede”, a casa do Aguinaldo.
5
“O mundo detesta mudanças e, no entanto, é a única coisa que traz progresso”.
C. F. Kettering
6
RESUMO
As associações de doadores de sangue desempenham um papel importante no processo de
doação de sangue, promovendo a conscientização da população e auxiliando hospitais e
hemocentros a manter um nível suficiente de bolsas de sangue. Por não terem fins lucrativos,
estas entidades são categorizadas como do terceiro setor. Neste setor se enquadram as
entidades que realizam trabalhos sociais contribuindo com diversas áreas da sociedade. É
comum que estas entidades apresentem dificuldades no seu gerenciamento, devido ao grande
volume de informações manipuladas e à falta de meios eficazes para gerenciá-las. A partir de
um estudo de caso realizado junto a Associação dos Doadores de Sangue de Bom Despacho
(ADSBD) foram identificadas estas dificuldades e então apresentado como a informatização é
importante para o seu gerenciamento. Diante disso, foi desenvolvido, utilizando as técnicas da
Engenharia de Software, o ADSBD Manager, um sistema gerencial para auxiliar a
administração da entidade.
Palavras chaves: doação de sangue, terceiro setor, informatização, Engenharia de Software.
7
ABSTRACT
The associations of blood donors are an important role in the process of donation of blood by
promoting awareness of the population and helping hospitals and blood centers to maintain a
sufficient level of the blood reservations. Because of the non-profit objectives, these entities
are categorized as the third sector, in this sector are entities that perform social work
contributing to several problems in areas of the society. It is common that these entities have
difficulties in their management, because of the large number of information handled and the
lack of resources to manage them. From an analyzation of a case, done with the Association
of Blood Donors in Bom Despacho (ADSBD), these problems have been identified and then
displayed as the information is important to its management. In this way, was developed,
using the techniques of Software Engineering, the ADSBD Manager, a management system to
assists the administration of the entity.
Key words: Blood Donation, The Third Sector, Information, Software Engineering.
8
LISTA DE ILUSTRAÇÕES
LISTA DE FIGURAS
Figura 1: Metodologia em cascata.................................................................................... 33
Figura 2: Visão geral das fases propostas pelo modelo espiral........................................ 34
Figura 3: Processo de compilação de um programa Java................................................. 43
Figura 4: Plataformas do Java........................................................................................... 43
Figura 5: Tela do IDE NetBeans....................................................................................... 45
Figura 6: Tela principal do IBOConsole........................................................................... 46
Figura 7: Tela do DBDesigner.......................................................................................... 47
Figura 8: Especificação JPA............................................................................................. 49
Figura 9: Tela do IReports................................................................................................ 50
Figura 10: Tela de criação de um diagrama de seqüência................................................ 52
Figura 11: Diagrama de caso de uso: Caso de uso geral................................................... 57
Figura 12: Caso de Uso Cadastrar Doadores de Sangue................................................... 59
Figura 13: Diagrama de atividade cadastrar doadores de sangue..................................... 61
Figura 14: Diagrama seqüencia básica de Cadastro doador de sangue............................. 62
Figura 15: Diagrama de seqüencia de exceção................................................................. 63
Figura 16: Modelo de Domínio: Gerenciamento de Doadores e Colaboradores.............. 64
Figura 17: Modelo de Domínio: Gerenciamento de Atividades....................................... 64
Figura 18: Diagrama Entidade Relacional do ADSBD Manager..................................... 66
Figura 19: Diagrama de pacote: Arquitetura do software................................................. 67
Figura 20: Trecho de código da classe DAOGenerico...................................................... 69
Figura 21: Tela inicial ADSBD Manager.......................................................................... 71
Figura 22: Tela de cadastro de doadores........................................................................... 72
Figura 23: Tela de cadastro de colaboradores................................................................... 72
Figura 24: Tela de busca avançada de doadores............................................................... 73
Figura 25: Tela de controle de doações............................................................................. 73
Figura 26: Tela gerenciamento do projeto futuro doador................................................. 74
9
LISTA DE QUADROS
Quadro 1: Principais eventos relacionados a doação de sangue ocorridos no Brasil........ 20
Quadro 2: Comparativo entre OO e Programação Estruturadas....................................... 40
Quadro 3: Descrição dos Casos de Uso – Digrama Casos de Uso Geral.......................... 58
Quadro 4: Descrição do Caso de Uso Cadastrar Doador de Sangue................................. 60
LISTA DE GRÁFICOS
Gráfico 1: Evolução da quantidade de bolsas coletas e a quantidade utilizada em Bom
Despacho...........................................................................................................................
28
Gráfico 2: Ciclo de vida de um software sem um processo definido de
desenvolvimento ..............................................................................................................
31
Gráfico 3: Ciclo de vida aplicando técnicas da Engenharia de Software......................... 32
Gráfico 4: Resultado do questionário de usabilidade........................................................ 70
10
LISTA DE ABREVIATURAS E SIGLAS
ADOSARA - Associação de Doadores de Sangue Voluntários da Região da Amurel
ADSBD - Associação de Doadores de Sangue de Bom Despacho
AIDS – Síndrome da Imunodeficiência Adquirida
ANVISA – Agência Nacional de Vigilância Sanitária
API – Interface de Programação de Aplicativos
AWT – Abstract Window Toolkit
CASE – Engenharia de Software auxiliada por computador
CNAS - Conselho Nacional de Assistência Social
CPU – Unidade de Processamento Central
DER – Diagrama Entidade-Relacional
EJB – Enterprise Java Beans
ERP – Planejamento de Recursos Empresariais
GPL - General Public License
GPL – General Public License
HEMOBRÁS - Empresa Brasileira de Hemoderivados e Biotecnologia
HIV – Vírus da Imunodeficiência Humana
IBGE – Instituto Brasileiro de Geografia e Estatística
IDE – Ambiente Integrado de Desenvolvimento
IEC – Comissão Eletrotécnica Internacional
IPL – InterBase Public License
ISO – Organização Internacional para Padronização
JFC - Java Foundation Classes
JPA – Java Persistence API
JVM – Máquina Virtual Java
ODBC - Open Database Connectivity
OMS - Organização Mundial de Saúde
OO – Orientação a Objetos
PAC – Posto de Coleta Avançado
PDF – Formato de Documento Portável
PNVDS - Programa Nacional de Doação Voluntária de Sangue
POJO – Plain Old Java Object
POO – Paradigma Orientado a Objetos
11
PRÓ-SANGUE - Programa Nacional do Sangue
PSF – Posto de Saúde da Família
RAD - Rapid Application Development
SBHH - Sociedade Brasileira de Hematologia e Hemoterapia
SEFIP - Sistema Empresa de Recolhimento do FGTS e Informações à Previdência Social
SGBD – Sistema de Gerenciamento de Banco de Dados
SQL – Linguagem de Consulta Estruturada
SRS – Documento de Especificação de Requisitos
SUS – Sistema Único de Saúde
TI – Tecnologia da Informação
UML – Linguagem de Modelagem Unificada
XML – Extensible Markup Language
XP - Extreme Programming
12
SUMÁRIO
1 INTRODUÇÃO......................................................................... 14
1.1 Relevância do Projeto............................................................ 15 1.2 Problema e justificativa......................................................... 15 1.3 Objetivos do projeto............................................................... 16 1.3.1 Objetivo geral........................................................................ 17 1.3.2 Objetivos específicos............................................................. 17 1.4 Organização do projeto......................................................... 17
2 ASSOCIAÇÕES DE DOADORES DE SANGUE: CONTEXTUALIZAÇÃO............................................................
18
2.1 Considerações iniciais............................................................ 18 2.2 A doação de sangue no Brasil............................................... 19 2.3 – Organizações do terceiro setor: conceituação.................. 22 2.3.1 Associações de Doadores de Sangue.................................... 22 2.3.2 A Associação de Doadores de Sangue de Bom Despacho.... 26 2.4 Considerações finais............................................................... 29
3 TÉCNICAS E FERRAMENTAS PARA O DESENVOLVIMENTO DO ADSBD MANAGER...................
30
3.1 Considerações iniciais............................................................ 30 3.2 Engenharia de software......................................................... 31 3.3 UML......................................................................................... 36 3.4 Orientação a Objetos............................................................. 39 3.5 Tecnologias utilizadas............................................................ 41 3.6 Considerações finais............................................................... 52
4 METOLOGIA DE DESENVOLVIMENTO DO ADSBD MANAGER...................................................................................
53
4.1 Considerações inicial.............................................................. 53 4.2 Levantamento de requisitos................................................... 54
13
4.3 Análise de Requisitos e Projeto............................................. 54 4.3.1 Caso de uso: visão geral do sistema...................................... 56 4.3.2 Especificação do caso de uso Cadastrar doadores de Sangue............................................................................................
59
4.3.3 Modelo de Domínio.............................................................. 63 4.4 Análise Entidade-Relacional................................................. 65 4.5 Arquitetura do Software....................................................... 67 4.6 Implementação....................................................................... 68 4.7 Testes realizados......................................................... 69 4.8 Implantação............................................................................ 70 4.9 Apresentação do Sistema....................................................... 71 4.10 Considerações Finais............................................................ 74 5 CONSIDERAÇÕES FINAIS DO PROJETO......................... 75 5.1 Dificuldades enfrentadas....................................................... 75 5.2 Contribuições do projeto....................................................... 76 5.3 Trabalhos Futuros.................................................................. 76 5.4 Considerações finais............................................................... 77 REFERÊNCIAS........................................................................... 79
14
1 INTRODUÇÃO
A doação de sangue é um processo fundamental para a área da saúde, uma vez que
viabiliza vários procedimentos médicos. Devido ao elevado número de acidentes de trânsito,
doenças e processos cirúrgicos, a demanda de sangue vem crescendo em todo o mundo, sendo
comum deparar-se com situações nas quais ele está em falta. No Brasil, o percentual de
doadores de sangue está abaixo do recomendado pela OMS (Organização Mundial da Saúde)
e na tentativa de reverter este quadro, várias entidades do terceiro setor realizam um trabalho
de conscientização junto à sociedade, a fim de aumentar o número de doadores de sangue.
Entidades do terceiro setor não têm fins lucrativos e realizam diversos trabalhos de
cunho social, ajudando inúmeras áreas problemáticas da sociedade, incluindo-se a relativa à
doação de sangue. Sendo assim, as associações de doadores de sangue atuam como
facilitadoras do processo de doação, conscientizando a população e encaminhando doadores
aos hemocentros.
Este projeto mostra as necessidades gerenciais das associações de doadores de sangue
e aponta como a informatização pode trazer melhorias significativas para estas entidades.
Com o intuito de perceber estas necessidades, um estudo foi feito junto à Associação dos
Doadores de Sangue de Bom Despacho (ADSBD), localizada na cidade de Bom Despacho –
MG. Esta associação trabalha com grande volume de informações, pois, além de possuir um
cadastro de doadores de sangue e colaboradores financeiros, realiza o controle de uma série de
atividades internas.
Após a compreensão das necessidades gerenciais da ADSBD percebeu-se que a
implantação de um sistema informatizado auxiliaria, consideravelmente, a associação na
realização de suas atividades. Sendo necessário que o sistema realize buscas e atualizações de
cadastros de forma rápida e segura, proporcionando à entidade um ganho de eficiência e
tempo e que gere relatórios precisos em tempo hábil. A implantação do sistema traz um
aumento na disponibilização dos serviços e, conseqüentemente, facilita a ampliação do campo
de atuação da entidade.
Para se construir um software de qualidade, é preciso seguir os princípios da
Engenharia de Software, desde o levantamento de requisitos até a implantação. Então, a fim
de documentar e garantir confiabilidade, segurança e manutenabilidade a todo o software, o
desenvolvimento da aplicação gerencial para a ADSBD, o ADSBD Manager, seguiu estes
princípios.
15
O trabalho apresenta, portanto, um estudo sobre as necessidades gerenciais das
associações de doadores de sangue e as dificuldades enfrentadas neste processo. E, baseado
em um caso concreto, é desenvolvido um software para auxiliar no gerenciamento de uma
associação.
1.1 Relevância do Projeto
Conforme apresentado no tópico anterior, a doação de sangue se mostra um
procedimento importante para a sociedade. Porém conscientizar a população e, assim,
conseguir a quantidade adequada de doadores é algo complexo e que envolve um trabalho
muito grande. Na execução deste trabalho, destaca-se o papel das associações de doadores de
sangue, entidades sem fins lucrativos, que através do serviço voluntário desenvolvem projetos
e atividades para conscientizar a população da importância da doação de sangue.
A partir do estudo realizado junto a uma destas associações de doadores de sangue,
verificou-se que ela poderia ampliar consideravelmente suas atividades e projetos se seu
gerenciamento não fosse tão oneroso. Então, a fim de propiciar a esta entidade uma melhora
no seu gerenciamento foi proposto este trabalho, que além de pesquisas sobre doação de
sangue e terceiro setor, objetiva desenvolver um software que auxilie no gerenciamento desta
associação, facilitando seus procedimentos administrativos e possibilitando a ampliação de
seus projetos e atividades.
Esta ampliação de projetos e atividades é benéfica a toda sociedade, uma vez que o
percentual de pessoas conscientizadas e, conseqüentemente, o de doadores de sangue tendem
a crescer. Assim será possível que os estoques de sangue se mantenham sempre em um nível
bom, que atenda a demanda da população.
1.2 Problema e justificativa
As informações têm um papel fundamental para as organizações, e gerenciá-las de
modo eficiente é essencial para a conquista do sucesso. As organizações do terceiro setor não
são diferentes e precisam criar políticas para controlar suas informações, uma vez que lidam
com grande quantidade das mesmas. Estas entidades precisam ter um acesso rápido e um
controle muito grande sobre estas informações, para que consigam desenvolver suas
atividades e projetos.
16
Ao observar as associações de doadores de sangue, facilmente se identificam várias
informações manipuladas. São cadastros de doadores de sangue, controle de doações e
resultados de pesquisas de triagem. Controlar tantas informações se torna oneroso e
sobrecarrega os envolvidos no seu gerenciamento, além de dificultar o acesso às mesmas
dentro de um tempo hábil.
Diante da importância e da quantidade de informações, a maneira que vem se
mostrando mais eficiente para controlá-las é a utilização de sistemas informatizados. Estes
aplicativos são capazes de armazenar, manipular e disponibilizá-las a quem necessite, de
forma consistente e rápida. Pode-se afirmar que a utilização de softwares gerenciais é
essencial para que organizações atinjam seus objetivos e consigam consolidar-se no mercado.
Entidades do terceiro setor enfrentam obstáculos para a implantação de um software
gerencial, dos quais se destacam a falta de recursos financeiros para aquisição de um software
e a falta de aplicações que atendam as suas necessidades. Diante desta situação, a proposta
deste projeto, de estudar as necessidades gerenciais das associações de doadores de sangue e,
a partir de um caso real, desenvolver um aplicativo gerencial se mostra pertinente.
A partir do estudo realizado na ADSBD, percebeu-se que as principais dificuldades
apresentadas no seu gerenciamento estão relacionadas ao tempo gasto para o registro das
atividades internas, a busca e atualização de cadastros de doadores e colaboradores e a
produção de relatórios. Destaca-se também a complexidade para se produzir estes relatórios,
sendo necessário manipular grande quantidade de documentos.
Frente a estas dificuldades e a escassez de softwares destinados a estas entidades, o
desenvolvimento e a implantação de uma aplicação gerencial na ADSBD se mostra
importante para que a associação consiga otimizar seu gerenciamento e, assim, ampliar os
seus projetos. A utilização de um sistema informatizado resolve algumas dificuldades
apresentadas de maneira simples, como por exemplo, relatórios seriam gerados rapidamente,
sem a necessidade de ficar somando valores em vários formulários, diminuindo a margem de
erro. O tópico abaixo traz os objetivos explícitos deste projeto.
1.3 Objetivos do projeto
Esta seção apresenta os objetivos deste projeto, eles estão divididos entre os
específicos e um geral.
17
1.3.1 Objetivo geral
Adaptar os procedimentos gerenciais da Associação dos Doadores de Sangue de Bom
Despacho (ADSBD) ao uso de sistemas informatizados.
1.3.2 Objetivos específicos
• Desenvolver um sistema, o ADSBD Manager, utilizando técnicas da Engenharia de
Software, para auxiliar no gerenciamento da ADSBD;
• Mostrar a necessidade e a importância da informatização em uma associação dos
doadores de sangue;
• Descrever o impacto da informatização na ADSBD.
1.4 Organização do projeto
A fim de facilitar a compreensão do projeto, este trabalho foi elaborado em capítulos,
divididos conforme a abrangência de cada um.
O capitulo 2 apresenta a doação de sangue, seus procedimentos e a importância das
associações de doadores de sangue neste contexto. Descreve também a ADSBD e suas
necessidades gerenciais.
O capitulo 3 apresenta as tecnologias e ferramentas utilizadas no projeto de
desenvolvimento do ADSBD Manager, o sistema gerencial que auxiliará a ADSBD.
O capitulo 4 traz os passos do desenvolvimento do software, detalhando as etapas de
especificação de requisitos, modelagem da base de dados e desenvolvimento.
Por fim, o capitulo 5 traz as considerações finais mostrando dificuldades enfrentadas,
contribuições e possíveis melhorias para o projeto.
18
2 ASSOCIAÇÕES DE DOADORES DE SANGUE:
CONTEXTUALIZAÇÃO
Esta seção aborda a doação de sangue, contendo um breve histórico e uma descrição
da situação no Brasil e em Minas Gerais. Apresenta, também, a Associação de Doadores de
Sangue de Bom Despacho (ADSBD), entidade sem fins lucrativos, para qual foi desenvolvido
o software deste projeto. São mostradas suas necessidades, conquistas e sua importância para
a sociedade.
2.1 Considerações iniciais
A doação de sangue é considerada um procedimento fundamental para que os
profissionais da medicina possam salvar vidas. Como demonstra Moura et al (2006, p. 62), o
sangue captado nas doações, “é utilizado em diversas situações e doenças, como: cirurgias,
acidentes, anemias e outras”.
O processo de doação de sangue é um tanto complexo, uma vez que envolve doadores,
receptores, bancos de sangue, hospitais e as entidades filantrópicas que dão apoio a esta área.
De acordo com Gomes e Maia (2007) a doação é um grande processo divido em vários sub-
processos. Por exemplo, antes de efetuar a doação, o doador passa por triagens (clínica e
hematológica). Após a coleta, a bolsa de sangue passa por uma bateria de exames (hepatite,
HIV, chagas, entre outros) a fim de garantir a segurança do receptor. Cada bolsa coletada
possui um tempo limite para ser utilizada, este prazo se altera de acordo com os aditivos e
anticoagulantes utilizados, podendo variar de 21 a 42 dias.
Segundo Ludwig e Rodrigues (2005) o aumento da população mundial e os avanços
tecnológicos na área da medicina influenciam diretamente no aumento da demanda por
sangue, para tanto, exige-se que este tenha passado por exames que confirmem sua qualidade.
Este aumento na demanda está acontecendo em todo o mundo como evidenciado por Moura
et al (2006) ao afirmar que o crescente número de acidentes de trânsito, de doenças em geral e
de cirurgias são fatores que fazem esta procura crescer.
Levada por esta situação, a OMS observou ser importante estabelecer alguns critérios
para a doação e transfusão de sangue, e assim, definiu alguns parâmetros, como por exemplo,
que entre 3% e 5% da população de cada país deve ser considerada doadora voluntária de
sangue. A OMS acredita que com este percentual é possível atender a demanda atual. Na
19
Europa a média é de 5 doadores a cada 100 habitantes. Acredita-se que este elevado índice
(5% da população) se deve, entre outros fatores, ao fato do continente já ter passado por duas
grandes guerras e isso aumentou a solidariedade entre as pessoas (MOURA et al, 2006).
De acordo com Ludwig e Rodrigues (2005) o percentual de doadores voluntários de
sangue no Brasil, no ano de 2005, foi de 2,2%, índice abaixo do preconizado pela OMS. Entre
os principais obstáculos para se atingir o patamar desejado estão a dificuldade de
conscientização da população sobre a importância da doação, a falta de fidelidade dos
doadores, uma vez que muitos só realizam a primeira doação e não se tornam doadores
regulares, e o medo das pessoas em relação aos procedimentos para a coleta.
Com a intenção de facilitar o contato com doadores e com candidatos à doação,
existem associações de doadores de sangue espalhadas pelo Brasil. São entidades sem fins
lucrativos, que tem por objetivo facilitar o processo de doação de sangue, conquistar novos
doadores e manter aqueles já ativos. Após pesquisa junto à Sociedade Brasileira de
Hematologia e Hemoterapia (SBHH) e a Agência Nacional de Vigilância Sanitária
(ANVISA), constatou-se a não existência de estimativas sobre a quantidade de entidades com
este fim no Brasil.
2.2 A doação de sangue no Brasil
A doação de sangue no Brasil teve início efetivo em meados da década de 1920.
Segundo Gomes e Maia (2007), neste período eram realizadas apenas transfusões braço-a-
braço. Na década de 1940 aconteceram grandes evoluções como a criação do primeiro Banco
Nacional de Sangue, em 1943 e da Sociedade Brasileira de Hematologia e Hemoterapia
(SBHH), em 1949.
A primeira lei relacionada à doação de sangue foi sancionada em 1950, a Lei nº 1.075
que incentivava a doação voluntária de sangue. Atualmente a Lei nº 10.205, também
conhecida como “Lei do Sangue”, sancionada em 2001, regulamenta o processo e estabelece
os critérios de controle da doação de sangue e dos hemoderivados (GOMES E MAIA, 2007).
O QUADRO 1 apresenta os principais acontecimentos relacionados a doação de
sangue no Brasil.
20
QUADRO 1 Principais eventos relacionados a doação de sangue ocorridos no Brasil
Época Evento 1877
Década de 1920
Década de 1930
Década de 1940
1950
1965
1969
Década de 1970
1979
Década de 1980
1988
1998
2001
2004
Provável data da primeira transfusão de sangue, no Rio de Janeiro;
Doadores cadastrados, sangue não estocado e transfusões braço-a-braço;
Primeiro serviço organizado de transfusão de sangue, no Rio de Janeiro, transfusões braço-a-braço e sem exames de triagem no sangue do doador;
Primeiros bancos de sangue privados, remuneração pela doação de sangue, criação da Sociedade Brasileira de Hematologia e Hemoterapia (SBHH); Primeira lei federal, Lei nº 1.075 vigorou até 1964 e institui, entre outras coisas, o abono do dia de trabalho para doar sangue; Sancionada a Lei nº 4.071, dispõe sobre a atividade hemoterápica e é a base para a Política Nacional de Sangue;
A OMS realiza diagnóstico da situação da hemoterapia no país; Doadores de sangue em sua maioria remunerados; Sociedade Brasileira de Hematologia e Hemoterapia promove a doação voluntária de sangue; Criado o Programa Nacional do Sangue (Pró-Sangue) pelo Ministério da Saúde. Com o avanço dos casos de AIDS, aumenta a pressão nacional pela segurança transfusional; Constituição de 1988 veta a comercialização de sangue e hemoderivados;
Instituição da Meta Mobilizadora Nacional;
Sancionada a Lei nº 10.205, a Lei do Sangue;
Lei autoriza a criação da Empresa Brasileira de Hemoderivados e Biotecnologia (HEMOBRÁS).
Fonte: VERTCHENKO, 2005, p. 21 (adaptado). Segundo Vertchenko (2005), dentre os eventos citados no QUADRO 1 os abaixo
relacionados merecem maior destaque:
• a campanha de doação promovida pela SBHH, em 1979. Após a proibição da
remuneração pela doação, os estoques de sangue atingiram níveis baixíssimos e os
incentivos à doação voluntária cresceram;
• a criação do Pró-Sangue, em 1980. Este programa foi um marco no processo de
21
profissionalização da doação de sangue. Segundo Medeiros (2004) este programa
colocou um fim na mercantilização do sangue. Foi implantada uma rede de centros de
hematologia e hemoterapia nos estados e foi regulamentado o ressarcimento pelos
serviços prestados na coleta, processamento e transfusão do sangue, facilitando assim
a ampliação e a qualificação do processo de doação e transfusão de sangue;
• a instituição da Meta Mobilizadora Nacional, em 1998, pelo Ministério da Saúde. Foi
um ato visando garantir a qualidade em todo o processo de doação e transfusão de
sangue até 2003. Este é um grande projeto que engloba doze programas, merecendo
destaque o Programa Nacional de Doação Voluntária de Sangue (PNVDS), que tem
por objetivo aumentar a quantidade de doadores voluntários de sangue em todo o país.
A situação atual no Brasil não é muito favorável, ainda existe um déficit na relação
entre a quantidade necessária de bolsas e a quantidade coletada, porém uma melhora tem sido
notada ano a ano. O percentual de doadores voluntários, ou seja, pessoas que doam por boa
vontade, vem aumentando gradativamente, como demonstrado por Vertchenko (2005), em
1997 esse percentual era de 25%, já em 2002 chegou a 51% dos doadores. Isto mostra a
necessidade de se estabelecer políticas públicas sérias, como o PNDVS e a Meta
Mobilizadora, para tratar deste assunto tão importante para a sociedade, e assim atingir o nível
desejado de doadores no Brasil.
A estruturação da hemorrede pública em Minas Gerais iniciou-se em 1985, como fruto
do Pró-Sangue, com a criação da Fundação Centro de Hematologia e Hemoterapia de Minas
Gerais, o Hemominas, sendo instalado o hemocentro coordenador em Belo Horizonte. A
descentralização do serviço começou em 1987, para agilizar o processo e diminuir custos.
Para isto, o Hemominas estabeleceu convênios de cooperação mútua com prefeituras e
universidades em todo o estado (VERTCHENKO, 2005).
O Hemominas conta com 23 centros regionais, distribuídos pelo estado, e mantém
convênios com prefeituras e universidades. De acordo com a Fundação Hemominas (2009) a
ela é responsável por 87% das transfusões no estado, o restante é realizado em bancos de
sangue vinculados a hospitais particulares.
Em relação aos doadores, Minas Gerais se encontra numa situação semelhante ao
restante do país, faltam doadores voluntários. Vertchenko (2005) mostra que, apenas 1,11%
da população do estado doou sangue em 2002. Este percentual está abaixo da média nacional,
e do percentual preconizado pela OMS.
É importante que o Hemominas continue atuando e que amplie sua rede de convênios
22
para atingir o nível esperado de doadores e bolsas de sangue. Nesta ampliação da rede é
fundamental o relacionamento com as associações de doadores de sangue, uma vez que estas
entidades desempenham um papel importante na fidelização do doador e na conscientização
de mais pessoas, a fim de conseguir um número maior de doadores.
2.3 – Organizações do terceiro setor: conceituação
Soares, Catão e Santos (2004) definem organizações de terceiro setor como entidades
sem fins lucrativos que atuam nas áreas sociais, como a saúde, o lazer e o desenvolvimento
humano. Estas instituições apresentam um conjunto peculiar de características: não visam
lucratividade, não são governamentais, são organizadas, independentes, articuladas e
promovem os interesses coletivos.
Neste contexto é importante definir que o chamado primeiro setor, é o estado, a
administração pública e o segundo é o mercado, as organizações privadas, com fins
lucrativos. O terceiro setor é, portanto, uma nomenclatura utilizada para designar as
instituições que apresentam uma conjunção entre a finalidade do primeiro setor e a
metodologia de trabalho do segundo, ou seja, são agentes privados que agem para fins
públicos (AGUIAR E SILVA, 2001).
O gerenciamento das informações nas entidades do terceiro setor é complexo, devido
principalmente, à variedade de setores que elas atendem, ao fato de não existir uma
padronização nas informações que manipulam, uma vez que cada entidade busca se estruturar
da melhor maneira dentro de seu contexto. Por exemplo, ao se observar um grupo de
associações de doadores de sangue, é possível identificar formas distintas de gerenciamento.
Para minimizar essas dificuldades de gerenciamento, a utilização de sistemas
informatizados pode ser vista como uma possível solução. Um software facilita o fluxo das
informações dentro da entidade, dando maior consistência e confiabilidade nos procedimentos
administrativos.
2.3.1 Associações de Doadores de Sangue
As associações de doadores de sangue, como citado, desempenham um papel
importante no contexto da doação. Estas entidades, normalmente, são mantidas por doações
financeiras de cidadãos, empresas e em alguns casos, contam com um auxilio da
23
administração pública
Estas associação são criadas com o intuito de propiciar mais segurança e agilidade ao
processo de doação. Normalmente, elas mantêm um cadastro de doadores – o que facilita a
localização e o encaminhamento destes aos hemocentros; realizam atividades de
conscientização da população visando conquistar novos doadores e fidelizar os já ativos. O
grande objetivo destas entidades é auxiliar na manutenção de bons níveis nos estoques de
sangue.
De acordo com Moura et al (2006, p.62 apud Ministério da Saúde, 1998) o processo de
fidelização de doadores consiste em “mudar gradualmente o perfil do doador brasileiro e,
enfim, garantir a quantidade e qualidade do sangue”. Isso compreende um conjunto de
atividades voltadas para que o doador não realize somente a primeira doação e sim, para que
este se conscientize da importância da doação regular de sangue.
É fundamental para o sucesso de uma associação de doadores de sangue criar meios de
fidelizar os doadores. Porém definir esta estratégia não é tão simples. De acordo com Ludwig
e Rodrigues (2005) são vários os aspectos a serem observados nesta definição. É preciso
medir a reação (satisfação) dos doadores, ter um bom atendimento, oferecer serviços com
rapidez, cordialidade e resolver os problemas que surgirem. Outro ponto interessante neste
processo de fidelização é a divulgação das atividades, necessidades e conquistas da
associação, o que transmite uma idéia de transparência e comprometimento.
Algumas associações têm adotado técnicas de marketing para auxiliar na definição da
estratégia a ser adotada para a fidelização e conquista de novos doadores. Essas técnicas são
conhecidas como marketing social, que visam atingir o maior número de pessoas e fornecer
informações objetivas e de fácil compreensão. O Hemocentro de Cascavel, no Paraná, tem
obtido bons resultados com a implantação de modelos baseados no marketing social para a
divulgação de suas atividades. O hemocentro vem conseguindo erradicar a falta de doadores e
aumentar o percentual de doadores regulares e voluntários de sangue (MEDEIROS, 2004).
As associações de doadores de sangue desempenham, portanto, um relevante papel no
processo de coleta de sangue. Auxiliam hospitais e hemocentros, diminuindo,
consideravelmente, o fluxo de pessoas e documentos nestas organizações. Então, torna-se
necessário criar meios para o surgimento de novas associações e para que as já constituídas
melhorem a qualidade de seus serviços. Assim, será mais fácil que o Brasil atinja o percentual
e a qualidade desejada de doadores e bolsas de sangue.
24
• A importância da informação no contexto de uma associação de doadores de sangue
Segundo Freitas e Kladis (1995), as informações são conjuntos de dados processados
de maneira lógica e significativa, para que tenham um valor real no contexto organizacional.
Elas são recursos fundamentais dentro de qualquer organização, com ou sem fins lucrativos.
Daí a importância de se estabelecer uma política de informação consistente e adequada.
Afinal, informações bem construídas e bem apresentadas possibilitam vantagens competitivas
e facilitam os processos administrativos e de tomada de decisão dentro de qualquer
organização.
As associações de doadores de sangue trabalham com um fluxo considerável de
informações: são doadores, receptores, coletas e atividades gerenciais. Neste contexto, o
correto gerenciamento das informações traz benefícios como a facilitação e a diminuição do
tempo gasto com o seu gerenciamento, o aumento da segurança e da confiabilidade nas suas
atividades.
Para Vitorino, Costa, Kenchian (2008) a implantação de uma política de informação
na área da saúde deve considerar, além de outros fatores, os seguintes aspectos: segurança,
sigilo e acessibilidade. Em uma associação de doadores de sangue o sigilo dos dados sobre
doadores é fundamental, e deve ser bem implantado. Para evitar problemas com divulgações
indevidas e para melhorar a qualidade e a agilidade no gerenciamento é importante que essas
associações possuam recursos para implantar uma boa política de informação.
• A informatização do gerenciamento das associações
Os computadores e a informática, de um modo geral, são de grande valor para a
sociedade e estão presentes em diversos segmentos, desde os mais simples, como no lazer e
na comunicação entre pessoas até os mais complexos, como as cirurgias médicas. O processo
de informatização teve início na década de 1960 e continua evoluindo até os dias de hoje,
sempre buscando atender as necessidades das pessoas e organizações (SHIGUNOV NETO E
TEIXEIRA, 2006).
Dentro das organizações a utilização de sistemas informatizados tem se mostrado
muito eficiente no gerenciamento das informações. A utilização deste tipo de recurso se
destaca principalmente por suportar vários processos empresariais, como a tomada de decisão,
controle de estoque e pessoal e por dar confiabilidade e disponibilizar, em tempo adequado às
informações a quem necessite delas (FREITAS E KLADIS, 1995 apud BIO, 1991).
25
Nota-se a necessidade que as organizações, de um modo geral, têm, em aperfeiçoarem
seus procedimentos gerenciais para que consigam obter bons resultados. Este processo de
aperfeiçoamento tem passado, constantemente, pela implantação de sistemas informatizados,
uma vez que esses tornam menos onerosos os procedimentos, trazem maior confiabilidade,
agilidade e consistência às informações (SOARES, CATÃO E SANTOS, 2004).
Organizações do terceiro setor, como as associações de doadores de sangue, são
ambientes onde a implantação de sistemas informatizados se mostra viável, devido à
quantidade e ao fluxo de informações nelas. Porém, este processo esbarra em dois aspectos
relevantes. Primeiro, a falta de recursos financeiros destas entidades para a aquisição de um
software ou para a estruturação de um projeto de desenvolvimento de um. E, em segundo
lugar, a dificuldade de se encontrar sistemas que realmente atendam as suas necessidades.
• Softwares existentes para o terceiro setor
As entidades do terceiro setor têm apresentado uma demanda considerável por
softwares gerenciais. Esta procura vem aumentando porque, com a utilização de sistemas
informatizados, obtém-se um ganho de eficiência, confiabilidade, consistência e tempo. Nesta
perspectiva, foram pesquisados alguns softwares destinados para estas entidades.
Encontrar softwares destinados ao terceiro setor não é simples e entre os encontrados o
Master Manager ou Sistema de Gerenciamento de Fundações, desenvolvido pela Gemini
Sistemas foi o que mais se aproximou do ponto desejado. É um software destinado ao
gerenciamento de qualquer fundação. Sendo possível adaptá-lo ao modelo administrativo de
cada instituição. Possui também alguns módulos específicos, como o de gestão de projetos
que funciona integrado com o de gestão financeira e contábil, o que facilita o gerenciamento
de atividades mais específicas das organizações (GHIGNATTI, STEFFEN E TURCHETO,
2007).
Outro sistema é o Radar Empresarial, desenvolvido pela WK Sistemas. É um software
que segue a linha dos ERP’s, um conjunto de sistemas interligados para o gerenciamento
completo de uma instituição. É destinado a todas as organizações podendo ser adaptado a uma
entidade do terceiro setor. Possui um módulo para o gerenciamento de projetos, controlando a
parte financeira e de pessoal, que é um ponto interessante para o terceiro setor. Porém ele é,
assim como o Master Manager, um sistema pago, o que pode inviabilizar sua implantação em
algumas entidades (GHIGNATTI, STEFFEN E TURCHETO, 2007).
26
No que tange o gerenciamento de associações de doadores de sangue, foi identificado
um sistema específico desenvolvido pela Tecmedia Internet Design, de Santa Catarina. Na
realidade, a empresa desenvolveu um módulo baseado na sua plataforma de desenvolvimento,
que é responsável pelo cadastro dos doadores e das doações. O sistema é utilizado pela
Associação de Doadores de Sangue Voluntários da Região da Amurel (ADOSARA) situado
no município de Capivari de Baixo – SC. Os principais benefícios com a implantação do
sistema foram a facilitação do acesso aos doadores e a rapidez no encaminhamento destes às
solicitações dos hemocentros (PORTAL TECMEDIA, 2008).
Segundo Soares, Catão e Santos (2004) a falta de softwares destinados ao terceiro
setor é uma lacuna que deve ser preenchida o mais rápido possível pelos profissionais e
empresas de TI, a fim de possibilitar a entidades deste setor um melhor gerenciamento de suas
atividades e uma ampliação nos seus projetos.
2.3.2 A Associação de Doadores de Sangue de Bom Despacho – MG
O município de Bom Despacho, localizado no centro-oeste mineiro, a
aproximadamente 145 quilômetros de Belo Horizonte, tem uma população, segundo IBGE
(2007) de 42.460 habitantes. Na área da saúde, conta com 2 hospitais, sendo um particular e
outro conveniado ao SUS, 8 Postos de Saúde da Família (PSF), 1 policlínica, 1 centro de
saúde e 1 pronto atendimento (SIAB, 2008).
A população do município sofria com a falta de doadores aptos e disponíveis para
atender a demanda de sangue da cidade e também com a dificuldade para se deslocar até os
hemocentros para realizarem a doação, uma vez que o hemocentro mais próximo está sediado
em Divinópolis, a aproximadamente 80 quilômetros. Percebendo tal realidade e a gravidade
do problema enfrentado, no ano 2000, por iniciativa do então Vigário da Paróquia Matriz de
Nossa Senhora do Bom Despacho, Padre João Lúcio Gomes Benfica, iniciou-se uma
campanha para a fundação de uma associação que facilitasse o processo de doação de sangue
na cidade (REQUERIMENTO CNAS, 2007).
Então, com o propósito de fundar esta associação, foi realizada em 17 de maio de
2000, uma reunião pública na qual foi eleita uma comissão voluntária para a criação da
associação de doadores de sangue na cidade. O estatuto foi aprovado em 05 de fevereiro de
2001 e registrado em cartório em 03 de outubro do mesmo ano, sendo assim criada a
Associação dos Doadores de Sangue de Bom Despacho (ADSBD). A ADSBD tem por
27
objetivos principais facilitar o processo de doação de sangue, auxiliar as agências
transfusionais de Bom Despacho e região e promover a conscientização da população sobre a
importância de se doar sangue (ESTATUTO ADSBD, 2008).
A associação é composta por uma diretoria eleita a cada 2 anos e conta com uma
equipe de funcionários, alguns contratados, outros cedidos pela Câmara Municipal e, também
com voluntários, para a realização de suas atividades. Ela é mantida através de colaborações
financeiras. A quantidade de colaboradores gira em torno de 500, em algumas ocasiões, ela
recebeu repasse da administração pública estadual e municipal. Em 2008, a ADSBD possuía
2118 doadores de sangue cadastrados (RELATÓRIO ANUAL CIRCUNSTANCIADO ANO
BASE 2008, 2009).
Dentre muitas conquistas da associação, destacam-se a criação da Lei Municipal n°
1.876/2002, que estabeleceu a introdução do conteúdo programático multidisciplinar “doação
de sangue, tecidos e partes do corpo”, na Rede Municipal de Ensino; a conquista de uma sede
junto ao município e as 11 coletas de sangue realizadas na cidade, em parceria com o
Hemominas. A entidade foi reconhecida de Utilidade Pública Municipal pela Lei n° 1.880 de
01/04/2002, de Utilidade Pública Estadual pela Lei n° 16.275 de 18/07/2006 e de Utilidade
Pública Federal pela portaria n° 266 de 24/02/2006 (REQUERIMENTO CNAS, 2007).
A entidade vem pleiteando uma certificação junto ao Conselho Nacional de
Assistência Social (CNAS), que lhe permitirá receber subsídios do governo federal e, assim,
ampliar suas atividades e dar a elas uma maior qualidade. O processo está transitando desde
2007 no Ministério do Desenvolvimento Social e Combate à Fome, porém é muito complexo
e exige muitos requisitos, como o título de Entidade de Utilidade Pública Federal, o qual a
ADSBD já possui. A fim de manter este título, a entidade produz o Relatório Anual
Circunstanciado, que é enviado ao Ministério da Justiça, contendo todas as atividades
desenvolvidas. Este relatório é muito complexo e é produzido conforme o modelo enviado
pelo Ministério, que, normalmente passa por alterações todo ano (REQUERIMENTO CNAS,
2007).
Desde o seu surgimento, a ADSBD vem buscando conscientizar a população bom-
despachense sobre a importância da doação de sangue, para, assim, conseguir o número
necessário de doadores e bolsas. Vem desenvolvendo projetos, dos quais merece maior
destaque o Projeto Futuro Doador, que trabalha com as crianças e adolescentes nas escolas da
cidade, promovendo a conscientização destes. Desde o início de 2009 busca uma parceria com
o Hemominas para criar em Bom Despacho um Posto de Coleta Avançado (PAC), que
28
permitirá a realização de coletas mensais no município, o que facilitará para os doadores, uma
vez que não precisarão se deslocar para outras cidades.
Nos últimos anos a ADSBD tem conseguido alcançar a quantidade necessária de
bolsas para atender as necessidades do município, inclusive, em alguns anos foram coletadas
mais bolsas que o necessário, sendo essas repassadas a outros municípios. O GRAF. 1
apresenta a evolução da quantidade de bolsas coletadas. Em 2008, por exemplo, foram
coletadas 585 bolsas de sangue enquanto a demanda do município foi de 315. É clara a
melhora no processo de doação desde a criação da ADSBD e a sua importância para Bom
Despacho e região (RELATÓRIO ANUAL CIRCUNSTANCIADO ANO BASE 2008, 2009).
GRÁFICO 1 – Evolução da quantidade de bolsas coletas e a quantidade utilizada em Bom Despacho Fonte: RELATÓRIO ANUAL CIRCUNSTANCIADO ANO BASE 2008, 2009.
• A estrutura organizacional da ADSBD
As principais atividades administrativas da ADSBD estão relacionadas à manipulação
de informações cadastrais de doadores de sangue e colaboradores financeiros. São
gerenciadas, também, todas as doações de sangue realizadas por doadores cadastrados na
associação. Desta forma é possível manter um cadastro atualizado que permite identificar, de
maneira confiável, um doador ou colaborador.
O gerenciamento das atividades internas da associação é outro ponto importante. São
controladas 39 atividades, que vão desde o envio de correspondências até o gerenciamento do
número de bolsas coletas e utilizadas. Estas atividades são a base para a produção do
29
Relatório Circunstanciado Anual e obtenção de um monitoramento constante do nível de
qualidade dos serviços prestados pela entidade.
A produção de relatórios é outro ponto fundamental para o correto gerenciamento da
associação. São produzidos relatórios simples, como o de aniversariantes de um mês e
complexos como Relatório Circunstanciado Anual. A partir do resultado destes é possível
identificar falhas administrativas, estruturar rotinas de trabalho e planejar projetos da
instituição.
Neste tópico foram apresentadas as principais atividades administrativas da ADSBD, a
fim de elucidar sua metodologia de trabalho e permitir uma melhor compreensão do seu
funcionamento.
2.4 Considerações finais
Esta seção apresentou um histórico da doação de sangue, a situação no Brasil, em
Minas Gerais e também no município de Bom Despacho - MG. Sendo discutida a importância
e a posição das associações de doadores de sangue para a sociedade e como a informatização
pode auxiliar no gerenciamento destas. Por fim, foi apresentada a ADSBD, a associação de
doadores de sangue que será a base para o desenvolvimento deste projeto. Foram mostrados
seus objetivos, conquistas e funcionamento.
Os tópicos a seguir irão apresentar a estrutura, o desenvolvimento, os resultados e
possíveis melhorias para este projeto.
30
3 TÉCNICAS E FERRAMENTAS PARA O
DESENVOLVIMENTO DO ADSBD MANAGER
Esta seção aborda as técnicas utilizadas durante o desenvolvimento da aplicação,
contendo toda a linha de pesquisa, desde metodologias de desenvolvimento de software até as
ferramentas utilizadas. Sendo mostrado como os processos de desenvolvimento de software
podem ajudar na elaboração de projetos, além de demonstrar a importância da modelagem
UML e da análise de ferramentas de desenvolvimento para a construção de um software que
atenda a uma entidade do terceiro setor.
3.1 Considerações iniciais
A implantação de sistemas nas mais diversas áreas, tem se tornado cada vez mais
comum. E isso não é diferente dentro de uma associação de doadores de sangue. É importante
que sistemas voltados para o terceiro setor sejam desenvolvidos de forma a atender as
expectativas das organizações.
Quando falamos de sistemas de software, temos o conceito de que o software é apenas
o produto final, que passou do ambiente de produção para o ambiente comercial, mas não é
bem assim. O conceito de software é muito mais amplo, abrange toda a documentação,
arquivos de configuração e o conjunto de programas que são necessários para sua execução.
Software não é apenas o programa, mas também todos os dados de documentação e configuração associados, necessária para que o programa opere corretamente. Um sistema de software consiste, geralmente, de u m conjunto de programas separados; arquivos de configuração, que são utilizados para configurar os programas, documentação do sistema, que descreve a estrutura do sistema; a documentação do usuário, que explica como usar o sistema; e sites Web por meio dos quais os usuários obtêm informações recentes sobre o produto. (SOMMERVILLE, 2007, p 4).
Dada a complexidade e a amplitude de um software, estruturá-lo de uma forma
organizada e definir uma metodologia são fundamentais para se obter sucesso na implantação
de qualquer sistema, desde seu desenvolvimento até a aceitação do usuário. Nos tópicos
seguintes serão abordadas técnicas da engenharia de software e as ferramentas que foram
utilizadas durante as fases de elaboração, análise e desenvolvimento do projeto.
31
3.2 Engenharia de software
Engenharia de software pode ser definida como uma disciplina da engenharia que
aborda todos os aspectos do desenvolvimento do software, desde a concepção até a sua
implantação e manutenção (SOMMERVILLE, 2007). Esta disciplina tem por objetivo
auxiliar os engenheiros de software na elaboração de projetos mais concisos, aumentando
consideravelmente a qualidade do produto final.
A formação do conceito de engenharia de software começou a partir de 1968, após
uma conferência que tinha como objetivo discutir a chamada “crise do software”. Esta crise
ocorreu por que os equipamentos de hardware não acompanhavam a evolução dos softwares,
e estes, por sua vez, se tornavam cada vez mais complexos. A falta de padronização
dificultava ainda mais a manutenção destes no ambiente comercial. Nesta conferência foram
levantados vários aspectos referentes à produção de software e a partir destes conceitos foram
desenvolvidos, ao longo dos anos, várias técnicas que auxiliam os desenvolvedores no
planejamento e na execução de projetos de software.
A aplicação errônea ou a ausência destas técnicas no desenvolvimento tem custado
caro para as organizações. Para se ter uma idéia, uma aplicação que não segue os padrões de
desenvolvimento de software, geralmente consome cerca de 70% do tempo do seu ciclo de
vida com a manutenção. Isto mostra a importância da engenharia de software desde a fase de
levantamento de requisitos até a manutenção (Prado et al, 2005). O GRAF. 2 mostra o ciclo
de vida de um software sem um processo definido de desenvolvimento.
GRÁFICO 2 – Ciclo de vida de um software sem um processo definido de desenvolvimento Fonte: PRADO et al , 2005, p.5
Como podemos notar, a ausência das técnicas da engenharia de software tem impacto
direto nos custos e no tempo de desenvolvimento, sendo os maiores esforços concentrados na
32
fase de manutenção. Este esforço excessivo prejudica não só os projetos futuros, mas também
os que estão em andamento. Para diminuir este impacto, as organizações podem adotar
algumas metodologias, ou um conjunto delas, descritas pela engenharia de software, aliadas a
ferramentas que agilizam o desenvolvimento. O GRAF. 3 mostra um ciclo de vida de um
software com uma metodologia definida.
GRÁFICO 3 – Ciclo de vida aplicando técnicas da Engenharia de Software. Fonte: PRADO et al , 2005, p.5.
Para se obter sucesso na aplicação destas técnicas, deve-se levar em conta quais são os
modelos de processos adequados para o projeto em questão e quais as melhores práticas
devem ser efetivamente executadas, para garantir a qualidade e atender as expectativas das
organizações.
• Metodologia em Cascata
Segundo Tavares (2005), “o modelo em cascata consiste em um conjunto de técnicas
para fases particulares do processo de software”. Ou seja, cada etapa do desenvolvimento se
interage somente com a etapa posterior e esta só é iniciada quando a anterior é finalizada. Ao
término de cada etapa é gerada uma saída que será a entrada para a próxima fase. A FIG. 1
mostra as relações entre as etapas da metodologia em cascata.
33
FIGURA 1 – Metodologia em cascata. Fonte: VASCONCELOS et al , 2006, p.28.
O modelo em cascata separa muito bem cada fase de desenvolvimento. Na fase de
definição de requisitos são elucidadas todas as funcionalidades do sistema juntamente com o
cliente. A partir desta fase, a equipe de análise e projeto elabora as especificações, o sistema é
implementado e testado. O cliente só volta a ter contato novamente com a equipe na fase de
operação e manutenção.
Um dos pontos fortes da metodologia em cascata é a produção pesada de
documentação, que auxilia os analistas na modelagem e especificação dos requisitos. Dentre a
documentação produzida podemos destacar o documento visão e o documento de
especificação de requisitos de software (SRS). Cada um destes documentos expressa as
funcionalidades em uma perspectiva diferente. O documento visão apresenta um panorama
inicial do sistema em alto nível, de forma que todos os envolvidos no sistema compreendam.
Já o SRS é a declaração oficial do que os desenvolvedores do sistema devem implementar e o
que é esperado pelo cliente (CAVALHO, TAVARES e CASTRO, s/a).
Uma outra vantagem da metodologia em cascata é a flexibilidade para se adaptar a
outras metodologias da engenharia de software. Esta característica permite que as empresas
desenvolvedoras aproveitem as melhores práticas de um conjunto de outras metodologias,
criando um modelo híbrido adaptável à sua realidade.
Um dos grandes problemas em se aplicar esta metodologia está na divisão inflexível
do projeto em estágios distintos e nos custos elevados para sua execução. Como o
relacionamento com o cliente é feito apenas nas fases iniciais do desenvolvimento, isso causa
um congelamento prematuro dos requisitos, dificultado a identificação e a correção de erros
no projeto (SOMMERVILLE, 2007).
Durante a fase de coleta e análise de requisitos do ADSBD Manager, foram aplicadas
as técnicas da metodologia em cascata, por possuir boa carga de documentação,
34
proporcionando, assim, uma especificação detalhada de requisitos, expondo a todos os
envolvidos quais as funcionalidades do sistema.
• Metodologia em espiral
Com o aumento da complexidade e dos custos de produção, o modelo em cascata
estava se tornando um obstáculo para projetos de software, devido à sua rigidez entre fases e à
sua limitação em absorver mudanças de requisitos. A partir desta visão, iniciou-se, dentro da
engenharia de software, discussões sobre formas alternativas de desenvolvimento, que
resultou nos modelos iterativos.
A metodologia em espiral foi uma das primeiras técnicas desenvolvidas baseada na
evolução incremental do software. Em vez de se especificar todas as funcionalidades no início
do projeto, são planejadas uma série de iterações e, ao final de cada iteração, tem-se uma
porção da aplicação pronta para o ambiente comercial (VASCONCELOS, 2006). A FIG. 2
mostra uma visão geral da metodologia em espiral.
FIGURA 2 – Visão geral das fases propostas pelo modelo espiral Fonte: Sommerville, 2007
No desenvolvimento do ADSBD Manager, durante a fase de análise, desenvolvimento
e implantação foram utilizadas as melhores práticas da metodologia em espiral,
principalmente, por agregar aspectos gerencias ao processo de desenvolvimento, facilitando o
encontro e correção de erros, além de auxiliar no planejamento do projeto.
35
• Metodologia Extreme Programming (XP)
A Extreme Programming (XP) é uma das mais conhecidas metodologias ágeis. Este
tipo de abordagem surgiu na década de 1990, devido à insatisfação dos desenvolvedores com
a extensa documentação que era produzida, em virtude das metodologias existentes. Consiste,
basicamente, na abordagem interativa para a especificação, desenvolvimento e entrega do
software, tornando, assim, o trabalho da equipe de desenvolvimento focada apenas no
produto final, sem se preocupar com a documentação do projeto (SOMMERVILLE, 2007).
O processo XP é voltado para o desenvolvimento de softwares orientado a objetos,
com equipes pequenas e que dão suporte ao desenvolvimento incremental, ou seja, desde o
início do projeto são lançados pequenos releases até que se tenha um produto final completo.
As práticas pregadas pelo processo são: a integração do cliente com a equipe de
desenvolvimento; o aceite do usuário a cada novo release; a simplicidade de se implementar
estritamente o que o cliente necessita; a coragem de se produzir quase nenhuma
documentação e acreditar que o software será capaz de evoluir com segurança e agilidade
(TELES, 2006).
Segundo Astels (2002) a Extreme Programming agrega as dez melhores práticas de
um processo de desenvolvimento de software, sendo, assim, ideal para projetos que tenham
requisitos vagos e que mudam constantemente. Dentro dos seus princípios, um dos que mais
chama a atenção é a programação em pares: um desenvolvedor codifica e o outro age como
revisor, ajudando-o a encontrar e corrigir erros de ortografia e sintaxe, além de oferecer idéias
e sugestões. A interação da equipe leva à criação de padrões e à constante revisão do código
que também são pontos chaves do processo, o que torna o código mais enxuto e simples de
ser interpretado.
O que torna a XP difícil de ser executada, segundo Back (2004), é reunir todas as
peças e mantê-las unidas, uma vez que envolve a mudança de cultura da própria equipe, a
capacidade de cooperação e a integração de todos de forma harmônica. Outro ponto que pode
fazer a XP fracassar é a adoção de grandes times de desenvolvedores, clientes desconfiados e
tecnologias que não suportam efetivamente as modificações constantes no software.
Neste projeto, na fase de desenvolvimento do software, serão adotadas melhores
práticas da Extreme Programming, como, por exemplo, a programação em pares, que irá dar
um suporte para que se produza um software de qualidade, seguindo padrões na parte de
codificação e acelerando o desenvolvimento do projeto.
36
3.3 UML
A Unifield Modeling Language (UML) surgiu da necessidade de se padronizar a
modelagem orientada a objetos. Ela é uma união de três notações principais e de uma série de
técnicas de modelagem retiradas de várias metodologias utilizadas no mercado, desde a
década de 1970. Segundo Pender (2004) “a UML permite que os desenvolvedores de sistemas
especifiquem, visualizem e documentem os modelos de uma maneira que admita a
escalabilidade, a segurança e a execução robusta”, ou seja, eleva o nível de abstração por todo
o processo, facilitando a identificação de padrões de comportamento.
Neste contexto, um modelo pode ser entendido como uma forma simplificada e
abstrata de se representar uma situação concreta, servindo de referência para a realização de
estudos e análises. Com isso, a padronização destes modelos se mostra importante, uma vez
que facilita a compreensão de todos os envolvidos no processo de desenvolvimento de um
software.
A UML não é uma linguagem, portanto, ela pode ser adotada e adaptada para os mais
diversos processos de desenvolvimento de software. Seus diagramas abrangem várias
perspectivas de um sistema, o que torna a sua utilização bem flexível e robusta. As principais
visões da UML são assim definidas por Booch, Rumbaugh, Jacobson (2005):
• A visão de casos de uso descreve o comportamento do sistema visto pelos usuários
finais.
• A visão de projeto dá suporte aos serviços que o sistema deverá oferecer.
• A visão de interação cuida principalmente de questões referentes ao desempenho e
escalabilidade.
• A visão de implementação abrange os componentes e os artefatos do sistema.
• A visão de implantação aborda aspectos de distribuição, fornecimento e instalação do
sistema físico.
Os diagramas da UML serão amplamente utilizados neste projeto, a fim de prover uma
maior precisão e confiabilidade na análise de requisitos. A documentação do software
utilizará dos diagramas de casos de uso, pacote, atividade, seqüência e classes, uma vez que
abrangem as várias visões do sistema e proporcionam a todos os envolvidos, no sistema, uma
maior clareza das regras de negócio do mesmo. Os motivos que levaram à escolha destes
diagramas serão demonstrados a seguir.
37
• Diagrama de casos de uso
Os diagramas de casos de uso são utilizados para fornecerem visões dinâmicas do
sistema. Sua aplicação pode fornecer várias formas de visualizar um projeto.
Diagramas de casos de uso fornecem um modo de descrever a visão externa do sistema e suas interações com o mundo exterior, representando uma visão de alto nível de funcionalidade intencional mediante o recebimento de um tipo de requisição do usuário (FURLAN,1998, 169).
Desta forma, os diagramas de casos de uso descrevem os requisitos funcionais,
delimitando as responsabilidades e oferecendo possíveis situações do mundo real para o teste
do sistema.
Um modelo de casos de uso consiste basicamente na relação entre atores e casos de
uso. Os atores representam os usuários ou outros sistemas que irão interagir com o caso de
uso. Já os casos de uso mostram o comportamento do sistema, cenários que o sistema percorre
em resposta a uma ação do ator. (ALMEIDA, 2001).
Dentro do diagrama, o relacionamento entre um ator e um caso de uso representa a
participação deste no caso de uso. Entre os casos de uso, existem outras duas relações: a
relação de estender (representada pelo estereótipo <<extends>>) e a relação de incluir
(representada pelo estereótipo <<include>>). A relação de estender significa que, dentro do
caso de uso de destino pode ou não incluir aquele caso de uso, já a relação de incluir,
significam que o caso de uso de destino tem que ser executado para que o comportamento do
caso de uso de origem seja realizado (ALMEIDA E DAROLT, 2001).
• Diagrama de Classes
O diagrama de classes é usado, freqüentemente, em análises orientadas a objetos por
mostrar a visão estática de um projeto de software. Um diagrama de classes mostra um
conjunto de classes, interfaces, colaborações e seus relacionamentos, servindo de base para
uma série de outros diagramas, como o de componentes e o de implantação. Eles são
importantes não só para a visualização, a especificação, e a documentação de modelos
estruturais, mas também para a construção de sistemas executáveis utilizando a engenharia de
produção e a reversa (BOOCH, RUMBAUGH, JACOBSON, 2005).
38
A utilização do diagrama de classes dá suporte para os requisitos funcionais de um
sistema, ou seja, os serviços que o sistema deverá oferecer aos usuários finais. Sua aplicação
pode atingir desde a delimitação do vocabulário de um sistema até a modelagem de
colaborações simples e de banco de dados. Há quatro tipos principais de relacionamento no
diagrama de classes: generalização e/ou especificação (elementos indicadores de herança),
agregação (usada para denotar relacionamentos todo/parte), associação (usada para denotar
classes não correlatas) e dependência (indicando que um elemento é dependente do outro),
tendo, assim, todos os elementos semânticos para uma compreensão do domínio da aplicação
(FURLAN, 1998).
• Diagramas de seqüência
O diagrama de seqüência é classificado como um diagrama comportamental, ou seja,
representam como os objetos se comportam utilizando a estrutura já definida em outros
diagramas. Esta capacidade dinâmica pode abranger de que forma o sistema responde depois
de uma ação do usuário. Representado como o sistema mantém a integridade interna dos
dados, como estes são movidos do armazenamento para uma visão do usuário (PENDER,
2004).
O diagrama de seqüência dá ênfase à ordenação temporal das mensagens, sendo
utilizado não só para a visualização, especificação, construção e documentação, mas também
para fazer a modelagem de um fluxo de controle de um caso de uso e auxiliar na construção
de sistemas executáveis (BOOCH, RUMBAUGH, JACOBSON, 2005).
• Diagramas de atividades
O diagrama de atividades é visto como parte da visão funcional de um sistema, pelo
fato de descrever processos lógicos ou funções. Ele foi projetado para dar suporte à descrição
dos comportamentos que dependem dos resultados de processos internos (PENDER, 2004).
Os diagramas de atividades são utilizados para detalhar classes, implementação de operações
e casos de uso, representando o que acontece e não quais os responsáveis pela ação
(ALMEIDA e DAROLT, 2001).
Um diagrama de atividades captura o funcionamento interno de um objeto, suas ações.
Além de mostrar como um processo de negócio funciona em termos de atores, fluxo de
trabalho, organização e objetos. Também é utilizado para mostrar como uma instância de caso
39
de uso pode ser realizado em termos de ações e mudanças de estado de objetos, demonstrando
como um conjunto de ações relacionadas podem ser executadas, dentre inúmeras outras
utilidades (FURLAN, 1998).
• Diagrama de pacotes
Os diagramas de pacotes fornecem uma visão de toda a arquitetura do sistema,
disponibilizando uma maneira diferente de organizar os componentes. Normalmente são
utilizados para agrupar quantidades consideráveis de classes, interfaces, componentes, nós,
diagramas e outros elementos, facilitando a compreensão geral do sistema.
Um pacote pode ser definido como um “mecanismo de propósito geral para a
organização do próprio modelo em uma hierarquia; ele não tem nenhum significado para a
execução.” (BOOCH, RUMBAUGH, JACOBSON, 2005), ou seja, o pacote é apenas uma
forma diferente de organizar seus componentes, sem valor para sua execução. O pacote deve
ser criado para agrupar elementos da arquitetura semelhantes, podendo conter desde classes e
interfaces até outros pacotes. Devem ser estabelecidos também um nome, seus elementos e
sua visibilidade, facilitando o entendimento do domínio da aplicação.
A vantagem de se utilizar este tipo de abordagem é que, diante de um sistema com
uma quantidade relativamente grande de componentes, pode-se modelar a sua arquitetura em
um diagrama, permitindo a todos os envolvidos uma visão geral do sistema, desde a
visibilidade até os relacionamentos entre eles.
3.4 Orientação a Objetos
A orientação a objetos começou a ser utilizada em maior escala na década de 1980,
trazendo uma nova maneira de analisar, projetar e desenvolver sistemas. Esta nova forma
aborda o desenvolvimento de sistemas de um modo mais abstrato e genérico. Os grandes
benefícios em relação à orientação estruturada, que era a mais utilizada até aquele momento,
são o reaproveitamento de código e a facilidade de manutenção (SIMOR e DORNELES,
2009).
O conceito deste paradigma está no objeto, sendo seus processos embasados na
representação computacional de objetos reais e de seus relacionamentos. Segundo Simor e
Dorneles (2009) a orientação a objetos busca representar, do modo mais fiel possível,
situações do mundo real no ambiente computacional.
40
Os processos do desenvolvimento orientado a objetos, conforme citado, são baseados
nos objetos e seus relacionamentos. Porém é importante destacar a existência de classes, estas
definem os objetos presentes no sistema e determinam o comportamento, os possíveis estados
e os relacionamentos destes. Desta forma cada objeto é, na realidade, uma instância de uma
classe (CEUNES PROGRAMAÇÃO III, s/a).
Baseado em CEUNES Programação III (s/a), os benefícios da utilização da orientação
a objetos são a centralização de dados e funções em uma única unidade do sistema (objeto); a
reutilização de código (herança) – permite um ganho significativo de tempo e custo no
desenvolvimento; o ocultamento de informação (encapsulamento) – uma classe acessa apenas
a interface de outra, evitando erros acidentais; manutenabilidade – o sistema não fica
acoplado, o que facilita a manutenção.
É comum deparar-se com questionamentos sobre a vantagem da utilização da
orientação a objetos em relação à estruturada. O QUADRO 2 traz um comparativo, onde é
possível perceber a metodologia e as técnicas de ambos os paradigmas.
QUADRO 2 Comparativo entre OO e Programação Estruturada
Programação Estruturada (Procedimental) Programação OO
• Ênfase: construção de algoritmos;
• Utiliza abordagem de refinamentos sucessivos;
• Subproblemas são codificados como unidades denominadas procedimentos, sub-rotinas ou funções;
• Unidades de programa podem ser agrupadas em módulos;
• Programa resultante consiste de uma coleção de unidades que se comunicam entre si;
• Visão top-down; • Forte uso de Decomposição Funcional; • O sistema é composto por dados e
funções, tratados separadamente, mas que podem interagir.
• Programas muito grande tornam-se muito complexos e difíceis de entender e manter;
• Dificuldade em modelar muitos problemas da vida real com enfoque em algoritmos;
• Metodologia desenvolvida objetivando suprir deficiências encontradas em programação algorítmica;
• Encapsulamento: combinação de dados (atributos) e funções (métodos) numa única entidade de programa;
• Objeto: entidade de encapsulamento; • Um programa no paradigma POO
consiste de vários objetos que se comunicam (isto é, trocam mensagens) entre si utilizando seus métodos constituintes;
• Visão de Objetos cooperativos; • As características de comportamento
e informações são modeladas de maneira fortemente relacionadas;
• O sistema é composto por objetos, que contêm dados e funções (isto é, estão reunidos em um só elemento).
• Ocultação de Informação: métodos que fazem parte de um objeto provêem (usualmente) a única forma de acesso
41
• É mais fácil simular o funcionamento de sistemas complexos com enfoque em suas partes constituintes do que em termos dos algoritmos utilizados pelo sistema.
• Linguagens procedimentais não oferecem facilidades para criação de novos tipos de dados que funcionem como os tipos de dados primitivos.
aos seus dados, campos de um objeto não podem ser acessados diretamente, apenas indiretamente por meio de seus métodos constituintes, prevenindo alterações acidentais de dados e facilitando a manutenção e depuração dos programas.
Fonte: CEUNES - PROGRAMAÇÃO III, s/a, página 13 (adaptado).
Diante deste quadro é possível perceber vantagens significativas da utilização da
orientação a objetos, principalmente em softwares maiores. Várias linguagens de
programação seguem este paradigma, C++, C#, Java, Object Pascal, Objective-C, Python,
Ruby e Smalltalk são bons exemplos. O próximo tópico traz detalhes da linguagem Java, na
qual este projeto esta sendo desenvolvido.
3.5 Tecnologias utilizadas
Para a produção de um software é necessário valer-se de um conjunto de tecnologias e
ferramentas apropriadas, a fim de propiciar agilidade, confiabilidade e produtividade na
execução do seu desenvolvimento. Com o aumento da complexidade no desenvolvimento de
software, surgiram várias ferramentas que auxiliam os desenvolvedores durante todo o ciclo
de vida da aplicação.
Estas ferramentas são classificadas como CASE (Computer Aided Software
Engineering) e podem ser utilizadas desde a análise até a implantação de um projeto de
software. Ferramentas Case pode ser definida como “Um produto de software que pode
auxiliar engenheiros de software através do apoio automatizado para atividades do ciclo de
vida de software conforme definido na ISO/IEC 12207 (KIDO, HIRAMA, 2008, p.3 apud
ISO, 1995).
As ferramentas Case podem ser classificadas de acordo com as áreas nas quais atuam,
dentro de um ciclo de vida de um software. Segundo Summerville (2007), esta classificação
pode ser feita conforme uma perspectiva funcional, de processo ou de integração. Na
perspectiva funcional, cada ferramenta é classificada de acordo com a sua função específica
no processo. Na perspectiva de processo, são consideradas as atividades de apoio que
fornecem. Já na perspectiva de integração a classificação é feita de acordo com o conjunto de
42
unidades integradas a uma ou mais atividades do processo.
Um dos grandes benefícios da utilização das Ferramentas Case é a redução do tempo
de desenvolvimento, pois fornecem suporte para a produção automatizada de documentação,
além de facilitar a compreensão geral dos requisitos do projeto. Outra vantagem é que, a partir
da análise de um projeto, é possível gerar softwares automaticamente, reduzindo o tempo e a
complexidade da implementação de um sistema.
Esta seção aborda as tecnologias utilizadas para o desenvolvimento do ADSBD
Manager. São apresentadas as ferramentas utilizadas em cada camada do software, desde a
persistência até a própria implementação do sistema.
• Linguagem Java
O paradigma de orientação a objetos é um dos modelos de programação mais
discutidos na área de desenvolvimento. A partir desta discussão, surgiram várias linguagens
que suportam este paradigma, podendo citar o C++, C#, Java, dentre outras. A principal
característica destas linguagens é permitir a reutilização de código, facilitando o processo de
produção de software.
A linguagem Java surgiu a partir de um projeto, desenvolvido pela Sun Microsystems,
chamado Green Project, que tinha como motivador a criação de tecnologias para a fabricação
de dispositivos eletrônicos inteligentes para o consumidor final. Em 1995, a Sun anuncia o
Java como plataforma de desenvolvimento, o que despertou o interesse da comunidade
comercial, devido á popularização da internet. Com o amadurecimento da linguagem, a sua
segunda edição oferece uma série de recursos que possibilita desenvolver desde aplicativos
corporativos de grande complexidade até softwares voltados para o consumidor final
(DEITEL E DEITEL, 2005).
Um grande diferencial da linguagem Java em relação a outras linguagens é o seu
processo de compilação: o compilador Java gera os Bytecodes (arquivos compilados), que no
momento da execução, serão interpretados pela máquina virtual Java (JVM). A JVM é uma
camada que faz a comunicação entre os programas Java e o sistema operacional, garantindo
assim sua portabilidade . A FIG. 3 mostra o processo de compilação de um programa Java.
43
FIGURA 3 – Processo de compilação de um programa Java
Fonte: Ruiz, 2008
A plataforma Java, por se tratar de uma linguagem muito ampla, abrange 3 versões
principais: uma versão voltada para dispositivos móveis, outra voltada para desenvolvimento
desktop e outra para aplicações corporativas. A FIG. 4 mostra a arquitetura de
desenvolvimento Java.
FIGURA 4 – Plataformas do Java
Fonte: Coura, 2009
o Micro Edition (J2ME): Esta versão é voltada para desenvolvimento de aplicações para
dispositivos móveis, tais como celulares, PDA’s, smartfones, dentre outros. Esta
plataforma é responsável pela produção de softwares com recursos limitados, ou seja,
controla de forma eficaz os recursos disponíveis, para conseguir o melhor desempenho
da aplicação;
o Standard Edition (J2SE): Esta versão propicia recursos para o desenvolvimento de
aplicações para desktops. Ela contém todas as API’s básicas para o desenvolvimento
de aplicações, incluindo suporte para a criação de interfaces gráficas.
o Enterprise Edition (J2EE): Esta versão é voltada para desenvolvimento de aplicações
corporativas e todo o suporte á comunicação em rede. Esta versão abrange a
plataforma J2SE e mais um conjunto de especificações e bibliotecas que fornecem
recursos para a criação de aplicações.
44
Além de disponibilizar uma série de recursos para as mais diversas áreas de
desenvolvimento, Java fornece algumas API’s para desenvolvimento de interfaces gráficas.
Uma das primeiras desenvolvidas foi a AWT (Abstract Window Toolkit), que utiliza as
definições do sistema operacional na qual a aplicação está sendo executada. O grande
problema em se utilizar esta API é a dificuldade de padronização das interfaces, uma vez que
a aplicação teria comportamentos diferentes em cada sistema operacional.
Posteriormente, como alternativa para desenvolvimento de interfaces, foi criado um
grupo de componentes gráficos denominado Swing, pertencente á JFC (Java Foundation
Classes), que não chega a substituir o AWT, mas estende alguns recursos. Com isso,
possibilita que as interfaces das aplicações permaneçam inalteradas, independente de
plataforma (COURA, 2006).
• IDE NetBeans
Segundo SANTOS (2007), um IDE (Integrated Development Environment) de
desenvolvimento pode ser definido como “um programa de computador, geralmente utilizado
para aumentar a produtividade dos desenvolvedores de software, bem como a qualidade
destes produtos”. A utilização deste tipo de programa está cada vez mais presente no ambiente
de desenvolvimento das empresas, devido à grande facilidade de se integrar ferramentas para
a aplicação de técnicas que facilitam a implementação de softwares.
Já as ferramentas de desenvolvimento rápido (RAD - Rapid Application Development)
surgiram a partir de um modelo de processo de software iterativo, na qual a fase de
desenvolvimento é bem reduzida. Hoje existem IDE’s que também oferecem recursos da
tecnologia RAD, disponibilizando um editor de código-fonte, um compilador e um debugador
– responsável por auxiliar no processo de encontrar e corrigir erros do software (RIBEIRO e
SILVA, 2008). A FIG. 5 traz uma tela do NetBeans.
45
FIGURA 5 – Tela do IDE NetBeans Fonte: SANTOS, 2007. O IDE Netbeans é um software livre, de código aberto e que suporta várias linguagens
de programação. Possui um editor de código-fonte e um destinado a criação de interfaces
gráficas. As principais vantagens de se utilizar o Netbeans são: a facilidade de instalação e
configuração; suporte as principais aplicações Java; auto-configuração de variáveis de
ambiente; facilidade de deploy da aplicação (passagem para produção) e a disponibilidade
para várias plataformas. Suas principais desvantagens estão relacionadas ao uso de memória,
exigindo no mínimo 512 MB, e uso excessivo da CPU (HIRAGI, 2006).
• Firebird
Um sistema de gerenciamento de banco de dados fornece operações de inserção,
alteração, exclusão, obtenção e atualização de dados relativos ao sistema de forma segura e
garante a integridade dos dados. Sua utilização traz inúmeros benefícios, tais como: eficiência
no acesso aos dados, redução do tempo de desenvolvimento de uma aplicação, controle de
acessos concorrentes, além da garantia de segurança e consistência dos dados (DURÃES,
2007).
O Firebird é um sistema de gerenciamento de banco de dados (SGBD) que surgiu a
partir do código fonte do InterBase, disponibilizado pela Borland, através de licença pública
46
em 25 de julho de 2000. Ele é mantido por programadores do mundo inteiro que dão a sua
contribuição, continuando o projeto e sua filosofia de software livre (BANDEIRA, s/a).
A primeira versão oficial do Firebird foi lançada em março de 2002, licenciada pela
IPL (InterBase Public License), sendo compatível com o padrão ANSI-SQL 92. Contando
com o tempo de desenvolvimento, ele está a mais de vinte anos em operação. Diversas
organizações utilizam-no, podendo citar a Embrapa, que implantou um software que tem a sua
arquitetura cliente/servidor centrada no Firebird; a Caixa Econômica Federal, através do
software SEFIP, dentre inúmeras outras. Isso mostra a estabilidade e a confiabilidade desta
ferramenta (FREITAS, 2007).
• IBOConsole
Para facilitar a manipulação de dados no SGBD Firebird, existem várias ferramentas
que auxiliam o desenvolvedor na administração de banco de dados. O IBOConsole é
considerado um ambiente de desenvolvimento integrado (IDE), voltado para a administração
dos SGBD’s Firebird e InterBase. Ele integra uma série de ferramentas que permitem o
gerenciamento de várias bases de dados de forma gráfica, agilizando o processo de criação e
manipulação dos dados (NASCIMENTO, FALCÃO e CUNHA, 2006). A FIG. 6 mostra uma
tela do IBOConsole.
FIGURA 6 – Tela do IBOConsole Fonte: Nascimento, Falcão e Cunha, 2006.
47
Dentre os vários recursos disponibilizados pelo IBOConsole para a criação e
manipulação de dados podemos citar o editor visual para consultas SQL, um depurador de
procedimentos de armazenamento e gatilho, dentre outros. Outra vantagem do IBOConsole é
que, por ser um software livre, possui seu código aberto e não é necessário adquirir uma
licença para uso comercial.
• DBDesigner
Existem várias ferramentas para modelagem de banco de dados disponíveis no
mercado. Uma delas é o DBDesigner, que foi desenvolvido sob a licença GPL (General
Public License) com o propósito de auxiliar projetos de banco de dados, possibilitando a
criação de diagramas entidade-relacional, demonstrando os relacionamentos entre tabelas
(ARAÚJO, 2009). A figura abaixo mostra a tela inicial da aplicação (FIG 7).
FIGURA 7 – Tela do DBDesigner Fonte: http://www.revistaphp.com.br/arquivos/Image/flavia/p1.jpg Essa ferramenta oferece integração a diversos SGBD’s existentes no mercado, desde
que seja permitido o seu acesso via ODBC (Open Database Connectivity), o que possibilita a
sua utilização integrada ao SGBD Firebird. Por se tratar de uma ferramenta eficiente para a
modelagem de dados, sua utilização possibilita desenvolver modelos lógicos e físicos de um
banco de dados. Ele permite criar regras de integridade oferecendo suporte à engenharia
reversa e, o sincronismo entre o modelo entidade-relacional e a base de dados (ARAÚJO,
2009).
48
• JPA
Sem dúvida, uma das áreas mais críticas do desenvolvimento de softwares orientados
a objetos é a persistência de dados em banco de dados relacionais. Cerca de 30% do código da
aplicação se refere à persistência de dados. Com isso, surgiram duas abordagens principais
para sanar este problema: criação de banco de dados orientado a objetos e frameworks para
fazer o mapeamento objeto-relacional (SILVEIRA, 2006).
Os bancos de dados orientados a objetos, apesar de estarem em discussão no meio
acadêmico, ainda não estão sendo aplicados no mercado. Um dos motivos é a dificuldade de
transição de dados entre os bancos relacionais e os orientado a objetos, uma vez que a maioria
das bases de dados atuais são relacionais, tornando-se inviável a sua utilização,
principalmente no meio comercial.
O mapeamento objeto-relacional (ORM) é “a tecnologia que provê a persistência de
forma automatizada e transparente dos objetos em uma aplicação, em tabelas de uma base de
dados relacional, usando metadados para fazer a troca de dados entre os objetos e a base de
dados”. (FILHO, 2006 p. 16 apud BAUER; KING, 2005, p.46). Ou seja, com este
mapeamento é possível utilizar os benefícios do paradigma orientado a objetos com a
estabilidade e a tecnologia relacional, diminuindo o tempo de desenvolvimento e a
complexidade em se persistir dados.
A especificação EJB (Enterprise JavaBeans) surgiu da necessidade de oferecer uma
infra-estrutura de desenvolvimento de aplicações com a possibilidade de se utilizar objetos
distribuídos na internet, como parte da plataforma J2EE. A especificação estabelecia uma
série de serviços (gerenciamento de transações, segurança, recursos, dentre outros), porém a
manipulação destas entidades era muito limitada. Por isso, na especificação EJB 3.0, foi
criada uma nova API de persistência, a JPA, que traz todos os benefícios da orientação a
objetos, para a camada de persistência em Java (SANTANA et al., s/a).
A API de persistência na plataforma Java define uma maneira simples de mapear
objetos Java para um banco de dados relacional. Nas especificações EJB anteriores a 3.0, os
bens de entidade (POJO’s de persistência) consumiam muitos recursos, dependiam do
servidor de aplicação e de todo o ambiente de execução J2EE. Outro ponto fraco das
especificações anteriores é que não havia uma padronização dos objetos mapeados do banco
de dados, ou seja, fornecedores individuais poderiam construir seus próprios objetos
persistentes, o que acarretava a não-portabilidade entre fornecedores diferentes (BURKE E
MONSON-HAEFEL, 2007).
49
A nova especificação JPA utiliza o mapeamento objeto-relacional, simplificando o
processo de desenvolvimento e padronizando as entidades POJO (Plain Old Java Objects) de
persistência. O tratamento de dados como objetos facilita a manipulação e deixa a
programação mais simples, dando maior qualidade e portabilidade entre aplicações. Além da
padronização do mapeamento objeto-relacional, a JPA também proporciona uma
independência de plataforma de desenvolvimento, podendo ser aplicada tanto na J2EE quanto
na plataforma J2SE (SANTANA et al., s/a). A FIG. 8 apresenta um desenho esquemático
mostrando a especificação JPA.
FIGURA 8 – Especificação JPA
Fonte: Curte, 2007 apud Adaptado de Bellia, Renato. Revista Java Magazine, ed. 44, p. 28.
Nota-se que a tecnologia JPA utiliza uma camada intermediária entre o banco e a
aplicação e necessita de um provedor que implemente a especificação JPA. No mercado
existem várias implementações, cada uma oferecendo recursos adicionais à especificação e
todos têm seus pontos fortes e fracos, dentre estas opções destacam-se o TopLink e
principalmente o Hibernate.
O Hibernate é um framework open-source, provedor da especificação JPA. Segundo
Bauer e King, 2005 “ele é o intermediário entre a interação do aplicativo com o banco de
dados relacional, deixando o desenvolvedor livre para pensar no problema do negócio”. Sua
utilização permite que a aplicação manipule apenas objetos, o que facilita a persistência e a
recuperação de dados no banco de dados. Além disso, diminui o impacto para a aplicação, no
caso de alguma mudança no banco, e aumenta, consideravelmente, a produtividade do
desenvolvimento de softwares.
50
• IReports
A geração de relatórios é um recurso fundamental em qualquer aplicação comercial,
por permitir que os dados sejam formatados de forma mais elegante para o usuário. Nesta
perspectiva, nasceu em 2001, o JasperReports, criado por Teodor Danciu, que tinha como
objetivo ajudar os desenvolvedores na produção de relatórios, tanto desktop quanto para web,
a partir do formato XML. Em 2002, Giulio Toffoni lança, de forma independente, uma
ferramenta visual que gerava um formato compatível com o JasperReports. A partir de 2005,
a JasperSoft, mantenedora do JasperReports, adotou o IReports como ferramenta oficial para
a geração de relatórios do JasperReports. A FIG. 9 apresenta uma tela desta ferramenta.
FIGURA 9 – Tela do IReports Fonte: Lozano, 2006.
O IReports é uma ferramenta de código aberto, voltada para aplicações Java, que
utiliza o formato da biblioteca do JasperReports. Sua utilização traz vantagens, tanto para os
programadores experientes, agilizando o processo de construção de relatórios mais
complexos, quanto para os iniciantes, pois permite a criação de relatórios sem a necessidade
de manipular o código fonte. Além dos recursos para a comunicação com o banco de dados,
permite agrupar informações vindas de grupos de dados de diversas tabelas; definir uma
51
padronização de formatos para impressão e possibilita exportar os relatórios gerados para
diversos formatos (GONÇALVES, 2008).
• JUnit
A execução de testes nos códigos produzidos sempre foi uma parte crítica dos
projetos, no que tange o tempo e os custos dos mesmos. O JUnit é um framework de código
aberto, criado para facilitar a criação de testes dentro da linguagem de programação Java.
Através dele é possível detectar se determinado método funcionará como esperado e descobrir
possíveis falhas.
Segundo Neto (2006) existem varias baterias de testes que são executadas no software
antes de serem disponibilizadas para os usuários finais. Estes testes vão desde os unitários até
os de integração e sistema. Os testes unitários são aqueles executados nas menores porções do
software e tem por objetivo encontrar pequenos erros como, por exemplo, códigos mal
elaborados, a fim de garantir uma qualidade no produto desenvolvido durante o processo. Já
os testes de integração e sistema objetivam verificar o comportamento do sistema em
conjunto, encontrado possíveis problemas de interação entre unidades de software.
Uma das grandes vantagens em se aplicar testes utilizando o framework JUnit é a
criação rápida de códigos de teste, possibilitando uma maior qualidade e ganho de tempo no
desenvolvimento e no próprio teste. Outra vantagem é que, uma vez escrito, os testes podem
ser executados rapidamente, sem que o processo de desenvolvimento seja interrompido. A
verificação automatizada dos resultados agilizam, ainda mais, a fase de testes no software.
• JUDE
A modelagem UML se mostra importante em projetos desenvolvidos utilizando
linguagem orientada a objetos. Neste projeto, para facilitar esta modelagem, a ferramenta
JUDE, desenvolvida pela empresa Eiwa System Management, foi utilizada no processo de
análise de requisitos. A figura abaixo apresenta um diagrama de seqüência modelado nesta
ferramenta (FIG. 10).
52
FIGURA 10 – Tela de criação de um diagrama de seqüência Fonte: http://jude.change-vision.com/jude-web/product/jude_pl.html Esta ferramenta está disponível no mercado em duas versões, a Jude Community que
possui a licença GNU GPL (General Public License) e a Jude Professional que necessita de
licença. Em sua versão GPL, são disponibilizados funcionalidades básicas para a modelagem,
suportando todos os diagramas da UML versão 2.0. Já a sua versão Professional oferece
recursos avançados, tais como impressão melhorada de diagramas e templates, input-output
de modelos para arquivos XML, funções de copiar e colar em formato de vetor. A utilização
desta ferramenta possibilita, além da modelagem, a geração automática de documentação e a
importação de arquivos de código Java (FERREIRA, REIS, 2005).
3.6 Considerações finais
Nesta seção foram apresentadas as ferramentas utilizadas durante o desenvolvimento
do ADSBD Manager. Foram abordadas as metodologias de desenvolvimento aplicadas
durante o projeto, como o modelo em cascata, espiral e XP. Também foram apresentadas as
ferramentas utilizadas durante a análise de requisitos, como o Jude Professional e o
DBDesigner. Na fase de implementação do software, foi utilizado o IDE Netbeans e a
linguagem Java como tecnologia base da aplicação. Por fim, o SGBD Firebird e o
IBOConsole foram utilizados para a persistência dos dados. O capítulo seguinte trata da
metodologia de desenvolvimento do ADSBD Manager.
53
4 METOLOGIA DE DESENVOLVIMENTO DO ADSBD
MANAGER
Esta seção apresenta como foi desenvolvido o software de gerenciamento da ADSBD.
Sendo mostradas as fases de desenvolvimento e quais tecnologias utilizadas em cada uma
dessas.
4.1 Considerações inicial
O desenvolvimento de um software é processo complexo, dividido em algumas fases.
Por isso é importante se definir uma metodologia de trabalho que atenda as necessidades de
cada projeto. Neste caso especifico foi utilizada uma metodologia de desenvolvimento
baseada nas melhores praticas da metodologia em cascata, espiral e da XP.
Este projeto pode ser divido em 3 fases maiores, sendo cada uma dessas composta por
outras fases. A primeira foi à coleta e análise dos requisitos do sistema, a segunda a
documentação do software e por fim a implementação, testes e implantação. Em cada uma
destas etapas se buscou utilizar técnicas e ferramentas adequadas para que, desta maneira,
fosse possível desenvolver um software baseado nos princípios da engenharia de software.
• Visão geral do sistema
O sistema ADSBD Manager tem por finalidade auxiliar a associação no gerenciamento
das suas atividades administrativas. Estas atividades estão relacionadas ao cadastro, busca e
relatórios sobre doadores, colaboradores, doações e atividades gerenciais.
O funcionamento do software está relacionado a 4 núcleos principais: o gerenciamento
de doadores - gerencia informações relacionadas aos doadores de sangue, permitindo
cadastro, busca, exclusão e atualização de doadores; gerenciamento de colaboradores -
gerencia informações relacionadas aos colaboradores financeiros, permitindo cadastro, busca,
exclusão e atualização de colaboradores financeiros; gerenciamento de doações de sangue -
gerencia as informações relativas às doações de sangue, realizando um controle das doações;
e as atividades internas - gerencia as atividades administrativas da associação, gerando
relatórios periódicos sobre elas.
54
A partir do gerenciamento destes pontos é possível ter um controle sobre as atividades
da ADSBD, gerando os relatórios necessários e facilitando a manipulação das informações.
Abaixo será detalhada a fase de levantamento de requisitos, apresentando as técnicas
utilizadas e o seu resultado.
4.2 Levantamento de requisitos
Com o objetivo de compreender melhor o contexto do sistema, foi realizado um
levantamento de requisitos utilizando a metodologia em cascata. Inicialmente foi realizada
uma entrevista de ativação na qual foi apresentada para a diretoria da ADSBD a proposta e
definidas as diretrizes para a realização do projeto.
Em seguida, foi realizada uma nova entrevista com o objetivo de identificar os
stackholders e os principais requisitos do sistema, sendo o resultado desta entrevista
formalizado em um documento que mostra uma visão inicial do sistema em alto nível
(documento visão). A partir deste documento, foi estruturada uma entrevista a fim de
identificar detalhadamente todos os requisitos do sistema.
Durante esta entrevista, foram levantadas informações sobre os stackholders, o
funcionamento da instituição, a documentação gerada e os formulários utilizados em seu
gerenciamento. Após este levantamento, se discutiu quais seriam os pontos chave dos
requisitos, e o modo de documentar o software de forma a atender as expectativas da
organização. Posteriormente, foi produzido um documento de especificação de requisitos
(SRS), que seria a base para as outras fases de desenvolvimento do software.
Os documentos produzidos, como o documento visão e o SRS estão disponíveis na
“Documentação do software ADSBD Manager”, bem como em formato digital e também na
web, através do site Source Forge, podendo, os mesmos, ser acessados pelo link
http://adsbdmanager.sourceforge.net/.
4.3 Análise de Requisitos e Projeto
Uma vez elaborado o documento de especificação de requisitos (SRS), é realizada uma
análise para refinamento destes, os documentos gerados servem de base para as outras fases
do desenvolvimento. Para esta análise, foi utilizada a modelagem UML e a ferramenta CASE
Jude Professional para a geração da documentação.
55
Primeiramente, foram produzidos os diagramas de casos de uso de todo o sistema. A
partir deles, foram produzidos o modelo de domínio e os diagramas de seqüencia e atividades
dos casos de uso principais. Posteriormente, foi produzido o diagrama de pacotes para
demonstrar a arquitetura da aplicação. Finalmente foi gerada a Especificação dos Casos de
Uso, estando disponível na “Documentação do software ADSBD Manager”, bem como em
formato digital e também na web, através do site Source Forge, podendo, ser acessada pelo
link http://adsbdmanager.sourceforge.net/.
• Funcionalidade do sistema
Após a análise de requisitos, foram enumeradas as funcionalidades essenciais do
sistema:
• Gerenciamento de doadores de sangue
o Cadastrar doadores de sangue;
o Atualizar cadastros de doadores;
o Realizar a impressão dos cadastros efetuados;
o Pesquisar doadores de sangue através dos campos nome, endereço, tipo
sanguíneo, sexo, data da última doação, disponibilidade para viajar, telefone.
• Gerenciamento de Colaboradores Financeiros
o Cadastrar colaboradores financeiros;
o Atualizar colaboradores financeiros;
o Realizar a impressão dos cadastros efetuados;
o Pesquisar colaboradores financeiros através dos campos nome, endereço para
recolhimento, telefone, data de aniversário, data da colaboração, situação do
colaborador.
• Gerenciamento de doações de sangue
o Cadastrar as doações efetuadas pelos doadores;
o Imprimir um relatório contendo todas as doações efetuadas por um doador;
o Controlar a periodicidade das doações de sangue de cada doador.
• Gerenciamento das atividades interna
o Gerenciar atividades relacionadas à doação de sangue
� Controle de conscientização de familiares;
� Controlar as bolsas utilizadas;
56
� Controle das bolsas captadas nas coletas realizadas em Bom Despacho;
� Controle de acompanhamento de doadores aos Hemocentros.
o Gerenciar as atividades do projeto “Futuro Doador”
o Gerenciar correspondências
� Felicitações de aniversariantes;
� Cartas de agradecimento;
� Cartas de pêsames;
� Ofícios expedidos;
� Felicitações pelo dia nacional do doador voluntário de sangue;
� Correspondências diversas.
o Gerenciar colaborações recebidas
� Controle de mão de obra voluntária;
� Controle de doações de materiais;
� Controle de doações financeiras.
o Gerenciar Divulgações
� Divulgações em rádios;
� Divulgações em jornais;
� Divulgações em TVs;
� Palestras e treinamentos;
� Divulgações diversas;
o Gerenciar serviços autônomos
o Geração de relatórios periódicos das atividades internas
o Controlar carga horário de cada atividade
4.3.1 Caso de uso: visão geral do sistema
A FIG. 11 apresenta um diagrama de caso de uso com as principais funcionalidades do
sistema, e objetiva mostrar, aos envolvidos no projeto, os requisitos que serão implementados.
57
FIGURA 11 – Diagrama de caso de uso: Caso de uso geral Fonte: Os autores.
Como se pode perceber na FIG. 11, o sistema irá abranger uma série de atividades
dentro da organização, sendo os casos de uso gerenciar doadores, gerenciar colaboradores,
controlar doações de sangue e gerar relatórios os núcleos do sistema. É importante ressaltar
que no diagrama acima, para efeitos de melhor visualização, algumas funcionalidades foram
agrupadas em casos de uso genéricos, que estão detalhadamente especificados no documento
de Especificação de Casos de Uso.
O documento de Especificação de Casos de Uso (disponível na “Documentação do
software ADSBD Manager”, em formato digital e também na web, através do site Source
Forge, podendo, ser acessada pelo link http://adsbdmanager.sourceforge.net/) traz uma
especificação detalhada dos casos de uso, onde será possível visualizar todas as
funcionalidades do sistema. Os casos de uso principais como cadastro de doadores e
colaboradores, gerenciar projeto Futuro Doador e o gerenciar doações de sangue foram
modelados também com os diagramas de seqüência e de atividade.
58
• Especificações do caso de uso geral
A FIG. 11, mostrada no tópico anterior apresenta em alto nível as principais
funcionalidades do sistema. Para uma melhor compreensão do mesmo, o QUADRO 3
apresenta uma pequena descrição de cada caso de uso
QUADRO 3 Descrição dos Casos de Uso – Digrama Casos de Uso Geral
Caso de Uso Descrição Controlar Doadores de Sangue Realiza o gerenciamento de todas as atividades
relacionadas aos doadores de sangue, como cadastro, busca e atualização dos dados.
Gerenciar Doações de Sangue Realiza o gerenciamento de todas as atividades relacionadas às doações de sangue efetuadas pelos doadores cadastrados pela na ADSBD. São registradas as datas, locais e motivos de cada doação.
Controlar Colaboradores Realiza o gerenciamento de todas as atividades relacionadas aos colaboradores financeiros, como cadastro, busca e atualização dos dados.
Gerenciar Treinamentos Realiza o gerenciamento de todos os treinamentos realizados pela ADSBD, seja com voluntários ou profissionais.
Gerenciar "Projeto Futuro Doador"
Realiza o gerenciamento de todas as atividades do "Projeto Futuro Doador".
Controlar Divulgações Realiza o gerenciamento de todas as atividades de divulgação realizadas pela ADSBD, seja através de jornais, TV, rádio ou faixas.
Gerenciar Doações de Equipamento
Realiza o gerenciamento de todas as doações de equipamentos e matérias recebidos pela ADSBD.
Gerenciar Prestação de Serviços Realiza o gerenciamento todos os serviços prestados sejam por autônomos ou voluntários, para a ADSBD.
Gerenciar Reuniões Realiza o gerenciamento de todas as reuniões (ordinárias e extraordinárias) realizadas pela ADSBD.
Gerar Relatórios Realiza a emissão de relatórios sintéticos e analíticos relativos às atividades internas, levantamentos estatísticos sobre doadores de sangue e colaboradores.
Gerenciar Correspondências Realiza o gerenciamento de todas as atividades relacionadas ao envio de correspondências.
Fonte: Os autores.
O sistema de gerenciamento da ADSBD, como pôde ser percebido, é muito amplo e
visa disponibilizar um meio informatizado que atenda todas as necessidades gerenciais da
59
associação. As descrições detalhadas de todos os casos de uso estão disponibilizadas no
documento de Especificação de Casos de Uso.
4.3.2 Especificação do caso de uso Cadastrar Doadores de Sangue
A fim de melhor compreender o domínio da aplicação, a partir do caso de uso geral,
foram selecionados os seis principais, e, a partir deles, foram modelados os diagramas de
seqüencia e atividades. A fim de não sobrecarregar este trabalho será apresentada somente a
especificação do caso de uso cadastrar doadores de sangue. Os demais casos de uso principais
estão especificados no documento de Especificação de Casos de Uso.
O caso de uso cadastrar doador de sangue é um dos principais, pois a partir dele várias
outras atividades são desenvolvidas. A FIG. 12 traz a representação do deste caso de uso e o
QUADRO 4 a descrição deste.
FIGURA 12 – Caso de Uso Cadastrar Doadores de Sangue. Fonte: Os autores.
60
QUADRO 4 Descrição do Caso de Uso Cadastrar Doador de Sangue
Fonte: Os autores. Para melhor compreender os fluxos de informações executadas pelo ator, foi elaborado
um diagrama de atividade. O objetivo deste diagrama é mostrar as ações que são
desempenhadas quando uma determinada operação é executada. A FIG. 13 mostra o fluxo de
trabalho executado pelo ator durante o cadastro de um doador de sangue.
Caso de Uso Descrição Nome do Caso de Uso Cadastrar Doador de Sangue Sumário Realiza o cadastramento de doadores de sangue na ADSBD. Ator Agente ADSBD Pré-Condições A tela correspondente ao gerenciamento dos doadores deverá estar
disponível para o usuário Pós-Condições O sistema apresentará uma mensagem informando o status da
operação Seqüência Básica 1 Clicar no botão de Cadastro de Doador de Sangue;
2 Informar os dados de cadastro do Doador 2.1 Dados Pessoais; 2.2 Endereço Residencial e Comercial; 2.3 Pesquisa e situação do doador; 3 Clicar no botão Salvar;
Seqüência Exceção Caso o usuário não informe algum dos campos de preenchimento obrigatório será exibida uma mensagem informando o ocorrido e a tela será reapresentada para o usuário
61
FIGURA 13 – Diagrama de atividade cadastrar doadores de sangue Fonte: Os autores.
Na FIG. 13 o ator ativa a tela de cadastro de doadores. Após esta ativação, o ator pode
optar por cancelar a operação ou continuar o processo. Caso ele continue o processo, ele
informa os dados do doador e, logo em seguida é verificado se os dados fornecedos estão
completos, caso contrário, é exibida uma mensagem informando o ocorrido. Caso os dados
sejam validados, eles são persistidos e o fluxo de trabalho finalizado.
A partir das descrições de casos de uso, foram elaborados os diagramas de seqüência.
O objetivo destes diagramas é mostrar as trocas de mensagens entre os objetos em tempo de
execução, mostrando, assim, os procedimentos executados pelo sistema durante o cadastro de
algum doador de sangue. A FIG. 14 enfatiza os procedimentos básicos para se cadastrar um
doador de sangue.
62
FIGURA 14 – Diagrama seqüencia básica de Cadastro doador de sangue Fonte: Os autores. Na FIG. 14, o agente da ADSBD ativa a tela de cadastro de doadores de sague. Após
ter inserido as informações do doador, é realizada uma verificação para validar estas
informações e, a partir deste ponto, é acionado o serviço responsável pela persistencia, que
finalmente é grava as informações no banco. Ao final do processo é exebido uma mensagem
para o usuário informando o sucesso da operação. A figura abaixo mostra a seqüencia
executada pelo sistema caso o usuário informe algum dado incompleto (FIG. 15).
63
FIGURA 15 – Diagrama de seqüencia de exceção Fonte: Os autores. Na FIG. 15 é enfatizada a seqüência de exceção do caso de uso cadastrar doadores de
sangue. Neste diagrama o agente da ADSBD aciona a tela de cadastro. Após informar os
dados do doador, é feita uma verificação dos dados. Esta verificação constata que há alguns
dados que não foram fornecidos pelo agente, sendo retornada uma mensagem de erro ao
agente, solicitando a verificação dos dados pendentes. Este tipo de verificação de dados é
muito proveitoso, pois não permite que dados incompletos sejam repassados para as outras
camadas da aplicação.
4.3.3 Modelo de Domínio
O modelo de domínio apresenta uma visão geral da estrutura do software. Sua
representação é feita através de um diagrama de classes definido pela UML. Esta modelagem
objetiva apresentar de forma consistente e simples as classes, que representam as entidades, e
seus relacionamentos.
Neste projeto, a definição do modelo de domínio foi dificultada pelo fato da ADSBD
possuir uma estrutura de funcionamento muito grande e complexa. A associação mantém
cadastros de doadores e colaboradores, além de realizar um controle de todas as suas
atividades internas. Neste controle são registradas todas as atividades administrativas, sendo
64
que algumas utilizam documentos provenientes de hospitais e hemocentros.
Então, a partir da especificação dos casos de usos e dos requisitos do sistema (SRS)
foram modelados, utilizando a ferramenta JUDE Professional, dois diagramas de classe
representando as classes conceituais do domínio da aplicação. Para uma melhor visualização e
compreensão, o modelo de domínio foi dividido em dois diagramas, sendo que a FIG. 16
aborda o gerenciamento de doadores e colaboradores e a FIG. 17 o gerenciamento de
atividades.
FIGURA 16 – Modelo de Domínio: Gerenciamento de Doadores e Colaboradores Fonte: Os autores.
A FIG. 16 apresenta todas as classes envolvidas no gerenciamento dos doadores e
colaboradores. Destacando ainda o controle das doações que é feito para cada doador, onde é
possível acompanhar todas as doações efetuadas pelo mesmo.
FIGURA 17 – Modelo de Domínio: Gerenciamento de Atividades Fonte: Os autores.
65
A FIG. 17 apresenta o controle das atividades internas da associação. É baseada no
diagrama de casos de uso geral e a algumas classes foram generalizadas a fim de facilitar
visualização e o entendimento.
4.4 Análise Entidade-Relacional
A construção de um diagrama entidade-relacional tem como objetivo, identificar as
entidades mais relevantes em uma organização, e destacar suas propriedades e
relacionamentos. Portanto para se construir um deste diagrama é importante compreender
bem o negócio para o qual o software será desenvolvido.
A construção do diagrama entidade-relacional deste projeto foi feita após o
levantamento e a analise dos requisitos, uma vez que isso facilita a compreensão do domínio
da aplicação. Então, utilizando a ferramenta DBDesigner foi modelado um diagrama inicial,
sendo este refinado até se chegar ao ponto demonstrado pela FIG. 18.
66
FIGURA 18 – Diagrama Entidade Relacional do ADSBD Manager Fonte: Os autores.
67
Na modelagem nota-se a existência de 2 tabelas que centralizam os fluxos principais
da associação. A tabela Pessoas e seus relacionamentos focalizam a parte de gerenciamento
de doadores e colaboradores, enquanto a tabela Atividades é o foco do gerenciamento das
atividades administrativas.
4.5 Arquitetura do Software
A arquitetura da aplicação foi modelada através do diagrama de pacotes, na qual
mostra a divisão da aplicação em 3 camadas distintas: a camada de apresentação, que cuida de
todas as classes referentes a interface de comunicação com o usuário, a camada de serviço,
que é responsável por conter toda a regra de negócio da aplicação e a camada de persistência,
responsável pela persistência dos dados no banco. A figura abaixo mostra o diagrama de
pacotes, demonstrando a arquitetura modelada para o software (FIG. 19).
FIGURA 19 – Diagrama de pacote: Arquitetura do software Fonte: Os autores. A camada de visão contém todas as classes responsáveis pela comunicação com o
usuário. Nesta camada foi utilizado a tecnologia Swing, disponibilizada pelo Java, para o
desenvolvimento da interface. Este pacote também contém algumas classes para validar os
dados da interface, garantindo a consistência dos dados que são passados para as outras
camadas.
A camada de serviço contém classes que disponibilizam para as outras camadas
recursos, tanto para persistência quanto para a visão de forma que os dados não são
persistidos sem passar por essa camada. Além de oferecer estes serviços, este pacote contém
68
classes responsáveis por realizar toda a regra de negócio da aplicação, como a geração de
relatórios, tratamento de erros, dentre outras.
A camada de persistência é responsável pela comunicação da aplicação com o banco
de dados. Nesta camada foi utilizada a especificação JPA, na qual foi realizado o mapeamento
objeto-relacional. Com isso, foi possível definir apenas uma classe genérica, responsável por
persistir, recuperar e atualizar qualquer entidade mapeada.
O pacote de entidade contém todas as classes mapeadas do banco de dados, permitindo
a sua utilização em todas as camadas, uma vez que estas classes têm a definição dos tipos de
dados na aplicação como um todo.
A utilização desta arquitetura se fez necessária, uma vez que a aplicação pode sofrer
modificações tanto por parte dos dados necessários as suas atividades quanto nos relatórios
gerados. Com a adoção deste modelo, pode-se reduzir o impacto das modificações no
software, sendo necessário apenas alterar a camada respectiva, sem alterar as demais.
A arquitetura do software ADSBD Manager, desenvolvido durante este projeto,
respeitou a divisão de camadas, a fim de desenvolver uma aplicação desacoplada, que tenha
fácil manutenabilidade.
4.6 Implementação
A implementação de um software é uma das fases mais dispendiosas do processo de
desenvolvimento. Na implementação do ADSBD Manager, muitas dificuldades foram
encontradas, tais como a utilização do uma tecnologia recente (JPA) para a persistência de
dados, a elaboração dos algoritmos para a geração de relatórios e de uma interface simples e
funcional.
O uso da JPA na persistência exigiu um estudo aprofundado e a realização de vários
testes, contudo seu uso beneficiou o projeto, aumentando a produtividade dos
desenvolvedores e a robustez da aplicação. Sua utilização possibilitou a criação de uma única
classe que encapsula toda a comunicação entre a aplicação e o banco de dados. A figura
abaixo apresenta um trecho do código desta classe (FIG. 20).
69
FIGURA 20 – Trecho de código da classe DAOGenerico Fonte: Os autores. A FIG. 20 traz um trecho da classe “DAOGenerico”, sendo feita através dela toda a
comunicação com a base de dados. Seus métodos trabalham com objetos que implementam a
interface “Persistivel”, ou seja, todas as entidades do sistema implementam esta interface, e
através desta classe é possível inserir, deletar e recuperar qualquer uma delas no banco de
dados.
Outros pontos relevantes foram a utilização do IReports, que facilitou na criação do
design dos relatórios e na integração destes com a aplicação; a programação em pares, que
propiciou uma codificação mais refinada e coesa e a modularização do software, que permitiu
a equipe desenvolvedora concentrar seus esforços em porções específicas da aplicação.
4.7 Testes realizados
A realização de testes em uma aplicação é uma das fases mais importantes e mais
dispendiosas, uma vez que se gasta muito tempo com o planejamento e a própria execução
dos mesmos. Para automatizar este processo, foi utilizado o framework JUnit, para a
realização de testes unitários na camada de serviço da aplicação.
Durante estes testes, foram detectados vários problemas estruturais e lógicos, nas quais
foram identificados e corrigidos. Após a realização dos testes, já com o módulo de cadastro de
70
doadores e colaboradores finalizados, foram realizados testes de unidade, com o objetivo de
identificar erros nas camadas do software.
Finalmente, antes de implantar o modulo de cadastro, foram realizados uma bateria de
testes, como o cadastro de vários doadores e colaboradores para testar a robustez da aplicação
em execução. Com a realização destes testes, verificamos que a estrutura implementada foi
satisfatória
4.8 Implantação
A implantação de um sistema informatizado em qualquer organização é algo
complexo, exigindo planejamento e readequações nos procedimentos organizacionais. A
implantação do ADSBD Manager foi estruturada a fim de reduzir o impacto da informatização
na entidade e não causar problemas com informações inconsistentes.
O módulo de gerenciamento de doadores de sangue e colaboradores financeiros, após
uma bateria de testes, foi implantado e está em funcionamento na entidade. Foi realizado um
treinamento no qual foi apresentado o sistema e suas principais funcionalidades, e aplicado
um questionário sobre sua usabilidade, sendo o resultado deste apresentado no gráfico abaixo
(GRAF. 4).
GRÁFICO 4 – Resultado do questionário de usabilidade Fonte: Os autores. O módulo de gerenciamento de atividades teve sua implantação reestruturada, pois,
durante a bateria de testes, foram encontradas falhas relacionadas principalmente aos
algoritmos de geração de relatórios, o que ocasionou um atraso na entrega da versão
definitiva. Tais falhas estão sendo analisadas pelos desenvolvedores e um planejamento para a
implantação futura foi elaborado.
71
4.9 Apresentação do Sistema
Conforme citado as interfaces gráficas do sistema foram desenvolvidas utilizando a
API Swing do Java. As figuras abaixo apresentam algumas telas do sistema, sendo abaixo de
cada uma delas explicada a sua funcionalidade.
A tela inicial apresenta as funcionalidades do sistema, que podem ser acessadas
através de uma barra de menus ou pelos ícones de atalho da barra de ferramentas. A FIG. 21
mostra a tela principal do ADSBD Manager.
FIGURA 21 – Tela inicial ADSBD Manager Fonte: Os autores.
A tela de cadastro de doadores é responsável pela edição, inclusão e atualização de
doadores de sangue, bem como a geração de um relatório, em formato PDF, que o usuário
poderá imprimir. A FIG. 22 mostra a tela de cadastro de doadores.
72
FIGURA 22 – Tela de cadastro de doadores Fonte: Os autores.
A tela de cadastro de colaboradores oferece as opções de inserção, atualização e
edição de um colaborador, bem como a geração de relatório, em formato PDF, dando as
opções de imprimir ou não. A FIG 23 mostra a tela de cadastro de colaboradores.
FIGURA 23 – Tela de cadastro de colaboradores Fonte: Os autores. A tela de busca avançada de doadores permite que o sistema faça uma busca
automatizada através dos campos nome, endereço, tipo sanguíneos, fator Rh, situação do
doador, disponibilidade para viajar e pela data de aniversário. A FIG 24 mostra a tela de busca
de doadores.
73
FIGURA 24 – Tela de busca avançada de doadores Fonte: Os autores. A tela de controle de doações é responsável por controlar todas as doações realizadas
per um doador, sendo informados a data, o motivo, o local e uma observação. A FIG. 25
mostra a tela de busca de doadores.
FIGURA 25 – Tela de controle de doações Fonte: Os autores.
A tela de gerenciamento projeto futuro doador é responsável pelo gerenciamento de
todas as atividades relativas a este projeto. Ela disponibiliza as opções de inserir qual o
público alvo, as atividades desenvolvidas e os recursos utilizados. A FIG 26 mostra a tela de
gerenciamento do futuro doador.
74
FIGURA 26 – Tela gerenciamento do projeto futuro doador Fonte: Os autores.
A aplicação abrange mais uma série de funcionalidades, e possui uma grande
quantidade de telas. Seria inviável a exposição de todas estas telas neste trabalho, por isso
foram apresentadas aquelas relacionadas as funcionalidades principais do sistema, a fim de
dar uma idéia geral sobre do ADSBD Manager.
4.10 Considerações Finais
Esta seção trouxe a metodologia de desenvolvimento do software. Foram apresentadas
todas as fases e detalhados os procedimentos em cada uma. Os diagramas de caso de uso e de
classe foram apresentados bem como o diagrama entidade-relacional que modelou a base de
dados do sistema. Por fim algumas telas foram mostradas a fim de propiciar uma maior
compreensão do que realmente foi desenvolvido.
O tópico seguinte traz algumas considerações sobre as dificuldades, contribuições e
possíveis melhorias para este projeto.
75
5 CONSIDERAÇÕES FINAIS DO PROJETO
Esta seção apresenta uma conclusão deste projeto, são abordadas as dificuldades
enfrentadas no seu desenvolvimento e suas contribuições. Outro ponto interessante é o que
trata de melhorias futuras para o projeto.
5.1 Dificuldades enfrentadas
Por se tratar de um projeto muito amplo, várias dificuldades foram encontradas. Tais
obstáculos podem ser categorizados sob 2 aspectos: os relacionadas a compreensão do
domínio da aplicação e os relacionados ao desenvolvimento do software.
Devido à complexidade da estrutura de funcionamento da ADSBD enfrentaram-se
dificuldades na compreensão de seu domínio. Pois a grande quantidade de informações e o
relacionamento dessas geram empecilho no entendimento para as pessoas que não estão
habituadas ao cotidiano da associação.
No que tange ao desenvolvimento do sistema, as principais dificuldades estão
relacionadas aos seguintes pontos: a documentação do software – devido à amplitude e
complexidade do negócio; definição da metodologia – exigiu uma grande pesquisa sobre as
varias metodologias existentes, a fim de se identificar as melhores praticas e, então, estruturar
uma que se adequasse ao projeto; a utilização do JPA na camada de persistência – por se tratar
de uma tecnologia recente, que auxilia no mapeamento objeto relacional, foi preciso realizar
um estudo detalhado para sua utilização neste projeto.
Também relacionada ao desenvolvimento do software, pode-se destacar a necessidade
do sistema não impactar fortemente nos procedimentos administrativos da associação. Isto se
deve ao fato dos funcionários da ADSBD não possuírem experiência com informática, e como
a migração do modelo manual para o informatizado já é um grande impacto, mudar também
tais procedimento poderiam causar a não utilização do sistema. Para tanto, foi preciso criar
um sistema onde os antigos formulários fossem apresentados digitalmente, mantendo-se
assim, a forma de gerenciamento.
É importante destacar que todas estas dificuldades enfrentadas foram agravadas ou
geradas pela inexperiência da equipe de desenvolvimento. Uma vez que esta é a primeira vez
que participaram de um grande projeto, realizando todas as fases do desenvolvimento, desde o
levantamento e análise dos requisitos até a implantação do software.
76
5.2 Contribuições do projeto
O desenvolvimento deste projeto contribui tanto para seus desenvolvedores quanto
para a ADSBD, associação para qual um sistema de gerenciamento foi construído.
As principais contribuições para os seus desenvolvedores estão relacionadas ao fato de
terem colocado em prática muitas das técnicas apreendidas durante o bacharelado. Por
exemplo, muitas metodologias foram estudadas, suas melhores práticas levantadas e uma
metodologia de desenvolvimento adequada ao projeto foi construída. Sendo assim, foi
possível desenvolver todas as fases de um projeto de software e, então, compreender melhor
como se dá este processo na prática.
Quanto às contribuições para a ADSBD destaca-se, inicialmente, uma pesquisa sobre a
doação de sangue, as associações de doadores de sangue e o gerenciamento destas, onde
foram mostradas as necessidades e dificuldades enfrentadas por estas entidades. Por fim e,
talvez a maior contribuição deste projeto, foi à construção de um sistema de gerenciamento
para a ADSBD, o ADSBD Manager. Este sistema foi desenvolvido baseado exatamente nos
seus procedimentos administrativos, a fim de facilitar toda administração da associação.
5.3 Trabalhos Futuros
Conforme citado anteriormente, este projeto foi abrangente e atingiu desde a situação
da doação de sangue e necessidades gerenciais das entidades do terceiro setor até a parte de
desenvolvimento de software, mostrando metodologias e ferramentas utilizadas. Porém o
ponto principal está no desenvolvimento do sistema de gerenciamento da ADSBD.
O sistema foi desenvolvido sob a linguagem Java e utilizou-se o Firebird como SGBD
e o Swing para a construção de interfaces gráficas. Em se tratando do software
especificamente, uma das melhorias seria a construção da camada de visão utilizando
tecnologias mais recentes que permitem a criação de interfaces mais elaboradas e interativas.
Apesar dos componentes Swing serem portáveis e flexíveis, uma vez que são
implementados em Java, não trazem muitos recursos que permitam a construção de interfaces
ricas, interativas e que facilitem a cognição do usuário. Daí a possibilidade de se reconstruir a
camada de visão utilizando uma tecnologia recente como o Flex, da Adobe ou JavaFX.
A utilização destas ferramentas traz inúmeros recursos para a construção de interfaces
ricas. A não utilização de uma destas tecnologias neste projeto se deve ao fato do tempo
77
necessário para o aprendizado ser grande, além do que o estudo sobre JPA e a compreensão
do domínio da aplicação consumiram muito tempo.
Por se falar do domínio da aplicação, este é outro ponto que pode passar por possíveis
melhorias. As mudanças aqui cabem nas situações onde a ADSBD alterar seus procedimentos
administrativos. Como citado, o Relatório Anual Circunstanciado segue um modelo do
Ministério da Justiça, e esse passa por alterações constantemente. Como as atividades internas
(atualmente são 39 atividades) são controladas a fim de ser a base deste relatório, é possível
que elas sejam adaptadas aos novos parâmetros do modelo. Podendo uma atividade ser
excluídas ou alteradas, bem como novas podem ser criadas.
Diante disso é interessante que, periodicamente, o sistema seja reavaliado, a fim de
adequá-lo aos procedimentos utilizados pela ADSBD. Em alguns destes casos será preciso
uma reestruturação da base de dados e, claro, das regras de negócio. Todas estas possíveis
melhorias visam propiciar a associação um sistema cada vez mais simples, intuitivo, confiável
e que atenda as suas necessidades de fato.
5.4 Considerações finais
O processo de doação de sangue é muito importante para a sociedade e através dele,
muitas vidas são salvas. Porém seus procedimentos são complexos e envolvem hospitais,
hemocentros, associações de doadores de sangue e, claro doadores e receptores.
Neste trabalho objetivou-se demonstrar o papel das associações de doadores de sangue
dentro do processo de doação e as suas formas de gerenciamento. Evidenciando-se as
necessidades enfrentadas por elas, devido à quantidade de documentos manipulados. A
dificuldade de encontrar softwares gerenciais que atendam as estas necessidades e como um
sistema informatizado auxiliaria no gerenciamento destas.
Outro objetivo, talvez o mais complexo, foi o desenvolvimento de um aplicativo
gerencial para a ADSBD. Utilizando de técnicas da engenharia de software, foi estruturado
todo um projeto de construção deste software, iniciando-se com o levantamento e analise de
requisitos, quando foram gerados os documentos visão e o SRS; passando pela modelagem
baseada na UML até a implementação e implantação do software.
Toda a documentação elaborada para a construção do ADSBD Manager encontra-se
disponível na “Documentação do software ADSBD Manager”. Também em uma mídia e na
web, através do site Source Forge, pelo link http://adsbdmanager.sourceforge.net/.
78
A metodologia de desenvolvimento do software foi baseada nas práticas da
metodologia em cascata, espiral e da Extreme Programming, a partir delas se criou um
metodologia que se adequasse as necessidades e limitações do projeto. Muitas ferramentas
foram utilizadas a fim de aumentar a produtividade e a confiabilidade, das quais se destacam
o Jude, na modelagem UML e o DBDesigner, na modelagem entidade-relacional.
A implementação foi feita na linguagem Java utilizando a IDE NetBeans, o que
facilitou muito este processo e minimizou algumas dificuldades. Durante esta fase vale
ressaltar a utilização da JPA na camada de persistência, o que gerou dificuldades por ser uma
tecnologia nova, mas que trouxe uma produtividade considerável ao projeto.
Sendo assim, implementado o ADSBD Manager, um sistema capaz de atender as
necessidades da associação, cadastrando doadores e colaboradores e gerando os relatórios
pertinentes. Este projeto tem pontos para melhorias, como a camada de visão, que utilizou a
API Swing, pode ser construída com uma tecnologia nova que traga mais qualidade e
interação as interfaces, como o Flex o JavaFX. Além de adequações na lógica de
funcionamento do sistema, em caso de mudanças nas rotinas de trabalho da associação.
Pode-se afirmar que este trabalho conseguiu, apesar das dificuldades enfrentadas,
apresentar o papel das associações de doadores de sangue e suas necessidades e dificuldades
no que tange seu gerenciamento. E que a partir de um estudo de caso, feito junto a ADSBD,
foi desenvolvido ADSBD Manager, um software capaz de atender as necessidades gerencias
da entidade.
79
REFERÊNCIAS
AGUIAR, Marianne Thamm de. ; SILVA, Eduardo Marcondes Filinto. Terceiro Setor: Buscando uma Conceituação. Cadernos Fundata. 2001. Disponível em: <http://www.fundata.org.br/Artigos%20-%20Cefeis/06%20-20TERCEIRO%20SETOR%20-%20BUSCANDO%20UMA%20CONCEITUA%C3%87%C3%83O.pdf> Acesso em: 11 jun. 2009. ALMEIDA, Alexandre de; DAROLT, Reginaldo. Pesquisa e desenvolvimento em UML. Universidade do Sul de Santa Catarina. Araranguá, 2001. Disponível em: <http://joaomorais.com.br/jm/uploads/Links/uml.pdf>. Acesso em: 30 set. 2009. ARAÚJO, Marco Antônio P. DBDesigner: Uma ferramenta gratuita para a modelagem de dados. SQL Magazine. 2009 disponíveis em: <http://www.devmedia.com.br/articles/viewcomp.asp?comp=6840>. Acesso em: 19 set. 2009. ASTELS, David; MILLER, Granville; NOVAK, Miroslav. Extreme Programming guia rápido. Rio de Janeiro: Campus, 2002. BANDEIRA, Junior Marcos. Estudo dos Sistemas de Gerenciamento de Bancos de Dados Firebird, Mysql e PostgreSql e seus recursos para armazenamento de imagens. Universidade Federal de Santa Maria. Santa Maria. Disponível em: <http://www.etaj.com.br/~jmoreira/apostila/pdfs/DBFree.pdf>. Acesso em: 8 set. 2009. BAUER, Christian; KING, Gavin. Hibernate em Ação. Rio de Janeiro: Editora Ciência Moderna Ltda., 2005. BECK, Kent. Programação extrema explicada: acolha as mudanças. Porto Alegre: Bookman, 2004. BIO, Sergio Rodrigues. Sistemas de informação: um enfoque gerencial. São Paulo: Atlas. 1991. BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do usuário. 2. ed. Rio de Janeiro: Elsevier, 2005. BURKE, Bill; MONSON-HAEFEL, Richard. Enterprise JavaBeans 3.0. 5. ed. São Paulo: Pearson Prentice Hall, 2007.
80
CARVALHO, Ana Elizabete Souza de; TAVARES, Helena Cristina; CASTRO, Jaelson Brelaz. Uma Estratégia para Implantação de uma Gerencia de Requisitos Visando a Melhoria Dos Processos de Software. Centro de Informática, Universidade Federal de Pernambuco. Disponível em: <http://www.creupiapostilas.hpg.ig.com.br/Pro-Req-3.pdf>. Acesso em: 03 jul. 2009. CEUNES – Programação III. Apostila Introdução a Orientação a Objetos. UFES/CEUNES. São Mateus-ES. s/a. Disponível em: <http://www.ceunes.ufes.br/downloads/2/mariateixeira-EC.Programa%C3%A7%C3%A3o%20III.Cap%C3%ADtulo%201.2009.2.pdf >. Acesso em: 04 nov. 2009. COURA, Michele dos Santos. Ambiente de Aprendizagem de Lógica de Programação. Faculdade de Engenharia de Guaratinguetá Especialização em Informática Empresarial. Guaratinguetá – SP. 2006. Disponível em: <http://www.feg.unesp.br/ceie/Monografias-Texto/CEIE0605.pdf>. Acesso em: 13 nov. 2009. DEITEL, H. M. ; DEITEL P. J. Java como programar. 6 ed. São Paulo: Pearson Prentice Hall, 2005. DURÃES, Dayane Helen Santos. Análise de Desempenho entre os Bancos de Dados POSTGRESQL e FIREBIRD na plataforma Windows 2000. Universidade Estadual de Montes Claros. Montes Claros, 2007. Disponível em: <http://www.ccet.unimontes.br/arquivos/monografias/246.pdf>. Acesso em: 08 set. 2009. ESTATUTO ADSBD. Associação de Doadores de Sangue de Bom Despacho. Estatuto. Bom Despacho, 2008. FERREIRA, Neuziany Nery; REIS, Regiane. Requisitenow!: Uma ferramenta web de apoio ao levantamento e análise de requisitos, baseado em casos de uso. Universidade da Amazônia, Belém, 2005 disponível em <http://www.cci.unama.br/margalho/portaltcc/tcc2005/PDF/004.pdf> Acesso em 19 de set 2009. FREITAS, Henrique M. R. de; KLADIS, Constantin Metaxa. Da organização a política informacional das organizações: um quadro conceitual. São Paulo; RAP, v 29, Junho/Setembro 1995. p. 73 – 86. Disponível em: <http://www.ea.ufrgs.br/professores/hfreitas/files/artigos/1995/1995_026_RAP.pdf>. Acesso em: 23 abr. 2009.
81
FREITAS, Gustavo André de; PARIS, Riliane Alpoim. FIREBIRD . Faculdade de Ciências Aplicadas Sagrado Coração. Linhares, 2007. Disponível em: <http://www.gfsolucoes.net/trabalhos/Firebird.pdf>. Acesso em: 08 set. 2009. FUNDAÇÃO HEMOMINAS. CENTRO DE HEMATOLOGIA E HEMOTERAPIA DE MINAS GERAIS. 2009. Disponível em: <http://www.hemominas.mg.gov.br/hemominas/menu/aInstituicao/apresentacao.html>. Acesso em: 01 set. 2009. GHIGNATTI, Sachia F. ; STEFFEN, Tereza E. ; TURCHETTO, Fabiano. Sistema para gestão de entidades sem fins lucrativos. Universidade Luterana do Brasil (ULBRA), Torres. 2007. Disponível em: <http://guaiba.ulbra.tche.br/pesquisas/2007/artigos/sistemas/301.pdf>. Acesso em: 03 set. 2009. GOMES, Emiliana Bezerra.; MAIA, Evanira Rodrigues. Doador voluntário ou de reposição? Fatores determinantes para um doador de reposição tornar-se doador voluntário de sangue. Saúde Coletiva: Coletânea. Número 1. Vol.1. Outubro/2007. ISSN 1982-1441. Disponível em <http://coletanea2007.no.comunidades.net/index.php?pagina=1254963751> Acesso em: 01 set. 2009. GONÇALVES, Edson. Dominando Relatórios JasperReports com iReport. São Paulo: Ciência Moderna, 2008. HIRAGI, Gilberto. Ambiente de Desenvolvimento para Java ênfase em NetBeans. Disponível em: <http://ashwall.cenargen.embrapa.br/hiragi/tap/resumos/AmbienteNetBeans.pdf>. Acesso em: 08 set. 2009. IBGE CIDADES. Instituto Brasileiro de Geografia e Estatistica. CidadesSat. 2007. Disponível em <http://www.ibge.gov.br/cidadesat/topwindow.htm?>. Acesso em: 02 out. 2009. KIDO, Eduardo Yassuji; HIRAMA, Kechi. Arcabouço para a gestão de impactos da adoção de ferramentas case baseado na IEEE1175. XXVIII Encontro Nacional de Engenharia de Produção. Rio de Janeiro. 2008. Disponível em: <http://www.abepro.org.br/biblioteca/enegep2008_TN_STO_076_536_12102.pdf>. Acesso em: 30 out. 2009. LOZANO, Fernando. Relatórios Corporativos com Java e Software Livre. 2006. Disponível em: <http://uploads.javafree.com.br/files/10190295398982E12-relatorios-java-2.pdf>. Acesso em: 12 nov. 2009.
82
LUDWIG, Silvia Terra.; RODRIGUES, Alziro César de Morais. Doação de sangue: uma visão de marketing. Caderno Saúde Pública. 2005, vol.21, n.3, p. 932-939. ISSN 0102-311X. doi: 10.1590/S0102-311X2005000300028. Disponível em: <http://www.scielo.br/scielo.php?script=sci_arttext&pid=S0102-311X2005000300028&lang=pt>. Acesso em: 31 ago. 2009. MASSOL, Vincent; HUSTED, Ted. JUnit em ação. Rio de Janeiro: Ciência Moderna, 2005. MEDEIROS, João Marcos. Marketing Social e a Doação de Sangue. III Seminário do Centro de Ciências Sociais Aplicadas Cascavel. Unioeste, Cascavel. Paraná. 2004. Disponível em: <http://www.unioeste.br/campi/cascavel/ccsa/IIISeminario/artigos/Artigo%2015.pdf>. Acesso em: 31 ago. 2009. MINISTÉRIO DA SAÚDE (BR). Coordenação de Sangue e Hemoderivados. Meta Mobilizadora Nacional: Sangue - 100% com garantia de qualidade em todo o seu processo até 2003. Brasília: Programa Nacional de Doação Voluntária de Sangue. 1998. MOURA, Aldilene Sobreira de, et al. Doador de sangue habitual e fidelizado: fatores motivacionais de adesão ao programa.Universidade de Fortaleza. 2006, RBPS, n. 19, p. 61-67. Fortaleza, Ceará. Disponível em: <http://www.unifor.br/notitia/file/855.pdf>. Acesso em: 01 set. 2009. NASCIMENTO, Marcos Ribeiro do; FALCÃO, Jonathas Barros; CUNHA, Adilson Marques da. Uso de ferramentas de software livre no processo de desenvolvimento de sistema de banco de dados: um estudo de caso. Instituto Tecnológico da Aeronáutica, 2006. Disponível em: <http://161.24.9.6:81/cunha/artigos_2006/02a_2006_FerrSWLivreImplBD(Cun-Mar-Jon).pdf>. Acesso em: 05 out. 2009. NETO, Aristides Vicente de Paula. Criando testes com JUnit. Universidade Federal de Pernambuco, Recife. 2006. Disponível em: <http://javafree.uol.com.br/dependencias/tutoriais/testes_junit.pdf>. Acesso em: 05 set. 2009. PENDER, Tom. UML, a bíblia . Rio de Janeiro: Elservier, 2004. PORTAL TECMEDIA. 2008. Disponível em: <http://www.tecmedia.com.br/noticias/portal-corporativo-para-entidade-social>. Acesso em: 06 set. 09. PRADO, André Alves. et al. Engenharia de Software em aplicações de tecnologia da informação visando maior qualidade nos Sistemas de Informações Gerenciais. Disponível em: <http://www.fatea.br/janus/pdfs/artigo02.pdf>. Acesso em: 04 set. 2009.
83
RELATÓRIO ANUAL CIRCUNSTANCIADO ANO BASE 2008. Associação dos Doadores de Sangue de Bom Despacho. Relatório. Bom Despacho, 2009. REQUERIMENTO CNAS. Associação dos Doadores de Sangue de Bom Despacho. Requerimento. Bom Despacho, 2007. RIBEIRO, Alisson; SILVA, Gabriel da. Extensão das Funcionalidades de um Ambiente Integrado de desenvolvimento para linguagem PHP-GTK: Modelagem e Implementação. Centro Federal de Educação Tecnológica. Bambuí-MG, 2008. Disponível em: <http://www.cefetbambui.edu.br/str/artigos_aprovados/informatica/70-CO-5.pdf> Acesso em: 08 set. 2009. RUIZ, Evandro Eduardo Seron. Introdução ao Java. 2008. Disponível em: <http://dfm.ffclrp.usp.br/~evandro/ibm1030/intro_java/java_basics.html>. Acesso em: 13 nov. 2009. SANTANA, Fabrício. et al. Persistência com EJB 3.0 – Java Persistence API (JPA). Disponível em: <http://disciplinas.dcc.ufba.br/pub/MATA60/WebHome/persejb.pdf>. Acesso em: 04 set. 2009. SANTOS, Alexandro Klein dos. Os IDE’s (Ambientes de Desenvolvimento Integrado) como ferramentas de trabalho em informática. Universidade Federal de Santa Maria (UFSM). Santa Maria, 2007. Disponível em: <http://www-usr.inf.ufsm.br/~alexks/elc1020/artigo-elc1020-alexks.pdf>. Acesso em: 08 set. 2009. SHIGUNOV NETO, Alexandre; TEIXEIRA, Alexandre. Sociedade do conhecimento e ciência administrativa: reflexões iniciais sobre a gestão do conhecimento e suas implicações organizacionais. Belo Horizonte; Perspectiva da Ciência da Informação, v.11, n.2, Maio/Agosto 2006. p. 220 – 232. Disponível em: <http://www.eci.ufmg.br/pcionline/index.php/pci/article/viewFile/324/128> Acesso em: 19 abr. 2009. SIAB. Sistema de Informação de Atenção Básica. SubSistema do DataSUS. 2008. Disponibilizado pela Secretaria Municipal de Saúde de Bom Despacho. SIMOR, Fernando W.; DORNELES, Carina F. Um estudo de caso para análise comparativa entre programação Estruturada e Orientada a Objetos. Instituto de Ciências Exatas e Geociências - Universidade de Passo Fundo. Passo Fundo-RS. 2009. Disponível em <http://www.upf.br/computacao/images/stories/TCs/arquivos_20091/Fernando_Simor.pdf>. Acesso em: 04 nov. 2009.
84
SOARES, Euvaldo Antonio Ruiz; CATÃO, Gustavo Campos; SANTOS, Aldemar Araújo. Impacto Organizacional Da Implantação Dos Sistemas Integrados De Gestão Nas Entidades Do Terceiro Setor. 2004. Disponível em: <http://www.intempres.pco.cu/Intempres2000-2004/Intempres2004/Sitio/Ponencias/16.pdf>. Acesso em: 11 jun. 2009. SOMMERVILLE,Ian. Engenharia de software. 8. ed. São Paulo: Pearson Addison-Wesley, 2007. TAVARES, Claudia Fernanda. Onde irão agora as metodologias de desenvolvimento?. Universidade Federal do Rio Grande do Norte. Natal-RN. Disponível em: <http://www.consiste.dimap.ufrn.br/~claudia/Mestrado/Disciplinas/Engenharia_Software/Artigo%5B3%5D_MetodologiasDeDesenvolvimento.pdf>. Acesso em: 04 set. 2009. TELES, Vinícios Manhães. Extreme Programming: Aprenda como encantar seus usuários desenvolvendo softwares com agilidade e alta qualidade. São Paulo: Novatec, 2006. VASCONCELOS, Alexandre Marcos Lins de. et al. Introdução a engenharia de software e a qualidade de software. Universidade Federal de Lavras, Lavras-MG. 2006. Disponível em: <http://www.facape.br/jocelio/es/apostilas/Mod.01.MPS_Engenharia&QualidadeSoftware_V.28.09.06.pdf>. Acesso em: 05 set. 2009. VERTCHENKO, Stela Brener. Doação de Sangue: Aspectos sócio-econômicos, demográficos e culturais na região metropolitana de Belo Horizonte. Universidade Federal de Minas Gerais Programa de Pós-Graduação em Saúde Pública. Belo Horizonte-MG. 2005. Disponível em: <http://www.medicina.ufmg.br/saudepublica/dissert/stela_vertchenko05.pdf>. Acesso em: 01 set. 2009. VITORINO, Aurélio J. ; COSTA, Rogério H. da; KENCHIAN, Mary R. B. Política de Segurança em Tecnologia da Informação na Saúde: Modelo Corporativo Aplicado no HCFMUSP, XI Congresso Brasileiro de Informática na Saúde, 2008. Disponível em <http://www.sbis.org.br/cbis11/arquivos/818.pdf>. Acesso em: 30 ago. 2009.
