Documento de Arquitetura
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 24/08 | 1.0 | Estrutura básica do documento, inicio da Introdução e do Tamanho e Desempenho | Hiroshi |
| 28/08 | 1.1 | Adição do Definições, Referências e Começar Representação de Arquitetura | Guilherme |
| 28/08 | 1.2 | Finalização do Tópico Representação de Arquitetura | Guilherme |
| 29/08 | 1.3 | Adição do Tópico Visão de Casos de Uso | Natália Rodrigues |
| 29/08 | 1.4 | Adição dos Tópicos Tamanho e Desempenho e Qualidade | Lucas kishima |
| 29/08 | 1.5 | Iniciando tópico Visão de Implementação | Felipe Borges |
| 30/08 | 1.6 | Adição do Tópico Restrições e Metas de Arquitetura | Mateus Nóbrega |
| 30/08 | 1.7 | Conclusão do tópico Visão de Implementa | Felipe Borges |
| 30/08 | 1.8 | estruturação do tópico Introdução Visão Geral de acordo com os tópicos do documento e seus conteúdos | Felipe Borges |
| 31/08 | 1.9 | Ajustes no Tópico Visão de Casos de Uso | Natália Rodrigues |
| 31/08 | 1.10 | Adição do Tópico Visão Lógica | Michel Camargo |
| 31/08 | 1.11 | Ajustes no Tópico Restrições e Metas de Arquitetura | Mateus Nóbrega |
| 31/08 | 1.12 | Ajustes no Tópico Introdução Escopo, Restrições e Metas e Referências | Hiroshi |
| 31/08 | 2.0 | Revisão | Hiroshi, Felipe Borges, Guilherme |
| 31/08 | 2.1 | Revisão dos Tópicos Tamanho e desempenho e Qualidade | Lucas Kishima |
| 31/08 | 2.2 | Revisão do Tópico Visão Lógica | Michel Camargo |
| 02/09 | 2.3 | Revisão do Diagrama de pacotes e do Diagrama de classes | Felipe e Mateus |
| 27/09 | 2.4 | Formatação do Documento | Felipe, Guilherme e Mateus |
| 07/12 | 3.5 | Atualização dos diagramas de pacotes e diagrama de classes | Felipe Borges |
-
Introdução
- 1.1 Finalidade
- 1.2 Escopo
- 1.3 Visão Geral
- 1.4 Definições, Acrônimos e Abreviações
- 1.5 Referências
- Representação de Arquitetura
-
Restrições e Metas de Arquitetura
- 3.1 Metas
- 3.2 Restrições
- Visão de Caso de Uso
- Visão Lógica
- Desempenho
- Qualidade
1. Introdução
1.1 Finalidade
Este documento tem como objetivo apresentar a arquitetura escolhida para a aplicação do Receituário Médico. Para isso utilizamos diferentes características do projeto como casos de usos, restrições e requisitos, qualidade, desempenho dentre outros para justificar as decisões arquiteturais tomadas pela equipe de desenvolvimento na definição do escopo.
1.2 Escopo
Serão descritos neste documento, os componentes de software, padrões, plataformas de desenvolvimento e frameworks utilizados para o desenvolvimento do sistema que tem como foco auxiliar os profissionais da saúde durante a prescrição de medicamentos, exames e orientações. O documento explora a arquitetura para o sistema explicitando suas características como metas e restrições arquiteturais desenvolvido por alunos da disciplina de Métodos de Desenvolvimento de Software da Universidade de Brasília.
1.3 Visão Geral
Este documento é dividido nas seguintes secções:
-
Introdução: Apresentação da finalidade e organização do documento.
-
Representação de Arquitetura: Demonstra a arquitetura que usaremos no sistema.
-
Restrições e Metas de Arquitetura: Mostra os requisitos de usabilidade do software o os objetivos que impactam significativamente a aplicação.
-
Visão de Casos de Uso: Mostra todos casos de uso da aplicação.
-
Visão de Implementação: Apresenta como será implementado a arquitetura no sistema.
-
Visão Lógica: Apresenta partes importantes do projeto do ponto de vista da arquitetura e da modelagem do design.
-
Tamanho e Desempenho: Descreve as características da aplicação que impactam no desempenho.
-
Qualidade: Descreve como a escolha da arquitetura do software contribui para os recursos da aplicação.
- MTV - Model-Template-View.
- MVC - Model-View-Controller.
- Profissionais de saúde - A quem compete prescrever medicamentos, exames ou recomendações.
1.5 Referências
Fundação Universidade Federal do Paraná - Documento de Arquitetura: A estrutura de tópicos do documento de Arquitetura. Disponível em: http://www.funpar.ufpr.br:8080/rup/webtmpl/templates/a_and_d/rup_sad.htm. Acesso em: 22 ago. 2017;
FREIRE, Thiago; OLIVEIRA, Rodrigo; MORENO, Augusto; NASCIMENTO, Josué; AUGUSTO, Marcelo. Projeto WikiLegis: Documento de Visão. Disponível em: https://github.com/fga-gpp-mds/2016.2-WikiLegis/wiki. Acesso em 22 ago. 2017;
BATISTA, Matheus; ARAÚJO, Igor; WILLER, Guilherme; OLIVEIRA, Vinícius; BARCELOS, Filipe; SOUSA, André. Projeto Escola X: Documento de Visão. Disponível em: https://github.com/fga-gpp-mds/2017.1-PlataformaJogosUnB/wiki/Documento-de-Arquitetura. Acesso em 22 ago. 2017;
O MVC é um padrão de arquitetura que separa a implementação das funcionalidades em camadas chamadas Model, View, Controller.
-
Model : Responsável pela gerência dos dados, lógica de aplicação e regras de negócio referente ao banco de dados do sistema.
-
View : Responsável pela interação com o usuário, define elementos de interface como botões, imagens, tabelas entre outros.
-
Controller : Responsável por receber requisições do usuário e comandar ações dentro do sistema. A controller é responsável por integrar a view e a model. Nesta camada existem os comando de manipulações de informações (enviando e recebendo requisições da model e renderizando para a view) além das regras de negócios referentes a manipulações do sistema.
A arquitetura do Django, de acordo com o DjangoBook, segue o padrão MVC da sua própria maneira como MTV. Na arquitetura MTV as os pacotes funcionam da seguinte maneira:
-
Model: É na model onde se define o banco de dados, seu comportamento, suas classes, métodos e leitura e escrita bem como suas validações. Nesta camada também é definida algumas regras de negócio referentes a manipulações do banco de dados, ou seja, a model é a camada que concentra tudo referente ao banco de dados e seu comportamento na aplicação.
-
Template: Esta camada é a interface do usuário, nela contém apenas como será apresentado as informações enviadas pela view além de comunicar para a mesma as interações do usuário com a aplicação.
-
View: A view é uma ponte entre a model e o template. Nesta camada é implementado a lógica de comunicação da aplicação com a model além de direcionar as informações que serão apresentadas para o template correto.
Figura 1- Diagrama do um MTV, retirado no site em 03/09/2017.
3.1 Metas
O sistema deve garantir a privacidade dos dados inseridos em seu banco de dados, ele deve ser eficiente e conseguir responder às requisições em poucos segundos. Ela também deverá atender aos requisitos não funcionais, como o estruturamento de código, para que assim seja garantida a manutenibilidade do sistema.
3.2 Restrições
O sistema vai ser suportado nos navegadores Google Chrome 60, Safari, Mozilla Firefox 55, Opera 47 e Microsoft Edge. O desenvolvimento do mesmo será feito na linguagem de programação Python, versão 3.6, com a framework de desenvolvimento web Django, versão 1.11.4, com modelo MTV (adaptação da implementação do modelo MVC no framework Django). A conexão com a internet deverá ser obrigatória e a aplicação também deverá ser responsiva.
4.1 Atores
| Profissionais da Saúde | Os profissionais da saúde estarão aptos a se cadastrarem no sistema e convidarem pacientes para a utilização do mesmo. Eles farão a geração de receitas, terão a possibilidade de criar padrões personalizados para facilitar essa geração e, ainda, terão a viabilidade de consulta a outros receituários, assim como a marcação desses como favoritos. Os profissionais terão acesso a uma plataforma de comunicação com os pacientes. |
|---|---|
| Pacientes | Os pacientes poderão se cadastrar no sistema, em conformidade com o convite recebido do profissional competente. Terão a possibilidade de comunicação com os profissionais da saúde, poderão enviar exames aos mesmos e consultar o histórico de receitas, assim como fazer a visualização das mesmas e dos seus respectivos exames. |
Figura 2 - Diagrama de caso de uso do sistema Receituário Médico
| Caso de Uso | Descrição |
|---|---|
| UC01 - Manter Profissional de Saúde | Este caso de uso permite ao profissional da saúde a criação, edição ou exclusão do seu cadastro. |
| UC02 - Manter Paciente | Este caso de uso permite aos pacientes a criação e edição do seu cadastro. |
| UC03 - Realizar Login | Este caso de uso permite a profissionais da saúde e pacientes a realização de login e logout, ou seja, permite a entrada e saída do sistema. |
| UC04 - Pesquisar Receituário | Este caso de uso permite que o usuário profissional da da saúde faça pesquisas pelos receituários existentes na base de dados do sistema. |
| UC05 - Favoritar Receituário | Este caso de uso permite que o profissional da saúde marque como favoritos receituários pesquisados. |
| UC06 - Convidar | Este caso de uso permite que profissionais da saúde convidem pacientes a se cadastrarem no sistema. |
| UC07 - Conversar | Este caso de uso oferece uma plataforma de comunicação entre profissionais da saúde e pacientes. |
| UC08 - Enviar Exames | Este caso de permite que os pacientes enviem seus exames aos profissionais da saúde por meio do receituário. |
| UC09 - Consultar Histórico | Este caso de uso permite aos pacientes a realização de consultas ao seu histórico de receituários. |
| UC10 - Visualizar Exames | Este caso de uso possibilita aos pacientes a visualização dos seus exames. |
| UC11 - Visualizar Receitas | Este caso de uso possibilita aos pacientes a visualização das suas receitas. |
| UC12 - Manter Recomendação | Este caso de uso permite ao profissional da saúde a criação, edição, listagem ou exclusão de uma recomendação. |
| UC13 - Manter Medicamento | Este caso de uso permite ao profissional da saúde a criação, edição, listagem ou exclusão de um medicamento. |
| UC14 - Manter Exame | Este caso de uso permite ao profissional da saúde a criação, edição, listagem ou exclusão de uma exame. |
5. Visão Lógica
5.1 Visão Geral
As principais classes do ponto de vista da arquitetura do software e as implementações das funcionalidades são divididas pacotes que representam as camadas do modelo MTV. A divisão em pacotes está representada no diagrama abaixo.
Visão geral da aplicação do ponto de vista de pacotes e aplicativos dentro da arquitetura do sistema.
Figura 3 - Diagrama de pacotes do sistema Receituário Médico
| Pacote | Nome | Descrição |
| recipe | Prescription | Classe que representa os dados gerais da receita médica. |
| Medication | Classe que representa os dados de medicamentos na aplicação. | |
| Exam | Classe que representa os dados de exames na aplicação. | |
| Recommendation | Classe que representa os dados de recomendações médicas na aplicação. | |
| user | User | Classe abstrata que representa os dados gerais de usuários da aplicação comuns a médico e paciente. |
| Doctor | Classe filha de User que representa os dados de médico na aplicação. | |
| Patient | Classe filha de User que representa os dados de paciente na aplicação. | |
| messenger | Message | Classe responsável pela comunicação entre profissionais da saúde e pacientes. |
| File | Contém as informações do arquivo no banco de dados da aplicação. |
| Pacote | Nome | Descrição |
| recipe | PrescriptionView | Classe responsável por realizar as ações da prescrição, contém os métodos e interage com o banco de dados. |
| user | UserView | Classe abstrata que contém as funcionalidades básicas de um usuário e seus atributos. |
| PatientView | Contém as funcionalidades do paciente. |
Descrição das principais camadas do sistema e suas classes:
Figura 4 - Diagrama de classes do sistema Receituário médico
6. Desempenho
O desempenho do sistema será afetado por fatores como a velocidade da conexão do usuário com a internet, a quantidade de requisições sendo realizadas e a quantidade de filtros utilizados durante as buscas.
7. Qualidade
O padrão de arquitetura MTV organiza as camadas da aplicação de forma que elas se tornem mais independentes, ou seja, cada camada possui sua responsabilidade. A estruturação do código e implementação deverá ser compreensível e organizada de modo a possibilitar uma melhor visualização de onde se encontra cada aspecto do produto e a implementação de cada caso de uso.
