Análise - romulets/WazpitalBackend GitHub Wiki

Concepção

1.1. Para quem é o sistema?

O Sistema é para toda pessoa que utiliza serviços hospitalares 24 horas (pronto-socorro).

1.2. Que problemas ele resolverá?

Com esse sistema, a distribuição de pessoas que estão em hospital será equalizada. Tomando em consideração distância e lotação de um hospital, o usuário evitará filas e será atendido em menor tempo.

1.3. Onde ele será utilizado?

O plano geográfico é de inicialmente, em fase beta, funcionar apenas em Curitiba e região metropolitana. Após essa fase, estender para grandes capitais, onde é fácil de obter localização de hospitais e existe usuários o suficiente para suprir a necessidade do software para medir lotação de hospitais.

É necessário pensar em um plano melhor de crescimento. Pensar em questões como:

Será disponibilizado um formulário web para credenciamento de hospitais?
Entraremos em contato com prefeituras para saber quais são os hospitais?
Como será feito em cidades pequenas?

1.4. Quando ele será utilizado?

No momento em que o usuário precisar de um pronto-socorro.

1.5. Por que ele é necessário?

Atualmente as pessoas vão aos hospitais apenas considerando se gostam do atendimento ou a distância de sua localização até o estabelecimento. Porém, essas variáveis não são o suficiente para ter uma noção de se o atendimento irá demorar ou não. Com o aplicativo o usuário terá essa noção e como consequência a distribuição de pessoas entre hospitais tenderá a ser equalizada.

1.6. Como ele funcionará?

A ideia inicial do aplicativo se baseia no Waze. Usuários que estão no hospital poderão contribuir com o sistema fornecendo informações sobre hospital (lotação e tempo médio de consulta).

Com essa informação o software apresentará um Ranking de hospitais aos usuários procurando pronto-socorros, considerando as variáveis coletadas pela comunidade + distância entre o usuário e o hospital.

2. Análise da Aplicação

2.1. Quais são os Atores do sistema?

Os atores do sistema são o Mobile User, ator principal do sistema, que avalia os hospitais e relata erros em dados incorretos e o Admin, que será o responsável por registrar e/ou editar hospitais, além de corrigir e/ou apagar dados incorretos de hospitais já registrados.

2.2. Quais são as fronteiras do sistema?

O sistema terá fronteira com a API do Google Maps e com a API ViaCEP, uma API, assim como o nome sugere, para CEPs.

2.3. Quais são os Casos de Uso do sistema?

General Use Cases

2.4. Quais são as relações entre os Atores e Casos de Uso?

USD 1.1. Maintain Hospital

UseCase 1

USD 1.2. Maintain Hospital

UseCase 1.1

USD 2. Maintain information errors

UseCase 2

USD 3. Rate hospital

UseCase 3

USD 4. Register

UseCase 4

USD 5. Report information error

UseCase 5

2.5. Quais são os fluxos principais e alternativos?

3. Análise de Domínio

3.1. Quais são as Classes que compõem o domínio da informação?

Class Diagram

3.2. Quais são os principais atributos dessas classes?

Os principais atributos estão nas classes Hospital e Rate.

Na classe Hospital os principais são averageOverflowingLevel, averageAttendanceRate e avaregeAttendanceSpeed que indicam, respectivamente, o nível médio de lotação, qualidade de atendimento e velocidade do atendimento.

Na classe Rate os principais atributos são overflowingLevel, attendanceRate e attendanceSpeed que indicam, respectivamente, a nota que o Mobile User deu para o nível de lotação, qualidade de atendimento e velocidade de atendimento. Notas essas que formam o valor médio para cada hospital.

3.3. Quais são as associações entre essas classes?

As principais associações entre as classes são entre o Hospital, User e Rate.

User tem associação com Rate, que são todas as avaliações (rates) que o usuário (User) deu para determinado hospital.

Rate, além da associação com User descrito acima, possui uma relação com Hospital, que indica que aquela avaliação (rate) é referente aquele Hospital.

3.4. Quais são as multiplicidades das associações

Um User pode possuir 0 (zero) ou muitas rates, já Rate pode possuir apenas 1 (um) user.

Hospital pode possuir 0 (zero) ou muitas rates, já Rate pode possuir apenas 1 (um) hospital.

Em outras palavras, um usuário (User) pode realizar diversas avaliações (Rate) e essa avaliação pertence apenas a esse usuário.

Hospital pode receber diversas avaliações (Rate) e essas avaliações são referente apenas a 1 (um) hospital.

3.5. Existem relações de herança entre essas classes?

Apenas há relação de herança nas classes referente da camada DAO do sistema.

4. Arquitetura da Solução

4.1. Padrões e Nomenclatura

O projeto utiliza como padrão:

Controller: [Dominio da Funcionalidade]Controller
- Exemplo: UserController e HospitalController
DAO: [Dominio da Funcionalidade]Dao
- Exemplo: UserDao e HospitalDao
Servlet: [Funcionalidade]Servlet
- Exemplo: AddHospitalServlet e ListHospitalServlet

4.2. Tecnologias Utilizadas

Para servidor web utilizamos Java Servlet;
Camada de persistência utilizamos JPA;
Banco de dados utilizamos MySQL;
Para apresentar mapas utilzamos o Google Maps;
Para consultar CEPs utilizamos ViaCEP
Para trabalhar com json utilizamos a biblioteca gson

4.3. Diagramas de Classes e Pacotes Atualizar o diagrama de classes, introduzindo os pacotes DAO, BusinessController, etc. Inserir nos pacotes as classes e os métodos necessários.

Diagrama de Classes da Arquitetura