UNIVERSIDADE FEDERAL FLUMINENSE

EDSON BATISTA DOS SANTOS JUNIOR

IMPLEMENTANDO DOMAIN-DRIVEN DESIGN

NO DESENVOLVIMENTO JAVASCRIPT

Niterói
2016
 EDSON BATISTA DOS SANTOS JUNIOR

IMPLEMENTANDO DOMAIN-DRIVEN DESIGN

NO DESENVOLVIMENTO JAVASCRIPT

Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólo-
go em Sistemas de Computação.

Orientador:
Jean de Oliveira Zahn

NITERÓI
2016
Ficha Catalográfica elaborada pela Biblioteca da Escola de Engenharia e Instituto de Computação da UFF

S237 Santos Junior, Edson Batista dos

Implementando Domain-Driven Design no desenvolvimento
Javascript / Edson Batista dos Santos Junior. – Niterói, RJ : [s.n.],
2016.
55 f.

Projeto Final (Tecnólogo em Sistemas de Computação) –

Universidade Federal Fluminense, 2016.
Orientador: Jean de Oliveira Zahn.

1. Engenharia de software. 2. Aplicação web. 3. Sistema de

gestão integrada. 4. Administração de serviço de saúde. I. Título.

CDD 005.1
 EDSON BATISTA DOS SANTOS JUNIOR

IMPLEMENTANDO DOMAIN DRIVEN DESIGN

NO DESENVOLVIMENTO JAVASCRIPT

Trabalho de Conclusão de Curso subme-

tido ao Curso de Tecnologia em Siste-
mas de Computação da Universidade
Federal Fluminense como requisito par-
cial para obtenção do título de Tecnólo-
go em Sistemas de Computação.

Niterói, 22 de dezembro de 2016.

Banca Examinadora:
_________________________________________
Prof. Jean de Oliveira Zahn, MSc. – Orientador
UFF – Universidade Federal Fluminense

_________________________________________
Prof. Gleiph Ghiotto Lima de Menezes, DSc. – Avaliador
UFF – Universidade Federal Fluminense
Dedico este trabalho a todos que me incenti-
varam e apoiaram nesta jornada que é o
aprendizado.
AGRADECIMENTOS

A Deus, que sempre iluminou a minha cami-

nhada.

A meu Orientador Jean Zahn pelo estímulo e

atenção que me concedeu durante o curso.

A todos os meus familiares e amigos pelo

apoio e colaboração. E em especial a minha
querida esposa Bianca pelo apoio e compre-
ensão em todos os momentos.
“Faça o que puder, com o que tem, onde es-
tiver”.
Theodore Roosevelt
 RESUMO

Este trabalho tem por objetivo mostrar que o uso da metodologia Domain-
Driven Design com a linguagem de programação JavaScript torna possível a criação
de sistemas que expressam o conhecimento do domínio com um custo relativamente
baixo, de forma a atender às demandas da sociedade no que tange a busca por ser-
viços públicos de qualidade nas mais diversas áreas, como por exemplo, a área da
saúde. Com base em notícias divulgadas em órgãos de imprensa, o trabalho expõe
a situação de calamidade do gerenciamento das filas cirúrgicas. Explica o funciona-
mento de uma fila cirúrgica e sua diferença em comparação com outros tipos de fila,
e apresenta o conceito de prioridade/urgência baseado num sistema internacional de
classificação de gravidade do estado de saúde do paciente. Propõe o uso de um
serviço integrado de gerenciamento desenvolvido com a utilização de uma metodo-
logia e tecnologias fundamentadas na literatura de engenharia de software, discor-
rendo sobre as escolhas de cada uma delas a despeito das demais. Por último,
apresenta as conclusões formuladas durante o desenvolvimento do serviço e sugere
melhorias para as próximas versões.

Palavras-chaves: Domain-Driven Design, JavaScript e Filas cirúrgicas.

 LISTA DE ILUSTRAÇÕES

Figura 1: As camadas do DDD . ................................................................................ 26

Figura 2: Dado Formatado em XML...........................................................................28
Figura 3: Dado Formatado como JSON.....................................................................28
Figura 4: Etapas da Comunicação de um Serviço Web do Tipo SOAP.....................29
Figura 5: Exemplo de Funcionamento do JBoss........................................................31
Figura 6: Exemplo de Código Fonte em TypeScript...................................................34
Figura 7: Exemplo de Código Fonte JavaScript Transpilado de Código Fonte em
TypeScript..................................................................................................................35
Figura 8: Caso de Uso Cadastrar Paciente................................................................36
Figura 9: Caso de Uso Cadastrar Oferta de Cirurgia.................................................38
Figura 10: Caso de Uso Selecionar Paciente para Cirurgia.......................................40
Figura 11: Caso de Uso Informar Realização de Cirurgia..........................................42
Figura 12: Caso de Uso Informar Cancelamento de Cirurgia....................................43
Figura 13: Diagrama de Classes de Domínio............................................................45
Figura 14: Diagrama de Classes de Aplicação..........................................................46
Figura 15: Diagrama de Classes de Serviço..............................................................47
Figura 16: Aplicativo Postman....................................................................................48
Figura 17: Exemplo de Requisição de Lista de Pacientes.........................................49
Figura 18: Exemplo do Retorno do Início da Lista de Pacientes................................50
Figura 19: Exemplo do Retorno do Final da Lista de Pacientes................................50
Figura 20: Exemplo da Requisição para Alterar o Status de uma Cirurgia................51
Figura 21: Exemplo do Retorno da Requisição para Alterar o Status de uma Cirur-
gia...............................................................................................................................51
 LISTA DE ABREVIATURAS E SIGLAS

API – Application Programming Interface

ASA – American Society of Anesthesiologist
DDD – Domain-Driven Design
DPU – Defensoria Pública da União
ECMA – European Computer Manufacturer’s Association
HTML – Hypertext Markup Language
HTTP – Hypertext Transfer Protocol
IIS – Internet Information Service
JSON – JavaScript Object Notation
NPM – Node.js Package Manager
REST – Representational State Transfer
SOAP – Simple Object Access Protocol
SUS – Sistema Único de Saúde
UDDI – Universal Description, Discovery and Integration
UML – Unified Modeling Language
WSDL – Web Service Description Language
XML – Extensible Markup Language
 SUMÁRIO

RESUMO..................................................................................................................... 8
LISTA DE ILUSTRAÇÕES .......................................................................................... 9
LISTA DE ABREVIATURAS E SIGLAS .................................................................... 10
1 INTRODUÇÃO ................................................................................................... 13
2 TRABALHOS RELACIONADOS ........................................................................ 15
3 FUNDAMENTAÇÃO TEÓRICA .......................................................................... 18
3.1 O PROBLEMA ............................................................................................. 18
3.2 FILA CIRÚRGICA......................................................................................... 19
3.2.1 CRITÉRIOS DE PRIORIDADE EM FILAS CIRÚRGICAS ..................... 19
3.2.2 GERENCIAMENTO DE FILAS CIRÚRGICAS ATUAL .......................... 21
3.2.3 VANTAGENS NA UTILIZAÇÃO DE UM SERVIÇO INTEGRADO DE
GERENCIAMENTO DE FILAS CIRÚRGICAS ................................................... 22
4 FERRAMENTAS, ANÁLISE E PROJETO DO SISTEMA ................................... 23
4.1 METODOLOGIA DE DESENVOLVIMENTO ................................................ 23
4.1.1 DOMAIN-DRIVEN DESIGN ................................................................... 24
4.2 TECNOLOGIAS UTILIZADAS ...................................................................... 27
4.2.1 SERVIÇO WEB ..................................................................................... 27
4.2.2 LINGUAGEM JAVASCRIPT E FRAMEWORKS .................................... 30
4.2.3 TYPESCRIPT ........................................................................................ 33
4.2.4 BANCO DE DADOS MYSQL ................................................................. 35
4.3 ANÁLISE E PROJETO DO SISTEMA .......................................................... 35
4.3.1 CASOS DE USO ................................................................................... 36
4.3.1.1 CADASTRAR PACIENTE ............................................................... 36
4.3.1.2 CADASTRAR OFERTA DE CIRURGIA .......................................... 38
4.3.1.3 SELECIONAR PACIENTE PARA CIRURGIA ................................. 40
4.3.1.4 INFORMAR REALIZAÇÃO DE CIRURGIA ..................................... 42
4.3.1.5 INFORMAR CANCELAMENTO DE CIRURGIA .............................. 43
 4.3.2 DIAGRAMAS DE CLASSES .................................................................. 44
4.3.2.1 CLASSES DE DOMÍNIO ................................................................. 44
4.3.2.2 CLASSES DE APLICAÇÃO ............................................................ 45
4.3.2.3 CLASSES DE SERVIÇO................................................................. 47
5 SERVIÇO DE GERENCIAMENTO DE FILAS CIRÚRGICA ............................... 48
5.1 OBTENDO LISTA DE PACIENTES POR PROCEDIMENTO
AGUARDADO...... .................................................................................................. 49
5.2 INFORMANDO A REALIZAÇÃO DE UMA CIRURGIA ................................ 51
6 CONCLUSÕES E TRABALHOS FUTUROS ...................................................... 53
7 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................... 54
 13

1 INTRODUÇÃO

A linguagem de programação JavaScript foi inicialmente criada como parte

de browsers web de forma a fazer com scripts, geralmente de alteração de conteúdo
das páginas, pudessem ser executados no cliente sem nenhum, ou com um mínimo,
processamento no lado servidor [1].
Com a criação do compilador V81 pela Google, o código JavaScript anteri-
ormente interpretado, passou a ser compilado em código nativo, podendo ser execu-
tado sem a necessidade de um browser.
Devido as suas potencialidades, dentre as quais podemos destacar o pro-
cessamento assíncrono, esta linguagem vem sendo amplamente utilizada no desen-
volvimento no lado servidor.
O presente trabalho busca focar nos aspectos funcionais do desenvolvi-
mento apresentando os conceitos centrais do Domain-Driven Design, e como im-
plementá-los em JavaScript fazendo o uso de frameworks, que abstraiam as peculia-
ridades da linguagem e facilitem o desenvolvimento. Cada framework utilizado terá o
seu uso justificado, bem como as razões que implicaram na sua escolha em detri-
mento de outros que porventura forneçam funcionalidades semelhantes.
O projeto usado para exemplificar o uso do Domain-Driven Design, é uma
proposta de API REST para atender uma demanda do mundo real com requisitos e
regras de negócio formuladas por especialistas do domínio.
No capítulo 2 são apresentados os trabalhos relacionados ao tema, listan-
do os principais livros de Domain-Driven Design e como a linguagem JavaScript foi
preterida na escolha de linguagens para exemplificar seus conceitos.
No capítulo 3 é apresentado a metodologia de gerenciamento de uma fila
cirúrgica que é o exemplo utilizado neste trabalho.

1 V8 é um engine JavaScript de alta performance mantido sobre um projeto de código aberto da Goo-
gle, escrito na linguagem C++ e usado no Chromium, Node.js e várias outras aplicações embarcadas
(https://developers.google.com/v8/).
 14

No capítulo 4 são descritas as tecnologias e metodologia adotadas no de-

senvolvimento da solução proposta, bem como a análise de sistema realizada, com
os diagramas UML de casos de uso, tabelas de especificação de casos de uso e
diagramas de classes dos objetos do sistema.
No capítulo 5 é feita uma pequena demonstração da operação do serviço
web criado para o gerenciamento das filas cirúrgicas.
No capítulo 6 são apresentadas as conclusões formuladas durante o proje-
to da solução e os trabalhos futuros relacionados ao tema deste trabalho.
 15

2 TRABALHOS RELACIONADOS

Desde a publicação do livro Domain-Driven Design: Trackling Complexity

in Software [2], de Eric Evans em agosto de 2003, onde um projeto de aplicação de
reserva de cargas em viagens de navio utilizando a linguagem Java é usado para
apresentar os conceitos desta abordagem de desenvolvimento de software. Nos pa-
rágrafos seguintes, veremos os principais livros que foram lançados sobre o tema,
em ordem cronológica de lançamento. Em sua grande maioria, eles apenas aplicam
os conceitos já formulados às novidades tecnológicas surgidas com o passar do
tempo.
No livro Applying Domain-Driven Design and Patterns: With Examples in
C# and .Net [3], de maio de 2006, o autor Jimmy Nilsson discorre sobre a aplicação
dos padrões arquiteturais do Domain-Driven Design num projeto de gerenciamento
de pedidos na linguagem .Net com framework 2.0, em contraposição a linguagem
Java usada por Evans em seu livro.
Em .Net Domain-Driven Design with C#: Problem – Design – Solution [4],
de abril de 2008, Tim McCarthy usa a migração de um sistema de administração de
projetos de construção, criado originalmente em Microsoft Access para mostrar co-
mo o Domain-Driven Design facilitou este processo. Como o título deixa claro, tam-
bém foi utilizada a linguagem .Net, agora com o framework 3.5, com recursos como
o LINQ, ADO .Net Entity Framework, Windows Communication Foundation e Win-
dows Presentation Foundation.
No final de dezembro de 2009, Dan Haywood lançou o livro Domain-
Driven Design Using Naked Objects [5], onde usa um projeto de aplicação de geren-
ciamento de oficina mecânica para explorar os principais conceitos do Domain-
Driven Design. Naked Objects é um framework para automação de tarefas de de-
senvolvimento de sistemas, como, por exemplo, a criação das camadas de interface
com o usuário e de interface com o banco de dados, utilizando o ORM Hibernate,
baseadas num modelo de domínio. A linguagem de programação utilizada é o Java.
Já em Implementing Domain-Driven Design [6], de fevereiro de 2013, uma
aplicação de gerenciamento de projetos baseado em Scrum, é o exemplo utilizado
por Vaughn Vernon. Neste livro, além de avanços tecnológicos como o armazena-
 16

mento NoSQL, também são apresentados estilos arquiteturais como REST, CQRS,
Arquitetura Hexagonal, e uma novidade específica do Domain-Driven Design - os
Eventos de Domínio. O autor escolhe a linguagem Java, de forma consciente, como
ele mesmo declara, para “inspirar a comunidade Java a retornar à modelagem de
domínio fornecendo uma quantidade razoável de ideias de como as técnicas de pro-
jeto sólidas, porém ágeis e rápidas, podem beneficiar o trabalho deles”.
Em Patterns, Principles and Practices of Domain-Driven Design [7], de
maio de 2015, Scott Millet faz uso de uma aplicação de comércio eletrônico para se
aprofundar nos conceitos do Domain-Driven Design. Neste livro é dada uma ênfase
nas questões de integração entre aplicações, com o uso de Mensageria, RPC e
REST. Mais uma vez, a linguagem de programação .Net é usada na aplicação
exemplo.
Como observado, todos os livros citados utilizam-se das linguagens de
programação Java ou .Net para exemplificar os conceitos e padrões desta aborda-
gem de desenvolvimento de software. A preferência por estas linguagens não nos
causa estranheza ao levarmos em consideração o ranking de linguagens mais utili-
zadas publicado anualmente pela TIOBE Software BV [8], onde elas figuram entre as
primeiras colocadas por vários anos seguidos.
Nos últimos anos com o advento da Internet e dos dispositivos móveis, a
linguagem JavaScript passou por uma enorme popularização, tendo passado inclu-
sive a ser utilizada no Back-End e não apenas no Front-End, vide Node.js2, e até em
bancos de dados, vide PouchDB3. Com isto, é cada dia mais comum que aplicações
usem apenas o JavaScript como linguagem de programação, são as chamadas apli-
cações isomórficas.
Esta utilização do JavaScript na programação Back-End trouxe uma gran-
de questão: por que não utilizar uma abordagem de desenvolvimento já consagrada
como o Domain-Driven Design também com o JavaScript?

2 Node.js é uma plataforma JavaScript construída com a engine JavaScript V8 da Google

(https://nodejs.org/en/).
3 PouchDB é um banco de dados JavaScript de código aberto que foi projetado para ser executado
dentro de um navegador web (https://pouchdb.com/).
 17

No final de julho de 2015 foi publicado um livro sobre este tema, Java-
Script Domain-Driven Design [9], de Phillipp Fehre. Neste livro, o autor faz uso de
um sistema de gerenciamento de transferência entre prisioneiros de masmorras con-
troladas por orcs (seres demoníacos dos contos de fantasia medievais popularizados
nas obras do escritor J.R.R. Tolkien [10]) para exemplificar o uso dos principais con-
ceitos do Domain-Driven Design. Apesar da didática utilizada, que busca explicar de
forma simples os conceitos, há um esforço em aprofundar-se em detalhes peculiares
da linguagem quanto a orientação a objetos, que é um dos pilares do Domain-Driven
Design, que já estão superados com a utilização do framework de desenvolvimento
TypeScript.
Diferente deste último trabalho que apesar de falar tanto de Domain-
Driven Design quanto JavaScript, este trabalho pretende demonstrar como Domain-
Driven Design pode ser utilizado para o desenvolvimento de uma aplicação JavaS-
cript que forneça uma solução para um problema real: o gerenciamento de filas ci-
rúrgicas no âmbito do Sistema Único de Saúde (SUS)4. Durante a evolução do
mesmo, pretende-se demonstrar como as boas práticas descritas no Domain-Driven
Design deram suporte para um correto entendimento do problema a ser resolvido,
bem como possibilitaram um desenvolvimento de uma solução consistente e escalá-
vel em um intervalo de tempo satisfatório.

4 Sistema de saúde pública da República Federativa do Brasil. Busca atender a população, desde
atendimentos simples (e.g., atendimentos ambulatoriais) até atendimentos mais complexos (e.g.,
transplante de órgãos), garantindo acesso integral, universal e gratuito para toda a população do país
(http://www.portalsaude.saude.gov.br).
 18

3 FUNDAMENTAÇÃO TEÓRICA

O Domain-Driven Design trata essencialmente da modelagem de siste-

mas baseada na abstração dos conceitos do mundo real. Desta forma, para enten-
der a mecânica desta metodologia torna-se necessária a modelagem de um sistema
de software que atenda a uma demanda do mundo real. Neste trabalho foi escolhido
um serviço web para gerenciamento de filas cirúrgicas nas unidades do SUS.
A organização e gestão de filas é uma atividade trivial, especialmente no
âmbito computacional, mas quando inserimos outras variáveis além da ordem de
inserção do elemento como fatores complicadores dessa gestão, sobretudo ao lidar
com vidas humanas, é necessária uma atenção redobrada para inibir inconsistências
e evitar que alguma destas vidas seja posta em risco. O gerenciamento de filas ci-
rúrgicas é um destes casos.
Além do fator tempo de espera, existem outros fatores que devem ser le-
vados em consideração ao tratar do gerenciamento de uma fila cirúrgica, tais como:
(i) procedimento a ser realizado, (ii) gravidade do estado de saúde do paciente, (iii)
disponibilidade de vagas para atendimento e (iv) idade do paciente.

3.1 O PROBLEMA

Uma das maiores dificuldades enfrentadas pelos pacientes do SUS é a

demora na realização de cirurgias. Alguns pacientes chegam a esperar anos por ci-
rurgias, desde as mais simples até as mais complexas. Muitos destes pacientes têm
recorrido várias vezes à Justiça na busca pela garantia dos seus direitos, que são
assegurados pela Constituição Brasileira, que estabelece que “A saúde é direito de
todos e dever do Estado, garantido mediante políticas sociais e econômicas que vi-
sem à redução do risco de doença e de outros agravos e ao acesso universal e igua-
litário às ações e serviços para sua promoção, proteção e recuperação” [11] e com-
plementados pela lei orgânica 8080, que regulamenta as diretrizes do SUS e garante
o acesso universal da população aos serviços de saúde [12].
 19

Segundo a Defensoria Pública da União (DPU), existiam, em maio de

2014, mais de 13 mil pacientes aguardando pela realização de cirurgias das mais
diversas especialidades nos Hospitais Federais da Cidade do Rio de Janeiro, dentre
os quais mais de 750 crianças, adolescentes e idosos. Com base nestes dados, foi
impetrada uma Ação Civil Pública (ACP) pela própria DPU que resultou numa deci-
são liminar da 3ª Vara Federal da Seção Judiciária do Rio de Janeiro que obrigou o
Ministério da Saúde a implantar nos Hospitais Federais da Cidade do Rio de Janeiro
um sistema informatizado que possibilitasse o gerenciamento das filas cirúrgicas,
passível de multa de R$ 100 mil (cem mil reais) em caso do não cumprimento desta
determinação [13].
Diante do exposto, tornou-se urgente o desenvolvimento do sistema de-
mandado pela DPU. No entanto, o entendimento do funcionamento de uma fila ci-
rúrgica e de como fazer a integração dos vários órgãos que compõem o SUS no ge-
renciamento desta fila única, bem como o tempo escasso para o desenvolvimento
passaram a ser os principais fatores de complicação para se alcançar uma solução.

3.2 FILA CIRÚRGICA

Para compreender o contexto do serviço proposto, deve-se inicialmente

entender o que vem a ser uma fila cirúrgica e o processo de regulação da mesma.
Uma fila cirúrgica é uma lista ordenada de pacientes que aguardam por um mesmo
atendimento cirúrgico. A ordenação desta fila deve levar em consideração uma série
de fatores que serão relacionados a seguir.

3.2.1 CRITÉRIOS DE PRIORIDADE EM FILAS CIRÚRGICAS

Diferente dos demais tipos de filas que estamos habituados a ver em nos-
so dia-a-dia, onde a ordem de chegada é o principal, senão o único, critério para de-
finir a prioridade de atendimento, numa fila cirúrgica leva-se em consideração, como
 20

os mais relevantes critérios, fatores como a gravidade/urgência na realização do

procedimento cirúrgico, a idade do paciente, a complexidade do procedimento cirúr-
gico e o tempo de espera.
Por gravidade entenda-se o grau de sofrimento, limitações e risco de mor-
talidade que a não realização do procedimento cirúrgico impõe ao paciente. Já o
conceito de urgência considera, além da gravidade, os benefícios que a realização
do procedimento cirúrgico trará ao paciente. Este é o principal fator na priorização da
fila cirúrgica. Como indicativo deste fator, na implantação do serviço, será utilizado o
Sistema de Classificação ASA (American Society of Anesthesiologist) [14].
O Sistema de Classificação ASA possibilita a classificação dos pacientes
pelo seu estado físico em 6 (seis) níveis crescentes de gravidade/urgência, a saber:
 ASA I: paciente sem alterações fisiológicas ou orgânicas, cujo pro-
cesso patológico responsável pela necessidade de cirurgia não
causa problemas sistêmicos.
 ASA II: paciente com alteração sistêmica leve ou moderada relaci-
onada com patologia cirúrgica ou enfermidade geral.
 ASA III: paciente com alteração sistêmica intensa, relacionado com
patologia cirúrgica ou enfermidade geral.
 ASA IV: paciente com distúrbios sistêmicos graves que colocam
em risco a sua vida.
 ASA V: paciente moribundo do qual não é esperada a sobrevivên-
cia sem a realização do procedimento cirúrgico.
 ASA VI: paciente com morte cerebral declarada, cujos órgãos estão
sendo removidos com propósitos de doação.

A idade do paciente também é fator de suma importância ao se definir a

prioridade de atendimento, tendo em vista que idosos e crianças têm sua saúde
mais fragilizada ante a pacientes de outras faixas etárias. Além dos aspectos legais
decorrentes dos Estatutos do Idoso [15], da Criança e do Adolescente [16], que ga-
rantem prioridade para pacientes destes grupos etários.
O critério de complexidade de procedimento leva em consideração diver-
sos subfatores como especialização do profissional que realizará o procedimento,
 21

materiais e equipamentos que serão utilizados na realização do mesmo, e etc. Com

o intuito de simplificar a implementação do serviço, cada procedimento terá sua pró-
pria fila.
O tempo de espera, apesar de não ser o principal fator, como nas filas
mais comuns, não pode ser ignorado. Desta forma será usado como critério de prio-
rização para pacientes que têm o mesmo grau de gravidade/urgência e a mesma
idade.
Um dos principais complicadores na regulação de uma fila cirúrgica está
no fato de que a gravidade/urgência dos pacientes que estão em espera pode ser
alterada no decorrer desta espera. Entre a indicação de um paciente para a cirurgia
e a realização da mesma, vários fatores podem alterar sua classificação inicial. Des-
ta forma, é necessário um acompanhamento constante aos pacientes em espera e a
reavaliação da sua gravidade/urgência.

3.2.2 GERENCIAMENTO DE FILAS CIRÚRGICAS ATUAL

O sistema existente no Hospitais Federais do Estado do Rio de Janeiro, e-

SUS Hospitalar5 [17] apesar de tratar de toda a complexidade de um bloco cirúrgico,
como logística de insumos e equipamentos, e marcação de cirurgias, não trata do
gerenciamento da fila cirúrgica. Este gerenciamento era feito, à época, de forma ma-
nual com o auxílio de planilhas de dados.
Inicialmente, o projeto consistia em implementar este gerenciamento no sis-
tema já existente, mas com o decorrer do levantamento das especificações, verifi-
cou-se que esta abordagem não iria conseguir de uma forma consistente atingir o
objetivo de reduzir o tamanho das filas e diminuir o tempo de espera, devido às in-
formações sobre pacientes e oferta de cirurgias não serem compartilhadas entre os
hospitais.

5 O e-SUS Hospitalar é um software de gestão hospitalar completo, desenvolvido em tecnologia web.

(http://datasus.saude.gov.br/informacoes-de-saude/business-intelligence-bi/e-sus-hospitalar).
 22

3.2.3 VANTAGENS NA UTILIZAÇÃO DE UM SERVIÇO INTEGRADO DE GE-

RENCIAMENTO DE FILAS CIRÚRGICAS

A utilização de um serviço integrado de gerenciamento trará muitas van-

tagens ao processo de regulação das filas cirúrgicas. A integração das informações
de pacientes e oferta de cirurgias possibilitará que pacientes que aguardam cirurgias
em um determinado hospital possam ser atendidos por outro hospital que esteja
ofertando a cirurgia aguardada.
Com a possibilidade da oferta de cirurgias por hospitais de menor porte e
clínicas conveniadas, muitos pacientes, que esperam pela realização de procedi-
mentos de baixa complexidade em hospitais de grande porte, irão se beneficiar com
um atendimento mais rápido.
Tendo uma visão real da quantidade de pacientes em espera, os órgãos
responsáveis pelo gerenciamento dos ativos de saúde poderão agir de maneira mais
eficaz na gestão dos mesmos.
A implantação de um serviço integrado de gerenciamento, possibilitará
aos pacientes, numa futura etapa, o acompanhamento da fila cirúrgica, deixando
clara sua posição na mesma, dando transparência ao processo.
 23

4 FERRAMENTAS, ANÁLISE E PROJETO DO SISTEMA

Um fator crucial na escolha das tecnologias empregadas foi o cenário

atual do uso da tecnologia no SUS. Devido a pluralidade de unidades de saúde que
o compõe, desde hospitais de ponta em grandes centros urbanos a pequenos con-
sultórios em localidades isoladas, não existe um único software que centralize dados
e processos de operação. Há um esforço na produção de um software que supra
esta demanda, o e-SUS Hospitalar, no entanto, ele ainda se encontra numa fase
embrionária. Atualmente, existem vários sistemas com os mais variados propósitos
dentro das unidades de saúde. A introdução de um novo sistema, para o gerencia-
mento de filas cirúrgicas, aumentaria a complexidade do processo, uma vez que os
profissionais de uma unidade de saúde não possuem perfil técnico para utilização de
sistemas, estando treinados e familiarizados com os sistemas existentes.
Desta forma, optou-se pela criação de um produto de software com as
seguintes premissas: facilidade de integração aos sistemas existentes, baixo tráfego
de dados, restrição de acesso aos dados e registro de todas as operações executa-
das.
Para atender estas premissas foram utilizadas a metodologia e as tecno-
logias listadas nas subseções seguintes.

4.1 METODOLOGIA DE DESENVOLVIMENTO

Nesta seção será exposta a metodologia utilizada para o desenvolvimento

deste trabalho. O Domain-Drive Design é a base deste projeto e tem como objetivo
apresentar diretrizes que envolvem o desenvolvimento de software.
 24

4.1.1 DOMAIN-DRIVEN DESIGN

A atividade de desenvolvimento de software é uma das mais ricas em

termos de acúmulo de conhecimento. Um desenvolvedor não aprende apenas os
conceitos técnicos inerentes a sua área de atuação, mas também adquire conheci-
mentos das áreas que utilizarão o software que ele está desenvolvendo. Cada uma
destas áreas tem as suas peculiaridades, com termos e regras específicos. A área
de assunto onde o usuário utilizará o software, com o seu conjunto de peculiarida-
des, termos e regras, é conhecida como domínio do software [2].
Domain-Driven Design, ou DDD, em tradução livre, é Projeto Guiado por
Domínios. Esta metodologia de desenvolvimento de software foi formulada e apre-
sentada em um livro lançado em 2004, por Eric Evans.
O conceito principal do Domain-Driven Design está na utilização da pro-
gramação orientada a objetos para a criação de modelos abstratos que representem
o domínio do negócio da forma mais próxima possível que ele é no mundo real. Se-
gundo o próprio Evans diz em seu livro, deve-se dividir um programa complexo em
camadas, desenvolver um design coeso dentro de cada camada que dependa so-
mente das camadas abaixo dela, seguir padrões de arquitetura que proporcionem
baixo acoplamento com as camadas de cima, e concentrar o código relacionado com
o domínio em uma única camada de forma que ela fique isolada da interface com o
usuário, da camada de aplicação e da infraestrutura. Os objetos de domínio, livres
da responsabilidade de se exibir, de se armazenar, de gerenciar tarefas de aplica-
ção, e assim por diante, podem se concentrar em expressar o domínio. Isso permite
que um modelo evolua para se tornar rico e limpo o suficiente para captar o conhe-
cimento essencial do negócio e colocá-lo em funcionamento.
Para atingir este objetivo são utilizados vários conceitos, dentre os quais
cabe destacar as entidades, os objetos de valor e os padrões de modelagem como
fábricas, repositórios e serviços.
Entidades são objetos que tem um ciclo de vida bem definido no sistema,
e precisam ser identificados de forma inequívoca. Já objetos de valor, como o pró-
prio nome diz, são objetos que armazenam algum valor relevante durante algum
momento no sistema, não necessitando de identificação inequívoca e tendo um ciclo
 25

de vida curtíssimo, sendo facilmente substituíveis por outros objetos de valor de

mesmo tipo.
Fábricas são objetos responsáveis pela criação de outros objetos, geral-
mente complexos, compostos por vários outros objetos. Já repositórios são contai-
ners de objetos, responsáveis pela recuperação destes objetos quando necessários
em alguma atividade do sistema. Os serviços encapsulam métodos de vários objetos
que atuam juntos para a execução de uma tarefa.
Além dos padrões propostos, o Domain-Driven Design define que a lin-
guagem comum aos usuários do domínio seja usada em todas as etapas do desen-
volvimento, estando presente até mesmo no código gerado, favorecendo assim a
comunicação entre as partes e o entendimento de todas as nuances do domínio.
Este uso da linguagem comum é chamado de linguagem ubíqua.
Em termos arquiteturais o Domain-Driven Design define a divisão do sof-
tware em camadas bem definidas, que objetivam a proteção da camada de domínio,
onde ficam as regras de negócio específicas das entidades do domínio.
Uma das grandes vantagens do uso do Domain-Driven Design está no incentivo ao
uso das melhores práticas da programação orientada a objetos, como os princípios
SOLID6 [22].
Os princípios SOLID são:
 Single Responsability (Responsabilidade Única): determina que
cada classe deve ser especializada na resolução de uma única ati-
vidade.
 Open/Close (Aberto/Fechado): define que objetos de software de-
vem ser abertos para extensão e fechados para modificações.
 Liskov Substitution (Substituição de Liskov): formulado por Barbara
Liskov, determina que objetos podem ser substituídos por objetos
derivados deles sem que se altere as características do software.

6 SOLID é um acrônimo introduzido por Michael Feathers para os cinco princípios básicos da progra-
mação orientada a objetos, como assim foram por Robert C. Martin
(https://en.wikipedia.org/wiki/SOLID_(object-oriented_design).
 26

 Interface Segregation (Segregação de Interfaces): sugere que deve

haver várias interfaces específicas ao invés de uma interface de
uso geral.
 Dependency Inversion (Inversão de Dependência): propõe que ob-
jetos dependam de abstrações de outros objetos e não de suas
implementações concretas.

Figura 1: As Camadas do DDD.

A Figura acima apresenta a divisão de camadas proposta pelo Domain-

Driven Design. Esta divisão foi seguida durante o desenvolvimento do sistema pro-
porcionando como uma das principais vantagens, além das citadas anteriormente, a
melhor divisão das atividades pela equipe de desenvolvimento no transcorrer do tra-
balho.
Enquanto um membro da equipe trabalhava na codificação de uma de-
terminada funcionalidade da camada de domínio ou de serviço, por exemplo, outro
membro poderia se focar na codificação de uma funcionalidade na camada de per-
sistência.
Outro aspecto da metodologia Domain-Driven Design que foi de suma im-
portância no desenvolvimento do sistema, foram os Eventos de Domínio, que funci-
 27

onam como um fluxo de ações a serem tomadas pelos objetos do sistema quando
determinados eventos ocorrerem, por exemplo na alteração da gravidade do estado
de saúde de um determinado paciente presente na fila cirúrgica.

4.2 TECNOLOGIAS UTILIZADAS

Nesta seção serão apresentadas as tecnologias envolvidas no software

proposto. Serviços Web, Typescript e banco de dados MySQL são algumas dessas
tecnologias e que serão detalhadas nas seções seguintes.

4.2.1 SERVIÇO WEB

Os sistemas existentes nas unidades de saúde do SUS são heterogêneos

em termos de linguagens de programação e uso de bancos de dados. Desta forma,
a criação de uma base de dados que pudesse ser compartilhada por essas aplica-
ções não se mostrou uma alternativa viável. A alternativa mais atrativa tecnicamente
foi a criação de um serviço web onde os sistemas pudessem inserir e obter dados. O
acesso aos dados somente seria possível se o solicitante fornecesse uma identifica-
ção da unidade de saúde que estivesse realizando aquela operação, tornando pos-
sível assim o registro das operações realizadas, e a limitação das informações que
poderiam ser acessadas. Assim, os requisitos de facilidade de integração, restrição
de acesso e registro de operações seriam atendidos de forma satisfatória.
Um serviço web é um componente de software que é acessado através
da Internet, sendo assim, independente da plataforma computacional e da lingua-
gem de programação do sistema que o consome [18]. Um serviço web oferece pro-
cessamento remoto para que qualquer sistema consiga acessar o seu endereço web
e ao qual seja permitida sua interação, o que possibilita essa facilidade na utilização
de serviços web é o uso de um formato padronizado para o envio de dados e o re-
 28

torno do processamento destes dados. Os principais formatos padrão dos serviços

web são XML e JSON.

Figura 2: Dado Formatado em XML.

XML que é o acrônimo de eXtensible Markup Language, é uma linguagem

de marcação baseada na HTML que permite descrever dados de uma forma estrutu-
rada com o uso de tags [19]. Uma tag é uma palavra contida entre os caracteres < e
>. Enquanto na HTML as tags de marcação são predefinidas, a XML permite que
sejam criadas quaisquer tags que forem necessárias para descrever a informação
que se pretende usar. A estrutura de um documento escrito em XML, define que to-
das as tags devem ser utilizadas em pares, sendo uma tag de abertura e outra de
fechamento. A tag de fechamento deve conter a mesma palavra usada na tag de
abertura sendo precedida do símbolo /. A marcação <nome>José da Silva</nome> é
perfeitamente válida em XML, e define que a propriedade nome contém o valor José
da Silva.

Figura 3: Dado Formatado como JSON.

JSON que é o acrônimo de JavaScript Object Notation, foi criado como

uma alternativa a XML, utilizando a sintaxe do JavaScript para definir objetos [20]. A
grande vantagem no uso de JSON em relação a XML é a redução no tamanho da
estrutura das mensagens. Esta notação faz uso de um formato chave e valor para
descrever as informações. A informação de nome descrita anteriormente em XML,
seria representada em formato JSON como “nome”:”José da Silva”. Neste simples
exemplo tivemos uma redução de 26 para 22 caracteres, em informações complexas
onde exista uma estrutura com vários níveis e subníveis de informação, esta redu-
ção será ainda maior.
 29

Além do formato de dados usado para trafegar informações, um serviço

web possui uma arquitetura que define sua operação. As principais arquiteturas utili-
zadas para a criação de serviços web são SOAP e REST.
SOAP que é o acrônimo de Simple Object Access Protocol, é um protoco-
lo definido pelo W3C, em maio de 2008 [21], que especifica como informações po-
dem ser trocadas por plataformas computacionais heterogêneas e de forma distribu-
ída. O SOAP é fortemente baseado em XML, e fornece um fluxo de operação utili-
zando para isto uma linguagem para descrever os métodos e objetos de serviços
web (WSDL7) e um protocolo que permite que estes serviços sejam expostos para
quem desejar consumi-los (UDDI8).

Figura 4: Etapas da Comunicação de um Serviço Web do Tipo SOAP.

REST que é o acrônimo de Representational State Transfer é um estilo

de arquitetura que utiliza características do protocolo HTTP para definir métodos de
um serviço web, que foi apresentado na tese de doutorado de Roy Fielding em 2000
na Universidade da Califórnia [22]. Diferente do SOAP, onde cada serviço web pode
disponibilizar os mais variados métodos, bastando para isso descrevê-los através da
linguagem WSDL, os métodos de um serviço web baseado em REST são padroni-

7 WSDL, que é o acrônimo de Web Service Description Language, é uma linguagem baseada em
XML utilizada para descrever serviços web funcionando como um contrato do serviço
(https://pt.wikipedia.org/wiki/Web_Services_Description_Language).
8 UDDI, que é acrônimo inglês Universal Description, Discovery and Integration) é um serviço de
diretório onde empresas podem registrar (publicar) e buscar (descobrir) por serviços web
(https://pt.wikipedia.org/wiki/UDDI).
 30

zados e seguem os verbos disponíveis no protocolo HTTP. Além disto, podem ser
usados tanto XML quanto JSON para representar as informações trafegadas.
Tendo em mente a premissa que o serviço web utilizado para atender ao
requisito de gerenciamento de filas cirúrgicas não será exposto publicamente e que
as informações trafegadas devem ter o menor tamanho possível, a arquitetura esco-
lhida foi REST.

4.2.2 LINGUAGEM JAVASCRIPT E FRAMEWORKS

Uma vez definida que a arquitetura da solução será baseada na utilização

de um serviço web e que será adotada a metodologia Domain-Driven Design, se-
guiu-se na escolha da tecnologia sobre a qual o desenvolvimento seria calcado.
Um dos principais fatores levados em consideração foi o parque tecnoló-
gico já existente no Ministério da Saúde. A inserção de novas exigências de hardwa-
re e softwares de infraestrutura seria um complicador, tanto em questão de custos,
como no tempo de desenvolvimento.
O parque tecnológico do Ministério da Saúde, à época do desenvolvimen-
to da solução descrita neste trabalho, possuía servidores em ambiente Microsoft
Windows Server 2012 e CentOS Linux Server com os servidores web Internet Infor-
mation Services (IIS) e Apache HTTP Server, respectivamente. Neste ponto, o custo
foi o determinante, uma vez que os softwares de infraestrutura fornecidos pela Mi-
crosoft possuem um custo considerável comparando-se os softwares de infraestrutu-
ra Linux que são gratuitos. Tendo a infraestrutura definida, chegou a hora de definir
a linguagem de programação a ser utilizada.
As linguagens de programação utilizadas e suportadas no Ministério da
Saúde eram C#, Java e Delphi. A linguagem Delphi foi descartada de imediato devi-
do a sua inadequação para o uso em serviços web. A linguagem C# também foi
descartada devido a escolha da infraestrutura Linux. Restou a linguagem Java que
também foi descartada pelo nível de complexidade que traria a infraestrutura, uma
vez que necessita de um servidor de aplicação. Um servidor de aplicação é um
componente de software de infraestrutura que centraliza vários elementos de softwa-
 31

re e faz a orquestração da comunicação entre eles [24]. A linguagem Java possui

vários componentes para os mais diversos propósitos, como por exemplo, acesso a
banco de dados e geração de páginas em HTML. Um exemplo de um servidor de
aplicação é o JBoss. Na Figura 5 podemos ver um exemplo do funcionamento deste
servidor de aplicação.

Figura 5: Exemplo de Funcionamento do JBoss.

Com todas as linguagens de programação utilizadas sendo descartadas,

foi necessário encontrar uma que não trouxesse complexidade quanto a infraestrutu-
ra e nem tivesse uma curva de aprendizagem grande para não atrasar o desenvol-
vimento, cujo prazo já era bem reduzido. Neste contexto, a linguagem escolhida foi a
JavaScript.
JavaScript é uma linguagem de programação de scripts criada em 1996
pela Netscape para melhorar a experiência do usuário na exibição de páginas web
dinâmicas [1]. Por ter a sintaxe comum ao Java, o nome JavaScript ficou populariza-
do, no entanto, este nome era uma marca registrada da empresa Sun Microsys-
 32

tems9, que também detinha o registro do nome Java. A Netscape submeteu a lin-
guagem para que fosse feita uma padronização pela European Computer Manufac-
turer’s Association (ECMA) e, desta forma, o nome oficial da linguagem é ECMAS-
cript [25].
À primeira vista parece um contrassenso escolher uma linguagem criada
para melhorar a exibição de páginas web para criar um serviço web que, apesar de
ter a possibilidade de fornecê-las, geralmente não fornece páginas web. A resposta
para esta escolha está na plataforma de desenvolvimento JavaScript Node.js.
A plataforma Node.js foi criada no final de 2009 por Ryan Dahl com a aju-
da de 14 colaboradores tomando como base a engine JavaScript V8 da Google [26].
Com o objetivo de tornar o seu navegador web Chrome mais performáti-
co, a Google criou uma engine que permitia compilar o código JavaScript em código
de máquina nativo. Desta forma, já não é mais necessário o uso de um navegador
web para a execução de códigos escritos na linguagem JavaScript.
Node.js possui uma arquitetura não bloqueante baseada em fila de even-
tos que são tratados de forma assíncrona. Eventos são todas as ações que ocorrem
no sistema. Diferente da programação de páginas web dinâmicas onde temos even-
tos como click do mouse e seleção de itens em listas, o Node.js trata de eventos do
entrada e saída no servidor como a conexão de bancos de dados e a abertura de
arquivos. Ao identificar que um evento ocorreu e foi posto em sua fila, o Node.js pro-
cessa esse evento e não aguarda a sua finalização para que possa processar algum
outro evento que ocorra. Isso dá ao Node.js o poder de atender a um grande número
de eventos sem causar um impacto negativo significativo em sua performance. Além
disto, não são necessários requisitos adicionais de infraestrutura, já que a plataforma
Node.js pode ser executada tanto em ambientes Linux quanto em ambientes Win-
dows sem que seja preciso instalar nenhum outro software de infraestrutura.
Por ser uma plataforma de desenvolvimento, o Node.js possui suporte a
diversas bibliotecas e frameworks JavaScript que podem ser instalados para facilitar
o desenvolvimento de funcionalidades específicas. São tantos que existe um geren-
ciador de componentes na plataforma, o Node.js Package Manager (NPM). Este ge-
renciador baseia-se num arquivo de configuração existente no projeto em formato

9 A Sun Microsystems foi adquirida pela Oracle em 2010 (https://www.oracle.com/sun/index.html).

 33

JSON para fazer o download e a instalação dos componentes necessários ao proje-

to, chamados de dependências.
Dentre os muitos frameworks existentes na plataforma, foi escolhido o
Express.js para auxiliar no desenvolvimento do serviço web proposto.
O Express.js é um framework que fornece as funcionalidades de um ser-
vidor de aplicação, tais como tratamento de requisições HTTP, tratamento de exce-
ções e um pipeline de execução baseado em middlewares, que são funções que
podem ser executadas antes ou depois do processamento de uma requisição HTTP,
passando o resultado do seu processamento para o pipeline em execução. Isto se
torna bastante útil no registro das operações realizadas, já que uma função de regis-
tro pode ser inserida no pipeline sem alterar seu processamento.

4.2.3 TYPESCRIPT

Devido a sua utilização já consolidada na programação de páginas web

dinâmicas, a linguagem JavaScript possui uma curva de aprendizado muito peque-
na, o que foi um facilitador no seu uso durante o desenvolvimento. No entanto, sua
característica de ter tipagem fraca e dinâmica, que significa que o tipo de dados de
uma variável pode ser alterado em tempo de execução, se tornou um complicador
ao utilizar a metodologia Domain-Driven Design que é fortemente baseada no para-
digma da programação orientada a objetos. Um objeto possui como característica o
fato de encapsular seus dados protegendo-os de interferências de outros objetos.
Para fornecer essa característica à linguagem JavaScript foi usado o framework
TypeScript.
TypeScript é um superset da linguagem JavaScript criado pela Microsoft
em outubro de 2012 [27]. Um superset é uma implementação que possui todas as
características de algo acrescentando outras funcionalidades, ou seja, toda a sintaxe
e modo de operação do JavaScript também está contido no TypeScript. As funciona-
lidades acrescentadas são a tipagem forte e estática e as classes e interfaces pre-
sentes na linguagem C#, tornando o JavaScript totalmente aderente ao paradigma
da programação orientada a objetos.
 34

Um código escrito em TypeScript não será reconhecido diretamente pelo

Node.js uma vez que as novas funcionalidades fornecidas não existem na linguagem
JavaScript que é a linguagem compreendida pelo Node.js. Desta forma, antes de
processo de compilação do código pelo Node.js é feita uma transpilação do código
TypeScript em código JavaScript. Diferente do processo de compilação onde a partir
de um código fonte é gerado um binário em linguagem de máquina, na transpilação
a partir de um código fonte é gerado outro código fonte. Essa operação não pode ser
descrita como uma conversão, pois numa conversão, na grande maioria das vezes,
os códigos fontes gerados não possuem nenhuma semelhança de sintaxe, como por
exemplo a conversão de um código fonte escrito na linguagem C++ para a lingua-
gem C#.
Na Figura 6 podemos ver um exemplo de um código escrito em TypeS-
cript que cria uma classe com a função de executar uma saudação.

Figura 6: Exemplo de Código Fonte em TypeScript.

Na Figura 7 vemos a versão transpilada do código fonte apresentado na

Figura 6. A semelhança entre eles é enorme, no entanto, deve-se notar o uso das
palavras-chave function e prototype. Esses detalhes de sintaxe poderiam se tornar
um complicador muito grande na escrita do código pelos programadores, tornando o
mesmo propenso a erros de difícil detecção.
 35

Figura 7: Exemplo de Código Fonte JavaScript Transpilado de Código Fonte em TypeScript.

4.2.4 BANCO DE DADOS MYSQL

Seguindo na diretriz de não gerar complexidade em termos de infraestru-

tura, o banco de dados escolhido para a aplicação foi o MySQL que já existia na in-
fraestrutura do Ministério da Saúde e possui integração com o Node.js.
O MySQL é um banco de dados completo, robusto e extremamente rápi-
do, com todas as características existentes nos principais bancos de dados pagos
existentes no mercado [28].
Além destas características, um dos fatores que contribuiu positivamente
com o projeto foi o fato da sintaxe usada nesse banco de dados ser bastante conhe-
cida, uma vez que o mesmo possui licença de uso educacional é, geralmente, o es-
colhido no meio acadêmico para o ensino de bancos de dados.

4.3 ANÁLISE E PROJETO DO SISTEMA

Nas subseções seguintes serão apresentados diagramas que descrevem

o projeto do sistema. Entre eles estão os diagramas de caso de uso e diagramas de
classe. Estes diagramas geralmente são utilizados para transcrever projetos de sis-
temas de software [29].
 36

4.3.1 CASOS DE USO

A linguagem UML10 se utiliza de diagramas e tabelas para representar ca-

sos de uso. Casos de uso são uma técnica para captar os requisitos funcionais de
um sistema, e servem para descrever as interações entre os usuários e o sistema,
fornecendo uma narrativa sobre como o sistema é usado [29].
Os casos de uso descritos abaixo foram formulados após reuniões de
passagem de conhecimento com os especialistas do domínio, e foram utilizados
posteriormente para verificação da adequação do sistema desenvolvido aos requisi-
tos solicitados.

4.3.1.1 CADASTRAR PACIENTE

Este caso de uso descreve a interação de um estabelecimento de saúde

previamente cadastrado, identificado como Hospital responsável pelo Cadastro do
Paciente com o software, identificado como Sistema, para a inclusão das informa-
ções de um novo paciente numa fila cirúrgica.

Figura 8: Caso de Uso Cadastrar Paciente.

Atores
Ator Descrição

10 A linguagem UML (Unified Modeling Language) é uma notação diagramática para desenhar ou
apresentar Figuras relacionadas a software, principalmente, mas não unicamente, sob o paradigma
da orientação a objetos [30].
 37

Hospital responsável
É o estabelecimento de saúde responsável pelo
pelo Cadastro do
Cadastro do Paciente.
Paciente
É o software responsável pela regulação da fila
Sistema
cirúrgica.

Pré-Condição
Hospital responsável pelo Cadastro do Paciente previamente cadastrado no
Sistema.

Fluxo Básico
Regras de
ID Passo Fluxos
Negócio
RN001,
RN002,
Hospital responsável pelo Cadastro do Paciente FE01,
1 RN003,
envia as informações do Paciente ao Sistema FE02
RN004,
RN005
Sistema insere o Paciente na Fila de acordo
2 - RN006
com o critério de prioridade
3 Fim da especificação - -

Fluxos de Exceção
FE01 Token de acesso inválido
Regras
ID Passo de Mensagem
Negócio
O Token de Acesso enviado é
1 - -
inválido.
O Sistema retorna uma mensagem
2 - MSG_E001
de erro.
FE02 As informações do Paciente são inválidas
Regras
ID Passo de Mensagem
Negócio
Uma (ou mais) informação(ões) do
1 - -
Paciente é(são) inválidas.
O Sistema retorna uma mensagem
2 - MSG_E002
de erro.
 38

Mensagens

 MSG_E001 – Token inválido;

 MSG_E002 – Paciente inválido;

Regras de
Negócio
 RN001 – O Hospital responsável pelo Cadastro do Paciente deve ter
sido cadastrado previamente, e ter um token de acesso que deve ser
enviado em todas as interações com o Sistema;
 RN002 – O Paciente deve ter Nome, Código de Cadastro no SUS, Data
de Nascimento, Procedimento que aguarda, Gravidade e Status;
 RN003 – O Procedimento deve fazer parte da tabela de procedimentos
atendidos pelo SUS, e ter uma Complexidade que será Baixa, Média,
Alta ou Crítica;
 RN004 – A Gravidade do Paciente é representada usando a
Classificação ASA;
 RN005 – O Status do Paciente será Aguardando, Encaminhado,
Reagendado ou Liberado;
 RN006 – O Critério de Prioridade leva em consideração a Gravidade do
Paciente, a Idade do Paciente e o Tempo de Espera;

4.3.1.2 CADASTRAR OFERTA DE CIRURGIA

Este caso de uso descreve a interação de um estabelecimento de saúde

previamente cadastrado, identificado como Hospital responsável pela Oferta de Ci-
rurgia, com o software, identificado como Sistema, para a inclusão das informações
de uma oferta de cirurgia.

Figura 9: Caso de Uso Cadastrar Oferta de Cirurgia.

 39

Atores
Ator Descrição
Hospital responsável
É o estabelecimento de saúde responsável pela Oferta
pela Oferta de
de Cirurgia.
Cirurgia
É o software responsável pela regulação da fila
Sistema
cirúrgica.

Pré-Condição
Hospital responsável pela Oferta de Cirurgia previamente cadastrado no
Sistema.

Fluxo Básico
Regras de
ID Passo Fluxos
Negócio
RN007,
Hospital responsável pela Oferta de Cirurgia
FE01, RN008,
1 envia as informações de uma Oferta de
FE03 RN009
Cirurgia.

2 Sistema registra a Oferta de Cirurgia. - -

3 Fim da especificação - -

Fluxos de Exceção
FE03 As informações da Oferta de Cirurgia são inválidas
Regras
ID Passo de Mensagem
Negócio
Uma (ou mais) informação (ões) da
1 - -
Oferta de Cirurgia é(são) inválidas.
O Sistema retorna uma mensagem
2 - MSG_E003
de erro.

Mensagens

 MSG_E003 – Oferta de Cirurgia inválida;

 40

Regras de
Negócio
 RN007 – O Hospital responsável pela Oferta de Cirurgia deve ter sido
cadastrado previamente, e ter um token de acesso que deve ser enviado
em todas as interações com o Sistema;
 RN008 – Uma Oferta de Cirurgia deve ter Procedimento, Data/Hora e
Status;
 RN009 – O Status de uma Oferta de Cirurgia será Agendada, Realizada
ou Cancelada;

4.3.1.3 SELECIONAR PACIENTE PARA CIRURGIA

Este caso de uso descreve a interação software, identificado como Siste-

ma, e de estabelecimentos de saúde previamente cadastrados, identificados como
Hospital responsável pela Oferta de Cirurgia e Hospital responsável pelo Cadastro
do Paciente, com o software, identificado como Sistema, para a consulta das infor-
mações de pacientes selecionados para as cirurgias ofertadas anteriormente.

Figura 10: Caso de Uso Selecionar Paciente para Cirurgia.

 41

Atores
Ator Descrição
É o software responsável pela regulação da fila
Sistema
cirúrgica.
Hospital responsável
É o estabelecimento de saúde responsável pela Oferta
pela Oferta de
de Cirurgia.
Cirurgia
Hospital responsável
É o estabelecimento de saúde responsável pelo
pelo Cadastro do
Cadastro do Paciente.
Paciente

Pré-Condição
Hospital responsável pela Oferta de Cirurgia previamente cadastrado no
Sistema.
Hospital responsável pelo Cadastro do Paciente previamente cadastrado no
Sistema.

Fluxo Básico
Regras de
ID Passo Fluxos
Negócio
O Sistema informa ao Hospital responsável
-
1 pelo cadastro do Paciente os dados da Cirurgia -
Ofertada.
O Sistema altera o Status do Paciente para
2 - -
Encaminhado.
O Hospital responsável pela Oferta de Cirurgia
3 - -
obtém pacientes selecionados.
O Hospital responsável pelo Cadastro do
4 Paciente obtém o encaminhamento dos - RN010
Pacientes selecionados.
5 Fim da especificação - -

Regras de
Negócio
 RN010 – O Hospital responsável pelo cadastramento do Paciente será
responsável por encaminhar o Paciente à Cirurgia Ofertada;
 42

4.3.1.4 INFORMAR REALIZAÇÃO DE CIRURGIA

Este caso de uso descreve a interação do estabelecimento de saúde,

identificado como Hospital, responsável pela Oferta de Cirurgia, com o software,
identificado como Sistema, para informar a realização de uma cirurgia.

Figura 11: Caso de Uso Informar Realização de Cirurgia.

Atores
Ator Descrição
Hospital responsável
É o estabelecimento de saúde responsável pela Oferta
pela Oferta de
de Cirurgia.
Cirurgia
É o software responsável pela regulação da fila
Sistema
cirúrgica.

Pré-Condição
Hospital responsável pela Oferta de Cirurgia previamente cadastrado no
Sistema.

Fluxo Básico
Regras de
ID Passo Fluxos
Negócio
Hospital responsável pela Oferta de Cirurgia RN011
1 -
informa a realização da Cirurgia.
Sistema altera o Status do Paciente para
2 - -
Atendido.
3 Sistema retira o Paciente da Fila. - RN012
4 Fim da especificação - -
 43

Regras de
Negócio
 RN011 – Uma vez realizada a Cirurgia, o Hospital responsável pela
Oferta da Cirurgia deve informar sua realização;
 RN012 – O Sistema deve retirar da Fila o Paciente que foi atendido.

4.3.1.5 INFORMAR CANCELAMENTO DE CIRURGIA

Este caso de uso descreve a interação de um estabelecimento de saúde

previamente cadastrado, identificado como Hospital responsável pela Oferta de Ci-
rurgia, com o software, identificado como Sistema, para informar o cancelamento de
uma cirurgia ofertada anteriormente.

Figura 12: Caso de Uso Informar Cancelamento de Cirurgia.

Atores
Ator Descrição
Hospital responsável
É o estabelecimento de saúde responsável pela Oferta
pela Oferta de
de Cirurgia.
Cirurgia
É o software responsável pela regulação da fila
Sistema
cirúrgica.

Pré-Condição
Hospital responsável pela Oferta de Cirurgia previamente cadastrado no
Sistema.

Fluxo Básico
 44

Regras de
ID Passo Fluxos
Negócio
Hospital responsável pela Oferta de Cirurgia RN013
1 -
informa o Cancelamento da Cirurgia.
Sistema altera o Status do Paciente para
2 - -
Aguardando.
3 Sistema realoca o Paciente na Fila. - RN014
4 Fim da especificação - -

Regras de
Negócio
 RN013 – Se a Cirurgia for cancelada, o Hospital responsável pela Oferta
da Cirurgia deve informar seu cancelamento;
 RN014 – O Sistema deve realocar o Paciente na Fila.

4.3.2 DIAGRAMAS DE CLASSES

Dentre os diagramas propostos na UML está o diagrama de classes que

especifica as entidades do sistema, bem como suas propriedades e funcionalida-
des/métodos através de caixas retangulares.
Estas caixas retangulares são divididas em 3 partes verticalmente. Na
parte superior será posto o nome da classe, na parte central serão definidas suas
características, e na parte inferior estarão as suas funcionalidades.

4.3.2.1 CLASSES DE DOMÍNIO

O diagrama da Figura 13 descreve as classes das entidades definidas em

Domain-Driven Design como o domínio do sistema.
Tanto os nomes das classes como os das suas funcionalidades buscaram
se ater a linguagem ubíqua dos especialistas do sistema. Pode-se notar o termo
 45

Hospital, que de maneira formal deveria ser Unidade de Atendimento, uma vez que
algumas cirurgias, devido à sua baixa complexidade, poderiam ser realizadas em
clínicas e ambulatórios, no entanto, os especialistas sempre se referem à elas como
Hospitais, motivo pelo qual isto foi assim representado no código-fonte. Outro ponto
que deve ser considerado, em relação a isto, são os nomes das entidades e méto-
dos em português. Havia na equipe de desenvolvimento o desejo de utilizar o inglês
como idioma de escrita do código-fonte, devido a sua familiaridade com o mesmo

Figura 13: Diagrama de Classes de Domínio.

por conta das palavras reservadas da linguagem JavaScript serem neste idioma,
mas chegou-se ao consenso de que isto feriria a linguagem ubíqua.

4.3.2.2 CLASSES DE APLICAÇÃO

O diagrama da Figura 14 mostra a representação das classes de aplica-

ção do sistema.
 46

As classes de aplicação funcionam como fachadas11 para operações

CRUD12 geralmente executadas no banco de dados sobre as entidades de domínio.

Figura 14: Diagrama de Classes de Aplicação.

11 Fachada ou Façade é um padrão de projeto que fornece uma interface alternativa para um objeto,
geralmente ocultando sua complexidade dos seus usuários [31].
12 CRUD é o acrônimo de CREATE (criar), READ (ler), UPDATE (atualizar) e DELETE (excluir) na
língua inglesa para as quatro operações básicas utilizadas em bases de dados relacionais (RDBMS)
ou em interface para utilizadores para criação, consulta, atualização e destruição de dados
(https://pt.wikipedia.org/wiki/CRUD).
 47

4.3.2.3 CLASSES DE SERVIÇO

O diagrama da Figura 15 mostra a representação das classes de serviço

do sistema.
As classes de serviço, assim como as classes de aplicação, funcionam
como fachadas, no entanto, diferentemente destas últimas, cada classe de serviço
pode se referenciar à várias entidades de domínio. Um exemplo disto é o serviço
ObterEncaminhamentoPacientesSelecionados que obtém os encaminhamentos dos
pacientes selecionados de um determinado hospital para um tipo específico de cirur-
gia.
São nas classes de serviço que são orquestrados os fluxos dos eventos
de domínio devido ao acesso que estas classes tem as várias entidades. Um exem-
plo disto, é o serviço InformarRealizaçãoCirurgia, que atualiza o status da cirurgia e
retira os pacientes da fila, atualizando a posição dos outros pacientes.

Figura 15: Diagrama de Classes de Serviço.

 48

5 SERVIÇO DE GERENCIAMENTO DE FILAS CIRÚRGICA

Diferente de aplicações que possuem uma interface de usuário com a

exibição de elementos visuais, um serviço web não fornece nenhum retorno que seja
usualmente exibido ao usuário.
Para demonstrar a operação do serviço web de gerenciamento de filas ci-
rúrgicas foi utilizado o software Postman13, que é fornecido como uma extensão do
navegador web Chrome ou como um aplicativo para o sistema operacional OSX14. O
Postman permite que se construa requisições HTTP para URL de APIs REST e exi-
be os retornos destas requisições.

Figura 16: Aplicativo Postman.

Serão apresentados em seguidas algumas requisições enviadas ao servi-

ço web de gerenciamento de filas cirúrgicas, e seus respectivos retornos.

13 Postman é uma ferramenta para a execução de testes de APIs baseados na construção de requisi-
ções HTTP fornecida pela empresa Postdot Tecnologies (http://www.getpostman.com).
14 OSX é um sistema operacional baseado em Unix utilizado nos computadores pessoais da Apple
(http://www.apple.com/macos/sierra).
 49

5.1 OBTENDO LISTA DE PACIENTES POR PROCEDIMENTO AGUARDADO

A Figura 17 apresenta um exemplo de requisição construída com o Post-

man para a obtenção da lista de pacientes que aguarda para realizar uma cirurgia
para o tratamento de varizes.

Figura 17: Exemplo de Requisição de Lista de Pacientes.

O domínio da URL foi ocultado por motivos de segurança, bem como o Id

da unidade de saúde que está realizando a requisição no cabeçalho da mesma.
A segurança da aplicação é baseada na inclusão do Id da unidade de sa-
úde e de um hash15 que é gerado com o uso deste Id, do conteúdo do corpo da re-
quisição, e de uma senha previamente fornecida à unidade de saúde. O mesmo pro-
cesso de geração do hash executado pela unidade de saúde é executado pelo ser-
viço web quando recebe a requisição para que seja garantida tanto a integridade da
requisição como confirmado o seu remetente.
Ao receber a requisição do exemplo acima, o serviço web realiza a verifi-
cação de segurança e responde com o retorno de processamento mostrado nas Fi-
guras 18 e 19. A demonstração do retorno foi dividida em duas Figuras devido a
quantidade de registros retornados.

15 A criptografia hash permite que, através de uma string de qualquer tamanho, seja calculado um
identificador digital de tamanho fixo. Uma função hash é dita “one-way” pois uma vez obtido o valor
hash h para uma string x, é computacionalmente impossível fazer o processo inverso, ou seja, encon-
trar o valor de x a partir de h (http://www.gta.ufrj.br/grad/07_1/ass-dig/TiposdeCriptografia.html).
 50

Figura 18: Exemplo do Retorno do Início da Lista de Pacientes.

O retorno apresentado na Figura 18 mostra o início da mensagem JSON

retornada. Pode-se verificar a informação da URL da requisição e a lista de itens.

Figura 19: Exemplo do Retorno do Final da Lista de Pacientes.

 51

A Figura 19 apresenta o final da mensagem JSON retornada. Pode-se no-

tar as informações de paginação para a exibição da lista pelos sistemas que utiliza-
rem o serviço web.

5.2 INFORMANDO A REALIZAÇÃO DE UMA CIRURGIA

Na Figura 20 é exibida a requisição que altera o status de uma cirurgia

para Realizada. Note-se que o verbo HTTP utilizado é o PUT.

Figura 20: Exemplo da Requisição para Alterar o Status de uma Cirurgia.

Na Figura 21, podemos ver o retorno do processamento da requisição da

Figura 20.

Figura 21: Exemplo do Retorno da Requisição para Alterar o Status de uma Cirurgia.
 52

A unidade de saúde não precisa se preocupar com o gerenciamento da fi-

la cirúrgica, apenas informar que a cirurgia foi realizada. Todas as operações de ge-
renciamento da fila como movimentação e retirada de pacientes são tratadas por
eventos de domínio, que são transparentes ao consumidor do serviço web.
 53

6 CONCLUSÕES E TRABALHOS FUTUROS

As regras que envolvem a regulação de uma fila cirúrgica apesar de com-

plexas podem ser implementadas em sistemas informatizados com um custo relati-
vamente baixo (levando-se em conta que as ferramentas utilizadas são todas ou to-
talmente gratuitas ou têm um custo bem reduzido comparado às suas alternativas de
mercado) frente aos grandes benefícios para os pacientes atendidos pelo SUS, co-
mo a possibilidade de oferta de cirurgias de baixa complexidade por hospitais de
menor porte e clínicas conveniadas, que agilizarão o atendimento aos muitos pacien-
tes que aguardam por cirurgias deste tipo.
A criação de um serviço web para a integração das unidades de saúde se
mostrou tão promissor que foi firmado um pacto entre as três esferas do poder exe-
cutivo (municipal, estadual e federal) para a integração da gestão dos seus hospi-
tais, inclusive com as centralizações de marcações de consultas e cirurgias e de
compras de medicamentos e suprimentos [32].
O uso da metodologia Domain-Driven Design foi essencial para que o co-
nhecimento dos especialistas do sistema fosse transmitido de forma concisa e clara,
fato que foi comprovado pelos próprios especialistas durante as reuniões de passa-
gem de conhecimento, onde, devido ao uso da linguagem úbiqua, diagramas de
modelagem foram utilizados e não se apresentaram como barreiras de comunica-
ção. Desta forma não foi necessário que os usuários do sistema se adequassem ao
seu funcionamento, ao invés disto foi entregue um sistema que retratava a realidade
do domínio.
Como oportunidades para o futuro está a possibilidade do acompanha-
mento da fila pelo próprio paciente seja através de interfaces web ou de aplicativos
móveis, bem como a efetiva integração que foi o alvo do pacto firmado pelos gesto-
res das três esferas do poder executivo.
 54

7 REFERÊNCIAS BIBLIOGRÁFICAS

[1] ZAKAS, Nicholas C. JavaScript de Alto Desempenho. São Paulo: Novatec,

2010. Tradução de High Performance JavaScript.

[2] EVANS, Eric. Domain-Driven Design: Atacando as complexidades no

coração do software – 2ª Edição Revisada. Rio de Janeiro: Alta Books, 2009.
Tradução de Domain-Driven Design – Tackling Comuplexity in The Heart of
Software.

[3] NILSSON, Jimmy. Applying Domain-Driven Design and Patterns. Boston: Ad-
dison-Wesley, 2006.
[4] MCCARTHY, Tim. .Net Domain-Driven Design with C#: Problem – Design –
Solution. Indianápolis: Wiley, 2008.

[5] HAYWOOD, Dan. Domain-Driven Design Using Naked Objects. Raleigh: The
Pragmatic Bookshelf, 2009.

[6] VERNON, Vaughn. Implementing Domain-Driven Design.Westford: Addison-

Wesley, 2013.

[7] MILLET, Scott. Patterns, Principles and Practices of Domain-Driven Design.

Indianápolis: Wiley, 2015.

[8] TIOBE Index. Disponível em: http://www.tiobe.com/tiobe-index. Acesso em 16

nov. 2016.

[9] FEHRE, Phillipp. JavaScript Domain-Driven Design. Birmingham: Packt

Publishing.

[10] TOLKIEN, J. R. R. Lord of The Rings: The Fellowship of The Ring. Scoresby:
Allen & Unwin, 1954.

[11] BRASIL. Constituição da República Federativa do Brasil, Brasília, DF, Art.

196.

[12] BRASIL. Lei nº 8088, de 19 de setembro de 1990. Dispõe sobre as condições

para a promoção, proteção e recuperação da saúde, a organização e o
funcionamento dos serviços correspondentes e dá outras providências. Diário
Oficial da República Federativa do Brasil, Brasília, DF, p. 18.055, 20 set. 1990
Seção 1.

[13] Justiça determina reavaliação de filas de espera por cirurgias no Rio de Janeiro,
Defensoria Pública da União, Brasília, DF, 16 maio 2014. Disponível em:
http://www.dpu.gov.br/index.php?option=com_content&view=article&id=21592:
 55

justica-determina-reavaliacao-de-filas-por-cirurgias-no-rio-de-
janeiro&catid=215:noticias-slideshow&Itemid=458. Acesso em 16 nov. 2016.

[14] ASA Physical Status Classification System, The American Society of

Anesthesiologists, Schaumburg, USA. Disponível em: https://www.asahq.org/For-
Members/Clinical-Information/ASA-Physical-Status-Classification-System.aspx
Acesso em 16 abr. 2015.

[15] BRASIL. Lei nº 10741, de 1º de outubro de 2003. Dispõe sobre o Estatuto do

Idoso e dá outras providências. Diário Oficial da República Federativa do Brasil,
Brasília, DF, p. 1, 3 out. 2003 Seção 1.

[16] BRASIL. Lei nº 8069, de 19 de setembro de 1990. Dispõe sobre o Estatuto da

Criança e do Adolescente e dá outras providências. Diário Oficial da República
Federativa do Brasil, Brasília, DF, p. 13.563, 16 jul. 1990 Seção 1.

[17] e-SUS Hospitalar, DATASUS, Rio de Janeiro, RJ, p. 1 e 10. Disponível em:
ftp://ftp2.datasus.gov.br/public/sistemas/dsweb/datasus/Minuta_site_e-SUS_V2.pdf
Acesso em 16 nov. 2015.

[18] GURUGÉ, Anura. Web Services Theory and Pratice.Burlington: Elsevier,

2004.

[19] MARCHAL, Benoit. XML by Example. Indianápolis: Que, 2002.

[20] SMITH, Ben. Beginning JSON. New York City: Apress, 2015.

[21] Simple Object Access Protocol (SOAP) 1.1, W3C, Cambridge, MA. Disponível
em: https://www.w3.org/TR/2000/NOTE-SOAP-20000508. Acesso em 16 nov. 2016.

[22] FIELDING, Roy T. Architectural Styles and the Design of Network-based

Software Architectures. University of California, Irvine, 2000.

[23] MARTIN, Robert C. Código Limpo: Habilidades Práticas do Agile Software.

Rio de Janeiro: Alta Books, 2009. Tradução de Clean Code: A Handbook of Agile
Software.

[24] TONG, Kent Ka Iok. Beginning JSF 2 APIs and JBoss Seam. New York:
Apress, 2009.

[25] FLANAGAN, David. JavaScript: The Definitive Guide – 6th Edition.

Sebastopol: O’ Reilly, 2011. Tradução de Clean Code: A Handbook of Agile
Software.

[26] PEREIRA, Caio Ribeiro. Node.js: Aplicações web real-time com Node.js. São
Paulo: Casa do Código, 2014.

[27] MAHARRY, Dan. TypeScript Revealed. New York City: Apress, 2013.
 56

[28] MILANI, André. MySQL: Guia do Programador. São Paulo: Novatec, 2006.

[29] FOWLER, Martin. UML Essencial: Um breve guia para a linguagem-padrão

de modelagem de dados – 3ª Edição. São Paulo: Bookman, 2007. Tradução de
UML Distilled: A Brief Guide to the Standard Object Modeling Language, 3/e.

[30] LARMAN, Craig. Utilizando UML e Padrões: Uma introdução à análise e ao

projeto orientado a objetos e ao desenvolvimento iterativo – 3ª Edição. São
Paulo: Bookman, 2007. Tradução de Applying UML and Patterns: An Introduction to
Object-Oriented Analysis and Design and Iterative Development, 3rd Edition.

[31] STEFANOV, Stoyan. Padrões JavaScript. São Paulo: Novatec, 2011. Tradução
de JavaScript Patterns, 1st Edition.

[32] Hospitais municipais, estaduais e federais do Rio terão marcação de consultas e

cirurgias unificada. Jornal O Globo, Rio de Janeiro, RJ, 07 jan 2015. Disponível em:
http://oglobo.globo.com/rio/hospitais-municipais-estaduais-federais-do-rio-terao-
marcacao-de-consultas-cirurgias-unificada-14994804. Acesso em 16 nov. 2016.