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