Servidor de imagem cl nica com motor de pesquisa baseado ... · condic~oes para conquistar uma...

Faculdade de Engenharia da Universidade do Porto

Servidor de imagem clınica com

motor de pesquisa baseado em

regras

Rui Filipe Monteiro Pinto

Relatorio de Projecto/Dissertacao realizado(a) no Ambito do

Mestrado Integrado em Engenharia Informatica

Orientador: Antonio Miguel Pontes Pimenta Monteiro (Doutor)

Julho de 2008

c© Rui Pinto, 2008

Servidor de imagem clınica com motor depesquisa baseado em regras


Relatorio de Projecto/Dissertacao realizado(a) no Ambito do

Mestrado Integrado em Engenharia Informatica

Aprovado em provas publicas pelo Juri:

Presidente: Jaime dos Santos Cardoso (Doutor)

Arguente: Carlos Manuel Azevedo Costa (Doutor)

Coordenador: Antonio Miguel Pontes Pimenta Monteiro (Doutor)

31 de Julho de 2008

Resumo

Este documento descreve o trabalho realizado no ambito do projecto de finalde curso na empresa Siemens S.A.. Este trabalho incidiu na deteccao e correccao deerros e no desenvolvimento de novas funcionalidades para uma ferramenta medica,que permite a obtencao de relatorios, com diagnostico, a partir de imagens medicase de informacao produzida por medicos. O objectivo deste documento e descrevero projecto e mostrar os contributos do autor para a ferramenta. O trabalho de-senvolvido procura melhorar as condicoes de utilizacao e de manutencao futura daferramenta em questao.

i

Abstract

This document describes the work in the project that take place in SiemensS.A. The projects’ scope are the detection and correction of bugs and developmentof new capacities of a medical tool, with the ability to create medical reports, withdiagnosis, from medical images and from information provided by physicians. Thegoal of this document is to give some insight into the work development and alsodescribing the author’s contribution to the tool. The work aims to improve the tool’sconditions for use and for future maintenance.

iii

Agradecimentos

Quero agradecer a Siemens S.A. e ao Eng. Antonio Martins por me terem aceitepara o projecto de final de curso.

Ainda na Siemens ao Eng. Pedro Almeida, pelo apoio prestado durante todo oprojecto, bem como ao Eng. Andre Ferreira pelas duvidas tiradas.

Ao meu orientador na FEUP, Dr. Antonio Miguel Pontes Pimenta Monteiro, pelaslinhas condutoras que me deu.

Sem nunca esquecer a famılia, que esteve sempre la. Ao Fernando Jorge CoutinhoMonteiro, pelo trabalho que teve de revisao.

Por fim os amigos e amigas que dao sempre a distraccao necessaria para relaxar.

A todos os que me apoiaram, um muito obrigado.

E claro, sem nunca esquecer todos os que fazem coisas para que o mundo sejamelhor.


v

Conteudo

Conteudo vii

Lista de Figuras ix

Abreviaturas xi

1 Introducao 11.1 Contexto/Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Projecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Motivacao e Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Estrutura da Dissertacao . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Revisao das tecnologias existentes 92.1 Aplicacoes concorrentes . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Rotinas de funcionamento existentes . . . . . . . . . . . . . . . . . . 11

2.2.1 Hospital de Vila Nova de Gaia . . . . . . . . . . . . . . . . . . 132.2.2 Hospital da Arrabida . . . . . . . . . . . . . . . . . . . . . . . 13

2.3 Tecnologias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.1 Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3 Especificacao e Descricao 153.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 Documentacao . . . . . . . . . . . . . . . . . . . . . . . . . . 153.1.2 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.1.3 Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.4 Globalizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.1.5 Outros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.3 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4 Implementacao - Trabalho Desenvolvido 214.1 Documentacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Manual de Instalacao . . . . . . . . . . . . . . . . . . . . . . . 224.1.2 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4.1.2.1 Representacao da arquitectura . . . . . . . . . . . . 254.1.2.2 Realizacao dos Casos de Uso . . . . . . . . . . . . . 284.1.2.3 Vista Logica . . . . . . . . . . . . . . . . . . . . . . 28

vii

CONTEUDO

4.1.2.4 Vista dos Processos . . . . . . . . . . . . . . . . . . 304.1.2.5 Vista de Instalacao . . . . . . . . . . . . . . . . . . . 314.1.2.6 Outros . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1.3 Levantamento das Licencas . . . . . . . . . . . . . . . . . . . 374.2 Insercao numa Metodologia de Desenvolvimento de Software . . . . . 38

4.2.1 Modelos de desenvolvimento . . . . . . . . . . . . . . . . . . . 394.2.2 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.3 Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Registos da aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.1 Escolha do Metodo . . . . . . . . . . . . . . . . . . . . . . . . 434.3.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . 434.3.3 Outros Resultados . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4 Configuracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.4.1 Fundo da Aplicacao e Output final . . . . . . . . . . . . . . . 50

4.4.1.1 O Que Envolve . . . . . . . . . . . . . . . . . . . . . 504.4.1.2 Possibilidades . . . . . . . . . . . . . . . . . . . . . . 544.4.1.3 Implementacao . . . . . . . . . . . . . . . . . . . . . 54

4.4.2 Gestao de Utilizadores . . . . . . . . . . . . . . . . . . . . . . 564.4.3 Logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564.4.4 Outros Parametros . . . . . . . . . . . . . . . . . . . . . . . . 56

4.5 Globalizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.5.1 Metodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 574.5.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.6 Apoio Tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.7 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Conclusoes e Trabalho Futuro 615.1 Cumprimento dos objectivos . . . . . . . . . . . . . . . . . . . . . . . 615.2 Perspectivas e sugestoes futuras . . . . . . . . . . . . . . . . . . . . . 62

Referencias 65

A Software Architecture Document 71

B Reporting Installation Manual 93

C Configurator User Manual 107

viii

Lista de Figuras

1.1 Exemplo de funcionalidades fornecidas ao utilizador. . . . . . . . . . . 41.2 Editor do Siemens Reporting (dados fıcticios). . . . . . . . . . . . . . 5

2.1 Sistema multi-proposito Artis Zee . . . . . . . . . . . . . . . . . . . . 102.2 Visao geral do DIGIMatic-MED . . . . . . . . . . . . . . . . . . . . . 102.3 Ferramenta de medicao do DicomWorks . . . . . . . . . . . . . . . . 112.4 Plugin para edicao de DICOMs no PowerPoint . . . . . . . . . . . . . 12

3.1 Descricao da arquitectura feita anteriormente . . . . . . . . . . . . . 16

4.1 Arvores das solucoes do servidor e cliente . . . . . . . . . . . . . . . . 224.2 Workflow que define a visao 4+1 da Arquitectura . . . . . . . . . . . 244.3 Visao geral da arquitectura . . . . . . . . . . . . . . . . . . . . . . . . 264.4 Visao geral das interaccoes com o exterior . . . . . . . . . . . . . . . 274.5 Visao geral das classes logicas . . . . . . . . . . . . . . . . . . . . . . 284.6 Decomposicao logica de um relatorio . . . . . . . . . . . . . . . . . . 294.7 Decomposicao logica do motor de mapeamento . . . . . . . . . . . . . 304.8 Decomposicao logica da geracao do relatorio . . . . . . . . . . . . . . 314.9 Vista dos processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.10 Vista de Instalacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.11 Implementacao das Regras de Mapeamento . . . . . . . . . . . . . . . 344.12 Implementacao da geracao de uma apresentacao flash do relatorio . . 354.13 Implementacao de ReportFlashGenerator . . . . . . . . . . . . . . . . 364.14 Separacao da base de dados . . . . . . . . . . . . . . . . . . . . . . . 384.15 Fluxo de trabalho do Scrum . . . . . . . . . . . . . . . . . . . . . . . 414.16 Exemplo simplificado de um log na hierarquia debug . . . . . . . . . 454.17 Actividades ate ao login . . . . . . . . . . . . . . . . . . . . . . . . . 464.18 Actividades desde a seleccao de um estudo ate a abertura do estudo

no editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.19 Actividades desde a seleccao de um estudo ate a abertura do estudo

no editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.20 Actividades associadas a gravacao . . . . . . . . . . . . . . . . . . . . 514.21 Sistema de ficheiros de um relatorio gravado . . . . . . . . . . . . . . 534.22 Editor para o swf principal da apresentacao, na opcao do separador

central . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 554.23 Desenho grafico generico da Siemens . . . . . . . . . . . . . . . . . . 564.24 Menu de Configuracao do Cliente . . . . . . . . . . . . . . . . . . . . 574.25 Siemens Reporting Demo . . . . . . . . . . . . . . . . . . . . . . . . . 59

ix

LISTA DE FIGURAS

x

Abreviaturas

TAC tomografia computadorizada

DICOM Digital Imaging and Communications in Medicine

XA X-Ray Angiography

CT Computed Tomography

RUP IBM Rational Unified Process

WYSIWYG What You See Is What You Get

swf Shockwave Flash

SDK Software Development Kit

TDD Test-driven development

xi

LISTA DE FIGURAS

xii

Capıtulo 1

Introducao

O presente relatorio descreve o trabalho desenvolvido numa aplicacao de pos-

processamento, visualizacao e transporte de estudos clınicos, incidindo em aspectos

como o desenvolvimento de novas funcionalidades, o aumento da flexibilidade, ma-

nutencao, assistencia e correccao de erros. O trabalho foi realizado no ambito de um

projecto na Siemens S.A..

Neste primeiro capıtulo efectua-se a apresentacao do contexto do projecto, bem

como a motivacao para a sua existencia na empresa e a forma como este se integra

com as suas actividades de negocio.

1.1 Contexto/Enquadramento

O trabalho desenvolvido decorreu no ambito do projecto de final de curso do

Mestrado Integrado em Engenharia Informatica e Computacao na Faculdade de En-

genharia da Universidade do Porto, tendo uma duracao fixa de 20 semanas.

O trabalho incidiu sobre uma aplicacao cliente-servidor que vinha a ser desen-

volvida desde 2006, tendo como base uma equipa de 2 pessoas. O presente projecto

visou dar continuidade a esta aplicacao.

Sendo uma aplicacao ainda em fase de desenvolvimento, existe uma interaccao

com o cliente, atraves de intermediarios na propria empresa, que filtram a informa-

cao e definem quais as alteracoes a efectuar na aplicacao. Esta aplicacao insere-se

1

Introducao

na area medica, mais especificamente, na visualizacao de estudo medicos e no cor-

respondente diagnostico.

A empresa Siemens S.A.[1] e o maior conglomerado europeu de engenharia, ac-

tuando em 6 areas de negocio: automacao/controlo, energia electrica, transportes,

cuidados medicos, informacao/comunicacao e luz natural e artificial. Actualmente

conta com cerca de 480.000 empregados a nıvel mundial. O presente trabalho inseriu-

se na divisao Siemens Healthcare que, como o nome indica, produz solucoes para a

industria de cuidados de saude.

No caso portugues, a maioria dos Sistemas de Informacao para a saude imple-

mentados ainda nao atingiu o nıvel de eficacia de outros sectores, tais como, a banca

ou as telecomunicacoes. Isso deve-se ao facto do trabalho desenvolvido nos ultimos

anos nao ter contemplado o aparecimento de novos paradigmas, requisitos e neces-

sidades que as Tecnologias de Informacao tem obrigacao de enderecar de forma a

satisfazer os profissionais de saude e de gestao.

O aumento da esperanca media de vida, o envelhecimento da populacao, o au-

mento das doencas cronicas, o elevado numero de actos medicos, a necessidade de

reduzir custos e de optimizar recursos, a maior exigencia por parte dos cidadaos e

a crescente competitividade, sao algumas das novas realidades com as quais e ne-

cessario lidar para obter a maxima eficiencia na prestacao de cuidados de saude e

contribuir para uma evolucao sustentada das organizacoes.

Neste contexto de mudanca e de aparecimento de novos paradigmas, a Siemens

Healthcare posicionou-se no segmento de apoio as organizacoes de saude, criando

condicoes para conquistar uma maior eficiencia na prestacao de cuidados de elevada

qualidade, possibilitando a melhoria contınua dos processos e do desempenho global.

1.2 Projecto

O presente projecto foi apresentado com o nome de Servidor de imagem clı-

nica com motor de pesquisa baseado em regras, sendo denominado interna-

mente a Siemens como Siemens Reporting.

Esta solucao permite, atraves de um servidor, adquirir e processar conteudos

clınicos imagiologicos (imagem e vıdeo, no formato DICOM - Digital Imaging and

2

Introducao

Communications in Medicine), para depois serem visualizados, num cliente que fun-

ciona como produtor/editor de relatorios medicos. O medico/utilizador pode depois

efectuar um pos-processamento aos conteudos, produzindo o seu proprio diagnos-

tico, e colocando anotacoes. Alem disso, a ferramenta esta interligada com outra,

tambem da Siemens, a qual pode ja ter o diagnostico feito e acessıvel num ficheiro

pdf. Quando isto acontece o Siemens Reporting pode ir buscar automaticamente

essa informacao, na forma de texto para dentro do relatorio, anexando o ficheiro pdf

ao relatorio.

Depois desta etapa de pos-processamento, existe a possibilidade de gravar para

CD ou DVD o estudo e o diagnostico, podendo ser ambos visualizados numa apre-

sentacao multimedia de facil percepcao e navegacao, tendo tambem a possibilidade

de consultar as imagens originais do estudo, atraves de um visualizador de DICOMs

que e tambem gravado no CD/DVD.

Todos os processos automaticos da aplicacao assentam na utilizacao de modelos

de relatorio, contendo regras que indicam como e quais as imagens DICOM que

devem ser introduzidas, bem como, nos casos em que e possıvel, obter apenas deter-

minado texto proveniente do ficheiro pdf referido anteriormente.

A figura 1.1 apresenta uma descricao simplista das funcionalidades fornecidas ao

utilizador (medico), que basicamente pode criar relatorios, de forma automatica ou

manualmente, bem como definir modelos de relatorio para depois serem usados nos

relatorios automaticos.

Esta representacao resume a principal funcao do sistema, isto e, criar relatorios

clınicos visualmente apelativos, com inclusao automatica das imagens e/ou vıdeos

em formato padrao DICOM, reduzindo substancialmente a exigencia de interaccao

do pessoal clınico com a ferramenta.

Na figura 1.2 apresenta-se o editor de relatorios do Siemens Reporting. De

notar que o fluxo da aplicacao exige que este editor apareca depois de se ter seleccio-

nado o estudo para o qual se quer fazer um relatorio, atraves de um menu semelhante

a opcao ”novo relatorio”. Desta forma consegue-se visualizar o conteudo do relatorio

no editor. Grande parte do trabalho desenvolvido neste projecto foi realizado nesta

parte da aplicacao.

A ferramenta apresentava ainda varios problemas, exigindo tambem desenvolvi-

mentos de novas funcionalidades. Isto levou a definicao de um plano de trabalhos,

3

Introducao

Figura 1.1: Exemplo de funcionalidades fornecidas ao utilizador.

resultando no projecto tema deste documento.

Este projecto, basicamente, propunha-se realizar um estudo sobre a arquitectura

da aplicacao, desenvolver mais algumas funcionalidades e dar suporte tecnico, cor-

rigindo, ao mesmo tempo, os erros que se encontrem e providenciando manutencao

e assistencia.

4

Introducao

Figura 1.2: Editor do Siemens Reporting (dados fıcticios).

1.3 Motivacao e Objectivos

O desenvolvimento da tecnologia de imagem medica tem permitido um diag-

nostico cada vez mais precoce e um tratamento cada vez mais eficaz de diferentes

patologias. O uso cada vez mais frequente destas tecnicas nao-invasivas permite

normalmente clarificar o quadro clınico dos pacientes. No caso especıfico das do-

encas cardiovasculares, os meios mais utilizados para diagnostico sao o cateterismo

cardıaco e o Angio-TAC[2] cardıaco que permitem obter imagens das estruturas ana-

tomicas cardıacas com elevada resolucao espacial e temporal, sendo minimamente

invasivas.

Assim, quando estes procedimentos de diagnostico sao efectuados, e necessario

criar um registo clınico, contendo toda a informacao relativa a esse mesmo proce-

dimento e que permita a sua difusao e transmissao a todos os intervenientes no

tratamento do paciente.

Num ambiente clınico ocorrem constantes interrupcoes no trabalho do pessoal

5

Introducao

medico, tornando-se mais difıcil uma constante atencao ao registo correcto dos da-

dos, levando a que qualquer forma de facilitar esta tarefa seja bem vinda. Isto

significa, particularmente em areas exigentes como a cardiologia, que existe uma

necessidade na criacao de ferramentas capazes de facilitar todo o processo de registo

de dados, geracao de relatorios medicos contendo o diagnostico e claro facilitar a

distribuicao de toda esta informacao. Estes sistemas permitem notorias vantagens

ao nıvel do fluxo clınico.

Estas necessidades, principalmente a de distribuicao, aumentam para pacientes

externos a unidade que faz o diagnostico. Quando um medico externo requer um

exame, o qual pode nao ser da sua especialidade, a um laboratorio/hospital, pre-

tende receber o exame e o correspondente relatorio, incluindo possıveis diagnosticos.

As caracterısticas enunciadas justificam a existencia de ferramentas do tipo do

Siemens Reporting.

A aplicacao esta instalada num ambiente real, como projecto piloto, no Hospital

de Vila Nova de Gaia, para a Unidade de Diagnostico e Intervencao Cardiovascular,

nas modalidades XA e CT. Os testes entretanto realizados produziram alguns pedi-

dos de correccao de erros e tambem de algumas sugestoes de alteracao e inclusao de

novas funcionalidades na ferramenta. Existe, alem disso, a perspectiva de futuras

instalacoes, estando ja definido uma para o Hospital da Arrabida.

Apesar da aplicacao se encontrar ainda em fase de teste, existe ja um numero

consideravel de potenciais clientes, mais de uma dezena de hospitais, a curto prazo,

visto serem estes as organizacoes que apresentam maiores semelhancas com a insta-

lacao piloto, levando a uma maior facilidade de compreensao e confianca no processo

e no fluxo clınico. Os potenciais clientes sao, pelo menos no plano teorico, todos

os utilizadores de imagiologia medica. Alguns dos potenciais clientes ja mostraram

interesse na aplicacao, mesmo sem trabalharem com ela, uma vez que ja receberam

relatorios do Hospital de Vila Nova de Gaia[3], resultantes da ferramenta.

Este conjunto de factores, aliada a necessidade de um maior conhecimento so-

bre a ferramenta, levaram ao aparecimento do projecto descrito neste documento.

O objectivo principal foi tornar a aplicacao num produto flexıvel, fiavel, robusto e

rentavel, no qual os clientes possam ter um elevado grau de confianca.

6

Introducao

1.4 Estrutura da Dissertacao

Para alem da introducao, este relatorio contem mais 4 capıtulos.

O capıtulo 2 contem uma revisao de outros produtos. E tambem explicado o

modo como o Siemens Reporting substitui o fluxo clınico.

No capıtulo 3, descreve-se o problema a resolver e quais os seus requisitos e as

suas restricoes.

Segue-se o capıtulo 4 no qual se faz uma descricao do trabalho desenvolvido,

sendo apresentadas as razoes para as varias opcoes tomadas.

Por ultimo, no capıtulo 5, e feita uma retrospectiva do trabalho desenvolvido,

dando conta do cumprimento dos objectivos propostos. Alem disso, sao apresenta-

das algumas linhas directivas para o trabalho futuro.

7

Introducao

8

Capıtulo 2

Revisao das tecnologias existentes

Neste capıtulo e efectuada uma revisao dos produtos existentes no mercado,

concorrentes ao Siemens Reporting.

2.1 Aplicacoes concorrentes

Depois de uma analise do mercado, tendo em atencao a perspectiva do Hospital

de Vila Nova de Gaia e do Hospital da Arrabida, pode-se concluir que o Siemens

Reporting e uma solucao inovadora, visto nao existir ate ao momento nenhuma

ferramenta capaz de executar todas as funcionalidades desta aplicacao.

Evidentemente que existe um vasto leque de outras ferramentas que sao capazes

de executar uma ou um pequeno conjunto das tarefas permitidas pelas funciona-

lidades do Siemens Reporting. Como exemplo destas funcionalidades temos a

gravacao em CD/DVD, a qual e disponibilizada por imensas ferramentas. Assim, os

clientes de angiografia que usem o Artis[4], podem, apos o exame, gravar o estudo

com o respectivo visualizador, nao podendo, no entanto, fazer qualquer anotacao,

adicao de conteudos, ou outra qualquer personalizacao.

Outro exemplo de aplicacao e o robot de gravacao e impressao da DigiMatic[5],

que copia automaticamente para CD/DVD/Blu-Ray os estudo que lhe sao entregues.

Mais uma vez nao e possıvel personalizar esses estudos. Assim, as notas do diagnos-

tico existentes nao sao anexadas. No entanto, permite etiquetar os discos gravados

com os dados do paciente1. Para alem disso, tem a vantagem de poder definir regras

para agrupar estudos num unico disco. A figura 2.2 mostra o funcionamento desta

1No Siemens Reporting esta tarefa e feita manualmente.

9


Figura 2.1: Sistema multi-proposito Artis Zee

ferramenta, a qual esta directamente ligada a um servidor DICOM.

Figura 2.2: Visao geral do DIGIMatic-MED

Uma outra funcionalidade bastante importante, sao as anotacoes ou a criacao

de um diagnostico. Neste campo, pode dizer-se que juntando um visualizador de

DICOMs, capaz de adicionar anotacoes e de as exportar para um meio multimedia

generico, com um software de criacao para apresentacao multimedia, obtem-se a

funcionalidade descrita.

Neste campo podemos referir uma aplicacao gratuita, denominada DicomWorks[6],

composta por um visualizador dedicado a radiografias, podendo, no entanto, ser

usado com ficheiros DICOM. Esta caracterıstica torna a aplicacao bastante gene-

rica, permitindo fazer anotacoes, exportar para ficheiros de imagem ou vıdeo, bem

10


como exportar para PowerPoint e gravar em CD. A tıtulo de exemplo, na figura 2.3

temos a ferramenta de medicao do DicomWorks.

Figura 2.3: Ferramenta de medicao do DicomWorks

Uma outra ferramenta, importante por ser um plugin para o PowerPoint, denomi-

nada DICOM for PowerPoint[7], fornece ao PowerPoint a capacidade de manipular

DICOMs, o que lhe da a vantagem de estar associado a um software mundialmente

aceite e conhecido. Assim, sendo o PowerPoint uma ferramenta capaz de produzir

apresentacoes bastante flexıveis devido a quantidade de anotacoes disponıveis, fa-

zer a apresentacao do diagnostico desta forma traz algumas vantagens. A figura 2.4

mostra um exemplo da criacao de uma apresentacao contendo uma imagem DICOM.

2.2 Rotinas de funcionamento existentes

Nesta seccao, da-se uma visao sobre a forma como os estudos cardiovasculares

eram efectuados e qual o trajecto do diagnostico criado ate ao seu destino. Estes

exemplos referem-se aos hospitais de Vila Nova de Gaia e da Arrabida, uma vez

11


Figura 2.4: Plugin para edicao de DICOMs no PowerPoint

12


que sao estes dois hospitais que actualmente estao ligados ao Siemens Reporting.

Pretende-se com esta aplicacao alterar o fluxo de trabalho nas correspondentes uni-

dades de cardiologia.

2.2.1 Hospital de Vila Nova de Gaia

Nesta unidade, e usado o Syngo Dynamics [8] para fins de diagnostico, o qual

produz um ficheiro pdf contendo as conclusoes de cada estudo. Quando era neces-

sario que o estudo fosse distribuıdo, por exemplo para um paciente externo, um

tecnico tinha de se deslocar a um servidor de gravacao e pedir que o estudo fosse

gravado. Por outro lado, o relatorio produzido no Syngo Dynamics era impresso e

enviado num envelope.

2.2.2 Hospital da Arrabida

No Hospital da Arrabida, o diagnostico era criado usando ferramentas de edicao

de DICOMs, a captacao de imagem do ecra e o PowerPoint. Assim, as anotacoes sao

feitas nos DICOMs, sendo estes depois exportados para jpeg, por exemplo, e depois

adicionadas a uma apresentacao do PowerPoint. Pode tambem ser adicionado o

vıdeo correspondente duma captacao de imagem do ecra, quando da analise dos

DICOMs. A referencia temporal para este trabalho e de varias horas.

2.3 Tecnologias

A aplicacao e toda desenvolvida sobre a tecnologia .NET da Microsoft[9][10],

numa arquitectura cliente-servidor[11], sendo a comunicacao feita por .NET Remoting[12].

Contribuiram para a escolha desta tecnologia a sua versatilidade, a sua aceitacao

e a facilidade no desenvolvimento de aplicacoes usando esta tecnologia[13][14].

Para alem disto existe uma elevada utilizacao do Adobe Flash[15], usado princi-

palmente para carregar imagens/vıdeos e para criar a apresentacao final contendo o

relatorio final do estudo, ou seja, para criar o output da aplicacao.

2.3.1 Bibliotecas

Segue-se uma lista das bibliotecas usadas pela aplicacao

• Nhibernate[16] - e a versao do Hibernate para .Net e trata do mapeamento de

objectos em bases de dados, permitindo assim uma abstraccao no tipo de base

de dados usada.

13


• Turbine 7 SDK with Flash Output[17] - e uma biblioteca para .Net que permite

adicionar imagens, vıdeos, texto e codigo, a um ficheiro flash, criando conteudos

multimedia dinamicamente.

• DicomObjects[18] - cria um no completo de DICOM, fazendo consulta ou re-

colha de DICOMs, e sendo capaz de os codificar para jpg ou avi.

• Magic CD/DVD Burner (.NET) 1.x/2.x[19] - biblioteca de gravacao de CD/DVD.

• DockPanel Suite WinFormsUI2005[20] - permite manipular janelas, sendo ca-

paz de as criar com a opcao auto-hide semelhante as janelas do Visual Studio.

• AviSynth[21] - utilizado para agrupar varios ficheiros avi em apenas um.

• FFmpeg[22] - biblioteca de codificacao/descodificacao e conversao de audio e

vıdeo.

2.4 Conclusoes

Atraves desta revisao, podemos inferir que existem varias ferramentas capazes

de responder ao problema da apresentacao de relatorios medicos. No entanto, com

o Siemens Reporting, e usando diversas tecnologias, espera-se dar resposta a esse

mesmo problema, tentando faze-lo de uma forma diferenciadora, flexıvel e agrupando

numa unica aplicacao diversas funcionalidades fornecidas separadamente noutros

pacotes.

14

Capıtulo 3

Especificacao e Descricao

A revisao das tecnologias existentes feita no capıtulo 2 nao incide nas possıveis

solucoes para o projecto. Procura sim explorar todo o contexto da ferramenta, uma

vez que a aplicacao nao foi feita a partir do zero. Este capıtulo procura explicar a

especificidade do projecto e justificar a estrutura do capıtulo 2.

Nas proximas seccoes procura-se detalhar mais pormenorizadamente em que con-

siste o projecto, dando uma nocao pratica dos seus objectivos e fazendo referencia a

motivacao para a sua existencia e inclusao neste projecto. Para finalizar, e apresen-

tada uma breve descricao da metodologia seguida na resolucao desses problemas.

3.1 Requisitos

Os requisitos apresentados nesta seccao servem principalmente para definir os

objectivos do projecto.

3.1.1 Documentacao

Devido a ausencia de documentacao e de conhecimento acerca do desenvolvi-

mento do projecto, este ponto tem grande importancia dado que e sempre o ponto

inicial para se compreender uma aplicacao.

Este requisito incide sobre a documentacao da arquitectura da aplicacao, princi-

palmente sobre a sua vertente cliente. Este requisito foi especificado com base num

documento interno, o qual servia de base a descricao da arquitectura, em particular

no diagrama presente na figura 3.1.

Desta forma a arquitectura dos seguintes componentes teve de ser documentada:

15


Figura 3.1: Descricao da arquitectura feita anteriormente

• Report editor;

• Report model;

• Report generator;

• Mapping engine;

• Profiles;

• Reporting DB;

• Reporting content broker.

Espera-se que depois da elaboracao desta documentacao seja possıvel compreen-

der a arquitectura sobre a qual assenta o Siemens Reporting, alem de facilitar o

trabalho a quem se inicie no Siemens Reporting e permitir que possa continuar

o seu desenvolvimento.

3.1.2 Logs

O registo de logs permite dotar a aplicacao de um sistema de registo de erros.

Esta funcionalidade e importante, principalmente na componente cliente, para per-

mitir identificar e localizar erros e para que estes possam ser resolvidos de uma forma

facil e rapida.

Para alem do registo de erros, o sistema tem de ser capaz de registar cada passo

de colocacao de DICOMs (vıdeo ou imagem) nos modelos de relatorio1.2, ou seja,

16


registar porque determinada imagem foi colocada ou porque nao o foi. Isto tem uma

relacao directa com o sistema de regras presente no modelo de relatorio utilizado no

momento da sua criacao.

3.1.3 Configuracao

O desejo de uma configuracao simples e flexıvel, e um dos requisitos que mais

directamente esta relacionado com o desejo de tornar o Siemens Reporting mais

do que uma simples solucao, transformando-o num produto.

Apesar de nao terem sido inicialmente definidos, temos a seguir uma lista onde

se identificam os pontos de configuracao:

• Configuracao do cliente e do seu pacote visual: escolha do fundo da aplica-

cao e o aspecto visual do seu output, ou seja, dos flash que correspondem a

apresentacao do relatorio e que sao gravados para CD/DVD;

• Gestao de utilizadores do sistema;

• Editor grafico de todos os parametros da aplicacao.

Todos estes pontos sao importantes para o corpo tecnico da Siemens, visto faci-

litar o trabalho de configuracao para cada instalacao. Destes, o mais importante e

sem duvida a configuracao do output final, pois e a parte mais visıvel de toda apli-

cacao. Uma apresentacao flash do relatorio, diferente e personalizada, constituium

parametro muito valorizado pelos clientes.

3.1.4 Globalizacao

Globalizar a aplicacao significa ter uma forma simples e rapida de alterar a lıngua

do sistema. Para alem disso, o trabalho necessario para essa alteracao deve ser o

menor possıvel.

3.1.5 Outros

Procurou-se ainda desenvolver processos de resolucao de problemas do sistema

em que o Siemens Reporting se insere atraves do estudo deste e da resposta as

suas necessidades de suporte tecnico. Com isto pretende-se resolver qualquer defeito

ou erro encontrado, dando apoio tecnico a instalacao efectuada.

Por outro lado, deve-se dar resposta aos pedidos dos clientes, as personalizacoes

desejadas e aos novos rumos tracados pelos intermediarios dos clientes, pertencentes

a empresa. Assim, deve haver a possibilidade de adaptar a aplicacao as necessidades

17


ou gostos que forem surgindo.

O apoio tecnico engloba tantas possibilidades que, apesar de nao ser algo muito

tangıvel a partida, e sem duvida um ponto importante para a empresa. O que se

pretende principalmente e assegurar que a ferramenta se torna fiavel, robusta e que

tenha qualidade.

3.2 Metodologia

A principal caracterıstica da metodologia seguida e a adaptacao do desenvolvi-

mento as necessidades expressas pelos clientes. Por esse motivo, existe uma grande

exigencia de contacto com este, exigindo, tambem, que os canais de comunicacao

estejam sempre abertos. Apesar deste facto e necessidade, em primeiro lugar foi

essencial entrar em contacto com a ferramenta desenvolvida ate entao.

O processo iniciou-se com a consulta da documentacao existente. Este processo

revelou-se fundamental para compreender qual o ponto da situacao e quais as areas

cobertas pela equipa de desenvolvimento. Depois disso, procurou-se instalar e con-

figurar a ferramenta com recurso apenas a documentacao existente. Isto permitiu

avaliar esta parte da documentacao na pratica.

E importante que a aplicacao instalada seja colocada em modo debug. Isto sig-

nifica aceder ao codigo fonte e preparar um ambiente no qual seja possıvel fazer

testes, sem o risco de comprometer outros servicos. Basicamente, procurou-se criar

um ambiente local para testes e desenvolvimento.

Apos estas etapas, conseguiu-se ter uma nocao basica do estado da ferramenta,

tendo sido muito importante compreender em que areas e que existia uma falta de

informacao, de modo a poder ultrapassar esse problema. Por outro lado ficou-se

com um ambiente onde era possıvel explorar as funcionalidades da ferramenta. Com

uma analise profunda ao codigo fonte procurou-se entender os mecanismos que estao

na base da aplicacao, as suas funcionalidades e as suas potencialidades.

A passagem para a documentacao, foi o passo logico que se seguiu. Permitiu

combater a falta de informacao e obrigou a um aprofundamento do conhecimento

da aplicacao. Em particular a analise a arquitectura facilitou o desenvolvimento

do trabalho posterior. Esta documentacao pretende, tambem, ajudar os proximos

programadores que eventualmente tenham de continuar o desenvolvimento.

18


Depois do trabalho de escrita seguiu-se o trabalho sobre o codigo, ou seja, o

desenvolvimento e a melhoria da aplicacao. Este desenvolvimento foi pensado e

planeado procurando que tivesse os mesmos padroes de qualidade, no processo de

planeamento, que o resto dos padroes na empresa. De realcar que cada projecto, e

um projecto diferente e que o tipo de planeamento mais aconselhavel pode variar,

ou seja, as metodologias de desenvolvimento devem ser sempre analisadas e bem

escolhidas.

O planeamento deve ter sempre em conta o cliente, ou possıveis clientes, daı no

inıcio desta seccao termos referido e frisado a necessidade de comunicacao com os

clientes.

Planear deve ter em conta a prioridade atribuıda as tarefas a serem realizadas.

Assim, deve ter-se uma lista de objectivos sequenciais a cumprir. Por vezes as de-

pendencias ou necessidades obrigam a que tarefas supostamente sequenciais tenham

um teor paralelo e simultaneo.

Apos a decisao sobre quais as tarefas a realizar, analisaram-se uma a uma, procu-

rando encontrar o melhor caminho para se atingir o objectivo. Neste caso particular:

• Logs - envolvem escolher o tipo de registo e locais de registo;

• Configuracao - envolve saber quais os pontos de configuracao que se pretende,

bem como a forma como esta e feita;

• Globalizacao - envolve saber a forma de alteracao da lıngua e onde fica guar-

dada a informacao referente a cada lıngua;

• Apoio tecnico - envolve saber que mudancas nos requisitos sedevem efectuar,

de forma expedita, atribuindo prioridades a essas mudancas de acordo com o

trabalho actual; a mesma filosofia deve ser seguida para qualquer erro que se

venha a descubrir.

Por fim, procurou-se analisar os resultados obtidos a cada novo desenvolvimento,

fazendo uma analise crıtica do que foi feito, e planeando as etapas seguintes.

3.3 Resumo

A variedade de requisitos, bem como a possibilidade de aparecimento de erros

ou mudancas na aplicacao a pedido dos donos da ferramenta, levam a que algumas

competencias sejam essenciais, nomeadamente:

19


• autonomia;

• capacidade de analise;

• adaptacoes a novas situacoes ou requisitos.

20

Capıtulo 4

Implementacao - Trabalho

Desenvolvido

Este capıtulo tem como objectivo descrever todo o trabalho desenvolvido, sem

esquecer todo o seu contexto. Devido as especificidades do projecto e aos seus

principais objectivos, nomeadamente, resolver os problemas existentes e acrescentar

funcionalidades a aplicacao, nao foi possıvel incluir e desenvolver novas tecnologias.

A figura 4.1a mostra o codigo fonte do servidor e a figura 4.1b mostra o codigo

fonte do cliente. O trabalho incidiu principalmente sobre o codigo do cliente.

A partir destas figuras podemos verificar o elevado numero de funcionalidades

associadas a aplicacao, apesar de nao ser possıvel ficar com a nocao completa da

complexidade das interaccoes existentes dentro de cada parte do codigo fonte. Nas

proximas seccoes procura-se demonstrar em que medida a complexidade da imple-

mentacao influenciou o trabalho realizado neste projecto.

4.1 Documentacao

A primeira tarefa a ser iniciada neste projecto foi consultar a documentacao

existente, procurando depois ultrapassar a falta desta, principalmente no que diz

respeito a arquitectura do sistema.

Tentando sempre produzir documentos de acordo com o standard da empresa

e seguindo a metodologia descrita na seccao 3.2 redigiram-se varios documentos a

medida que se ia explorando a ferramenta.

21

Implementacao - Trabalho Desenvolvido

(a) Servidor (b) Cliente

Figura 4.1: Arvores das solucoes do servidor e cliente

4.1.1 Manual de Instalacao

Da analise de toda a documentacao existente, verificou-se a ausencia de informa-

cao sobre como executar e utilizar a aplicacao. Nomeadamente, a ausencia de um

manual de instalacao.

Resolveu-se entao instalar a ferramenta num ambiente local, evitando desta forma

que a tarefa sofra influencias externas, de modo que deste processo resulte um do-

cumento que sirva de guia de instalacao da aplicacao.

Desta forma criou-se o Manual de Instalacao, fazendo um lista dos pre-requisitos

22


a instalacao, dos passos a seguir na instalacao, bem como descrevendo os pacotes

de software usados apos a instalacao, necessarios para o funcionamento da aplica-

cao. Por fim, foram feitas algumas consideracoes a ter em conta na sua configuracao.

Este documento tem grande importancia, uma vez que permite a possibilidade

da aplicacao ser instalada por elementos que nao pertencem ao corpo tecnico. Por

este motivo a linguagem e os termos utilizados foram os mais correntes possıvel.

Por outro lado, tendo em conta as dificuldades encontradas, permitiu identificar

algumas falhas na aplicacao, nomeadamente a dependencia que a aplicacao tinha

perante as opcoes regionais e de lıngua.

O resumo deste trabalho encontra-se no anexo B.

4.1.2 Arquitectura

No ambito do projecto era necessario compreender e descrever varios componen-

tes do sistema, isto e, realizar um estudo sobre a sua arquitectura. Assim optou-se

por redigir um dos documentos do RUP, Software Architecture Document, que as-

senta nos seguintes fundamentos[23]:

• Descricao da arquitectura do software, incluindo as grandes divisoes dos seus

componentes, bem como as suas interaccoes;

• Compreensao dos princıpios de arquitectura usados no desenho e na implemen-

tacao;

• Descricao do hardware e das plataformas de software nos quais o sistema e

distribuıdo;

• Justificacao da forma como a arquitectura se ajusta aos requisitos nao funcio-

nais.

O documento providencia uma compreensao global da arquitectura do sistema

mostrando atraves de vistas os varios aspectos do sistema. Normalmente e usado

para captar as decisoes mais importantes feitas sobre o sistema a nıvel de arqui-

tectura. Neste caso particular as decisoes ja tinham sido tomadas sendo necessario

fazer engenharia reversa, uma vez que se tinha de inferir a arquitectura e nao estar

a cria-la.

Apesar de ser uma captura da arquitectura, o documento aborda os seguintes

tropicos:

23


• Visao geral da arquitectura;

• Objectivos da arquitectura;

• Casos de uso principais;

• Detalhes da arquitectura segundo varias perspectivas;

• Modelo de dados.

Figura 4.2: Workflow que define a visao 4+1 da Arquitectura

As varias perspectivas seguem o modelo 4+1[24], apresentado na figura 4.2 e que

resumidamente implica as seguintes vistas:

• Vista de Casos de Uso - descreve os actores e os casos de uso do sistema, apre-

sentando as necessidades dos utilizadores. Estes casos sao depois elaborados

ao nıvel do desenho para descrever os fluxos e restricoes em mais detalhe.

• Vista Logica - esta vista suporta principalmente os requisitos funcionais, isto

e, aquilo que o sistema deve providenciar em termos de servicos para os seus

utilizadores. O sistema e decomposto em varias abstraccoes chave, tiradas

principalmente do domınio do problema, na forma de objectos ou classes de

objectos. Isto permite uma analise das funcionalidades, identificando mecanis-

mos, ou elementos de desenho que sao comuns a varias partes do sistema.

24


• Vista dos Processos - a arquitectura dos processos tem em conta alguns requi-

sitos nao funcionais como:

– concorrencia;

– distribuicao;

– desempenho;

– escalabilidade;

– tolerancia a falhas.

• Vista de Instalacao - descreve uma potencial estrutura de instalacao, fazendo

referencia a alguns possıveis cenarios.

• Vista de Implementacao - descreve como e que os componentes do modelo de

desenho sao implementados em termos de codigo fonte, executaveis, bibliotecas

e suas dependencias.

Tendo em conta que o RUP e uma framework de processos nao rıgida, isto sig-

nifica adapta-lo para as necessidades. Por este motivo a notacao nao e igual a

apresentada em [24], tendo no entanto os mesmos objectivos.

O trabalho de analise e pesquisa incidiu sobre varios documentos e sobre o co-

digo, sendo imprescindıvel executar a ferramenta em modo debug.

De seguida, descrevem-se algumas conclusoes obtidas do Siemens Reporting.

4.1.2.1 Representacao da arquitectura

Na figura 4.3 apresenta-se uma visao geral da arquitectura do sistema. O que

se pode inferir deste diagrama e, principalmente, quais os componentes do sistema,

onde estao localizados e quais as suas ligacoes.

Desta forma podemos verificar que o servidor e composto por 4 componentes e

que o cliente e composto, tambem, por 4 partes bastante significativas para a arqui-

tectura, 3 das quais sao bibliotecas. Por outro lado, verifica-se que tanto o cliente

como o servidor acedem directamente a base de dados.

Como o Siemens Reporting nao actua sozinho, na figura 4.4 apresenta-se uma

visao geral das interaccoes com o exterior.

As interaccoes sao as seguintes:

25


Figura 4.3: Visao geral da arquitectura

• O servidor esta directamente ligado a um ou mais servidores de imagem DI-

COM;

• Os componentes Broker e Converter, fazem consulta e descarregamento de

DICOMs;

• O componente Receiver, esta a escuta de envios de DICOMs;

• A comunicacao cliente-servidor e feita por .NET Remoting[12]. Dentro do

servidor o componente que interage com o cliente e apenas o Broker;

• O cliente acede directamente aos servidores de imagem Syngo Dynamics[8];

• O cliente pode ser aberto a partir do Syngo Dynamics Client.

26


Figura 4.4: Visao geral das interaccoes com o exterior

Resumidamente o servidor serve de intermediario entre o cliente e os servidores

de imagem, fazendo de cache para DICOMs e facilitando a comunicacao. Por outro

lado, existe tambem uma versao dos DICOMs em formatos de imagem e vıdeo stan-

dard (jpeg, flv, avi). Esta conversao e feita tanto pelo Receiver como pelo Converter.

A diferenca e que um faz a conversao a pedido (Receiver) e o outro apenas quando

encontra novos DICOMs nos servidores de imagem. O Broker, sendo primariamente

o servico de cache, quando lhe e feito um pedido para o qual nao pode dar resposta a

partir dessa mesma cache, tem de comunicar com os servidores de imagem, fazendo

tal como os outros dois a conversao, quando necessaria. O componente Console,

nao aparece nas interaccoes porque apenas e usado para fins de gestao dos outros 3

componentes.

Quanto ao cliente, apenas se refere que este vai buscar aos servidores de ima-

gem Syngo Dynamics um documento pdf contendo as conclusoes do estudo realizado

atraves de SQL Stored Procedures.

27


4.1.2.2 Realizacao dos Casos de Uso

Depois de se fazer a apresentacao da arquitectura geral, deve-se descobrir quais

os casos de uso que sao transversais e para quais devera a arquitectura dar resposta.

Esta situacao esta representada na figura 1.1 que basicamente apresenta os casos de

uso dignos de serem referenciados neste documento.

Estes casos de uso traduzem-se em:

• Existencia de modelos de relatorios;

• Os relatorios automaticos, sao criados usando modelos de relatorios aplicados

a um determinado estudo;

• Os relatorios criados de forma ad-hoc, sao relatorios vazios contendo a possibi-

lidade de se introduzir qualquer imagem DICOM do estudo(Graphical Objects

Library).

4.1.2.3 Vista Logica

A vista logica mostra a separacao por classes logicas, sendo definidas, em pri-

meiro lugar, as camadas gerais. A figura 4.5 representa essa visao global.

Figura 4.5: Visao geral das classes logicas

28


De seguida efectuou-se a descricao de cada uma das classes, dando, quanto pos-

sıvel, uma visao interna destas. Muitas destas classes podem ser extrapoladas da

arquitectura geral. Seguiu-se uma breve descricao para as restantes, passando depois

para uma breve analise de algumas destas classes logicas em mais detalhe.

Tentando nao repetir informacao ja presente neste documento, acrescentam-se

as seguintes:

• BrokerInterface - inferface para comunicacao;

• DICOMObejcts - Biblioteca externa para manipulacao de DICOMs;

• DICOMHandler - controlador sobre uma biblioteca externa;

• Clinical - modelo de dados relacionado com utilizadores, pacientes, estudos e

unidades do hospital;

• StorableMedia - modelo de dados para ficheiros locais;

• DBManager - funcoes de acesso a base de dados (servidor);

• NHibernate - acesso a base de dados (cliente);

Outras classes logicas merecem tambem alguma atencao. O Mapping Engine,

decomposto na figura 4.6, e um mapa constituıdo por uma ou mais regras. Estas

diferentes regras sao sequenciais e ordenadas.

Figura 4.6: Decomposicao logica de um relatorio

O relatorio e decomposto num modelo logico, representado na figura 4.7. Para o

utilizador apenas se torna necessario compreender a existencia de relatorios e mode-

los de relatorio. Depois disso existe o VisualPackage que define o fundo da aplicacao

29


e do output final, que contem, entre outras coisas, varios ficheiros, denominados por

StorableMedia. Da mesma forma, qualquer anexo e tambem um ficheiro, logo, Sto-

rableMedia. Por ultimo, temos os objectos que sao incluıdos nos relatorios, podendo

ser de tres tipos:

• Texto estatico;

• Regras de mapeamento(texto ou imagem);

• Representacoes de imagens DICOM.

Figura 4.7: Decomposicao logica do motor de mapeamento

A criacao e gravacao do relatorio para CD/DVD e feita por Report Generator,

que descarrega os DICOMs originais e gera uma apresentacao flash do relatorio.

Neste processo sao usados alguns ficheiros flash como base e uma biblioteca externa

chamada Turbine que necessita de uma linguagem propria, a qual e fornecida pelo

MMLConverter. A figura 4.8 apresenta uma visao sobre o processo.

4.1.2.4 Vista dos Processos

Nesta vista, representada na figura 4.9, apesar de nao se fazer um representacao

de todos as processos e thread envolvidos, e feita uma identificacao dos principais,

sendo dada uma ideia da sua funcao. Neste caso, procurou-se escolher um nome que

indique razoavelmente qual o seu proposito.

30


Figura 4.8: Decomposicao logica da geracao do relatorio

A seguinte lista procura agrupar os processos e thread de acordo com as tarefas

realizadas:

• login - RetrieveSysUsersTask, AuthenticateTask;

• criar modelos - Reporting Editor, RetrieveVisualPackagesTask;

• criar relatorios no momento - Reporting Editor, RetrieveStudyImagesTask,

Broker;

• criar relatorios automaticos - Reporting Editor, RetrieveTemplatesTask;

• construir o relatorio - BuildReportTask, Broker;

• gravar o relatorio - OutputReportTask, GenerateReportOutput, CreateMedi-

aContents, FetchDicoms, Broker;

• criar a cache DICOM - Broker, Receiver, Converter

4.1.2.5 Vista de Instalacao

A vista de instalacao, presente na figura 4.10, apesar de bastante simplificada, e

capaz de gerar um cenario para o funcionamento do Siemens Reporting. Assim,

31


Figura 4.9: Vista dos processos

temos um servidor, que pode ter tambem uma base de dados anexada, e um ou mais

clientes a correr noutras maquinas. Tanto o cliente como o servidor necessitam de

permissao de leitura e escrita sobre uma pasta do sistema de ficheiros. O cliente tem

de ter acesso a um gravador de CD/DVD.

Este cenario encontra-se fortemente restringido pela velocidade de transmissao da

rede. Este e o principal entrave, visto que os DICOMs podem ser bastante grandes,

podendo atingir um valor na ordem dos Gigabytes.

4.1.2.6 Outros

A documentacao continua pela vista de implementacao. Opcionalmente e pela

relevancia para a arquitectura nao se inclui grande parte dessa informacao neste

documento, sendo colocada no anexo A, no capıtulo 8. Esta seccao apenas aborda

as principais camadas no domınio do problema. Ou seja o Report Model, o Report

Generator e o Mapping Engine. Estas 3 camadas fazem parte do cliente: o Report

Model faz uma apresentacao do relatorio, o Mapping Engine define as regras para

fazer relatorios automaticos e finalmente o Report Generator transforma o Report

Model numa apresentacao flash, permitindo tambem a sua gravacao.

32


Figura 4.10: Vista de Instalacao

O Mapping Engine e a parte principal que permite criar relatorios automatica-

mente pois define as regras com as quais o relatorio e preenchido para um determi-

nado estudo medico.

A sua implementacao e descrita na figura 4.11, onde se da conta das classes do

programa que estao envolvidas na implementacao destas regras.

Assim, tem-se a classe SQLQuery e ApplicationQuery que usam a classe Mapping

como parametro, onde a primeira transforma as regras numa consulta SQL. Esta

consulta e depois feita ao servidor o qual envia as representacoes das imagens que

validam a consulta. A segunda classe executa a mesma consulta mas a um conjunto

de objectos, ou seja, a uma NameValueCollection.

Na vista logica do motor de regras, refere-se que um mapa de regras e composto

por uma regra, ou um grupo de regras. Assim se cria uma raiz logica que pode ter

uma Rule ou um RuleGroup. Teoricamente falando, esta raiz pode conter ambas as

duas situacoes, mas existem condicoes a controlar isso, fazendo com que apenas se

possa ter ou uma regra ou um grupo de regras.

33


Figura 4.11: Implementacao das Regras de Mapeamento

O grupo de regras, RuleGroup e abstracto e internamente pode ter mais grupos

de regras ou regras individuais. Esta abstraccao e realizada por duas classes, que

significam duas operacoes logicas, AndGroup e OrGroup. Assim se podem ter ope-

racoes logicas ”e”e ”ou”entre grupos de regras e regras individuais.

Uma Rule define basicamente um filtro a aplicar a imagens DICOM. Isto sig-

nifica especificar o tipo de filtro, ou seja, qual o operador a ser executado sobre

os DICOM. Os tipos de operador estao definidos na classe RuleOperators, permi-

tindo operacoes como, StartsWith, Equals, NotEquals, BetweenRange, etc. Este

ultimo obriga a existencia de intervalos, permitindo assim uma regra ter intervalos

definidos pela class Range. Por ultimo refere-se que esta classe pode ser aplicada

a varios campos de um DICOM, estando estes especificados em FieldMappingTypes.

A geracao das apresentacoes flash dos relatorios e gravacao para CD/DVD, passa

34


Figura 4.12: Implementacao da geracao de uma apresentacao flash do relatorio

por diversas fases e diferentes partes do programa. Na figura 4.12 estao representadas

as classes que iniciam todo o processo de geracao de flash e gravacao para CD/DVD.

Tudo comeca na classe principal do editor Siemens Reporting, ReportEditor e no

seu metodo ConcludeAction. Este corre um comando, GenerateOutputCommand

que cria uma thread chamada OutputReportTask. Esta thread tem 3 funcoes prin-

cipais:

• Descarregamento dos DICOMs originais;

• Producao da apresentacao flash;

• Preparacao dos anexos e de um visualizador de DICOMs.

Depois o processo de gravacao e feito na classe WriteMedia, por intermedio de

uma DLL externa, MCDBNET2.dll.

Este componente esta divido por varios projectos da solucao, Reporting, SieDi-

alogs(WriteMedia) e ReportFlashGenerator. Este ultimo representa a essencia da

ferramenta ao gerar as apresentacoes flash. Por ser um subsistema importante e

tambem descrito neste documento. O projecto ReportFlashGenerator, descrito na

35


figura 4.13, tem como classe principal Generator e o metodo Generate. Os objectos

da classe Generator sao criados com 2 caminhos para 2 ficheiros swf e com um con-

trolador de Report/Template.

Figura 4.13: Implementacao de ReportFlashGenerator

Depois disso cria-se um objecto Turbine7, correspondente a biblioteca externa

Turbine. Assim a execucao passa para a classe ReportAssembler, que e uma realiza-

cao da classe abstracta Assembler. Esta classe usa um dos ficheiros swf, como base

da biblioteca Turbine. E criado depois um script para ser injectado na biblioteca,

recorrendo as classes PageFrame e Tag. O flash resultante com o nome report.swf,

e a apresentacao principal do relatorio. Os dados que lhe foram injectados dizem

36


respeito principalmente a variaveis globais, como o numero de paginas do relatorio

e outra informacao diversa, como o nome do doente, a data do estudo e nome do

medico.

A execucao fica a cargo de uma outra realizacao da classe Assembler, PageAs-

sembler, que usa o outro ficheiro swf. PageAssembler e executado para cada pagina

do relatorio, ou seja, cada pagina resulta num ficheiro swf, para a apresentacao final.

O processo de geracao resume-se aos seguintes passos:

• Geracao do report.swf, que representa o flash principal de uma apresentacao;

este swf guarda o numero de paginas de um relatorio, o nome do doente e do

medico, bem como data e tipo de estudo;

• Por cada pagina e criado um swf, com um nome diferente, mas seguindo uma

regra;

• Todos os objectos de cada pagina sao percorridos para serem inseridos no swf.

O resultado deste processo e um ficheiro report.swf que carrega outros ficheiros

swf, um por cada pagina.

O modelo de dados e a sua explicacao encontram-se presentes no anexo A, na

seccao 9. Apenas se faz referencia, tal como se mostra na figura 4.14, ao facto da

base de dados estar divida teoricamente em duas partes, tendo uma tabela comum

aos dois sistemas. O nome das tabelas indica a divisao: as tabelas que tem as

primeiras letras ”BK”pertencem ao servidor e todas as outras pertencem ao cliente

e sao mapeadas pelo NHibernate (mapeamento de objectos em bases de dados), o

que se traduz numa directa correlacao entre as classes logicas e o modelo de dados.

Daı a opcao de ter colocado esta informacao em anexo.

4.1.3 Levantamento das Licencas

Mais uma vez tendo em conta o objectivo de transformar o Siemens Reporting

num produto, e necessario definir uma polıtica de precos. Um dos aspectos a ter

em conta nesta definicao e a questao das licencas para as bibliotecas usadas. Foi

assim necessario fazer uma levantamento de todas as bibliotecas usadas, procurando

tambem saber qual o tipo de licenciamento exigido para se poder comercializar o

produto.

Deste trabalho de pesquisa na documentacao e no codigo, resultou um pequeno

documento contendo uma breve descricao sobre cada biblioteca e as implicacoes de

37


Figura 4.14: Separacao da base de dados

serem usadas num produto comercial de codigo fonte fechado. Para alem disso, deu

origem a seccao 2.3.1.

4.2 Insercao numa Metodologia de Desenvolvimento de Soft-

ware

Com o objectivo de se criar software com maior qualidade e eficiencia, deve-se

efectuar o planeamento previo do trabalho a realizar. Existe para isso um numero

elevado de modelos, qualquer um deles definindo um conjunto de tarefas ou metodos

de forma a gerir a vida de um software.

Estes modelos, de uma forma ou outra, abordam os seguintes temas:

• Analise do domınio;

38


• Analise dos requisitos - levantamento dos requisitos, analisando o ambito do

desenvolvimento perante os mesmos;

• Especificacao - descricao do que se vai desenvolver;

• Arquitectura do software - representacao abstracta do sistema;

• Implementacao;

• Teste;

• Instalacao;

• Documentacao;

• Treino e suporte - treinar os utilizadores para o uso do sistema;

• Manutencao.

4.2.1 Modelos de desenvolvimento

Para a escolha de um modelo de desenvolvimento as possibilidade sao diversas,

portanto deve-se ter em conta o contexto do software para se optar por um dos

disponıveis. Neste caso particular, tınhamos um software, ja com algum tempo,

que nao seguiu nenhuma metodologia em concreto. Alem disso, ja se encontra em

ambiente de producao e os seus requisitos estao em constante mudanca para servir

novas necessidades.

Alguns do possıveis modelos a seguir sao:

• Waterfall - modelo sequencial, passando pelas fases de especificacao de requi-

sitos, desenho, implementacao, validacao e manutencao. Segue a filosofia de

que o tempo perdido na especificacao produz ganhos mais tarde. No entanto,

nos sistemas nao triviais terminar completamente uma fase e so depois passar

a proxima e quase impossıvel, uma vez que existem demasiadas incertezas. As

necessidades, tanto da volatilidade nos requisitos, como o facto de ser um de-

senvolvimento transversal, fazem com que o waterfall nao seja o mais indicado

para o nosso caso.

• Espiral[25] - procura combinar o desenho e a implementacao, misturando os

conceitos de top-down (do geral para os pormenores) e bottom-up (dos porme-

nores para ao geral). Assim, procura passar em ciclo pelas seguintes fases:

– Definicao dos objectos;

– Identificacao e resolucao dos riscos;

39


– Desenvolvimento e testes;

– Planeamento da fase seguinte.

E um modelo apropriado para grandes projectos, tendo vantagens como a maior

qualidade das estimativas de tempo e de orcamento, a medida que se avanca no

projecto, alem de ser capaz de incorporar mudancas nos requisitos. E tambem

possıvel comecar a trabalhar na base do projecto desde o inıcio. A dimensao e

o estado actual do nosso software levam a que existam melhores opcoes.

• Agile[26] - metodologias que promovem o desenvolvimento iterativo com uma

colaboracao aberta e de adaptabilidade durante o ciclo de vida do projecto. E

baseado no seguinte conjunto de regras/objectivos:

– Satisfacao do cliente pela rapida e contınua entrega de software funcional;

– O Software funcional e a principal medida de progresso;

– Mudancas tardias nos requisitos nao levantam problemas;

– Cooperacao diaria entre as pessoas ligadas ao negocio e as ligadas ao

desenvolvimento;

– Considera que a comunicacao cara a cara e a mais vantajosa;

– Os projectos sao feitos por indivıduos motivados e de confianca;

– Atencao contınua aos detalhes tecnicos e bom desenho;

– Simplicidade;

– Equipas autonomas;

– Adaptacao regular a ambientes dinamicos.

Pelo contacto proposto com clientes e pela nao recusa de requisitos dinamicos,

esta famılia de metodologias apresenta-se como uma boa aposta.

• Extreme Programming[27] - modelo agil que assenta em caracterısticas como:

– Comunicacao;

– Simplicidade;

– Feedback do trabalho realizado;

– Coragem (autonomia);

– Respeito pelo trabalho e crıtica dos outros;

Envolve a tentativa de codificar o mais rapido possıvel, tentando sempre sim-

plificar sem medo de mudar posteriormente e ter a possibilidade de receber

40


feedback rapidamente, por exemplo atraves de testes automaticos. Estes as-

pectos levam a requisitos instaveis, conflitos de objectos atraves do uso de di-

ferentes perspectivas do cliente e escalabilidade da equipa de desenvolvimento.

Algumas das praticas da XP nunca poderiam ser usadas devido a dimensao.

Considera-se, mesmo assim, como uma opcao com possibilidades.

4.2.2 Scrum

Das metodologias acima descritas ja se podem encontrar algumas que se pode-

riam enquadrar no projecto. Em particular todas as que se adaptam a constantes

mudancas nos requisitos, que promovam a comunicacao com o cliente e que possi-

bilitem algum grau de autonomia a equipa de desenvolvimento. Uma metodologia

Scrum[28][29] segue todos os requisitos propostos, para alem de ser uma metodolo-

gia ja usada pela unidade de desenvolvimento no qual o Siemens Reporting se

encontra inserido.

O Scrum tornou-se assim a metodologia de desenvolvimento a seguir. A figura

4.15 resume bastante bem esta metodologia, sem entrar em pormenores.

Figura 4.15: Fluxo de trabalho do Scrum

Este fluxo resume-se ao seguinte:

• Existem funcionalidades do produto ainda por desenvolver;

• A equipa compromete-se a desenvolver um certo numero de funcionalidades

num espaco de 30 dias - sprint;

• Terminados estes 30 dias e feita uma entrega dos resultados;

41


• Depois da entrega e avaliacao, planeia-se o proximo sprint, ou seja, os proximos

desenvolvimentos;

• Diariamente e feita uma revisao do que se fez, das dificuldades encontradas e

planea-se que se vai fazer nesse dia.

4.2.3 Planeamento

A insercao no Scrum nao aconteceu logo no inıcio, dado que nessa altura ainda

se estava a proceder a mudanca da unidade de desenvolvimento responsavel pela fer-

ramenta. Assim, segundo a metodologia, foram apenas feitos 2 sprints. No entanto,

o trabalho desenvolvido para adequar a ferramenta conforme com a metodologia

considera-se uma vantagem para o futuro.

Esta tarefa obrigou a que se tivesse de fazer um levantamento das funcionalida-

des/tarefas desejadas junto dos responsaveis, isto e, dos representantes dos clientes.

Depois disto, fez-se o product backlog, procurando, com a aprovacao de todos, fa-

zer uma atribuicao de prioridades as tarefas. O passo seguinte foi a estimacao do

tempo gasto por cada tarefa de modo a permitir a definicao, por parte da equipa de

desenvolvimento, das tarefas a realizar durante um mes.

Este levantamento de funcionalidades/tarefas originou um product backlog com

54 itens. A partir daı, qualquer elemento ligado a ferramenta tinha a possibilidade

de editar o mesmo.

Como ja foi referido, apenas se realizaram 2 sprints originando uma sobrecarga

de horas para a parte ligada a este projecto. No primeiro, ficaram por realizar 30%

das horas de trabalho, tendo esse valor baixado para 16% no segundo (relacionada

com o autor deste projecto e das suas responsabilidades no apoio tecnico, ficou por

realizar apenas uma tarefa de 3 horas, mas que foi resolvida entretanto). Este in-

cumprimento deveu-se a falhas logısticas externas.

Apenas um dos metodos propostos pelo Scrum nao foi tido em conta - as reunioes

diarias. Isto ficou a dever-se a factores como a dimensao da equipa, a incompati-

bilidades de areas de accao, e aos horarios. Apesar disso, nao foi considerado um

entrave na aplicacao do Scrum.

O numero de itens do product backlog passou entretanto, de 54 para 71, devido

a volatilidade dos requisitos, tendo no final dos dois sprints ficado a faltar realizar

ainda 25 itens.

42


4.3 Registos da aplicacao

Em computacao, um registo (log) serve para proporcionar uma forma facil de

fazer auditoria sobre o sistema, permitindo conhecer o seu estado sem necessitar

da intervencao dos utilizadores. A automacao do registo interno do sistema e uma

boa forma de garantir alguma qualidade sobre o produto. Um bom sistema de

registos permite uma rapida identificacao e resolucao dos problemas. Por outro

lado, estes registos internos podem ajudar e ao business intelligence[30][31], ou seja,

permitem o conhecimento da forma como a ferramenta e usada, de modo a extrapolar

conclusoes para as areas do negocio ou mesmo a melhorar a ferramenta adaptando-a

as necessidades.

4.3.1 Escolha do Metodo

Basicamente um sistema de registos encontra-se dividido em duas partes:

• Registos da aplicacao;

• Registos para o sistema operativo - event log do Windows;

Geralmente, quando da ocorrencia de um erro grave, este e sinalizado no event

log do windows, podendo ser tambem guardado em ficheiro de texto. No desenvolvi-

mento da aplicacao optou-se por registos da aplicacao colocados em ficheiro, usando

uma hierarquia para varios tipos de registo. Existem varias formas de implementar

este sistema sendo as mais simples as que envolvem o uso de bibliotecas criadas para

esse efeito [32].

4.3.2 Implementacao

Na implementacao do sistema de registos foi usado o Log4Net[33] que basica-

mente suporta:

• Multiplas frameworks ;

• Multiplos outputs ;

• Arquitectura hierarquica;

• Configuracao por XML;

• Configuracao dinamica;

• Contextualizacao do registo;

• E baseado no log4j, em desenvolvimento desde 1996;

43


O que significa que se adequa perfeitamente para as necessidades. Assim iniciou-

se a implementacao do sistema de registos no servidor e no cliente. No servidor, o

trabalho efectuado consistiu na substituicao dos varios registos atraves da introdu-

cao de mensagens mais completas e em mais locais. A tarefa foi simplificada pela

ajuda dada pelo criador do codigo desta parte da aplicacao. O sistema de registo

no cliente, que era muito rudimentar, foi substituıdo por um muito mais completo.

Para alem de registos de texto, a biblioteca suporta o envio dos registos por

email, tendo esta opcao ficado configurada para erros graves. A hierarquia de regis-

tos permite um acesso facilitado a uma ferramenta de inspeccao independentemente

do ambiente no qual a ferramenta esteja a ser usada. Na figura 4.16 apresenta-se um

exemplo das mensagens de debug, que geram um relatorio automatico para o editor.

Nao foi feita qualquer tentativa para se criar business intelligence, no entanto, o

sistema de registos ficou com flexibilidade suficiente para ajudar nessa tarefa.

4.3.3 Outros Resultados

Para que se tivesse uma nocao das partes que deveriam produzir registos, foi

efectuada em ambos os casos, com destaque para o caso do cliente, uma analise ao

fluxo do programa. Essa analise foi aproveitada para criar varios diagramas repre-

sentativos da sequencia de actividades envolvidas na criacao de relatorios.

No anexo A, seccao 8.5, apresenta-se o trabalho produzido como extra da imple-

mentacao dos registos. Esta descricao, resumida, implica a descricao das actividades

efectuadas em varios momentos da execucao do programa.

• Antes do login;

• Seleccao do estudo e abertura do editor;

• Gravacao.

Na figura 4.17, indicam-se os passos para efectuar a actividade de login. Consis-

tem em testes a configuracao da funcionalidade impersonate do .NET e ao estado

do servidor e da base de dados. Como a aplicacao pode ser chamada por outras, e

tambem verificado o estado dos parametros passados.

Depois do login, a fase seguinte e a seleccao do estudo para o qual se quer um

relatorio. Isso e retratado na figura 4.18. Esta parte implica alguns testes para

se verificar que tipo de accao se pretende ao abrir o editor Siemens Reporting,

44


07-07-2008 15:32:50 DEBUG - Number of brokers: 107-07-2008 15:32:50 DEBUG - Broker status tested:True07-07-2008 15:32:51 DEBUG - Database access configuration successful.07-07-2008 15:32:53 DEBUG - RetrieveSysUsersTask gives the following online users: [vgama]07-07-2008 15:32:58 DEBUG - Tried login for vgama07-07-2008 15:32:58 DEBUG - Online login accepted for vgama07-07-2008 15:32:58 DEBUG - Save the local user vgama07-07-2008 15:32:58 DEBUG - Command issued: InitializationUtilities New.07-07-2008 15:32:58 DEBUG - Number of brokers: 107-07-2008 15:32:59 WARN - No studies for mapping WHERE Broker_Date >= ’30-06-2008’07-07-2008 15:32:59 DEBUG - Number of Patients:0 and Studies:007-07-2008 15:33:08 DEBUG - Getting all studies(GetAllStudies) for query[WHERE 1=1]gives[333]studies.07-07-2008 15:33:09 DEBUG - Number of Patients:257 and Studies:33307-07-2008 15:33:15 DEBUG - Number of online templates:407-07-2008 15:33:18 DEBUG - Creating document for step AutoBuildReport(open|new report).07-07-2008 15:33:18 DEBUG - Start of Build Report Task.07-07-2008 15:33:18 DEBUG - Number of brokers: 207-07-2008 15:33:20 DEBUG - Building report for study[1.2.276.0.200805190825002008222581].07-07-2008 15:33:20 DEBUG - Report will be built for patient [SILVA, ANTONIO],date[19-03-2008 08:57:00], procedure [Cateterismo Diagnostico]visualPackage[1-CHVNG Hemodinamica Standard].07-07-2008 15:34:02 DEBUG - Get SDReportFile for study [1.2.276.0.200805190825002008222581]responds[]07-07-2008 15:34:02 DEBUG - Building [2] template pages07-07-2008 15:34:02 DEBUG - Template Page [102 - Cena] optional,repeatable has [2] page objects.07-07-2008 15:34:02 DEBUG - PageObject [Template Container-MediaObjectTemplate] is Page Object Template.07-07-2008 15:34:02 DEBUG - Trying to match non text maps.07-07-2008 15:34:02 DEBUG - Trying to match MediaObjectTemplate[105 - Template Container] type [.DicomDerivedObject].07-07-2008 15:34:02 DEBUG - Match Online run map[4] from PageObjectTemplate07-07-2008 15:34:02 DEBUG - GetImages, with sql[ WHERE((study_id = ’1.2.276.0.200805190825002008222581’))].07-07-2008 15:34:12 DEBUG - GetImages, gives [10] IDicomExtendedInfo07-07-2008 15:34:12 DEBUG - GetImages gives 2 images:N: [1] size: [59] Instance: [1.3.12.2.1107.5.4.5.35017.30000008051907404626500000010.512]N: [1] size: [53] Instance: [1.3.12.2.1107.5.4.5.35017.30000008051907404626500000012.512]07-07-2008 15:34:12 DEBUG - Trying to match text maps.07-07-2008 15:34:12 DEBUG - Text maps has 0 matchs.07-07-2008 15:34:12 DEBUG - Maps from Template Page[102 - Cena] has [2] matches.07-07-2008 15:34:12 DEBUG - Adding PageObject(media) to Page [0 - Cena]07-07-2008 15:34:12 DEBUG - Template Page[102 - Cena] is Repeatable, creating pages for repeated items.07-07-2008 15:34:12 DEBUG - Adding PageObject(media) to Page [0 - Cena 2]07-07-2008 15:34:12 DEBUG - template page generated [2] report pages.07-07-2008 15:34:12 DEBUG - Template Page [103 - Conclus~oes] has [3] objects.07-07-2008 15:34:12 DEBUG - Checking Page Object [Template Container -TextObjectTemplate]07-07-2008 15:34:12 DEBUG - PageObject [Template Container -TextObjectTemplate] is Page Object Template.07-07-2008 15:34:12 DEBUG - Text mapping found in Page Object Template[Template Container - TextObjectTemplate]07-07-2008 15:34:12 DEBUG - Checking Page Object [Label - Siemens.Medical.PT.OM.Objects.TitleObject]07-07-2008 15:34:12 DEBUG - Trying to match non text maps.07-07-2008 15:34:12 DEBUG - Trying to match text maps.07-07-2008 15:34:12 DEBUG - Trying to match TextObjectTemplate[107 - Template Container] type [TextObject].07-07-2008 15:34:54 DEBUG - Trying to match TextObjectTemplate [108 - TextObjectTemplateController1]type [Siemens.Medical.PT.OM.Objects.TextObject].07-07-2008 15:34:54 DEBUG - Get SD Report text for study [1.2.276.0.20080519082500200822258107-07-2008 15:34:54 DEBUG - 0 - [Acesso/Encerramento]07-07-2008 15:34:54 DEBUG - 1 - [O Medico]07-07-2008 15:34:54 DEBUG - Text maps has 0 matchs.07-07-2008 15:34:54 DEBUG - Maps from Template Page[103 - Conclus~oes]has no matches and Optional flag is false.07-07-2008 15:34:54 DEBUG - template page generated [1] report pages.07-07-2008 15:34:54 DEBUG - Report has 3 pages07-07-2008 15:34:54 DEBUG - Get nonmapped dicoms07-07-2008 15:34:54 DEBUG - GetImages(possible non mapped images),with sql[ WHERE (study_id = ’1.2.276.0.200805190825002008222581’)AND (instance_id <>’1.3.12.2.1107.5.4.5.35017.30000008051907404626500000010.512’)AND (series_id <> ’1.3.12.2.1107.5.4.5.35017.30000008051907404626500000010.512’)].07-07-2008 15:34:54 DEBUG - GetImages, gives [0] IDicomExtendedInfo

Figura 4.16: Exemplo simplificado de um log na hierarquia debug

45


Figura 4.17: Actividades ate ao login

46


Figura 4.18: Actividades desde a seleccao de um estudo ate a abertura do estudo no editor

47


basicamente as questoes a responder sao:

• Tem um modelo de relatorios? qual?

• Tem VisualPackage? Qual?

• Usar todas as imagens? Ou so algumas?

Na figura 4.19 esta a continuacao deste processo. Um pequena analise a estes

diagramas revela um divisao clara face a existencia de um modelo de relatorio. Com

esta divisao conseguem-se 3 situacoes distintas: a abertura do editor para um mo-

delo de relatorios, para relatorios automaticos, ou para relatorios feitos no momento

- ad-hoc.

Outro aspecto a reter e a forma como os relatorios automaticos sao gerados. Este

processo inicia-se ao percorrer todas as paginas do modelo usado nesta automacao.

Em cada uma destas e feita uma inspeccao aos objectos que existem na pagina. Se

forem objectos com regras de mapeamento, estas sao retiradas e executadas tendo

em conta que as regras de texto estao ligadas ao Syngo Dynamics e as regras de

DICOMs estao ligadas ao servidor do Siemens Reporting, dado que apenas se

envia um consulta SQL ao servidor.

Ao mesmo tempo que se fazem estas consultas, caso exista, e tambem pedido

o ficheiro pdf ao Syngo Dynamics, correspondente ao diagnostico do estudo. No

fim sao tambem pedidas todas as imagens DICOM pertencentes ao estudo, que nao

foram mapeadas pelas regras.

Na figura 4.20 estao representadas as actividades associadas a gravacao para

CD/DVD. Rapidamente se percebe da divisao em tres partes. A primeira, coloca

ficheiros estaticos numa pasta para depois os gravar. Estes ficheiros sao um execu-

tavel, que serve de projector para o ficheiro report.swf, todos os anexos do relatorio

e ficheiros de script (bat) para abri-los, passando depois para a copia de um vi-

sualizador de DICOMs, terminando com a criacao de um ficheiro auto-executavel

(autorun) para o ficheiro executavel inicial.

A divisao implica tambem a separacao da tarefa de descarregar os DICOMs ori-

ginais e a colocacao destes ficheiros numa pasta preparada para a sua gravacao,

segundo um hierarquia DICOM.

48


Figura 4.19: Actividades desde a seleccao de um estudo ate a abertura do estudo no editor

49


Por ultimo, a geracao dos flash de apresentacao do relatorio. No fundo e a

geracao do report.swf e dos varios ficheiros swf iniciados pela letra ”s”, um para

cada pagina. Isto e feito usando a injeccao de scripts em swf base provenientes do

VisualPackage (fundos) associado ao relatorio.

4.4 Configuracao

Qualquer produto deve ser simples de configurar de modo que qualquer nova ins-

talacao seja feita no menor tempo possıvel. No decurso da exploracao da ferramenta,

e principalmente a medida que se documentava, foi possıvel compreender algumas

partes que estavam demasiado rıgidas e tambem que tipo de trabalho teria de ser

feito para aumentar a flexibilidade sobre as mesmas.

De seguida e dada uma ideia do tipo de trabalho desenvolvido para aumentar

a flexibilidade. No fim do trabalho estas pequenas configuracoes foram todas inte-

gradas, sendo criado um manual de utilizacao da ferramenta de configuracao. Este

manual esta disponibilizado no anexo C.

4.4.1 Fundo da Aplicacao e Output final

A ferramenta tem duas partes onde o grafismo varia de instalacao para instalacao.

E uma forma de personalizar a ferramenta para cada hospital, ou para cada unidade

hospitalar. Assim temos:

• O fundo do cliente - na parte onde se pode editar os relatorios (automaticos

ou gerados manualmente);

• A apresentacao flash que e gravada em CD/DVD.

4.4.1.1 O Que Envolve

Esta configuracao permite dar flexibilidade ao conceito de VisualPackage e que

basicamente e um conjunto de ficheiros estaticos directamente relacionados com a

unidade hospitalar onde vai ser usado o Siemens Reporting. Na pratica temos:

• Uma imagem, por exemplo jpg, a qual define o fundo do cliente;

• 3 ficheiros swf, isto e, flash preciamente compilados, os quais definem a apre-

sentacao flash final.

Estes 4 ficheiros por VisualPackage estao no servidor e quando o cliente necessita

de gerar um relatorio, estes sao-lhe enviados. O que isto significa e que um relatorio

50


Figura 4.20: Actividades associadas a gravacao

51


tem sempre associado estes ficheiros. Se for feito automaticamente, isto e, atraves

de um modelo de relatorio, este ja tem definido qual o seu VisualPackage. Quando e

feito um relatorio manualo, sem recursos a modelos, e pedido qual o VisualPackage

a usar.

O papel da imagem e facil de entender, tem a funcao de dar um aspecto mais

WYSIWYG a ferramenta, dando um fundo a aplicacao igual ao output final. Por

outro lado o uso de 3 ficheiros swf prende-se com a forma como a apresentacao de

flash e criada. Esta apresentacao e criada usando a biblioteca Turbine (seccao 2.3.1)

a qual cria novos ficheiros swf, a partir de ficheiros swf base. De realcar que apenas

2 dos 3 ficheiros swf sao usados pela biblioteca.

Os 3 ficheiros necessarios sao entao:

• Um ficheiro que serve como base do Turbine para o criar o swf principal da

apresentacao. Este por sua vez carrega dinamicamente outros ficheiros swf

correspondentes a cada dispositivo do relatorio;

• Cada dispositivo do relatorio e tambem gerado recorrendo ao Turbine e a um

outro swf base;

• O ultimo ficheiro e apenas copiado para o output final, pois so usa texto dina-

mico mas com regras bem definidas, fazendo apenas um carregamento de um

ficheiro de texto, que e criado quando se grava um CD/DVD.

Analisando os ficheiros que sao gravados para CD/DVD, consegue-se compre-

ender melhor. Assim a figura 4.21 representa o sistema de ficheiros, contendo um

auto-executavel (autorun) para um ficheiro flash executavel. Este carrega o re-

port.swf, que por sua vez carrega todos os slides do relatorio, representados pelos

ficheiros swf que comecam em ”s”. O ultimo slide permite abrir os anexos que estao

na pasta ”fscommand”, ou abrir um visualizador de DICOMs que se encontra na

mesma pasta, o qual acede aos DICOMs originais que estao na pasta ”DICOM”.

Depois desta explicacao, o objectivo deste tipo de configuracao e simples, me-

lhora a insercao no sistema destes 4 ficheiros e ter uma forma simples de editar os

ficheiros swf. Este ficheiros sao compilados, ou seja, so com o uso da fonte (ficheiros

fla) correspondente e que se pode mudar sem restricoes esses ficheiros. O que se

pretende e que o processo de edicao seja o mais simples possıvel e com flexibilidade

suficiente para se mudar o ambiente grafico de forma a adaptar-se a unidade hospi-

talar que vai usar esse VisualPackage.

52


Figura 4.21: Sistema de ficheiros de um relatorio gravado

O que se pretende com esta flexibilidade e ter partes do swf que possam ser

editadas facilmente, nomeadamente:

• Substituir imagens;

• Mudar texto e a sua cor;

• Mudar cores de fundo;

A primeira coisa que se deve fazer e tentar perceber as condicoes que se tem para

encontrar solucoes, isso envolve analisar os recursos disponıveis. Uns dos problemas,

logo levantado foi o facto de as fontes existentes nao serem, claramente, a ultima

versao, tendo diferencas em relacao as usadas pelo sistema implementado. Para alem

disso o conteudo destes nao esta especificado em lado nenhum.

De seguida analisaram-se as fontes disponıveis e assim se ficou a saber que sao

da versao flash 6 utilizando actionscript 2.

53


4.4.1.2 Possibilidades

Com o acesso a imensos documentos presentes em [34] foi possıvel reunir uma

serie de possıveis implementacoes.

• Usar swf gerados pelo Flex[35]; usando o comando [embeb] consegue-se em

compile-time injectar conteudos multimedia. Obriga a recriar os ficheiros swf

em flex e ter uma forma simples de compilar.

• Usar flash 9/actionscript 3, que tambem tem o mesmo tipo de comando. Isto

obriga a migrar os ficheiros fla para actionscript 3 e claro que o uso deste tipo

de solucao obriga a compilacao das fontes.

• Usar as capacidades do actionscript 2, que e capaz de carregar recursos em

runtime. Nao implica ter de compilar nenhum ficheiro fla quando se quer

personalizar os swfs, mas obriga ao aumento de ficheiros por VisualPackage.

• Criar um tutorial que indique, num editor de fla, como se chega aos locais onde

se pode personalizar o resultado, compilado depois para swf.

4.4.1.3 Implementacao

Existem varias restricoes que devem ser tidas em conta. Por um lado, o aumento

de flexibilidade tem de ser o mais simples possıvel de usar, por outro lado torna-se

desaconselhavel complicar a forma como a ferramenta usa os VisualPackages. As

possibilidades apresentadas anteriormente, embora possıveis, obrigam a consideracao

dos seguintes cenarios:

• Usar ferramentas de edicao pagas como o flex ou flash, que obriga os utilizadores

a terem algum conhecimento sobre estas. Ou usar SDK gratuitos, onde tambem

e necessario algum conhecimento extra para se poderem usar eficientemente;

• Aumentar o numero de ficheiros que um VisualPackage tem, visto serem usados

ficheiros extra em runtime;

• Aumento de ferramentas extra necessarias a aplicacao.

Tenta-se assim usar tecnologias ja existentes no sistema, nao complicando o fun-

cionamento interno da aplicacao. Isto leva ao uso do Turbine e a criacao de uma

aplicacao para este efeito. Esta, basicamente tem opcoes para se explorar o sistema

de ficheiros a procura de imagens, existindo tambem campos para adicionar texto

e campos de definicao de cor. Na figura 4.22 encontra-se um exemplo de uma das

54


Figura 4.22: Editor para o swf principal da apresentacao, na opcao do separador central

opcoes ligadas ao swf que esta na base da apresentacao final dos relatorios.

Apos estes estarem definidos, basta exportar e tem-se um ficheiro swf. Depois

disto bastara inserir no sistema. Como foi referido existem 3 ficheiros swf necessa-

rios, permitindo esta aplicacao personalizar 2 destes: aqueles os que estao envolvidos

na personalizacao de cada unidade hospitalar. Quanto ao terceiro nao existe neces-

sidade porque e sempre igual.

Criou-se um manual para o uso desta ferramenta, que no fundo esta integrada

no resto das configuracoes do sistema, ou seja, tem-se apenas 2 ferramentas de con-

figuracao. Uma para o servidor, outra para o cliente.

E sempre importante demonstrar o produto, mas nao existia nenhum VisualPac-

kage para alem dos usados em producao e que estao adaptados a unidade. Por esse

motivo foi desenhado uma personalizacao para demonstracoes, a qual fica por defeito

na ferramenta de configuracao. Na figura 4.23 esta o resultado final da ferramenta,

ou seja, a apresentacao em flash, para um relatorio completamente vazio mostrando

55


Figura 4.23: Desenho grafico generico da Siemens

o desenho grafico criado nesta fase.

4.4.2 Gestao de Utilizadores

Outro aspecto da configuracao sao os utilizadores. Existia ja uma pequena fer-

ramenta de gestao de utilizadores que apenas se tornou mais robusta e foi integrada

na ferramenta de configuracao.

4.4.3 Logs

Tendo em conta que se criou um sistema de logs que usa um ficheiro de configura-

cao, e tambem necessario ter na ferramenta de configuracao, uma abstraccao capaz

de editar a configuracao dos logs, sem ser necessario conhecer nada sobre estes.

4.4.4 Outros Parametros

O Siemens Reporting usa varios ficheiros de texto para configuracao. Assim,

neste ponto, foi adicionado a ferramenta de configuracao um ambiente grafico de

56


edicao dos mesmos.

Por outro lado, apesar de existirem outras ferramentas de configuracao, por exem-

plo, para a insercao de novos VisualPackages, para aumentar a simplicidade e tornar

essas ferramentas mais robustas, foi feito uma revisao a este processo.

Figura 4.24: Menu de Configuracao do Cliente

Apenas a tıtulo de exemplo apresenta-se o menu da aplicacao de configuracao na

figura 4.24, tendo a configuracao de registos, grafismos, edicao dos ficheiros de texto

de configuracao e utilizadores. Para alem de se verem as opcoes de visualizacao de

relatorios e de grafismos, estas duas opcoes foram fortemente revistas e alteradas

face as existentes na fase anterior do trabalho.

4.5 Globalizacao

Nesta parte[36], apesar do grau de dificuldade ser reduzido, o tempo exigido e

bastante elevado.

Antes da implementacao propriamente dita, teve de ser decidido o modo como

se iria desenvolver a globalizacao da ferramenta.

4.5.1 Metodos

Nao existem regras muito especıficas para se globalizar uma aplicacao. Por isso,

depois de se consultar algumas possibilidades passou-se para a implementacao.

Durante a exploracao obtiveram-se as seguintes formas de globalizar:

• Ter ficheiros de texto contendo todas as strings do codigo, por exemplo em

XML, bastando depois aceder ao ficheiro da lıngua pretendida;

57


• Usar ficheiros de recursos do .NET para cada projecto da solucao, contendo

as strings e outras definicoes como tamanhos de todos os componentes dos

formularios para os quais se aplica uma determinada lıngua.

4.5.2 Implementacao

De modo a rentabilizar o tempo decidiu-se agrupar as string todas num unico

ficheiro para toda a solucao. Os tamanhos das strings nao variam significativamente

e por isso nao existiu a necessidade de adaptar os forms para as varias lınguas. Esta

opcao prende-se com o facto de assim a implementacao ser mais rapida.

Fica-se assim apenas com um ficheiro de recursos para cada lıngua, ou melhor,

para cada cultura. Isto permite uma facil localizacao das strings para o caso de

surgir necessidade de se efctuar alguma alteracao. Uma das principais vantagens e

a simplicidade com que se adiciona uma nova lıngua, podendo-se mesmo recorrer a

ferramentas de traducao automatica.

Isto vem de encontro com o desejo das alteracoes futuras serem faceis de imple-

mentar.

No final obteve-se um ficheiro com mais de 400 strings.

4.6 Apoio Tecnico

O plano inicial do projecto nao contemplava esta parte da aplicacao. No entanto,

rapidamente, e de modo a aumentar a qualidade e satisfacao por parte dos clientes,

foi tendo cada vez mais tarefas associadas.

Destas destacam-se as seguintes:

• Remocao da dependencia da data no sistema;

• Correccao dos bugs que foram sendo encontrados no decurso da utilizacao da

aplicacao;

• Mudancas no fluxo de trabalho da ferramenta quando existem tarefas em lista

de espera;

• Possibilidade de cancelar tarefas pendentes;

• A criacao dos utilizadores deve ter em atencao que os nomes devem ser unicos;

58


• A criacao de maquinas virtuais para demonstracao, com fundo e apresentacao

em flash, com um grafismo generico da empresa;

• Testes em ambiente de producao;

• Actualizacao da ferramenta no ambiente de producao;

• Introducao de uma mensagem de texto em todos os diapositivos com imagens.

4.7 Resumo

No final do trabalho criou-se uma maquina virtual de demonstracao. Criou-se

assim uma ambiente virtual de demonstracao, usando a versao do Siemens Repor-

ting desenvolvida ate ao momento e com a configuracao feita atraves das ferramentas

criadas. A figura 4.25 mostra o editor para demonstracoes.

Figura 4.25: Siemens Reporting Demo

Pelo tipo de trabalho desenvolvido nota-se que este projecto nao e um projecto

tıpico, onde se define uma solucao para um problema especıfico. E sem duvida um

trabalho de expansao, onde a autonomia e a capacidade de analise sao fundamentais

59


para dar resposta a um elevado numero de problemas de teor bastante variado.

60

Capıtulo 5

Conclusoes e Trabalho Futuro

Esta seccao da conta da situacao face aos objectivos inicialmente tracados, bem

como do estado do projecto na empresa e as suas repercussoes na relacao com os cli-

entes. Como este projecto incidiu sobre uma ferramenta em desenvolvimento, torna-

se essencial avaliar os resultados que o presente trabalho teve em todo o contexto

da ferramenta face a situacao em que se encontrava anteriormente. Sao tambem

expostas as principais dificuldades encontradas ao longo do trabalho. Por ultimo e

apresentado um conjunto de possıveis desenvolvimentos futuros e de eventuais rumos

a seguir.

5.1 Cumprimento dos objectivos

Em geral, os objectivos propostos para este projecto foram cumpridos, tendo

sido praticamente cumprido todo o plano de trabalho acordado inicialmente. Ape-

nas uma tarefa nao foi realizada, uma vez que perdeu prioridade face a outras. Nesse

aspecto e devido a forma como o projecto foi gerido, atraves da adaptacao as neces-

sidades, podemos acrescentar que, alem de cumprir bastante bem o plano proposto,

foi dada resposta a muitos outros problemas que entretanto surgiram.

Esta conclusao e complementada pela satisfacao demonstrada pelos clientes, uma

vez que, actualmente, a ferramenta apresenta um elevado nıvel de qualidade e vai de

encontro ao desejado pelas organizacoes. Constatou-se uma evolucao bastante posi-

tiva, principalmente ao nıvel de qualidade, face a situacao inicial de funcionamento

da ferramenta.

61


Foi, tambem, melhorado o sistema de logs, permitindo actualmente detectar pro-

blemas no funcionamento da ferramenta atraves do registo de erros enviado pela

aplicacao. Isto permite obter um feedback positivo, uma vez que nao tem sido re-

portados erros.

Automaticamente, pelo sistema de logs, e pessoalmente pelo contacto com o cli-

ente, a impressao que se tem do funcionamento da ferramenta e boa.

No que toca a aspectos complementares, tais como o apoio ao planeamento, a

inclusao de uma metodologia de desenvolvimento permite a definicao de regras para

futuras alteracoes a ferramenta.

Como conclusao final, estamos convictos de que o trabalho desenvolvido ao longo

deste projecto transformou a ferramenta inicial num produto razoavelmente consis-

tente.

5.2 Perspectivas e sugestoes futuras

Neste ultima seccao apontam-se algumas sugestoes para o desenvolvimento fu-

turo.

Dado que actualmente so se preve, a curto prazo, a instalacao da aplicacao no

Hospital da Arrabida, a aposta da empresa e seguir com o trabalho desenvolvido e

apenas esse. Assim as sugestoes sao as seguintes:

• Mudanca da biblioteca DICOMObjects para uma que implique menos custos;

as responsabilidades desta biblioteca sao grandes, por isto, esta alteracao e

substancial.

• Mudar o mapeamento da base de dados para um que seja semelhante, tanto

no servidor como no cliente, evitando assim a repeticao de conceitos para o

cliente e o servidor.

• Tornar a arquitectura do sistema mais acessıvel ao cliente, evitado assim o

acesso constante ao servidor, muitas vezes redundante. Isto permite levar mais

processamento para o lado do cliente, principalmente na forma como se pro-

cessam as imagens mapeadas nos modelos de relatorios.

• Desenvolvimento de novas toolboxes que possam ser inseridas nos relatorios,

por exemplo:

– linhas;

62


– setas;

– ovais;

– polıgonos diversos;

• Simplificacao dos contentores das toolboxes que sao inseridas nos relatorios;

• Mudar o fluxo da aplicacao para se iniciar com um relatorio em branco e

so depois serem dadas todas as outras opcoes. Isto torna a aplicacao um

pouco mais semelhante ao que os utilizadores estao habituados a ter num editor

generico. Na seccao 1.2 refere-se o fluxo actual.

• Criar uma interface flexıvel para gravacao de CD/DVD atraves de robots ;

• Criar uma bateria de testes unitarios capazes de testar o fluxo da aplicacao,

bem como todas as funcionalidades de que dispoe.

Na nossa perspectiva, de todas estas sugestoes, as mais importantes sao as que se

referem as novas toolboxes, a simplificacao da utilizacao dos contentores das toolboxes

e a bateria de testes. Esta bateria deveria ser usada constantemente, indo ao ponto

de se sugerir o desenvolvimento baseado em testes - TDD.

63


64

Referencias

[1] Siemens. Siemens ag - global web site, Junho 2008. Site oficial em http:

//siemens.com/.

[2] Society for Vascular Surgery. Ct angiography. disponıvel em http://www.

vascularweb.org/patients/NorthPoint/CT_Scan.html.

[3] Nuno Guimaraes e Pedro Almeida. Reporting project status, Junho 2008.

[4] Siemens. Artis - exames cardiovasculares, Junho 2008. Artis Zee Multi-purpose system , disponıvel em http://www.medical.siemens.com/webapp/

wcs/stores/servlet/ProductDisplay~q_catalogId~e_-11~a_catTree~e_

100010,1007660,12751,14335~a_langId~e_-11~a_productId~e_181903~a_

storeId~e_10001.htm.

[5] DigiMatic. Digimatic-med - gravador de cd/dvd/blu-ray, Junho 2008. Infor-macao sobre o DIGIMatic-MED disponıvel em http://www.digimatic.eu/

dicom_en.htm.

[6] Loic Boussel Philippe Puech. Visualizador dicom - dicomworks, Junho 2008.DicomWorks disponıvel em http://dicom.online.fr/.

[7] Masoom Haider. Dicom for powerpoint, Novembro 2003. Department of MedicalImaging, University of Toronto, Canada, disponıvel em http://www.radfiler.

com/dicomppt.htm.

[8] Siemens. Syngo dynamics, Junho 2008. Informacao disponıvel em http://www.

syngo.com/.

[9] Microsoft. .net framework, Junho 2008. Informacoes sobre a framework .Net,disponıvel em http://www.microsoft.com/net/.

[10] Microsoft. Microsoft developer network, Junho 2008. APIs e tutorias para .Net,disponıvel em http://msdn.microsoft.com/en-us/default.aspx.

[11] GTE Darleen Sadoski. Client/server software architectures–an overview, Agosto1997. Artigo Arquitectura cliente-servidor, disponıvel em http://www.sei.

cmu.edu/str/descriptions/clientserver_body.html.

[12] Microsoft. Microsoft developer network, Junho 2008. Informacao sobre.Net Remoting, disponıvel em http://msdn.microsoft.com/en-us/library/

kwdt6w2k(VS.71).aspx.

65

http://siemens.com/

http://siemens.com/

http://www.vascularweb.org/patients/NorthPoint/CT_Scan.html

http://www.vascularweb.org/patients/NorthPoint/CT_Scan.html

http://www.medical.siemens.com/webapp/wcs/stores/servlet/ProductDisplay~q_catalogId~e_-11~a_catTree~e_100010,1007660,12751,14335~a_langId~e_-11~a_productId~e_181903~a_storeId~e_10001.htm




http://www.digimatic.eu/dicom_en.htm

http://www.digimatic.eu/dicom_en.htm

http://dicom.online.fr/

http://www.radfiler.com/dicomppt.htm

http://www.radfiler.com/dicomppt.htm

http://www.syngo.com/

http://www.syngo.com/

http://www.microsoft.com/net/

http://msdn.microsoft.com/en-us/default.aspx

http://www.sei.cmu.edu/str/descriptions/clientserver_body.html

http://www.sei.cmu.edu/str/descriptions/clientserver_body.html

http://msdn.microsoft.com/en-us/library/kwdt6w2k(VS.71).aspx

http://msdn.microsoft.com/en-us/library/kwdt6w2k(VS.71).aspx

REFERENCIAS

[13] Wikipedia Contributors. Comparison of the java and .net platforms, 2008.

[14] Christopher W. Cowell-Shah. Nine language performance round-up: Bench-marking math and file i/o. http://www.osnews.com/story/5602, 2004. Com-paracao de tempos de diversas linguagens, acedido a 25-Junho-2008.

[15] Adobe Systems Incorporated. Site oficial do adobe flash. http://www.adobe.

com/products/flash/, 2008. acedido a 25-Junho-2008.

[16] Hibernated. Mapeamento de objectos em base de dados. http://www.

nhibernate.org/, 2008. Informacao sobre NHibernate, acedido a 25-Junho-2008.

[17] Blue*Pacific Software. Turbine 7 sdk with flash output. http://www.

blue-pacific.com/products/aspturbine/default.htm, 2008. Informacaosobre o Turbine 7, acedido a 25-Junho-2008.

[18] Medical Connections. Dicomobjectst. http://www.medicalconnections.co.

uk/html/dicomobjects.html, 2008. Informacao sobre o DicomObjects, ace-dido a 25-Junho-2008.

[19] Binary Magic. Magic cd/dvd burner (.net 1.x/2.x). http://www.

binarymagics.com/site/magic_cddvd_burner_dot_net.html, 2008. Gravarde CD/DVD da Binary Magic, acedido a 25-Junho-2008.

[20] Dockpanel suite. http://sourceforge.net/projects/dockpanelsuite/,2005. Biblioteca de janelas semelhates as do Visual Studio, acedido a 25-Junho-2008.

[21] Avisynth - editor de vıdeos por script. http://avisynth.org, 2008. Informacaosobre o AviSynth, acedido a 25-Junho-2008.

[22] Ffmpeg - codificador e descodificador de audio e vıdeo. http://www.ffmpeg.

org/, 2008. Informacao sobre o FFmpeg, acedido a 25-Junho-2008.

[23] Simon Brown. Software architecture document guidelines. http:

//www.codingthearchitecture.com/2008/03/18/software_architecture_

document_guidelines.html, 2008. acedido a 30-Junho-2008.

[24] Philippe Kruchten. Architectural blueprints - the ”4+1”view model of softwarearchitecture. IEEE Software 12 (6), pages 42–50, Novembro 1995.

[25] Barry W. Boehm. A spiral model of software development and enhancement.Maio 1988.

[26] Desenvolvimento de software Agil. Referencias em http://www.

agilealliance.org/, http://agilemanifesto.org/.

[27] Extreme programming. Referencias para XP em http://www.

extremeprogramming.org/, http://www.xprogramming.com/ e http:

//www.agilealliance.org/article/articles_by_category/12?page=3.

66

http://www.osnews.com/story/5602

http://www.adobe.com/products/flash/

http://www.adobe.com/products/flash/

http://www.nhibernate.org/

http://www.nhibernate.org/

http://www.blue-pacific.com/products/aspturbine/default.htm

http://www.blue-pacific.com/products/aspturbine/default.htm

http://www.medicalconnections.co.uk/html/dicomobjects.html

http://www.medicalconnections.co.uk/html/dicomobjects.html

http://www.binarymagics.com/site/magic_cddvd_burner_dot_net.html

http://www.binarymagics.com/site/magic_cddvd_burner_dot_net.html

http://sourceforge.net/projects/dockpanelsuite/

http://avisynth.org

http://www.ffmpeg.org/

http://www.ffmpeg.org/

http://www.codingthearchitecture.com/2008/03/18/software_architecture_document_guidelines.html



http://www.agilealliance.org/


http://agilemanifesto.org/

http://www.extremeprogramming.org/

http://www.extremeprogramming.org/

http://www.xprogramming.com/

http://www.agilealliance.org/article/articles_by_category/12?page=3

http://www.agilealliance.org/article/articles_by_category/12?page=3

REFERENCIAS

[28] Ikujiro Nonaka Hirotaka Takeuchi. The new new product development game,Janeiro 1986. Referencias em http://www.agilealliance.org/, http://

agilemanifesto.org/.

[29] Softhouse. Scrum in five minutes. http://www.softhouse.se/Uploades/

Scrum_eng_webb.pdf, 2008. acedido a 2-Julho-2008.

[30] Hans Peter Luhn. A business intelligence system. IBM Journal.http://www.research.ibm.com/journal/rd/024/ibmrd0204H.pdf.

[31] Power, D.J. A Brief History of Decision Support Systems. DSSResources.COM,World Wide Web, http://DSSResources.COM/history/dsshistory.html, v2.8, Maio 31, 2003.

[32] Csharp-source. Open source loggin tools in c#. http://csharp-source.net/open-source/logging, 2008. acedido a 2-Julho-2008.

[33] Apache Software Foundation. Log4net. http://logging.apache.org/

log4net/, 2008. acedido a 2-Julho-2008.

[34] Adobe Systems Incorporated. Guias sobre produtos adobe. http://www.

adobe.com/support/documentation/, 2008. acedido a 3-Julho-2008.

[35] Adobe Systems Incorporated. Mxml - embeber imagens em swf. http://kb.

adobe.com/selfservice/viewContent.do?externalId=tn_19243, 2008. ace-dido a 3-Julho-2008.

[36] MSDN. Globalization architecture for asp.net. http://msdn.microsoft.com/en-us/library/aa478974.aspx, 2008. acedido a 3-Julho-2008.

67




http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf

http://www.softhouse.se/Uploades/Scrum_eng_webb.pdf

http://DSSResources.COM/history/dsshistory.html

http://csharp-source.net/open-source/logging

http://csharp-source.net/open-source/logging

http://logging.apache.org/log4net/

http://logging.apache.org/log4net/

http://www.adobe.com/support/documentation/

http://www.adobe.com/support/documentation/

http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_19243

http://kb.adobe.com/selfservice/viewContent.do?externalId=tn_19243

http://msdn.microsoft.com/en-us/library/aa478974.aspx

http://msdn.microsoft.com/en-us/library/aa478974.aspx

REFERENCIAS

68

Anexos

69

Anexo A

Software Architecture Document

Reporting Software Architecture Document Date: 09-May-2008 Software Architecture Document Version: 1.0

Confidential Siemens, 2008 Page 20 of 38

The server may have attached the database, but this is not a restriction, since this way there is no need for more hardware. Both the server and the client need access to the file system, which means they can read/write to some part of the disk. The Client must have a CD/DVD Burn Drive, for obvious reasons.

The server maps the Receiver, Converter and Broker services; and the client has the Reporting editor process.

The hardware requirements are not fully tested but the system does not need any top hardware to run, since it was tested with an encoding(DICOM encoding tested) server running on Intel® Core™2 Duo, 700MB RAM clocking at 1minute per XA study encode; a non encoding server with 256MB RAM at 1,66 GHz; has for the client a 256MB RAM at 1,66 GHz works fine. The application processing needs are not the real constraint.

The main constraint is the network. The connection between the client and the server must be very good since there may be original DICOM images passing through the network. Therefore it's advise a LAN with the maximum bandwidth possible. The DICOM's size is to big to be ignored.

8.Implementation View [This section describes the overall structure of the implementation model, the decomposition of the software into layers and subsystems in the implementation model, and any architecturally significant components.]

8.1Overview

[This subsection names and defines the various layers and their contents, the rules that govern the inclusion to a given layer, and the boundaries between layers. Include a component diagram that shows the relations between layers. ]

This section will only defines some of it's layers, the ones who are have significant importance on the domain problem, this means Report Model, Report Generator and Mapping Engine. This 3 layers are part of the client and define the client itself since with Report Model we have a representation of the report, with the Mapping Engine, only the desired DICOM end up on the Report Model and finally with the Report Generator we get to transform the Report Model into a more appealing flash report.

[For each layer, include a subsection with its name, an enumeration of the subsystems located in the layer, and a component diagram.]

Illustration 10: Deployment view



8.2Mapping Engine

The Mapping engine is implemented on the following classes:

Note that the SQLQuery and ApplicationQuery only use Mapping as a parameters, the first transformers the rules into SQL, so it can be used in a sql query and the second, does the same query but to objects on this case a NameValueCollection.

As said on the logical view of Mapping Engine, a map is a rule or a group of rules therefore Mapping has one LogicalRoot, this one has a Rule and a RuleGroup, although theoretically speaking it could have both, it's implemented so that if has a Rule, it has not any RuleGroup and vice-versa.

The RuleGroup(abstract) is “realized” by AndGroup and OrGroup, so there is a logical operator between the elements inside the group. Note the term elements because inside a group it can exist a list of rules or a list of grouped rules or any dicom field, using the dicom representation through group and element ids. The list referred above is ordered.

A Rule defines a filter, this means it has a operator – RuleOperators, that defines the clause of the rule, for instance, StartsWith, Equals,NotEquals, BetweenRange,etc. As we can see the operator can refer ranges, so a Rule can have a Range. The last thing about a Rule is where it will be applied – FieldMappingTypes - creating a simple list of DICOM fields on which the rule can be applied. The previous diagrama shows how the classes are connected. The next has not the class but can show the attributes and the methods that make the previous connections happen.

Illustration 11: Mapping Engine Implementation View



This is compacted into:

� A Mapping Engine is a Mapping;

� A Mapping has a Root – LogicalRoot;

� A LogicalRoot has 2 fields one for one rule, the other for a group;

� A RuleGroup has a list of groups(_group) and/or a list of rules(_rules), also can have a parent group(parent);

� ANDGroup and ORGroup only differ with superclass on the field GROUPNAME(string “OR”/”AND”) representation the and/or logical operators ;

� A Rule specifies an operator(RuleOperators) and DICOM filtered fields, can have a range or a value to be filtered, this means the field “value” is an Object and ValueRanges is a Range;

� A Range has lower and upper bound and a type of data(double/date).

� SqlQuery has a Mapping(_mapping) and with GetMappingAsSql returns a sql string equivalent to the rules inside the map.

� ApplicationQuery receives a map and a list of of the DICOM attributes, matching with GetMatches which returns a list of dicom images, each image is represented by a NameValueCollection with the a collection of dicom attributes.

The last referenced to Mapping Engine is made on the data view, the classes represented above have a direct connection with some tables(MPG_Mapping, MPG_RuleGroup, MPG_Rule, MPG_RuleGroup_Groups, MPG_RuleGroup_Rules), this is explored in more detail in the following section.

8.3Report Model

The implementation of Report Model is pretty much a simple map of the logical view, there are new classes but the logical structure is the same, the most important classes are showed next.

Illustration 12: Used Classes in Mapping Engine



This diagram shows some of the top classes, namely Template and its extension Report. The most important difference between them, as said above on the logical view, is that a Report is filled with DICOMs, in other words it has an associated study, this can be seen on the field study of Report, representing the class Study of Clinical Model. Template has one VisualPackage(field style), several Attachment objects in the list present on the field _attachments and the many-to one connection with Page is done by _pages and _pageList, the _pageList is a list of Page(EntetyList more exactly – class from NHibernate) and the _pages is a collection(serializable and enumerable class) of the _pageList, its this one that is accessed throughout the application. As for the VisualPackage present on the Template, the field which does that is the style.

The attachments present on templates/reports are always files, so the data field inside an Attachment is StoredMedia – file descriptor, present on the logical view as StorableMedia.

As for the VisualPackage it defines the style of the final flash report, even though it can be seen as one logical class, its implemented on VisualPackage,VisualStyle and FlashComponents. First the VisualPackage defines the background and the swf files used to create the final flash report, this is done on the fields template and style. The first one is a FlashComponets, which basically defines 2 swf files, one for the introduction flash and the other is used to create every page in the report; it also as swf for a conclusion this is present in _others – a set of files; and the second is a VisualStyle a simple background image. With these 3 swf files and a background image it's defined a design background for the final flash report. Since we are talking about files, pageswf, templateswf, dbImage are StoredMedia and _others makes a reference to StoredMedia, it's not direct because it uses a key to get to the StoredMedia object, this is much like a xy function, if we have the x, we get the y.

The TextFormatting, defines the color, alignment and font of several text classes, but these are only present in the next diagram. And finally the Page is detailed: a page is knows where it belongs, using the field _parent which has the parent Template/Report reference. It also has all of the object containers – PageObject, with a collection of PageObject in _objects, this one is composed with the list of PageObject defined in _objectCollection. The logical view does not contemplate a page with a personal VisualPackage, but the data model allows it to have a specific background image, vStyle – VisualStyle, nevertheless this is not used.

Illustration 13: Report Model Top Classes



The next diagram has the class PageObject as the “master” class of diagram. This class is used to place containers inside a page and therefore create the page's content.

The number of extension arrows shows how important the PageObject abstraction is. This abstract class is realized by 6 other classes representing the actual objects that can be placed on a Report, plus 4 classes that can be used on a Template. The container pretty much defines everything that can be seen on a report. The first thing we should do when looking at the diagram is to understand what are the container(PageObjects) properties. It has a parent, a Page Object reference on the field _nHParent; a Dimension(Positionning project) object in dimension, this class is basically has a size and some methods to validate sizes inside the application constraints, then it has another Positionning project class, the Location, which like the name indicates specifies the location inside the application; and like Page has, PageObject has the same vStyle(VisualStyle) pointing to a background image that never changes.

Every other class in this diagram expands the PageObject, either to another abstract class or a class that itself is expanded, so it will be present a description of the classes and what they represent on the application's scope.

Template/Report:

� TextObject – the field text, represents a string that will compose a text field inside the report/template;

� TitleObject – much like a TextObject this class has a field titleText(string), other than that this string will be formatted with the help of the class TextFormatting and this creates a title on the report/template; the BindableTitleObject connects a TitleObject with a TitleObjectTemplate;

� DicomDerivedObject – it's an abstract class and it always represent a container for DICOMs, therefore the class' attributes represent DICOM images: size, number, dicom series and dicom identification; since this is a file it has a StoredMedia in dbImg

Illustration 14: Report Model internal classes



� ImageObject – this DicomDerivedObject realization is an image and consists of a image Bitmap, the one that is placed on the report.

� CineObject – another DicomDerivedObject realization but this one represents videos, so dbImg is StoredMedia for a video, the realization's attributes are 2 bools defining autorun and loop variables.

� MultipleMediaObject – creates a media strip with several columns and rows, much like a table; it's composed by a entity dictionary(_media), if a key is present then we get a value and in this case a value is a DicomDerivedObject, either a video or an image; and a _multiAux, a MultipleObject with the parent PageObject, the rows, the columns and the _media itself.

� TableObject – is a simple table, it has the rows, the columns the name and the data, this data is a DataTable from System.Data.

Template

� PageObjectTemplate - its an realization of PageObject capable of biding objects through rules, by the use of a Mapping Engine on the field mapping;

� TitleObjectTemplate – it's the title used in the table TitleObject, this means it's not used as a single object that is dragged for a template, represents a Syngo Dynamics report;

� TextObjectTemplate – when there is the need to place text inside a template this is the class that is used; it has a list of titles, basically T_TextObjectTemplate_Titles;

� MediaObjectTemplate – it's one media with a mapping engine so it's filled with DICOMs, other than that has bools for its attributes with a pretty self explained name, the same goes for the 2 TextFormatting – title and body; note that this class is use in Media Template and Media Strip Template, being the difference the field showResultsSamePage that has a default value for Media Template and “true” for the strip

� MultipleMediaObjectTemplate – this class extends MediaObjectTemplate in a way that creates a MultipleMediaObject with mapping rules: has the same table properties, rows, columns, margin and a entity dictionary(_templates) that create a MultipleObject, but this time with MediaObjectTemplate; however this is not the object that is created in a media strip(as said above)

With all of these classes we create templates and reports, in both there is the possibility to add more objects and some of them, in the template domain, can filter DICOMs using several rules. Finally its used a design background - composed by and an introductory swf, another swf used in every page, a third swf for the last report's page and a background image - in order to create a flash version of the report.

8.4Report Generator

The logical view cannot just be mapped to implementation classes. The Logical view Burn Report is called when the ConcludeAction method in ReportEditor is invoked.

This ConcludeAction runs the Command, GenerateOutputCommand which creates a new ParallelTask, named OutputReportTask that verifies if it will fetch the DICOMs or not based on the online status of reporting editor(can connect with broker). After that it will produce the final flash and put that flash, a DICOM viewer, the attachments and the original DICOMs inside a CD/DVD. This burning process is done inside the WriteMedia by the library MCDBControl from the MCDBNET2.dll.



The componet is spred throughout several projects: Reporting, SieDialogs(WriteMedia) and ReportFlashGenerator. The last is responsible to create the flash report, an importante subsystem since it representes one of the the system's main funcions - export DICOMs to a more appealing and portable format. The ReportFlashGenerator is called by Generate of the static class GenerateOutput, which itself is called by the task GenerateReportOutput in OutputReportTask. The method Generate checks the path to 2 swf files, this is accessed by proprities of the report model, more preciselly, 2 proprities inside the VisualPackage(object FlashComponets named template and its fields templateswf and pageswf) that is part of a Report/Template. After those 2 swf, more swf files can be adeed on the end of the report, this a propritie name OtherKeys of VisualPackage(field _others on FlashComponets), but there is a constaint associated with these last swf files only the one with the key “utils.swf” will be added, the other will just be burned, this is hardcoded. After all these checks and the flash generation this static class adds alll the files to a static setup(SetupBurn) in order for them to access by the burn process. The flash generation is done by the main class of ReportFlashGenerator, the class Generator, so after the construction of the object, the method Generate is called. When this is done it's also specified if it will be used a last page defined by the "utils.swf".

The object Generator is created with 2 paths to the 2 swf files and the associated report/template – ReportController. It also creates a Turbine7 object When the method Generate is called, it will use the Assembler realization, ReportAssembler, passing important object like the turbine object and the report controller. If utils.swf is used then the ExtraSlide propritie in ReportAssembler is set to true.

It's importante to understand what the Turbine library is:

� The Turbine 7 SDK enables software application to generate Flash Rich Media and PDF Documents;

� Turbine is based on a sophisticated media-independent architecture that allows output to media formats like Flash and PDF;

� Use Flash or XML files as templates for data integration;

� Includes the easy to use Turbine Media Markup Language(MML – it's a simple XML language) that can express all the rich media capabilities: text, images, shapes, movie clips, buttons, scripting, video and audio;

Turbine needs a swf, to be used as template and a MML specification.

Illustration 15: Access Classes to burn and produce the final report



What ReportAssembler does is reseting turbine and loding the template swf(field templateswf in FlashComponents) into it. Then it creates the mml specification with the help of PageFrame class and the Tag class. As their name indicates, the first represents a page frame and the second a mml tag. Therefore to an empty PageFrame object is added 3 Tags - "script" tags, one with an array of titles, the other with report information, like patient name, study date, physycian name and the final script is the number os slides. These script basically set global varaibles inside the mml.

As soons as they are added, a mml specification is generated by PageFrame and turbine uses this mml to create a flash, named report.swf. In simple words the final report introduction.

After the introduction part of the report is generated, the system creates a swf for every page on the report, plus the final “utils.swf”. The method, GeneratePages in Generator, uses the Assembler realization PageAssembler to create each swf file for each page. The first difference between PageAssembler and ReportAssembler is the swf template used, since PageAssembler uses the pageswf from flashComponents.

As for the actual work, GeneratePages cycles through the report's pages(ReportController) and for each executes the method Assemble from PageAssembler, with a diference output name, hence one swf file for one page. To this Assemble it is given the page itself(PageController) and the output file. Inside the Assemble the behavior is much like the behavior from ReportAssembler, but now the PageFrame is initialized with the PageController and then to the turbine engine is given the mml specification - inside the PageFrame, if the page has objects then they will be converted to mml by the ObjectContainerTagger, with different parsers for TextObject(uses the converter class TextConverter in ConvertToMML.cs), TitleObject, MultipleMediaObject, CineObject, ImageObject.

Illustration 16: Used classes to create the report in a flash format



The other layers can also be seen on the data view, but this one does not appear directly on the data model because the main purpose is to produce, not to store.

The following section details the data view and all this can be seen.

8.5Report Client Activity and Sequences

The following diagrams are based on the client's activities, and were created to give some insight into the sequence of states and functions performed when we create a report, from the before login, to study selected and finally generate flash or burn.

8.5.1Before login

These steps form the login process, first the possible impersonation, then some if there is arguments it will try to authenticate, ping an assert broker state, and configure database access, otherwise it will retrieve system users and try one of those logins. If broker is not reachable login can be done off line, by loading the local users. After that programs continues with an execute arguments or a new report.

8.5.2From login to Create document

Illustration 17: Until Login Activities



This process basically defines the report/template variables, as simple as this:

� has template? which one?

� has visual package? Which one?

� Uses all the images? Or just a few?

Note that the use all images or just a few is not the mapping process, its just the distinction between ad-hoc report and normal report.

8.5.3From Create Document to Report Built

Illustration 18: From login to create document



The main division on this diagram is the variable template, if its ad-hoc reports template does not exists and report is already built because its empty(just has the study retrieved medias), the other possibility for an empty template is the new template function, with this we get the possibility to add mapping rules. Finally the normal process, it has template therefore it will build the report by running the maps, but first, the template attachments are added to report, then if dynamics is on it will fetch the pdf report. After that there is only the need to cycle through every template page and through every page object run all the maps, or copy the object it is not a template page object(has mapping rules). The maps are divided in 2, text maps, used for dynamics and media maps (the media from the study – dicoms), the last is done by creating an sql query, equivalent to the map, then this sql is passed to the broker and a list of dicoms(not actual dicoms, but the encoded ones) is returned. With this list many pages can be created.

Illustration 19: Building the report/template



As soon as the maps are executed, another map is created the one that will get all the non mapped images. Then the report is built. And the options are burning the report or preview.

8.5.4Burn report, flash generation

Burnnig splis in 3, deploy media, retrieve dicoms and generate the flash report. This last one is also used to preview the flash report.

Illustration 20: Burnning and flash generation



The first division is the media deployment, which copies a resource file named projector.exe, that basically is a flash exe that loads “report.swf”. Then all the attachments are copied to an output path, creating at the same time a bat file that runs the attachment if it is executed. Following a dicom viewer and a autorun.inf (autorun to projector.exe) are deployed. Another division is the dicom retrieval, broker writes the original dicoms and then they are moved to the output path.

As for the flash generation the first thing to be done is deployment of all the visual package attachments, doing that, the search for the extra swf (utils.swf) is also made. The the base swf template is used to create an intro flash – the report swf. To do that, there is the need to create a flash mml specification, for the report.swf mml has all the report page titles, report info(patient name, date) and finally the number of slides, that is particular importante because report.swf will load more swf files that follow a pattern(s1.swf, s2.swf, s3.swf, etc..) until “number of slides” is reached.

The for each page, a swf is created, this file follows the pattern described above and needs a page template swf and an mml specification, for this mml, each page object from the page is transformed into mml. And if there exists dicoms or attachments a xml is created and deployed, the same goes for the utils.swf, that even if what deployed on a previous step (deploy visual package attachments) will be again deployed but with a different name, the standard name, so it can be loaded like the page swfs, by the report.swf. Note that to this last swf, there is no mml, this is because all the information needed by this swf is loaded at runtime from the xml – dicom.xml.

After all this, it is verified the space needed and the existence of a burner and a cd or dvd is finally burned.

9.Data View (optional) [A description of the persistent data storage perspective of the system. This section is optional if there is little or no persistent data, or the translation between the Design Model and the Data Model is trivial.]

The Reporting Database is indeed a very important component, both the server and the client have direct access to this database and are heavily dependent on that database. Even thou the database is the same, the client's approach is very different from the server's approach. For that reason the database is divided into 2.The main reason is the information needs and the client's use of Nhibernate. So there is a set of table used by the client and a very different set of tables used by the server, the only resemblance to these 2 set is the table T_StorableMedia, that was created by Nhibernate, but is also used by the server. One can divide the database by the table's name: the BK_* are the server's tables(plus T_StorableMedia) and all the others are mapped by Nhibernate, thus belonging to the client's scope. The Document “Siemens Reporting Broker” has a lot of information regarding the server's tables, so it is advised an overview of that document.



Because of the division into 2 and the size of database it will be presented several diagrams representing the database space.

9.1Server Data View

The server has 2 diagrams the first represents a set of tables and their connections, the second represents the server configuration tables.

Illustration 21: Database division



This is a complement to the database information present in “Siemens Reporting Broker”.

First, the server information needs will be described:

� DICOM header information;

A physician(BK_Physician) performs a study(BK_Study) on a patient(BK_Patient); the study has one or more series(BK_Series) and has several images(BK_Image) that came from a server, an image has all its attributes stored in BK_Attributes and as long the image file exists in the server file system it is also an T_StorableMedia – file details.

� Image Servers and their connection details;

An Image Server(BK_Server) has one or more DICOM filters(BK_SERVERDICOMS) to accept only the needed DICOM images, the Reporting server can access image servers using different connection details(BK_Connection) and to whom the connection is made is established on BK_Server_Connection;

� Allowed clients;

Illustration 22: Main server tables

Illustration 23: Server config tables



Client workstation access details are stored in BK_Reporting_Workstations, only these have the credential to work with the Reporting Server;

� DICOM Modalities' specifications;

BK_Modalitiy_Catalog specifics who the DICOM are processed;

� Internal configurations.

BK_ConfigTable, has all the internal configuration needed by the server, like the local used folders, encoding specification, size of cache and how long this cache is stored.

� Misc requirements

BK_Commands_Temp stored commands in order to delete old images from the Reporting Server.

This part of the database can be almost explained by the table's name and there isn't the need to explain all the columns, since they have direct correlation with the domain problem and the most important fields are detailed in “Siemens Reporting Broker”.

9.2Client Data View

The client information needs are, as explained before, mapped on the database using NHibernate, this creates a lot of tables, but this is done using 3 models, Report Model, Clinical and Mapping Engine, the most important model is Report Model, as one can see how many tables were created for this model (T_* Tables). The models correlate as this:

This oversimplified model gives some insight into to the complex models that follows, basically the T_* tables have MPG_* tables as well some CLN_* tables, but some CLN_* are the owners of T_* tables. With the help of the following models, it is possible to grasp all the connection nodes that these 3 models have.

The Client database part will not be dived by these 3 logical models, mainly because of the relative small size of the Mapping Engine and the Clinical compared to the Report Model. So the 3 Diagrams do not follow any division rule. Some Table are on more than one diagram, this is done in order to give a full view of the database connections. As explained before the database is a direct map of the models defined inside the application, therefore understanding these models and understanding how they are mapped into the database is almost the same.

Illustration 24: Packages used by the client



9.2.1Digram 1 – The main table - Report/Template The first diagram represents the main class of Report Model, they are the Report, the Template, the Page and the VisualPackage. All the information related with the client database is based on these diagrams and the XML files needed for NHibernate.

The most important thing present on this diagrams are:

The T_Report/T_Template connection: even though T_Template is define as a subclass(extinction) of T_Report, the 2 tables are connected as one-to-one and they represent the main component of the Report Model, which has one patient associated (CLN_Patient), of course one patient has one or more reports, so this is one patient to many reports connection.

The T_Template, stores the templates as well the reports, this meas that there are T_Templates which have none correspondence in T_Report and by dependencies, aren't associated with any patient, for this reason a T_Template is a set of saved reports and a set of templates for the future reports, meaning that inside the T_Reports are all the saved reports. Besides that, T_Reports has the user(CLN_User) that created the report/template and sometimes the clinical service(CLN_ClinicalService) that was used(it can be null and it is for all the tested cases).

Other elements worthy of mentioning are one or many constraint(s) associated(T_TemplateAllowedStudies) with T_Template, as well some file attachments to the template itself – done with T_Template_Attachments and other tables connected with this one this defines which template is used when report is invoke with an “open study” command. Finally the template and the report have one or more pages. The last table - SD_ReportTitles represents the ReportTitle class, under the OM project, this is a list of regular expressions representing Syngo Dynamics Report titles .

Illustration 25: Main tables - report/template



9.2.2Diagram 2 – The Page table and StorableMedia In this diagram the most important tables are the T_Page, T_StorableMedia and the T_PageObject; the previous diagram refers the T_Page, the T_VisualPackage and the T_Teamplate_Attachments, so they will be described next:

The Templates and the reports may have several attachments(T_Attachment - many to many), so the T_Template_Attachments serve as an association table of a many to many connection; also they have one T_Visual_Package which defines the layout of the template/report.

This T_VisualPackage Consists primarily as 2 swf files(template_storedmediaid and page_storedmediaid - introductory swf and the swf present in every page), a background image – T_VisualStyle as well as other swf files for utilities(many to many) accomplished by T_VisualPackage_OtherStorableMedia. All these files are a T_StorableMedia(describes a file under the file system), the same happens to the attachments(T_Attachment).

A T_Page, consists of several T_PageObjects - page components that possesses a location, a size and a optional background image – T_VisualStyle. Ultimately a T_ DicomDerivedObeject is just an extension of a T_PageObjects, but for instance a Text field only exists in T_PageObjects, which means the T_ DicomDerivedObeject, as the name implies is a T_PageObject for Dicoms and for that reason they are a T_StorableMedia(for instance a jpeg or flv file). This T_ DicomDerivedObeject can be a series of images(video - flv) or an image alone(jpeg) therefore T_ DicomDerivedObeject is extended by either T_CineObject for videos and T_ImageObject for images.

The T_ MultipleMediaObject represents a class of the Report Model which can have multiple columns and rows where it's possible to place DICOM images, the T_MultipleMediaObject_Media hosts the many to many relationship between the T_ MultipleMediaObject and the encoded DICOM images inside it(T_DicomDerivedObeject). This class is used to place several dicom images making a sequence of images.

Illustration 26: Page table and StorableMedia



9.2.3Diagram 3 – The PageObject and the Mapping tab les As said above a T_PageObject can be an DICOM derived object, but that is not all, since T_TextObject and T_TitleObject extend T_PageObject, therefore a T_PageObjects can be a text field, a title, an DICOM image or a series of DICOM images. The Title has a formated text(alignment, font, colors) in T_TextFormatting, besides that if the title comes from the template it has an associated T_TitleObjectTemplate, trough the table T_BindableTitleObject , this T_TitleObjectTemplate is an extension of T_PageObjectTemplate which is an extention to T_PageObjects for objects created in templates, since they are created inside the templates and can map DICOMs, there is the possibility to bind only certain DICOMs, this is done with a MPG_Mapping.

The MPG_ Mapping has one rule(MPG_RULE) or a ordered list of rules (MPG_RuleGroup), the list inside of MPG_RuleGroup has as logical association(ie. And/Or, etc) between rules or even between groups-this means that a MPG_RuleGroup can have several MPG_RuleGroup using the connection with parent group(ParentRuleGroup) and the table MPG_RuleGroup_Groups, besides that the list of rules is tracked by MPG_RuleGroup_Rules. Finally inside a template one can have Text(T_TextObjectTemplate), media objects (T_MediaObjectTemplate) or multiple media objects-basically a table(rows/columns) with several medias spread across a T_MultipleMediaObjectTemplate.

10.Size and Performance [A description of the major dimensioning characteristics of the software that impact the architecture, as well as the target performance constraints.]

11.Quality [A description of how the software architecture contributes to all capabilities (other than functionality) of the system: extensibility, reliability, portability, and so on. If these characteristics have special significance, such as safety, security or privacy implications, they must be clearly delineated.]

Illustration 27: Page table and Mapping Engine tables

Anexo B

Reporting Installation Manual

SIEMENSMedical Solutions Reporting

Siemens Medical Solutions Portugal

Reporting Install

Document ID:

File Name: Reporting Install.odt

Document Version: 1.0

Status: Draft

Owner: Rui Pinto

Effective Date:

Note: This document is maintained in electronic form. Printed copies are not updated.

Siemens MED HS Reporting

Revision History

Revision Date Author Reason for change Minor or Major Change

0 29/02/2008 Rui Pinto Created 1.0

2


1 Índice 1 Índice ............................................................................................................................ 3 2 Introdução .................................................................................................................... 4 3 Referências .................................................................................................................. 4 4 Pré-requisitos ............................................................................................................... 4 5 SQL Server 2000 (2005) .............................................................................................. 4 6 Instalação do Servidor - Reporting Broker .................................................................... 4 7 Instalação do Cliente – Reporting Editor ...................................................................... 5 8 Configuração do Servidor – Reporting Broker .............................................................. 5

8.1 Base de dados ....................................................................................................... 5 8.1.1 Configuração do Broker ................................................................................... 5 8.1.2 Modalidades DICOM ....................................................................................... 5 8.1.3 Servidores ...................................................................................................... 6 8.1.4 Clientes permitidos .......................................................................................... 7

8.2 Ficheiros .Config .................................................................................................... 7 8.2.1 BrokerInterface.dll.config ................................................................................. 7 8.2.2 ConsoleInterface.dll.config ............................................................................. 8 8.2.3 DBManager.dll.config ...................................................................................... 9 8.2.4 Logger.dll.config .............................................................................................. 9

9 Configuração do Cliente – Reporting Editor ............................................................... 10 9.1 BrokerInterface.dll.config ..................................................................................... 10 9.2 reporting.exe.config ............................................................................................. 10

10 Requisitos Adicionais ............................................................................................... 11

3


2 IntroduçãoEste documento tem como objecto definir os passos necessários para se instalar o Reporting Broker bem como o Reporting Editor, listando o software essencial ao bom funcionamento do sistema e onde e como se pode configurar o sistema.

3 ReferênciasNo presente documento refere-se alguma informação que está presente e mais detalhada nos seguintes documentos

• “Siemens Reporting Broker”, Versão 2, 31/01/2008, André Ferreira;

4 Pré-requisitos● .Net Framework 2.0.● Windows Installer 3.1● SQL Server 2000 (2005)

5 SQL Server 2000 (2005)

● Nas configurações do SQL Server deve-se ter a autenticação como mixed mode (Windows Authentication e SQL Server Authentication).

● Caso se faça backup de uma base de dados existente, basta clicar em restore database, adicionado o caminho do ficheiro de backup, selecionado a opção from device/select device.

● Depois deve-se verficar se existem logins com acesso à base de dados, tanto nos logins dentro da secury, como nos users dentro da própria base de dados

6 Instalação do Servidor - Reporting Broker

● O Reporting Broker é instalado a partir do setup, instalando-o para todos os utilizadores;

● No mesmo setup é também instalado automaticamente o AviSynth, sendo apenas necessário as opções padrão.

● Para a conversão de vídeo é necessário um codec de video, sendo assim depois de se instalar o Reporting Broker, dentro do directório de instalação do mesmo, existe a pasta External, contendo algumas ferramentas usadas pelo Reporting Broker. Aí deve-se aceder à pasta DivX e executar manualmente a instalação do DivX 3.1alpha release. Ou usar o configurado do broker e selectionar a opção DivX. Nste processo, apenas é essencial instalar um codec de video, ou seja, é possivel usar outros codecs.

● Para a comunicação com os servidores DICOM, o ficheiro .ocx do Dicom Objects é registado automaticamente durante a instalação, caso se detecte algum problema este ficheiro deve ser registado manualmente através dos comandos

4


da shell do Windows (regsvr32 "<BrokerInstallFolder>\External\DicomObjects\DicomObjects.ocx"). Estando a linceça em <BrokerInstallFolder>\External\DicomObjects.

7 Instalação do Cliente – Reporting Editor● Executar o setup do Reporting Editor, senguindo os passo do wizard e

selecionando a opção instalar para todos os utilizadores.

8 Configuração do Servidor – Reporting BrokerPara se configurar o servidor deve-se ter em atenção que existem dois “locais” de configuração: na base de dados e nos ficheiros .config dentro do directorio de instalação do Reporting Broker.

8.1 Base de dadosDirectamente ou usando o BrokerConfig que está dentro do directorio de instalação do Reporting Broker pode-se configurar dados relativos a:

8.1.1 Configuração do Broker

8.1.2 Modalidades DICOMConfigurações das modalidades DICOM, caso não exista configurações para uma determinada modalidade, são usados valores default.

5

Figure 1: Configuração do Broker a partir do BrokerConfig


8.1.3 Servidores Configuração do Servidores DICOM (tab Servers), dos servidores onde estão a correr os serviços Converter, Receiver e Console (Connections), bem como das ligações entre os servidores Converter, Receiver e Console aos servidores DICOM (tab Server Connections).

6

Figure 3: Configuração dos Servidores Dicom e dos Serviços Converter, Receiver e Console

Figure 2: Configuração das Modalidades DICOM


8.1.4 Clientes permitidos

Todas estas configurações estão também disponiveis em tabelas da base de dados, sendo mapeamentos ditectos. Todos estes campos de configuração são bastante auto-descritos pelo próprio nome, no entanto no documento Siemens Reporting Broker pode-se encontrar uma descrição mais detalhada.

8.2 Ficheiros .Config

8.2.1 BrokerInterface.dll.configContendo as configurações relacionadas com a coneccão entre o broker e o editor, definindo o tipo de ligação TCP, no campo SecureChannel, o servidor onde corre o broker, bem como o nome e a porta do serviço windows. O domínio, user, pass são apenas necessários quando se usa conecções seguras, definindo assim as credênciais do canal.

7

Figure 4: Clientes Permitidos


8.2.2 ConsoleInterface.dll.configFicheiro XML contendo variaveis para o acesso à consola:

<?xml version="1.0" encoding="utf-8" ?><configuration> <appSettings> <add key="Server" value="localhost" /> <add key="Port" value="9002" /> <add key="Service" value="RemoteConsole" /> <add key="UserName" value="Reporting" /> <add key="Password" value="demo" /> <add key="Domain" value="vm-f1cf3ddfff9f" /> <add key="Secure" value="true"/> </appSettings></configuration>

Estes campos de configuração são em todo iguais aos do ficheiro BrokerInterface.dll.config.

8

Figure 5: Interface do Broker com o Editor


8.2.3 DBManager.dll.config

8.2.4 Logger.dll.config

9

Figure 6: Acesso à base de dados

Figure 7: Configuração para o envio de emails de erros


9 Configuração do Cliente – Reporting EditorAs configurações do cliente, encontram-se nos ficheiros .config dentro do directorio de instalação.

9.1 BrokerInterface.dll.configFicheiro XML responsavel pela ligação entre o reporting editor e o reporting broker:

<?xml version="1.0" encoding="utf-8" ?><configuration> <appSettings> <add key="Server" value="localhost" /> <add key="Port" value="9001" /> <add key="Service" value="BrokerRemoting" /> <add key="UserName" value="Reporting" /> <add key="Password" value="demo" /> <add key="Domain" value="vm-f1cf3ddfff9f" /> <add key="Secure" value="true"/> </appSettings></configuration>

Aqui define-se o servidor do broker, pelo host, nome do serviço e porta. É possível usar canais TCP seguros ou não seguros, usando para tal o campo Secure. O resto das configurações (user, pass, domain) serve para identificar a máquina e para que esta possa ser aceite pelo broker, devendo existir dados correspontes do lado do broker nos clientes permitidos. No caso de ser um canal seguro TCP o o Domain deve ser o nome da máquina, nos casos em que esta está fora de uma rede windows; se a máquina pertencer a um dominio, tanto se pode usar o domínio ou o nome da máquina, depende se o user especificado é um user local ou um user do dominio.

Domain deve ser o domain da máquina, no entanto, quando se usa canais não seguros, basta que exista correspondecia nos clientes permitidos do lado do broker.

9.2 reporting.exe.configFicheiro XML contendo praticamente todas as definições relacionadas com editor, especificando, por exemplo qual o visualizador DICOM, algumas definições para gravar CD/DVD, possibilidade de usar 2 ecrãs e de trabalhar offline. As mais importates, e aquelas que são essencias à instalação são as que se apresentam de seguida: <?xml version="1.0" encoding="utf-8" ?><configuration> <applicationSettings> <Siemens.Medical.PT.Reporting.Properties.Settings> <setting name="DataSourceAddress" serializeAs="String">

10


<value>localhost</value> </setting> <setting name="DataSourceName" serializeAs="String"> <value>Reporting</value> </setting> <setting name="DataSourceLogin" serializeAs="String"> <value>sa</value> </setting> <setting name="TempPath" serializeAs="String"> <value>d:\rpttmp</value> </setting> <setting name="DynamicsConnectionString" serializeAs="String"> <value>Data Source=155.155.69.1068.69.111;Initial Catalog=acusondb;User Id=API_asdasd;Password=$asdasd</value> </setting> <setting name="DynamicsDepartment" serializeAs="String"> <value>hemodinamica</value> </setting> <setting name="DynamicsUser" serializeAs="String"> <value>consulta</value> </setting> <setting name="DynamicsPasswd" serializeAs="String"> <value>consulta</value> </setting> </Siemens.Medical.PT.Reporting.Properties.Settings> </applicationSettings> <userSettings> <Siemens.Medical.PT.Reporting.Properties.Settings> <setting name="DataSourcePassword" serializeAs="String"> <value>demo</value> </setting> </Siemens.Medical.PT.Reporting.Properties.Settings> </userSettings></configuration>

Com estas configurações definimos o acesso à base de dados, com os campos DataSourceAddress, DataSourceName, DataSourceLogin e DataSourcePassword. Com os campos DynamicsConnectionString, DynamicsDepartment, DynamicsUser, DynamicsPasswd define-se o acesso ao syngo® Dynamics, sendo apenas necessário nos casos onde este se aplique. Por fim existe o campo TempPath, definido uma pasta para dados temporários necessários à geração dos reports.

10 Requisitos Adicionais● Flash Player 9, contendo o Flash Player Active X;● Partilha de ficheiros avançada quando se usa canais seguros TCP;● Formato da data do windows em portugues (Regional and Language Options,

dentro do painel de controlo);

11


● Pastas configuradas para o broker, definidas em 8.1.1, devem ter permissão de leitura e escrita para o user Network Service. No caso de se usar canais seguros TCP, o user que é dado para as credenciais deve também ter permissões de leitura e escrita para as mesmas pastas.

● Os canais TCP têm de ser configurados da mesma forma no cliente e no servidor. Não pode haver um cliente com canais seguros tcp, enquanto o servidor está com canais não seguros ou vice versa.

12

Anexo C

Configurator User Manual

SWF Editor User Manual

Reporting - Configurator

Document ID: configurator_user_manual

File Location:

Document Version: 1.0

Status: Final

Language: English

Effective Date: 21-May-2008

Note: This document is maintained in electronic form. Printed copies are not updated.

Approval:

Version Name Function Date

<version> <name> Project Manager <dd-Mmm-yyyy>

<version> <name> SQA – if exists <dd-Mmm-yyyy>

Authors and Contributors:

Name Contact Description Date

<name> <mail> <Author/ Contributor> <dd-Mmm-yyyy>

Access List:

Internal Access

External Access

Revision History:

Version Date Author Reason for change, and identify all documents effected by change

Minor or Major Change

0.1 06-March-2008 Rui Pinto Created and released swf editor manual

1 21-March-2008 Rui Pinto Update to full user manual

Table of Contents

Table of Contents

1. Introduction 4

2. Menu 4

3. Users Editor 6

4. XML Editor 6 4.1 Remoting Config 6 4.2 Reporting Client 7

5. Reports 7

6. Visual Package 8

7. SWF Editor 8 7.1 Base SWF – Report SWF Config 9

7.1.1 Swf Base Template 10 7.1.2 Top Logo 10 7.1.3 Bottom Logo 10 7.1.4 Bottom Text 11 7.1.5 Background Color 11 7.1.6 Left Center 12 7.1.7 Top Left 12 7.1.8 Separator 12

7.2 Utils SWF – Extra SWF Config 13 7.2.1 Extra SWF Template 14 7.2.2 Extra Title Text 14 7.2.3 Extra Separator 15 7.2.4 Extra Center Text 15 7.2.5 Extra Center Title 16

8. Visual Package Editor 16

9. Conclusion 17

Configurator User Manual

1.Introduction

This document provides a guide for the use of Configurator and what is the propose on the Reporting scope.

The configurator provides a Reporting configuration interface, where all the client settings can be changed:

� First there is a CRUD(create, read, update, delete) for the system users.

� An editor for the .config files, which are xml files with specific rules and tags.

� A visual packages insert tool.

� A swf editor.

Another important tool is swf editor, because Reporting throughout the whole application uses a design package composed of 3 swf file and an image, these files define the background of the output. So there is a strong need to add flexibility to this process, prior to this application th flexibility existed only as a basic “design package insert tool”, and editions to the swf were made on their sources, but editing the specified swfs is not as simple as one might thing therefore, to make Reporting more of a product, this process was analyzed and swf editor was born.

SWF Editor can edit the swf files so the output changes, its just as simple as this.

There is no need for 1 of the 3 swfs to change - the slide base, since this one has no underlining layout.

Ther other 2 swf are editing using this tool and after all the editions, using the export function a new one is created. These new swf files need to be inserted as a design package into Reporting using the normal tools for that process, because this standalone application for the moment does not interact directly with Reporting, which means that inserting these swf files into reporting is not a swf editor responsibility, but visual packages insert tool.

SWF Editor was created based on the simple fact that editing images is much more easy than editing swf, so the editing process is more or less just selecting images, text and colors that will be used inside the swf files. Since the original swf are not actionscript3 this process is more tricky and complicated and for that reason SWF Editor is the simplest and fastest way to change the design of the output. Nevertheless the flexibility is not total, this can only be accomplished by editing the swf files through their sources - fla, but has enough flexibility to cover the basic needs of any deployment change.

Besides that, this tool provides an easy load/delete report/templates function. The same goes for visual packages, but these can also be edited and by editing means inserting new ones, the true editing is done by SWF Editor.

2.Menu Lets introduce the main menu:

With it, we can connect to a database/broker using the Connect button or under File/Connect. Note that some of the configurations need connections settings.

Illustration 1: Main Menu

This connect only specifies the database settings, if we need to change the broker settings, we can use the broker interface configuration tool, the same happens for the reporting broker interface. But first XML editor must be presented. Which has a proper section.

Under Configuration we have:

Users Editor and Visual Package use the database and the broker so they require valid db and broker settings. As for XML Editor and SWF Editor, they only access local files.

Reports and Visual Packages can be loaded and deleted,

Illustration 2: Menu Connect

Illustration 3: Configuration menu

Illustration 4: Reports menu Illustration 5: Visual Packages menu

3.Users Editor

The users editor can CRUD users, the options are self explained, note that the password if it is the same as the login, Reporting will not ask for it, another detail is the ExternalID, which is used in external applications such as Syngo Dynamics. For the sake of unique users , login and name must only exist in one user. The normal approach defines only the login as unique, but since Reporting presents the Name to the user, this field is also unique.

4.XML Editor

The XML editor basically edits 2 .config files that Reporting uses. The First can also be used for Configurator's broker interface. The files are XML and have specific tags, therefore this tool edits those tags. First we select which type of file will be used, either the remoting (broker) interface config file or the reporting settings file.

4.1Remoting Config

Illustration 6: User Editor

Illustration 7: XML Editor menu

Here we set, the server, service name and port, the username password and domain user to connect to Reporting Broker, as wich type of TCP channel is user – secure or note.

4.2Reporting Client

These options configure the reporting client, so we have database settings, Syngo Dynamics options, Impersonation user settings, DICOM viewer path and some other miscellaneous options, the most important of these is the TempPath.

5.Reports

Illustration 8: Remoting Config

Illustration 9: Reporting Client

With this option we can see the Reports/Template saved on the system. After that, if one is select and “Report/Delete” command is issued then the Report/Template will be erased from the system.

6.Visual Package

This is the list of Visual Packages, they can be edited if we double click them. This edition process open the Visual Package Editor, explained on the proper topic.

7.SWF Editor SWF Editor is divided into 2, this can be seen by the menu options:

Illustration 10: Reports Loaded

Illustration 11: Visual Packages Loaded

The Report SWF Config, edits the main swf for the output. This one defines, for instance, all the logos. The Extra SWF Config defines the extra slide - utils, where all the attachments are insert, and the open command to the DICOM viewer. After a new command, if export is clicked a save explorer will be opened and after that the new swf will be saved.

7.1Base SWF – Report SWF Config

The following examples were made as a pre-configuration with Siemens layout.

Now it will be explained how to set this output.

� First the options are: � Swf Base Template; � Top Logo; � Bottom Logo; � Bottom Text; � Background Color; � Left Center; � Top Left;

Illustration 12: SWF Editor Menu

Illustration 13: Output with Siemens Layout

� Separator.

7.1.1Swf Base Template

Here the base swf file can be set, as always swf editor has default values, the same goes for the swf file itself. Usually this swf does not need any change because, swf editor exists for that porpose.

7.1.2Top Logo

Provides the image for the top logo.

7.1.3Bottom Logo

Illustration 14: Menu from new base swf

Illustration 15: Swf Base Template options

Illustration 16: Top Logo options

Same as top logo, but this one defines the bottom image.

7.1.4Bottom Text

Defines the bottom text and the used color.

7.1.5Background Color

Defines the background color, if the swf file is not viewed in fullscreen the fla document color may be seen if one expands the window more than 1024x764. This fla document color can be seen if the

Illustration 17: Bottom logo options

Illustration 18: Bottom Text options

transparency alpha is not 255. Note the fla document color, can only be set on the fla and it is white on the default base swf file.

7.1.6Left Center

This is another logo, place on the left side of the output at the middle of the report, note the png format and the use of emptiness on the image.

7.1.7Top Left

The final logo for the first part of the output, the top left logo.

7.1.8Separator

The separator appears when the is a click to continue the report, this is just the background used to show all the slides on the report. The following illustration is the output report when it's on that state:

Illustration 19: Left Center Logo options

Illustration 20: Top Left Logo options

For this part the following options are presented:

The options are, the image place inside the separator and its transparency alpha; and the separator background color.

7.2Utils SWF – Extra SWF Config

The utils swf presented is based on the previous utils swf files, the normal look is the following:

Illustration 21: Output when slides are showed

The extra swf has the following sub-menus:

7.2.1Extra SWF Template

Defines the swf file used has template for the utils swf.

7.2.2Extra Title Text

Illustration 22: Extra SWF output

Illustration 23: Extra SWF Config menu

Illustration 24: Extra SWF Template options

Text and color of the title of the utils swf.

7.2.3Extra Separator

The utils' separator has only a background color to be defined.

7.2.4Extra Center Text

This text is the text used for the click event that opens the DICOM viewer.

Illustration 25: Extra Title Text options

Illustration 26: Extra Separator options

Illustration 27: Extra Center Text options

7.2.5Extra Center Title

Finally the text used to list all the attachments, for that reason can be considered a sub title.

These options define the text and the background color for that sub title.

8.Visual Package Editor

These are the options for the Visual Package. A Visual Package consists basically of a name, 3 swf files, one Visual style (an image).

Here we can insert or edit(note the id field, if its 0, then its a new Visual Package, otherwise it's an edition) a Visual Package.

Illustration 28: Extra Center Title Text

Illustration 29: Visual Package Editor

Also the 2 types of files produced by SWF Editor must be insert through here – report swf and extra swf. Note the Visual Package Attachments, these are files which are included on the Visual Package and ultimately will be copied to the Reporting flash output, but never access directly because they are optional. The extra swf(the used “utils.swf”) is a special case of a Visual Package Attachment, therefore it has a special field for it and does not need to be inserted as an Attachment.

9.Conclusion

This tool simplifies the configuration process and it was made so it has default values, specially for the swf files which means if we just do the “next, next, next” method we will have always a default value. The same goes for file filters namely the ones used on XML editor, which filter only the standard names of the .config files.

Servidor de imagem cl nica com motor de pesquisa baseado ... · condic~oes para conquistar uma...

Documents

Transcript of Servidor de imagem cl nica com motor de pesquisa baseado ... · condic~oes para conquistar uma...