O DataTORM no contexto do projeto do ToRM-

O projeto de desenvolvimento e construção do ToRM-05 consiste de uma evolução do sistema ToRM-005 já em funcionamento. As duas principais alterações são:

• mudança da freqüência de operação para 21 MHz; e

• mudança para uma plataforma computacional baseada em microcomputadores IBM/PC compatíveis.22

A tabela a seguir resume as especificações propostas para o sistema:

Tabela 17 - Especificações do sistema ToRM-05

Item Especificação

Campo 0,5 Tesla em um magneto supercondutor de corpo inteiro Freqüência de

operação

21 MHz Seqüências de

exame

Spin-Echo Multi-slice e Multi-Echo, Gradient Recalled Echo, Inversion Recovery e Steady State Free Precession

Item Especificação

Tempo de exame SE/MS/1000/100: 4 minutos. Scout view: 15 segundos Resolução no plano: 3 mm. Espessura da fatia: 5 mm

Matriz de aquisição 2D 256 x 128 ou 256 x 256 3D 256 x 128 x 64

Orientação das fatias Oblíqua qualquer

Armazenamento Magnético de 2 Gbytes. Magneto-ótico com disco removível de 258 Mbytes

Impressão Dry silver print (processo Kodak) Computador

principal

IBM/PC compatível com processador da família Pentium/Intel

Sistema operacional Windows 95

Do ponto de vista deste trabalho, o aspecto mais importante é a nova plataforma computacional. A Figura 31 a seguir descreve a arquitetura básica do sistema. Um microcomputador com um processador Pentium de 166 MHz será dedicado exclusivamente à operação do sistema. Após cada estudo, os dados adquiridos são enviados para outro microcomputador que exercerá o papel de estação de consulta principal, onde os dados serão armazenado no banco de dados DataTORM. As duas estações estarão ligadas entre si por uma rede Ethernet de 10 Mbps. Em uma rede separada, mas com acesso à estação de consulta, poderão ser conectados outros computadores que poderão ter acesso aos resultados remotamente.

Ethernet Ethernet Laptop remoto Microcomputador remoto Estação remota Outros subsistemas do tomógrafo Servidor Impressora Banco de Dados Câmara Multiformato Espectrômetro Estação de operação CD Magneto-ótico

Figura 31 - Configuração dos computadores que compõem o ToRM-05.

Na estação de operação estarão instalados três módulos de programa principais:

• SPECTOS: programa o espectrômetro para a aquisição;

• TORMOCX: controla a aquisição dos dados provenientes do espectrômetro e

processa os dados;

• TORMGUI: interface com o usuário responsável pela coordenação geral da

operação do sistema.

Na estação de consulta estará o sistema de banco de dados DataTORM e nela poderão ser acoplados equipamentos para impressão dos resultados e armazenamento em meios removíveis.

Os módulos de programa estão organizados em uma estrutura de camadas estabelecida para promover uma independência funcional entre estes módulos e, conseqüentemente, facilitar o desenvolvimento. A Figura 32 a seguir, inspirada no modelo de referência ECMA/NIST, usado originalmente para descrever ambientes integrados de engenharia de programação,23 _{apresenta a arquitetura básica dos}

mesmo computador ou se estão instalados em computadores diferentes ligados por rede.* BD - DataTORM Jet Engine WINDOWS SGBD - DataTORM TORMGUI TORMOCX SPECTOS Visualização

Figura 32 - Diagrama dos módulos de programa do sistema ToRM-05.

Na base da figura está o sistema operacional Windows 95, que gerencia a utilização dos recursos do computador e proporciona os meios de comunicação entre os diversos módulos de programa do sistema. Durante a operação do sistema de MRI, o usuário interage principalmente com o módulo TORMGUI, que incorpora e executa um modelo completo de operação do tomógrafo, sendo ele o responsável por ter acesso e utilizar os demais módulos de programa de maneira transparente ao usuário. Os dados são armazenados em arquivos de banco de dados relacionais do

* _{Ao contrário do modelo de referência ECMA/NIST, o DataTORM não é um repositório de objetos}

distribuídos que pode ser utilizado por todas as aplicações de maneira transparente e automática. Uma representação mais fiel seria colocar o DataTORM como uma aplicação adicional, juntamente com os módulos SPECTOS, TORMOCX e um módulo de visualização, e, na parte posterior da Figura 32, substituir o Jet Engine pelos módulos de OLE 2.0 e colocar no lugar do BD - DataTORM os objetos a serem distribuídos, como, por exemplo, o objeto “Dados”, proposto na seção 3.3.2.2, que pode ser utilizado para manipular os dados não-convencionais. O OLE 2.0 é parte de um padrão proprietário de objetos distribuídos chamado DCOM24 _{e que opera na plataforma Windows. Outras}

possíveis escolhas poderiam ser os padrões CORBA25 _{ou CORBAmed,}26 _{que são padrões abertos de}

objetos distribuídos. O propósito da figura mencionada, da maneira como ela está, é apenas destacar as diversas partes do DataTORM do restante dos módulos de programa do sistema ToRM-05.

DataTORM. O acesso a estes dados é feito através do SGBD Jet Engine* _{pelo SGBD}

DataTORM desenvolvido no MS Access 2.0, ou por um outro aplicativo capaz de utilizar o SGBD Jet Engine para ter acesso ao BD DataTORM, como, por exemplo, pelo TORMGUI,

O TORMGUI utiliza os módulos SPECTOS e TORMOCX para interagir com o espectrômetro e processar os dados de aquisição. O SGBD DataTORM é um aplicativo de banco de dados para ter acesso aos dados de forma independente. Outros módulos podem ser inseridos nesta estrutura, sejam eles produtos comerciais comprados ou aplicativos desenvolvidos localmente, como, por exemplo, um aplicativo responsável para visualização de imagens de MRI que está sendo desenvolvido.

A decisão de projeto referente a escolha da plataforma computacional limitou o número de possíveis escolhas para as ferramentas de desenvolvimento do DataTORM. Para facilitar a implementação do SBD, decidiu-se por utilizar um SGBD comercialmente disponível e conhecido. O produto escolhido foi o MS Access 2.0.† _{A escolha foi baseada no fato do produto ser da empresa Microsoft e, como}

outros produtos desta empresa já estavam sendo utilizados para o desenvolvimento de programas do ToRM-05, esperava-se assim facilitar a compatibilidade entre os vários subsistemas de programa. Outra razão era a simplicidade de aprendizado e uso do produto. Ele foi usado, então, para construir o BD e para implementar a aplicação de banco de dados que serve de interface com o usuário.

Alguns meses mais tarde foi lançado nos Estados Unidos da América o produto FoxPro 3.0 que, em parte, atenderia os requisitos relativos ao armazenamento e manipulação de dados não convencionais. Como levaria muito tempo para se importar este programa ou esperar que fosse lançado no mercado nacional, a sua utilização foi descartada. Aproximadamente um ano depois desta escolha, foi lançada uma nova versão do MS Access, a versão 7.0, também chamado de MS Access 95. Esta versão inicial possuía problemas de “vazamento de memória”,

* _{O Jet Engine é o SGBD utilizado pelo MS Access e pelo MS Visual Basic. O Apêndice IV,}

Microsoft Access Versão 2.0, fornece detalhes adicionais sobre este módulo.

† _{O Apêndice IV, Microsoft Access Versão 2.0, fornece alguns detalhes adicionais sobre este}

que consumia rapidamente os recursos do sistema operacional disponíveis para a aplicação. Este era um problema grave que não ocorria na versão 2.0 do produto. Por esta razão, e apesar das diversas melhorias desta nova versão, decidiu-se manter o desenvolvimento na versão 2.0 do MS Access.

3.3 Proposta para o sistema de banco de dados

3.3.1 Descrição dos modelos de dados