Ambientes de Laudo à Distância
Um protocolo de aplicação
para comunicação DICOM
André Germano Regert mtr. 99132036 Martin Prüsse mtr. 00132306
Orientador: Prof. Dr. Rer. Nat. Aldo von Wangenheim
Índice
Resumo ... 5 1 Introdução ... 6 1.1 Descrição do problema... 7 1.2 Motivação ... 8 1.3 Objetivos... 9 1.3.1 Objetivo Geral ... 9 1.3.2 Objetivos Específicos ... 9 1.4 Estrutura do trabalho ... 92 Fundamentação Teórica e Metodológica ... 11
2.1 O padrão DICOM... 11
2.2 Protocolos... 12
2.2.1 O modelo de referência OSI... 12
2.2.2 Protocolos da Internet ... 15
2.2.3 Protocolo TCP... 16
2.2.4 Protocolo UDP... 16
2.2.5 Protocolos de Aplicação... 17
2.2.6 DICOM Upper Layer Services... 18
2.3 Extreme Programming... 19
3 Cyclops Medical Station ... 21
3.1 Funcionalidades... 21
3.1.1 Estruturas DICOM disponíveis ... 21
3.1.2 Ferramenta de Visualização... 22
3.1.3 Ferramentas de Manipulação... 23
4 Cyclops Application Protocol... 25
4.1 Requisitos de Transmissão... 25 4.2 Requisitos de Manipulação... 26 4.3 Requisitos de Visualização... 26 4.4 Requisitos de Comunicação ... 27 4.5 Modelando o Protocolo... 27 4.5.1 A Interface de Conexão... 28 4.5.2 A camada de Sessão ... 30
4.5.3 A camada de Aplicação... 33
Tabela 8 – Descrição dos campos SUBC de manipulação. ... 35
5 Testes. ... 36
5.1 Programação Orientada a Testes... 36
5.1.1 Testes da Interface de Transporte ... 36
5.1.2 Testes da Camada de Sessão ... 37
5.1.3 Testes da Camada de Aplicação... 38
5.2 Eficiência do Protótipo ... 39
6 Sala de Laudos Virtual ... 41
6.1 Uma Sessão de Laudo Colaborativo ... 41
6.2 Modelo Proposto para SLV... 42
6.3 Protótipo Implementado... 42
7 Conclusões sobre o trabalho... 47
7.1 Eficiência do Protótipo ... 47
7.2 Trabalhos Futuros... 47
Bibliografia... 48
Anexos ... 51
Anexo 1 - Requisitos do sistema ... 51
Requisitos funcionais ... 51
Requisitos não funcionais ... 53
Anexo 2 – Casos de Uso e Histórias do Usuário ... 55
Anexo 3 – Código Fonte dos Testes... 61
Anexo 4 – Código Fonte do Protocolo ... 61
Anexo 5 – Primitivas do Protocolo de Aplicação... 87
Resumo
O padrão DICOM é o padrão médico internacional mais difundido atualmente. Ele apresenta suporte as mais diversificadas atividades médicas, com foco nos bem conhecidos sistemas de arquivamento de imagens e comunicação – PACS. Porém as estruturas de comunicação DICOM não possuem suporte a ferramentas colaborativas em tempo real.
Hoje, é impossível que um profissional da área médica se conecte de forma padronizada e em tempo real através de um software ou estação radiológica. Este tipo de comunicação serve para substituir os atuais métodos de teleconferência, que degradam a qualidade das imagens transmitidas, sendo assim de pouca ajuda no caso de um laudo radiológico.
O objetivo deste trabalho é complementar esta lacuna do padrão DICOM desenvolvendo um protocolo visando o suporte a ferramentas colaborativas. Para isto, foram analisadas as principais ferramentas de uma estação radiológica, assim como as principais estruturas DICOM as quais o suporte precisa ser mantido.
Como validação do trabalho, foi realizada a implementação o protocolo em uma estação radiológica. O resultado é um protocolo robusto, genérico e ainda assim passível de extensões a outros tipos de ferramentas DICOM.
1 Introdução
O CMS, do acrônimo Cyclops Medical Station, é um framework1 para o desenvolvimento de ferramentas de análise e diagnóstico de imagens médicas. O CMS foi desenvolvido pelo Projeto Cyclops, um projeto de cooperação binacional entre Brasil e Alemanha e que visa o desenvolvimento de ferramentas de análise e diagnóstico de imagens médicas [1].
O CMS é composto por algumas ferramentas básicas para auxilio ao diagnóstico, como uma ferramenta de visualização de imagens médicas no padrão internacional DICOM (Digital Imaging and Comunication in Medicine) [2], um banco de dados local para armazenamento destas imagens e algumas outras ferramentas para alteração das imagens, como desenho, texto, zoom, brilho e contraste. Considerando estas e outras características, o CMS foi utilizado como base para a reengenharia de uma ferramenta que cria um ambiente de laudo à distância, a Sala de Laudos Virtual, ou SLV [3].
A SLV pode ser vista de uma forma simplificada como uma aplicação do tipo cliente-servidor que estende a ferramenta de visualização de imagens do CMS. Através de uma conexão via internet, a SLV permite que duas ou mais destas ferramentas sejam conectadas entre si. Assim um usuário pode alterar simultaneamente as imagens em todas elas, auxiliado por uma ferramenta de conversa textual e, onde disponível, uma ferramenta para conversa de voz.
Analisando um pouco mais a fundo as características da SLV, notou-se a possibilidade de desenvolvimento de um protocolo genérico para modificação de dados médicos no padrão DICOM. Um protocolo com estas funcionalidades tornaria a SLV muito mais abrangente no auxílio ao diagnóstico médico, gerando uma grande economia de tempo e recursos que seriam necessários para uma reunião.
1 Um framework é, segundo a engenharia de software, um componente de software
reutilizável que define uma solução genérica para uma determinada classe de problemas, provendo funcionalidades que podem ser utilizadas em várias aplicações ou ferramentas diferentes.
Infelizmente, o compartilhamento direto da visualização não é possível usando somente os serviços providos pelo padrão DICOM, pois ele não abrange requerimentos específicos para esta aplicação. Soluções comerciais feitas com este propósito apresentam são proprietárias, dificultando a intercomunicação entre outros softwares com propósitos semelhantes.
Prover um novo protocolo de aplicação ao mesmo tempo, simples de usar, que funcione transparentemente em aplicativos que suportem o padrão DICOM, e leve o suficiente para não impor tráfego proibitivo na rede. Este protocolo visa compartilhamento de informação em tempo real, onde a troca de estados da aplicação, dados da imagem, estados da apresentação e sincronização entre os aplicativos possam ser alcançados sem alterações nos serviços de rede DICOM.
1.1 Descrição do problema
Imagine que um exame complicado precisa ser avaliado, e o radiologista encarregado não se sente à vontade para dar uma palavra final sobre o diagnóstico. É ético dizer que em casos assim uma segunda opinião deveria ser pedida, pois um diagnóstico deve ser preciso. Considere que os especialistas para este exame não podem se encontrar com facilidade. Então o diagnóstico deve ser prorrogado.
Usando uma ferramenta que funcione de forma colaborativa, ambos os especialistas podem rapidamente se encontrarem virtualmente e discutir o caso o quanto antes, o que ajudaria consideravelmente a agilizar o processo. O protocolo de aplicação apresentado tem a intenção de interconectar visualizadores de imagens médicas de uma maneira simples. Assim, as ferramentas disponíveis nestes vizualizadores estarão disponíveis para facilitar ainda mais o trabalho dos médicos.
O principal objetivo do protocolo de aplicação aqui desenvolvido é encapsular o compartilhamento de dados entre as ferramentas de diagnóstico digital, sem interferir diretamente nos serviços DICOM prestados.
É possível encontrar similaridades com os protocolos Health Level Seven, do acrônimo HL7 [4]. Porém, estes visam intercomunicar e integrar todo o
software presente em um ambiente médico, sem se preocupar diretamente com colaboração em tempo real entre as aplicações.
Para tornar este projeto uma realidade, foi necessária uma análise das funcionalidades para manipulação de dados médicos do CMS, verificando quais delas são encontradas em outras ferramentas estado da arte. Apenas as funcionalidades presentes em comum no CMS e nestas ferramentas serão implementadas e validadas. Assim, será possível utilizar o protocolo para comunicar o CMS com outros softwares de manipulação que utilizem o mesmo.
1.2 Motivação
Segundo Mendes, nos últimos anos a tele medicina tem possibilitado, em vários países, uma redução de custos nas instituições ligadas a saúde. Através dela é possível o tratamento e acompanhamento sem a necessidade de deslocamento de equipamentos, médicos e até mesmo pacientes para a manutenção da saúde. Ela torna possível realizar exames, consultas e cirurgias por médicos sem que a presença física deles seja necessária.
A realidade brasileira é bem diferente. Os equipamentos e médicos especialistas normalmente estão concentrados nos grandes centros, e existe pouca ou nenhuma tecnologia de tele medicina implantada nos sistemas de saúde pública dos estados. No Estado de Santa Catarina, somente no final de 2004 foi definido pelo Governo do Estado, em conjunto com a Secretaria Estadual de Saúde e o Projeto Cyclops, uma política de implantação de uma estrutura de tele medicina, destinada a atender eficientemente as regiões onde existe carência de profissionais especializados.
Equipamentos de radiologia, como alguns tomógrafos de última geração, antes não existentes no interior do estado, estão sendo comprados e instalados. A realização de exames agora poderá ser feita sem que os pacientes precisem se deslocar para os grandes centros. Mas os especialistas ainda não estão presentes, ou são recém contratados e possuem pouca experiência.
O protocolo entrará em cena neste cenário: possibilitar aos especialistas a realização de laudos colaborativos sem a necessidade de deslocamento físico.
Um médico radiologista em Chapecó poderá realizar um laudo colaborativo, com outro em Joinville e mais um em Florianópolis. O tempo necessário para o envio de cópias do exame para ambos, cruzar as opiniões deles e chegar a uma conclusão não será mais um problema. O laudo poderá ser realizado em tempo real pelos três, e o principal objetivo estará alcançado. Com o resultado do exame em mãos rapidamente, as chances de um paciente ser rapidamente atendido e reabilitado serão muito maiores.
1.3 Objetivos
O desenvolvimento do protocolo para comunicação direta entre clientes DICOM tem como objetivos:
1.3.1 Objetivo Geral
Desenvolver um protocolo de comunicação em tempo real entre clientes para manipulação de dados médicos para o padrão DICOM.
1.3.2 Objetivos Específicos
• Analisar os serviços de rede DICOM disponíveis, verificando a viabilidade de sua utilização para comunicação em tempo real entre clientes.
• Programar as funcionalidades necessárias não existentes no padrão internacional.
• Fácil utilização para o usuário final, o médico radiologista.
1.4 Estrutura do trabalho
No capítulo 1 apresenta-se a introdução ao assunto abordado por este trabalho, em conjunto com as motivações e objetivos do mesmo.
Em seguida, no capítulo 2, será apresentada a fundamentação teórica necessária para o entendimento deste trabalho, onde serão abordados assuntos como o padrão DICOM e seus serviços de rede, protocolos de rede utilizados, e alguns aspectos referentes aos métodos de engenharia de software utilizados.
No terceiro capítulo será feita a apresentação e análise do sistema CMS demonstrando-se as estruturas de dados médicos do padrão DICOM disponíveis para teste. No quarto capítulo, será feita a modelagem do protocolo de aplicação. Apresentaremos detalhadamente as estruturas modeladas a partir do planejamento de testes e seu funcionamento.
Em seguida, no capítulo 5, é feita uma apresentação dos resultados obtidos com a programação de um protótipo para o sistema. O capitulo seis comenta a validação do protocolo através da reprogramação da SLV no CMS. O capítulo 7 apresenta os resultados obtidos e demonstra possibilidades de trabalhos futuros. Em anexo são revisados a análise de requisitos e os casos de uso descritos anteriormente por John A. F. Mendes. Também trás as possibilidades de trabalhos que possam ser feitos futuramente de forma agregada ao protocolo.
2 Fundamentação Teórica e Metodológica
O desenvolvimento deste trabalho será embasado em inúmeros padrões internacionais, como DICOM e OSI. Estes padrões e tecnologias são descritos no decorrer desde capítulo.
2.1 O padrão DICOM
Algum tempo após o surgimento das primeiras imagens médicas em formato digital, o American College of Radiology – ACR [5] – e a National Electrical Manufacturers Association – NEMA [6] – perceberam a necessidade de padronização para sistemas de arquivamento de imagens médicas e comunicação, conhecidos como PACS [7] na sigla em inglês. Então, em 1983, foi formado um comitê conjunto para desenvolver um padrão para facilitar a conectividade entre diversos fabricantes de equipamentos de imagens médicas. Com este objetivo este comitê publicou em 1995 a versão 1.0 deste padrão com o documento chamado ACR/NEMA Standards Publication No. 300-1985 [8].
Este documento sofreu várias revisões. Enfim, em 1992 foi lançada a versão 2.0 deste padrão, que foi denominada ACR/NEMA Standards Publication No. 300-1988. Esta versão realmente se tornou o padrão para comunicação e intercâmbio de imagens. Apesar de ter sido largamente utilizada, a versão do padrão sofria de muitas deficiências quanto sua parte de comunicação em rede.
Então, o padrão sofreu uma revisão e reorganização radical e entre 1992 e 1993 foi publicada uma nova versão chamada ACR/NEMA Standards Publication PS3, que ficou mais conhecida pelo nome DICOM 3.0 (do inglês Digital Imaging and Communications in Medicine). Após mais três anos de trabalho auxiliados por várias sugestões das áreas industrial e acadêmica, o DICOM 3.0 foi dado por completo. Assim, esta versão acabou se tornando o padrão de fato para PACS, pois apresenta uma definição realmente abrangente e robusta para comunicação e intercâmbio de imagens médicas.
A abrangência do padrão DICOM 3.0 em PACS não se restringe simplesmente a um protocolo de codificação dos dados da imagem e sua
transmissão. Ele também define diversas classes de serviços, como armazenamento, recuperação, pesquisa e impressão de imagens, formatos utilizados no armazenamento das imagens em meios removíveis, processos de negociação de associações para a transmissão dos dados das imagens através de redes, etc.
2.2 Protocolos
Um protocolo é uma convenção ou padrão que controla ou permite a conexão, comunicação e transferência de dados entre dois pontos computacionais. Eles podem ser desenvolvidos em hardware, software, ou uma combinação dos dois.
Protocolos são utilizados para descrever qualquer conjunto de regras que permita máquinas diferentes ou softwares a se comunicarem sem ambigüidade. Isso implica que há um formato comum para as mensagens trocadas e um conjunto de primitivas ou comandos que todos os dispositivos ou aplicações envolvidas devem compreender, e que as transações entre eles sigam uma seqüência lógica previsível.
2.2.1 O modelo de referência OSI
Em meados da década de 80 a ISO, do acrônimo International Organization for Standardization [9], iniciou um esforço em redes de computadores chamado Open Systems Interconnect, também conhecido pela sigla OSI [10].
Antes do OSI, construir redes de computadores dependia diretamente de sistemas proprietários. Este era um novo esforço da indústria para que todos utilizassem um padrão comum que possibilitasse a compatibilidade entre os equipamentos e software.
O modelo OSI foi o maior avanço no ensino de conceitos de redes de computadores. Ele promoveu a idéia de camadas de protocolo, definindo interoperabilidade entre dispositivos e software. Cada camada tem a
propriedade de utilizar somente as funções da camada diretamente inferior, e exporta funcionalidade somente para a camada diretamente superior. Um sistema que tem programado um protocolo com o comportamento consistindo de uma série dessas camadas é chamado de “pilha de protocolos” ou simplesmente “pilha”. Pilhas podem ser programadas em software, hardware, ou numa mistura dos dois. Tipicamente, apenas as camadas mais baixas são construídas em hardware, com as camadas altas programadas em software.
A tabela abaixo descreve as camadas da pilha de protocolos do modelo de referência OSI, com suas respectivas funções.
Tabela 1 – As camadas da pilha de protocolos OSI.
Camada Descrição
7 Aplicação
Esta camada de protocolos é a “janela” entre usuários comunicantes no ambiente OSI, através da qual ocorre toda troca de informação significativa para eles. Todas as camadas abaixo desta existem para tornar esta comunicação possível.
6 Apresentação
Codificar dados estruturados desde o formato interno usado no transmissor para um fluxo de bits adequado à transmissão, e depois decodificá-los na representação do destino, é a função dos protocolos da camada de apresentação.
5 Sessão
Os protocolos da camada de sessão organizam e sincronizam o diálogo, além de gerenciarem a troca de dados entre entidades da camada de apresentação.
4 Transporte Protocolos desta camada fornecem o serviço de transferência
transparente de dados entre entidades da camada de sessão.
3 Rede
Esta camada agrupa protocolos de operação da rede, tais como algoritmos para cálculo de rotas e de controle de congestionamento. Cabe a ela levar os pacotes da origem ao destino, optando caminho apropriado.
2 Enlace Detecta e possivelmente corrige erros na camada de meios físicos.
circuitos de dados na camada física.
1 Física
Define as características mecânicas, elétricas, funcionais e de procedimentos para ativar, manter e desativar conexões físicas para a transmissão de bits.
Segundo Tanenbaum, os princípios que foram aplicados para modelar as sete camadas estão resumidos abaixo:
• Uma camada deve ser criada onde uma diferente abstração mostra-se necessária.
• Cada camada deve executar uma função bem definida.
• A função de cada camada deve ser escolhida visando sua utilização com ou a definição de protocolos internacionalmente padronizados.
• Os limites da camada devem ser escolhidos para minimizar o fluxo de informações entre as interfaces que ela irá suportar.
• O número de camadas deve ser grande o suficiente, para que funções distintas não precisem ser agrupadas na mesma camada sem necessidade, e pequeno o suficiente, para que a arquitetura não se torne difícil de manter.
A pilha de protocolos OSI atual foi considerada por muitos como complicada demais e, até certo ponto, impossível de ser programada. Ela especificava a eliminação de todos os protocolos existentes no momento de sua criação, substituindo-os por novos em todas as camadas da pilha. Isto realmente levou vários fabricantes e usuários que já tinham investido em outras tecnologias a não utilizá-la. Além disso, os protocolos OSI foram especificados por grupos com interesses em requerimentos muito diferentes, o que levou o modelo a ter inúmeras características opcionais. Com muitas partes da especificação opcionais, as implementações feitas se tornaram incompatíveis, negando todo o empenho em definir o modelo.
2.2.2 Protocolos da Internet
O conjunto de protocolos da Internet pode ser descrito com uma analogia ao modelo OSI, ou seja, uma pilha de protocolos. Eles são conhecidos também como TCP/IP [11], derivados dos dois primeiros protocolos feitos para Internet: TCP, do acrônimo Transmission Control Protocol [12, 13, 14], e IP, do acrônimo Internet Protocol [15].
Existe uma discussão sobre como mapear o modelo TCP/IP com o modelo OSI. Sabendo que os dois modelos não correspondem precisamente, podemos afirmar que não há uma resposta correta.
Um mapeamento comum é o feito pela tabela abaixo. Ela descreve as camadas da pilha de protocolos do modelo TCP/IP, comparando-a com as equivalentes do modelo OSI.
Tabela 2 – Camadas do modelo OSI comparadas o modelo da Internet, também conhecido como TCP/IP.
OSI TCP/IP 7 Aplicação 6 Apresentação 5 Sessão Aplicação 4 Transporte Transporte 3 Rede Inter-redes 2 Enlace 1 Física Host/rede
Como podemos observar pela tabela, as camadas de Apresentação e Sessão do modelo OSI são absorvidas pela camada de aplicação no TCP/IP. A camada de transporte é bastante similar à do modelo OSI. Quanto à camada de rede, enquanto o modelo OSI foca em interligar redes similares, o modelo TCP foca em conectar redes diferentes. As camadas de enlace e física não são abordadas em detalhes pelo modelo TCP/IP. Este apenas ressalta que
entidades conectadas à rede devem utilizar o mesmo protocolo, de forma que seja possível enviar pacotes IP, independente dos tipos de rede envolvidos.
2.2.3 Protocolo TCP
O protocolo TCP, da pilha de protocolos da internet, é o principal protocolo de transporte utilizado por ela. Ele garante um fluxo de bytes confiável entre duas entidades através de uma rede não confiável. Projetado para se adaptar dinamicamente as características da rede, é robusto ao enfrentar vários tipos de falhas.
Cada máquina que suporta o TCP possui uma entidade de transporte TCP, que pode ser parte de uma biblioteca, um processo, ou uma parte integrante do sistema operacional. Esta entidade recebe um fluxo de dados de processos locais, quebra-o em pequenos pedaços e envia cada pedaço como um datagrama IP [16]. Da mesma forma, ao receber uma seqüência de datagramas, a entidade os reconstrói de maneira apropriada à estrutura de dado original. Como a camada de rede, que utiliza o protocolo IP, não garante que os pacotes sejam entregues, cabe ao TCP retransmiti-los quando necessário. Resumidamente, o TCP provém à confiabilidade que a maioria dos sistemas requer e que o IP não garante.
2.2.4 Protocolo UDP
O conjunto de protocolos da Internet suporta um protocolo de transporte não voltado à conexão, o UDP [17], acrônimo de User Datagram Protocol. Este protocolo provém uma maneira para as aplicações enviarem datagramas IP sem que uma conexão precise ser estabelecida.
O cabeçalho de um pacote UDP nada mais é do que um pacote IP acrescido de 3 campos, os campos porta de destino e fonte, e um campo opcional de checksum. São estes campos que irão determinar qual aplicação será
responsável por receber e tratar os pacotes. A porta fonte é necessária quando uma resposta precisa ser enviada de volta.
É importante frisar explicitamente o que o protocolo UDP não faz: controle de fluxo, controle de erro, retransmissão no recebimento de um segmento com erro. Tudo isso depende dos processos do usuário. O que ele faz é adicionar a possibilidade de alternar entre processos múltiplos através das portas.
2.2.5 Protocolos de Aplicação
A camada de aplicação do modelo de referência OSI e da pilha de protocolos da internet é a parte que realmente faz o trabalho para os usuários. Assim como nas camadas inferiores, quando dois programas de usuário precisam trocar dados, é necessário construir um protocolo. Quando estas aplicações fazem isto através de uma rede ou da internet, as outras camadas servem de base para a comunicação somente, apresentando uma funcionalidade transparente ao usuário.
A camada de aplicações contém os programas do usuário (também conhecidos como aplicações ou aplicativos) que fazem o verdadeiro trabalho para o qual os computadores foram adquiridos. Esses programas utilizam os serviços oferecidos pela camada de aplicações para suas necessidades de comunicação. Entretanto, certas aplicações, tais como a transferência de arquivos, são tão comuns que foram desenvolvidos padrões a fim de eliminar a necessidade de cada empresa desenvolver sua própria aplicação e para garantir que todos usem os mesmos protocolos.
As questões normalmente tratadas pelos protocolos de aplicação envolvem o gerenciamento de conexões (não as funcionalidades das mesmas), troca de informações e arquivos. Exemplos de protocolos de aplicação bastante utilizados são os protocolos FTP [18], para acesso remoto a repositórios de arquivos, e SMTP [19], para troca de mensagens de correio eletrônico.
2.2.6 DICOM Upper Layer Services
Segundo Clunie, o padrão DICOM possui, diferentemente de outras tentativas de se estabelecer um padrão, o potencial para chegar a este objetivo.
Ele difere substancialmente de outras tentativas na definição dos chamados Service-Object Pairs [20]. Se um fabricante diz que seu equipamento suporta uma Classe DICOM de Arquivamento de Ressonância Magnética como um Provedor de Classe de Serviço, e outro fabricante diz que sua workstation suporta o mesmo como um Usuário de Classe de Serviço, e ambos podem conectar utilizando-se TCP/IP via Ethernet, certamente estes dois dispositivos têm a possibilidade de comunicarem-se.
O DICOM UL utiliza-se de padrões internacionais para comunicação, o TCP/IP e OSI citados anteriormente, no seu protocolo de aplicação. Porém, apenas o mecanismo de associação, que trata da troca de mensagens e de como as conexões são estabelecidas, está sendo utilizado no modelo.
Abaixo um esquema de como o serviço DICOM UL está definido.
Ser apenas capaz de comunicar-se e transmitir informação não é suficiente. Isto é apenas uma ferramenta útil para a construção de um sistema. Não importa se uma workstation pode baixar uma imagem de um scanner de ressonância magnética, se ela não souber quando esta imagem está disponível, a que paciente pertence, e onde ela deve ser subsequentemente arquivada. Em outras palavras, o DICOM UL não garante funcionalidade, apenas facilita a conectividade.
2.3 Extreme Programming
A metodologia para desenvolvimento de software XP [23], do acrônimo Extreme Programming, é a mais conhecida das metodologias tidas como ágeis. As raízes de XP estão na comunidade Smalltalk2, e na estreita colaboração desenvolvida por Kent Beck e Ward Cunningham no final dos anos 80. Ambos refinaram suas práticas nos anos seguintes, e as estenderam na abordagem de um processo de desenvolvimento que fosse tanto adaptativo como orientado a pessoas.
A passagem de prática informal para uma metodologia tem como marco inicial o projeto C3, desenvolvido por Kent Beck em 1996, usando novos conceitos em desenvolvimento de software. O princípio é que você pode aprimorar o processo de desenvolvimento de software em quatro dimensões principais: a Comunicação, a Simplicidade, o Feedback e a Coragem. Estes são os valores apregoados pela filosofia XP.
Os programadores XP se comunicam constantemente com o cliente e com seus colegas programadores, mantendo o projeto simples e claro. Eles obtêm
feedback testando o software desde seu primeiro dia, e distribuem o sistema aos
usuários tão cedo quanto possível, programando as modificações que forem
2 Smalltalk foi a primeira linguagem de programação a realmente programar o modelo de
abstração da Programação Orientada a Objetos. A comunidade Smalltalk é composta por muitos estudiosos e cientistas de todas as áreas da Ciência da Computação.
solicitadas. Com esses fundamentos, eles estão aptos a responder corajosamente a requisitos e tecnologias instáveis.
Os testes são um dos principais fundamentos de XP. Todo o código gerado é desenvolvido a partir da técnica Desenvolvimento Orientado a Testes, onde os programadores escrevem primeiramente códigos de teste, e destes emerge o código de produção. Tudo isto é integrado a um processo de produção, numa plataforma muito estável para o desenvolvimento futuro.
Sobre essa plataforma, XP constrói um processo evolucionário de projeto, baseado em refazer um sistema base a cada iteração. O foco do projeto é apenas a iteração atual, de modo que nada é projetado para necessidades futuras. O resultado é um disciplinado processo de projeto. Surpreendentemente, XP combina essa disciplina com um alto grau de adaptação, o que faz dela a mais bem desenvolvida das metodologias ágeis.
3 Cyclops Medical Station
Segundo o manual do usuário [22], o Cyclops Medical Station é um aplicativo da família de softwares Cyclops compatível com o padrão internacional de transmissão e arquivamento de imagens DICOM, que objetiva possibilitar médicos radiologistas executar laudos de exames de tomografia computadorizada, ressonância magnética e ultra-sonografia diretamente a partir de um computador.
Os exames a serem laudados podem ser buscados a partir de um servidor de imagens médicas, ou diretamente a partir do sistema de arquivos do computador do médico radiologista.
Uma característica importante do CMS é a forma como as imagens médicas são tratadas. No caso de o computador em uso possuir suporte a aceleração gráfica no padrão DirectX3, estes recursos serão utilizados. Outra característica do CMS é que muitas das ferramentas que ele apresenta não foram implementadas no Cyclops Personal, como as ferramentas para mensuração das imagens e as ferramentas de desenho.
3.1 Funcionalidades
Além das características acima descritas, o CMS é um framework, e pode ser utilizado como base para o desenvolvimento de muitas outras ferramentas para análise de imagens médicas. Esta característica foi fundamental na escolha do CMS como base de testes para o desenvolvimento do protocolo.
3.1.1 Estruturas DICOM disponíveis
O projeto Cyclops reuniu, com o passar dos anos, um grande número de séries radiológicas de tomografia computadorizada e ressonância magnética.
3 DirectX é uma tecnologia para tratamento de imagens desenvolvida pela Microsoft
Corporation, que utiliza para este fim algoritmos programados em hardware, acelerando o processamento.
Este repositório foi disponibilizado aos seus pesquisadores para o desenvolvimento de algoritmos de processamento de imagens e softwares de auxílio ao diagnóstico. Todos os exames têm autorização dos pacientes para uso em pesquisa, e estas estruturas foram anonimizadas para este fim, preservando assim a identidade dos mesmos.
O framework do CMS tem em sua base uma forte ferramenta para visualização destes tipos de exames, em seus diversos formatos descritos no padrão DICOM. Por isto, escolhemos estas estruturas para tratar inicialmente no desenvolvimento do protocolo.
3.1.2 Ferramenta de Visualização
A ferramenta de visualização do CMS possui a uma interface bastante simples. Ela é basicamente uma janela que mostra um ou mais exames abertos pelo usuário através de um repositório remoto ou arquivos guardados localmente.
Figura 2 – Ferramenta de Visualização do CMS
O importante ao observar o visualizador do CMS é considerar como ele mostra e manipula as imagens. Abaixo enumeramos as principais características:
• as imagens podem ser reposicionadas pelo mouse através da barra de rolagem ou mouse wheel.
• a quantidade de imagens visíveis simultaneamente pode ser alterada de acordo com a necessidade do usuário.
• O tamanho das imagens é redimensionado de acordo com o tamanho da janela.
Estas características também são comuns em outras estações radiológicas.
3.1.3 Ferramentas de Manipulação
Como extensões da ferramenta de visualização, as ferramentas de manipulação servem para auxiliar o médico radiologista na realização de laudos. A barra mostrada na figura 3 tem a função de cada botão descrita a seguir, da esquerda para direita.
Figura 3 – A barra de ferramentas de manipulação do CMS
A ferramenta de lupa permite que se aumente uma dada região da imagem. Ela é útil para que os radiologistas se certifiquem de detalhes na imagem sem ter que executar um zoom global.
A ferramenta de pan serve para movimentar a imagem e todos os seus overlays pela área reservada para a imagem. Sua principal utilização é posicionar alguma estrutura contra a barra métrica dos lados direito e inferior para executar alguma mensuração rápida.
A ferramenta de janelamento4 radiológico permite que se ajuste um mesmo exame para diferentes tipos de densidade radiológica5. Desta forma, por
4 O janelamento, ou janela de observação, é definido por um centro de densidade e um
intervalo a partir deste centro, que filtra as densidades a serem visualizadas em um exame radiológico. Este intervalo é ajustado de acordo com o tecido a ser observado.
exemplo, a partir de uma mesma tomografia o médico pode observá-la com janela de osso ou janela de córtex, como demonstrado pela figura 4.
Figura 4 – Ferramentas de Visualização com janelamento para tecido cerebral à esquerda, e tecido ósseo à direita.
A ferramenta de zoom permite que todas as imagens de uma série sejam aumentadas ou diminuídas. Já a ferramenta de overlay permite ao radiologista fazer anotações sobre as imagens de um exame. Também permite que mensurações sejam executadas.
Estas são as ferramentas comumente utilizadas durante a avaliação de um exame radiológico. O CMS ainda possui outras ferramentas mais elaboradas, mas que são muito complexas para generalização no desenvolvimento do protocolo.
5 A densidade radiológica da água destilada em condições normais de temperatura e
4 Cyclops Application Protocol
Considerando as características levantadas nos capítulos anteriores e às estruturas disponíveis para teste, para a primeira versão do protocolo foi decidido dar suporte apenas a algumas das estruturas abordadas.
Em relação ao padrão DICOM, nos ateremos detalhadamente apenas a séries tomográficas e de ressonância magnética. Isto porque são tipos de estrutura que o CMS dá suporte ao laudo, e pela disponibilidade de séries anonimizadas para testes. Este tipo de exame exige plenamente as capacidades do software, possibilitando o uso da maioria das ferramentas do mesmo.
Além de abordar o visualizador, uma escolha óbvia, pois o maior objetivo do protocolo é a visualização colaborativa, o compartilhamento das demais ferramentas também deverá ser implementado: zoom, posicionamento, lupa, janelamento, e as ferramentas de overlay.
Em relação à estrutura do protocolo, decidiu-se seguir um modelo semelhante ao modelo de referência OSI, a partir da quarta camada até a camada de aplicação. Algumas atribuições da camada de apresentação não serão abordadas nesta primeira versão, pois o único software disponível para testes é o CMS, não justificando suprir as necessidades suportadas por ela. As camadas inferiores serão suportadas pela pilha de protocolos TCP/IP. Estas escolhas serão mais bem entendidas pela enumeração dos principais requisitos levantados a seguir.
4.1 Requisitos de Transmissão
É na sutil diferença entre reprodução e transmissão que se faz a base do funcionamento do Cyclops Application Protocol. O principal requisito para a comunicação entre os clientes é manter os dados transmitidos simples.
Assim sendo, apenas os dados sobre as manipulações deverão ser transmitidos entre os clientes, e não os seus resultados. Se os resultados fossem transmitidos, teríamos algo semelhante a um stream de vídeo, e como exigência uma banda para comunicação diretamente dependente da qualidade
visual das imagens a serem transmitidas. Ou seja, quanto melhor a qualidade, maior a banda.
Transmitindo apenas os dados, diminuímos a banda de transmissão para apenas alguns kilobytes. Todo o resultado deve ser recalculado na chegada destes dados nos clientes envolvidos, e isto é de responsabilidade do protocolo.
4.2 Requisitos de Manipulação
O principal requisito de manipulação é a restrição ao usuário quanto à liberdade para a mesma. Durante conversas sobre o que seria uma sessão colaborativa com profissionais radiologistas, chegou-se a conclusão que não faz sentido que todos os envolvidos possam manipular os exames ao mesmo tempo. O interessante seria que cada um deles pudesse revezar a manipulação.
Desta forma, o protocolo precisa se responsabilizar pela restrição a apenas um usuário para a manipulação dos exames. Este usuário diz-se possuir o controle da sessão. Um usuário com controle da sessão pode manipular livremente os exames envolvidos na mesma, e utilizar as ferramentas disponibilizadas para este fim. Aos outros usuários envolvidos, o papel de espectadores é dado, até que o controle da sessão seja passado a um deles.
As ferramentas de manipulação precisam ser identificadas pelo protocolo. Ao ser selecionada uma ferramenta de manipulação, a informação de que isto ocorreu deverá ser transmitida a todos os envolvidos na sessão. Isto se dá pelo fato de que a manipulação deve ser reproduzida pelo protocolo nos clientes envolvidos, e não transmitida. Todas as operações realizadas com a ferramenta são transmitidas da mesma forma.
4.3 Requisitos de Visualização
Uma ferramenta de visualização para o protocolo não deverá sofrer nenhuma alteração visual em relação ao seu design, e também ao seu
comportamento. Assim, todo comportamento oriundo de uma sessão colaborativa será transparente à usabilidade da ferramenta.
Durante uma sessão colaborativa, um apontador deverá refletir o ponteiro do mouse do usuário que está manipulando a ferramenta, para os usuários que estiverem observando. Da mesma forma, um observador poderá alterar o tamanho da sua ferramenta de visualização sem que qualquer outro usuário perceba esta alteração.
Isto implica algumas responsabilidades ao protocolo: o protocolo deverá manter o posicionamento do apontador relativo ao tamanho da ferramenta de visualização de cada usuário; assim, todas as manipulações também devem ser refletidas por esta posição relativa, e manter a proporcionalidade das imagens ao mesmo tempo.
4.4 Requisitos de Comunicação
De nada adianta um protocolo colaborativo se os usuários não puderem dialogar entre eles, em tempo real. Programas de conversa textual são ferramentas comuns para o usuário da internet nos dias de hoje. Também não são mais novidades os programas que utilizam a tecnologia de voz sobre ip.
O protocolo modelado com certeza deve deixar espaço para o diálogo entre seus usuários, substituindo assim a necessidade de um terceiro programa deste tipo para este fim.
4.5 Modelando o Protocolo
O protocolo de aplicação modelado a seguir foi dividido em duas camadas. A camada inferior serve para controle de contexto, onde o tráfego para/de rede é acessado através de uma interface genérica para a camada de transporte. A camada superior intercepta, interpreta e encapsula a manipulação dos dados DICOM, numa mescla da quinta e da sétima das camadas OSI. Esta camada também tem uma interface, que tem a função de acoplar o protocolo com o aplicativo em si, e cuida da comunicação entre os usuários e os softwares de visualização.
Um sistema de etiquetas será responsável pela identificação dos pacotes de controle, dados e comunicação. Explicando de maneira simples, cada vez que novas informações forem adicionadas ao contexto de uma sessão colaborativa, uma nova etiqueta é negociada para aquela informação. Desta forma, a manipulação dos dados pode ser feita em tempo real e é compartilhada entre todos os envolvidos na sessão.
Antes que qualquer dado possa ser transmitido, um canal de comunicação TCP/IP é estabelecido. Isto pode ser feito através de um servidor ou via conexão direta entre os clientes. Para simplificar, a conexão direta entre os clientes foi adotada.
4.5.1 A Interface de Conexão
A conexão direta entre dois clientes será feita a princípio utilizando-se a arquitetura cliente-servidor. Os papéis de cliente e servidor podem se inverter durante uma sessão, dependendo das atividades que cada usuário estiver envolvido.
Como a conexão deve ser realizada pela camada de transporte, nada mais natural que construir uma interface que dê suporte as diretivas da mesma. O objetivo desta interface é facilitar o uso de componentes que implementem a camada de transporte, independentemente da linguagem de programação utilizada.
A camada de transporte, como especificada por Tanenbaum, possui cinco primitivas que precisam ser correspondidas: LISTEN, CONNECT, SEND, RECEIVE e DISCONNECT. A primitiva LISTEN é utilizada normalmente por um servidor. Ao ativar esta primitiva, ele espera até que um cliente utilize a primitiva CONNECT, e então um canal de comunicação é estabelecido entre os dois. Com este canal estabelecido, as camadas superiores podem utilizar as primitivas SEND para enviar dados e RECEIVE para receber dados. Ao terminar a troca de informações, a primitiva DISCONNECT é utilizada para fechar o canal.
A tabela abaixo define as primitivas utilizadas para a interface de conexão, que será utilizada pelas camadas superiores.
Tabela 3 – Primitivas para a interface de transporte.
Primitiva Função
C-WAIT O protocolo irá esperar por uma conexão. Equivalente a primitiva LISTEN.
C-CONNECT O protocolo irá tentar se conectar. Equivalente a primitiva CONNECT.
C-SEND O protocolo está enviando dados. Equivalente a primitiva SEND.
C-RECEIVE O protocolo está esperando dados. Equivalente a primitiva RECEIVE.
C-DISCONNECT O protocolo deseja encerrar a conexão. Equivalente a primitiva DISCONNECT.
Estas primitivas serão acessadas pela camada diretamente superior à camada de transporte, a camada de sessão do nosso protocolo. O diagrama abaixo define visualmente quais os pontos de acesso à interface definida.
Figura 5 – Interface de conexão do protocolo.
A implementação da Interface é diretamente dependente dos componentes utilizados, assim como o tratamento dos eventos passados às camadas superiores. A máquina de estados para a conexão também é dependente do componente, o que nos leva a entrar em mais detalhes somente no capítulo 5.
4.5.2 A camada de Sessão
A camada de sessão é responsável pela identificação dos dados transmitidos no ambiente colaborativo. Numa sessão colaborativa, é possível que mais de um exame esteja sendo visualizado. Cada um dos exames é definido como um contexto, e cada um dos contextos possui uma etiqueta de identificação.
Figura 6 – Pacote de Sessão.
O pacote de sessão demonstrado na figura 6 é usado para identificação dos dados transmitidos em cada sessão. Sua estrutura está definida na tabela abaixo.
Tabela 4 – Descrição dos Campos do pacote de Sessão.
Campo do Pacote Descrição
CTRL Campo de controle. Identifica se o pacote está sendo utilizado para transferência de dados ou negociação de uma nova etiqueta.
TAG Este campo contém a etiqueta que identifica o contexto dos dados contidos no pacote.
SIZE O campo SIZE enumera o tamanho em bytes do campo DATA
DATA Os dados a serem enviados ao contexto TAG. Normalmente é um pacote da camada superior, um pacote de aplicação.
Certamente, um contexto não precisa ser necessariamente uma ferramenta de visualização. Desta forma, outras ferramentas podem ser definidas como um contexto, deixando em aberto um espaço para extensão das capacidades do protocolo, assim como seu aspecto genérico.
As etiquetas são guardadas em uma tabela de correlação, para que possam ser relacionadas com cada contexto aberto durante uma sessão. Elas são descartadas assim que um contexto é fechado. Assim uma etiqueta pode ser utilizada várias vezes numa mesma sessão, para contextos diferentes.
O pacote de sessão é utilizado para encapsular os dados para a camada de aplicação, assim como para retornar dados recebidos pela interface de transporte. Esta pode acessar a camada de sessão através de algumas primitivas, definidas na tabela abaixo.
Tabela 5 – Primitivas da camada de Sessão.
Primitiva Descrição
S-CCONNECT O protocolo tentará se conectar a outro. Faz interface direta com a camada de transporte. Equivale a diretiva C-CONNECT
Primitiva Descrição
da mesma.
S-CWAIT O protocolo esperará por uma conexão de outro. Faz interface direta com a camada de transporte. Equivale a diretiva C-WAIT da mesma.
S-CCON-SUCCESS
O canal de comunicação foi estabelecido com sucesso.
S-TAG-WAIT O protocolo de aplicação espera por uma nova etiqueta, a ser negociada pelo protocolo de sessão.
S-TAG-REQ O protocolo de aplicação envia uma requisição de etiqueta.
S-TAG-SUCCESS
Uma etiqueta foi devidamente negociada.
C-SUCCESS O protocolo de aplicação conectou-se com sucesso e entra em estado inativo.
A figura 7 mostra o diagrama de estados para estabelecimento de conexão entre dois softwares utilizando o protocolo, juntamente com a definição da primeira etiqueta utilizada em uma sessão, uma etiqueta de controle.
Figura 7 – Diagrama de estados para uma conexão direta.
Tabela 6 – Estados durante o estabelecimento de uma conexão direta.
Estado Descrição
q0 Conexão não estabelecida.
q1 Esperando por estabelecimento de conexão. q2 Estabelecendo conexão
q3 Requerendo uma nova etiqueta, a ser usada para controle do protocolo de aplicação.
q4 Esperando pela etiqueta de controle. q5 Conexão estabelecida.
4.5.3 A camada de Aplicação
A camada de aplicação é responsável pela interface entre o protocolo e o usuário. Isto significa que é nesta camada que os dados a serem transmitidos durante uma sessão colaborativa devem ser capturados e encapsulados, assim como precisam ser interpretados ao serem recebidos das camadas inferiores através de um canal de comunicação.
Para isto, os tipos de informação a serem transmitidas precisam ser inicialmente classificadas. Considerando a análise feita da estação radiológica CMS, podemos identificar os tipos de informação envolvidos:
• dados sobre o posicionamento do ponteiro do mouse. • dados sobre a ferramenta de visualização.
• dados sobre as ferramentas de manipulação. • dados sobre o controle da aplicação.
• o diálogo entre os usuários do protocolo.
Esta classificação está diretamente ligada ao contexto de uso da estação radiológica, à exceção dos diálogos e do controle da aplicação, neste caso a ferramenta de visualização. Se outro contexto estivesse disponível para teste, certamente outros tipos de informação seriam levantados. Cada tipo enunciado aqui também agrega um grande número de operações possíveis sobre a informação propriamente dita.
Desta forma, o pacote de aplicação utilizado para trocar informação entre os contextos pode ser visto abaixo.
Figura 8 – Pacote de Aplicação.
O primeiro campo do pacote de aplicação, representado na figura 8, é o campo CMD. Ele identifica o tipo de operação sobre a informação a ser transmitida. No caso do contexto descrito, pode ser referente à ferramenta de visualização, às ferramentas de manipulação ou ainda controle da aplicação. O campo SUBC identifica a operação propriamente dita, a ser executada no recebimento ou que foi capturada para transmissão. O último campo, DATA, possui os dados capturados necessários para a reprodução da operação pelo protocolo.
O campo SUBC pode ter um comportamento diverso, dependendo da necessidade do campo CMD. Por exemplo, quando o campo CMD define uma transmissão de conversa textual, o campo SUBC pode ser ignorado, pois o campo DATA certamente conterá o texto da mensagem.
Quando CMD identifica dados de controle, SUBC terá uma das operações descritas na tabela X.
Tabela 7 – Operações do campo de controle SUBC.
Operação Descrição
SESSION_CONTROL Indica que um dos hosts está tomando ou liberando o controle da sessão. O Campo DATA tem 0 (zero) bytes.
NUMBER_OF_FILES Indica à aplicação que uma transferência de arquivos será iniciada. O campo DATA possui 4 bytes, contendo o número de arquivos a serem enviados ou recebidos.
ocorrendo. O campo DATA possui informação sobre o nome do arquivo, seu tamanho e o arquivo em si.
DISCONNECT Indica o fim da sessão, sendo todos os recursos utilizados durante a mesma liberados.
O mesmo se dá com o campo CMD preenchido com a máscara que identifica a manipulação dos dados. O campo SUBC terá uma das operações descritas na tabela X.
Tabela 8 – Descrição dos campos SUBC de manipulação.
FIELD DESCRIPTION
GENERIC_TOOL Indica a seleção de uma das ferramentas disponíveis para uso.
COLOR_TOOL Se a ferramenta for uma ferramenta de overlay uma cor para a mesma pode ser selecionada. KEY_TOOL Indica que a ferramenta para anotações textuais
sobre o exame está em uso.
MOUSE_TOOL Provém a posição de uma ferramenta apontadora, em tempo real. Isto permite que o usuário com o controle da sessão aponte uma área de interesse no exame, assim como outras iterações em tempo real.
Em relação ao campo MOUSE_TOOLS, podemos ressaltar que toda a iteratividade em tempo real provida pelo protocolo pode ser especialmente visualizada por esta ferramenta. Todos os movimentos do mouse do usuário, que possui o controle da sessão no momento, são capturados e transmitidos para os outros clientes envolvidos. A propagação destes movimentos é o que passa a sensação mais direta de iteratividade aos usuários.
5 Testes.
Segundo a metodologia tomada para o desenvolvimento, a programação orientada a testes, todo código gerado deve ser oriundo da programação de um teste. Com isto, o protótipo gerado realmente foi feito a partir de ciclos incrementais de teste, como descrito a seguir.
5.1 Programação Orientada a Testes
A programação orientada a testes é uma metodologia com passos bem definidos, onde todos os testes geram código, e todo código gerado a partir de um teste não deve alterar o funcionamento dos demais testes. Isso significa que sempre que for feito uma nova parte do software, ele deverá continuar passando em todos os testes.
Observando o modelo projetado para o protocolo, vemos que ele é dividido em duas camadas, cada uma com duas partes (a camada propriamente dita e uma interface). Desta forma o planejamento de testes foi dividido também para cada uma destas partes. Por motivo de documentação, descreveremos os mesmos aqui de forma seqüencial, e não incremental, como definido pela metodologia.
5.1.1 Testes da Interface de Transporte
Os primeiros testes planejados foram os testes para a interface de transporte. Como se trata de uma interface, todos os testes neste ponto precisavam ser simulados.
Inicialmente, fez-se uma unidade de testes para as três primitivas relacionadas à conexão: C-CONNECT, C-LISTEN e C-DISCONNECT. O primeiro teste simulava o estabelecimento da conexão, assim como a desconexão bem sucedida. Cada uma destas diretivas foi ostensivamente testada até se observar a robustez de cada chamada a elas. Terminados os
testes com estas diretivas, estendeu-se esta unidade de testes para que ela simulasse também as primitivas C-SEND e C-RECEIVE.
Neste ponto, já possuíamos o código para a interface da camada de transporte com a camada de sessão, e esta também poderia começar o seu ciclo de testes.
5.1.2 Testes da Camada de Sessão
A primeira unidade de testes gerada para a camada de sessão testava a passagem transparente das primitivas CCONNECT, CWAIT e S-CDISCONNECT. Pela simplicidade destes testes, o código gerado a partir dele estava pronto rapidamente. A interface gráfica destes testes pode ser vista na figura 9.
Figura 9 – Um protótipo inicial para os testes do Protocolo de Sessão.
Agora as primitivas a serem testadas não podiam mais ser simuladas, pois nelas deveria estar o comportamento básico do protocolo. Nesse escopo, os cabeçalhos de controle descritos no anexo X tiveram métodos de comparação desenvolvidos a partir de testes utilizando máscaras.
Com os cabeçalhos testados, o próximo passo foi criar testes para a negociação de contexto da sessão. A partir destes testes é que se observou a
necessidade de algumas das estruturas definidas no código, como o registro para o contexto. Estes testes são mostrados na figura 10.
Figura 10 – Ultima unidade para os testes do protocolo de sessão.
A estrutura do protocolo possibilita a extensão do mesmo, e como requisitos para uma implementação futura, foram testadas primitivas para compactação dos dados transmitidos e cifragem dos mesmos.
À medida que novas funcionalidades do protocolo iam surgindo na implementação, novas unidades de testes eram construídas. Ao final, temos uma unidade de testes para o protocolo de sessão, que já garante o funcionamento do mesmo em vários dos aspectos necessários para a comunicação entre as camadas de aplicação, que agora pode ser gerada também a partir de testes.
5.1.3 Testes da Camada de Aplicação
Com os serviços da camada de sessão disponíveis depois dos seus testes prontos, pôde-se iniciar a programação dos testes da camada de aplicação. Aqui a abordagem foi um pouco diferente, pois se procurou disponibilizar primeiramente a interface com os serviços que vão ser usados pelo protocolo.
Com esta interface pronta, cada um dos serviços foi sendo gerado a partir dos testes.
Figura 11 – Unidade de testes para o protocolo de aplicação.
Esta unidade de testes serviu para confirmar a funcionalidade das funções geradas para o tratamento de mensagens para as ferramentas de conversa textual, conversa de voz, posicionamento do mouse e algumas ferramentas de desenho.
Neste momento já possuímos o protocolo interpretando todos os requisitos básicos levantados para o seu projeto. Agora é viável pensar na sua validação em um software radiológico, no caso o CMS com a SLV.
5.2 Eficiência do Protótipo
O protótipo do protocolo foi derivado diretamente dos testes. Para efeitos de comparação, consideramos a quantidade de informação útil transmitida.
Para uma aplicação em tempo real, o menos sempre significa mais. Se observarmos um aplicativo colaborativo que se utiliza de stream de vídeo, cada imagem é tratada e enviada repedidas vezes para os clientes envolvidos na sessão. Toda essa informação é útil, mas a qualidade é baixa se a quantidade de banda de transmissão for baixa. A figura abaixo exemplifica o que seria uma seqüência de pacotes da camada de aplicação desse software.
Figura 12 – Seqüência de pacotes de stream de vídeo.
Basicamente, uma imagem nova é enviada a cada ciclo de pacotes, gerando uma sobrecarga na rede neste instante. Cada um dos pacotes com os dados de atualização indicam modificações menores na imagem para os pixels do próximo quadro. Estas modificações são aproximadas, o que degrada a qualidade da imagem visualizada.
No protótipo desenvolvido nos testes, as imagens são modificadas in loco, não sendo necessário reenviá-las a cada alteração. Isto gera uma quantidade de tráfego extremamente baixa na rede, se compararmos com o exemplo da figura 12.
6 Sala de Laudos Virtual
A SLV foi primeiramente desenvolvida por John A. F. Mendes, como proposta de dissertação de mestrado. Feita como uma extensão para a ferramenta de visualização de imagens Cyclops Personal, no entanto, as características necessárias para que um laudo a distância pudesse ser realizado com sucesso não chegaram a ser completadas em sua totalidade. A causa disto não estava diretamente ligada a SLV em si, mas sim a versão do Cyclops Personal disponível até então para o desenvolvimento da ferramenta.
Até o final de 2003, o Cyclops Personal ainda estava em desenvolvimento. Algumas das ferramentas de alteração das imagens ainda não estavam funcionando no sistema, como a de desenho. Também nesta mesma época, foi decidido pelos integrantes do Projeto Cyclops que seria projetado um framework para a criação de ferramentas para tele medicina, o CMS. Com isto, o desenvolvimento do Cyclops Personal foi interrompido e suas funcionalidades integradas ao desenvolvimento do CMS. A SLV foi finalizada em fevereiro de 2004, com a versão do Cyclops Personal disponível.
O novo framework estava praticamente concluído no final de 2004. Em outubro deste mesmo ano, já possuía uma ferramenta de visualização de imagens complementada pelas ferramentas de desenho em pleno funcionamento.
Ao analisarmos comparativamente o Cyclops Personal e o CMS, verificamos muitas diferenças. A forma como a ferramenta de visualização é programada no Cyclops Personal é bastante diferente, e dificulta em muito o reaproveitamento do código feito anteriormente.
6.1 Uma Sessão de Laudo Colaborativo
O funcionamento da SLV segue uma seqüência de acontecimentos de razoavelmente curta. Primeiro, um usuário escolhe através da interface de filtragem as imagens relevantes ao laudo colaborativo. Outros usuários conectam-se a SLV do primeiro ou são conectados através do software
gerenciador de sessões. Os arquivos escolhidos são transmitidos para todos os que ainda não os possuírem, e a sessão tem início.
Durante a sessão, o módulo de voz sobre IP pode ser ativado se requerido pelos usuários, ou então eles podem trocar informações através da janela de conversa textual. Alterações podem ser feitas nas imagens, e serão reproduzidas em todas as SLV’s conectadas.
6.2 Modelo Proposto para SLV
A SLV foi projetada para agir transparentemente, assim como o protocolo. A idéia é que o usuário tenha a impressão de que esteja simplesmente utilizando o CMS, simultaneamente participando de uma conversa sobre o caso estudado. Para passar esta sensação ao usuário, as únicas necessidades para o funcionamento da SLV são apenas alguns controles na interface e, se não estiver disponível a conversa de voz, uma janela para conversa textual.
As características dos sistemas mencionados anteriormente levaram a uma remodelagem quase completa da SLV para a integração com o CMS. Todo o código para captura de informações terá que ser refeito, pois suas principais funções são derivadas da ferramenta de visualização. O protocolo para comunicação entre as aplicações será o recém desenvolvido Cyclops Application Protocol.
6.3 Protótipo Implementado
O código gerado nos testes descritos no capítulo 5 foi utilizado para implementar o novo protocolo para a SLV. Todo o protocolo anterior foi descartado. O código foi integrado ao sistema e foram criadas interfaces para a conexão entre duas SLV’s.
Figura 13 – Interface de conexão para registrar-se em uma Sessão.
Figura 14 – Interface de conexão para criar uma Sessão.
Para tornar transparente ao usuário as ferramentas de manipulação, optou-se por encapsular as mesmas durante a optou-sessão colaborativa. Assim, foram feitos encapsuladores para a janela de visualização. Com os interpretadores de comandos funcionando, temos uma SLV transparente à vista do usuário.
Figura 15 – Interface do CMS sem a SLV
Visualmente, a única diferença é a barra de controle adicionada ao menu do CMS. Porém, tudo que é feito em um visualizador no CMS está encapsulado de forma a ser reproduzido em todas as SLVs conectadas em uma sessão.
Num caso de uso do CMS sem a SLV os visualizadores recebem a entrada do usuário diretamente e processam essa entrada como mostra a figura 17.
Figura 17 – CMS sem a SLV
Quando usando a SLV os visualizadores tem, cada um, suas interfaces de entrada cobertas com um encapsulador que intercepta esta entrada do usuário. Isto é feito caso o usuário possua o privilégio necessário para realizar tal entrada, ou seja, possui o controle da sessão.
As informações de entrada são reproduzidas pelo encapsulador, tal como se fosse o próprio usuário, e envia uma notificação às demais SLVs conectadas a ocorrência desta entrada, reproduzindo a entrada nos seus respectivos visualizadores, como visto na figura 18, de maneira a simular uma entrada comum de um usuário em frente a máquina.
Figura 18 – CMS com a SLV
Em anexo, um pequeno manual de uso do protótipo produzido para validação do protocolo.
7 Conclusões sobre o trabalho
Ao final dos ciclos de iteração chegou-se a um protótipo bastante eficiente, com um protocolo genérico passível de ser estendido e implementado para outras plataformas radiológicas.
Nos anexos, se encontra a documentação mais detalhada sobre o código gerado e o projeto do protocolo.
Pode-se dizer com segurança que os objetivos propostos pelo projeto foram alcançados. As sessões a seguir descrevem um pouco mais os resultados obtidos.
7.1 Eficiência do Protótipo
O protótipo derivado dos testes de unidade até a primeira versão mostrou-se bastante fiel as necessidades citadas nos requisitos do sistema. A quantidade de dados transmitidos durante a sessão mostrou-se mínima, como visível na figura 12 explicado no capítulo 5.2.
A única demora em relação à velocidade de transmissão está no compartilhamento de arquivos dos exames, o que não chega a ser um inconveniente. Isto está diretamente relacionado com a capacidade de download do cliente que não possui os mesmos. Porém, a transmissão prévia dos exames é o que garante a qualidade da sessão colaborativa.
7.2 Trabalhos Futuros
A interface com a camada de transporte pode ser readaptada para sessões multiponto, ou seja, que envolvem mais do que dois clientes simultaneamente, por isto ser uma característica latente da camada de transporte. A diferença básica estaria na hora de enviar os pacotes, onde se precisaria ter uma lista de clientes que estão envolvidos na sessão.
Outro objetivo a ser alcançado seria adicionar outras estruturas DICOM além das já suportadas, aumentando as capacidades do protocolo desenvolvido.
Bibliografia
[1] ABDALA, Daniel D. Cyclops Personal. Uma Ferramenta para
Gerenciamento e Visualização de Imagens Médicas no Padrão DICOM 3.0 (Trabalho de conclusão de curso – Ciências da Computação),
Universidade Federal de Santa Catarina, Santa Catarina, 2002.
[2] DELLANI, Paulo. Desenvolvimento de um Servidor de Imagens Médicas
Digitais no Padrão DICOM. Dissertação de Mestrado – 2001.
[3] Mendes, John A. F. Telemedicina: Sala de Laudos Virtual, uma Proposta
para Teleradiologia. Dissertação de Mestrado. Universidade Federal de
Santa Catarina. Fevereiro de 2004.
[4] HL7: Health Level 7. Disponível em: <http://www.hl7.org/>. Acesso em: 12 abr. 2006.
[5] ACR: American College of Radiology. Disponível em: <http://www.acr.org>. Acesso em: 12 abr. 2006.
[6] NEMA: National Electrical Manufacturers Association. Disponível em: <http://www.nema.org>. Acesso em: 12 abr. 2006.
[7] DICOM Part 1: Introduction and Overview. Disponível em:
<http://medical.nema.org/dicom/2004/04_01PU.PDF>. Acesso em: 12 abr. 2006.
[8] CLUNIE, David. Medical Image Format FAQ. Disponível em:
[9] ISO: International Organization for Standardization. Disponível em: <http://www.iso.org>. Acesso em: 12 abr. 2006.
[10] TANEMBAUM, Andrew S. Reference Models: The OSI Reference Model. In: Computer Networks, Fourth Edition. 3. ed.: Prentice Hall, 2004. Cap. 1, p. 39-41.
[11] IETF: The Internet Engineering Task Force. Disponível em:
<http://www.ietf.org>. Acesso em: 12 abr. 2006.
[12] POSTEL, Jonathan B. TRANSMISSION CONTROL PROTOCOL.
Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc793.txt>. Acesso em: 12 abr. 2006.
[13] BRADEN, R. (Ed.). Requirements for Internet Hosts - Communication
Layers. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc1122.txt>. Acesso
em: 12 abr. 2006.
[14] JACOBSON, V.; BRADEN, R.; BORMAN, D. TCP Extensions for High
Performance. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc1323.txt>.
Acesso em: 12 abr. 2006.
[15] POSTEL, Jonathan B. Internet Protocol. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc791.txt>. Acesso em: 12 abr. 2006.
[16] TANEMBAUM, Andrew S. Reference Models: The OSI Reference Model. In: Computer Networks, Fourth Edition. 3. ed. : Prentice Hall, 2004. Cap. 5.6, p. 330-357.
[17] POSTEL, Jonathan B. User Datagram Protocol. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc768.txt>. Acesso em: 12 abr. 2006.
[18] POSTEL, Jonathan B; REYNOLDS, J. File Transfer Protocol. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc959.txt>. Acesso em: 12 abr. 2006.
[19] KLENSIN, J. (Ed.). Simple Mail Transfer Protocol. Disponível em: <ftp://ftp.rfc-editor.org/in-notes/rfc2821.txt>. Acesso em: 12 abr. 2006.
[20] DICOM Part 3: Information Object Definitions. Disponível em: <http://medical.nema.org/dicom/2004/04_03PU3.PDF>. Acesso em: 12 abr. 2006.
[21] Extreme Programming. Disponível em:
<http://xp.edugraf.ufsc.br/bin/view/XP/WebHome>. Acesso em: 12 abr. 2006.
[22] Cyclops Medical Station. Disponível em
Anexos
Anexo 1 - Requisitos do sistema
Os seguintes requisitos foram levantados a partir dos requisitos descritos na dissertação de mestrado de John A. F. Mendes. Alguns deles foram modificados ou não se aplicavam mais ao escopo deste sistema. Os requisitos também foram levantados em reuniões com o orientador, co-orientador e pesquisadores deste projeto.
Requisitos funcionais
ID Descrição Classificação
R.F.1 Para iniciar a SLV, o usuário deve escolher criar a sessão ou se conectar a uma sessão.
R.F.2 Ao optar por se conectar a uma sessão o usuário deve informar um nome (ou apelido) para identificá-lo em um meio de comunicação textual, e o nome do servidor (ou endereço IP) onde está sendo criada a sessão a qual se conectar.
Conectar a uma Sessão
R.F.3 O usuário deve optar por realizar a conexão (uma vez fornecidos nome do usuário e endereço do servidor) ou cancelar o processo de conexão.
Conectar a uma Sessão R.F.4 Ao optar por criar uma sessão da SLV o usuário deve
selecionar as imagens de interesse e informar um nome (ou apelido) para identificá-lo em um meio de comunicação textual.
Criar uma Sessão
R.F.5 Ao optar por criar uma sessão da SLV, se já houver ao menos uma série aberta o usuário será questionado se quer escolher imagens dentre as séries já abertas no CMS, caso contrário (ou
Criar uma Sessão
resposta negativa) será questionado se deseja escolher imagens das séries armazenadas na base de dados local.
R.F.6 Durante o processo de seleção das imagens de
interesse deve ser possível selecionar imagens individuais, selecionar todas as imagens, remover imagens individuais da seleção ou todas de uma vez.
Criar uma Sessão
R.F.7 O usuário deve optar por esperar pela conexão de outro (uma vez selecionadas as imagens de interesse e fornecido o nome do usuário) ou cancelar o processo criação de sessão.
Criar uma Sessão
R.F.8 Uma vez estabelecida uma conexão entre duas SLVs deve ser estabelecido um meio de comunicação textual e proceder-se com a transmissão das imagens de interesse.
Inicio da Sessão
R.F.9 Um dos usuários envolvidos pode a qualquer
momento tomar o controle da sessão (salvo ocasião em que esta já estiver de posse de algum outro usuário) e quando tiver terminado de fazer uso deste privilégio liberar o controle da sessão para que um outro (ou ele mesmo) possa tomá-lo em algum momento futuro.
R.F.10 Apenas o usuário com o controle da sessão deve poder alternar entre as imagens de interesse, bem como ter controle das ferramentas disponíveis no CMS (dentre elas: ferramentas de desenho, lupa, zoom, pan, janelamento, rotação das imagens, alterar a ordem de exibição, reconstrução multiplanar, etc.).
R.F.11 Quando um usuário fizer uso de alguma ferramenta do CMS durante a sessão o efeito deste uso deve ser
