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 | 2.0 | Adição do Definições, Referências e Começar Representação de Arquitetura | Guilherme |
| 28/08 | 2.1 | Finalização do Tópico Representação de Arquitetura | Guilherme |
| 29/08 | 2.2 | Adição do Tópico Visão de Casos de Uso | Natália Rodrigues |
| 29/08 | 2.3 | Adição dos Tópicos Tamanho e Desempenho e Qualidade | Lucas kishima |
| 29/08 | 2.4 | Iniciando tópico Visão de Implementação | Felipe Borges |
| 30/08 | 2.5 | Adição do Tópico Restrições e Metas de Arquitetura | Mateus Nóbrega |
| 30/08 | 2.6 | Conclusão do tópico Visão de Implementa | Felipe Borges |
| 30/08 | 2.7 | 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 | 2.8 | Ajustes no Tópico Visão de Casos de Uso | Natália Rodrigues |
| 31/08 | 2.9 | Adição do Tópico Visão Lógica | Michel Camargo |
| 31/08 | 3.0 | Ajustes no Tópico Restrições e Metas de Arquitetura | Mateus Nóbrega |
| 31/08 | 3.1 | Ajustes no Tópico Introdução Escopo, Restrições e Metas e Referências | Hiroshi |
| 31/08 | 3.2 | Revisão | Hiroshi, Felipe Borges, Guilherme |
| 31/08 | 3.3 | Revisão dos Tópicos Tamanho e desempenho e Qualidade | Lucas Kishima |
| 31/08 | 3.4 | Revisão do Tópico Visão Lógica | Michel Camargo |
| 02/09 | 3.5 | Revisão do Diagrama de pacotes e do Diagrama de classes | Felipe e Mateus |
-
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
- Tamanho e Desempenho
- Qualidade
1. Introdução
1.1 Finalidade
Este documento tem como objetivo apresentar uma visão da arquitetura escolhida para o software. Para isso são utilizadas abordagens diversas em diferentes aspectos do sistema, de modo a explicitar as decisões arquiteturais que foram tomadas pela equipe durante a definição do escopo. Cada tópico irá explicar e formalizar as decisões com base nos requisitos do sistema.
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 Faculdade Gama.
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.
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 eme poucos segundos. Ela também deverá atender aos recursos não funcionais, como o estruturamento de código, para que a manutenção do sistema ocorra de modo versátil.
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. 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 - 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. |
| UC02 - Manter Profissionais de saúde | Este caso de uso permite ao profissional da saúde a criação, edição ou exclusão do seu cadastro. |
| UC03 - Manter Receituário | Este caso de uso permite ao profissional da saúde a criação, edição ou exclusão de um receituário. |
| 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 - Manter Pacientes | Este caso de uso permite aos pacientes a criação, edição ou exclusão do seu cadastro. |
| UC09 - Enviar Exames | Este caso de permite que pacientes enviem seus exames aos profissionais da saúde. |
| UC10 - Consultar Histórico | Este caso de uso permite aos pacientes a realização de consultas ao seu histórico de receituário. |
| UC11 - Visualizar Exames | Este caso de uso possibilita aos pacientes a visualização dos seus exames. |
| UC12 - Visualizar Receitas | Este caso de uso possibilita aos pacientes visualização das suas receitas. |
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 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. |
| DoctorView | contém as funcionalidades do Profissional da sáude. | |
| 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
Devido à quantidade de receitas que serão mantidas no banco de dados, o tamanho do sistema tende a ser grande, haja vista que é previsto o processamento de um grande volume de dados. 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, tornando o código mais organizado e compreensível, possibilitando uma melhor visualização de onde se encontra cada aspecto do produto e seus casos de uso.
