Sistema de Agendamento de Sade

Documento de Arquitetura de Software

Verso 1.4

Autores
Bruno Silva
Diego Ferreira
Mrcio Borges
Michael William
Viviane Ferraboli

Histrico de Revises
Data

Verso

Descrio

Autor

09/05/15

1.0

Escrita de escopo, definies, referncias, restries

Todos

10/05/15

1.1

Lista de casos de uso

Todos

11/05/15

1.2

Insero das imagens dos diagramas

Todos

12/05/15

1.3

Reviso Geral

Todos

26/05/15

1.4

Ajuste de inconsistncias

Todos

02/06/15

1.5

Adicionando tarefas do sprint 4

Todos

Sumrio
1.

Introduo
1.1
Finalidade
1.2
Escopo
1.3
Definies, Acrnimos e Abreviaes
1.4
Referncia

2.

Representao da Arquitetura

3.

Metas e Restries de Arquitetura

4.

Viso de Casos de Uso

5.

Viso Lgica
5.1
Diviso em Pacotes

6.

Viso de Processos (no necessria)

7.

Viso de Implantao

8.

Viso de Implementao
8.1
Camadas
8.1.1 Ex: Presentation Layer
8.1.2 Ex: Control Layer
8.1.3 Ex: Domain layer
8.2
Solues utilizadas
8.2.1 Hibernate
8.3
Convenes
8.3.1 Nomes de classes
8.3.2 Estrutura de diretrios

9.

Viso de Dados
9.1
Modelo de objetos persistentes
9.2
Estratgias
9.3
Modelo relacional

15
15
16
16
16
16

1.

Introduo

1.1 Finalidade
Este documento oferece uma viso geral arquitetural abrangente do sistema, usando diversas vises
arquiteturais para representar diferentes aspectos do sistema. O objetivo deste documento capturar
e comunicar as decises arquiteturais significativas que foram tomadas em relao ao sistema.
1.2 Escopo
Este documento contm as realizaes da Arquitetura de Software do Sistema de Agendamento de Sade.
1.3 Definies, Acrnimos e Abreviaes
Esta subseo deve apresentar as definies de todos os termos, acrnimos e abreviaes
necessrios para a correta interpretao do Documento de Arquitetura de Software. Essas
informaes podem ser fornecidas mediante referncia ao Glossrio do projeto.

Java Linguagem de programao orientada a objetos

SQL Server(Express) Structured Query Language
SOAP Simple Object Access Protocol
HTTP Hypertext Transfer Protocol
HTTPS - Hyper Text Transfer Protocol Secure
LINUX Kernel de cdigo fonte aberto
Apache TomCat Container web de cdigo fonte aberto baseado em java
LDAP - Lightweight Directory Access Protocol protocolo de aplicao aberto
XSS - Cross-site scripting tipo de vulnerabilidade do sistema de segurana de um computador
CSRF Cross-site request forgery - falsificao de solicitao entre sites

1.4 Referncia
Esta subseo deve apresentar uma lista completa de todos os documentos mencionados no
Documento de Arquitetura de Software. Cada documento deve ser identificado por ttulo, nmero de
relatrio (se aplicvel), data e organizao responsvel pela publicao. Especifique as fontes das
quais possvel obter referncias. Essas informaes podem ser fornecidas por um anexo ou outro
documento.
Ttulo
UC02 Gerenciar Agenda

Link
UC02 - Gerenciar Agenda.docx

Data
21/04/2015

UC03 Realizar
Atendimento

UC03 - Realizar Atendimento.docx

21/04/2015

UC04 Verificar cobertura

de plano

UC04 - Verificar cobertura de plano do paciente.docx

21/04/2015

UC06 Efetuar
Agendamento

UC06 - Efetuar agendamento.docx

21/04/2015

UC07 Solicitar
agendamento pela interface

UC07 - Solicitar agendamento pela interface web.docx

21/04/2015

2.

Representao da Arquitetura
Esta seo descreve qual a arquitetura de software do sistema atual e como ela representada. Nas
Vises de Casos de Uso, Lgica, do Processo, de Implantao e de Implementao, este documento
enumera as vises necessrias e, para cada uma delas, explica os tipos de elementos do modelo que
contm.
Este documento apresenta a arquitetura como uma srie de vises: viso de casos de uso, viso
lgica, viso de processos, viso de implantao e viso de implementao. Essas vises so
apresentadas como Modelos do Astah e utilizam a Linguagem Unificada de Modelagem (UML).

3.

Metas e Restries de Arquitetura

Esta seo descreve os requisitos de software e os objetivos que tm um impacto significativo na
arquitetura, como proteo, segurana, privacidade, uso de um produto desenvolvido internamente e
adquirido pronto para ser usado, portabilidade, distribuio e reutilizao.
Existem algumas restries de requisito e de sistema principais que tm uma relao significativa
com a arquitetura. So elas:

Sero utilizados apenas softwares livres para o desenvolvimento do sistema.

O sistema poder ser acessado atravs da intranet ou pela web.
Dever ser utilizado protocolo web seguro (https).
A1 Injeo

As falhas de Injeo, tais como injeo de SQL,

de SO (Sistema Operacional) e de LDAP,
ocorrem quando dados no confiavis so
enviados para um interpretador como parte de
um comando ou consulta. Os dados
manipulados pelo atacante podem iludir o
interpretador para que este execute comandos

indesejados ou permita o acesso a dados no

autorizados.

A2 Quebra de Autenticao e
Gerenciamento de Sesso

A3 Cross-Site Scripting (XSS)

As funes da aplicao relacionadas com

autenticao e gerenciamento de sesso
geralmente so implementadas de forma
incorreta, permitindo que os atacantes
comprometam senhas, chaves e tokens de
sesso ou, ainda, explorem outra falha da
implementao para assumir a identidade
de outros usurios.
Falhas XSS ocorrem sempre que uma
aplicao recebe dados no confiveis e os
envia ao navegador sem validao ou filtro
adequados. XSS permite aos atacantes
executarem scripts no navegador da vtima
que podem sequestrar sesses do
usurio, desfigurar sites, ou redirecionar o
usurio para sites maliciosos.

A4 Referncia Insegura e Direta a

Objetos

Uma referncia insegura e direta a um

objeto ocorre quando um programador
expe uma referncia implementao
interna de um objeto, como um arquivo,
diretrio, ou registro da base de dados.
Sem a verificao do controle de acesso ou
outra proteo, os atacantes podem
manipular estas referncias para acessar
dados no-autorizados.

A5 Configurao Incorreta de Segurana

Uma boa segurana exige a definio de

uma configurao segura e implementada
na aplicao, frameworks, servidor de
aplicao, servidor web, banco de dados e
plataforma. Todas essas configuraes
devem ser definidas, implementadas e
mantidas, j que geralmente a configurao
padro insegura. Adicionalmente, o
software deve ser mantido atualizado.

A6 Exposio de Dados Sensveis

Muitas aplicaes web no protegem

devidamente os dados sensveis, tais como
cartes de crdito, IDs fiscais e credenciais
de autenticao. Os atacantes podem
roubar ou modificar esses dados
desprotegidos com o propsito de realizar
fraudes de cartes de crdito, roubo de
identidade, ou outros crimes. Os dados
sensveis merecem proteo extra como
criptografia no armazenamento ou em
trnsito, bem como precaues especiais
quando trafegadas pelo navegador.

A7 Falta de Funo para Controle do

Nvel de Acesso

A maioria das aplicaes web verificam os

direitos de acesso em nvel de funo antes
de tornar essa funcionalidade visvel na
interface do usurio. No entanto, as
aplicaes precisam executar as mesmas
verificaes de controle de acesso no
servidor quando cada funo invocada.
Se estas requisies no forem verificadas,
os atacantes sero capazes de forjar as
requisies, com o propsito de acessar a
funcionalidade sem autorizao adequada.

A8 Cross-Site Request Forgery (CSRF)

Um ataque CSRF fora a vtima que possui

uma sesso ativa em um navegador a
enviar uma requisio HTTP forjada,
incluindo o cookie da sesso da vtima e
qualquer outra informao de autenticao
includa na sesso, a uma aplicao web
vulnervel. Esta falha permite ao atacante
forar o navegador da vtima a criar
requisies que a aplicao vulnervel
aceite como requisies legtimas
realizadas pela vtima.

A9 Utilizao de Componentes
Vulnerveis Conhecidos

Componentes, tais como bibliotecas,

frameworks, e outros mdulos de software
quase sempre so executados com
privilgios elevados. Se um componente
vulnervel explorado, um ataque pode
causar srias perdas de dados ou o
comprometimento do servidor. As
aplicaes que utilizam componentes com
vulnerabilidades conhecidas podem minar
as suas defesas e permitir uma gama de
possveis ataques e impactos.

A10 Redirecionamentos
encaminhamentos Invlidos

Aplicaes web frequentemente

redirecionam e encaminham usurios para
outras pginas e sites, e usam dados no
confiveis para determinar as pginas de
destino. Sem uma validao adequada, os
atacantes podem redirecionar as vtimas
para sites de phishing ou malware, ou usar
encaminhamentos para acessar pginas no
autorizadas.

A linguagem para o desenvolvimento do sistema ser o JAVA;

O Servidor de Aplicao definido para o sistema ser o Apache Tomcat;
O Sistema Operacional que dar suporte aos servios da aplicao ser o LINUX;
O Sistema Gerenciador de Banco de Dados definido para suportar a aplicao ser o SQL Server(Express);
Consultas devem ser desenvolvidas em SQL ANSI para permitir migrao de banco de dados no futuro ou
implantao em outros bancos.

4.

Cliente e servidor trocaro mensagens via protocolo SOAP.

As atualizaes de sistema poder ocorrer a cada 15 dias, previamente acertados, a partir das 23h00.
A janela de atualizao deve ser de at duas horas.
O cliente dever ter link redundante para garantir comunicao nas autorizaes.

Viso de Casos de Uso

Esta seo lista os casos de uso ou cenrios do modelo de casos de uso que representam uma
funcionalidade central e significativa do sistema final ou se tm uma ampla cobertura de arquitetura,
ou seja, que experimenta vrios elementos de arquitetura e enfatizam ou ilustram um determinado
ponto complexo da arquitetura.
Os Casos de Uso do sistema de Agendamento de Sade so listados a seguir. Os Casos de Uso em
negrito so destacados por que so muito importante para a arquitetura:

5.

Caso de uso 2 Gerenciar Agenda

Caso de uso 3 Realizar Atendimento

Caso de uso 4 Verificar cobertura do plano do paciente

Caso de uso 6 Efetuar Agendamento

Caso de uso 7 Solicitar Agendamento pela Interface Web

Viso Lgica
Esta seo descreve as partes significativas do ponto de vista da arquitetura do modelo de design,
como sua diviso em subsistemas e pacotes. Alm disso, para cada pacote significativo, ela mostra
sua diviso em classes e utilitrios de classe. Apresenta as classes significativas do ponto de vista da
arquitetura e descreve suas responsabilidades, bem como alguns relacionamentos, operaes e
atributos de grande importncia.

5.1 Diviso em Pacotes

Nesta seo sero apresentadas as camadas da arquitetura proposta. Sero descritas as
responsabilidades de cada camada quais tecnologias devem ser aplicadas a cada uma delas.

5.1.1

Pacote br.com.sas.Autenticao

Classe Login
Descrio

Classe para autentificar o usurio

Relaes

Depende da classe de aceso ao banco.

Responsabilidades

Autentica classes de usurios para determinadas funes.

Mtodos

acessaSistema(): acessa sistema de determinado perfil.

Atributos

login: username de cada usurio.

senha: passcode do usurio.

5.1.2

Pacote br.com.sas.RealizarAtendimento

Classe Atendimento
Descrio

Classe para administrar dados do atendimento

Relaes

Depende da classe de login, internacao, consulta, exame.

Responsabilidades

Realizar o agendamento da consulta mdica

Mtodos

pesquisarPaciente(): busca e seleo do paciente a ser agendado

pesquiaEspecialidade(): busca e seleo da especialidade mdica
pesquisaMedico(): busca e seleo do mdico
pesquisaAgenda(): busca e seleo do horrio para o atendimento

Atributos
5.1.3

Pacote br.com.sas.InterfacecomWeb

Classe InterfaceWeb
Descrio

Classe para acesso via web

Relaes

Depende da classe Agendamento

Responsabilidades

Solicitao e agendamento de consulta pela interface web

Mtodos

autentificarIDDaCarteira(): autentifica o n nico da carteira do plano

do paciente
pesquiaEspecialidade(): busca e seleo da especialidade mdica
pesquisaMedico(): busca e seleo do medico
pesquisaAgenda(): busca e seleo do horrio para o atendimento
efetuarAgendamento(): confirma o agendamento para a especialidade
selecionada.

Atributos
5.1.4

Pacote br.com.sas.PacoteAgendamento

Classe Agendamento
Descrio

Classe dedicada a agenda consultas, exames e internao

Relaes

Depende das classes Consulta, Exame e Internao

Responsabilidades

Efetuar agendamento para pacientes.

Mtodos

verificaDados(): chama classes para verificao de permisso de plano

de sade

Atributos

idAgendamento: cdigo nico para cada agendamento.

statusDeAgendamento: salva o status de agendamento para controle de
permisses.

Classe Internacao
Descrio

Classe destinada obter e salvar dados da internao.

Relaes

Filha da classe Atendimento

Responsabilidades

Concatenar e salvar os dados de internao

Mtodos

enviaDadosAoBanco(): envia dados a classe que mantm o banco de

dados.

Atributos

idInternacao: cdigo nico para cada internao

responsavel: dados do responsvel pelo paciente
numDoQuarto: guarda o nmero do quarto
statusDaInternacao: monitora o status da internao

Classe Consulta
Descrio

Classe destinada obter e salvar dados da consulta.

Relaes

Filha da classe Atendimento

Responsabilidades

Concatenar e salvar os dados de consulta

Mtodos

enviaDadosAoBanco(): envia dados a classe que mantm o banco de

dados.

Atributos

idConsulta: Cdigo nico para cada consulta

convenio: Qual convnio ser utilizado
categoriaDaConsulta: Qual a natureza da consulta
medico: Nome do mdico
local: Endereo da consulta
horrio: Horrio da consulta

Classe Exame
Descrio

Classe destinada obter e salvar dados de exames.

Relaes

Concatenar e salvar os dados do exame.

Responsabilidades

Realizar o agendamento da consulta mdica

Mtodos

enviaDadosAoBanco(): envia dados a classe que mantm o banco de

dados.

Atributos

idExame: cdigo nico para cada exame

preRequisitos: o que necessita efetuar para que exame possa ocorrer
statusDePermissao: verificar se tem autorizazao para gerar exame
medicoRequerimento: Mdico que requeriu o exame
local: Endereo do exame
horrio: Horrio do Exame

5.1.5

Pacote br.com.sas.VerificaodePlanos

Classe VerificaPlano
Descrio

Classe que analisa o plano do ID do paciente selecionado

Relaes

No h relaes ccom outra classe

Responsabilidades

Verifica permisses do tipo de plano

Mtodos

verificaDados(): chama classes para verificao de permisso de plano

de sade

Atributos

tipoDePlano: guarda informao sobre o tipo de plano do ID

5.1.6

Pacote br.com.sas.PacoteEditarAgenda

Classe EditaAgenda
Descrio

Classe que gerencia a agenda do hospital

Relaes

Depende das classes de Paciente, Agenda, Sala, Usuario e Mdico

Responsabilidades

Atualizar a agenda

Mtodos

atualizaPaciente(): Cadastra/ Atualiza/Deleta paciente

atualizaAgenda(): Cadastra/ Atualiza/Deleta agenda
atualizaSala(): Cadastra/ Atualiza/Deleta sala
atualizaUsuario(): Cadastra/ Atualiza/Deleta usuario
atualizaMedico(): Cadastra/ Atualiza/Deleta medico

Atributos
Classe Agenda
Descrio

Classe que gerencia a agenda do hospital

Relaes

Depende das classes de Paciente, Agenda, Sala, Usuario e Mdico

Responsabilidades

Atualizar a agenda

Mtodos

atualizaPaciente(): Cadastra/ Atualiza/Deleta paciente

atualizaAgenda(): Cadastra/ Atualiza/Deleta agenda
atualizaSala(): Cadastra/ Atualiza/Deleta sala
atualizaUsuario(): Cadastra/ Atualiza/Deleta usuario
atualizaMedico(): Cadastra/ Atualiza/Deleta medico

Atributos

idAgenda: identificador nico para cada agenda

pacienteA: paciente desta agenda
medicoA: medico desta agenda
salaA: sala desta agenda
localA: local do atendimento
setorA: setor de localizao (se houver)
horarioA: horrio do atendimento

Classe Paciente
Descrio

Classe destinada obter e salvar dados de pacientes

Relaes

Filha da classe EditaAgenda e Agenda

Responsabilidades

Concatenar e salvar os dados de pacientes

Mtodos

enviaDadosAoBanco(): envia dados a classe que mantm o banco de

dados.

Atributos

idPaciente: cdigo nico para cada paciente

nome: Nome do paciente
idade:Idade do paciente
cPF: cadastro de pessoa fsica
rG: registro de pessoa fisica
endereo: endereo do paciente
telRes: telefone residencial
telCel: telefone celular
telContato: telefone auxiliar para contato
email: email do paciente

Classe Medico
Descrio

Classe destinada obter e salvar dados de mdicos

Relaes

Filha da classe EditaAgenda e Agenda

Responsabilidades

Concatenar e salvar os dados de mdicos

Mtodos

enviaDadosAoBanco(): envia dados a classe que mantm o banco de

dados.

Atributos

idMedico: id nico para cada mdico

nome: nome do mdico
idade: idade do mdico
cRM: cadastro de cada mdico
telCel: telefone celular
telCom: telefone comercial

Classe Sala
Descrio

Classe destinada obter e salvar dados de salas

Relaes

Filha da classe EditaAgenda e Agenda

Responsabilidades

Concatenar e salvar os dados de mdicos

Mtodos

enviaDadosAoBanco(): envia dados a classe que mantm o banco de

dados.

Atributos

idSala: id nico para cada mdico

setor: nome do mdico
num: nmero da sala

6.

Viso de Processos (no necessria)

[Esta seo descreve a decomposio do sistema em processos leves (threads simples de controle) e
processos pesados (agrupamentos de processos leves).]

7.

Viso de Implantao
[Esta seo descreve uma ou mais configuraes da rede fsica (hardware) na qual o software
implantado e executado. Para cada configurao, ela deve indicar no mnimo os ns fsicos
(computadores, CPUs) que executam o software e as respectivas interconexes (barramento, LAN,
ponto a ponto e assim por diante.).]

8.

Viso de Implementao

8.1 Camadas
Esta subseo nomeia e define as diversas camadas e o seu contedo, as regras que determinam a
incluso em uma camada especfica e as fronteiras entre as camadas.
8.1.1 Ex: Presentation Layer
The Presentation layer contains all the components needed to allow interactions with an end-user. It
encompasses the user interface.
[Exibe o contedo de um modelo ao usurio. Nesta camada so utilizados Java Server Pages
(JSPs) , TagLib(TagStruts) para a gerao do cdigo HTML. ]
8.1.2 Ex: Control Layer
The Control layer contains all the components used to access the domain layer or directly the
resource layer when this is appropriate.
[Transfere as interaes entre a camada de apresentao e o que deve ser executado pela camada de
modelo. Nesta camada usamos o framework Struts / XML. ]

8.1.3 Ex: Domain layer

The Domain layer contains all the components related to the business logic. It gathers all the
subsystems that meet the needs of a particular business domain. It also contains the business object
model.
[Representa os dados corporativos e as regras de negcio que governam o acesso e a atualizao
desses dados. Utilizaremos nessa camada os padres: Data Access Object (DAO) que na nossa
arquitetura utilizamos a ferramenta Hibernate na veso 3.1.3 Para acesso a dados, Transfer Object
(TO), Busisness Object (BO), Actions e DispacthActions. ]
8.2 Solues utilizadas
8.2.1 Hibernate
Hibernate um framework para o mapeamento objeto-relacional criado na linguagem Java e
dstribudo com a licena LGPL. A princiapal caracterstica deixar os objetos criados durante a
execuo do sistema sejam persistidos em um banco de dados. Com a utilizao do Hibernate
contaremos com a abstrao do acesso e persistncia dos dados no banco de dados, logo no
necessitamos conhecer individualmente cada um dos bancos de dados suportados, pois ser o
Hibernate que far este acesso.
8.3 Convenes

8.3.1

Nomes de classes

Todos os nomes criados para as classes devem ser substantivos. No permitido usar abreviaes,
siglas ou substantivos pejorativos;

Iniciar com letra maiscula;

No podem conter caracteres especiais, acentuados;

Quando houver uma classe com nome composto, a primeira letra de cada palavra deve ser
maiscula;

O nome da classe deve ser igual ao nome do seu arquivo fonte;

Deve fazer referncia ao seu objeto.

8.3.2 Estrutura de diretrios

Os pacotes devero ser nomeados utilizando o prefixo br.com.sas seguido do nome do pacote.
No arquivo da classe, deve ser indicado primeiramente o pacote onde se encontra a classe e em
seguida as importaes de classes.

9.

Viso de Dados
Sero apresentadas a seguir a estratgia e os modelos que trazem uma perspectiva do
armazenamento de dados persistentes do sistema.
9.1 Modelo de objetos persistentes

9.2 Estratgias
Para as classes que necessitam relacionamento foi utilizado tipos clssicos de relacionamento
muitos para muitos e muitos para um.
As classes Internacao, Exame e Consulta se relacionam com a classe Agendamento, pois essa
contm todos os dados necessrios de qualquer destas trs classes citadas.
O mesmo tipo de relao encontrado entre Paciente, Mdico e Sala, que se relacionam com a
classe Agenda, uma pequena diferena que apenas um paciente pode se relacionar com uma
Agenda e tambm deve haver no mnimo um mdico para uma agenda.
A tabela login ser nica e sem relaes, pois s h a necessidade de manter estes dados no banco.
O mtodo de construo das classes e depois a converso para tabela foi feita na plataforma Astah
Professional.

9.3 Modelo relacional