Você está na página 1de 11

Estudo de caso

Mello Diagnstico Webservice


Apresentao
Um escritrio de desenvolvimento1 foi contratado pela Clnica de Exames Mello para
reformular o seu website. Uma necessidade do cliente final era que tivesse a
disponibilizao dos dados dos exames para os clientes acessarem pela Internet.
Apesar de desenvolver o website e a configurao dos servidores, o escritrio terceirizou a
produo do webservice e da aplicao de apresentao em formato PDF, sendo esse o
trabalho desenvolvido por mim.

Stakeholders

O projeto

CAPO SOFTWARE SP

O usurio dos servios da clnica de exames recebia um endereo eletrnico e um nmero


de ordem de servio e uma senha. Com esses dados, ele acessaria um servidor
intermedirio que por sua vez se comunicava com o servidor da clnica. Alm do usuriopaciente, o servio tambm poderia ser utilizado pelos mdicos dos pacientes informado
seu CRM2.
Como os exames j eram informatizados, o desafio foi adequar o sistema j existente ao
mundo da Internet. A aplicao desktop da clinica trabalhava com o banco de dados
Firebird, um banco complexo pois continha tabelas de pacientes, funcionrios, exames,
pronturios, modelos de exames, e outros dados. Os dados eram salvos no formato RTF,
um formato que antecedeu o PDF.
Para fazer essa adequao de um modelo de dados complexos, antigos e projetados para
uma aplicao desktop ou intranet; bem como para manter o servidor principal isolado de
ataques maliciosos, foi pensado num webservice.

Parte 1
O Webservice

O webservice foi projetado para ser multiapresentvel, ou seja, para que o mesmo
webservice pudesse ser apresentado em vrios formatos, como HTML, XML e JSON. Por
exemplo, em XML, o mesmo recurso poderia ser acessado apenas acresentando a extenso
.xml.
Para que isso alcanasse os objetivos, era necessrio fornecer mtodos de interao com o
cliente adaptveis ao formato. No caso de quando estamos apresentando em formato
2

Nmero de cadastro do rgo de classe.

HTML, desejamos que tenhamos um formulrio para login. Porm, quando queremos em
outro formato, podemos passar as informaes por requisio HTTP.

Figura 1 Interao no modo HTML

Figura 2 Interao usando requisio HTTP

Isso permite no somente que a nossa aplicao use o webservice mas, que outras
aplicaes futuras possam utilizar tambm oferecendo uniformidade e reduo de
custos.
A seguir podemos ver como ficariam os dados aprensentados no formato html, xml e json
apenas mudando a extenso.

Figura 3 Dados no formato HTML

Figura 4 Dados no formato XML

Figura 5 Dados no formato JSON

Cada exame dava acesso a dois tipos de visualizaes:


a) pronturio; e
b) laudo evolutivo.
No primeiro caso, apareciam as informaes detalhadas do exame em questo e no
segundo as informaes resumidas dos ltimos 4 exames. Tudo isso estava embaralhado
no banco de dados, por exemplo, as unidades de medida e os valores de referncia
estavam numa tabela, os resultados do exame estavam em outro, os exames que
pertenciam ao mesmo paciente em outra.
O webservice j deveria montar tudo e entregar da maneira mais prtica para o uso e para
isso foi necessrio fazer um estudo minuncioso da estrutura j existente.

Figura 6 Acesso do Pronturio de um Exame

Figura 7 Acesso do Laudo Evolutivo (compilao) de um Exame

Outro ponto importante que a URL de acesso aos recursos foi pensada respeitando o
padro REST3. Por exemplo:
URL/Exame, mostra todos os exames daquele paciente/mdico;
URL/Exame/nmero/Pronturio, acessa o pronturio de determinado exame;
URL/Exame/nmero/Laudo, acessa o laudo evolutivo de determinado exame.
3

REST o uso inteligente da URL deixando ela inteligvel para seres humanos

Se um exame for acessado no estiver disponvel para aquele login, no somente o exame
no estar disponvel como seus recursos derivados tambm estaro salvaguardados.

Figura 8 Negao de acesso para determinado login

Recursos adicionais de ordenao e paginao tambm foram implementados usando a


filosofia REST.
A paginao permite no s informar a pgina desejada mas, tambm a quantidade de
itens por pgina. Esse recurso no til somente para melhorar a visualizao mas,
tambm para poupar recursos do servidor.

Figura 9 A paginao indicada por mtodo GET, informando a pgina e a janela

Para ordenao, usamos o nome da coluna a ser ordenada junto com o caractere !. Se o
ponto de exclamao vier antes do nome da coluna, a ordem crescente; enquanto que, se
vier depois, decrescente.

Figura 10 Ordenao Crescente

Figura 11 Ordenao Decrescente

Parte 2
Aplicao
O formato de apresentao final para o usurio era o PDF. Aps se identificar, o cliente
tinha acesso as informaes coletadas do webservice, porm, processadas no formato PDF.

Figura 12 Apresentao dos dados do webservice em PDF

Primeiramente, vemos que existe um cabealho contendo cdigos de barras, o logo da


clnica e tambm informaes gerais sobre o exame. Tudo isso podendo ser salvo, em um
desktop ou em um dispositivo mobile, ou impresso pelo usurio.
Tambm vemos que o formato antigo RTF foi interpretado e apresentado no formato PDF,
mantendo inclusive a formatao de tamanhos, tabulao, e peso da fonte.

Figura 13 Detalhes da formatao: tamanho da fonte, tabulao e negrito

Aqui vemos a parte do laudo evolutivo:

Figura 14 Laudo evolutivo adicionado ao final do exame

Concluso
Resultados & Feedback
Todos os resultados propostos e desafios apresentados foram conquistados. A maior
dificuldade do projeto foi entender a base de dados j existente, a qual no tive acesso a
relatrios do projeto anterior.
Alm disso, o script da aplicao deveria fazer toda a renderizao (e obteno dos dados)
em menos de 30 segundos para no sobrecarregar o servidor. Aps muitas optimizaes,
chegamos em 3 segundos de processamento.
Apesar da grande experincia adquirida, a maior insatisfao do cliente foi a demora para
desenvolver o projeto, tanto na parte 1 quando na parte 2, o prazo estipulado foi
ultrapassado. Ainda sim, o cliente ponderou que havia pouca informao disponvel e
inclusive conflituosa ou imprecisa que rederam vrias horas de retrabalho.
O cliente aprovou a qualidade e o nvel de tecnologia empregado no projeto, trazendo
recursos bem atuais.

Contato
joao.felipe.c.b@gmail.com