EDSON BATISTA DOS SANTOS JUNIOR
IMPLEMENTANDO DOMAIN-DRIVEN DESIGN
NO DESENVOLVIMENTO JAVASCRIPT
Niterói
2016
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
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.
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
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”.
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 tecnometodo-logias 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.
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.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
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/).
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.
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. Coco-mo 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-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 gran-de gran-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/).
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
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).
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].
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
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,
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 consDes-tante 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).
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.
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.
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
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
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 obob-jetos 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-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 operaidentifica-çã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-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 utilizato-das 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.
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 peprotoco-lo 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
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).
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 softwahardwa-res 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 ginfraestrutu-ratuitos. Tendo a infinfraestrutu-raestrutuinfraestrutu-ra definida, chegou a hoinfraestrutu-ra 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-re e faz a orquestração da comunicação entsoftwa-re 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 ginfraestrutu-rande painfraestrutu-ra não atinfraestrutu-rasar 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-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 aju-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. Eveneven-tos 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 eveneven-tos 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 propro-cessar 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
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 funexce-çõ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.
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.
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].
4.3.1 CASOS DE USO
A linguagem UML10 se utiliza de diagramas e tabelas para representar ca-sos de uso. Caca-sos 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].
Hospital responsável pelo Cadastro do Paciente
É o estabelecimento de saúde responsável pelo Cadastro do Paciente.
Sistema É o software responsável pela regulação da fila cirúrgica.
Pré-Condição
Hospital responsável pelo Cadastro do Paciente previamente cadastrado no Sistema.
Fluxo Básico
ID Passo Fluxos Regras de Negócio
1 Hospital responsável pelo Cadastro do Paciente envia as informações do Paciente ao Sistema
FE01, FE02 RN001, RN002, RN003, RN004, RN005
2 Sistema insere o Paciente na Fila de acordo
com o critério de prioridade - RN006
3 Fim da especificação - -
Fluxos de Exceção
FE01 Token de acesso inválido ID Passo
Regras de Negócio
Mensagem
1 O Token de Acesso enviado é
inválido. - -
2 O Sistema retorna uma mensagem
de erro. - MSG_E001
FE02 As informações do Paciente são inválidas ID Passo
Regras de Negócio
Mensagem
1 Uma (ou mais) informação(ões) do
Paciente é(são) inválidas. - -
2 O Sistema retorna uma mensagem
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.
Atores
Ator Descrição
Hospital responsável pela Oferta de
Cirurgia
É o estabelecimento de saúde responsável pela Oferta de Cirurgia.
Sistema É o software responsável pela regulação da fila cirúrgica.
Pré-Condição
Hospital responsável pela Oferta de Cirurgia previamente cadastrado no Sistema.
Fluxo Básico
ID Passo Fluxos Regras de Negócio
1
Hospital responsável pela Oferta de Cirurgia envia as informações de uma Oferta de Cirurgia. FE01, FE03 RN007, RN008, RN009
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 ID Passo
Regras de Negócio
Mensagem
1 Uma (ou mais) informação (ões) da
Oferta de Cirurgia é(são) inválidas. - - 2 O Sistema retorna uma mensagem
de erro. - MSG_E003
Mensagens
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.
Atores
Ator Descrição
Sistema É o software responsável pela regulação da fila cirúrgica.
Hospital responsável pela Oferta de
Cirurgia
É o estabelecimento de saúde responsável pela Oferta de Cirurgia.
Hospital responsável pelo Cadastro do Paciente
É o estabelecimento de saúde responsável pelo Cadastro do 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
ID Passo Fluxos Regras de Negócio
1
O Sistema informa ao Hospital responsável pelo cadastro do Paciente os dados da Cirurgia Ofertada.
- -
2 O Sistema altera o Status do Paciente para
Encaminhado. - -
3 O Hospital responsável pela Oferta de Cirurgia
obtém pacientes selecionados. - -
4
O Hospital responsável pelo Cadastro do Paciente obtém o encaminhamento dos Pacientes selecionados.
- RN010
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;
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 pela Oferta de
Cirurgia
É o estabelecimento de saúde responsável pela Oferta de Cirurgia.
Sistema É o software responsável pela regulação da fila cirúrgica.
Pré-Condição
Hospital responsável pela Oferta de Cirurgia previamente cadastrado no Sistema.
Fluxo Básico
ID Passo Fluxos Regras de Negócio
1 Hospital responsável pela Oferta de Cirurgia
informa a realização da Cirurgia. -
RN011
2 Sistema altera o Status do Paciente para
Atendido. - -
3 Sistema retira o Paciente da Fila. - RN012
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 pela Oferta de
Cirurgia
É o estabelecimento de saúde responsável pela Oferta de Cirurgia.
Sistema É o software responsável pela regulação da fila cirúrgica.
Pré-Condição
Hospital responsável pela Oferta de Cirurgia previamente cadastrado no Sistema.
Fluxo Básico Regras de
Negócio
RN011 – Uma vez realizada a Cirurgia, o Hospital responsável pela Oferta da Cirurgia deve informar sua realização;
ID Passo Fluxos Regras de Negócio
1 Hospital responsável pela Oferta de Cirurgia informa o Cancelamento da Cirurgia. -
RN013
2 Sistema altera o Status do Paciente para
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
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.
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).
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.
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).
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 FiFi-guras 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).
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.
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.
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.
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 linguapassa-gem ú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.
