Sistemas para Internet II: Relatório Site PHP

Lucas Custodio - 116525

lucascust@furg.br

Sumário
1 Introdução 2
1.1 Sistema de Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Front-end 2
2.1 Pagina Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Cadastro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Perfil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Edição de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 Back-end 7
3.1 Armazenamento e Tratamento de Dados (XML) . . . . . . . . . . . . . . . 7
3.2 Principais Algoritmos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 Login e Cookies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2 Validação dos dados . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 Busca de informações . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4 Estruturação de Tabelas do Pefil . . . . . . . . . . . . . . . . . . . 10
3.2.5 Reconhecimento de exames . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.6 Edição de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Resultados 12

5 Agradecimentos 17

1
1 Introdução
O presente trabalho propõe uma aplicação simplificada para gerenciamento de um
plano de saúde. Para tal, será utilizado pseudo-usuários padrão para cada categoria ao
longo do relatório para fim de explicações conforme a Tabela 1. Além disso, esses usuários
estarão nativamente cadastrados na aplicação para testes locais.

Tipo de Usuário Dados

Email: admin@email.com
Administrador
Senha: 0000
Email: lab@email.com
Laboratório
Senha: 0000
Email: medico@email.com
Médico
Senha: 0000
Email: paciente@email.com
Paciente
Senha: 0000

Tabela 1: Informações de usuários e suas categorias.

1.1 Sistema de Arquivos

Os arquivos da aplicação são separados conforme a Figura 1(a). Como é observável,
para cada função, existe uma pasta para a mesma, no caso, Cadastro, Login, Perfis
(Profile) e edição (Edit). Dentro de cada pasta de funções, existem arquivos com os
nomes das categorias de usuários correspondentes, Figura Figura 1(b). As pastas CSS
e Font armazenam os estilos das páginas e a fonte utilizada nelas, respectivamente. Por
fim, em Dados, temos as informações dos usuários cadastrados — bem como exames e
consultas — no mesmo padrão das funções, com arquivos separados para cada tipo.
Fora das pastas, existem os arquivos principais: index.php representando a página
principal do website, login.php com a página de login, que guiará para o login de cada tipo
de usuário e a masterpage.php que é uma página para auxiliar em testes e desenvolvimento,
podendo ir diretamente para qualquer parte da aplicação. Posteriormente, na Seção 2 será
abordado a interface que interage com usuário, conhecida por Front-end, na Seção 3 a parte
lógica que realiza as execuções solicitadas pelo front-end, o Back-end será apresentada.
Finalmente, a Seção 4 traz resultados referentes à execução da aplicação e contextos que
a mesma gera.

2 Front-end
Para a estruturação e customização da interface gráfica, não foi utilizado frameworks
como bootstrap ou bibliotecas como JQuery, portanto, utilizou-se unicamente HTML e
CSS. Essa decisão foi tomada para fins de aprendizado da base do front-end, princi-
palmente visando como seriam feitos elementos dinâmicos com essas linguagens. Nas
subseções a seguir será abordada a interface de cada página.

2.1 Pagina Principal

Representada pelo arquivo index.php, A página inicial serve apenas para iniciarmos
a aplicação, ou então acessarmos a página mestre. Dois arquivos de CSS são utilizados:

2
o próprio da página index.css e um que é comum a todas as páginas, trazendo algumas
padronizações, como os botões main.css.

(a) (b)

Figura 1: (a) Pastas recolhidas e (b) Arquivos dentro de “Cadastro”e “Login”.

Figura 2: Página inicial do website proposto.

2.2 Cadastro
A página de cadastro é basicamente composta por entradas de texto, mas diverge em
algumas delas de acordo com o tipo de usuário. Como exemplo, na Figura 3, o cadastro
de pacientes possui a entrada no estilo “radio”, para inserção de gênero, que coincide
com o médico e se ausenta no laboratório e administrador. No caso do laboratório, existe
um campo em formato de lista de checkbox para inserir os tipos de exames que o mesmo
dispõe.

3
 Figura 3: Página para cadastro de pacientes.

Além dos usuários, é possı́vel cadastrar também consultas e exames, e consequente-

mente, há uma página exclusiva para ambos. Sua disposição é similar às demais, porém,
com alguns campos especiais, como para inserção de data, que é um tipo especı́fico de en-
trada e também, o campo para horários, que é uma entrada do tipo lista com os possı́veis
horários. A página de edição de exames pode ser vista na Figura 4.

Figura 4: Página inicial do website proposto.

4
2.3 Login
A página de login possui duas etapas: na primeira (Figura 5), o usuário escolhe seu
tipo perante a plataforma. A escolha é feita por uma seleção estilo “radio”, com a exceção
do administrador, que dispõe de um botão para encaminhá-lo ao seu ambiente correspon-
dente, também de login. Na segunda etapa da página para login haverá os campos para
inserir e-mail e senha, de forma similar à Figura 5, porém com campos do tipo texto.

Figura 5: Página de login geral.

2.4 Perfil
Aqui temos uma aplicação de interface dinâmica, pois no perfil poderemos ver na
página a lista de exames ou consultas que o usuário está vinculado. Na Figura 6, refe-
rente ao perfil de um laboratório, a tabela se apresenta vazia, e seu preenchimento será
apresentado posteriormente na Seção 4. Para o caso do paciente, haverá duas tabelas,
pois o mesmo poderá estar vinculado tanto a exames quanto a consultas.

2.5 Edição de dados

Para a edição de dados, a página apresentada na Figura 7 é proposta. No caso ilus-
trado, refere-se à edição de dados de um laboratório, que por sua vez apresenta as in-
formações acima das entradas (em branco no exemplo). Ademais, os tipos de exames
fornecidos pelo laboratório são apresentados em lista, de acordo com a quantidade de
tipos, bem como um botão para sua remoção.

5
 Figura 6: Página de perfil para laboratórios.

Figura 7: Página de edição de dados de um laboratório.

6
3 Back-end
Nesta seção será abordado as regras de negócio para a execução das funções que tan-
gem a aplicação, apresentando os principais algoritmos para ilustração da implementação
usada. Utilizou-se majoritariamente PHP para tais funções, e um pouco de Javascript
para funções auxiliares. Apenas bibliotecas nativas dessas linguagens foram utilizadas,
como a simplexml do PHP para lidar com permissividade dos dados por XML, investigado
na próxima seção.

3.1 Armazenamento e Tratamento de Dados (XML)

Os dados da aplicação são armazenados em arquivos XML individuais para cada tipo
de cadastro. A estrutura padrão é um grande grupo do tipo no plural, como “labo-
ratorios”, “medicos”ou “consultas”, e dentro há nodos com o mesmo nome, porém, no
singular, representando cada cadastro. Para cada usuário, exame ou consulta cadastrado,
é gerado um id único através da função uniqid (), nativa do PHP. Essa função retorna
um identificador prefixado baseado no tempo atual em milionésimos de segundos, que
para o caso do sistema proposto, garante a unicidade dos ids. O Código 1 demonstra
um arquivo XML para laboratórios com um único cadastro. É o único caso com um dos
nodos (exames) com nodos filhos, guardando cada tipo de exame dentro de si.
<l a b o r a t o r i o s>
<l a b o r a t o r i o i d=” 5 f d 6 f 0 0 c 3 8 7 a 3 ”>
<name>Nome</name>
<a d r e s s>Endereco</ a d r e s s>
<phone>T e l e f o n e</ phone>
<e m a i l>Email</ e m a i l>
<CNPJ>CNPJ</CNPJ>
<password>Senha</ password>
<exames>
<exame>Exame1</exame>
<exame>Exame2</exame>
<exame>Exame3</exame>
<exame>Exame4</exame>
</ exames>
</ l a b o r a t o r i o>
</ l a b o r a t o r i o s>

Código 1: Estrutura de dados em XML de um laboratório genérico dentro da aplicação.

Apesar de os dados estarem generalizados no Código 1, cada um tem sua particula-
ridade, podendo ser somente números, letras e espaços ou então, o formato padrão de
e-mail. Os detalhes de validação da entrada é apresentado na Seção 3.2.2. Para o caso de
cadastros para não-usuários (exames e consultas), os dados de ambos os lados da relação
são armazenados para a apresentação dos mesmos nos perfis individuais relacionados.
Ademais, campos vazios são gerados para futuras inserções de dados, no caso, receitas e
observações para médicos e resultado dos exames para laboratórios. O Código 2 ilustra o
cadastro de consultas.
<c o n s u l t a s>
<c o n s u l t a i d=” 5 f d b 1 5 1 e 6 0 2 4 4 ”>
<namePatient>Nome do P a c i e n t e</ namePatient>
<nameDoctor>Nome do Medico</ nameDoctor>
<e m a i l P a t i e n t>Email do P a c i e n t e</ e m a i l P a t i e n t>
<e m a i l D o c t o r>Email do Medico</ e m a i l D o c t o r>
<d a t e>Data</ d a t e>
<hour>H o r a r i o</ hour>

7
 <p r e s c r i p t i o n />
<o b s e r v a t i o n s />
</ c o n s u l t a>
</ c o n s u l t a s>

Código 2: Cadastro de consulta no arquivo XML correspondente.

Como é observável nos códigos apresentados, existe uma indentação para os XML,
respeitando a hierarquia dos nodos. Não limitado aos exemplos, esse padrão é construı́do
automaticamente pela aplicação através da abertura do arquivo XML pela função dom
import simplexml (). Através dessa função um elemento DOM (Document Object Model )
é criado, que por sua vez permite alterações na estrutura e estilo de um XML. Tal objeto
possui um atributo booleano formatOutput, que quando posto como verdadeiro, indenta
o arquivo de forma adequada ao salvá-lo.

$dom → f ormatOutput = true;

3.2 Principais Algoritmos

Nesta seção, alguns trechos selecionados do código-fonte são apresentados e explorados.
O critério de seleção se baseia subjetivamente em sua relevância para o funcionamento do
sistema, bem como sua especificidade em relação a demais trechos.

3.2.1 Login e Cookies

Para logar na plataforma, independente de qual tipo o usuário seja, é requerido o
e-mail e senha do mesmo. Quando logado, é gerado um cookie com a seguinte estrutura :

Nome: ‘administrador’ | ‘laboratorio’ | ‘medico’ | ‘paciente’
cookie
Valor: e-mail
Portanto, através do cookie, que é visı́vel em todas as páginas, podemos identificar o
tipo do usuário e sua identidade sempre que necessário. Em sua criação, o cookie tem
prazo de expiração de 86 mil segundos (1 dia). No cenário atual, é possı́vel conectar em
todos os tipos de contas simultaneamente, permitindo a existência de até 1 (um) cookie
para cada tipo. Esse caso é permitido apenas para desenvolvimento e testes, não sendo
o cenário adequado para o deploy da aplicação. Como consequência, poderá existir uma
sobreposição de cookies, que no sistema, o de administrador sempre é prioridade em caso
de concorrência.
Por conseguinte, quando o usuário entra na página de login, sempre é verificado se há
um cookie ativo, e caso positivo, manda-o imediatamente para seu perfil correspondente.
Essa verificação é facilmente feita por

isset($ COOKIE[0 tipo de usuario0 ]),

que verifica se um cookie especı́fico — variável global $ COOKIE — existe através da

função isset(), também nativa do PHP. Com isso, caso estejamos conectados como admi-
nistrador e paciente simultaneamente, por exemplo, seremos redirecionados para o perfil
de administrador automaticamente ao entrar na página de login. Caso queiramos acessar
a página de perfil do paciente, em tal situação, deve-se utilizar a página mestre para o
encaminhamento direto à pagina desejada. Outra opção seria realizar a desconexão do
administrador através de seu perfil.
É importante também, que exista o cookie para o tipo de usuário do perfil acessado,
mesmo que tenha sido via página mestre, pois caso contrário, o sistema notificará a

8
falta da conexão e retornará para página de login. Além das funções conectivas, os
cookies desempenham papel fundamental na aquisição de dados dentro da plataforma. A
Tabela 2 apresenta diferentes aplicações dos mesmos em diferentes escopos do sistema,
acompanhado de sua função e origem.

Arquivo Linha Código Função

Profile / 66 if($ COOKIE[“laboratorio”] == Verifica se há labo-
laboratorios.php $exame→emailLaboratorio): ratório no XML exame

Cadastro / 132 $child → addChild(‘emailLab’, Armazena e-mail lo-

exames.php $ COOKIE[“laboratorio”]); gado no XML

Login / 48 isset($ COOKIE[‘laboratorio’]) Verifica se há cookie

laboratorios.php para login automático
Cadastro / 115 getName($ COOKIE[“laboratorio”], Encontra nome do
exames.php “laboratorio”); usuário logado.

Tabela 2: Tabela de utilização de cookies em diferentes aplicações.

3.2.2 Validação dos dados

Para garantir que os dados de entrada na aplicação são corretos, a seguinte sequência
foi implementada:

ˆ Verifica existência:
empty($ POST[“ ψ ”])

ˆ Limpa a entrada:

– Remove contra-barras:
stripslashes($data)
– Remove espaços antes e depois da string:
trim($data)

ˆ Caso necessário, compara com um RegEx para tipagem de caracteres:

preg match(“/ˆ[a-zA-Z ]*$/”,$name)

Na verificação de existência, a função empty() retorna verdadeiro caso a variável global

$ POST[“ ψ ”] esteja vazia, sendo ψ o nome de um tipo de entrada genérico. Na sequência
há uma limpeza na entrada recebida caso tenha passado pelo teste de existência. A
limpeza consiste basicamente em remover os caracteres de contra-barra “\”e espaços vazios
antes e depois da entrada. Os espaços vazios não se limitam ao “espaço”, — ou caractere
32 na tabela ASCII — pois inclui também tabulações “\t”, nova linha “\n”e o byte nulo
“\0”.

3.2.3 Busca de informações

A página de edição de dados de um laboratório, por exemplo, precisa adquirir as
informações do mesmo entre os arquivos de dados do sistema. Para o exercı́cio dessa
função, o PHP presente no Código 3 é executado imediatamente ao abrir a página, gerando
uma variável que identifica o laboratório em seu respectivo XML. Sua lógica é simples:

9
percorre o arquivo XML de laboratórios e compara o e-mail do laboratório atual (fornecido
pelo cookie) com cada instância de laboratório presente no arquivo, quando encontra,
armazena o valor da iteração.
$ xml = s i m p l e x m l l o a d f i l e ( ” . . / Dados/ l a b o r a t o r i o s . xml” ) ;
f o r ( $ i = 0 ; $ i < $ xml=>count ( ) ; $ i ++) {

$ l a b o r a t o r i o X m l = $ xml=>l a b o r a t o r i o [ $ i ]=> e m a i l ;

i f ( $ COOKIE [ ’ l a b o r a t o r i o ’ ] == $ l a b o r a t o r i o X m l ) {
$laboratorioId = $i ;
break ;
}
}

Código 3: Busca do laboratório logado para o arquivo XML correspondente.

Para percorrer o arquivo XML, é necessário utilizar um método presente no objeto
gerado pela iniciação do XML através da função simplexml load file(), no caso, o método
count(). Tal método conta quantos filhos um nodo tem, para o XML de laboratórios
como um todo, e retornará o número de laboratórios. Através desse valor podemos per-
correr o objeto $xml, pois podemos interpretá-lo como um vetor quando o invocamos com
colchetes “[n]”, sendo n a posição do elemento no XML. Baseado no mesmo princı́pio,
ao encontrarmos o atual laboratório dentro do arquivo de dados, feito pela comparação
dentro do if (), armazenamos o valor atual do contador $i e o utilizamos para identificá-lo
e adquirir os dados correspondentes. Ademais, como o atributo e-mail é único no banco
de dados, ao encontramos no arquivo o laboratório que está atualmente logado, pode-se
usar a declaração break para finalizar a busca, evitando um percorrimento desnecessário
dos demais nodos do XML.

3.2.4 Estruturação de Tabelas do Pefil

O perfil do usuário apresenta uma tabela de seus exames e/ou consultas em sua com-
posição, dependendo do tipo de usuário. Para a geração dessa tabela, utilizou-se a própria
estruturação de tabela do HTML, e o Código 4 explicita do corpo da tabela tbody. Utili-
zando o exemplo do perfil de um médico, as linhas são geradas dinamicamente de acordo
com a quantidade de consultas vinculadas a ele. Cada coluna recebe seu valor extraı́do
do XML para as consultas identificadas, com exceção das ultimas duas, que são criadas
em branco. Essas colunas finais representam a receita médica e observações, respectiva-
mente, e são iniciadas vazias. As observações são vistas unicamente pelo perfil médico,
sendo omitidas para o paciente, o que pode ser feito simplesmente removendo a linha
correspondente. A única informação que é alterada para a apresentação é a hora da con-
sulta, que no arquivo de dados é armazenada com um inteiro, e para o a apresentação é
adicionado os caracteres “:00” a tı́tulo de legibilidade para o usuário.
<tbody>
<?php f o r e a c h ( $ xml=>c o n s u l t a a s $ c o n s u l t a ) :
i f ( $ COOKIE [ ” medico ” ] == $ c o n s u l t a =>e m a i l D o c t o r ):? >
<t r >
<td> <?php echo $ c o n s u l t a =>namePatient ; ?> </td>
<td> <?php echo $ c o n s u l t a =>e m a i l P a t i e n t ; ?> </td>
<td> <?php echo $ c o n s u l t a =>d a t e ; ?> </td>
<td> <?php echo s t r v a l ( $ c o n s u l t a =>hour ) . ” : 0 0 ” ; ?> </td>
<td> <?php echo $ c o n s u l t a =>p r e s c r i p t i o n ; ?> </td>
<td> <?php echo $ c o n s u l t a =>o b s e r v a t i o n s ; ?> </td>
</t r >

10
 <?php e n d i f ; e n d f o r e a c h ; ?>
</tbody>

Código 4: Busca do laboratório logado para o arquivo XML correspondente.

3.2.5 Reconhecimento de exames

Quando é realizado o cadastro de um exame, a plataforma precisa apresentar ao usuário
(laboratório) os tipos de exames que o mesmo realiza para que haja a seleção de um deles.
Para tanto, é necessário reconhecer quais os exames presentes no cadastro do laboratório,
bem como apresentá-los visualmente. Consequentemente, há variações no HTML tendo
a quantidade de exames disponı́veis como dependência, o Código 5 traz a proposta de
solução com uma mesclagem de HTML e PHP. Um dos reveses dessa abordagem é uma
baixa legibilidade do código. O primeiro encapsulamento select é a declaração de um menu
de opções em HML. Para a criação dos itens, ou opções, uma estrutura PHP precede a
declaração com três funções: a primeira percorre os laboratórios do arquivo de dados, a
segunda identifica se o e-mail do laboratório do arquivo é o igual ao do usuário logado,
e por fim, a terceira função percorre os exames do nodo “exames”, como mencionado
anteriormente, é o único atributo multi-valorado das estruturas XML da aplicação. Ao
percorrer os exames, o HTML que corresponde à definição de opções é instanciado, e
portanto, para cada tipo de exame, uma opção é criada com seu nome.
< s e l e c t i d=” e x a m s e l e c t ” name=”exam” v a l u e=”<?php echo $ exam;? > ”>
<?php f o r e a c h ( $ xml=>l a b o r a t o r i o a s $ l a b o r a t o r i o ) :
i f ( $ COOKIE [ ” l a b o r a t o r i o ” ] == $ l a b o r a t o r i o =>e m a i l ) :
f o r e a c h ( $ l a b o r a t o r i o =>exames=>exame a s $ exam ):? >
<o p t i o n > <?php echo $ exam ; ?> </o p t i o n >
<?php e n d f o r e a c h ; e n d i f ; e n d f o r e a c h ; ?>
</ s e l e c t >

Código 5: Aglutinação de PHP e HTML para introduzir tipos de exames em um menu.

3.2.6 Edição de dados

A fim de modificar dados do usuários, a lógica dos códigos já apresentados aqui são
reaproveitadas. Primeiramente, o conceito de busca da Subsubseção 3.2.3 é usado para
identificar qual nodo do arquivo XML deve ser modificado. Posteriormente, os dados
recebidos na requisição são testados conforme a validação da Subsubseção 3.2.2. Por fim,
a edição é feita por

$xml → laboratorio[$laboratorioId] → name = $name

para o caso de uma mudança de nome de um laboratório. No caso, com o arquivo XML
instanciado como um objeto, basta modificar seus atributos para termos a edição, e para
efetivar a mudança, o objeto $xml é salvo ao final do código. O cenário que temos nessa
ocasião é que podemos mudar quaisquer dados simultaneamente e independentes entre
si, pois modificamos apenas aquilo que é recebido, visto que o teste de validação verifica
existência.
Outra modificação que pode ser requerida é a remoção de um tipo de exame de um
laboratório. Dentro da página de edição é apresentado uma lista dos tipos de exames
cadastrados para o laboratório em questão, usando o mesmo princı́pio do algorı́timo da
3.2.5. Ao lado dos nomes desses tipos, há um botão indicando a possibilidade da remoção.

11
Pressionando do botão e requerindo a remoção, o exame é buscado dentro do nodo “exa-
mes”, que por sua vez está dentro do nodo “laboratório”. Quando encontrado o código

unset($xml → laboratorio[$Id] → exames → exame[$i]);

é executado para a remoção da linha que corresponde ao exame a ser retirado. A veri-
ficação que identifica a remoção de tipo de exame é a primeira das verificações, e quando
chamada, ela própria salva o XML e executa um retorno, não dando continuidade à demais
edições, por se tratar de um botão especı́fico.

4 Resultados
Para uma validação do funcionamento da aplicação, ilustrações gráficas de seu funcio-
namento trazem uma noção de seu comportamento de acordo com os requisitos previstos.
Esta seção compila tais ilustrações, que em conjunto com a execução do código-fonte
validam o funcionamento pleno.
Em primeira instância, na página principal da aplicação podemos ver na Figura 8 que
não temos cookies criados, e no momento, todos os arquivos de dados estão vazios.

Figura 8: Primeiro momento do sistema, sem cookies .

Dando continuidade, entrando na página de login, encaminhando para o ambiente do

administrador e iniciando seu cadastro, temos o cenário da Figura 9. Os dados previstos
na Tabela 1 são utilizados para realizar o cadastro, e como é observável, antes do envio
ainda não há registros no arquivo de dados.
Ao enviarmos as informações de entrada, a página foi redirecionada para a página de
login de administradores e podemos observar seu registro em administradores.xml
Por conseguinte, é feito o login com os dados do cadastro, resultando na Figura 11. É
recebido uma caixa de alerta informando o sucesso do login, e podemos ver através dos
cookies do navegador, que temos uma nova instância de cookie administrador com seu
valor representando o e-mail do mesmo, grifado em vermelho.
Na Figura 12 temos já o cadastro e logins de todos os usuários previstos na Tabela 1, e é
feito uma tentativa de cadastro de uma consulta. Na imagem temos dois erros propositais

12
 Figura 9: Momento antes do envio de cadastro .

Figura 10: Resultado após realizar o cadastro de administrador.

13
Figura 11: Notificação de login e cookie gerado.

14
para teste da ferramenta, sendo o primeiro na Figura 12 (a) uma entrada inválida de
e-mail, sem o caractere “@”, nem uma finalização “.com”ou similar. Temos então um
erro de formato. No segundo teste, em Figura 12 (b), é inserido um e-mail no formato
válido, mas que não corresponde a nenhum usuário cadastrado, portanto, é apresentada
uma caixa de alerta com tal informação.

(a)

(b)

Figura 12: Injeção de falha (a) formato e (b) inexistência.

Após testes de erros propositais, a Figura 13 realiza um cadastro correto de consulta,

gerando o nodo “consulta”no arquivo consultas.xml contendo as informações inseridas,
mais as adquiridas através da aplicação.

Figura 13: Efetivação do cadastro de consulta .

Para averiguar o comportamento da apresentação de tipos de exame que um labo-

ratório oferece, a Figura 14 apresenta em (a) as opções para marcar um exame e em (b),

15
quando é aberto a página de edição. Pode ser visto que ambos retornaram apresentaram
os mesmos exames, que são os contidos no arquivo de dados.

(a) (b)

Figura 14: Demonstração do reconhecimento de exames.

Tendo alguns exames e consultas marcadas, podemos vê-las ao acessar o perfil de

laboratório para exames Figura 15 (a), e o perfil de médico para as consultas Figura 15
(b).

(a)

(b)

Figura 15: (a) Perfil laboratório e (b) perfil médico após cadastros.

Por fim, acessando a página do paciente, temos ambas tabelas apresentadas simulta-
neamente, considerando o paciente logado. Vale salientar que o paciente não recebe a

16
informação das observações.

Figura 16: Perfil do paciente mostrando ambas relações.

Com a sequência de execuções apresentadas, pode-se concluir que a aplicação é funci-

onal.

5 Agradecimentos
Agradeço o Ubaldo por ceder seu nome para exemplificação do paciente, pode ser visto
na Figura 17. No caso da Diana e do LAMSA não tive autorização, espero que não me
processem.

(a) (b)

Figura 17: (a) Ubaldo deitado e (b) Ubaldo deitado.

17