Relatório do Trabalho Final da Disciplina de Engenharia de Software de Componentes

Transcrição

1 Relatório do Trabalho Final da Disciplina de Engenharia de Software de Componentes 1. Proposta de trabalho final: Thiago Coelho Prado Configuração em tempo de compilação de um servidor de imagens médicas no padrão DICOM (Digital Imaging and Communications in Medicine), desenvolvido pelo Laboratório de Telemedicina (LabTelemd/HU) pertencente ao Grupo Cyclops Especificação do servidor: O padrão DICOM descreve formalmente uma série de padrões internos, como o formato de imagens médicas que os aparelhos devem disponibilizar, protocolo de comunicação entre cliente e servidor, além de especificações de segurança e web services. Esse servidor deve realizar alguns serviços básicos: Store: armazenamento de exames Find: busca de atributos de exames Move: cópia de exames entre servidores Echo: verificação de disponibilidade do servidor Além da especificação formal, o servidor desenvolvido propõe mais duas features: Portal de Laudos: possibilita ao médico executor acessar um portal web, em que se encontram exames médicos, e dar laudos. Com isso não é necessário a presença do médico no hospital ou clínica. Armazenamento em Arquivo de Disco: permite a gravação de exames em mídias. 2. Problema: 2.1. Cenário: O serviço de armazenamento (Store) utiliza para persistência de dados a forma de banco de dados relacional (PostgreSql). A figura abaixo mostra o fluxo de exames mensal pertencentes à RCTM (Rede Catarinense de Telemedicina) Feb-08 Apr-08 Jun-08 Aug-08 Oct-08 Dec-08 Feb-09 Jan-08 Mar-08 May-08 Jul-08 Sep-08 Nov-08 Jan-09 Mar-09 Medicina Nuclear Tomografia Ultra-som

2 As imagens armazenadas não podem ser removidas do banco de dados por no mínimo 5 anos, porém esse tempo de armazenamento pode aumentar dependendo da modalidade do exame (Tomografia Computadorizada, Ressonância Magnética, Medicina Nuclear, etc. ). Como consequência, o custo de armazenamento tende a aumentar. Para resolver esse problema estão sendo estudadas técnicas de armazenamento alternativas ao banco de dados relacional. Em uma dessas técnicas, a imagem médica é armazenada em um formato hierárquico chamado HDF (Hirarchical Data Format - mantido pela Universidade de Illinois). A decisão entre qual forma de armazenamento será realizada é feita através da configuração de um arquivo que é lido pelo servidor. Além disso, o servidor apresenta duas features (Persistência em Disco e Portal de Laudos) que são configuradas através de um mesmo arquivo. Com o modelo atual de configuração do servidor, há códigos objeto que não são necessários, pois o modelo de armazenagem HDF e o modelo de banco de dados relacional são excludentes. Há também as features, que eventualmente podem nem ser utilizadas Solução apresentada: Para a solução desse problema será utilizado AOP (Aspect-Oriented Programming). O modelo de armazenamento será tratado como um aspecto da aplicação. Teremos 1 weaving principal, que se trata do modo de armazenamento e 2 weavings secundários que são das 2 features. O arquivo de configuração ainda existe, mas apenas contém informações necessárias que podem mudar, como servidor que possui a base de dados de exames dicom (ip, porta, nome da base), do armazenamento hdf (caminho do armazenamento), base de dados do portal (ip, porta, nome da base) e caminho para o arquivo em disco. Para não haver complexidade no trabalho será aplicado AOP apenas nos serviços de armazenamento (Store) e busca por atributo (Find). 3. Modelagem: Nessa seção são mostradas as modelagens conceituais referentes ao trabalho Entidades de Domínio Nessa modelagem vemos que há 2 serviços sendo utilizados. O primeiro trata-se do serviço de Store, que acessa as interfaces de armazenamento (BD relacional ou HDF) e as interfaces do portal e arquivo em disco. Já o segundo acessa apenas as interfaces das bases de dados dos exames médicos (novamente BD relacional e HDF).

3 3.2. Padrão de Projetos Como nos serviços tudo se trata de persistência e acesso de dados foi decidido que o serviço acesse apenas 1 interface (no modelo anterior o Store acessava 4 diferentes), concentrando assim os tipos de armazenamento em um lugar só. Os 3 weavings serão feitos apenas em 1 lugar. A interface para o serviços foi feita usando o padrão de projeto Facade. Ela provê um 2 métodos para o Store e Find. Além disso internamente provê as demais funcionalidades opicionais.

4 Diagrama de Classe Na figura abaixo temos os serviços acessando apenas uma interface e através dela sendo realizado os acessos as outras. O método store() além de executar as operações de BD relacional ou HDF chamará os métodos store(string) para armazenamento em disco e o senttoportal(informationobjectdefinition) para o portal de laudos Diagrama de Componentes Aqui temos cada um dos componentes que serão acessados. Os serviços irão utilizar o componente principal Storage, que será composto pelo componente Database ou HDF e que acessará outros 2 componentes Portal e DICOMTOFile.

5 3.4. Diagrama de Atividade Aqui temos um diagrama de atividades bastante simplificado. O servidor espera a conexão do cliente. Após isso o cliente envia a requisição do tipo de serviço (Store ou Find), que são realizados e após isso envia a resposta ao cliente, sucesso no caso do armazenamento ter ocorrido corretamente ou a informação requisitada caso tenha sido realizado um serviço de busca.

6 4. Códigos fonte: 4.1. Storage Facade: Aqui temos 2 construtores diferetentes. O primeiro para o serviço de Store que recebe os atributos remotos e locais ( calling e called AE Title respectivamente) que serão usados para verificar qual o tipo de configuração desejada refente ao armazenamento e o objeto que representa o exame médico e o segundo para o serviço de Find que recebe apenas a configuração local (called AE Title) e os atributos que serão utilizados na busca. Além disso provê os 2 métodos store e find (para o find é necessário ainda a invocação do método getresult()), que são definidos e invocam o storeweaved e findweaved, que ainda não tem definições (serão feitas durante o weaving), além de realizarem os serviços das features. 4.2 Aspectos do StorageFacade Os 2 header do aspecto (StorageFacadeDatabase e StorageFacadeHDF) contendo 2 pointcuts. Ambos usam a função call, para que os métodos storeweaved e findweaved sejam definidos. Os advices tratam de implementar a forma que o armazenamento será feito StorageFacadeDatabase O primeiro passo realizado para o armazenamento em BD relacional se dá transformando o objeto iod (Information Object Definition) que contém as informações do exame médico em representações na forma de objetos das tabelas do banco de dados relacional. Em seguida essas tabelas são repassadas

7 classe que acessará o banco de dados e realizará a tarefa. O seviço de busca repassa os atributos requeridos a classe responsável pelo acesso ao BD relacional, que por sua vez após realizar o serviço retorna um vetor contendo os resultados. Esse vetor pode ser acessado pela classe Find através do método getresult() provido pelo StorageFacade StorageFacadeHDF Similar ao BD relacional o serviço realizado para o armazenamento em HDF se dá transformando o objeto iod (Information Object Definition) que contém as informações do exame médico em representações na forma hierárquica que por sua vez acessa as classes responsáveis por esse tipo de armazenamento. O seviço de busca HDF ainda está sob desenvolvimento para atender as necessidades do serviço de Find, porém atuará de maneira similar provendo como retorno um vetor de resultados que pode ser acessado através do método getresult() provido pelo StorageFacade.

8 4.4 PortalAspect Aqui o pointcut definido utiliza a função execution, dentro da função já definida (store) e será executada após (after) a persistência dos exames médicos terem sidos realizadas. Após obter dados referentes a configuração do portal, o envio é realizado, podendo ser mais de 1 portal de laudos. 4.5 DICOMTOFileAspect O pointcut novamente é o método store e utiliza função execution e o código novamente é executado após (after) a persistência dos exames médicos terem sidos realizadas. A configuração descreve o caminho onde o exame médico deve ser armazenado e a classe IODToFile trata de transformar o iod em um arquivo seguindo o padrão DICOM. 5. Integração com ferramentas de compilação: Para funcionar de forma automatizada, foi feito a integração da ferramenta de aspecto com o CMAKE. A utilização é simples e atua em cima de variavéis que são definidas durante o processo de configuração. Exemplos de uso: cmake. -DDATABASE (usa apenas banco de dados relacional) cmake. -UDATABASE (usa apenas o armazenamento em HDF) cmake. -DDATABASE -DPORTAL -DDICOMTOFILE (bando de dados + portal + arquivo em disco) cmake. -UDATABASE -DPORTAL (HDF + portal)

9 O código abaixo é responsável pela chamada da ferramenta de aspect (ac++) e funciona verificando as variáveis definidas durante o processo de configuração. Ao final é montado o comando que a ferramenta vai utilizar com seus devidos parâmetros: arquivo de configuração da ferramenta (--config ) -p (caminho do projeto) -c (arquivo a ser compilado StorageFacade ) -o (arquivo resultado) -a (headers de aspecto StorageFacadeDatabase / StorageFacadeHDF, PortalAspect e DICOMTOFileAspect ) -I (includes) -v9 (verbosidade com maior nível de detalhamento) 6. Conclusão: A utilização de aspectos e a sua realização durante o tempo de compilação de forma automatizada facilitou a realização dos testes para verificar a validade da utilização de meios alternativos a banco de dados relacional no armazenamento de imagens médicas no padrão DICOM. Também tornou possível para o servidor que se encontra em produção a configuração de features que podem ou não ser requeridas, sendo assim se no futuro for surgir a necessidade de mais features, a inserção ou remoção será de forma mais fácil. 7. Referências: DICOM PostgreSql

10 HDF AspectC CMake