Tesi PACS

UNIVERSIT DEGLI STUDI DI PADOVA
Facolt di Scienze MM. FF. NN.

Corso di Laurea in Informatica
Implementazione di una versione demo di un PACS

Laureando Stefano Tonello Matricola 575381 Relatore Prof. Tullio Vardanega
Anno Accademico 2010/2011
A mia nonna Alessandrina e alla mia famiglia che mi hanno sempre sostenuto.
Sommario
Questa relazione si pone lobiettivo di descrivere lattivit di stage svolta dal laureando Stefano Tonello presso lazienda Aqrate S.r.l. Il progetto proposto dallazienda consiste nella realizzazione di un PACS (Picture archiving and communication system ) molto basilare. Il documento suddiviso in quattro parti principali: Dominio applicativo: contiene informazioni riguardanti lazienda ospitante ed in particolare il settore sul quale opera; Strategia aziendale: fornisce una prospettiva di problema, attese ed obiettivi dal punto di vista dellazienda intorno allo stage; Lo stage: espone il modo in cui stato svolto lo stage; Valutazione retrospettiva: racchiude le considerazioni nali.
Allinterno del documento sono state adottate le seguenti convenzioni tipograche: Riferimenti: i termini che fanno riferimento a pagine del documento sono seguiti dal link della sezione in azzurro (3.4.1); Termine del glossario: per indicare che un termine presente nel glossario viene utilizzata la seguente nomenclatura: parola[g] . Qualora lo stesso termine compaia pi volte allinterno della stessa sezione, viene evidenziata la sua presenza nel glossario solo la prima volta, facilitando cos la lettura del documento. La stessa cosa vale nel caso in cui la sua denizione sia chiara dal contesto. Termini in lingua straniera: viene utilizzato il carattere corsivo ;
iii
Indice
Sommario Indice Elenco delle gure Elenco delle tabelle 1 Dominio applicativo 1.1 1.2 1.3 Informazioni generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Il contesto aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tecnologie e strumenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3.1 1.3.2 1.3.3 1.3.4 1.3.5 1.3.6 1.3.7 1.3.8 1.4 Windows Azure Platform . . . . . . . . . . . . . . . . . . . . . . .NET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . LINQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WPF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SharePoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Visual Studio 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . SQL Server 2008 . . . . . . . . . . . . . . . . . . . . . . . . . . . iii iv vii ix 1 1 2 3 3 3 5 5 6 6 7 7 8 8 9 10 11
Il sistema di oerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.4.1 1.4.2 1.4.3 Prodotti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Servizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Soluzioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
Il processo di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
INDICE 2 Strategia aziendale 2.1 Introduzione ai PACS, Picture archiving and communication system . . 2.1.1 2.1.2 2.1.3 2.1.4 2.1.5 2.2 2.3 2.4 2.5 2.6 2.7 2.8 2.9 Immagini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Funzionalit dellarchivio . . . . . . . . . . . . . . . . . . . . . . Copia di riserva . . . . . . . . . . . . . . . . . . . . . . . . . . . . Integrazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
v 12 12 13 14 15 16 17 19 19 20 21 22 23 24 25 27 27 28 37 37 38 40 44 44 46 47 50 50 52 54
Il problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Approccio al problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lobiettivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I fattori di rischio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Veriche e revisioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Utilizzo e sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . Piano di lavoro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Lo stage 3.1 La formazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.2 Standard DICOM . . . . . . . . . . . . . . . . . . . . . . . . . .
Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 Requisiti Software . . . . . . . . . . . . . . . . . . . . . . . . . . Casi duso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 3.4
Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.4.1 3.4.2 3.4.3 Componente Client . . . . . . . . . . . . . . . . . . . . . . . . . . Componente server . . . . . . . . . . . . . . . . . . . . . . . . . . Interfaccia graca del server . . . . . . . . . . . . . . . . . . . . .
3.5
Verica e validazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5.1 3.5.2 Metodi di verica utilizzati . . . . . . . . . . . . . . . . . . . . . Descrizione dei test e delle misurazioni eettuati . . . . . . . . .
4 Valutazione retrospettiva
INDICE 4.1 4.2 4.3 4.4 Analisi personale dellattivit di stage . . . . . . . . . . . . . . . . . . . Conoscenze pregresse ed acquisite . . . . . . . . . . . . . . . . . . . . . . Consuntivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Lesperienza in Aqrate S.r.l. . . . . . . . . . . . . . . . . . . . . . . . .
vi 54 55 56 58 59 64
Glossario Bibliograa
Elenco delle gure

1.1 1.2 1.3 2.1 2.2 2.3 2.4 3.1 Logo dellazienda. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 4 9 13 15 24 25
Infrastruttura del framework .NET . . . . . . . . . . . . . . . . . . . . . . . Aqrate Vector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Immagine di una tomograa visualizzata in un sistema PACS. . . . . . . . . Architettura di un sistema PACS. . . . . . . . . . . . . . . . . . . . . . . . . Architettura di Aqrate Vector integrato con le funzionalit DICOM . . . . . Diagramma di Gantt relativo al piano di lavoro a preventivo. . . . . . . . . Schema semplicato delle relazioni tra le entit paziente, studio, serie ed immagine nello standard DICOM. . . . . . . . . . . . . . . . . . . . . . . .
29
3.2
Schema semplicato della distribuzione gerarchica dellinformazione tra le entit paziente, studio, serie ed immagine nello standard DICOM. . . . . . . 30
3.3
Schema semplicato delle sorgenti di informazione per le entit paziente, studio, serie ed immagine nello standard DICOM. . . . . . . . . . . . . . . . 32
3.4
Diagramma UC1: Use case generale delle funzionalit a disposizione dellApplication Entity chiamante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5
Diagramma UC2: Use case generale delle funzionalit a disposizione dellApplication Entity chiamato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6
Architettura della rete PACS: un PACS Server, e multipli PACS Clients (PACS Workstations / DICOM Viewers ) . . . . . . . . . . . . . . . . . . . 41 42 44 45
3.7 3.8 3.9
Richiesta di associazione DICOM . . . . . . . . . . . . . . . . . . . . . . . . DC1 : Diagramma delle classi della componente client . . . . . . . . . . . . File con i dati di congurazione. . . . . . . . . . . . . . . . . . . . . . . . . vii
Elenco delle gure 3.10 DC2 : Diagramma delle classi della componente server . . . . . . . . . . . . 3.11 Screenshot[g] della prima nestra . . . . . . . . . . . . . . . . . . . . . . . . 3.12 Screenshot della nestra nella quale si congurano i parametri generali . . . 3.13 Screenshot della nestra nella quale si congurano i parametri di Abstract Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.14 Screenshot della nestra nella quale si congurano i parametri di Transfer Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Diagramma di Gantt relativo al piano di lavoro a consuntivo. . . . . . . . .
viii 46 47 48
49
49 57
Elenco delle tabelle

2.1 3.1 3.2 3.3 3.4 Probabilit di rischio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requisiti di vincolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Requisiti di qualit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Risultati delle misurazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 37 37 37 53
ix
Capitolo 1
Dominio applicativo
1.1 Informazioni generali
Denominazione dellazienda: Aqrate S.r.l. Indirizzo: via Roma 37/1 Citt: Montebelluna Provincia: Treviso CAP: 31044 Telefono: 0423600005 Mail: Nicola.Cinel@Aqrate.it Sito: www.aqrate.net
Figura 1.1: Logo dellazienda. 1
CAPITOLO 1. DOMINIO APPLICATIVO
1.2
Il contesto aziendale
Aqrate S.r.l. nasce nel 2007 dallincontro di professionalit che si integrano a vicenda creando un team in grado di realizzare soluzioni software per le imprese. Lazienda basa le proprie soluzioni sui prodotti della tecnologia MicrosoftTM in modo da garantire minore tempo di sviluppo e maggiore stabilit della soluzione. Grande importanza viene data alla capacit del personale di gestire al meglio progetti e relazioni, sia nei confronti della clientela sia verso lazienda stessa. Rientra infatti nel modus operandi lattenzione ed il rispetto nei confronti del cliente e delle sue esigenze, in tal senso la posizione dellazienda non mai quella di semplice fornitore ma di business partner. Il livello di competenza oerto consente di poter curare un progetto dalla sua denizione alla sua implementazione, garantendo il raggiungimento del risultato richiesto. Lazienda fornisce la soluzione completa di documentazione e di codice sorgente; questultimo opportunamente commentato e consente al cliente di potersi svincolare in qualsiasi momento.
1.3
Tecnologie e strumenti
Nelle prossime sottosezioni si passeranno in rassegna le principali tecnologie e gli strumenti che si utilizzano in azienda.
1.3.1
Windows Azure Platform
La piattaforma Windows Azure rappresenta il layer PaaS (Platform as a Service) allinterno della strategia di Cloud Computing di Microsoft. Windows Azure Platform, essendo una Platform as a Service rappresenta lambiente ideale per sviluppare, eseguire e gestire le proprie applicazioni o servizi in the cloud indipendentemente dalla tecnologia e dai framework[g] di sviluppo. Su Windows Azure Platform infatti possibile sviluppare in .NET, JAVA, PHP, Ruby, e persino in C++. La piattaforma Windows Azure a sua volta composta da 3 elementi: 1. Windows Azure: il sistema operativo per il Cloud che permette alle applicazioni di girare e fornisce potenza computazionale, storage, hosting e funzioni di management. 2. Microsoft SQL Azure: il database relazionale per il Cloud. 3. Windows Azure AppFabric: linsieme di servizi di infrastruttura applicativa per lIdentity Management e la connettivit. Quindi, con Windows Azure Platform, possibile gestire cloud storage (relazionali e at) e sviluppare applicazioni nel cloud facilmente integrabili con altri servizi e/o applicazioni sia on-premises che in the cloud.
1.3.2
.NET Framework
Il framework .NET include una vasta gamma di librerie e supporta diversi linguaggi di programmazione, in modo da consentire linteroperabilit tra linguaggi diversi(ogni linguaggio pu usare codice scritto in un altro linguaggio). I programmi scritti per il framework .NET vengono eseguiti in un ambiente software conosciuto come Common Language Runtime(CLR), una macchina virtuale per le applicazioni che fornisce importanti servizi quali la sicurezza, la gestione della memoria e la gestione delle eccezioni.
Linsieme delle librerie e il CLR insieme costituiscono il framework .NET. La Base Class Library del framework .NET fornisce un set di funzionalit, per tutti i linguaggi, per laccesso ai dati, la connettivit ai database, la crittograa, lo sviluppo di applicazioni per il web, la comunicazione in rete. Questo permette agli sviluppatori di combinare il proprio codice sorgente con il framework, in modo da ridurre la complessit nello scrivere il codice e in modo da assicurarne una maggiore portabilit. La gura 1.3 illustra larchitettura del framework. In particolare si nota come il codice scritto in un qualsiasi dei linguaggi supportati venga compilato con il compilatore adatto e trasformato in un secondo tipo di codice, indipendente dalla piattaforma, detto Common Intermediate Language (CIL). A questo punto, il CLR trasforma il CIL nel linguaggio macchina che pu essere eseguito nella piattaforma in cui risiede.
Figura 1.2: Infrastruttura del framework .NET
1.3.3
LINQ
LINQ lacronimo per Language Integrated Query ed una tecnologia introdotta per permettere la ricerca allinterno di qualunque struttura dati direttamente sfruttando il linguaggio. Grazie a questa tecnologia, si possono scrivere query, in C# o VB, che possono essere eseguite per ricercare elementi in una collezione di oggetti, nodi in una struttura XML[g] , o (ben pi importante) in un database SQL. LINQ non altro che unestensione del linguaggio che permette di eseguire query verso una determinata risorsa. La risorsa pu essere un le XML, un database o una collection di classi e nonostante questo, la sintassi LINQ rimane la stessa.
1.3.4
WPF
WPF, Windows Presentation Foundation, una libreria di classi del Framework .NET proprietarie Microsoft per lo sviluppo dellinterfaccia graca delle applicazioni in ambienti Windows. Linnovazione principale di WPF la rimozione di ogni legame con il modello di sviluppo tradizionale di Windows, introdotto con la versione 1.0 del sistema operativo. Tutti i controlli sono stati riscritti e lo stesso meccanismo basato su scambio di messaggi, cuore del modello di programmazione di Windows, stato abbandonato. WPF basato su un sistema di graca vettoriale che si appoggia alle DirectX[g] per sfruttare laccelerazione hardware delle moderne schede grache. WPF pu essere impiegato per realizzare applicativi eseguibili anche allinterno del browser Microsoft Internet Explorer o di altri browser avanzati, purch sia presente il Framework. Il linguaggio usato per la creazione di una interfaccia utente in WPF lXAML (eXtensible Application Markup Language ), basato su XML. Larchitettura di Windows Presentation Foundation si basa sia su codice gestito che su codice nativo. Comunque, le API[g] pubbliche esposte sono disponibili soltanto come codice gestito. Mentre la maggior parte di WPF in codice gestito, il motore di composizione che renderizza le applicazioni WPF un componente nativo. Il suo nome Media Integration Layer (MIL) e risiede in milcore.dll. Esso si interfaccia direttamente con DirectX e provvede il supporto di base per le superci 2D e 3D, eettua la manipolazione controllata nel tempo dei contenuti di una supercie con una vista per esporre animazioni costruite ad alto livello, esegue la composizione degli elementi individuali
di una applicazione WPF nella scena nale 3D che rappresenta la UI dellapplicazione e quindi si incarica di renderizzarla sullo schermo. I media codec sono anche implementati come codice non gestito, e sono forniti da windowscodecs.dll. Nella parte di codice gestito abbiamo il Presentation Core (presentationcore.dll) che fornisce un wrapper per MIL e implementa il cuore dei servizi per WPF e il Presentation Framework (presentationframework.dll) che implementa le novit incluse layouts, time-dependent, story-board based animations e data binding.
1.3.5
JQuery
JQuery una libreria di funzioni per le pagine web, codicata in javascript, che si propone come obiettivo quello di astrarre ad un livello pi alto la programmazione lato client del comportamento di ogni singola pagina HTML. Tramite luso della libreria JQuery possibile, con poche righe di codice, eettuare svariate operazioni, come ad esempio ottenere laltezza di un elemento, o farlo scomparire con eetto dissolvenza. Anche la gestione degli eventi completamente standardizzata e gestita automaticamente, assieme alla loro propagazione; stessa cosa per quanto riguarda lutilizzo di AJAX[g] , in quanto sono presenti alcune funzioni molto utili e veloci che si occupano di istanziare i giusti oggetti ed eettuare la connessione e linvio dei dati.
1.3.6
SharePoint
SharePoint un programma lato server che permette la creazione di particolari siti web principalmente ad uso aziendale (Intranet[g] ) ma che possono anche essere messi in rete e quindi essere disponibili e utilizzati come normali siti web. Lautenticazione viene fatta inserendo un nome utente e password al momento del login. Questa procedura viene agevolata dal single sign on che nellambito delle tecnologie Microsoft viene spesso inserito al momento dellaccensione del proprio pc. Il sistema si preoccuper pertanto di autenticarvi automaticamente nei siti in cui si dispone delle credenziali di accesso. Limportante valore aggiunto sta nel condividere informazioni e/o documenti in diversi modi. possibile creare liste, repository documentali, calendari sincronizzati con outlook e molto altro ancora. SharePoint completamente integrato con il pacchetto Oce e ore molte soluzioni come il versionamento dei documenti che essendo salvati su
server godono del vantaggio della collaborazione. Due utenti infatti, possono collegarsi da due posti dierenti e visionare o lavorare sullo stesso documento. Va fatta una precisazione: un solo utente pu modicare un certo documento mentre pi persone possono visionarlo in contemporanea. Questa operazione viene denita check-out e check-in e serve ad impedire che si crei confusione su chi modica cosa.
1.3.7
Visual Studio 2010
Visual Studio un ambiente di sviluppo integrato (Integrated development environment o IDE) sviluppato da Microsoft, che supporta attualmente diversi tipi di linguaggio, quali C, C++, C#, F#, Visual Basic .Net e ASP .Net, e che permette la realizzazione di applicazioni, siti web, applicazioni web e servizi web. inoltre un RAD (Rapid Application Development ), ovvero una applicazione atta ad aumentare la produttivit aiutando il programmatore con mezzi come lIntelliSense o un designer visuale delle forms. Visual Studio inoltre multipiattaforma: con esso possibile realizzare programmi per server, workstation, pocket PC, smartphone e, naturalmente, per i browser.
1.3.8
SQL Server 2008
Microsoft SQL Server un DBMS[g] relazionale, meglio noto come Relational Database Management System (RDBMS), prodotto da Microsoft. Microsoft SQL Server 2008 ore una piattaforma dati adabile, produttiva ed eciente per eseguire le pi esigenti applicazioni mission-critical, abbattere tempi e costi di sviluppo e gestione delle applicazioni e fornire informazioni traducibili in azione a tutti i livelli dellorganizzazione.
1.4
Il sistema di oerta
Loerta di Aqrate alla clientela prevede: Prodotti; Servizi; Soluzioni. Nelle seguenti sottosezioni vengono analizzate le proposte che lazienda dedica al cliente.
1.4.1
Prodotti
Aqrate cerca di garantire software con le seguenti caratteristiche: Scalabilit, per permettere al crescere della richiesta di performance di essere controbilanciato da una maggiore disponibilit del sistema; Modularit, per fare in modo che il software sia pluggabile; Innovazione. 1.4.1.1 Aqrate Vector
Aqrate Vector un componente software che fa da ponte tra il protocollo medico HL7 e il sistema di Conservazione Digitale. Il software riceve i documenti dai sistemi medicali HL7 e li preparara per la Conservazione Digitale estraendone le(referti, radiograe) e metadati(nome paziente, struttura medica, codice identicativo, data refertazione). Esso un servizio Windows, modulare, multithread ad alto parallelismo.
Figura 1.3: Aqrate Vector
Aqrate Vector basato interamente su tecnologia Microsoft .NET Framework 4.0 ed stato sviluppato utilizzando Microsoft Visual Studio 2010. Esso pu essere installato su qualsiasi sistema operativo Microsoft ed portabile su tecnologia Java - Db Oracle.
1.4.2
Servizi
Lazienda aiuta ed aanca il cliente nelle diverse fasi del processo di trasformazione dellidea in un servizio o un prodotto. Unaccurata pianicazione riduce i tempi di sviluppo e i costi di gestione, comportando una maggiore soddisfazione. Aqrate ore i seguenti servizi al cliente: Project Management ; Analisi e progettazione; Supporto tecnologico; Sviluppo di software verticale; Problem solving.
10
1.4.3
Soluzioni
Lazienda propone le seguenti soluzioni software : Applicazioni aziendali: realizzazione di applicazioni che strutturano le informazioni in una soluzione centralizzata, veloce ed adabile. Esse sono in grado di interagire con gli altri strumenti aziendali per massimizzare la collaborazione e lecienza. Gestione della cooperazione aziendale: Aqrate ha esperienza nellelaborazione di soluzioni di Collaboration e WorkFlow. Gli strumenti di Collaboration consentono ai dipendenti di aziende con diverse unit ed uci, di condividere il proprio lavoro in modo sicuro ed organizzato. Le soluzioni di tipo WorkFlow invece sono orientate a quei processi aziendali che comportano una serie di passaggi e di interazioni tra i vari uci o reparti. Lazienda realizza per i propri clienti lo strumento per automatizzare e rendere sicure queste procedure. Gestione documentale avanzata: viene oerta una soluzione per strutturare larchiviazione dei documenti, rendendo sicuri gli accessi alle varie aree documentali e riducendo i tempi per la ricerca delle informazioni. System Integration: soluzione per realizzare lintegrazione dei sistemi IT aziendali in modo da rendere automatico lallineamento delle informazioni ridondanti tra i vari sistemi. Soluzioni per Microsoft Oce SharePoint Server: Aqrate sviluppa e fornisce consulenza in ambito SharePoint. Le professionalit che fanno parte del team hanno esperienza concreta nello sviluppo di soluzioni Microsoft SharePoint. Lazienda in grado cos di sviluppare soluzioni ad hoc, integrandosi con gli altri applicativi e server della famiglia Microsoft.
11
1.5
Il processo di sviluppo
Lapproccio di Aqrate quello di focalizzarsi sul business del cliente mediante unesperienza diretta in ambiente di produzione, pi che un approccio teorico. Lattitudine dellazienda propensa allapprendimento della specica realt di business e viene adottata una modalit lavorativa orientata allintegrazione totale con le esigenze del committente. Di norma Aqrate usufruisce del modello di ciclo di vita agile perch consente di rivedere di continuo le speciche e di cambiarle durante lo sviluppo mediante un forte scambio di informazioni e di pareri. Questo modello tenta di ridurre il rischio di fallimento sviluppando il software in nestre di tempo limitate chiamate iterazioni che, in genere, durano qualche settimana. Ogni iterazione un piccolo progetto a s stante e deve contenere tutto ci che necessario per rilasciare un piccolo incremento nelle funzionalit del software : pianicazione, analisi dei requisiti, progetto, implementazione, test e documentazione. Anche se il risultato di ogni singola iterazione non ha sucienti funzionalit da essere considerato completo deve essere rilasciato e, nel susseguirsi delle iterazioni, deve avvicinarsi sempre di pi alle richieste.
Capitolo 2
Strategia aziendale
Il capitolo seguente vuole descrivere al lettore quali sono gli obiettivi da soddisfare durante tutta lattivit di stage, quali sono le motivazioni che hanno spinto lazienda alla proposta del progetto, i vincoli da rispettare e lapproccio usato per la risoluzione del problema. Inoltre viene esposta la pianicazione del lavoro settimanale.
2.1
Introduzione ai PACS, Picture archiving and communication system
PACS lacronimo anglosassone di Picture archiving and communication system (Sistema di archiviazione e trasmissione di immagini) e consiste in un sistema hardware e software dedicato allarchiviazione, trasmissione e visualizzazione delle immagini diagnostiche digitali. Un sistema PACS normalmente composto da una parte di archiviazione, utilizzata per gestire dati e immagini e una di visualizzazione, che presenta limmagine diagnostica su speciali monitor ad altissima risoluzione, sui quali possibile eettuare la diagnosi. I sistemi PACS pi evoluti permettono anche lelaborazione dellimmagine, come per esempio le ricostruzioni 3D. Una parte fondamentale ma non visibile dallutente nale si occupa del colloquio con gli altri attori del usso radiologico, utilizzando di solito i relativi proli IHE (Integrating the Healthcare Enterprise ) tramite lo standard HL7 (Health Level 7 ). In special modo, fondamentale la sua integrazione con il sistema in-
12
CAPITOLO 2. STRATEGIA AZIENDALE
13
formatico radiologico o RIS (Radiology Information System ), che rappresenta il software gestionale della Radiologia.
Figura 2.1: Immagine di una tomograa visualizzata in un sistema PACS.
2.1.1
Immagini
Le immagini sono ricevute e trasmesse nel formato denito da DICOM (Digital Imaging and Communications in Medicine ), che permette di inglobare e trattare anche testo (per esempio i referti) e documenti di vario genere, tra cui i PDF[g] ; i visualizzatori collegati sono in genere in grado di mostrare immagini e referti, ma anche di riconoscere i tipi di immagine e comportarsi di conseguenza. I sistemi PACS, in origine creati per gestire le immagini generate dalle TAC (Tomograa Assiale Computerizzata), al giorno doggi sono in grado di trattare tutte le immagini radiologiche digitali e, tramite speciali digitalizzatori, anche quelle create da modalit analogiche. Da notare che le immagini ricevute non devono essere modicate in alcun modo, per poter sempre risalire alloriginale trasmesso dalla modalit; leventuale elaborazione viene registrata in aggiunta alle altre immagini. Di solito ammessa una compressione senza perdita di dati (lossless ) per diminuire lo spazio occupato su disco. Proprio per garantire che ogni immagine immagazzinata nel PACS sia eettivamente quella generata dalla modalit durante le-
14
same, spesso il PACS spedisce tutti gli oggetti DICOM ad un sistema di archiviazione legale.
2.1.2
Architettura
Recentemente, con levoluzione della tecnologia delle reti, sempre pi sistemi PACS stanno passando ad una architettura di tipo web, dove lapplicazione risiede su un server, permettendo un semplice accesso alle immagini con il solo utilizzo di un browser sul proprio computer, senza necessit di installazioni speciche. Per la semplice distribuzione delle immagini (cio per la loro consultazione, sia nei reparti che allesterno dellospedale) il computer pu essere un normale terminale. Per la diagnosi la stazione di lavoro deve avere: suciente RAM[g] per contenere tutte le immagini sotto esame; unappropriata scheda graca, in grado di pilotare i monitor diagnostici ad alta risoluzione (anche no a 5 megapixel, per gli esami mammograci); un processore potente, per la veloce manipolazione di immagini che possono raggiungere i 20 megabyte luna. In origine, le immagini venivano archiviate immediatamente su memoria di massa locale ad accesso veloce e l tenute per un tempo variabile tra 3 e 6 mesi. In seguito politiche automatiche del sistema le spostavano poi su DVD allinterno di un juke-box (gestore di media ottici), da dove potevano essere richiamate in automatico in caso di necessit senza intervento umano (near-line), ma con tempi di risposta notevolmente superiori. I DVD venivano periodicamente tolti dal juke-box e, contrassegnati da un codice generato dal sistema, immagazzinati in armadi ignifughi: in caso di necessit, gli esami potevano essere immessi nuovamente nel sistema, ovviamente con intervento umano e tempi che non potevano essere minori di qualche ora. Con la diminuzione dei costi delle memorie di massa, diventata prassi mantenere tutte le immagini nella memoria ad accesso immediato cio su hard disk; questo, assieme alle crescenti velocit delle reti, permette un tempo di accesso alle informazioni dellordine dei secondi per una singola immagine. Come aermato in precedenza, un
15
tipico sistema PACS in grado di gestire solo oggetti DICOM; tali oggetti contengono al loro interno, oltre allimmagine, anche i dati relativi al paziente e allesame a cui si riferiscono. Il sistema PACS registra questi dati quando riceve le immagini e li utilizza quando gli viene richiesta una lista di esami o pazienti, invece di accedere ogni volta agli oggetti DICOM; in questo modo, tutte le ricerche sono eettuate su un archivio testuale, ricorrendo a quello DICOM solo quando necessario visualizzare o comunque spostare le immagini. Larchitettura della parte hardware viene progettata ad hoc per ogni situazione, in quanto pu dipendere dal numero di ospedali coinvolti, dal loro carico di lavoro e dalle politiche di backup necessarie per mantenere la continuit del servizio. Larchivio DICOM on-line di solito registrato su memorie di massa su sistemi SAN[g] o NAS[g] , spesso congurati in RAID[g] o con architettura ridondante. Ogni disco pu essere sostituito in caso di problemi senza interrompere il funzionamento del sistema.
Figura 2.2: Architettura di un sistema PACS.
2.1.3
Funzionalit dellarchivio
Le procedure con cui vengono ricevute e trasmesse le immagini sono denite dallo standard DICOM; in generale, il passaggio avviene sempre tra due AETitle (Application Entity Title ): tra la modalit diagnostica che genera le immagini e il PACS, tra il PACS e un archivio remoto o una stampante. Un esempio tipico di utilizzo la procedura di
16
Query/Retrieve, in cui un nodo DICOM remoto richiede una serie di informazioni, per esempio la lista degli esami di un determinato paziente; vengono passati, tramite unassociazione DICOM, i dati da ricercare (in questo caso lidenticativo del paziente) ed i campi che si vogliono avere come risultato (gli identicativi degli esami); il PACS ltra i propri dati e risponde con la lista richiesta. Da tale lista, il richiedente pu decidere di voler vedere le immagini di un determinato esame tra quelli trovati: questa volta la transazione conterr lidenticativo dellesame scelto, mentre le informazioni di ritorno dovranno essere le immagini; il PACS riconosce il comando e metter nella coda di spedizione gli eettivi oggetti DICOM. Tutto questo avviene in modo trasparente allutente: infatti compito dellapplicativo creare la corretta comunicazione DICOM, interpretando le scelte che lutente eettua sullinterfaccia graca. Altre procedure importanti sono la Store (ricevimento delle immagini provenienti da una modalit), lautorouting (inoltro automatico ad un altro nodo DICOM delle immagini ricevute), la print che permette di stampare su una stampante DICOM limmagine assieme alle eventuali annotazioni aggiunte durante la refertazione.
2.1.4
Copia di riserva
La potenza del PACS risiede anche nella possibilit di analisi storiche sullandamento di una patologia, per cui necessario assicurare che quanto archiviato sia sempre disponibile, anche in caso di problemi hardware o avvenimenti esterni. In pi, oltre ai dati personali dei pazienti, nel PACS sono mantenuti anche dati sensibili relativi allo stato di salute: questi dati devono quindi essere protetti da perdite, o meglio in caso di errori o di eventi distruttivi, deve essere possibile il loro recupero, oltre a garantire la continuit dellutilizzo. La legislazione italiana richiede che in caso di problemi larchivio debba essere recuperato entro un massimo di 7 giorni. Quindi, una parte importante di un sistema PACS ha lo scopo di ridurre al minimo i rischi di perdita di dati; le politiche per la sicurezza dei dati sono molteplici, ma lelemento comune rappresentato dalleffettuare una seconda copia di tutti i dati ricevuti: via rete ad un altro server, ad un produttore di media ottici, su unit a nastro; importante che il sistema di recupero sia sicamente in unaltra locazione, per esempio per non essere coinvolto nello stesso incendio. Queste procedure sono indicate con il termine inglese disaster recovery.
17
2.1.5
Integrazioni
Il PACS deve essere integrato con tutti gli altri attori informatici, per poter trarre il massimo vantaggio dallinformatizzazione. Per far questo utilizza sia lo standard DICOM che il linguaggio HL7 come previsto da IHE. Nel normale usso di lavoro della Radiologia, le interazioni in cui coinvolto il PACS sono (secondo il prolo Scheduled Workow - SWF di IHE): Prenotazione: nel caso il sistema PACS non abbia una completa architettura web, il RIS comunica al PACS via HL7 la lista degli esami previsti e nella notte precedente il PACS spedisce alla stazione di visualizzazione gli esami precedenti del paziente (prefetch ), in modo che siano a disposizione del medico radiologo al momento dellesame. Per un sistema web nativo, questa fase non necessaria, in quanto tutti gli esami sono sempre disponibili via web; Accettazione: riceve lavviso dal RIS via HL7 che il paziente giunto in Radiologia e si predispone per ricevere le immagini, per esempio creando il paziente se non gi esistente nellarchivio (alcuni PACS non necessitano di questo passaggio, in quanto possono creare il paziente allarrivo delle immagini, utilizzando i dati allinterno delle immagini stesse); Esecuzione: la modalit diagnostica spedisce le immagini dellesame al PACS; se sono pi di una, sono organizzate in serie. I dati del paziente e dellesame da eseguire sono comunicati dal RIS alla modalit (DICOM Modality Worklist ) prima dellesame; Refertazione: il medico radiologo accede alla propria lista di lavoro dal RIS, che richiede al PACS di aprire le immagini necessarie sui monitor di refertazione; se necessario, il medico pu vedere immagini degli esami precedenti dello stesso paziente. Il referto viene scritto sul RIS, che si occupa di passarlo al PACS: questa comunicazione pu essere fatta tramite un le DICOM (SR - Structured Report ), oppure tramite un messaggio HL7. Il PACS pu gestire sia il referto in formato testo che documenti rmati digitalmente.
18
Esistono almeno due tipi di codici identicativi univoci che attraversano lintero usso, riconosciuti anche dal PACS: lidenticazione del paziente e quella dellepisodio (studio); i codici corrispondenti (PatientID e StudyID) vengono usati ogni volta che necessaria una comunicazione con un altro attore. Esistono poi altri messaggi utilizzati dal PACS per comunicazioni al di fuori del usso di lavoro, tra cui i pi importanti sono quelli relativi allanagraca del paziente (messaggi ADT), scambiati quando tali dati vengono variati o creati. Un esempio importante (descritto nel prolo IHE Patient Information Reconciliation - PIR) laggiornamento di un paziente che allarrivo in ospedale non in grado di comunicare le proprie generalit: lesame verr comunque eseguito utilizzando un nome ttizio, che verr corretto in seguito su un unico attore e propagato a tutti gli altri, tra cui il PACS, che ricever comunicazione tramite il RIS. Secondo la visione IHE, il PACS non ha necessit di integrarsi direttamente con il software di riferimento ospedaliero HIS, ma solamente attraverso il RIS.
19
2.2
Il problema
La necessit di avere un linguaggio digitale universale capace di trasmettere le informazioni cliniche attraverso la rete ha portato ad un accordo tra NEMA (National Electric Manufacturer Association ) ed ACR (American College of Radiology ). Il risultato pi importante stato la creazione del protocollo standard DICOM (Digital Imaging and Communications in Medicine ), che descrive la comunicazione di immagini in un modo standard riconosciuto a livello mondiale. Lo standard permette la formattazione e lo scambio di immagini digitali ad alta risoluzione e di informazioni mediche in tempo reale verso workstation, PACS e stampanti localizzate in aree diverse ma connesse fra loro in rete. La possibilit di immagazzinare, rivedere e trasmettere le immagini cliniche ed i relativi referti attraverso reti locali e geograche in tempo reale crea percorsi innovativi verso nuove frontiere diagnostiche. La semplicit di immagazzinamento e recupero di singole immagini, loop, referti, sono alcune delle possibilit oerte dalla tecnologia basata su piattaforma PC. Aqrate vuole espandere le funzionalit del proprio prodotto, AqrateVector (1.4.1.1), implementando un PACS completo che rispetti il protocollo medicale DICOM.
2.3
Approccio al problema
Il primo approccio al problema la presentazione dello stage nella quale lazienda denisce i requisiti macroscopici. La fruizione di tali informazioni, mi permette di concentrarmi nello studio delle tecnologie e degli strumenti da utilizzare. Il primo passo quello di studiare accuratamente lo standard DICOM, in particolare di comprendere funzionamento, potenzialit ed utilizzo delle SOP Class. Lo studio basato oltre che sulla documentazione fornita dallazienda, sui documenti messi a disposizione dal sito dellassociazione NEMA. Questa prima attivit incentrata sullo standard in oggetto e sulla comprensione dei requisiti da soddisfare. La comprensione del ne ultimo delle funzionalit da sviluppare importante per capire cosa fare e come attuarlo.
20
2.4
Lobiettivo
A fronte di quanto detto nora, lo scopo dello stage quello di realizzare un modulo caricabile dinamicamente da un application server proprietario di Aqrate, in modo da realizzare un PACS (Picture archiving and communication system ) molto basilare. Lobiettivo dello stage di implementare le seguenti SOP Class (3.1.1.5): Verication SOP Class; Storage SOP Class. E cio di fare in modo che lapplicativo sia in grado di: Rispondere al DICOM ping, cio gestire la C-Echo (3.1.1.7); Memorizzare una IOD (Information Object Denition 3.1.1.5) di tipo CR (Computed Radiology ), cio gestire la C-Store (3.1.1.7). Ci si deve cimentare con: La comprensione dello standard DICOM; La scelta dellarchitettura implementativa (vengono valutati due dierenti approcci); Limplementazione del modulo. Per quanto riguarda il secondo punto, fondamentale studiare i punti di forza degli approcci proposti e fornire elementi tali da giusticare la scelta dellarchitettura della soluzione. Limplementazione riguarda lo sviluppo di un componente senza alcuna interfaccia graca, in grado di congurarsi dinamicamente per la ricezione e linvio di messaggi DICOM su socket TCP/IP in grado di gestire le operazioni di C-Store e C-Echo. Tale componente la base per lo sviluppo futuro di un PACS completo che implementi quindi anche altre operazioni utili, come C-Get e C-Find, e che possa integrare il prodotto Aqrate Vector (1.4.1.1) con il protocollo DICOM.
21
2.5
Vincoli
Le direttive date dallazienda allo stagista sono state le seguenti: Sviluppare un PACS Server e un PACS Client; Gestire la C-Echo e la C-Store; Utilizzo del framework[g] Microsoft R .NET, del linguaggio di programmazione C# e Visual Studio 2010 come ambiente di sviluppo integrato; Produzione di documentazione. Tali direttive per essere soddisfatte richiedono una cospicua fase di studio delle normative, per apprendere i concetti che stanno alla base dello standard DICOM. Per questo motivo Aqrate ha stabilito uniniziale attivit di formazione, come vincolo per poter iniziare qualsiasi attivit di sviluppo, con lo scopo di introdurre lo stagista al mondo dei PACS ed alla struttura ed al funzionamento dello standard DICOM. Un altro vincolo richiesto che il software realizzato debba essere il pi possibile portabile e quindi compatibile in particolare con i sistemi operativi GNU/Linux, Mac OS X e Windows. Per lo sviluppo dei documenti si utilizza il programma Microsoft Oce Word. Tutto il codice sorgente che viene creato dal programmatore deve seguire le convenzioni di codica C#. Il codice sorgente che riguarda il progetto deve essere contenuto nella directory del progetto, da cui possono eventualmente partire rami di sviluppo paralleli. Non deve essere presente codice estraneo al progetto. Il codice deve essere accompagnato da commenti scritti in inglese o italiano rispettando le politiche di qualit imposte tramite gli strumenti di validazione del codice. La qualit del codice, ed in particolare la sua estensibilit, devono essere particolarmente curate per facilitare eventuali sviluppi futuri da parte di altre persone. Ogni le di codice sorgente deve possedere unintestazione che abbia un registro delle modiche contenente data della modica nella forma DD.MM.YYYY e autore della modica.
22
2.6
I fattori di rischio
Questa sezione ha lobiettivo di descrivere alcuni dei rischi che possibile incontrare durante la realizzazione del prodotto. Il rischio denito come il valore atteso del danno derivante dal vericarsi di una combinazione di condizioni incerte, tale se comporta un disagio, una soerenza o una perdita, percepibile da determinati soggetti, conseguente al vericarsi di situazioni che sono possibili ma non certe. I rischi non incidono tutti nella stessa maniera, dieriscono per probabilit e impatto. Nella tabella 2.1 deniamo le probabilit di rischio.
Livello di probabilit Basso Medio Alto
Criterio molto probabile che non si verichi Uguale probabilit che si verichi o meno altamente probabile che si verichi
Tabella 2.1: Probabilit di rischio
Di seguito per ogni rischio identicato si cerca di delineare unanalisi generale e una procedura di mitigazione. Assenza per malattia Analisi: per problemi di salute o lo stagista o il tutor aziendale, durante le fasi di verica, potrebbero assentarsi. Probabilit: bassa. Procedura di mitigazione: se lassenza del componente si limita a qualche giorno, ma a un periodo di tempo prolungato, si procede con la ripianicazione del piano di lavoro. Scarsa conoscenza delle tecnologie utilizzate Analisi: alcune delle tecnologie che saranno impiegate durante lo sviluppo del progetto sono a me sconosciute. Probabilit: alta. Procedura di mitigazione: studio della documentazione on-line, in particolare di quella fornita dal tutor aziendale.
CAPITOLO 2. STRATEGIA AZIENDALE Variazione dei requisiti
23
Analisi: non sono ammesse radicali variazioni se non ad evidente miglioramento di quanto pianicato. Probabilit: media. Procedura di mitigazione: se verranno comunicate variazioni dei requisiti, dovr prontamente apportare delle modiche allanalisi dei requisiti e, di conseguenza, allintero progetto, in modo calcolare il prima possibile una nuova stima dei relativi costi e ridurre il danno che pu provocare questo evento. Linguaggio di programmazione Analisi: non si ritiene che luso del linguaggio di programmazione imposto dal committente possa comportare particolari problemi. Probabilit: bassa. Procedura di mitigazione: in caso di problemi con la sintassi o la semantica del linguaggio usufruire della documentazione uciale che si trova nel sito di Microsoft.
2.7
Veriche e revisioni
Le attivit di verica, proposte dal tutor aziendale, sono focalizzate sui concetti appresi e sulla loro attuazione. La verica delle conoscenze maturate la metrica per vagliare la possibilit di proseguire con le attivit proposte o di stanziare nella fase di lavoro in oggetto per raorzare le stesse. Al termine di ogni attivit di sviluppo attuata da parte del tutor aziendale una revisione formale interna. Le revisioni prendono in oggetto i seguenti punti: documentazione prodotta in relazione allo sviluppo eettuato; verica dello stato di avanzamento dello stage.
24
2.8
Utilizzo e sviluppi futuri
Il mio stage serve allazienda per implementare un PACS basilare. Il prototipo da me implementato alla base dello sviluppo di un PACS completo che in futuro servir al prodotto Aqrate Vector (1.4.1.1) per integrare le pi importanti funzionalit DICOM. Il prodotto software, inoltre, verr pubblicato nel sito aziendale con lo scopo di pubblicizzarlo ed indirettamente di acquisire informazioni circa possibili clienti interessati al futuro sviluppo di Aqrate Vector con lo standard DICOM. Il prototipo verr sicuramente migliorato ed espanso introducendo ulteriori servizi quali: Storage commitment : utilizzato per confermare leettiva memorizzazione permanente di un immagine su un dispositivo di memoria; Query/Retrieve : consente ad una stazione di lavoro di trovare gli elenchi di immagini o altri oggetti e poi recuperarli da un PACS; Modality worklist : consente di ottenere i dettagli dei pazienti e la worklist degli esami; Printing : servizio utilizzato per inviare le immagini ad una stampante DICOM. Nella gura seguente viene illustrata unanticipazione dello sviluppo futuro dellarchitettura DICOM del prodotto Aqrate Vector.
Figura 2.3: Architettura di Aqrate Vector integrato con le funzionalit DICOM
25
2.9
Piano di lavoro
Figura 2.4: Diagramma di Gantt relativo al piano di lavoro a preventivo.
26
Nella gura 2.4 viene illustrata la pianicazione delle attivit stabilite ad inizio stage con il tutor dellazienda, al ne di organizzare nel modo migliore le fasi da svolgere.
Come riportato dal diagramma di Gantt, in relazione alle diverse funzionalit da sviluppare, lattivit di stage scomposta in pi fasi: La prima fase consiste nella formazione sulle tecnologie utilizzate allinterno dellazienda, utili e necessarie per le fasi successive: studio dei concetti fondamentali, del dominio e degli strumenti; Le fasi intermedie vertono, invece, nella vera e propria realizzazione e verica delle singole funzionalit: sviluppo, verica e documentazione; Lultima fase dedicata ai test dunit e alla correzione dei malfunzionamenti. La fase iniziale, dedicata alla formazione e comprensione del dominio applicativo ed aziendale, interessa non solo le tematiche arontante durante lo stage, ma presenta una panoramica generale dellazienda e del mercato ICT.
Capitolo 3
Lo stage
Il seguente capitolo vuole descrivere quali sono state le attivit svolte durante il periodo di stage, attraverso le varie fasi arontate, necessarie alla sua realizzazione, cercando di entrare nel dettaglio di quelle pi rilevanti. Il modello di ciclo di vita adottato per lo sviluppo del progetto, e dei singoli moduli, stato quello iterativo evolutivo. La scelta, presa in accordo con lazienda, stata dettata dal fatto che lazienda stessa non aveva unidea del tutto precisa e denitiva riguardo alla metodologia implementativa di determinate funzionalit. Di conseguenza si scelto un modello di ciclo di vita che permettesse un certo grado di libert nellaggiunta incrementale di funzionalit nei moduli stessi, non previste in partenza, ma emerse in fasi successive di realizzazione.
3.1
La formazione
Durante la prima settimana di stage ha avuto luogo la fase di apprendimento dei concetti fondamentali dello standard DICOM, cos come pianicato. Lazienda mi ha fornito di tutti i mezzi necessari, quali documentazione e connessione ad Internet. La prima fase della formazione stata dedicata ad uno studio generale sullargomento per avere una visione completa ed esaustiva del dominio. Successivamente mi sono soermato sui concetti maggiormente correlati allo stage. Di seguito vengono descritti i concetti appresi durante questa prima fase. La seguente documentazione stata da me scritta e fornita allazienda per facilitare lapprendimento dello standard DICOM.
27
CAPITOLO 3. LO STAGE
28
3.1.1
Standard DICOM
DICOM (Digital Imaging and Communications in Medicine ) uno standard orientato alla comunicazione di immagini mediche in formato digitale. Diuso soprattutto nei dipartimenti di radiologia, caratterizzato da una struttura aperta e da ampie possibilit di estensione ed applicazione per tutte le specialit che producono immagini mediche: patologia, endoscopia, odontoiatria, oculistica e dermatologia. Negli anni 80, con la crescente diusione dei sistemi di acquisizione delle immagini mediche in formato digitale (modalit) diventa indispensabile trovare soluzioni per semplicare la connessione e linteroperabilit, a vantaggio di utenti e produttori. DICOM la risposta a questa necessit. DICOM denisce linterfaccia che rende possibile la connessione tra sistemi diversi. Le funzionalit oerte includono: il trasferimento in rete di oggetti ed immagini (invio, ricezione e ricerca); il trasferimento tramite le; lintegrazione con altri sistemi (richiesta di un elenco di esami da completare, invio della notica dellesecuzione di un esame, impiego di documenti strutturati per la gestione congiunta di dati, referti ed immagini). Lo standard stato sviluppato congiuntamente da utenti e produttori di dispositivi con lobiettivo di rendere possibile la connessione tra sistemi di produttori diversi. Possiede le componenti fondamentali per dialogare con i sistemi informatizzati di gestione delle immagini (PACS, Picture Archiving and Communication System ), dellattivit ospedaliera (HIS, Hospital Information System ) e, in particolare, del dipartimento di radiologia (RIS, Radiology Information System ). 3.1.1.1 Le caratteristiche generali
Le speciche DICOM si sviluppano a partire da modelli che stabiliscono quali sono e con quali relazioni interagiscono le entit reali, presenti nel contesto a cui lo standard applicato (pazienti, immagini, ecc.). Il vantaggio di questi modelli quello di mostrare chiaramente e congiuntamente le entit e le relazioni, non per descrivere il usso dei dati, ma per denire la struttura dellinformazione. I modelli sono generalmente rappresentati con diagrammi del tipo schematizzato in gura 3.1, dove le frecce vengono utilizzate per indicare la direzione di una relazione. La documentazione dello standard suddivisa in parti e ciascuna parte pu comprendere degli allegati, dove sono riportate quelle sezioni che possono essere oggetto di
29
Figura 3.1: Schema semplicato delle relazioni tra le entit paziente, studio, serie ed immagine nello standard DICOM.
modiche od estensioni. Lo standard in continua evoluzione, per migliorare le funzionalit indirizzate allintegrazione e per ampliare le possibilit di interfacciare sistemi diversi da quelli tradizionalmente presenti in un reparto di radiologia. 3.1.1.2 La dichiarazione di conformit
La conformit allo standard DICOM dovrebbe assicurare la connettivit tra due dispositivi, cio la possibilit di scambiare in modo corretto messaggi in formato DICOM, ma non implica linteroperabilit a livello di applicazione, cio la capacit di manipolare correttamente linformazione. Linteroperabilit pu richiedere speciche aggiuntive sulle applicazioni e sul usso di dati. Lo standard DICOM impone di specicare in una dichiarazione di conformit le informazioni necessarie per assicurare la connettivit e per poter vericare il livello di interoperabilit, senza dover sicamente provare il sistema. Conseguentemente, per poter qualicare unimplementazione dello standard e valutarne la compatibilit con altri sistemi, non suciente la semplice conformit allo standard, deve essere esaminato il contenuto della dichiarazione di conformit.
CAPITOLO 3. LO STAGE 3.1.1.3 Il modello di informazione
30
In funzione della specialit clinica, possono variare la terminologia e le modalit operative utilizzate per lacquisizione delle immagini, per lesecuzione delle procedure e per lidenticazione delle immagini. In un ambiente in cui linformazione deve essere condivisa, queste diversit devono essere in parte superate. Linformazione deve essere manipolata in modo uniforme, indipendentemente dal particolare contesto in cui viene generata. DICOM utilizza un proprio modello di informazione, sucientemente essibile ed adattabile ad ambienti diversi. La struttura del modello un insieme di entit e relazioni tra entit, dove ciascuna entit caratterizza una specica fase del processo di produzione e manipolazione delle immagini. Le principali entit e relazioni presenti nel modello DICOM possono essere descritte con riferimento allattivit di un tipico dipartimento di radiologia. Come indicato nello schema semplicato di gura 3.1, le immagini prodotte da ciascuna modalit vengono ordinate in una cartella paziente per tipo di studio e per serie correlate da speciche condizioni. Le principali entit sono il paziente, lo studio, la serie e limmagine. Le corrispondenti relazioni sono: il paziente oggetto di uno o pi studi; ciascuno studio pu contenere una o pi serie; ciascuna serie pu contenere una o pi immagini.
Figura 3.2: Schema semplicato della distribuzione gerarchica dellinformazione tra le entit paziente, studio, serie ed immagine nello standard DICOM.
Il modello DICOM distribuisce linformazione gerarchicamente su quattro livelli fondamentali, come illustrato in Figura 3.2. Il livello pi elevato costituito dai dati iden-
31
ticativi del paziente sottoposto a studio. Lo studio raccoglie le informazioni relative ad una richiesta di esami e costituisce il livello di riferimento per il sistema amministrativo (dipartimentale o centrale). La serie denisce le caratteristiche e le modalit operative dei sistemi utilizzati per eettuare lesame. Il livello pi basso costituito dai dati rappresentativi dellimmagine prodotta dal dispositivo di acquisizione. Le diverse entit sono strettamente collegate alle diverse fasi del processo di produzione di unimmagine. Diversi sottosistemi generano in momenti diversi linformazione associata a ciascuna entit, come illustrato schematicamente in gura 3.3. I dati del paziente vengono normalmente forniti dal sistema amministrativo (centrale o dipartimentale) e sono utilizzati dal sistema di acquisizione. I dati relativi allo studio provengono in parte dal sistema amministrativo, che fornisce gli elementi per identicare e collegare parti diverse di uno stesso studio, e in parte dal sistema di acquisizione. Le informazioni sulla serie e sulle immagini sono completamente dipendenti dal sistema di acquisizione. 3.1.1.4 Le principali entit
Lentit paziente costituisce il punto di riferimento per tutta linformazione prodotta su un singolo paziente. A questa devono essere collegati tutti gli studi a cui il paziente stato sottoposto. La struttura dati del paziente contiene codici di identicazione ed informazioni di tipo anagraco. Linformazione viene generata e mantenuta dal sistema amministrativo esterno al sistema di acquisizione. Lentit studio il principale livello di riferimento clinico ed amministrativo. Viene generata da una richiesta di esami. A questa possono essere associate una o pi procedure e ciascuna procedura pu produrre una singola immagine o una serie di immagini correlate. Linformazione viene prodotta in parte dal sistema amministrativo, che deve garantire lidenticazione consistente dello studio, e in parte dal sistema di acquisizione. La struttura dati dello studio contiene codici di identicazione univoca (UID, Unique Identier) ed informazioni relative allesame (data e ora di esecuzione, nome del medico richiedente, ecc.) e al paziente (et, sesso, peso, occupazione, ecc.). Lentit serie associata ad uno specico sistema di acquisizione e alle modalit operative di una particolare procedura. A questa possono essere associate una o pi immagini. La relazione tra le immagini pu essere di tipo clinico (ad esempio immagini dello stesso organo visto da posizioni diverse) o sico
32
(ad esempio una sequenza di immagini temporalmente o spazialmente correlate). In DICOM, non esiste un insieme di regole che denisca, per ogni sistema di acquisizione, il contenuto di una serie. Rientra nei compiti della dichiarazione di conformit specicare quali regole siano utilizzate da una particolare implementazione. Linformazione viene generata esclusivamente dal sistema di acquisizione. La struttura dati della serie contiene codici di identicazione univoca (UID) ed informazioni relative al dispositivo utilizzato e alle modalit di acquisizione.
Figura 3.3: Schema semplicato delle sorgenti di informazione per le entit paziente, studio, serie ed immagine nello standard DICOM.
Lentit immagine contiene, in formato digitale e in funzione del dispositivo utilizzato, una singola immagine o una coppia di immagini (ad esempio per i sistemi biplanari) o un insieme di immagini (ad esempio una sequenza di fotogrammi). Immagini multiple possono essere trattate come una singola immagine, quando la loro relazione molto semplice. Linformazione viene generata esclusivamente dal sistema di acquisizione. La struttura dati dellimmagine contiene codici di identicazione univoca (UID) ed informazioni relative alle matrici di pixel (dimensioni, valori numerici, codica, ecc.). 3.1.1.5 Le classi DICOM
Nel denire le procedure di gestione dellinformazione, lo standard DICOM segue un approccio orientato agli oggetti, basato su classi ed istanze. Una classe contiene una coppia di dichiarazioni relative ai dati e ai metodi utilizzabili per trattare una specica tipologia di oggetti. I dati codicano linformazione. I metodi determinano quali operazioni possono essere eettuate. La classe unentit astratta. Dichiara il formato e la struttura dei dati (non il loro valore) e il tipo di operazioni ammesse. Unistanza rappresenta un particolare oggetto di una classe. Il valore dei suoi dati deve essere
33
compatibile col formato dichiarato nella classe di appartenenza. Listanza pu essere manipolata solo con i metodi deniti nella classe di appartenenza. In DICOM linformazione viene scambiata mediante istanze a classi. La struttura delle classi viene denita con una specica terminologia. Le immagini vengono descritte da classi SOP (Service Object Pair ), che comprendono una denizione IOD (Information Object Denition ), per la parte dati, e un gruppo di servizi, per la parte metodi. Le classi SOP possono specicare estensioni o restrizioni dei dati presenti nella denizione IOD o dei metodi disponibili nel gruppo di servizi. Specici meccanismi di generazione dei codici di identicazione univoca (UID) garantiscono lunivocit di unistanza SOP e facilitano la costruzione di relazioni certe tra le diverse istanze. La classe SOP costituisce lunit funzionale elementare di DICOM. Ciascuna implementazione dichiara quali sono le classi disponibili (conformi allo standard) e in quale modo sono supportate. Implementazioni diverse possono comunicare solamente utilizzando le parti funzionali comuni. Chiarita lunit funzionale fondamentale denita da DICOM (la SOP Class) vediamo come avviene lo scambio di informazioni. Alla base del protocollo in esame esiste un approccio Client/Server, nel senso che, ogni volta che due applicazioni decidono di connettersi per scambiarsi informazioni, una delle due deve svolgere il ruolo di fornitore del servizio (SCP: Service Class Provider ) mentre laltra quello di utente (SCU: Service Class User ). Ovviamente, per ciascuna combinazione di SOP Class e ruolo, lo standard denisce un set di regole di base controllate in fase di pre-colloquio o negoziazione, durante la quale si stabilisce se la comunicazione tra i due apparati possibile oppure no. 3.1.1.6 Le entit di informazione
La parte dati di una classe SOP una denizione IOD. Le denizioni IOD specicano il signicato, gli obiettivi e la struttura dellinformazione rappresentata. Linformazione viene suddivisa in entit di informazione. Ciascuna entit di informazione corrisponde ad una particolare entit del modello di informazione DICOM. Unentit di informazione contiene un insieme di attributi, ciascuno dei quali descrive una porzione di informazione elementare. Per esempio, gli attributi della denizione IOD del paziente comprendono il nome, il cognome e il sesso. Attributi correlati sono raggruppati in moduli. Per
34
ciascun attributo viene specicato un codice di identicazione univoco, oltre ad un nome e ad una breve descrizione del signicato e dei possibili valori. Una denizione IOD normalizzata ha una sola entit di informazione. Ad esempio, normalizzata la denizione IOD del paziente, che contiene solo dati relativi al paziente, principalmente di tipo anagraco. Una denizione IOD composita contiene pi entit di informazione tra loro correlate. Ad esempio, composita le denizioni IOD di unimmagine, destinata a rappresentare informazioni relative alle entit paziente, studio e serie, assieme ai dati propri dellimmagine. Unimmagine DICOM unistanza ad una classe SOP. Unistanza composita contiene tutta linformazione necessaria per il trattamento dellimmagine. La parte dati strutturata conformemente al modello di riferimento denito dallo standard e contiene lintera gerarchia di informazioni, dallentit paziente allentit immagine. In questa modalit, parte dei dati vengono duplicati per tutte le istanze relative allo stesso paziente e allo stesso studio. Unistanza normalizzata contiene linformazione relativa allentit immagine e solo i riferimenti per tutte le altre entit necessarie per ricostruire linformazione associata allimmagine. In questa modalit diminuisce la quantit di dati da trasferire ed aumenta la complessit dei collegamenti tra le diverse istanze. Le diverse istanze devono fornire dati consistenti per tutte le entit presenti ai diversi livelli. Le informazioni relative allo studio e al paziente devono essere confrontabili per tutti i dispositivi utilizzati e devono essere garantite da una fonte esterna comune. Ciascuna implementazione dello standard deve inoltre denire una struttura uniforme per tutte le serie e le immagini generate su uno stesso dispositivo. Lidenticazione di ciascuna entit (paziente escluso) viene ottenuta assegnando un codice identicativo univoco (UID). I meccanismi di identicazione univoca del paziente devono essere garantiti da un soggetto esterno. 3.1.1.7 Gli elementi di servizio
Il gruppo di servizi, o anche chiamato DIMSE service, si compone di elementi di servizio. Gli elementi di servizio deniti in DICOM contengono speciche che ne possono limitare lapplicazione solo a denizioni IOD normalizzate o composite. Elementi di servizio applicabili a denizioni IOD normalizzate sono utilizzati per: leggere o modicare il valore di uno o pi attributi;
CAPITOLO 3. LO STAGE creare o cancellare unistanza; segnalare un evento; eseguire unazione. Elementi di servizio applicabili a denizioni IOD composite sono utilizzati per:
35
memorizzare unistanza in unaltra Application Entity, servizio chiamato C-Store; trovare o leggere tutte le istanze aventi attributi con pressati valori, servizio chiamato C-Find; vericare la comunicazione fra due AE, servizio chiamato C-Echo. Esistono elementi di servizio specici per ciascuna tipologia di classe DICOM. Ad esempio, nel modello DICOM una richiesta di esami si compone di una o pi richieste di procedure, ciascuna delle quali viene eseguita in una o pi fasi. Le liste di lavoro DICOM includono tutte le fasi previste dalle procedure, suddivise per paziente. Gli elementi di servizio DICOM, previsti per le classi relative alle liste di lavoro, includono: La gestione delle liste di lavoro: permette ad una modalit di richiedere la lista di lavoro corrente, di selezionare i pazienti e di programmare lesecuzione di speciche fasi, previste dalle procedure richieste. La notica di esecuzione di una fase di una procedura: permette ad una modalit di inviare al sistema informatizzato (HIS o RIS) le informazioni relativi allesecuzione e ai risultati di una particolare fase, prevista dalla procedura richiesta. 3.1.1.8 La denizione delle immagini
Lo standard DICOM denisce pi classi SOP di tipo immagine. Ciascuna classe utilizza una specica denizione IOD, applicabile ad un particolare dispositivo di acquisizione. Tutte condividono un insieme minimo di informazioni che permette la visualizzazione delle immagini in modo generico, indipendentemente dal tipo di classe. Le informazioni di base, che devono essere presenti in unistanza ad una classe SOP di tipo immagine, sono: gli identicatori (UID) della classe, dello studio, della serie e dellimmagine (lUID
36
dellimmagine coincide con lUID dellistanza); il tipo di dispositivo di acquisizione; le informazioni sulla matrice di pixel dellimmagine. Altre informazioni utili per descrivere il paziente, lo studio, la serie ed ulteriori particolari dellimmagine possono essere omessi. Sono disponibili estensioni alla denizione IOD di immagine generica per quasi tutte le principali modalit e, in particolare, per i seguenti sistemi: Radiograa computerizzata: non sono richieste informazioni speciche particolari; Tomograa computerizzata: il posizionamento importante per elaborare sequenze di immagini e creare rappresentazioni tridimensionali; Risonanza magnetica: oltre ad informazioni di posizione sono necessarie informazioni sul protocollo di acquisizione; Medicina nucleare: contiene informazioni dedicate sulle modalit di acquisizione e sul formato dellimmagine; Ultrasuoni: sono importanti i parametri di acquisizione, posizione e formato e le informazioni sul colore; Angiograa: sono importanti i parametri di acquisizione, posizione e formato e le informazioni sullimmagine utilizzata come maschera per la sottrazione. Ciascuna denizione IOD pu utilizzare moduli comuni a tutte le denizioni IOD o moduli specici presenti in un solo tipo di denizione IOD.
37
3.2
3.2.1
Analisi dei requisiti

Requisiti Software
Si presenta ora la tabella dei requisiti, divisi per categoria e ordinati secondo tre livelli di priorit dal pi alto al pi basso: obbligatorio (OB), desiderabile (DE), opzionale (OP). Ad ogni requisito assegnato un codice che lo identica univocamente. I codici vengono assegnati secondo la seguente convenzione: A.PR n dove A una lettera che identica il tipo di requisito, PR identica la priorit del requisito ed ad ognuno assegnato un numero n. Codice F.OB 1 F.OB 2 F.OB 3 F.OB 4 F.DE 1 F.DE 2 F.DE 3 F.OP 1 Descrizione Sviluppare un PACS Server Sviluppare un PACS Client Rispondere al DICOM PING, cio gestire la C-Echo Memorizzare una IOD (Information Object Denition ) di tipo CR (Computed Radiology ), cio gestire la C-Store Possibilit di trasferire le DICOM contenenti immagini JPEG[g] Possibilit di trasferire le DICOM contenenti immagini JPEG2000[g] Creare un le di congurazione con cui lutente possa settare i parametri dassociazione Creare uninterfaccia graca usando la libreria WPF per lapplicazione lato server Tabella 3.1: Requisiti funzionali
Codice V.OB 1 V.OB 2
Descrizione Utilizzo del linguaggio di programmazione C# e Visual Studio 2010 come ambiente di sviluppo integrato Produzione di documentazione Tabella 3.2: Requisiti di vincolo
Codice Q.OB 1 Q.OB 2 Q.OB 3
Descrizione Eettuare test di unit per ogni funzionalit sviluppata Eettuare analisi statica del codice Testare il PACS basilare sviluppato con i le DICOM rilasciati dal sito uciale http://medical.nema.org Tabella 3.3: Requisiti di qualit
38
3.2.2
Casi duso
Presentiamo di seguito alcuni casi duso della componente software realizzati. Vedremo possibili usi generali e come le componenti interagiscono tra di loro.
Figura 3.4: Diagramma UC1: Use case generale delle funzionalit a disposizione dellApplication Entity chiamante.
Use case: UC1; Sommario: Funzionalit a disposizione dellApplication Entity chiamante; Attore: Application Entity Calling ; Precondizioni: indirizzo IP, porta, Abstract Syntax e Transfer Syntax devono essere congurate correttamente; Descrizione: lApplication Entity chiamante dopo aver richiesto e in seguito stabilito unassociazione pu richiedere le operazioni di C-Echo o di C-Store. Al termine richiede la chiusura dellassociazione. Postcondizioni: loperazione eettuata andata a buon ne.
39
Figura 3.5: Diagramma UC2: Use case generale delle funzionalit a disposizione dellApplication Entity chiamato.
Use case: UC2; Sommario: Funzionalit a disposizione dellApplication Entity chiamato; Attore: Application Entity Called ; Precondizioni: indirizzo IP, porta, Abstract Syntax e Transfer Syntax devono essere congurate correttamente; Descrizione: lApplication Entity chiamante dopo aver ricevuto e in seguito stabilito unassociazione esegue le operazioni di C-Echo o di C-Store. Al termine chiude lassociazione. Postcondizioni: loperazione eettuata andata a buon ne.
40
3.3
Progettazione
Dopo aver studiato lo standard DICOM ed aver focalizzato i requisiti da adempiere, ho dovuto progettare larchitettura delle componenti software. Una rete PACS composta da un server PACS centrale il quale possiede un database contenente immagini che pi client possono archiviare, recuperare e visualizzare. Il server e i client comunicano fra di loro utilizzando il protocollo DICOM. Ogni computer in una rete PACS sono identicati dal proprio indirizzo di rete (IP Address ), dalla porta di comunicazione (porta TCP/IP) e da un nome (Application Entity Title ). Ogni computer un DICOM Node nella rete PACS. IP address, porta TCP/IP e Application Entity Title sono informazioni obbligatorie per connettere ogni DICOM node nelle rete PACS. Per costruire la versione demo di un PACS che ci interessa abbiamo bisogno di: Una componente software che rappresenti un PACS Server. Essa deve essere capace di stabilire unassociazione con il client, di rispondere al ping di un client, di salvare ed archiviare un le DICOM in un dispositivo di memoria persistente. Concluse le operazioni richieste dal client deve rilasciare lassociazione cos da essere disponibile per unaltra operazione con un altro client. Una componente software che rappresenti un PACS Client. Essa richiede di stabilire unassociazione con il server, in seguito pu vericare se il server disponibile in rete, pu richiedere di archiviare un le DICOM e richiede di rilasciare lassociazione una volta nita loperazione.
41
Figura 3.6: Architettura della rete PACS: un PACS Server, e multipli PACS Clients (PACS Workstations / DICOM Viewers )
Per connettere client e server fondamentale instaurare unassociazione DICOM. Lo scopo di questultima di assicurare che due applicazioni DICOM siano compatibili e trasferiscano dati in un formato ed in un ordine ben denito. Le regole delle associazioni DICOM, costruite sopra larchitettura TCP/IP, rendono questultima capace di trattare gli oggetti e i comandi DICOM. La costituzione di un associazione DICOM il processo che avviene allinizio di ogni transazione della rete DICOM, uno sorta di handshake. Durante questo handshake due Application Entity DICOM si scambiano informazioni circa le loro funzionalit e si accordano sui parametri di comunicazione che devono essere utilizzati. La chiave di ogni associazione il concetto di Presentation Context. Quando unApplication Entity vuole inizializzare una transazione di rete essa comprime tutte le informazioni di s stessa in un messaggio di Presentation Context e lo manda allApplication Entity ricevente. Un messaggio di Presentation Context composto da: Abstract Syntax : codica le SOP Class supportate nella comunicazione fra Application Entity ;
42
Transfer Syntax : rappresenta i formati di codicazione dei dati che sono supportati nella comunicazione. Quando un messaggio di Presentation Context mandato allApplication Entity ricevente, questultima accetta o riuta lassociazione.
Figura 3.7: Richiesta di associazione DICOM
Al giorno doggi data la vasta scelta di progetti open source[g] disponibile nella rete Internet possibile costruire una rete PACS gratuitamente avendo solo come costi le componenti hardware utilizzate. Con il consenso dal tutor aziendale, ho analizzato la gamma di librerie DICOM disponibili in Internet al ne di poter scegliere quella maggiormente indicata ai nostri ni. Avendo come requisito obbligatorio di vincolo luso del framework .NET, sono state prese in considerazione librerie implementate con il linguaggio di programmazione C# escludendo quelle implementate utilizzando come linguaggio Java, come ad esempio la libreria Java Dicom Toolkit (http: //wiki.trispark.com/display/jdt/) o la libreria dcm4chee (http://sourceforge. net/projects/dcm4che/). Sono state analizzate le librerie open-source Dicom# (http: //sourceforge.net/projects/dicom-cs/) e ClearCanvas (http://www.clearcanvas. ca/dnn/). Inizialmente, su consiglio del mio tutor aziendale, stata presa in considerazione anche Leadtools (http://www.leadtools.com), libreria shareware[g] . Senza dubbio delle tre librerie quella architettata ed implementata nel modo migliore Leadtools ma dopo aver contattato tramite e-mail lazienda LEAD Technologies, Inc. stata rapidamente esclusa poich il costo della licenza per il rilascio e per la necessaria manutenzione era spropositato. Dicom# e ClearCanvas sono state analizzate studiando il
43
loro diagramma delle classi, le misurazioni sul loro codice e le funzionalit che mettevano a disposizione. Seppur Dicom# abbia minore complessit ciclomatica[g] e minore grado di accoppiamento[g] delle classi rispetto alla libreria ClearCanvas, ho scelto questultima per i seguenti motivi: oltre alle DIMSE C-Echo e C-Store, mette a disposizione i servizi di C-Find, C-Move, C-Get; in grado di integrare le DICOM contenenti dati compressi secondo gli algoritmi JPEG, JPEG Lossless, JPEG Lossy e JPEG2000; dispone di una documentazione ben argomentata e di un forum di supporto ed assistenza sempre celere e di grande aiuto.
44
3.4
Implementazione
Come precedentemente detto ho implementato il PACS basilare usufruendo della libreria ClearCanvas, la quale denisce IOD e DIMSE dello standard DICOM. Ho sviluppato la componente client, successivamente la componente server. Data la disponibilit di tempo rispetto a quanto pianicato, anche se non era previsto, ho proposto al tutor aziendale la creazione di uninterfaccia graca per il server. Dopo la risposta positiva del tutor ho implementato linterfaccia usando la libreria graca WPF. risultata molto interessante lidea dellinterfaccia poich d la possibilit di pubblicare nel sito dellazienda un PACS Server demo, cominciando cos a pubblicizzare il prodotto. Nelle prossime sottosezioni verr brevemente descritto ci che stato fatto.
3.4.1
Componente Client
Figura 3.8: DC1 : Diagramma delle classi della componente client
45
Per la componente client ho implementato la classe Client, la quale contiene tre fondamentali metodi, oltre al costruttore. Nel costruttore creo unistanza della classe ClientHandler, la quale mi rappresenta un nuovo handler [g] che mi gestisce tutti gli eventi associati al client. Con il metodo void init(...) creo e conguro i parametri dassociazione. Imposto il nome dellApplication Entity Client e dellApplication Entity Server, lindirizzo IP e la porta in cui si metter in ascolto il server. Inoltre setto la struttura dati Presentation Context, la quale comprende sia lAbstract Syntax che la Transfer Syntax. I dati di congurazione li ricavo dal le di settings AqrateSettings.
Figura 3.9: File con i dati di congurazione.
Con il metodo void start() se i parametri dassociazione sono congurati correttamente e se un PACS server disponibile apro un nuovo socket [g] e cerco di connettere il client aprendo quindi una nuova associazione. Dopo aver aperto una nuova associazione con il server, lhandler del client pu gestire i seguenti eventi: Dimse Timeout ; Errore di rete; Aborto dellassociazione da parte del server; Risposta di associazione avvenuta con successo; Risposta di associazione riutata;
CAPITOLO 3. LO STAGE Risposta di rilascio dellassociazione; Risposta di operazione eettuata con successo da parte del server.
46
Con il metodo void stop() blocco lassociazione con il server e chiudo il socket del client.
3.4.2
Componente server
Figura 3.10: DC2 : Diagramma delle classi della componente server
Per la componente server ho implementato la classe Server, la quale contiene tre fondamentali metodi, oltre al costruttore. Nel costruttore creo unistanza della classe ServerHandler, la quale mi rappresenta un nuovo handler che mi gestisce tutti gli eventi associati al server. Con il metodo void init(...) creo e conguro i parametri dassociazione. Imposto il nome dellApplication Entity Client e dellApplication Entity Server, lindirizzo IP e la porta in cui si metter in ascolto il server. Inoltre setto la struttura
47
dati Presentation Context, la quale comprende sia lAbstract Syntax che la Transfer Syntax. I dati di congurazione li ricavo dal le di settings AqrateSettings (vedi gura 3.9). Con il metodo void start() apro un nuovo socket e metto in ascolto il server per qualsiasi richiesta del client. Dopo aver aperto una nuova associazione con il client, lhandler del server pu gestire i seguenti eventi: Dimse Timeout; Errore di rete; Aborto dellassociazione da parte del client; Richiesta di associazione; Richiesta di rilascio dellassociazione; Richiesta di eettuare una DIMSE. Con il metodo void stop() blocco lassociazione con il client e chiudo il socket del server.
3.4.3
Interfaccia graca del server
Figura 3.11: Screenshot[g] della prima nestra
48
La prima nestra dellinterfaccia graca della componente server composta da unarea di testo, nella quale vengono riportati gli eventi e le operazioni eettuate da parte del server, da un bottone che premuto mette in ascolto o meno il socket del server e da un altro bottone che serve per congurare tutti i parametri. Se si preme questultimo appare la sottostante nestra.
Figura 3.12: Screenshot della nestra nella quale si congurano i parametri generali
In questa nestra si possono congurare il nome dellApplication Entity del server, il numero della porta della rete TCP/IP, lindirizzo IP e la cartella di destinazione per un eventuale salvataggio di un le DICOM. Con il bottone Advanced si possono abilitare o disabilitare i vari parametri di congurazione del Presentation Context.
49
Figura 3.13: Screenshot della nestra nella quale si congurano i parametri di Abstract Syntax
Figura 3.14: Screenshot della nestra nella quale si congurano i parametri di Transfer Syntax
50
3.5
3.5.1
3.5.1.1
Verica e validazione
Metodi di verica utilizzati
Test
Lanalisi dinamica una forma di analisi che richiede lesecuzione del codice e viene utilizzata sia per la verica che per la validazione del software. Questo tipo di analisi viene eetuato tramite prove, dette test, su singole unit, su unit integrate tra loro o sullintero sistema. Durante lattivit di stage sono state eettuati due tipi di test: Test di sistema: vengono applicati al sistema software completo e integrato. Lobiettivo di un test di sistema quello di vericare che il sistema aderisca a tutti i requisiti specicati. Principalmente questo tipo di test sono test funzionali, ovvero vengono controllate le dierenze tra il sistema e i requisiti funzionali e i test case vengono presi dai casi duso. Con i test di sistema si controllano quindi le dierenze tra i casi duso e il comportamento osservato; Test di unit: vengono applicati ai singoli moduli o componenti software e mirano a vericare la presenza di malfunzionamenti, errori e difetti. Il piano di test di unit, ovvero la batteria dei test da eseguire, pu essere pianicato solamente al termine della progettazione di dettaglio del sistema. I test di unit che saranno eseguiti mireranno ad avere sia copertura statement (eseguire almeno una volta tutte le righe di comando del software ) sia copertura branch (eseguire ogni ramo della logica del usso di controllo almeno una volta). I test di unit si dividono in: Test funzionali (Black Box ): tecnica fondata sullanalisi delloutput generato dal sistema in risposta a specici input senza preoccuparsi del codice. Una strategia per la denizione dei casi di test basata sulla suddivisione degli input in classi di equivalenza. Se linput valido un range si creano tre classi di equivalenza corrispondenti ai valori sotto, sopra e dentro al range. Se invece linput valido un insieme discreto di valori allora si creano due classi di equivalenza corrispondenti ai valori dentro e fuori allinsieme. Si intende
51
che il comportamento del sistema sia equivalente per input appartenenti alla stessa classe di equivalenza; Test strutturali (White Box ): tecnica fondata sulla individuazione di specici input deniti sulla conoscenza della struttura del software ed in particolare del codice ed analisi delloutput. Il criterio di copertura che ciascuna istruzione e ramo del usso siano eseguiti almeno una volta. 3.5.1.2 Metriche
Una metrica lo standard per la misura di alcune propriet del software e viene generalmente utilizzata per stimare la qualit del software stesso. Le metriche prese in considerazione durante lattivit di stage si dividono in metriche dimensionali e di complessit.
Metriche dimensionali Linee di codice sorgente: SLOC (Source Line of Code ): misurazione della dimensione del software. Tale metrica si basa sul numero di codice sorgente scritte. Percentuale di commenti: percentuale delle linee di commento rispetto a tutte le linee di codice. usata per valutare la comprensibilit, il riuso e la manutenzione. Il CP ideale di circa il 30%.
Metriche di complessit Complessit Ciclomatica: rappresenta il numero di test necessari per testare il codice in modo completo. La complessit ciclomatica viene usata per valutare la complessit di un algoritmo di un metodo e si basa sulla struttura del grafo che lo rappresenta. In un grafo G fortemente connesso, il numero ciclomatico v(G) uguale al numero di percorsi linearmente indipendenti. Se sono presenti molte espressioni booleane ci saranno tante scelte che generano percorsi multipli, ad
52
ognuno dei quali associato un caso di test; minore il valore della complessit ciclomatica e minore la dicolt di esecuzione dei test.
3.5.2
3.5.2.1
Descrizione dei test e delle misurazioni eettuati

Test di unit
Ogni modulo, una volta ultimato, stato mantenuto in Alpha-test per alcune ore. La strategia si rivelata molto utile, vista la natura del progetto: le sezioni da sviluppare non prevedevano algoritmi complessi o interazioni molto tte fra componenti. La maggior parte del lavoro di test consistita nel vericare che le funzionalit sviluppate rispondessero correttamente con input volutamente errati. In sintesi, stato necessario vericare che il sistema di validazione dei dati funzionasse. La scelta stata eettuata dallazienda, in quanto tale metodo viene utilizzato correntemente per tutte le altre implementazioni che vengono eettuate in azienda. 3.5.2.2 Test di sistema
Vengono qui di seguito elencati i requisiti obbligatori, deniti nel documento Analisi dei requisiti, che verranno testati tramite test di sistema. Per ognuno di tali requisiti verr data una descrizione di cosa dovr fare il test e il grado del suo soddisfacimento. Server Descrizione: sviluppare un PACS server; Soddisfacimento: totale. Client Descrizione: sviluppare un PACS client; Soddisfacimento: totale. C-Echo Descrizione: rispondere al DICOM PING, cio gestire la C-Echo;
CAPITOLO 3. LO STAGE Soddisfacimento: totale. C-Store
53
Descrizione: Memorizzare una IOD (Information Object Denition ) di tipo CR (Computed Radiology ), cio gestire la C-Store; Soddisfacimento: totale.
3.5.2.3
Risultati delle misurazioni
Utilizzando la funzionalit Code Metrics di Visual Studio 2010 si sono potute calcolare le seguenti misurazioni: numero di SLOC; percentuale di commenti; complessit ciclomatica. Nella tabella 3.4 sono illustrati i risultati che si sono ottenuti per ogni componente in merito alle due misurazioni prese in esame. Componente CLIENT SERVER INTERFACCIA GRAFICA SLOC 91 184 247 CP 27% 12% 24% CC 15 25 89
Tabella 3.4: Risultati delle misurazioni
Capitolo 4
Valutazione retrospettiva
4.1 Analisi personale dellattivit di stage
Attraverso lattivit di stage ho potuto osservare come si dierenzi il modus operandi accademico da quello professionale; seppur nel settore informatico si avvicinino molto di pi rispetto ad altri ambiti, si nota un profondo distacco tra il mondo universitario e il mondo del lavoro. Allinterno dellazienda richiesto, oltre che la funzionalit e la documentazione dellapplicativo, una presentazione che lo renda appetibile a possibili utenti compratori mentre in ambito universitario la logica e il percorso concettuale che portano alla creazione del prodotto sono fattore dinteresse primario. A mio parere lattivit di stage resta un punto fondamentale del corso di laurea perch permette di ampliare le conoscenze teoriche e pratiche gi acquisite e di entrare in contatto con le dinamiche lavorative tese soprattutto alla soddisfazione del cliente nale. Ho inoltre potuto notare che nel lavoro vengono richieste conoscenze speciche ed approfondite degli strumenti utilizzati. Questo aspetto non viene arontato nel percorso di studi universitari, a causa del poco tempo a disposizione e per la continua evoluzione che caratterizza il mondo dellinformatica. Nonostante ci, penso che listruzione universitaria abbia un approccio proiettato al futuro e come tale, il suo compito sia quello di fornire i concetti che stanno alla base delle tecnologie pi diuse, senza focalizzarsi troppo su un caso specico.
54
CAPITOLO 4. VALUTAZIONE RETROSPETTIVA
55
4.2
Conoscenze pregresse ed acquisite
La distanza tra le conoscenze da me possedute ad inizio stage e quelle richieste risultata ampia, ma questo era noto e previsto ben prima dellavvio delle attivit. Il tutor aziendale che mi ha seguito conosce la realt universitaria e sa quali sono le conoscenze medie di uno studente del terzo anno del corso di informatica, quindi proprio per questo stata pianicata n da subito unattivit di formazione, la quale riuscita a sopperire con successo alle mie lacune iniziali. Ritengo comunque che la presenza di lacune nella formazione di uno studente universitario sia inevitabile poich linformatica una disciplina vasta, complessa e sempre in evoluzione; normale che gran parte della formazione di un informatico avvenga sul campo, mettendo in pratica quello che ha imparato e scoprendo cose nuove. Nellambito del progetto, di grande utilit sono state le competenze di Reti e Sicurezza e di Ingegneria del Software che ho acquisito durante gli studi. Grazie alle nozioni apprese nel corso di Reti e Sicurezza, ho potuto ridurre la dicolt nello studio dello standard DICOM poich le conoscenze in mio possesso mi hanno permesso di comprendere rapidamente i punti fondamentali. Lesame di Ingegneria del Software stato importantissimo, in quanto, pur essendo un corso di laurea, rispecchia al meglio le caratteristiche di unattivit di sviluppo software svolta allinterno di una realt aziendale. Il periodo impiegato per concludere il mio stage in Aqrate, si rilevato al di sopra delle aspettative per quanto riguarda le conoscenze apprese. Lo stage mi ha permesso di: esaminare il modo di lavorare allinterno di Aqrate; studiare lo standard DICOM su documenti uciali, aspetto da non sottovalutare considerando la complessit con cui concetti semplici vengono esplicati; aumentare la mia formazione nelle tecnologie Microsoft; ranare le conoscenze che avevo del linguaggio di programmazione C#; scegliere autonomamente gli aspetti pi signicativi da monitorare; implementare unapplicazione, valutando problematiche e punti di forza.
56
4.3
Consuntivo
Lo stage terminato positivamente in quanto tutti gli obiettivi pressati sono stati raggiunti secondo i tempi e le modalit stabilite. Si pu aermare ci, constatando che: tutti i requisiti, obbligatori, desiderabili ed opzionali, sono stati sviluppati e portati a termine; la scelta del ciclo di vita si dimostrata adatta al tipo di progetto da realizzare; si dispone di una versione demo di un PACS; lazienda, in particolare il tutor, si sono dimostrati molto soddisfatti.
Lattivit di stage nel suo complesso stata portata a termine nei tempi prestabiliti, a fronte comunque di alcune discrepanze rispetto a quanto inizialmente perventivato. In particolare le prime tre settimane di stage si sono svolte senza alcun tipo di problema, grazie ad una attivit in prevalenza dedicata allo studio del dominio applicativo e delle tecnologie/strumenti da utilizzare. Dalla quarta settimana no alla sesta settimana era stato pianicato lo sviluppo delle classi C-Echo e C-Store ma grazie alla facilit di comprensione della libreria ClearCanvas ne sono state utilizzate solo due. Il tempo risparmiato della sesta settimana stato riusato per implementare una componente graca, sviluppata tramite la libreria WPF, per il PACS Server. Le settimane successive ci che stato svolto ha seguito le linee guida descritte nel piano di lavoro.
57
Figura 4.1: Diagramma di Gantt relativo al piano di lavoro a consuntivo.
58
4.4
Lesperienza in Aqrate S.r.l.
Trattandosi della mia prima esperienza lavorativa nel campo informatico, non ho termini di paragone per valutare Aqrate. Ci nonostante, la mia permanenza allinterno dellazienda da ritenersi molto positiva. possibile sintetizzare tutto ci che riguarda il mio periodo di stage in Aqrate nei punti seguenti: mi stata data la possibilit di valutare criticamente lattuale situazione aziendale; mi stata fatta una panoramica del mercato nel settore ICT; ho potuto capire quanto sia dicile creare e mantenere un rapporto procuo e duraturo con i clienti. Grazie al mio tutor, Nicola Cinel, ho avuto n da subito il suo appoggio, la sua disponibilit, la possibilit di organizzare il mio lavoro e di accedere a tutte le informazioni necessarie per proseguire lo stage, che ha contribuito tantissimo per la realizzazione del lavoro pianicato. Questo mi ha permesso di lavorare velocemente, riuscendo a completare lo stage nei tempi previsti e in maniera totalmente positiva. Il progetto in particolare mi ha permesso di scoprire e di utilizzare con successo tutta una serie di tecnologie che non conoscevo, aumentando notevolmente la mia esperienza e il mio bagaglio di conoscenza. Tutto questo stato un banco di prova importante che mi ha permesso di unire le mie capacit alle nozioni acquisite in questi anni di studio per la risoluzione di un problema completamente nuovo. Lambiente di lavoro in cui mi sono trovato ha contribuito molto alla realizzazione di questo progetto. Oltre agli impiegati del azienda, sempre amichevoli e disponibili per diversi confronti, ho potuto conoscere altri stagisti con cui ho scambiato opinioni. Lesperienza stata completamente positiva e mi ha permesso di crescere sia professionalmente che come persona, ed avere pi ducia nelle proprie forze e capacit.
Glossario
A
Accoppiamento: propriet esterna del software che indica quanto le componenti dipendono strettamente luna dallaltra. Si punter a ottenere un basso accoppiamento poich, in questo caso, eventuali modiche a una componente avranno poche ripercussioni sulle altre con cui instaurata una relazione di dipendenza. AJAX: una tecnica di sviluppo per la realizzazione di applicazioni web interattive. Lo sviluppo di applicazioni HTML con AJAX si basa su uno scambio di dati in background fra web browser e server, che consente laggiornamento dinamico di una pagina web senza esplicito ricaricamento da parte dellutente. API: uninterfaccia che abilita e/o facilita literazione tra software dierenti allo stesso modo in cui la user interface facilita la comunicazione tra umani e computer.
C
Complessit ciclomatica: una metrica che serve per denire il numero di cammini linearmente indipendenti di una sezione di codice sorgente.
D
DBMS: un sistema software progettato per consentire la creazione e manipolazione eciente di database (ovvero di collezioni di dati strutturati) solitamente da parte di pi utenti. 59
GLOSSARIO
60
DirectX: una collezione di API[g] per gestire attivit legate alla multimedialit, soprattutto game programming e video, sulle piattaforme Microsoft.
F
Framework: struttura di supporto su cui un software pu essere organizzato e progettato. Generalmente presenta delle librerie utilizzabili in uno o pi linguaggi di programmazione assieme a degli strumenti per lo sviluppo del software.
H
Handler: un gestore di eventi che cerca di intercettare gli eventi che possono accadere su un determinato oggetto.
I
Intranet: una rete locale (LAN), o un raggruppamento di reti locali, usata allinterno di una organizzazione per facilitare la comunicazione e laccesso allinformazione, che pu essere ad accesso ristretto.
J
JPEG: lacronimo di Joint Photographic Experts Group, un comitato ISO/CCITT che ha denito il primo standard internazionale di compressione per immagini a tono continuo, sia a livelli di grigio che a colori. un formato aperto e ad implementazione gratuita. JPEG specica solamente come una immagine pu essere trasformata in uno stream di byte, ma non come questo pu essere incapsulato in supporti di memorizzazione. JPEG2000: uno standard di compressione immagini basato sulla trasformazione wavelet discreta. Cos come il celebre formato JPEG, anche JPEG 2000 stato creato dal Joint Photographic Experts Group, ed denito dallo standard ISO/IEC 15444-1.
GLOSSARIO
61
N
NAS: un dispositivo collegato ad una rete di computer la cui funzione quella di condividere tra gli utenti della rete una Area di storage(vedi SAN[g] ).
O
Open source: indica software i cui autori (pi precisamente i detentori dei diritti) ne permettono, anzi ne favoriscono il libero studio e lapporto di modiche da parte di altri programmatori indipendenti. Questo realizzato mediante lapplicazione di apposite licenze duso. La collaborazione di pi parti permette al prodotto nale di raggiungere una complessit maggiore di quanto potrebbe ottenere un singolo gruppo di lavoro. Lopen source ha tratto grande benecio da Internet perch esso permette a programmatori geogracamente distanti di coordinarsi e lavorare allo stesso progetto.
P
PDF: formato di le basato su un linguaggio di descrizione di pagina sviluppato da Adobe Systems nel 1993 per rappresentare documenti in modo indipendente dallhardware e dal software utilizzati per generarli o per visualizzarli. Un le
PDF pu descrivere documenti che contengono testo e/o immagini in qualsiasi risoluzione. un formato aperto.
R
RAID: un sistema informatico che usa un gruppo di dischi rigidi per condividere o replicare le informazioni. I beneci del RAID sono di aumentare lintegrit dei dati, la tolleranza ai guasti e le prestazioni, rispetto alluso di un disco singolo. RAM: una tipologia di memoria informatica caratterizzata dal permettere laccesso diretto a qualunque indirizzo di memoria con lo stesso tempo di accesso.
GLOSSARIO
62
S
SAN: una rete o parte di una rete ad alta velocit (generalmente Gigabit/sec) costituita esclusivamente da dispositivi di memorizzazione di massa, in alcuni casi anche di tipologie e tecnologie dierenti. Il suo scopo quello di rendere tali risorse di immagazzinamento (storage) disponibili per qualsiasi computer (generalmente application e DDBB server) connesso ad essa. Screenshot: il risultato della cattura istantanea di ci che visualizzato sul monitor del computer. Shareware: una tipologia di licenza software molto popolare sin dai primi anni novanta. Il software sotto tale licenza pu essere liberamente ridistribuito, e pu essere utilizzato per un periodo di tempo di prova variabile. Scaduti questi termini, per continuare ad utilizzare il software necessario registrarlo presso la casa produttrice, pagandone limporto. Allavvio dellapplicazione shareware generalmente una nestra informa lutente su come eettuare la registrazione e sulle condizioni di utilizzo. Socket: si indica unastrazione software progettata per poter utilizzare delle API[g] standard e condivise per la trasmissione e la ricezione di dati attraverso una rete oppure come meccanismo di IPC. il punto in cui il codice applicativo di un processo accede al canale di comunicazione per mezzo di una porta, ottenendo una comunicazione tra processi che lavorano su due macchine sicamente separate. Dal punto di vista di un programmatore un socket un particolare oggetto sul quale leggere e scrivere i dati da trasmettere o ricevere.
T
Thread: un singolo usso sequenziale di istruzioni allinterno di un programma.
GLOSSARIO
63
X
XML: un linguaggio di marcatura che associa alcune propriet dellXML con le caratteristiche dellHTML, un le XHTML , sostanzialmente, una pagina HTML scritta in conformit con lo standard XML. Il linguaggio prevede un uso pi restrittivo dei tag HTML sia in termini di validit che in termini di sintassi per descrivere solo la struttura logica della pagina, mentre il layout e la resa graca sono imposti dai fogli di stile a cascata (Cascading Style Sheets, CSS).
Bibliograa
Questi sono stati i miei riferimetni bibliograci:
[1] Aqrate S.r.l., sito web aziendale, http://www.aqrate.net/
[2] Sito uciale dello Standard DICOM, http://medical.nema.org
[3] Sito della libreria JDT, http://wiki.trispark.com/display/jdt/
[4] Sito della libreria dcm4che, http://sourceforge.net/projects/dcm4che/
[5] Sito della libreria Dicom#, http://sourceforge.net/projects/dicom-cs/
[6] Sito della libreria ClearCanvas, http://www.clearcanvas.ca/
[7] .NET Framework, http://en.wikipedia.org/wiki/.NET_Framework
[8] LINQ, http://msdn.microsoft.com/it-it/library/bb386976.aspx
[9] WPF, http://msdn.microsoft.com/en-us/library/ms754130.aspx
64
Ringraziamenti
Ringrazio il prof. Tullio Vardanega per la disponibilit nel seguire lo sviluppo del progetto di stage e per i consigli che mi hanno agevolato a scrivere il presente documento. Ringrazio inoltre Mirco Girotto e Nicola Cinel, tutor aziendale, che hanno seguito costantemente il mio lavoro e con i quali sono stato a stretto contatto durante lo stage. Ringrazio inne tutti i dipendenti di Aqrate che hanno reso i miei due mesi in azienda piacevoli e stimolanti.
65

Tesi PACS

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tesi PACS

Caricato da

Copyright:

Formati disponibili

UNIVERSIT DEGLI STUDI DI PADOVA

Facolt di Scienze MM. FF. NN.

Implementazione di una versione demo di un PACS

Anno Accademico 2010/2011

3 Lo stage 3.1 La formazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1.1 3.2 Standard DICOM . . . . . . . . . . . . . . . . . . . . . . . . . .

Analisi dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2.1 3.2.2 Requisiti Software . . . . . . . . . . . . . . . . . . . . . . . . . . Casi duso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Elenco delle gure

3.7 3.8 3.9

Elenco delle tabelle

Figura 1.1: Logo dellazienda. 1

CAPITOLO 1. DOMINIO APPLICATIVO

CAPITOLO 1. DOMINIO APPLICATIVO

Windows Azure Platform

CAPITOLO 1. DOMINIO APPLICATIVO

Figura 1.2: Infrastruttura del framework .NET

CAPITOLO 1. DOMINIO APPLICATIVO

CAPITOLO 1. DOMINIO APPLICATIVO

CAPITOLO 1. DOMINIO APPLICATIVO

Visual Studio 2010

SQL Server 2008

CAPITOLO 1. DOMINIO APPLICATIVO

CAPITOLO 1. DOMINIO APPLICATIVO

Figura 1.3: Aqrate Vector

CAPITOLO 1. DOMINIO APPLICATIVO

CAPITOLO 1. DOMINIO APPLICATIVO

Introduzione ai PACS, Picture archiving and communication system

CAPITOLO 2. STRATEGIA AZIENDALE

Figura 2.1: Immagine di una tomograa visualizzata in un sistema PACS.

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 2. STRATEGIA AZIENDALE

Figura 2.2: Architettura di un sistema PACS.

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 2. STRATEGIA AZIENDALE

Livello di probabilit Basso Medio Alto

Tabella 2.1: Probabilit di rischio

CAPITOLO 2. STRATEGIA AZIENDALE Variazione dei requisiti

CAPITOLO 2. STRATEGIA AZIENDALE

Utilizzo e sviluppi futuri

Figura 2.3: Architettura di Aqrate Vector integrato con le funzionalit DICOM

CAPITOLO 2. STRATEGIA AZIENDALE

Figura 2.4: Diagramma di Gantt relativo al piano di lavoro a preventivo.

CAPITOLO 2. STRATEGIA AZIENDALE

CAPITOLO 3. LO STAGE 3.1.1.3 Il modello di informazione

Analisi dei requisiti

Codice V.OB 1 V.OB 2

Codice Q.OB 1 Q.OB 2 Q.OB 3

Figura 3.7: Richiesta di associazione DICOM

Figura 3.8: DC1 : Diagramma delle classi della componente client

Figura 3.9: File con i dati di congurazione.

Figura 3.10: DC2 : Diagramma delle classi della componente server

Interfaccia graca del server

Figura 3.11: Screenshot[g] della prima nestra

Descrizione dei test e delle misurazioni eettuati

CAPITOLO 3. LO STAGE Soddisfacimento: totale. C-Store

Risultati delle misurazioni

Tabella 3.4: Risultati delle misurazioni

CAPITOLO 4. VALUTAZIONE RETROSPETTIVA

Conoscenze pregresse ed acquisite

CAPITOLO 4. VALUTAZIONE RETROSPETTIVA