Documento de Arquitetura de Software
Sistema de Agendamento de SadeDocumento de Arquitetura de Software
Verso 1.4AutoresBruno Silva
Diego Ferreira
Mrcio Borges
Michael William
Viviane Ferraboli
Histrico de Revises
DataVersoDescrioAutor
09/05/151.0Escrita de escopo, definies, referncias, restriesTodos
10/05/151.1Lista de casos de usoTodos
11/05/151.2Insero das imagens dos diagramasTodos
12/05/151.3Reviso GeralTodos
26/05/151.4Ajuste de inconsistnciasTodos
02/06/151.5Adicionando tarefas do sprint 4Todos
Sumrio
41.Introduo
41.1Finalidade
41.2Escopo
41.3Definies, Acrnimos e Abreviaes
41.4Referncia
52.Representao da Arquitetura
53.Metas e Restries de Arquitetura
84.Viso de Casos de Uso
85.Viso Lgica
95.1Diviso em Pacotes
146.Viso de Processos (no necessria)
147.Viso de Implantao
158.Viso de Implementao
158.1Camadas
158.1.1 Ex: Presentation Layer
158.1.2 Ex: Control Layer
168.1.3 Ex: Domain layer
168.2Solues utilizadas
168.2.1Hibernate
168.3Convenes
168.3.1Nomes de classes
168.3.2Estrutura de diretrios
179.Viso de Dados
179.1Modelo de objetos persistentes
189.2Estratgias
199.3Modelo relacional
1. Introduo
1.1 FinalidadeEste 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 sites1.4 RefernciaEsta 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.TtuloLinkData
UC02 Gerenciar AgendaUC02 - Gerenciar Agenda.docx21/04/2015
UC03 Realizar AtendimentoUC03 - Realizar Atendimento.docx21/04/2015
UC04 Verificar cobertura de planoUC04 - Verificar cobertura de plano do paciente.docx21/04/2015
UC06 Efetuar AgendamentoUC06 - Efetuar agendamento.docx21/04/2015
UC07 Solicitar agendamento pela interfaceUC07 - Solicitar agendamento pela interface web.docx21/04/2015
2. Representao da ArquiteturaEsta 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 InjeoAs 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 SessoAs 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.
A3 Cross-Site Scripting (XSS)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 ObjetosUma 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 SeguranaUma 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 SensveisMuitas 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 AcessoA 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 ConhecidosComponentes, 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 InvlidosAplicaes 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.
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.4. 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:
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 Web5. 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 PacotesNesta 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.AutenticaoClasse Login
DescrioClasse para autentificar o usurio
RelaesDepende da classe de aceso ao banco.
ResponsabilidadesAutentica classes de usurios para determinadas funes.
MtodosacessaSistema(): acessa sistema de determinado perfil.
Atributoslogin: 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
RelaesDepende da classe de login, internacao, consulta, exame.
ResponsabilidadesRealizar o agendamento da consulta mdica
MtodospesquisarPaciente(): busca e seleo do paciente a ser agendadopesquiaEspecialidade(): busca e seleo da especialidade mdicapesquisaMedico(): 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
RelaesDepende da classe Agendamento
ResponsabilidadesSolicitao e agendamento de consulta pela interface web
MtodosautentificarIDDaCarteira(): autentifica o n nico da carteira do plano do paciente
pesquiaEspecialidade(): busca e seleo da especialidade mdicapesquisaMedico(): 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
RelaesDepende das classes Consulta, Exame e Internao
ResponsabilidadesEfetuar agendamento para pacientes.
MtodosverificaDados(): chama classes para verificao de permisso de plano de sade
AtributosidAgendamento: cdigo nico para cada agendamento.
statusDeAgendamento: salva o status de agendamento para controle de permisses.
Classe Internacao
DescrioClasse destinada obter e salvar dados da internao.
RelaesFilha da classe Atendimento
ResponsabilidadesConcatenar e salvar os dados de internao
MtodosenviaDadosAoBanco(): envia dados a classe que mantm o banco de dados.
AtributosidInternacao: cdigo nico para cada internao
responsavel: dados do responsvel pelo pacientenumDoQuarto: guarda o nmero do quarto
statusDaInternacao: monitora o status da internao
Classe Consulta
DescrioClasse destinada obter e salvar dados da consulta.
RelaesFilha da classe Atendimento
ResponsabilidadesConcatenar e salvar os dados de consulta
MtodosenviaDadosAoBanco(): envia dados a classe que mantm o banco de dados.
AtributosidConsulta: Cdigo nico para cada consulta
convenio: Qual convnio ser utilizado
categoriaDaConsulta: Qual a natureza da consulta
medico: Nome do mdico
local: Endereo da consultahorrio: Horrio da consulta
Classe Exame
DescrioClasse destinada obter e salvar dados de exames.
RelaesConcatenar e salvar os dados do exame.
ResponsabilidadesRealizar o agendamento da consulta mdica
MtodosenviaDadosAoBanco(): envia dados a classe que mantm o banco de dados.
AtributosidExame: 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
DescrioClasse que analisa o plano do ID do paciente selecionado
RelaesNo h relaes ccom outra classe
ResponsabilidadesVerifica permisses do tipo de plano
MtodosverificaDados(): chama classes para verificao de permisso de plano de sade
AtributostipoDePlano: guarda informao sobre o tipo de plano do ID
5.1.6 Pacote br.com.sas.PacoteEditarAgendaClasse EditaAgenda
DescrioClasse que gerencia a agenda do hospital
RelaesDepende das classes de Paciente, Agenda, Sala, Usuario e Mdico
ResponsabilidadesAtualizar a agenda
MtodosatualizaPaciente(): Cadastra/ Atualiza/Deleta pacienteatualizaAgenda(): Cadastra/ Atualiza/Deleta agenda
atualizaSala(): Cadastra/ Atualiza/Deleta sala
atualizaUsuario(): Cadastra/ Atualiza/Deleta usuario
atualizaMedico(): Cadastra/ Atualiza/Deleta medico
Atributos
Classe Agenda
DescrioClasse que gerencia a agenda do hospital
RelaesDepende das classes de Paciente, Agenda, Sala, Usuario e Mdico
ResponsabilidadesAtualizar a agenda
MtodosatualizaPaciente(): Cadastra/ Atualiza/Deleta paciente
atualizaAgenda(): Cadastra/ Atualiza/Deleta agenda
atualizaSala(): Cadastra/ Atualiza/Deleta sala
atualizaUsuario(): Cadastra/ Atualiza/Deleta usuario
atualizaMedico(): Cadastra/ Atualiza/Deleta medico
AtributosidAgenda: identificador nico para cada agendapacienteA: paciente desta agendamedicoA: medico desta agendasalaA: sala desta agendalocalA: local do atendimento
setorA: setor de localizao (se houver)horarioA: horrio do atendimento
Classe Paciente
DescrioClasse destinada obter e salvar dados de pacientes
RelaesFilha da classe EditaAgenda e Agenda
ResponsabilidadesConcatenar e salvar os dados de pacientes
MtodosenviaDadosAoBanco(): envia dados a classe que mantm o banco de dados.
AtributosidPaciente: cdigo nico para cada paciente
nome: Nome do pacienteidade:Idade do pacientecPF: cadastro de pessoa fsicarG: registro de pessoa fisicaendereo: endereo do pacientetelRes: telefone residencial
telCel: telefone celular
telContato: telefone auxiliar para contato
email: email do paciente
Classe Medico
DescrioClasse destinada obter e salvar dados de mdicos
RelaesFilha da classe EditaAgenda e Agenda
ResponsabilidadesConcatenar e salvar os dados de mdicos
MtodosenviaDadosAoBanco(): envia dados a classe que mantm o banco de dados.
AtributosidMedico: id nico para cada mdiconome: nome do mdico
idade: idade do mdico
cRM: cadastro de cada mdico
telCel: telefone celular
telCom: telefone comercial
Classe Sala
DescrioClasse destinada obter e salvar dados de salas
RelaesFilha da classe EditaAgenda e Agenda
ResponsabilidadesConcatenar e salvar os dados de mdicos
MtodosenviaDadosAoBanco(): envia dados a classe que mantm o banco de dados.
AtributosidSala: 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 CamadasEsta 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 HibernateHibernate 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 diretriosOs 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 DadosSero 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 EstratgiasPara 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