1

PONTIFÍCIA UNIVERSIDADE CATÓLICA DE MINAS GERAIS

NÚCLEO DE EDUCAÇÃO A DISTÂNCIA
Pós-graduação Lato Sensu em Arquitetura de Software Distribuído

Nome Aluno

SISTEMA DE CONTROLE DE DOAÇÃO DE SANGUE

Belo Horizonte
2016
 2

Nome Aluno

SISTEMA DE CONTROLE DE DOAÇÃO DE SANGUE

Trabalho de Conclusão de Curso de Especialização

em Arquitetura de Software Distribuído como
requisito parcial à obtenção do título de especialista.

Orientador(a): Nome Professor

Belo Horizonte
2017
 3

Dedicatória (opcional)
 4

AGRADECIMENTOS
Opcional
 5

RESUMO

Este projeto aborda uma solução de controle de informações e agendamento de

consultas para doação de sangue por meio da internet, utilizando dispositivos móveis ou
desktop. Atualmente os bancos de sangue enfrentam problemas relacionados aos estoques
sanguíneos por falta de doadores. Isto se deve ao fato de que, muitas vezes, as pessoas não
têm tempo ou não sabem a localização de um determinado banco de sangue. Outro ponto
relevante é a questão do agendamento, pois, muitas vezes, as pessoas têm que ligar para os
laboratórios para saber se existe agenda disponível, sobrecarregando os atendentes. Outro
ponto crítico é o fato das clínicas, hospitais e o Sistema Único de Saúde (SUS) do Governo
Federal não se integrarem de maneira que possibilite um atendimento mais rápido,
melhorando o controle das informações, processos internos e exames efetuados, até mesmo
identificar as necessidades de maneira mais ágil. Para solucionar este problema, o projeto
propõe criar um sistema onde seja possível disponibilizar um controle mais eficiente do
agendamento, possibilitando ao doador por meio de um cadastro na internet, escolher o
laboratório mais próximo de sua residência e com os dias e horários disponíveis, assim
trazendo comodidade ao doador. O projeto arquitetural aborda uma solução de integração
entres os hospitais, laboratórios e o SUS para automatizar todo o processo, desde o
agendamento, a coleta, até chegar ao paciente que necessita da doação.

Palavras-chave: Arquitetura de Software. Software-Desenvolvimento. Doação de Sangue.

Serviços Web. Arquitetura Orientada a Serviço. Web Responsiva.
 6

SUMÁRIO

1. Objetivos do trabalho .............................................................................................. 7

2. Descrição Geral da Solução .................................................................................... 7
2.1. Apresentação do problema .................................................................................. 7
2.2. Descrição Geral da Solução (Escopo) ................................................................. 8
3. Definição conceitual da solução .............................................................................. 9
3.1. Requisitos Funcionais .......................................................................................... 9
3.2. Requisitos Não-Funcionais................................................................................. 15
3.3. Restrições Arquiteturais ..................................................................................... 18
3.4. Mecanismos Arquiteturais .................................................................................. 18
4. Modelagem e projeto arquitetural .......................................................................... 19
4.1. Modelo de casos de uso..................................................................................... 19
4.2. Descrição resumida dos casos de uso ............................................................... 26
4.3. Modelo de componentes .................................................................................... 28
4.4. Modelo de implantação ...................................................................................... 29
4.5. Modelo de dados ................................................................................................ 31
5. Prova de conceito / protótipo arquitetural .............................................................. 31
5.1. Implementação e implantação............................................................................ 31
5.2. Interfaces............................................................................................................ 33
6. Avaliação da Arquitetura ....................................................................................... 35
6.1. Análise das abordagens arquiteturais ................................................................ 35
6.2. Identificação dos atributos de qualidade ............................................................ 35
6.2. Cenários ............................................................................................................. 35
6.4. Avaliação ............................................................................................................ 37
6.5. Resultados ......................................................................................................... 45
7. Conclusão ............................................................................................................ 46
REFERÊNCIAS ......................................................................................................... 46
APÊNDICE B – Código Fonte ................................................................................... 48
 7

1. Objetivos do trabalho
O objetivo geral deste projeto é apresentar uma proposta de arquitetura para
automatizar o processo de doação de sangue, auxiliando o doador a localizar um centro de
doação mais próximo e, assim, efetuar um agendamento de forma mais rápida e cômoda pela
internet. O projeto visa atender e facilitar o controle dos agendamentos pelos profissionais da
saúde, possibilitando que os novos sistemas legado e atuais dos agentes possam se integrar
com essa plataforma, deixando os processos automatizados e mais rápidos, reduzindo custo e
tempo.
Os objetivos específicos são:
1. Criar um módulo web que possibilite agendamento online, que seja responsivo,
atendendo tanto desktop quanto usuários com acesso móbile. Esse módulo terá
acesso público na internet.
2. Criar os módulos para os agentes que possibilite o controle dos agendamentos,
dos exames efetuados e o envio dos resultados aos doadores. Esse módulo será
restrito para os profissionais da saúde, com autenticação segura.
3. Possibilitar que os agentes possam enviar, de forma integrada e cômoda, todos
os dados necessários de exames e serviços para o sistema do SUS, para que
possam receber por eles.
4. Possibilitar que os hospitais possam fazer a gestão das campanhas e integrá-las
as redes sociais para atingir o maior número de pessoas possíveis.
5. Possibilitar o rastreamento utilizando sensores de RFID com o objetivo de um
controle mais eficiente das informações e a localização da bolsa de sangue.

2. Descrição Geral da Solução

2.1. Apresentação do problema

Hoje, são vários os aspectos que fazem com que as pessoas doem menos sangue no
Brasil do que em outros países. A falta de conscientização dos doadores, a deficiência
estrutural dos locais de doação para minimizar os descartes de sangue e o controle
ineficiente impossibilitam que os laboratórios e hospitais possam agilizar os processos
burocráticos de doação de sangue.
 8

Atualmente um dos problemas constantes na área da saúde é a coleta e distribuição de

sangue, hoje em dia esse processo é feito arcaicamente e sofre um grande déficit de doações
de sangue.
O início do processo de doação de sangue ocorre a partir do momento em que o
doador manifesta interesse de doar. Atualmente o doador precisa descobrir o telefone de
contato do laboratório mais próximo para fazer o agendamento. Cada laboratório faz o
cadastro das informações do doador. Porém, cada laboratório possui um formulário distinto, o
que dificulta a identificação do doador.
Atualmente, a solicitação de bolsas de sangue é feita pelo médico do paciente receptor
através de e-mail ou telefonando diretamente ao laboratório. Considerando que cada
laboratório possui seu próprio controle do banco de sangue, o Sistema Único de Saúde não
consegue saber de maneira precisa o nível do estoque dos bancos de sangue por região ou
município. Nesse cenário, também é difícil identificar os serviços prestados em cada doação.
Durante a etapa de aprovação do pagamento dos serviços, realizada pelo setor financeiro do
SUS, há poucos detalhes sobre os serviços prestados em cada doação, dificultando a auditoria
e a detecção de incoerências nos serviços prestados pelos laboratórios.

2.2. Descrição Geral da Solução (Escopo)

A aplicação se aplica em função de uma melhor distribuição e coleta dentro da rede de

saúde privado e público. Possibilita imediata verificação entre essas no tocante a informação
de quantidades e tipagens sanguíneas a disposição, isso em tempo real.
O sistema a integração entre SUS, rede privada e pública da necessidade imediata do
sangue a disposição, como também fará automaticamente uma previsão de necessidades futu-
ras do material.
As equipes de coleta podem ter a informação dos exames que devem ser realizados ao
coletar o sangue, através de dispositivos informatizados, de modo a conhecer e estabelecer o
teor qualificativo do material a ser distribuído.
O banco de dados de tipagem e quantidades de sangue a disposição na rede se justifica
pelo mero fato de que uma vida humana requer velocidade e eficácia para ser salva. Também
promove a confiabilidade e veracidade das informações para que não haja problemas de des-
vio ou utilização indevida do material coletado.
Esse sistema será acessado por vários usuários. Doador, Unidades Hospitalares,
Laboratórios, SUS, Equipe de coleta e Gestor.
 9

• Doador: poderá realizar seu cadastro prévio bem como agendar o período para
realizar a doação de sangue.
• Unidades Hospitalares, Laboratórios, SUS: por sua vez esses usuários poderão
ter acesso à quantidade e tipagem sanguínea disponível na instituição, bem como
também podem credenciar-se para utilização do sistema com cadastro prévio e
validado pelo GESTOR.
• Equipe de coleta: responsável por coletar o sangue e identificar quais exames
deverá ser realizado.
• Gestor: Acompanha e planejar por meio de relatório e gráficos a distribuição e/ou
coletas das bolsas sanguíneas. Bem como aprovar ou não o credenciamento das
unidades, laboratório.

3. Definição conceitual da solução

3.1. Requisitos Funcionais

Obs.: não é necessário dividir em módulos como exemplificado, mas é aconselhável
para ficar aderente à proposta.
Módulo Administrador (Privado)
• Cadastro de Usuários
O sistema deve permitir que o administrador cadastre usuários para o controle do sis-
tema;
O sistema deve permitir que o administrador defina o perfil dos usuários como: Ad-
ministrador, Operador.
• Cadastro de Tipos de Agentes
O sistema deve permitir que o administrador cadastre o tipo de agente, possibilitando
que o sistema fique dinâmico e multi-agentes;
• Cadastro de Agentes
O sistema deve possibilitar ao administrador do sistema cadastrar os agentes. O cadas-
tro deve permitir que o administrador defina qual o tipo de agente, como: Unidade
Hospitalar, Laboratório de Análises Clínicas e Sistema Único de Saúde;

Módulo Agenda (Privado)

• Cadastro de Agenda
 10

O sistema deve possibilitar ao administrador do sistema cadastrar a disponibilidade de

agenda para os doadores. O administrador poderá vincular a agenda para o agente especi-
fico cadastrado no sistema.
O sistema deverá possibilitar o cadastro de horários disponíveis para atendimento em fai-
xa de 1 horas. Por exemplo: 07:00, 08:00, 09:00 etc. O sistema deverá permitir um nume-
ro x de agendamento em cada range de hora.
O sistema deverá possibilitar parametrizar esse números de agendamento por hora
O sistema só permitira que os administradores visualizam a agenda geral do sistema. O
operadores dos agentes só poderão visualizar sua própria agenda.
O sistema deverá permitir que essa agenda possa ser consumida através de um serviço
web para que outros sistema legados possa visualizar em seu próprio sistema.
O sistema deverá permitir que o cadastro de agenda possa ser feito através de serviço
web.

Módulo Unidade Hospitalar

• Cadastro de Operadores
O sistema deve permitir o cadastro de usuário/operadores que possam solicitar doação de
sangue;
• Recebimento de Doação
O sistema deve permitir que a unidade hospitalar solicite doação de sangue pelo próprio
sistema ou pela a integração. O sistema deve possibilitar a integração através de um ser-
viço web para que essa solicitação possa ser executada pelo sistema legado hospitalar ou
clínico. Essa solicitação poderá ser efetuada por tipo sanguíneo e quantidade.
O sistema deve permitir que a unidade hospitalar informe o destino da bolsa de sangue e
os dados do paciente que recebeu a doação. O sistema deve permitir que a unidade hospi-
talar registre o diagnóstico do paciente que recebe a doação;
Essa funcionalidade deve ser disponível pelo sistema interno web ou interface de integra-
ção.
O sistema deve registrar todas essas solicitações para que seja possível o envio de forma
consolidada ao SUS.
O sistema deve permitir a leitura pelo sistema RFID utilizando leitor USB para identificar
a bolsa de sangue recebida.

Módulo Sistema Único de Saúde (SUS)

 11

• Consolidação dos Dados

O sistema deve possibilitar o envio de todas as informações de doações e distribuições
solicitadas de forma consolidada para o SUS. Essas informações consolidadas devem
contemplar:
▪ Doações solicitadas pelos hospitais;
▪ Distribuições;
▪ Serviços e Exames realizados.
O sistema deve permitir que o envio seja manual ou em lote;
O envio das informações consolidadas deverá ser efetuado por meio dos serviços dispo-
níveis pelo sistema legado de pagamento do SUS. Essa integração é efetuada pelo Web-
Service;

Módulo Agendamento de Doação (público)

• Cadastro de Doadores
O sistema deve possibilitar que os doadores possam se cadastrar pela internet. Esse ca-
dastro deve coletar todas as informações necessárias para que o sistema consiga fazer
uma triagem inicial dos dados. No cadastro, o sistema deve completar o endereço do doa-
dor quando o mesmo informar seu CEP residencial. Essas informações devem vir de uma
base de endereços do correios;
O sistema deve solicitar ao doador que o mesmo confirme seus dados pelo e-mail que ele
receberá após completar seu cadastro;
O sistema deve efetuar a triagem básica por meio das informações coletadas pelo sistema
de cadastro de doadores e informar ao doador se ele está apto ou não para continuar com
o processo de agendamento. Essa análise deve ser efetuada de acordo com as normas na-
cionais e internacionais, como as do Ministério da Saúde, da Associação Americana e do
Conselho Europeu de Bancos de Sangue;
O sistema só pode autorizar o agendamento para o doador após as informações de cadas-
tro passarem pela triagem do sistema, informando se o mesmo está apto ou não para efe-
tuar o agendamento online;
• Agendamento
O sistema deve permitir que doadores cadastrados e aptos possam agendar a doação de
sangue pelo sistema online. No agendamento, o sistema deve possibilitar que o doador
possa escolher a unidade clínica/laboratórios conveniados mais próximo, de acordo com
 12

o endereço cadastrado e permitir que o doador possa escolher datas e horários definidos
pelo sistema;
• Resultado do Exame
O sistema deve possibilitar ao doador imprimir o resultado do exame pela internet com a
senha fornecida na coleta.

Módulo Coleta de Sangue (privado)

• Autorizar Coleta
O sistema deve permitir ao operador localizar agendamentos "Apto" no sistema e gerar a
senha de triagem/coleta;
O sistema deve permitir o cadastro do doador que não efetuou o agendamento pela inter-
net;
O sistema deve levar em consideração o horário do agendamento e a hora que o doador
chegou ao laboratório e gerar a fila da senha de acordo com as seguintes informações: ca-
so seja atendimento prioritário, deve ter a senha gerada com código "P" e a ordem na fila
de atendimento; caso seja doador sem prioridade, o sistema deve gerar a senha com o có-
digo "C" + ordem na fila.
O sistema deve organizar a fila de acordo com o horário de agendamento, de forma que
respeite o atendimento e horários agendados. O sistema deve ter uma inteligência, com a
qual seja possível organizar as filas de acordo com o horário, levando em consideração
atendimento prioritário e não prioritário.
O sistema deve gerar a senha para agendamentos atrasados, quando o doador chega após
o horário agendado. Nessa situação, o sistema deve permitir a coleta e gerar a senha no
final do último atendimento liberado até aquele momento.
O sistema deve gerar uma pulseira de controle com os dados do doador. Ele deve permitir
que o operador imprima essa pulseira para colocar no pulso do doador, a qual deve conter
os seguintes dados: "Nº Senha, Nome do doador, data de nascimento";
• Painel de Senha
O sistema deve disponibilizar um painel de senha para o laboratório dispor de um proces-
so mais organizado na fila de doação. O painel deve mostrar o código e o nome do doa-
dor na tela.
 13

O sistema deve permitir a calibragem de chamadas para atendimento prioritário e não

prioritário. O sistema deve ter um valor padrão 3 x 1, ou seja, a cada 3 prioritário, chama
1 não prioritário.
O sistema deve permitir que essa calibragem seja definida apenas para um usuário, ou se-
ja, o sistema deve permitir que um usuário possa atender somente "Prioritários" ou "Não
prioritários";
• Registro da Coleta
O sistema deve possibilitar que, ao final da coleta de sangue, o enfermeiro(a) possa in-
formar no sistema que o processo de coleta foi finalizado, liberando o sangue coletado
para exames;
O sistema deve emitir um documento com os dados do doador, data de previsão do resul-
tado dos exames e uma senha web para que o doador possa visualizar o resultado pela in-
ternet.
O sistema deve possibilitar que o doador possa avaliar a qualidade do atendimento. Essa
funcionalidade deve estar disponível na internet ou num terminal de atendimento no labo-
ratório. O sistema deve solicitar que o doador escolha uma das opções: Ruim, Regular,
Bom, Muito Bom, Ótimo;

• Rastreamento Bolsa Sangue

O sistema deve possibilitar o registro das informações do doador em um chip RFID, o
qual acompanhará a bolsa de sangue e poderá ser rastreado de forma mais segura.
O sistema deve possibilitar a leitura de dados RFID das informações contidas no chip e
registrar todos os dados no sistema para fins de rastreabilidade e relatório;
Módulo Controle de Exames (privado)
• Localizar Exames
O sistema deve permitir localizar as informações dos doadores que estão com exames
pendentes pelo NOME, CPF e/ou RG;
O sistema deve permitir adicionar o resultado dos exames coletados para o prontuário do
doador no sistema, em formato PDF ou de forma manual. O sistema deve possibilitar que
o resultado dos exames possa ser enviado pela integração com o sistema legado dos labo-
ratórios. Essa integração deve estar disponível por meio de serviço web;
O sistema deverá notificar ao doador, por E-mail ou SMS, que o resultado dos exames já
está disponível e pode ser obtido pela internet ou no laboratório onde realizou a coleta;
 14

O sistema deve ser integrado com sistema do SUS para que possa enviar o resultado dos
exames e informações consolidadas;
• Resultado Exames
O sistema deve permitir localizar o resultado dos exames por Data, Nome, CPF, RG, Se-
nha;
O sistema deve permitir imprimir o resultado dos exames.
O sistema deve permitir enviar manualmente o resultado dos exames em formato PDF pa-
ra o doador por e-mail;

Módulo Controle de Campanhas (privado)

• Cadastro
O sistema deve permitir o cadastro de campanhas. Nesse cadastro deverão ser solicitadas
algumas informações essenciais para a consolidação dos dados e geração de relatórios ge-
rencias para campanhas, como: Nome da Campanha, Data Início e Fim da campanha,
Apoiadores, Objetivos, Região, estado, cidade, imagem da campanha;
O sistema deverá possibilitar ao final de cada campanha registrar os dados/números obti-
dos na campanha.
O sistema deverá possibilitar o Upload da imagem do folder da campanha;
• Rede Social
O sistema deverá permitir que a campanha cadastrada seja publicada nas principais redes
sociais, como Facebook e Instagram;

Módulo Relatório (privado)

• Relatórios Gerenciais
O sistema deve possibilitar a extração de dados em formato EXCEL ou PDF com os da-
dos consolidados por região, cidade, estado, tipo de sangue, sexo, quantidades de pessoas;
• Relatório Analítico
O sistema deve possibilitar a extração dos dados em formato EXCEL ou PDF das infor-
mações sobre a rastreabilidade das doações. O relatório deverá conter todas a informa-
ções do doador, até quem recebeu a doação.
O sistema deverá possibilitar a extração de um relatório onde informe o volume de doa-
ção por região, estado e cidade. O sistema deve ser inteligente conforme as escolhas do
usuário da seguinte maneira: Ao escolher a região, ele deverá carregar os estados de
 15

acordo com aquela região e carregar as cidades de acordo o estado selecionado. O sistema
deverá utilizar o serviço de integração dos CORREIOS para essa funcionalidade.

3.2. Requisitos Não-Funcionais

A seguir são apresentados os requisitos não funcionais do sistema:

(você pode fazer uma lista enumerada de requisitos. Eles devem estar coerentes e válidos.
Usar o princípio SMART na declaração).

Um exemplo usando a forma Estímulo-Resposta

• Usabilidade - O sistema deve prover boa usabilidade

Estímulo Usuário realizando um agendamento
Fonte do Estímulo Usuário acessando uma funcionalidade de agendamento
Ambiente Funcionamento, carga normal
Artefato Módulo Agendamento de Doação
Resposta A camada de apresentação apresenta facilidade de navega-
ção, simplicidade e objetiva.
Medida da resposta Usuário conseguiu realizar o agendamento em no máximo
5 minutos

• Acessibilidade - O sistema deve suportar ambientes Web responsivos e ambientes mó-

veis.
Estímulo Realização do Agendamento
Fonte do Estímulo Usuário acessando o sistema de um celular.
Ambiente Funcionamento, carga normal
Artefato Módulo de Agendamento de Doação
Resposta A camada de apresentação se adaptou as resoluções e ta-
manho das telas, mudando os componentes de posição de
forma a ficar melhor a navegação do usuário.
Medida da resposta Identidade visual semelhante em todas as resoluções, com
objetos redimensionados de acordo com a resolução e ta-
manho.
 16

• Desempenho - O sistema deve ser rápido.

Estímulo Acessando a tela de consulta de agendamento
Fonte do Estímulo Usuário efetuando uma consulta de agendamento
Ambiente Funcionamento, carga normal
Artefato Módulo de Agendamento de Doação
Resposta O sistema respondeu com os dados solicitados
Medida da resposta O sistema respondeu em menos de 8 segundos

• Desempenho - Processamento do sistema para dados massivos em lote

Estímulo Envio de dados massivo em lote
Fonte do Estímulo Sistemas legado dos agentes
Ambiente Funcionamento, carga normal
Artefato Módulo Sistema Único de Saúde, Módulo Unidade Hospi-
talar
Resposta O sistema processou de forma massiva os lotes de dados
Medida da resposta O sistema deverá processar 500 registros de forma massiva
em no máximo 60 segundos.

• Desempenho - Gerar relatório analítico

Estímulo Geração de relatório
Fonte do Estímulo Usuário acessa a tela para gerar relatório analítico
Ambiente Funcionamento, carga normal
Artefato Módulo Relatório
Resposta O sistema recupera os dados analiticos desejado e exibe na
tela para o usuário.
Medida da resposta Um relatótio analitico mensal (de 30 dias) deve ser exibido
para o usuário em no máximo 20 segundos.
• Manutenibilidade - O sistema deve apresentar manutenção facilitada.
Estímulo Um componente de negócio responsável pelo envio de e-
mails precisa ser atualizado.
Fonte do Estímulo Lentidão ocorreu durante o envio de e-mail.
Ambiente Diversos módulos usam esse componente. Na ocasião da
 17

falha, o componente poderia estar atendendo várias notifi-

cações de exames ou cadastro.
Artefato Módulo Agendamento Doação, Módulo Controle Exames.
Resposta Todas as notificações de e-mail devem ser atendidas após a
atualização do componente.
Medida da resposta Todos os e-mails na fila de processamento devem ser envi-
ados em até 1 minuto.

• Testabilidade - O sistema deve ser simples para testar

Estímulo Execução de testes no sistema
Fonte do Estímulo Analista desenvolvedor
Ambiente Ambiente de Desenvolvimento
Artefato Módulo Administrador, Cadastro de Usuário
Resposta O sistema testou todas as funcionalidades como inclusão,
edição, exclusão, localização.
Medida da resposta O sistema deve possibilitar efetuar os testes com scripts
automatizados executando com apenas um comando.

• Interoperabilidade - O sistema deve se comunicar com os sistemas dos agentes. Al-

guns desses sistemas são antigos e desenvolvidos com tecnologia COBOL/CICS.
Estímulo Teste de conexão
Fonte do Estímulo Sistemas dos Agentes
Ambiente O sistema está em funcionamento com carga normal
Artefato Módulo Sistema Único de Saúde, Módulo Controle Exa-
mes.
Resposta O WebService do sistema SUS respondeu com sucesso a
solicitação.
Medida da resposta Conexão efetivada.

• Disponibilidade - O sistema deve operar em qualquer período do dia e da noite.

Estímulo Shutdown no cluster primário do servidor de aplicação.
Fonte do Estímulo Administrador do Servidor de Aplicação
 18

Ambiente Diversos usuários estão utilizando o sistema

Artefato Gerenciador de cluster
Resposta Todos os usuários logados na aplicação devem continuar
utilizando o sistema sem perceber que houve uma queda de
um dos Nós do servidor de aplicação.
Medida da resposta Todas as solicitações dos usuários devem ser atendidas,
podendo haver um atraso de 3 segundos devido à queda de
um dos Nós.

• Segurança - O sistema deve apresentar altos padrões de segurança.

Estímulo Acessar uma página privada pela url sem estar logado no
sistema.
Fonte do Estímulo Usuário Administrador
Ambiente Em funcionamento com carga normal.
Artefato Módulo Administrador, Unidade Hospitalar, Sistema Úni-
co de Saúde, Coleta de Sangue, Controle de Exames, Con-
trole de Campanha, Relatórios, Agenda
Resposta O sistema deve redirecionar o usuário para a tela solicitan-
do usuário e senha.
Medida da resposta O sistema não deve permitir o acesso a páginas privadas.

3.3. Restrições Arquiteturais

• O sistema deve ser desenvolvido em JAVA
• O sistema deve utilizar o serviço dos correios para disponibilizar os dados
precisos de cadastro de endereço e CEP.
• O sistema deve abrir de forma responsiva em aparelhos menores, como celular
e tablet.
• O sistema deve ser modular para facilitar a implantação.
• As integrações entre os sistemas devem utilizar o padrão ws-security.

3.4. Mecanismos Arquiteturais

Mecanismo de Análise Mecanismo de Design Mecanismo de Imple-
mentação
 19

Persistência Banco de dados relacional MySql

Persistência Framework ORM Hibernate

Acesso dados em Framework Cache EhCache

memória
Comunicação entre Contêiner EJB GlassFish 4
processos
Integração com siste- Interface utilizando XML WebServices
mas legados

Log Framework Log4j

Auditoria Framework ORM Hibernate ORM Envers

Build Ferramenta de Compilação Maven

Deploy Configuração da IDE de deploy Eclipse

Front-End Interface de comunicação com o XHTML, JSF,

usuário do portal. PRIMEFACES, AJAX,
JASPER REPORT

4. Modelagem e projeto arquitetural

4.1. Modelo de casos de uso

O diagrama de casos de uso oferece uma visão global dos casos de uso e dos atores
que dele participam. Para uma melhor analise arquitetural do projeto, separei os casos de uso
por módulos de acordo com os requisitos informados acima.
 20

OBS.: Essa separação em módulos é só um exemplo. Não é necessário separar em

módulos .

Figura 1 - Diagrama de Casos de Uso: Módulo Administrador

 21

Figura 2 - Diagrama de Casos de Uso: Módulo Unidade Hospitalar

 22

Figura 3 - Diagrama de Casos de Uso: Módulo SUS

 23

Figura 4 - Diagrama de Casos de Uso: Módulo Agendamento de Doação

 24

Figura 5 - Diagrama de Casos de Uso: Módulo Coleta de Sangue

 25

Figura 6 - Diagrama de Casos de Uso: Módulo Controle de Exames

Figura 7 - Diagrama de Casos de Uso: Módulo Controle de Campanha

 26

Figura 8 - Diagrama de Casos de Uso: Módulo Relatório

Figura 9 - Diagrama de Casos de Uso: Módulo Agenda

4.2. Descrição resumida dos casos de uso

 27

Faça aqui uma descrição resumida de cada caso de uso. Pode ser também no formato
de estórias.
Exemplo:
O caso de uso: efetuar agendamento
Descrição resumida:
Este caso de uso permitir ao usuário realizar um agendamento de doação. Ele deve
fornecer ao doador a possibilidade de visualizar todos os laboratórios de análises clíni-
cas próximos a sua residência. Deve fornecer um calendário e filtros para o doador vi-
sualizar as possíveis datas e horários disponíveis para a sua doação.

Estória

Como doador de sangue ID.:

01

Eu quero realizar o agendamento da minha doação pelo aplica-

tivo móvel ou web, informando o local, data e hora do agenda-
mento da doação. Também quero alterar e/ou excluir agenda-
mentos realizados.

Para não precisar realizar o agendamento por telefone ou ir

pessoalmente ao local de doação para agendamento.

Prioridade: ALTA Estimativa: 1

 28

4.3. Modelo de componentes

O diagrama componentes do sistema, os quais impactaram no design da arquitetura e
seleção das tecnologias. Foram organizados para serem reutilizáveis e fornecendo interfaces
bem definidas de acordo com suas responsabilidades.

Descrição dos componentes.

 29

Exemplos
Serviços: agrega os serviços que são disponibilizados pela aplicação.
Controllers: agrega os controladores da aplicação. É um controlador para cada
Módulo. Em refatoração próxima, os controladores serão divididos por caso de uso.

4.4. Modelo de implantação

A seguir é mostrado um detalhamento dos componentes e os módulos

envolvidos e como o modelo de implantação deve ser implantando para atender
principalmente os requisitos não funcionais de disponibilidade e performance. No modelo
acima não está explicito a arquitetura de cluster. Nessa arquitetura devemos considerar um
sistema de cluster balanceado. Assim podemos garantir que em uma sobrecarga em um dos
servidores, o processo de balanceamento possa redirecionar para outro servidor que esteja
com uma menor carga. Dessa forma pode-se garantir a disponibilidade e a performance do
sistema.
 30

No modelo de implantação acima, pensando nos RNF de desempenho, vai diminuir a

carga de consultas no banco com o componente de cache "EhCache", dessa forma, podemos
diminuir as consultas na base de dados que são repetidas, evitando um custo desnecessário de
ir ao banco de dados e também no trafego de rede.

Componente Descrição
Navegador Navegadores web representa o brownser a ser utilizado pelos os
usuários para interagir com as funcionalidades do sistema.

Servidor de Aplicação É o componente do modelo de implantação responsável por

gerenciar o processamento das requisições e nele que vamos
instalar nossos artefatos e componentes de negócio.
Servidor de Cache Responsável por armazenar consultas em memória e
sincronizar os dados com a base de dados do sistema. Esse
componente tem o objetivo de fazer com que as consulta que
sempre trazem valores iguais, sem mudanças, fiquem
armazenadas na memória, assim a aplicação não precisa ir até o
banco de dados efetuar uma busca. Com isso conseguimos
melhorar o desempenho e permitir que alguns dados retornem
de forma mais rápida para o usuário.
Servidor de Banco de Responsável por armazenar os dados da aplicação.
dados
Servidor Sigep Interface WebService responsável por prover os serviços de
CEP dos correios.
Servidor SUS Interface WebService do sistema do SUS, disponibilizada em
um servidor webcics mainframe.
 31

4.5. Modelo de dados

Colocar o diagrama de classes ou o modelo lógico de banco de dados
5. Prova de conceito / protótipo arquitetural

5.1. Implementação e implantação

A prova de conceito desse projeto visa atender as necessidades dos casos de uso do
módulo de agendamento de doação de sangue. O objetivo desse protótipo é verificar se o
processo de agendamento esta coerente com a arquitetura definida e está atendendo todas as
necessidades do usuário relacionado ao requisitos de qualidade, assim minimizar riscos e
maximizar ganhos de produtividade na sequência do projeto.

As tecnologias usadas na POC são as descritas no item de mecanismos arquiteturais.

A telas da aplicação podem ser vistas nas evidências da avaliação.

Nessa POC, pretende-se validar os seguintes requisitos não funcionais:

▪ Segurança - O sistema deve apresentar altos padrões de segurança.

Esse RNF foi escolhido devido a preocupação em manter dados seguros e evitar falhas
de segurança no projeto.

Os critérios de aceite são:

• Não permitir que usuários possam acessar paginas privadas sem estar autenticados
no sistema.
• Ao identificar que o usuário não está autenticado, o sistema deve redirecionar o
usuário para tela de autenticação.
• O sistema deve permitir que o usuário navegue em telas publicas sem precisar
estar autenticado.

▪ Usabilidade - O sistema deve prover boa usabilidade.

 32

Esse RNF foi escolhido devido a importância em manter um sistema com boa usabilidade, e
que possamos garantir uma navegação simples e objetiva.

Os critérios de aceite são:

• A tela do sistema deve apresentar facilidade de navegação

• O usuário não pode demorar mais que 5 minutos para efetuar um agendamento.
• O acesso as funcionalidade devem apresentar objetividade e não serem confusos.

▪ Acessibilidade - O sistema deve suportar ambientes Web responsivos e ambientes

móveis.

Esse RNF foi escolhido para garantir que atenda todas as exigências da arquitetura em ter um
sistema responsivo e que se adapte em celulares, tablets e desktops.

Os critérios de aceite são:

• A tela do sistema deve apresentar facilidade de navegação e os objetos da tela

devem se adaptar de acordo com a resolução identificada, tanto para celulares
como desktops.
• O sistema deve se manter com o mesmo padrão de cores e objetos.
• O sistema deve ser compatível com os principais browser do mercado como:
Internet Explorer, Chrome e Firefox.

▪ Desempenho - O sistema deve ser rápido.

Esse RNF foi escolhido com o objetivo de garantir uma boa performance na aplicação e poder
determinar se o desempenho desse requisito não funcional será atendido.

Os critérios de aceite são:

• A telas devem ser bem otimizadas para que não demorem mais que 8 segundos a
serem renderizadas ao usuário.
 33

• O sistema deve mostrar ao usuário um componente de LOADING ou

CARREGANDO na tela do usuário quando o mesmo efetuar alguma consulta no
sistema.

▪ Testabilidade - O sistema deve ser simples para testar.

Esse RNF foi escolhido com o objetivo de poder garantir que as funcionalidades do sistema
possa ser testada de forma rápida e eficiente, e que a arquitetura definida, possibilite testes
automatizados de forma simplificada, garantido a qualidade do sistema desde o inicio.

Os critérios de aceite são:

• As configurações do projeto, deve permitir que seja configurado e implementado

algum framework de teste unitário, como por exemplo jUnit.
• O sistema deve efetuar testes regressivos para garantir que não houve nenhuma
falha em alguma funcionalidade que já estava funcionando.
• Os testes devem ser automatizados e executados de forma simplificada com apenas
um comando.

5.2. Interfaces

Sessão 1: Interface do Web Service SIGEP WEB

A interface poderá ser consultada e configurada no ambiente de desenvolvimento no

seguinte endereço:

Desenvolvimento:
https://apphom.correios.com.br/SigepMasterJPA/AtendeClienteService/AtendeCliente
?wsdl
Para o acesso ao ambiente de desenvolvimento, poderão ser utilizados os seguintes
dados para autenticação e teste de implementação:

Usuário Senha Código Contrato Código Cartão

 34

Administrativo Serviço
sigep n5f9t8 08082650 9912208555 ... 0057018901

Obs.: Para desenvolvimento, os códigos de serviços podem ser obtidos através dos
método buscaCliente(), exemplificado logo mais abaixo.

Produção:
https://apps.correios.com.br/SigepMasterJPA/AtendeClienteService/AtendeCliente?ws
dl
Para produção deverão ser utilizados os parâmetros do contrato com os Correios.

Sessão 2: Métodos do Web Service do SIGEP WEB

Os métodos e elementos necessários para utilização do Web Service serão descritos e

exemplificados logo abaixo.

Método consultaCEP()

Este método retorna o endereço atualizado da base dos Correios

Assinatura do método:
consultaCep(cep)

Campo Tipo Descrição Obrigatório

Cep String(8) Número do cep sem hifen Sim

Exemplo:
 35

6. Avaliação da Arquitetura
6.1. Análise das abordagens arquiteturais
Apresente um breve resumo das principais características da proposta arquitetura.
6.2. Identificação dos atributos de qualidade
Os atributos identificados estão relacionados aos requisitos listados na seção anterior:
Usabilidade, desempenho, acessibilidade e segurança.

6.2. Cenários

Cenário 1: Ao realizar o acesso a uma URL ou página, o sistema deve apresentar altos
padrões de segurança necessário, garantindo que o usuário possa acessar as páginas privadas
apenas autenticado no sistema. O sistema deve redirecionar o usuário para a tela de
autenticação quando o mesmo tentar acessar uma página privada sem estar autenticado no
sistema. O sistema deverá garantir que as páginas públicas possam ser acessadas sem estar
autenticado. Garantindo assim a segurança e confidencialidade das informações estando em
de acordo com um dos requisitos não funcionais.
Cenário 2: Ao navegar na tela, o sistema deve apresentar boa usabilidade. A navegação
dever apresentar facilidade e o acesso as funcionalidades devem ser bem objetivos para a
função que precisa ser realizada, o usuário deve efetuar um agendamento em no máximo 5
 36

minutos, assim garantindo a agilidade e a usabilidade para fica de acordo com um dos
requisitos não funcionais.
Cenário 3: Ao realizar o acesso a aplicação através de um dispositivo móvel ou desktop
com resolução reduzida, utilizando os browser principais como IE, Chrome e Firefox, a tela
do usuário deverá se adaptar automaticamente, redimensionando seus links, botões, padrão de
cores e tabela de dados de acordo com a resolução, estando de acordo com acessibilidade
necessária para atender um dos requisitos não funcionais.
Cenário 4: Ao realizar um acesso em alguma tela privada ou pública, o sistema deve ter um
desempenho aceitável e responder em no máximo 8 segundos a renderização dos objetos na
tela, mostrando um componente na tela informando que o processo esta em andamento, e
quando o processo finalizar esse componente deve ser escondido, assim atendendo um dos
requisitos não funcionais.

Na priorização foi utilizado o método de Árvore de Utilidade reduzida e com

prioridades. Foi categorizado de acordo os atributos de qualidade a que estão relacionados e
então classificados em função de sua importância e complexidade, considerando a percepção
de negócio e arquitetura. As duas variáveis de priorização "Importância" e "Complexidade",
apresentadas nas colunas IMP. e COM. respectivamente forma classificadas em alta (A),
média (M) e baixa (B) de acordo com as características do requisito.

Atributos de
Cenários IMP. COM.
Qualidade
Segurança Cenário1: O sistema deve apresentar altos padrões A M
de segurança.
Funcionalidade

Usabilidade Cenário2: O sistema deve prover boa usabilidade. M B

Acessibilidade Cenário3: O sistema deve suportar ambientes M A

Web responsivos e ambientes móveis.
Desempenho Cenário4: O sistema deve ser rápido. A M
Eficiên
cia
 37

6.4. Avaliação

Processo de avaliação dos cenários identificados no item 6.1 são analisados. O

objetivo é determinar os riscos, não riscos, pontos de sensibilidade e tradeoffs e as evidências
mostrando o requisito de qualidade sendo atendido.

• Cenário 1.

Atributo de Qualidade: Segurança

Requisito de Qualidade: O sistema deve apresentar altos padrões de segurança
Preocupação:
Impossibilitar o acesso a páginas privadas do sistema sem autenticação no sistema.
Cenários(s):
Cenário1
Ambiente:
Sistema em operação normal
Estimulo:
Usuário tentando acessar uma página privada do sistema sem estar autenticado no sistema.
Mecanismo:
Criar um recurso de Filtro que possibilite o gerenciamento de todas as requisições HTTP do
servidor, filtrando o endereço que está sendo acessado.
Medida de Resposta:
O usuário deve ser redirecionada para tela de autenticação.
Considerações sobre a arquitetura:
Riscos: O gerenciamento de sessões e de autenticação apropriados
são críticos para segurança web. Falhas nessa área
frequentemente envolvem falha ao proteger credencias e
sessões durante o ciclo de vida.
Pontos de Sensibilidade: Servidor de aplicação operando em modo HTTPS
Tradeoff: Não existe
 38

• Evidências do Cenário1.

Usuário acessando a página pública do site de doação de sangue.

Doador efetuando autenticação no sistema para acesso as páginas privadas do sistema. O

sistema gerando uma sessão de segurança onde permite o usuário navegar entre as páginas
privadas do sistema, se o mesmo tentar acessar alguma página privada sem a sessão criada o
sistema redireciona para a página de login.

• Cenário 2.
 39

Atributo de Qualidade: Usabilidade

Requisito de Qualidade: O sistema deve prover boa usabilidade.
Preocupação:
Sistema deve apresentar desempenho satisfatório dentro dos limites aceitável.
Cenários(s):
Cenário2
Ambiente:
Sistema em operação normal
Estimulo:
Usuário navegando no site e efetuando um agendamento, devendo apresentar objetividade e
um agendamento rápido em no máximo 5 minutos.
Mecanismo:
Telas simples e objetivas sem muitos componentes a serem carregados possibilitando o
servidor de aplicação renderizar de forma rápida os objetos na tela do usuário. Os processos
em AJAX permitindo que seja carregado de forma rápida evitando carregar a página inteira
novamente e sim apenas o bloco onde se faz necessário alterar as informações. O sistema
trabalha com template padrão para todas as telas, assim alterando apenas o conteúdo principal.
Medida de Resposta:
O usuário não deve demorar mais que 5 minutos para efetuar um agendamento e os processos
que demoram alguns segundos para retornar informação, devem mostrar ao usuário um
componente que informe o usuário que o processo esta em andamento.
Considerações sobre a arquitetura:
Riscos: Pode ocorrer algum pico de memória no servidor ou um
numero de usuários muito grande ocasionando sobre carga
no servidor de aplicação, fazendo com que os
processamentos fiquem mais lentos.
Pontos de Sensibilidade: Balanceamento de carga ativo
Tradeoff: Não existe

• Evidências do Cenário2.
 40

Usuário se autenticando no sistema com o componente informando o processo em andamento.

Processo efetuado até o final concluído com o agendamento e os dados estatísticos de perfor-
mance mostrando a velocidade de carregamento das páginas até o processo final de agenda-
mento.
 41

• Cenário 3.

Atributo de Qualidade: Acessibilidade

Requisito de Qualidade: O sistema deve suportar ambiente web responsivos e
ambientes móveis.
Preocupação:
O sistema deve redimensionar seus objetos de acordo com o tamanho da tela.
Cenários(s):
Cenário3
Ambiente:
Sistema em operação normal
Estimulo:
Usuário se autenticando no sistema, excluindo um agendamento.
Mecanismo:
Criar a tela de autenticação e as demais telas internas privadas como Based Component para
facilitar a integração dos componentes de negocio com a interface do usuário.
Medida de Resposta:
O sistema deve se adaptar a resoluções de tela do dispositivo móvel, desktop ou tablet.
Considerações sobre a arquitetura:
Riscos: Cerca de 5% dos usuários acessam o sistema por meio de
redes móveis 2G ou conexão discada (56KBps), estes
usuários poderão enfrentam lentidão quando do acesso
através de dispositivos móveis ou equipamentos com
limitação de resolução.
Pontos de Sensibilidade: Não existe
Tradeoff: Não existe

• Evidências do Cenário3.
 42

Usuário se autenticando no sistema através de um celular móbile com resolução de tela 468 x
428, mostrando a responsividade e o site se adaptando em ambientes mobile.

• Cenário 4.

Atributo de Qualidade: Desempenho

Requisito de Qualidade: O sistema deve ser rápido
Preocupação:
Sistema deve apresentar desempenho satisfatório dentro dos limites aceitável.
Cenários(s):
Cenário4
 43

Ambiente:
Sistema em operação normal
Estimulo:
O sistema deve ser rápido e renderizar as páginas em no máximo 8 segundos.
Mecanismo:
Criado com telas objetivas, poucos componentes evitando uma interpretação maior do
servidor de aplicação para renderizar os dados para o cliente.
Medida de Resposta:
As páginas devem apresentar rapidez e bom desempenho.
Considerações sobre a arquitetura:
Riscos: Pode ocorrer algum pico de memória no servidor ou um
numero de usuários muito grande ocasionando sobre carga
no servidor de aplicação, fazendo com que os
processamentos fiquem mais lentos.
Pontos de Sensibilidade: Balanceamento de carga ativo
Tradeoff: Não existe

• Evidências do Cenário4

Usuário navegando em telas públicas e telas privadas autenticado no sistema. O sistema mos-
trou agilidade e renderização rápida para a tela do usuário.
44
 45

6.5. Resultados

Considerando os atributos de qualidade, o objetivo da validação arquitetural foi

analisar esses atributos. Verifiquei que a arquitetura proposta atende as necessidades do
projeto com possíveis melhorias. Avaliação permitiu que fosse possível concretizar de forma
mais objetiva os testes e cenários para definir pontos fortes e pontos fracos nessa avaliação.
Nessa avaliação considerei os seguintes requisitos de qualidades no quadro abaixo.

Requisitos Não Funcionais Testado Homologado.

RNF1: O sistema deve apresentar altos padrões de SIM SIM

segurança.

RNF2: O sistema deve prover boa usabilidade. SIM SIM

RNF3: O sistema deve suportar ambientes Web SIM SIM

responsivos e ambientes móveis.

RNF4: O sistema deve ser rápido. SIM SIM

Avaliando a arquitetura proposta para esse projeto, foi possível identificar alguns
pontos importantes e algumas limitações. A página pública principal do sistema esta
desenvolvida de forma responsiva e dentro dos padrões w3c, sendo compatível com os
principais browser do mercado e se adaptando responsivamente em aparelhos móbile. Outro
ponto importante, seria a separação das páginas publicas das páginas privadas, facilitando o
controle de segurança.
As páginas públicas podem se comunicar por REST com os componentes de negócio,
possibilitando futuramente separar as camadas, caso seja necessário deixar a parte estática em
um servidor apache e a parte de negocio em um servidor de aplicação, assim diminuindo a
 46

carga e melhorando o desempenho. Outra vantagem é a produtividade para criar o projeto,

podendo trabalharem duas equipes separadas, sendo uma equipe de design, onde irão criar as
páginas estáticas, e a equipe de back-end responsável pelos componentes de negocio. Outro
ponto importante analisado, esta com os objetos de negocio, cada um com seus objetivos
específicos e coesos, com suas responsabilidades, possibilitando outras aplicações externas
utilizarem esses componentes, facilitando o reuso e integrações.
Analisando a arquitetura final, ela apresentou alguns pontos de limitações com o
possível risco de segurança e desempenho. As páginas privadas de doadores serão as mesmas
para os usuários das clinicas e hospitais, o controle será por perfil, podendo haver algum
problema de perfil ou falha de cadastro possibilitando um doador acessar outros recursos de
agendamento, ficando esse ponto como melhoria futura, podendo separar esse módulo. No
geral a arquitetura apresenta na minha visão mais pontos forte do que limitações. Mostra-se
ser uma arquitetura com possibilidade de crescimento do projeto e de fácil manutenção,
possibilitando se integrar com outras aplicações.

7. Conclusão
Este trabalho apresentou um protótipo arquitetural para uma aplicação de controle integrado
de doação de sangue. Entende-se que os objetivos foram atingidos. Foram apresentadas algu-
mas limitações que não impactam a aceitação da proposta. Se houvesse mais tempo para o
desenvolvimento elas seriam tratadas. Pode-se fazer uma refatoração de alguns módulos sem
alterar os aspectos arquiteturais. Isso fica como sugestão para uma próxima versão.

REFERÊNCIAS

BARRUCHO, Guilherme Luis. O que falta para o Brasil doar mais sangue? Disponível
em: <http://www.bbc.com/portuguese/noticias/2015/08/150812_sangue_doacoes_brasil_lgb
> Acesso em 4 de Jun de 2016.

LARMAN, Graig. Utilizando UML e Padrões: Uma introdução a análise e ao projeto

orientados a objetos. 3º Edição. Porto Alegre: Bookman, 2011.

SOMMERVILLE, Ian. Engenharia de Software. 9º edição. São Paulo: Pearson, 2011.

47
 48

APÊNDICE B – Código Fonte

O código fonte da prova de conceito que foi desenvolvido para atender os requisitos não
funcionais dessa arquitetura de software.

URL do sistema implantado no Azure: http://poc-sca-xxx.axxxxzurewebsites.net

URL do GitHub: https://github.com/xxxx/poc-sistema-xxxxcontrole-sangue

URL da apresentação da POC no Youtube: https://youtxxxxxu.be/5pJoxxxxEagP7U