Versão do Modelo: 1.

1
Documentação do Projeto
Emissão: 13/11/2020 Página: 1/14

Projeto:
Medapp

Projeto da Disciplina Dispositivos Móveis

ALISSON ROCHA DOS SANTOS

CLISTENYS EDUARDO TEIXEIRA BATISTA DE SOUSA
DANIEL PEREIRA OLIVEIRA
ULISSES NATAN CASCAES CORREIA
WESLEY SOUSA E SOUSA

Medapp
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 2/14

Projeto:
Medapp

Histórico de Revisões do Documento

Revisão Descrição Modificado por Status Data

1.0 Prévias das Classes Clistenys Eduardo Em desenvolvimento 10/11/2020
1.1 Classes definitivas Clistenys Eduardo Aprovado 13/11/2020
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 3/14

Projeto:
Medapp

1 Descrição do Projeto

1.1 Escopo
Justifica-se este projeto com a constante rotatividade de documentos na clínica fisioterapêuti-
ca FisioLife tem gerado prejuízos para a organização, que precisa lidar não somente com os custos
de documentos, mas também com seu armazenamento e preservação. Assim, acreditamos que a
implantação de um software para gerenciar as principais tarefas da empresa é a melhor solução nes-
te caso, pois atua na automação e controle de documentos, ajudando os colaboradores a executar
suas tarefas e motivando-os, quanto na gestão de tarefas, descentralizando as atividades dentro da
clínica.
Trata-se de um sistema mobile para auxiliar médicos e recepcionistas de uma fisioterapêutica
FisioLife no processo de atendimento e gerenciamento de filas de espera. As agendas dos médicos
seriam configuradas de acordo com os dias e horários de atendimentos de cada um, bem como a
quantidade máxima de consultas permitidas. Já na recepção o sistema auxiliaria os atendentes a
identificar a consulta de um paciente marcada previamente e na inserção de novos pacientes na fila
de atendimento sem marcação prévia de uma consulta.
O Software será online e, disponibilizado para as plataformas mobile. Cada colaborador pode-
rá gerenciar suas atividades individualmente para promover as competências necessárias ao seu
cargo ou papel. Além disso, cada colaborador terá a dois conteúdos: um com um acesso geral da
clínica e outro com recursos específicos da sua competência. A ideia é que sejam disponibilizadas
mais funcionalidades após a conclusão deste projeto. Elas deverão atender ao que foi proposto em
cada uma das competências individuais dos colaboradores.
O projeto possui um prazo de tempo para conclusão de 2 semanas, tendo como principais
Stakeholders do Projeto são: Nossa Cliente do projeto Lídia Fernanda; Patrocinadora Vauz Corp; Ge-
rente de projeto: Clistenys Eduardo; Equipe de desenvolvimento: Wesley Sousa, Daniel Oliveira e
Clistenys Eduardo. Além disso, possui alguns critérios de aceitação como: No que tange o agenda-
mento de consultas, deverá seguir as especificações descritas na Política de Trabalho Corporativa;
Os prontuários de pacientes deverão seguir o modelo repassado pela área de Administração; A plata-
forma deverá possibilitar o cadastro de novas especialidades no sistema.
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 4/14

Projeto:
Medapp

1.2 Requisitos

Requisitos funcionais

1.2.1 [REQ-01] O sistema deve permitir a manipulação de informações da Clínica,

que são: Nome da clínica, endereço, telefone.

1.2.2 [REQ-02] O sistema deve guardar informações sobre os médicos da clínica:

Nome do médico, CPF, RG, telefone, endereço.

1.2.3 [REQ-03] O sistema deve permitir a manipulação de pacientes, suas informa-

ções pessoais (Nome, Endereço, Telefone, CPF, RG, Sexo e Convênio ao qual está
associado), e informações sobre a ficha médica (Principal queixa do paciente, ante-
cedentes médicos, história da doença atual, hipótese de diagnóstico, medicação
prescrita, exames em aparelhos e sistemas, e exames complementares). Informa-
ções sobre o paciente não podem ser removidas do sistema, por exigências da lei.

1.2.4 [REQ-04] Somente o médico possui acesso à visualização / modificação de

dados da ficha médica de um paciente.

1.2.5 [REQ-05] O sistema deve manter uma Agenda de Compromissos para cada
médico. Os compromissos devem conter data, hora inicial, hora final, uma descrição
do compromisso. Os compromissos podem ser tanto consultas da própria clínica
(neste caso, o compromisso deve ser associado a um paciente) quantos compro-
missos externos (momentos em que o médico estará ocupado, e não poderá atender
pacientes). Os secretários devem poder ter acesso às agendas dos médicos, para
conveniência destes.

1.2.6 [REQ-06] O sistema deve permitir a manipulação de documentos médicos

(receitas e atestados) que possam ser impressos. O sistema também deve prover
facilidades para edição do cabeçalho / rodapé do documento a ser gerado.
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 5/14

Projeto:
Medapp

1.2.7 [REQ-07] O sistema possui uma base de dados local para ser utilizada quan-
do estiver no modo off-line, ou seja, sem conexão com o banco de dados. Quando
no modo off-line, o usuário apenas pode consultar as informações existentes na ba-
se local, que correspondem à última atualização feita na mesma antes do sistema
ser desconectado.

Requisitos não-funcionais

1.2.8 [RNF 01] - Tempo de Resposta

Descrição: Os usuários do sistema deverão esperar, em média, dez segundos

para o processamento de uma requisição. Isto é, o throughput médio (padrão)
do sistema deverá ser estimado em cinco segundos para qualquer operação.

Prioridade: Importante

1.2.9 [RNF 02] - Interface Amigável

Descrição: Considerando que os operadores do sistema geralmente não pos-

suem intimidade com aplicações, a interface gráfica deverá considerar aspec-
tos de usabilidade. Desenvolveremos a GUI utilizando a API de Java. O obje-
tivo é utilizar aspectos que beneficiem a navegabilidade do usuário no siste-
ma, como disposição intuitiva e hierárquica dos menus. Uma boa estimativa
de tempo para o usuário aprender a utilizar o sistema é que seu aprendizado
dure, no máximo, 25 minutos.

Prioridade: Importante

1.2.10 [RNF 03] - Usuários Simultâneos

Descrição: O sistema deverá suportar processamento multi-usuário, ou seja,

vários usuários poderão utilizar o sistema simultaneamente.

Prioridade: Essencial
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 6/14

Projeto:
Medapp

1.2.11 [RNF 04] - Privacidade

Descrição: Usuários não poderão acessar informações de outros usuários

sem que estejam autenticados no sistema. Outras regras também serão im-
postas de acordo com a hierarquia dos usuários dentro do sistema. Por
exemplo, secretária não pode ter acesso os dados da ficha de atendimento do
paciente.

Prioridade: Essencial

1.2.12 [RNF 05] - Linguagens de Programação

Descrição: O Medapp utilizará JavaScript para implementação dos códigos do

Sistema. Essa tecnologia permitirá o desenvolvimento de um sistema robusto.

Prioridade: Desejável

1.2.13 [RNF 07] - Ferramentas

Descrição: As ferramentas utilizadas serão:

VS Code: Um IDE para desenvolvimento de códigos;

Power Point 2016: Ferramenta utilizada para a modelagem dos casos de uso,
de diagramas de classes e outros aspectos do projeto.
Microsoft Office: Sua utilização será como editor de material auxiliar, i. e. do-
cumentação, e desenvolvimento do site do projeto;

Prioridade: Desejável
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 7/14

Projeto:
Medapp

1.3 Tecnologias

1.3.1 React

O React é a biblioteca mais popular do JavaScript e é usada para construir

uma interface de usuário (IU). Ela oferece uma resposta excelente para o usuário
adicionar comandos usando um novo método de renderizar sites.
Os componentes dessa ferramenta foram desenvolvidos pelo Facebook. Ela
foi lançada em 2013 como uma ferramenta JavaScript de código aberto. Atualmente,
ela permanece na frente das suas principais competidoras, como a Angular e a Boo-
tstrap, as duas bibliotecas JavaScript mais bem vendidas.

1.3.2 React Native

Baseado no React, framework JS para desenvolvimento web, o React Native

possibilita a criação de aplicações móvel multiplataforma (Android e iOS) utilizando
apenas Javascript. Porém, diferente de outros frameworks com esta mesma finali-
dade (Cordova, por exemplo), todo o código desenvolvido com o React Native é
convertido para linguagem nativa do sistema operacional, o que torna o app muito
mais fluido.

1.3.3 Expo

O Expo é uma ferramenta utilizada no desenvolvimento mobile com React Na-

tive que permite o fácil acesso às API’s nativas do dispositivo sem precisar instalar
qualquer dependência ou alterar código nativo. Apesar de cumprir esse papel muito
bem, o Expo possui algumas desvantagens, principalmente para programadores que
estão migrando de um estágio iniciante para intermediário com React Native.
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 8/14

Projeto:
Medapp

1.3.4 Node.js

O Node.js se caracteriza como um ambiente de execução JavaScript. Com

ele, o usuário pode criar aplicações sem depender do browser para isso. Com alta
capacidade de escalabilidade, boa flexibilidade, arquitetura e baixo custo, torna-se
uma ótima opção para programação.

1.3.5 Express

Express é o framework Node mais popular e a biblioteca subjacente para uma

série de outros frameworks do Node. O Express oferece soluções para gerenciar re-
quisições de diferentes verbos HTTP em diferentes URLs, integrar "view engines"
para inserir dados nos templates, definir as configurações comuns da aplicação web,
como a porta a ser usada para conexão e a localização dos modelos que são usa-
dos para renderizar a resposta e adicionar novos processos de requisição por meio
de "middleware" em qualquer ponto da "fila" de requisições.

1.3.6 PostgreeSQL

O PostgreSQL é um sistema de gerenciamento de banco de dados objeto-

relacional baseado no POSTGRES Versão 4.2. O POSTGRES foi pioneiro em vários
conceitos que somente se tornaram disponíveis muito mais tarde em alguns siste-
mas de banco de dados comerciais.

1.3.7 JSON

JSON é basicamente um formato leve de troca de informações/dados entre

sistemas. Mas JSON significa JavaScript Object Notation, ou seja, só posso usar
com JavaScript correto? Na verdade não e alguns ainda caem nesta armadilha,
além de ser um formato leve para troca de dados é também muito simples de ler,
essas características permitem comparar o JSON com o formato XML.
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 9/14

Projeto:
Medapp

1.4 Fontes de dados

Atualmente, a aplicação usa uma API criada pelos desenvolvedores do
projeto. O lado do cliente irá consumir o servidor Epress usando uma biblioteca
chamada Axios pra fazer requisições HTTP, onde os dados irão ser consultados no
SGBD PostgreSQL. Quando confirmados sua disponibilidade pelo SGBD os dados
serão retornados para o cliente em forma de JSON.
Os dados são passados pelo corpo da requisição (Body), onde os dados
passam de um servidor para outro com autorizações do CORS, que é um
mecanismo que permite que recursos restritos em uma página da web sejam
recuperados por outro domínio fora do domínio ao qual pertence o recurso que será
recuperado.
 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 10/14

Projeto:
Medapp

2 Arquitetura Geral da Solução - Diagrama de Componentes

 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 11/14

Projeto:
Medapp

3 Modelo Estático - Diagramas de Classe

 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 12/14

Projeto:
Medapp

4 Modelo Dinâmico - Diagramas de Sequência

 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 13/14

Projeto:
Medapp

5 Protótipos de Tela e Funcionamento do Sistema

 Versão do Modelo: 1.1
Documentação do Projeto
Emissão: 13/11/2020 Página: 14/14

Projeto:
Medapp