DICOM gestión imágenes

Desarrollo de aplicaciones DICOM para la gestion
de imagenes biomedicas
Fernando Ballesteros Herranz
Octubre 2003
En los momentos de crisis, s

olo la imaginaci
on es m
as importante que el
conocimiento
(Albert Einstein)
Lo u
nico que podemos decidir es que hacer con el tiempo que se nos ha dado
(Gandalf)
Al final todo es pasajero, incluso la oscuridad se acaba para dar paso a un nuevo
da, y cuando el sol brilla, brilla m
as radiante a
un
(SamSagaz Gamyi)
Dedicado a mis padres Juli y Heliodoro, mi ta Encarni, mi hermana Helena y

especialmente a mi novia Araceli por todo el apoyo y la ayuda que me ha prestado
en la realizacion de este proyecto durante este largo tiempo.
Tambien lo dedico a mis compa
neros de proyecto, Ricardo, David, Marta, Ivan,
Jose, Bakali, Thomas, Wouter y Jeroen con los que tanto momentos buenos he pasado
y a un compa
nero de fatigas a lo largo de toda la carrera, Pedro Lus.
Agradecer a Carlos Platero, Roberto Gonzalez y Miguel Angel

Sanchez-Uran la
confianza depositada en m y la gua que han sido para m en la realizacion de este
proyecto y la posibilidad que me han dado de poder aprender.
Resumen
El estandar DICOM (Digital Imaging and Communications in Medicine) nacio en

el a
no 1993, a partir de un redise
nado completo de la publicacion normalizada No
33-1988 de ACR-NEMA, y pertenece al campo de la informatica medica, por lo que,
en principio esta norma se solapa con otras de este campo.
El estandar DICOM 3.0 permite la transmision, tratamiento e impresion de archivos
DICOM, que son imagenes biomedicas con un informe cada uno del estudio realizado.
Se ha realizado una aplicacion basandonos en el estandar, que permita compartir
archivos en un entorno distribuido; dicho de otra manera, una aplicacion que permita
a los clientes visualizar, mandar y recibir los archivos contenidos de un servidor.
El presente trabajo, describe un sistema multiplataforma desarrollado para el
manejo, procesamiento y auditora de Imagenes de Diagnostico Medico a traves de
redes (Intra o Internet). El sistema esta basado en un dise
no Cliente/Servidor orientado a objetos, para el cual se utilizo como lenguaje de programacion JAVA, y se
realizo de acuerdo a la norma DICOM 3.0.
Para la realizacion de la aplicacion se ha trabajado con libreras JDT (Java Dicom
Toolkit), con las libreras JDK 1.4.1., en el entorno JBuilder Enterprise 7. Ha sido
desarrollada enteramente en JAVA y puede ser utilizable en cualquier sistema operativo.
Como parte del proyecto fin de carrera, tambien se han realizado las tareas de
administracion de sistemas (Windows NT, 2000 y Linux) y mantenimiento del servidor
Web Apache (www.elai.upm.es) del departamento.
Abstract
The standard DICOM (Digital Imaging and Communications in Medicine) was

born in the year 1993, from complete re-designed of the normalized publication No
33-1988 of ACR-NEMA, and it belongs to the field of the medical computer science,
for what, at first this norm lapel with others of this field.
The standard DICOM 3.0 allows the transmission, treatment and impression of
files DICOM, which are biomedical images with a report each of the realized study.
An application has been realized basing on the standard, which allows to share
files in a distributed environment; said otherwise, an application that it allows the
clients to visualize, to order and to receive the files contained of a servant.
The present work, a system describes multiplatform developed for the managing,
processing and audit of Images of Medical Diagnosis across nets (Intra or Internet).
The system is based on a design Cliente/Servidor orientated to objects, for which was
used as language of programming JAVA, and were realized in agreement to the norm
DICOM 3.0.
For the accomplishment of the application one has worked with libraries JDT (Java
Dicom Toolkit), with the libraries JDK 1.4.1., in the environment JBuilder Enterprise
7. It has been developed entirely in JAVA and can be usable in any operative system.
As a part of my project, I have done system administration tasks (Windows
NT, 2000 and Linux) and the maintenance of the department Apache Web server
(www.elai.upm.es).
Indice general
1. Introducci
on
1.1. Marco del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3. Sumario del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . .
2. El Estado de la t
ecnica
2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Librera de Imagenes Medicas . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Libreras de Imagenes Medicas . . . . . . . . . . . . . . . . . .
2.2.2. Arquitecturas para libreras digitales de imagenes . . . . . . .
12
2.3. Estandar DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
2.3.2. Historia de DICOM . . . . . . . . . . . . . . . . . . . . . . . .
17
2.3.3. Procesamiento Distribuido . . . . . . . . . . . . . . . . . . . .
19
2.3.4. Conceptos generales de DICOM . . . . . . . . . . . . . . . . .
21
2.3.5. Conceptos de DICOM Network . . . . . . . . . . . . . . . . .
33
2.3.6. Clases de Servicio soportados . . . . . . . . . . . . . . . . . .
37
INDICE GENERAL
2.3.7. Conectividad . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
2.3.8. Estandar DICOM . . . . . . . . . . . . . . . . . . . . . . . . .
43
2.3.9. Instancias SOP de imagenes DICOM . . . . . . . . . . . . . .
46
2.3.10. Modelo de informacion de las imagenes . . . . . . . . . . . . .
46
2.3.11. Instancias imagen SOP . . . . . . . . . . . . . . . . . . . . . .
49
2.3.12. Relaciones e indentificacion . . . . . . . . . . . . . . . . . . .
50
2.3.13. Clasificacion de los datos de imagen . . . . . . . . . . . . . . .
53
2.3.14. Extension de la informacion . . . . . . . . . . . . . . . . . . .
58
2.3.15. Tipos de imagenes . . . . . . . . . . . . . . . . . . . . . . . .
59
2.3.16. Procesando imagen . . . . . . . . . . . . . . . . . . . . . . . .
63
2.3.17. Aplicacion de los Datos de las Imagenes . . . . . . . . . . . .
72
2.3.18. El futuro de DICOM . . . . . . . . . . . . . . . . . . . . . . .
74
2.4. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
3. Libreras DCMTK de Offis
ii
77
3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
3.2. Estandarizacion de la Comunicacion de Imagenes Medicas . . . . . .
77
3.3. Descripcion de DICOM seg

un Offis . . . . . . . . . . . . . . . . . . .
78
3.3.1. Estructura de los datos en el estandar DICOM . . . . . . . . .
79
3.3.2. Servicios de Red . . . . . . . . . . . . . . . . . . . . . . . . .
79
3.3.3. Intercambio de medios de comunicacion . . . . . . . . . . . . .
79
3.3.4. Declaracion de Conformidad . . . . . . . . . . . . . . . . . . .
80
3.4. Libreras DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
r
GVA-ELAI-UPM PFC0075-2003
INDICE GENERAL
3.4.1. Instalacion de libreras . . . . . . . . . . . . . . . . . . . . . .
81
3.4.2. Dcmnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
3.4.3. Dcmjpeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
3.4.4. DicomScope . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
3.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4. Programaci
on en JAVA
91
4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
4.2. Instalacion de la JVM . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.3. El compilador de Java . . . . . . . . . . . . . . . . . . . . . . . . . .
94
4.4. Variables y tipos de datos . . . . . . . . . . . . . . . . . . . . . . . .
95
4.4.1. Comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . .
95
4.4.2. Identificadores . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
4.4.3. Palabras clave reservadas . . . . . . . . . . . . . . . . . . . . .
96
4.4.4. Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
4.4.5. Matrices o vectores . . . . . . . . . . . . . . . . . . . . . . . .
98
4.5. Operadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
4.5.1. Operadores aritmeticos . . . . . . . . . . . . . . . . . . . . . .
99
4.5.2. Operadores de asignacion
99
. . . . . . . . . . . . . . . . . . . .
4.5.3. Operadores a nivel de bit . . . . . . . . . . . . . . . . . . . . . 100

4.5.4. Operadores relacionales . . . . . . . . . . . . . . . . . . . . . . 100
4.5.5. Operadores logicos booleanos . . . . . . . . . . . . . . . . . . 101
4.6. Control del flujo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
r
iii
INDICE GENERAL
4.6.1. Instruccion condicional if-else . . . . . . . . . . . . . . . . . . 101

4.6.2. Instruccion condicional switch . . . . . . . . . . . . . . . . . . 102
4.6.3. Bucles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.6.4. Otras instrucciones . . . . . . . . . . . . . . . . . . . . . . . . 104
4.7. Clases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.7.1. Referencias a objetos . . . . . . . . . . . . . . . . . . . . . . . 106
4.7.2. Variables de una instancia . . . . . . . . . . . . . . . . . . . . 106
4.7.3. Operador new . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.7.4. Operador(.) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.7.5. Declaracion de metodos . . . . . . . . . . . . . . . . . . . . . 107
4.7.6. Llamada a metodos . . . . . . . . . . . . . . . . . . . . . . . . 108
4.7.7. Constructores . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.7.8. Sobrecarga de metodos . . . . . . . . . . . . . . . . . . . . . . 109
4.7.9. Operador this . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
4.7.10. Herencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.8. Paquetes e interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.8.1. Paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.8.2. Proteccion de accesos . . . . . . . . . . . . . . . . . . . . . . . 113
4.8.3. Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.9. Gestion de cadenas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.9.1. Constructores . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.9.2. Metodos de String . . . . . . . . . . . . . . . . . . . . . . . . 114
iv
r
INDICE GENERAL
4.9.3. Conversion a String . . . . . . . . . . . . . . . . . . . . . . . . 115

4.10. Gestion de excepciones . . . . . . . . . . . . . . . . . . . . . . . . . . 116
4.10.1. try y catch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.10.2. throw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.10.3. finally . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.10.4. Gestion incompleta de las excepciones . . . . . . . . . . . . . 118
4.11. Hilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
4.11.1. Thread . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.11.2. Runnable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
4.11.3. Prioridades de los hilos . . . . . . . . . . . . . . . . . . . . . . 121
4.11.4. Sincronizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.11.5. Comunicacion entre hilos . . . . . . . . . . . . . . . . . . . . . 122
4.11.6. Metodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.12. Utilidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.12.1. Envolturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.12.2. Enumeraciones . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.12.3. Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.12.4. System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.12.5. Date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
4.13. Entrada/Salida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.13.1. File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.13.2. InputStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
r
INDICE GENERAL
4.13.3. OutputStream . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4.13.4. Flujo de archivo . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.13.5. Flujos filtrados . . . . . . . . . . . . . . . . . . . . . . . . . . 132
4.13.6. SequenceInputStream . . . . . . . . . . . . . . . . . . . . . . . 133
4.13.7. Ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.14. Trabajo en Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.14.1. InetAddress . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.14.2. Datagramas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.14.3. Conectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.14.4. Conexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.15. Interfaces Graficas de Usuario . . . . . . . . . . . . . . . . . . . . . . 140
4.15.1. Componentes AWT . . . . . . . . . . . . . . . . . . . . . . . . 140
4.15.2. Organizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.15.3. Componentes de men
u . . . . . . . . . . . . . . . . . . . . . . 143
4.15.4. Componentes Swing . . . . . . . . . . . . . . . . . . . . . . . 143
4.15.5. Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.16. Encriptacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.16.1. Arquitectura Criptografica de Java (JCA) . . . . . . . . . . . 145
4.16.2. Extension criptografica de Java (JCE) . . . . . . . . . . . . . 148
4.17. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5. Estudio de libreras JDT
151
5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
vi
r
INDICE GENERAL
5.2. Terminologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

5.3. Datasets o conjunto de datos . . . . . . . . . . . . . . . . . . . . . . . 152
5.3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
5.3.2. Manipulacion de los atributos . . . . . . . . . . . . . . . . . . 152
5.3.3. Entrada/Salida de los datasets DICOM . . . . . . . . . . . . . 155
5.3.4. Metodos u
tiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
5.4. Depositos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.4.1. Clase DDict: deposito de atributos . . . . . . . . . . . . . . . 159
5.4.2. Clase UID: depositos UID . . . . . . . . . . . . . . . . . . . . 160
5.5. Imagenes en JDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.5.1. La clase DicomImage . . . . . . . . . . . . . . . . . . . . . . . 161
5.6. Gua para usuarios de JDT . . . . . . . . . . . . . . . . . . . . . . . . 161
5.6.1. Insertar datos que no son de imagen . . . . . . . . . . . . . . 161
5.6.2. Insertar datos de imagen con los metodos de DicomImage . . . 162
5.6.3. Insertando los datos de imagen con ImageProducer . . . . . . 162
5.6.4. Compresion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.7. Creacion de una conexion . . . . . . . . . . . . . . . . . . . . . . . . 165
5.7.1. Iniciador de la asociacion . . . . . . . . . . . . . . . . . . . . . 165
5.7.2. Receptor de la asociacion . . . . . . . . . . . . . . . . . . . . . 167
5.8. Estructura de JDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.8.1. Arbol
de clases . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.8.2. Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
r
vii
INDICE GENERAL
5.9. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
6. Desarrollo de aplicaci
on
177
6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177

6.2. Uso de SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6.2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
6.2.2. Instalacion en Windows 98 . . . . . . . . . . . . . . . . . . . . 178
6.2.3. Instalacion en Windows 2000 . . . . . . . . . . . . . . . . . . 181
6.2.4. Utilidades del SDK . . . . . . . . . . . . . . . . . . . . . . . . 182
6.3. Uso de TextPad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.3.2. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . 186
6.3.3. Uso con Java . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
6.4. Uso de JBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.4.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.4.2. Instalacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
6.4.3. JDK y JBuilder . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.4.4. Creacion de aplicaciones en JBuilder . . . . . . . . . . . . . . 190
6.5. Instalacion de JDT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.5.1. Instalacion en Windows 95/98 . . . . . . . . . . . . . . . . . . 212
6.5.2. Instalacion en Windows NT/2000/XP
. . . . . . . . . . . . . 213
6.5.3. Incluir JDT en JBuilder . . . . . . . . . . . . . . . . . . . . . 213

6.6. Implementacion de Servidor DICOM . . . . . . . . . . . . . . . . . . 215
viii
r
INDICE GENERAL
6.6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

6.6.2. Listar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
6.6.3. Enviar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.6.4. Guardar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
6.6.5. Query/Retrieve . . . . . . . . . . . . . . . . . . . . . . . . . . 219
6.6.6. Editar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
6.6.7. Encriptacion/Desencriptacion . . . . . . . . . . . . . . . . . . 221
6.7. Implementacion de Cliente DICOM . . . . . . . . . . . . . . . . . . . 222
6.7.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
6.7.2. Panel Cliente-Servidor . . . . . . . . . . . . . . . . . . . . . . 223
6.7.3. Panel VisorDicom . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.7.4. Panel Procesamiento . . . . . . . . . . . . . . . . . . . . . . . 241
6.7.5. Panel Crear DICOM . . . . . . . . . . . . . . . . . . . . . . . 245
6.7.6. Distribucion e instalacion de la aplicacion . . . . . . . . . . . 253
6.8. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
A. Administraci
on de sistemas
257
A.1. Introduccion a Windows NT y 2000 . . . . . . . . . . . . . . . . . . . 257

A.1.1. Presentacion del sistema operativo NT . . . . . . . . . . . . . 257
A.1.2. Sistemas de archivos . . . . . . . . . . . . . . . . . . . . . . . 258
A.1.3. El interfaz de usuario de NT . . . . . . . . . . . . . . . . . . . 259
A.2. La red Microsoft Windows . . . . . . . . . . . . . . . . . . . . . . . . 260
A.2.1. Los grupos de trabajo . . . . . . . . . . . . . . . . . . . . . . 260
r
ix
INDICE GENERAL
A.2.2. Los dominios NT . . . . . . . . . . . . . . . . . . . . . . . . . 261

A.2.3. Uso de los dominios de NT . . . . . . . . . . . . . . . . . . . . 261
A.2.4. Elementos de un dominio . . . . . . . . . . . . . . . . . . . . . 262
A.2.5. El sistema de recursos de red . . . . . . . . . . . . . . . . . . 263
A.2.6. Inicio de sesion en un grupo de trabajo . . . . . . . . . . . . . 266
A.2.7. Inicio de sesion en un dominio . . . . . . . . . . . . . . . . . . 267
A.2.8. Los controladores de dominio . . . . . . . . . . . . . . . . . . 268
A.2.9. Diferencias entre NT Workstation y NT Server . . . . . . . . . 268
A.3. El Administrador de usuarios . . . . . . . . . . . . . . . . . . . . . . 269
A.3.1. Creacion y modificacion de usuarios en el dominio . . . . . . . 270
A.3.2. Creacion de grupos . . . . . . . . . . . . . . . . . . . . . . . . 275
A.4. Permisos y seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
A.4.1. Administracion del plan de cuentas . . . . . . . . . . . . . . . 277
A.4.2. Administracion del plan de derechos de usuarios . . . . . . . . 278
A.5. Permisos y seguridad en NT . . . . . . . . . . . . . . . . . . . . . . . 279
A.5.1. Los perfiles de usuario en NT . . . . . . . . . . . . . . . . . . 279
A.5.2. Perfiles de usuario frente a perfiles obligatorios . . . . . . . . . 280
A.5.3. Tipos de perfiles de usuarios . . . . . . . . . . . . . . . . . . . 280
A.5.4. El directorio de perfiles en NT . . . . . . . . . . . . . . . . . . 281
A.5.5. Creacion de un perfil en NT 4.0 . . . . . . . . . . . . . . . . . 282
A.6. El editor de directivas POLEDIT.EXE . . . . . . . . . . . . . . . . . 283
A.6.1. Funcionamiento de las directivas . . . . . . . . . . . . . . . . . 284
r
INDICE GENERAL
A.6.2. Creacion de las directivas del sistema para un dominio . . . . 284

A.6.3. Modo de funcionamiento de las directivas . . . . . . . . . . . . 285
A.6.4. Directivas para sistemas, usuarios y grupos . . . . . . . . . . . 286
A.7. El protocolo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
A.7.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
A.7.2. El protocolo TCP/IP frente a otros protocolos . . . . . . . . . 287
A.7.3. Elementos del protocolo TCP/IP . . . . . . . . . . . . . . . . 288
A.7.4. El sistema de direcciones del protocolo IP . . . . . . . . . . . 289
A.7.5. El mecanismo de difusion (broadcast) en el protocolo IP . . . 291
A.7.6. Implementacion del protocolo TCP/IP en NT . . . . . . . . . 291
A.7.7. Configuracion del protocolo TCP/IP en NT . . . . . . . . . . 291
r
xi
Indice de figuras
2.1. Clasificacion de las imagenes medicas . . . . . . . . . . . . . . . . . .
2.2. Arquitectura de una libreria digital de imagenes . . . . . . . . . . . .
12
2.3. Modelo de protocolo de comunicaciones DICOM . . . . . . . . . . . .
19
2.4. Procesamiento distribuido . . . . . . . . . . . . . . . . . . . . . . . .
19
2.5. Transmision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
2.6. Modelo de un proceso distribuido . . . . . . . . . . . . . . . . . . . .
21
2.7. Clases de Servicio de DICOM . . . . . . . . . . . . . . . . . . . . . .
22
2.8. Relacion entre los IODs y los atributos . . . . . . . . . . . . . . . . .
24
2.9. Ejemplo de un IOD de imagen compuesto . . . . . . . . . . . . . . .
25
2.10. Ejemplo de los atributos del modulo Paciente . . . . . . . . . . . . .
26
2.11. Estructura del mensaje DICOM . . . . . . . . . . . . . . . . . . . . .
28
2.12. Estructura del Data Element . . . . . . . . . . . . . . . . . . . . . . .
29
2.13. Vision general de la codificacion y decodificacion de las instacias SOP
32
2.14. DICOM y el intercambio network . . . . . . . . . . . . . . . . . . .
33
2.15. Ejemplos de Contextos de Presentacion . . . . . . . . . . . . . . . . .
35
2.16. Capas OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
xiii
INDICE DE FIGURAS
2.17. Conexion TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
2.18. Definicion de objeto compartido con Media Service Class . . . . . . .
40
2.19. Conformance Statement con Perfil de Sistema . . . . . . . . . . . . .
41
2.20. Conformance Statement con Perfil de Aplicacion . . . . . . . . . . . .
43
2.21. Relaciones entre las Partes del estandar DICOM. . . . . . . . . . . .
45
2.22. Modelo de informacion . . . . . . . . . . . . . . . . . . . . . . . . . .
47
2.23. Ejemplo de mapeado de una imagen CT . . . . . . . . . . . . . . . .
49
2.24. Modelo de informacion de una imagen compuesta DICOM . . . . . .
51
2.25. Clasificacion de la informacion de la imagen . . . . . . . . . . . . . .
54
2.26. Juego basico de atributos de las instancias de imagen SOP . . . . . .
60
2.27. Pasos del proceso y tipos de datos de la imagen . . . . . . . . . . . .
64
2.28. Muestreo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
2.29. Datos de pixel con la conversion de los valores del pixel . . . . . . . .
66
2.30. Pasos del proceso de la presentacion de una imagen . . . . . . . . . .
67
2.31. Decodificacion de los Datos de Pixel . . . . . . . . . . . . . . . . . . .
69
2.32. Modalidad dependiendo de la escala y la conversion . . . . . . . . . .
70
2.33. Conversion a escala de grises . . . . . . . . . . . . . . . . . . . . . . .
71
2.34. Ciclo de vida de la informacion de una Image SOP Instance . . . . .
72
3.1. Libreras DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
3.2. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
86
3.3. Archivo de configuracion de DicomScope . . . . . . . . . . . . . . . .
87
3.4. Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
88
xiv
r
INDICE DE FIGURAS
3.5. Print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
3.6. Process Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
90
4.1. Evolucion de Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92
4.2. Bibliotecas de clases de Java . . . . . . . . . . . . . . . . . . . . . . .
93
4.3. Compilacion y ejecucion . . . . . . . . . . . . . . . . . . . . . . . . .
95
4.4. Palabras clave de Java . . . . . . . . . . . . . . . . . . . . . . . . . .
96
4.5. Operaderes relacionales . . . . . . . . . . . . . . . . . . . . . . . . . . 101

4.6. Operaderes logicos booleanos
. . . . . . . . . . . . . . . . . . . . . . 101
4.7. Propagacion de excepciones . . . . . . . . . . . . . . . . . . . . . . . 116

4.8. Flujos estandar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4.9. Jerarqua de componentes del AWT . . . . . . . . . . . . . . . . . . . 142
4.10. Componentes Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.11. Layout de Swing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.1. Conversion entre tipo Java y tipo DICOM . . . . . . . . . . . . . . . 152
5.2. Conversion de tipo DICOM a tipo Java . . . . . . . . . . . . . . . . . 175
6.1. API de SDK 1.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
6.2. Compilacion con SDK . . . . . . . . . . . . . . . . . . . . . . . . . . 183
6.3. Api generada con Javadocs . . . . . . . . . . . . . . . . . . . . . . . . 184
6.4. Entorno de trabajo de TextPad 4.7.0 . . . . . . . . . . . . . . . . . . 187
6.5. Configuracion de JDK . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.6. Designacion de nuevas JDK . . . . . . . . . . . . . . . . . . . . . . . 190
r
xv
INDICE DE FIGURAS
6.7. Asistente para proyectos . . . . . . . . . . . . . . . . . . . . . . . . . 191

6.8. Galera de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
6.9. Asistente para aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . 193
6.10. Vista en dise
no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
6.11. contentPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
6.12. Editor de texto ejecutado
. . . . . . . . . . . . . . . . . . . . . . . . 196
6.13. Men
u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
6.14. Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
6.15. actionPerformed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
6.16. jMenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
6.17. Bibliotecas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.18. Configurar bibliotecas
. . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.19. Listado en Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

6.20. El servidor enva objeto Dicom . . . . . . . . . . . . . . . . . . . . . 217
6.21. El servidor recibe objeto Dicom . . . . . . . . . . . . . . . . . . . . . 218
6.22. Panel Ciente-Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
6.23. Boton Base De Datos y Enviar
. . . . . . . . . . . . . . . . . . . . . 225
6.24. Boton Coger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

6.25. Boton Editar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.26. Panel Visor DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
6.27. Zoom In y Zoom Out . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
6.28. Zoom con eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
xvi
r
INDICE DE FIGURAS
6.29. Botones Siguiente y Anterior . . . . . . . . . . . . . . . . . . . . . . . 234

6.30. Boton Seguidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
6.31. Boton Guardar JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6.32. Insertar y ver datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.33. Crear campos nuevos . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.34. Nuevo campo insertado . . . . . . . . . . . . . . . . . . . . . . . . . . 241
6.35. Panel Procesamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 242
6.36. Boton para a
nadir archivos al proyecto . . . . . . . . . . . . . . . . . 244
6.37. Boton para abrir imagen a procesar . . . . . . . . . . . . . . . . . . . 244
6.38. Boton para procesar imagen . . . . . . . . . . . . . . . . . . . . . . . 245
6.39. Panel Crear DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.40. Imagen para crear un archivo Dicom . . . . . . . . . . . . . . . . . . 247
6.41. Datos de texto a insertar . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.42. Comprobacion de la creacion de archivo Dicom en escala de grises . . 249
6.43. Comprobacion de la creacion de archivo Dicom en RGB . . . . . . . . 250
6.44. Generacion de ejecutables . . . . . . . . . . . . . . . . . . . . . . . . 253
6.45. Creador de ejecutables . . . . . . . . . . . . . . . . . . . . . . . . . . 253
6.46. Marcas de la creacion de ejecutables . . . . . . . . . . . . . . . . . . . 254
A.1. Conectar a unidad de red . . . . . . . . . . . . . . . . . . . . . . . . . 265
A.2. Administrador de Usuarios . . . . . . . . . . . . . . . . . . . . . . . . 269
A.3. Administrador de Usuarios; usuario nuevo . . . . . . . . . . . . . . . 270
A.4. Administrador de Usuarios; usuario nuevo; grupos . . . . . . . . . . . 272
r
xvii
INDICE DE FIGURAS
A.5. Administrador de Usuarios; usuario nuevo; perfil . . . . . . . . . . . . 272

A.6. Administrador de Usuarios; usuario nuevo; horas . . . . . . . . . . . . 273
A.7. Administrador de Usuarios; usuario nuevo; iniciar de sesion . . . . . . 274
A.8. Administrador de Usuarios; usuario nuevo; cuenta . . . . . . . . . . . 274
A.9. Administrador de Usuarios; usuario nuevo; marcado . . . . . . . . . . 275
A.10.Administrador de Usuario; directivas; plan de derechos de usuarios . . 278
A.11.Panel de Control; Sistema; Perfiles de Usuario; Copiar a
. . . . . . . 282
A.12.El editor de directivas del sistema . . . . . . . . . . . . . . . . . . . . 285

A.13.El Editor de Directivas del Sistema, Equipo . . . . . . . . . . . . . . 286
A.14.Panel de control. Red . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
A.15.Panel de control. Red. Protocolos. Agregar protocolo TCP/IP . . . . 293
A.16.Protocolo TCP/IP, Direccion IP, Avanzado . . . . . . . . . . . . . . . 294
A.17.Protocolo TCP/IP, Direccion IP, Avanzadas . . . . . . . . . . . . . . 295
A.18.Protocolo TCP/IP, Enrutamiento . . . . . . . . . . . . . . . . . . . . 296
xviii
r
Captulo 1
Introducci
on
DICOM1 es un estandar en comunicacion e imagenes en medicina, que facilita el
manejo de informacion medica entre hospitales y centros de investigacion.
La gran importancia de este estandar es que da la posibilidad de interconectar
sistemas informaticos de diferentes fabricantes y hace posible la comunicacion entre
ellos; en un hospital donde los aparatos medicos son de muchas marcas diferentes
debido a la especializacion.
DICOM hace posible que los archivos medicos puedan viajar de forma segura entre
hospitales, centros de investigacion y departamentos. Luego esa informacion puede ser
vista remotamente para que los medicos puedan diagnosticar desde su casa y buscar
diferentes opiniones de otros expertos de una forma rapida y sencilla.
La creciente utilizacion de sistemas de adquisicion y tratamiento digital de imagenes
medicas ha hecho necesaria la adopcion de un estandar que posibilite el intercambio
de estas. Las imagenes medicas son muy importantes para los diagnosticos de pacientes, tratamientos terapeuticos y evaluacion de resultados. Gracias a las nuevas
tecnicas de imagenes digitales, tales como la topografa computarizada, angiografa
por sustraccion digital, resonancia magnetica y as sucesivamente, han reducido las
dosis de radiacion a los pacientes y los cortes anatomicos.
DICOM poco a poco se esta introduciendo en todo el ambito sanitario, y que sin
duda facilitara el manejo de la informacion medica.
Los objetivos del estandar son:
Lograr una interfaz com
un para todos los dispositivos de imagenes (tomografa,
1
Digital Imaging and Communications in Medicine

CAPITULO 1. INTRODUCCION
resonancia magnetica, ultrasonido, rayos x, etc.)

Intentar desligar Dicom de las instituciones que lo desarrollan para que realmente pueda ser un estandar independiente.
Dicom 3.0 debe ser aplicable a toda la esfera de las imagenes medicas, desde su
transmision hasta el tratamiento e impresion.
De momento la estandarizacion poco a poco va tomando forma:
Se define la utilizacion de protocolos OSI, para asegurar una comunicacion eficiente y que soporte una amplia variedad de tecnologas de red basadas en
normas OSI, CSMA/CD, ATM, X.25, etc. Y TCP/IP como protocolo de transporte, que es abierto y compatible con las redes que se estan instalando en los
centros sanitarios.
Los estandares de codificacion de la informacion y los datos resultantes de utilizar los Objetos de Informacion (imagenes, informes, etc.) con las Clases de
Servicio (impresion, almacenamiento, etc.), se homogeneizan.
Tecnicas de compresion normalizadas (JPEG con y sin perdidas)
Reglas de codificacion para construir una secuencia de datos para ser transmitida como un mensaje.
1.1.
Marco del proyecto
El marco del proyecto realizado es:
en primer lugar, el estudio del estandar Dicom

en segundo lugar, estudio de libreras DCMTK2
en tercer lugar, estudio de libreras JDT3
y en cuarto lugar, desarrollo de la aplicacion.
El presente trabajo ha sido realizado en etapas, la primera de las cuales consistio en

el estudio de la norma DICOM 3.0, base fundamental de este trabajo.
2
3
DICOM Toolkit
Java DICOM Toolkit
r
1.2. OBJETIVOS DEL PROYECTO
La siguiente etapa fue el estudio y prueba de las libreras DCMTK desarrolladas

en C++ y de las cuales se vieron aplicaciones como DicomScope o la conectividad
entre dos maquinas.
Luego se estudio el Toolkit de Java, y paralelamente este lenguaje de programacion
orientado a objetos.
Una vez visto que las libreras JDT son las que mas nos interesaron, se llevo a
cabo la implementacion de nuestra aplicacion.
La aplicacion que se ha creado esta desarrollada en lenguaje Java,con la herramienta JBuilder Enterprise 7 y el editor TextPad, bajo plataforma Intel y sistema
operativo Windows 2000.
Tambien se han estado haciendo labores de mantenimiento de la red del laboratorio
del Grupo de Vision Artificial(GVA) del Departamento de Electronica, Automatica
e Informatica Industrial y la web (www.elai.upm.es) del departamento.
Cabe rese
nar, que tratandose de un proyecto realizado en el ambito de la investigacion, la mejor forma ha sido escribirlo en formato LATEX.
1.2.
Objetivos del proyecto
Este proyecto trata de ser una gua completa para el estudio del estandar Dicom,
sus posibles aplicaciones y utilizacion en el futuro.
Se han estudiado dos toolkit de Dicom con el fin de ver cual sera mas u
til para el
desarrollo de una aplicacion final, en la que los principales servicios que proporciona
el estandar puedan ser operativos y utilizables para la medicina del nuevo siglo, ya
que DICOM ha tenido un importante avance en el u
ltimo a
no.
1.3.
Sumario del proyecto
Este proyecto se encuentra dividido por captulos y apendices que pretenden

mostrar los trabajos y conocimientos adquiridos durante el a
no de trabajo.
De esta forma, en el captulo 2 se desarrolla la base teorica del estandar DICOM,
y es parte fundamental para la comprension del trabajo realizado y desarrollo de las
aplicaciones, es posible que requiera mas de una lectura para entender el estandar.
r

CAPITULO 1. INTRODUCCION
En el captulo 3, se explica la instalacion y utilizacion de las libreras de C++

proporcionadas por OffisDicom, as como una peque
na aplicacion realizada con ellas,
para la transmision de objetos Dicom por la red. Tambien se describe, la utilizacion de
una aplicacion desarrollada parte en Java parte con las libreras de C++. Esta aplicacion es el DicomScope, y se explica el funcionamiento de cada parte del programa
y la transmision de estudios por red.
El 4 es una gua para aprender a programar en Java, tanto conceptos sencillos
como los mas complicados como los hilos, los sockets y la encriptacion. Este captulo
es fundamental para entender los siguientes captulos ya que el programa y las libreras
utilizadas estan desarrollas en Java.
El estudio de las libreras JDT y las funciones que implementan del estandar
Dicom estan explicadas en el captulo 5.
Finalmente en el captulo 6, se explica el camino seguido y la forma de uso del
programa desarrollado en java y utilizando las libreras JDT as como las conclusiones
finales.
El apendice A pretende ser una peque
na gua para la administracion de sistemas
Windows de Red, basada en la experiencia a lo largo del proyecto.
r
Captulo 2
El Estado de la t
ecnica
2.1.
Introducci
on
En este captulo se hace una introduccion a los conceptos y el estado actual en el

que se encuentran:
Imagenes medicas distribuidas

Estandar DICOM
La primera parte es la relativa a la distribucion de imagenes medicas donde se

vera el estado en el que se encuentran las tecnicas de distribucion de imagenes, principalmente a traves de Internet, como las libreras digitales de imagenes medicas.
En la segunda parte se van a explicar los conceptos definidos en el estandar
DICOM, partiendo de un modelo de proceso distribuido.
Finalmente, se llegara a la explicacion de los conceptos de DICOM Network, para
realizar la conectividad entre las maquinas y la explicacion de los servicios que el
estandar ofrece.

CAPITULO 2. EL ESTADO DE LA TECNICA
2.2.
Librera de Im
agenes M
edicas
[BOBA00] [TJAND99]
Los sistemas tradicionales de gestion de imagenes medicas, tales como los sistemas de visualizacion y de archivo y comunicacion, estan basados en estaciones de
trabajo especializadas y sistemas de arquitectura cerrada. La tecnologa de Internet
esta siendo explorada para la distribucion eficiente y rentable de imagenes medicas.
Las imagenes medicas son el corazon de los diagnosticos de pacientes, tratamientos
terape
uticos, planificacion quir
urgica, muestreo de enfermedades, y a largo plazo para
repetir evaluaciones de resultados. En las pasadas tres decadas, ha habido tremendos cambios con la llegada de nuevas tecnicas como la tomografa computarizada
(CT), resonancia magnetica (MRI), resonancia espectroscopica (MRS), resonancia
magnetica funcional (fMRI), angiografa por sustraccion digital (DSA), tomografa
por emision de positrones (PET), magnetic source imagin (MSI), y as sucesivamente.
Estas modalidades de imagenes digitales, que actualmente constituyen alrededor
del 30 por ciento de los analisis de imagenes medicas en los Estados Unidos, han
revolucionado la manera de adquirir imagenes de pacientes. Han proporcionado un
metodo no invasivo para ver cortes transversales anatomicos y estados fisiologicos, y
han reducido la dosis de radiacion a los pacientes y los traumas de reconocimiento. El
otro 70 por ciento de analisis de imagenes de craneo, torax, pecho, abdomen, y hueso
estan hechas en los convencionales rayos X o radiografa digital (CR). Diferentes tipos
de pelculas digitalizadoras, como los escaner, camaras de estado solido, escaner de
tambor (drum scanner) y vdeo camaras, se usan rutinariamente para convertir las
pelculas planas de rayos X en formato digital para su posterior tratamiento y archivo.
En la figura 2.1 se muestra la clasificacion de las modalidades de imagenes medicas
conforme al contenido anatomico (estructural) o fisiol
ogico (funcional) de las imagenes
generadas. Cada una de estas modalidades de imagen proporciona una funcion y
caractersticas u
nicas que no pueden ser reemplazadas por las otras modalidades. La
dimension de una imagen digital se encuentra entre 128 x 128 pixels (p.e., PET y
tomografa computarizada por emision de fotones simples SPECT de modalidades
de medicina nuclear) y 4000 x 5000 pixels (p.e., mamografa).
Estos avances en la tecnologa de la imagen van a continuar. Sin embargo, la reorganizacion y redise
no de los sistemas de sanidad esta cambiando el foco de la imagen
digital de la generacion y adquisicion de imagenes al post-tratamiento y gestion de
datos de imagen. El motivo de este cambio es para poder obtener el mayor beneficio
posible de los datos que ya existen. Los nuevos cambios principales de la proxima
decada se centraran en la recogida, archivo, indexado, comunicacion y gestion de
los datos de imagenes multimedia para una mejor rentabilidad en educacion medica,
investigacion clnica y diagnostico.
r
2.2. LIBRERIA DE IMAGENES

MEDICAS
Figura 2.1: Clasificacion de las imagenes medicas
Los FS-PACS (full-scale Picture Archiving and Communication Systems), tambien llamados en castellano sistemas de archivo y comunicacion de imagenes a gran
escala, son el metodo predominante para la gestion de informacion de imagenes en
los hospitales. Un FS-PACS consiste en una integracion de PACS, en informacion
administrativa dependiente del Servicio de Radiologa (en ingles, Radiology Information System RIS) e informacion del hospital (en ingles, Hospital Information
System HIS). Los FS-PACS de un hospital de tama
no medio (alrededor de 600-800
camas) podran requerir 1 Terabyte de datos digitales por a
no en su librera o archivo
de imagenes. Desde 1995 ha habido mas de 50 instalaciones de FS-PACS en todo el
mundo, con cientos de PACS y a
un mas mini-PACS en el funcionamiento cotidiano.
Los PACS estan dise
nados para revisiones diagnosticas por radiologos y cardiologos,
pero estos sistemas tampoco estan dise
nados para funcionar correctamente en una
distribucion de imagenes medicas, esto es, comunicando imagenes medicas y datos
relacionados a otros especialistas como medicos e investigadores. Un sistema abierto
con mecanismos omnipresentes de acceso seguros podra permitir a los usuarios utilizar completamente la funcionabilidad de la librera digital de imagenes medicas de
manera rentable. Las tecnologas de Internet y la red mundial WWW proporcionan
una plataforma ideal para el desarrollo de libreras de im
agenes medicas.
2.2.1.
Libreras de Im
agenes M
edicas
Cuando se dise
na, gestiona y utiliza una librera digital de imagenes medicas en
Internet hay que tener en cuenta una serie de puntos que se presentan a continuacion.
r

Datos centralizados o datos distribuidos

La decision de adoptar una base de datos centralizada frente a una arquitectura
de objetos distribuidos esta basada en varias consideraciones, como el tama
no de la
base de datos, datos localizados o distribuidos, el n
umero de usuarios, y los servicios
requeridos.
La arquitectura de los PACS estandar esta basada en el modelo de base de datos
centralizada, y esto tambien se aplica a otros sistemas integrados de sanidad, tales
como el Registro Computerizado de Pacientes (en ingles, computerized patient record
CPR) y el HIS. Incluso los mas recientes desarrollos de los FS-PACS todava consolidan informacion en un gran registro centralizado. En general, los PACS son sistemas
cerrados, facilitando servicios a un n
umero limitado de estaciones de trabajo, con
frecuencia a traves de conexiones de alta velocidad tales como ATM (Asynchronous
Transfer Mode) o Ethernet de 100 Mb/s. Los usuarios necesitan acceso instantaneo
a imagenes de alta resolucion para revision de diagnosticos y revisiones clnicas.
A diferencia, una librera de imagenes medicas basada en Internet puede necesitar soportar un gran n
umero de peticiones. La informacion puede ser distribuida a
traves de diferentes departamentos y hospitales, o incluso para revisiones externas y
consultas privadas.
La arquitectura de objetos distribuidos es mas apropiada para gestionar tales entornos de informacion heterogeneos y distribuidos. El modelado de datos es separado
de los clientes, y la logica comercial es desempe
nada en los servidores medios. El sistema distribuido puede aumentar proporcionalmente a un gran n
umero de usuarios,
ofreciendo un funcionamiento y fiabilidad mejorados, y aplicando coherencia a los
datos. Un punto a tener en cuenta con los objetos distribuidos es el coste y complejidad adicional cuando se a
naden servidores medios.
Servidor de im
agenes basado en PACS o basado en Internet
Los controladores de PACS son programas de aplicacion del servidor dise
nados
para acceso rapido desde las imagenes archivadas hasta las estaciones especializadas
de visualizacion para lectura de diagnosticos. La practica com
un para facilitar acceso
a traves de Internet a los archivos de imagenes en PACS es a traves de un servidor
HTTP configurado para comunicarse con los controladores de PACS. El usuario enva
peticiones al servidor, el cual en turnos pregunta al controlador de PACS por el
conjunto de imagenes correspondientes. Los controladores de PACS, sin embargo, no
estan dise
nados para procesar un gran n
umero de solicitudes. La carga de trabajo
extra generada por el servidor HTTP degrada el funcionamiento en conjunto de los
controladores de PACS.
r

MEDICAS
Otro tema relativo al acceso a las imagenes en PACS a traves de Internet es el

soporte del navegador para la resolucion de imagenes medicas. Las imagenes medicas
son almacenadas como imagenes en escala de grises, con resoluciones entre 12 y 16
bits/pixel. Las estaciones de trabajo de visualizacion estan especficamente dise
nadas
para visionar imagenes de alta resolucion. Por el contrario, los navegadores de Internet corren en monitores que no soportan mas 256 niveles de escala de grises. Para
solucionar este problema, un modulo de aplicacion muestrea las imagenes en PACS a
una resolucion menor para visionarlas en los navegadores. La adiccion de tal modulo
de aplicacion hace que el dise
no y integracion de los PACS sea mas difcil, y reduce
en conjunto el funcionamiento del sistema.
En resumen, un controlador de PACS esta dise
nado para un acceso a imagen
rapido para un n
umero reducido de usuarios (p.e., radiologos y cardiologos). Por el
contrario, un servidor de Internet puede manipular un gran n
umero de peticiones,
debido a su naturaleza deslocalizada. Por lo tanto, la librera digital de imagenes
medicas basada en Internet debera ser dise
nada con el servidor de Internet como
componente principal y central, antes que modulos de aplicacion centralizados en los
controladores de PACS.
Grandes clientes o peque

nos clientes
El visionado de imagenes en PACS requiere costosas estaciones de trabajo hechas

a medida, configuradas con m
ultiples monitores de alta resolucion, de 1000 x 1500
a 4000 x 4000 pixels de resolucion. Los programas de aplicacion estan desarrollados
especficamente para correr en tales estaciones de trabajo. Como las estaciones de
trabajo son a
nadidas o modificadas, la instalacion, integracion y las actualizaciones
de software son gastos costosos que hay que considerar. A veces, las estaciones de
trabajo pueden necesitar ser redise
nadas para soportar una nueva operatividad.
Por otra parte, los navegadores de Internet pueden funcionar en ordenadores personales relativamente economicos. Los documentos hypermedia y las imagenes son
almacenadas en servidores. En el nivel mas sencillo, los documentos son textos planos
con hyperlinks incrustados a imagenes y otros recursos. Con la llegada de lenguajes
de programacion basados en Internet, tales como Java, los navegadores tienen mayor grado de operatividad. Las nuevas caractersticas son a
nadidas a una localizacion
centralizada, resultando en menos costos y mantenimiento mas facil. Los navegadores
de Internet tambien permiten acceso omnipresente a imagenes medicas a traves de
plataformas de m
ultiples clientes, mientras se mantiene un interface de usuario medianamente coherente. Sin embargo, la baja resolucion de las imagenes y la capacidad
para mostrar niveles de grises de los navegadores limita su uso a lecturas de diagnostico aproximadas.
r

Visualizaci
on 2D o visualizaci
on 3D
Los PACS estan dise
nados para soportar varios modelos de visualizacion de imagenes
2D, que pueden simular a las radiografas convencionales. Las caractersticas a
nadidas
a la visualizacion de imagenes digitales incluye soporte de zoom, de rotacion, ajustes
panoramicos, de ventana, de nivel. Recientes avances en hardware y lenguajes para
imagenes 3D facilitan el movimiento hacia la visualizacion 3D.
La pregunta es si hay una necesidad de facilitar visualizacion 3D online en PACS
o libreras de imagenes medicas. Los Radiologos estan entrenados con la habilidad
de reconstruir mentalmente la imagen 3D a partir de cortes de imagenes en 2D. El
complejo proceso de visualizacion en 3D no a
nade ninguna nueva informacion y podra
incluso disminuir su lectura eficiente. Por otro lado, la visualizacion online es u
til para
la interpretacion combinada o correlacion de imagenes 3D anatomicas o fisiologicas, o
datos metabolicos, y para operaciones en tiempo real de terapia de imagenes guiadas
y procedimientos quir
urgicos. El desafo que se presenta es debido no solo al gran
tama
no de las imagenes medicas, sino tambien a la complejidad de las relaciones
entre los distintos datos.
La implementacion del las capacidades de visualizacion en los PACS o en una
librera de imagenes digitales sera probablemente una decision estrategica de como
uno debera expandir los servicios del sistema a otras disciplinas. Un modelo operativo
consiste en a
nadir un servidor de visualizacion potente en una arquitectura Three
Tiered y transmitir los resultados de la visualizacion a las estaciones clientes a traves
de redes de alta velocidad. La ventaja de esta configuracion es la reduccion de carga
computacional de las estaciones clientes.
Recuperaci
on por el contenido de la imagen
El dise
no original de los PACS es para soportar el estudio de imagenes; de esta
manera, las imagenes son recuperadas basandose en claves, tales como el nombre
del paciente o el identificador del hospital. La gestion de documentos de imagen
esta basado en sistemas de archivos planos. La ventaja es el simple dise
no de modelado
de datos. Este enfoque carece de la capacidad de buscar e indexar las grandes bases de
datos de PACS por el contenido (p.e., las caractersticas de la imagen o las relaciones
de nombre). Esto impide grandemente la utilidad de los PACS para otras operaciones
clnicas, tales como referencias online.
La recuperacion de imagenes por su contenido (BCIR - Content-based image retrieval) ha sido la llave para la actividad en la investigacion de una librara digital de
imagenes. Las actuales tecnicas de desarrollo en libreras digitales pueden ser adaptadas a los PACS. Muchas de las tecnicas existentes, sin embargo, se ocupan de la
10
r

MEDICAS
b
usqueda a traves de caractersticas comunes de las imagenes, tales como el color, forma, textura, o una combinacion de estas. Pero en el dominio de las imagenes medicas,
deben ser dise
nados todava mas algoritmos especficos para la extraccion de caractersticas y modelos de datos mas complejos y costosos para tomar ventaja de la rica
informacion contenida en las libreras de imagenes medicas.
Privacidad y seguridad de las im

agenes m
edicas
La privacidad del paciente y la seguridad de la informacion medica es una cuestion
importante que tiene que ser considerada cuando se trata con libreras de imagenes
digitales basadas en Internet. Para diagnosis, consulta, o investigacion, las imagenes
medicas y los datos del paciente pueden ser distribuidos a instituciones externas fuera
del hospital o clnica del paciente.
La seguridad punto a punto (point-to-point) se consigue generalmente a traves
de la encriptacion. Los actuales algoritmos de encriptacion son robustos y los suficientemente fuertes para una amplia aceptacion por las comunidades industrial y
gubernamental. La cuestion es integrar la tecnologa de codificacion en la librera
digital, con un mnimo gasto y cambio en el funcionamiento.
Otra cuestion relacionada con la seguridad, es el cribado y filtrado de peticiones.
Tiene que implementarse un mecanismo para la gestion de peticiones permitidas para
cada usuario.
Funcionamiento y fiabilidad
Los usuarios de PACS necesitan acceso rapido a las imagenes medicas para lecturas y diagnosticos primarios, y para ello a menudo se necesitan redes de alta velocidad (p.e., ATM y 100 Base T). Los PACS son esencialmente sistemas cerrados
con un peque
no n
umero de usuarios, asegurando de ese modo un buen funcionamiento comparado con los sistemas basados en Internet. La estrecha relacion existente
entre las aplicaciones de visualizacion y el modelo de datos incrementa ademas el
funcionamiento. Con mas nodos siendo a
nadidos a Internet, la librera digital basada
en esta necesita considerar esta cuestion de funcionamiento. La librera digital de
imagenes medicas debe ser capaz de organizar las peticiones clnicas no primariascomo tareas principales. Una librera digital de imagenes debera ser dise
nada para
lecturas secundarias o b
usquedas de datos por referencia.
Implementando una librera digital de imagenes con una intranet se puede lograr
un funcionamiento comparable a los tradicionales sistemas de PACS, mientras economizamos con el uso de ordenadores de escritorio economicos en lugar de estaciones
r
11

Figura 2.2: Arquitectura de una libreria digital de imagenes
de trabajo de alta calidad. El exito del funcionamiento de los sistemas basados en

Internet es ademas el uso de aplicaciones ejecutandose dentro del navegador, tales
como applets de Java. Por esta razon, los algoritmos que requieren extensos calculos,
tales como la manipulacion de imagenes, no se ejecutan eficientemente en el entorno
del navegador.
Los sistemas PACS estan creados para funcionar de manera continua, con una
fiabilidad de 24 x 71 . La tecnologa en auge basada en Internet, que es relativamente
nueva, tiene todava que solucionar el tema de la fiabilidad. La actual implementacion
de una Maquina Virtual de Java tiene todava que probarse para su fiabilidad en
largos periodos de tiempo. Se han realizado muchos trabajos en gestion de sistemas
tradicionales de funcionamiento de red, pero para sistemas de objetos distribuidos,
tales como CORBA, muy poco esta disponible en terminos de interfaces de gestion
de sistemas y herramientas.
2.2.2.
Arquitecturas para libreras digitales de im

agenes
Arquitectura de Base Centralizada de Datos

Hay que discutir dos arquitecturas; un modelo de base centralizada de datos y
una arquitectura de objetos distribuidos. La figura 2.2 ilustra la arquitectura general
de un sistema centralizado de datos. Este sistema frecuentemente contiene servidores
de aplicaciones de bases de datos y proporciona capacidad de acceder a Internet.
Debido a su gran tama
no, los estudios de imagenes son archivados en un medio de
1
12
Funcionamiento continuo de 24 horas por 7 das a la semana.
r

MEDICAS
almacenamiento diferente (p.e., un jukebox o sistemas de cinta digital).

El enfoque centralizado es extensamente utilizado en los RIS, HIS, y otros sistemas integrados de sanidad. Los FS-PACS tambien se adaptan a esta estructura.
Existen sistemas que almacenan y reproducen datos en una amplia base centralizada.
Para aplicaciones La ventaja principal de las bases centralizadas es su bajo coste de
desarrollo y mantenimiento.
Los datos multimedia de una librera digital de imagenes consisten en datos de los
archivos de imagenes de PACS, RIS, HIS, bases de datos clnicas, o archivos externos.
Esta naturaleza de los datos es inherentemente multimedia, consistiendo en imagenes
medicas, historiales medicos, demografas, dictados de voz, e indicaciones biomedicas.
Los datos pueden ser almacenados en un archivo del sistema, o en bases de datos
relacionadas. Una tecnologa para aplicaciones en Internet que esta en auge son las
bases de datos de objetos. Los protocolos estandar de informacion medica, tales como
DICOM (Digital Imaging and Communication in Medicine) y HL7 (Health Level
Seven), proporcionan un metodo a los datos para ser compartidos y archivados.
El servidor de Internet funciona como proxy para las peticiones de los usuarios. El
navegador genera peticiones HTTP (Hypertext Transfer Protocol) en representacion
del usuario en el servidor de Internet. Sucesivamente, el servidor Web enva la peticion
a una maquina de reglas, la cual procesa la peticion, construye los tipos de datos
requeridos, y devuelve una respuesta al servidor HTTP y al usuario. Las maquinas
de reglas tienen varias funciones, incluyendo un mecanismo de filtrado de preguntas
o un agente que mapea las solicitudes del usuario a tipos de datos apropiados.
El navegador de Internet es el mecanismo de omnipresencia por el cual los usuarios
acceden a tal sistema. La informacion puede ser presentada en el formato HTML (Hypertext Markup Language). Los documentos pueden ser gestionados estaticamente integrando los procesos del servidor, tales como el CGI (Common Gateway Interface).
El reciente desarrollo de XML (Extended Markup Language) favorecera las capacidades avanzadas del navegador proporcionando caracteres definidos por el usuario.
El surgimiento de los lenguajes de programacion basados en Internet, tales como Java, permiten capacitar al navegador para cargar y ejecutar dinamicamente peque
nas
aplicaciones, llamadas applets. Ventajas de este metodo es la gestion de aplicaciones
centralizadas y un interface coherente a traves de m
ultiples plataformas. Existen
varias desventajas en el uso de Java y el navegador; el funcionamiento se convierte en
un problema cuando los applets son interpretados dinamicamente por el navegador.
Por esta razon, los applets de Java estan restringidos en tama
no y complejidad.
r
13

Arquitectura de Objetos Distribuidos

Mientras las bases de datos centralizadas ofrecen simplicidad en el desarrollo y
bajo coste de mantenimiento, no trabajan bien con cargas de trabajo grandes y sistemas heterogeneos. Sin embargo, existe una resistencia en las organizaciones medicas actualmente a ser atadas en una arquitectura basada en la solucion de un u
nico
vendedor. Los sistemas existentes de soporte de almacenamiento de datos necesitan
protocolos y modelos de datos comunes para facilitar transacciones con las bases de
datos. Los problemas surgen cuando las fuentes de datos existentes utilizan protocolos y modelos de datos diferentes. Ademas de esto, las transacciones son realizadas
contra una u
nica base centralizada. Un sistema centralizado con un amplio n
umero
de usuarios aplica una considerable carga de trabajo en el servidor. Una parada en el
servidor detiene el sistema entero.
La tecnologa de objetos distribuidos soluciona estas cuestiones definiendo el middleware (infraestructura) entre el cliente y la fuente heterogenea de datos, y automatizando muchas tareas de desarrollo tales como inscripcion, localizacion, activacion y
demultiplexado de objetos. Los objetos distribuidos son similares a las abstracciones
de objetos en los lenguajes de programacion. Los objetos distribuidos proporcionan
un conjunto de campos y metodos accesibles a los clientes. Una framework (sistema)
es proporcionado para la gestion de objetos distribuidos. Los objetos proveen a los
usuarios un modelo virtual de la fuente de datos, permitiendo una integracion de
modelos de datos y protocolos heterogeneos. El framework puede replicar dinamicamente a los objetos, facilitando un reequilibrio automatico y una tolerancia a fallos
limitada.
14
r
2.3.
2.3. ESTANDAR
DICOM
Est
andar DICOM
[NEMA] [DICOM] [HORI] [KURA] [REVET97]

En esta seccion se va a hacer un estudio del estandar de comunicacion e imagenes
digitales en medicina DICOM 2 .
2.3.1.
Introducci
on
El uso de la informatica en aplicaciones clnicas es una constante hoy en da,

especialmente en el campo del diagnostico por imagen. El uso de la imagen digital
se ha ido imponiendo debido a los avances tecnologicos, ya que suponen una mejor
calidad de la misma y la posibilidad de transmitirla a distintos puntos de manera
inmediata. El problema fundamental para su empleo es la correcta interpretacion
de la informacion. Es por ello que la ACR3 (American College of Radiology) y la
NEMA4 (National Electrical Manufacturers Association) iniciaron un proyecto para
la elaboracion de un estandar para la transferencia de imagenes y la informacion
asociada a ellas que, tras varios intentos dio origen al formato DICOM 3.0, que es el
estandar habitualmente utilizado por las firmas digitales.
El estandar se ha desarrollado para encontrar las necesidades que fabricantes y
usuarios tienen con el equipamiento de imagen medica para la interconexion de dispositivos sobre redes estandares. Sus partes m
ultiples proveen medios para la expansion
y actualizacion, y el dise
no del estandar se apunto para permitir el desarrollo simplificado para todo tipo de imagen medica. DICOM tambien provee medios por los
que los usuarios de equipamiento de imagen pueden intercambiar informacion de dispositivos diferentes. Las futuras adiciones a DICOM incluyen apoyo para la creacion
de archivos sobre medios extraibles (tales como discos opticos y cinta magnetica),
las nuevas estructuras de radiografa como angiografa, y extiende el control de la
documentacion impresa.
En 1992 en la reunion anual de la Sociedad de Radiologa de America del Norte
(RSNA), en la parte 1 (Introduccion y Descripcion) y en la 8 (Soporte de Comunicaciones de Red e intercambio de Mensaje) del DICOM de ACR-NEMA (Imagen
medica y Comunicaciones en la Medicina) el Estandar se haba votado y aprobado.
Las partes restantes 2 a 7 y 9 se hicieron disponibles para comentarios. En infoRAD,
se realizo una demostracion de la Version de DICOM 3.0, la parte 8 usando mensajes
de la version previa 2.0 de ACR-NEMA. Mientras estas no eran implementaciones
2
Digital Imaging and Communication in Medicine

Asociaci
on de Colegios de Radiologa
4
Asociaci
on Nacional de Fabricantes Electricos
3
r
15

que incluan todas las estructuras de datos de DICOM, mostraron que el apoyo de
red era operacional y podra cumplirse exitosamente.
Durante el encuentro anual de 1992 se formaron Grupos de trabajo de ACR-NEMA
(WGs) responsables de las partes restantes y completar el estandar de DICOM en
encuentros mensuales. Se termino en septiembre de 1993, donde las versiones finales
de muchas de las partes haban experimentado la prueba de implementacion real a lo
largo de 1993 para asegurar que la calidad de estandar sera demostrada por productos
reales en el encuentro de 1.993.
La creciente utilizacion de sistemas de adquisicion y tratamiento digital de Imagenes
Medicas ha hecho necesaria la adopcion de estandares que posibiliten el intercambio
de estas tanto dentro de las propias instituciones como fuera de ellas.
El estandar DICOM 3.0 nace en el a
no 1993, a partir de un redise
no completo de
5
o
la Publicacion Normalizada N 300-1988 de ACR-NEMA y pertenece al campo de la
Informatica Medica por lo que, en principio, esta norma se solapa con otras de este
campo.
En primer lugar, dejar claro que DICOM 3.0 es aplicable a toda la esfera de las
Imagenes Medicas, desde la transmision hasta el tratamiento e impresion, independientemente de la especialidad medica que la exporte.
En segundo lugar, y quizas lo mas importante a da de hoy, indicar que aunque la
Norma tiene el potencial de facilitar la realizacion de trabajos con PACS, la utilizacion
de la Norma DICOM 3.0 no garantiza, por si misma que se cumplan todos los objetivos
que se intentan lograr en un sistemas de gestion de imagenes. Se facilita, pero no se
garantiza, la interoperatividad en un entorno multi-vendedor.
En tercer lugar, quedan por delimitar elementos importantes de informacion asociada a la propia imagen, por lo que se prevee numerosas extensiones que den soporte
a futuras aplicaciones.
El avance de la estandarizacion poco a poco va siendo una realidad:
Se homogenezan los estandares de codificacion de la informacion y del conjunto

de datos resultantes de utilizar los Objetos de Informacion (imagenes) con las
Clases de Servicio (impresion, almacenamiento, etc), as como se especifican
varias tecnicas de compresion normalizadas (JPEG con y sin perdidas).
Se muestran las reglas de codificacion que se deben cumplir para construir un
secuencia de datos para ser transmitida como un mensaje.
5
16
Digital Imaging and Communications Standard: version 2.0
r
2.3. ESTANDAR
DICOM
Se especifica los servicios de comunicaciones y los protocolos necesarios para,

en un entorno de red, intercambiar mensajes.
Se define la utilizacion de un conjunto de protocolos OSI (Interconexion de Sistemas Abiertos) para asegurar una comunicacion eficiente y que soporte una
amplia variedad de tecnologas de red basadas en normas internacionales como la ISO 8802-3 CSMA/CD (la famosa red Ethernet), ATM (muy en boga
actualmente), X.25, etc. Y como protocolo de transporte se puede utilizar el
famoso TCP/IP que hay que recordar que es un protocolo de proposito general, por lo que el sistema, en este apartado, es realmente abierto y compatible
con la mayora de las redes que se estan instalando actualmente en los centros
sanitarios.
2.3.2.
Historia de DICOM
En un esfuerzo para desarrollar unos medios estandar para que usuarios de equipamiento de imagen medica (tal como TAC, resonancia magnetica, medicina nuclear, y ultrasonidos) puedan intercambiar imagenes u otros dispositivos entre estas maquinas, el
Colegio Estadounidense de Radiologa (ACR) y la Asociacion Nacional de Fabricantes
Electricos (NEMA) formo un comite conjunto a principios de 1983. La mision de este
grupo, el Comite para estandarizar las comunicaciones y la Imagen digital de ACRNEMA, estuvo en hallar o desarrollar una interfase entre el equipamiento y cualquier
otro dispositivo que el usuario quiera conectar. Ademas de las especificaciones para
la conexion de hardware, el estandar se desarrollara para incluir un diccionario de
los elementos de datos necesitados para interpretacion y la exhibicion de imagenes.
La comision inspecciono muchos patrones de interfase existentes, pero no se encontro ninguno que fuera enteramente satisfactorio. En algunos, sin embargo, se encontraron ideas u
tiles. La Asociacion Estadounidense de Fsicos en la Medicina (AAPM)
haba, un a
no antes, desarrollado un formato estandar para grabar imagenes sobre
la cinta magnetica. La porcion de cabecera contendra una descripcion de la imagen
junto con los elementos de datos (tal como nombre paciente) para identificarlo. El
concepto de usar elementos de longitud variable identificados con una etiqueta o la
llave (el nombre del elemento) se creyo que era particularmente importante y fue
adoptado por la comision.
Despues de 2 a
nos de trabajo, la version primera del estandar, ACR-NEMA 3001985 (tambien llamado ACR-NEMA Version 1.0) se distribuyo en 1985 en la reunion
anual del RSNA y publicada por NEMA. Como con muchas versiones primeras, se
encontraron errores y sugirieron mejoras. La comision haba creado un grupo de trabajo (WG) VI para mejorar el estandar una vez se publico. Este WG contesto muchas
preguntas de desarrolladores potenciales y comenzo trabajando sobre cambios para
mejorar el estandar. En 1988, ACRNEMA 300-1988 (o Version 2.0 de ACR-NEMA)
r
17

se publico. Uso sustancialmente la misma especificacion de hardware que la Version

1.0, pero se agrego nuevos elementos de datos y se fijaron un n
umero de errores e
inconsistencias.
El problema era que por 1988 muchos usuarios quisieron una interfase entre dispositivos y una red. Mientras esto podra realizarse con la Version 2.0, el estandar
carecio de partes necesarias para la comunicacion robusta de red. Por ejemplo, uno
podra enviar a un dispositivo un mensaje que contenga informacion de cabecera y
una imagen, pero el dispositivo no sabra necesariamente que hacer con los datos. La
Version 2.0 de ACR-NEMA no era dise
nada para conectar equipamiento directamente
a una red, resolver estos problemas significaban cambios importantes al estandar. La
comision haba adoptado la idea que las futuras versiones del Estandar de ACRNEMA tendran compatibilidad con las versiones anteriores, y esto puso algunas
restricciones al WG VI.
En una decision importante para el estandar, se decidio que el desarrollo de una
interfase para el apoyo de red requerira demasiados parches sumados a la Version
2.0. El proceso entero tuvo que ser redise
nado, y el metodo adoptado fue el de objeto
orientado a dise
no.
Ademas, un examen completo de los tipos de servicios necesitados para comunicar
con redes diferentes mostro que definiendo un servicio basico permitira que la capa
superior procesara las comunicaciones (la capa de aplicacion) para hablar con un
n
umero de protocolos diferentes de red. Estos protocolos se modelan como una serie
de capas, frecuentemente referida a comostacks. En la Version existente 2.0 elstac
definido en una conexion punto a punto era uno. Dos de los otros se eligieron con
base en la popularidad y futura expansion: El Protocolo de Control de Transmision /
Internet de Protocolo (TCP / IP)6 y la Organizacion Internacional de Estandares de
Interconexion de Sistemas7 (ISO-OSI). La figura 2.3 muestra un diagrama del modelo
de comunicacion desarrollado. La filosofa basica de dise
no era que una aplicacion de
imagen medica determinada (fuera del alcance del estandar) podra comunicar sobre
cualquier de los stacks de otro dispositivo que use la misma stack. Con la adherencia
al estandar, sera posible cambiar las comunicaciones de stacks sin tener que para
revisar los programas de computadora de la aplicacion.
Despues de tres de a
nos de trabajo, WG VI, con valiosas sugerencias de la industria
y la academia, ha completado DICOM de ACR-NEMA (tambien llamado DICOM
3.0). Es un estandar de tama
no mayor que las versiones 1.0 o 2.0, pero tambien
soporta muchas caractersticas de las versiones anteriores.
6
7
18
Transfer Control Protocol / Internet Protocol

International Standard Organization - Open Systems Interconnection
r
2.3. ESTANDAR
DICOM
Figura 2.3: Modelo de protocolo de comunicaciones DICOM
2.3.3.
Procesamiento Distribuido
Un simple modelo de un proceso distribuido servira para explicar el mecanismo y

terminologa usada en el estandar DICOM. Figura 2.4.
Con un simple modelo de un proceso distribuido se puede explicar el mecanismo
y terminologa usada en el estandar DICOM.
Figura 2.4: Procesamiento distribuido
Un proceso distribuido esta formado al menos por dos procesos que comparten
informacion y confiando en la operatividad de uno en el otro. Un n
umero de procesos
distribuidos actuando juntos proporcionan servicios para sistemas en entornos como
departamentos de radiologa. Figura 2.5.
Antes de que los procesos puedan actuar juntos una serie de temas tienen que ser
r
19

Figura 2.5: Transmision
tratados. Tienen que estar de acuerdo en el papel (rol) que cada uno desempe
nara,
tener una vision equivalente de la informacion y seleccionar las operaciones que cada
parte realizara.
Primeramente, el papel de cada parte debe ser definido como cliente o como servidor. La parte que utiliza la operatividad de la otra, tiene el papel de cliente. La
parte contraria actuando sobre un modelo concertado tiene el papel de servidor. El
funcionamiento de ambas partes viene definida por la relacion que comparten. La
relaci
on define que parte y bajo que condicion toma la iniciativa en el proceso. En
muchos casos los clientes provocan el proceso, pero a veces lo hace el servidor.
Ademas de los papeles que desempe
nan, ambas partes tienen que estar de acuerdo en la informacion que intercambian. La informacion esta definida por el contexto
del servicio que el proceso distribuido esta realizando. Cada proceso individual tendra una vision selectiva de esta informacion, pero la vision tiene que ser coherente en
la totalidad del contexto.
La operacion define como debe ser procesada la informacion intercambiada en la
otra parte, tal como almacenar informacion, devolver un resultado, etc.
La combinacion del contexto, relacion, operaciones e informacion es la piedra fundamental del procesamiento distribuido y tiene que ser definida antes de que una
aplicacion pueda ser realizada. Todos estas cuestiones son parte del dominio de la
aplicaci
on(application domain) de los procesos distribuidos. Estos no se ocupan de
la forma en que la informacion es intercambiada actualmente, pero cuentan con los
servicios de menor nivel (p.e. TCP/IP) suministrados por el dominio del intercambio(exchange domain) para poder hacer frente al intercambio.
Ambas partes, cliente y servidor, tienen que ser capaces de emitir peticiones a los
servicios de menor nivel. Los servicios de menor nivel llevaran el intercambio y estan
ocultos para el dominio de la aplicacion del cliente o servidor. La parte que solicita
20
r
2.3. ESTANDAR
DICOM
los servicios es el usuario del servicio (service user). El equivalente es el proveedor del
servicio (service provider). Ambas partes pueden tener distintas implementaciones,
pero comparten el mismo conocimiento sobre como se intercambian los datos (protocolo) y tienen el mismo interface logico (formato de peticion) entre s. Ambas partes
deben determinar como viene representada la informacion en el formato de bit/byte.
El proveedor del servicio debe determinar en que formato la informacion fue transferida y convertida a la representaci
on esperada por el dominio de la aplicacion. La
representacion es conocida entre el usuario y el proveedor del servicio en cada parte.
Despues del intercambio, la informacion presentada a los procesos utilizando la informacion es igual en ambas partes, independientemente de como fuera intercambiada.
El intercambio fsico entre los proveedores del servicio puede ser va network o
media. Cada mecanismo tiene su propia forma de manejar el conocimiento de la
representacion.
La Figura 2.6 representa los conceptos que acaban de ser estudiados.
Figura 2.6: Modelo de un proceso distribuido
2.3.4.
Conceptos generales de DICOM
DICOM es un estandar que cubre las cuestiones plantedas en la seccion anterior.

Esta seccion abordara los conceptos generales con respecto al mecanismo de inter-
r
21

cambio actualmente usado.

Los objetos (pacientes, imagenes, reportes,etc.) y sus interrelaciones son descritos
mediante modelos de entidad-relacion. El primer modelo fue definido para la radiologa. Otras disciplinas medicas han pedido su incorporacion al estandar.
DICOM utiliza su propia terminologa para describir el contexto, relaciones,asociaciones,
etc. El primer paso es el mismo modelo que para el procesamiento distribuido con la
transformacion de la figura 2.6 en la figura 2.7 aplicando los terminos equivalentes de
DICOM.
Figura 2.7: Clases de Servicio de DICOM
Se considero que la mejor manera de desarrollar las estructuras de datos era el

dise
no orientado a objetos. Los objetos definidos en los modelos son llamadosentidades.
los atributos describen las caractersticas de un objeto. Cuando se dan valores a los
atributos de un objeto, defiendo un objeto reas, existente, se habla de una instancia del
objeto. Los objetos de agrupan en clases, seg
un su tipo. Las clases se comunican entre
s, mediante mensajes. DICOM define las clases de objetos y sus mensajse permitidos
en lo que es llamado SOP(Service-Object Pair). Cuando un equipo especifica que
es compatible con una clase SOP, es posible saber de forma no ambigua como se
entenderan sus datos, ya sea por el proveedor de los servicios de la clase : SCP(Service
Class Provider) o por el usuario de los servicios de la clase: el SCU (Service Class
22
r
2.3. ESTANDAR
DICOM
User). Para realizar una asociacion, lo primero es que SCU y SCP esten deacuerdo
en utilizar una clase SOP.
Clases de Servicio (Service Classes) y Clases SOP (SOP Classes)

La relacion entre ambas partes es definida por la descripcion de la Clase de Servicio. La Clase de Servicio describe explcitamente los papeles que ambas partes desempe
nan. Dependiendo de la Clase de Servicio el contexto del servicio esta definido.
Con DICOM ambos papeles son llamados: Usuario de la Clase de Servicio o SCU
(Service Class User) (cliente) y Proveedor de la Clase de Servicio o SCP (Service
Class Provider) (servidor). No hay que confundir SCU y SCP con el usuario del
servicio y el proveedor del servicio del dominio del intercambio.
Parte de la Clase de Servicio es la descripcion de la informacion y operaciones.
En DICOM estas estan combinadas con la definicion de la clase, llamada Clase de
Servicio de Par Objeto (Service Object Pair Class) o Clase SOP (SOP Class). En
cada definicion de Clase SOP una u
nica Definici
on de Objeto de Informaci
on (Information Object Definition) o IOD es combinado con uno o mas servicios. Para cada
uno de estos servicios los detalles de los papeles de ambas partes que tienen que
desempe
nar son invariables. Mas de una Clase SOP puede existir en una Clase de
Servicio cuando mas de un IOD esta implicado. Una Clase de Servicio entiende la
relacion de informacion definida en diferentes IODs.
Una Clase SOP identifica las capacidades del proceso distribuido especfico de
una Clase de Servicio. Cuando las partes estan de acuerdo en utilizar una Clase
SOP, ambas partes deben asegurar que desempe
naran sus papeles como se describen,
utilizando el contexto de la Clase de Servicio incluida. Antes de que la informacion
se intercambie puede tener lugar la identificacion de la Clase SOP, que es una parte
importante que tiene que ser realizada al principio. El mecanismo usado depende del
tipo de intercambio: network o media.
Utilizando la Clase de Servicio y otras definiciones derivadas, las partes en el
entorno de un proceso distribuido funcionan juntas mediante los servicios proporcionados por el dominio del intercambio.
Definiciones de Objeto de Informaci

on (Information Objects Definitions)
La parte de informacion de una Clase SOP es definida en los IODs. Un IOD es
una coleccion de partes de informacion relacionada, agrupadas en Entidades de Informaci
on (Information Entities) o atributos. Cada entidad contiene informacion sobre
un u
nico objeto (mundo real) como un paciente, una imagen, etc. Dependiendo del
r
23

contexto definido por la Clase de Servicio, un IOD consiste en una entidad de informacion u
nica llamada IOD normalizado (normalized IOD) o una combinacion de
entidades de informacion llamada IOD compuesto (composite IOD). Las Clases de
Servicio que llevan a cabo funciones de administracion (en su mayor parte cuestiones
simples) utilizan IODs normalizados, aquellas que manejan el flujo de imagenes (estructura compleja de informacion) utilizan IODs compuestos. Cada Clase SOP es
definido con uno o mas IODs que son combinados con uno o mas servicios.
Figura 2.8: Relacion entre los IODs y los atributos
La relacion entre diferentes entidades de informacion (estructuracion) y los IODs

compuestos es descrita en el modelo de informaci
on (information model) perteneciente
a la Clase de Servicio. Con IODs normalizados (solo una entidad de informacion) no
hay ninguna necesidad de estructuracion. Las relaciones en otras piezas de informacion
estan hechas aludiendo a esa informacion.
Las entidades de informacion consisten en atributos, describiendo una u
nica parte
de informacion, p.e., el nombre de un paciente. Los atributos que tienen una relacion
estan agrupados en modulos de informaci
on de objetos o IOMs (Information Object
Modules). Los IOMs estan definidos de tal manera que pueden ser usados en mas de
un IOD. Estos IOMs tambien tienen la ventaja de que las descripciones semanticas
de los atributos descritos pueden ser agrupados juntos. La figura 2.8 representa una
vision general de estas relaciones.
Un ejemplo de una IOD compuesto, imagen IOD esta representada en la Figura
2.9.
24
r
2.3. ESTANDAR
DICOM
Figura 2.9: Ejemplo de un IOD de imagen compuesto
Atributos
Los atributos son la entidad de informacion basica y tienen que ser descritos
en detalle.Figura 2.10. Las siguientes caractersticas o campos de un atributo estan
definidas en el estandar DICOM:
un u
nico Nombre de Atributo (Attribute Name) (legible por el ser humano).
una u
nica Etiqueta de Atributo (Attribute Tag) (legible por los sistemas de
informacion).
una Descripcion de Atributo (Attribute Description) (semantica).
un Valor de Representacion (Value Representation) (sintaxis).
un Valor de Multiplicidad (Value Multiplicity).
tipo de clasificacion: 1, 1C, 2, 2C o 3 (usadas dependiendo del contexto de las
Clases SOP, Clases de Servicio, papel que desempe
na, etc.).
El tipo de clase especifica el uso de los atributos especificados en las Clases SOP
y el papel del SCU o del SCP. Dependiendo de la situacion, cada atributo es forzado
r
25

a tener un valor (tipo 1) o forzado con o sin valor (tipo 2) o opcional (tipo 3).
Figura 2.10: Ejemplo de los atributos del modulo Paciente
Dentro de un IOD, los atributos agrupados o individuales pueden ser condicionados por la situacion en la que el IOD esta siendo usado. Por ejemplo, un analisis utilizando contraste puede almacenar informacion en un modulo de Contrast/Bolus.
Los atributos de este modulo estan por consiguiente disponibles o no disponibles,
dependiendo del uso del contraste. Si se usa, el tipo de clase especificada para los
atributos debe ser obedecida (definida como tipo 1C y tipo 2C).
Elementos de Servicio (Service Elements)

Los Elementos de Servicio son las operaciones permitidas en los Objetos de Informacion (IODs) para una Clase SOP definida. El grupo de elementos de servicio
pertenece a la Clase SOP y es llamada Grupo de Servicio (Service Group).
El Grupo de Servicio de una Clase SOP es seleccionado de una lista fija de Elementos de Servicio de DICOM. Algunos Elementos de Servicio estan proyectados para
usarse con IODs compuestos, otros para uso con IODs normalizados. Una tercera
categora, medios de almacenamiento (storage media) relacionados con Elementos
de Servicio, manejando instancias de Clases SOP normalizadas o compuestas como
archivos. Una Clase SOP utiliza uno o mas elementos de servicio.
El contexto descrito por la Clase de Servicio esta limitado cuando se utilizan
IODs compuestos (p.e., transferir imagen). Elementos de Servicio semejantes tienen
un significado complejo, p.e., STORE, FIND, MOVE. No hay ninguna relacion asumida entre los Elementos de Servicio individuales en una secuencia cuando se utilizan
Clases de Servicio compuestos. Si existe una relacion, es fuera del alcance de la Clase
de Servicio y debera estar definida en el proceso fluyente utilizando las Clases de
Servicio.
26
r
2.3. ESTANDAR
DICOM
En contraste, las Clases de Servicio utilizando IODs normalizados tienen un contexto mas amplio, como funciones directivas. Estas utilizan los Elementos de Servicio
primitivos para operaciones con piezas sencillas de informacion: GET, SET, ACTION,
etc. La Clase de Servicio define la relacion de la secuencia de la peticiones primitivas.
Con Clases de Servicio normalizadas ambas partes estan al tanto del procedimiento
de ambas partes, utilizando los Elementos de Servicio para controlarlos.
Cada Clase SOP utiliza uno o mas Elementos de Servicio de cada uno de los grupos compuestos (C-XXXX) o de los grupos normalizados (N-XXXX). Los siguientes
Elementos de Servicio estan disponibles: C-STORE, C-FIND, C-MOVE, C-GET, CCANCEL, C-ECHO, N-GET, N-SET, N-ACTION, N-CREATE, N-DELETE y N-EVENTREPORT. Las sem
anticas de los Elementos de Servicio dependen de la Clase de Servicio y de la Clase SOP en la cual estan utilizados.
Los Elementos de Servicio relacionados con Media, M-WRITE, M-READ, M-DELETE,
M-INQUIRE-FILE-SET y M-INQUIRE-FILE definen funciones primitivas para el tratamiento con archivos.
Gracias a las Clases de Servivio (mensajes DICOM) hay una comunicacion entre
ambas partes. Antes de poder lograr el intercambio de informacion entre dos Clases
SOP, debe establecerse entre ellas una Asociacion (Association en DICOM), donde se
negocia para establecer las posibilidades de trabajo de cada parte. Una vez establecida
la asociacion, si esta fue satisfactoria puede establecerse el intercambio de mensajes a
traves de los DIMSE- DICOM Service Element- (DIMSE-C en este caso, que soporta
operaciones con Instancias Compuestas SOP).
Los mensajes entre dos aplicaciones DICOM estan codificados y son enviados en
forma de Data Set que esta compuesto de Command Elements y deben tener una
estructura como la que se muestra en la figura 2.11.
La norma establece que la estructura del mensaje y set de comandos sea por
defecto: - Tags en orden Creciente, - Little Endian, -VR Implcito.
La transferencia de mensajes entre aplicaciones DICOM se establece mediante el
flujo de Data y Command Elements ordenados seg
un el Tag y codificados.
Si en el Data Set vienen ya implicitos los datos que quieren ser pasados de un
equipo a otro, este se compone de Data Elements y su estructura es seg
un la figura
2.12. Este es el modo en que se codifican los mensajes para transferir los estudios y
la informacion de un equipo a otro.
Tanto el Command Set como el Data Set son cola de Command Elements8 o
8
Elementos de Comandos DICOM (Store, Find, etc.)
r
27

Figura 2.11: Estructura del mensaje DICOM
Data Elements9 respectivamente. En ambos casos, la estructura del elemento es la

misma, difiriendo simplemente en el n
umero de grupo y en algunos casos en el VR.
Tag: es un par ordenado de n

umeros de 16 bits codificados en hexadecimal.
El primero de ellos hace referencia al Grupo, mientras el segundo se refiere al
Elemento, y son ledos como enteros sin signo. Identifica los atributos, el par
(grupo,elemento). Estan definidos en el Data Dictionary.
Value Representation (VR): es una cadena de dos caracteres que seg
un la cual
se especifica el tipo de dato que se leera en el Value Field. En la Parte6 de la
norma se especifica el tipo de dato (cadena de caracteres de hasta 16 bytes,
cadena de caracteres de 4 bytes, etc.) correspondiente a cada sigla (AE, AS,
etc.).
Value Length: Length: entero sin signo de 16 o 32 bits (seg
un sea VR, Explcito
o Implcito). Contiene un n
umero par que indica la extension del campo Value
Field, donde se hallan contenidos los datos propiamente dichos.
Value Field: aqu se encuentra un n
umero par de elementos conteniendo el/los
valor/es. Es el dato propiamente dicho, cuya ndole esta determinada por los
campos anteriores.
9
28
Codificaci
on de datos (Fecha de Estudio, Modalidad de Estudio, etc.)
r
2.3. ESTANDAR
DICOM
Figura 2.12: Estructura del Data Element
Instancias SOP (SOP Instances)

El esqueleto de las definiciones citadas anteriormente toma forma cuando se utilizan en un proceso distribuido. Despues del acuerdo que mantienen las Clases SOP
(e implcitamente la Clase de Servicio), y como los papeles de la SCU y la SCP estan
divididos, las instancias de la clase SOP pueden ser distribuidas entre las dos partes.
Los Atributos tienen que ser proporcionados con los valores correctos y almacenado
en la Instancia SOP como se especifica en la definicion de los atributos.
Despues de recopilar la informacion, esta sera codificada a los formatos definidos
por DICOM, utilizando la Representacion del la Etiqueta (Tag) y del Valor (Value)
para crear un DICOM data set, en el cual cada atributo es codificado en un data element. Este data set es manejado por el proveedor del servicio de intercambio, el cual
garantiza que la parte contraria recibe identico data set. Las diferencias en la representacion del sistema especificado son tomadas en una cuenta durante el intercambio,
asegurando que los significados semanticos permanecen intactos.
El receptor del data set decodificara este para extraer la informacion que necesita
y actuar como acuerdo de la semantica de la Clase SOP.
Identificaci
on
Como parte del proceso de creacion de una Instancia SOP, una identificacion es
generada como atributo de la SOP Instance. La identificacion es pretendida para la
r
29

utilizacion por los sistemas de informacion antes que por los humanos y tiene dos
caractersticas: la identificacion de la clase (class identification) y la identificacion de
la instancia (instance identification).
Esta identificacion tiene que ser usada en un entorno de muchos vendedores en
distintas partes del mundo. Para asegurar la unicidad de cada identificacion en todo
el mundo, un mecanismo es utilizado para generar una cadena de caracteres, llamada
Identificador Unico
o UID (Unique Identifier), tal y como sigue:
<root>.<suffix>
La parte de root es proporcionada por una autoridad que garantice que nadie
mas utilizara este root. Este n
umero sera asignado por estandares de organizaciones
y compa
nas tales como Philips u hospitales, que deberan asegurar que permanece
u
nico a lo largo de sus propios sistemas. Utilizando un sistema de identificacion u
nico,
cada sistema tendra un u
nico root a lo largo de todo el mundo. El suffix tiene que ser
creado dinamicamente por el sistema en la creacion de la instancia.
Un vez que una instancia es identificada por un UID, esta debe ser utilizada
consistentemente. Si se crean copias o la instance es reproducida sin ninguna modificacion, debera tener el mismo UID, de lo contrario dos piezas de identica informacion
coexistiran con diferentes identificaciones, lo que podra conducir a confusion.
Relaciones
Ademas de la identificacion de la Clase SOP y la Instancia SOP, los UIDs tambien
se utilizan para identificar una relaci
on entre instancias. En una instancia compuesta
(composite instance) que contiene una secuencia de imagenes, la Entidad de Informacion (Information Entity) que contiene la informacion de la secuencia sera com
un
para todas aquellas instancias. En este caso solo un UID es requerido, el atributo por
s mismo identifica que tipo de entidad de informacion es identificada.
En el caso de instancias normalizadas (normalized instances), solo son posibles
referencias a instancias fuera de s mismas, aqu la combinacion de una identificacion
de una clase y una instancia es requerida. Este es tambien el caso de imagenes que
estan referidas a cada una, cuando tienen una relacion segura.
Con el metodo de la unicidad de identificacion de informacion utilizando UIDs,
es tan solo posible comparar si las instancias son iguales. El valor del UID no tiene
ning
un significado, y no puede ser utilizado para clasificar, etc. Utilizando otro metodo, atributos mas significativos tales como la fecha y la hora y los n
umeros de la
secuencia, la relacion entre la informacion puede ser establecida.
30
r
2.3. ESTANDAR
DICOM
Representaci
on del Valor (Value Representation)
Para cada atributo un Representaci
on del Valor (VR) es definido. Una Representacion del Valor describe como un atributo es codificado en un Data Element
(elemento de dato). El conocimiento de la Representacion del Valor es compartido
por las partes en el intercambio de informacion, el proceso de codificacion y decodificacion tiene que tener cuidado en la seleccion del VR correcto para un atributo
(identificado por su etiqueta tag).
Dos formas de compartir esta informacion son posibles: compartir un diccionario
de datos que contiene todos los posibles atributos de intercambio o incluyendo la representacion del valor como una parte del data element. El u
ltimo metodo incrementa
los gastos de intercambio de informacion, pero es mucho mas flexible comparado con
el uso de un diccionario de datos compartido. Especialmente en un entorno de muchos
proveedores, sincronizar el diccionario de datos es difcil.
Cuando la Representacion del Valor es incluido, el mensaje es codificado con un
VR explcito (explicit VR). En el otro caso, la codificacion tiene lugar con un VR
implcito (implicit VR).
Transfer Syntax
Antes de que la Data Set de una Instancia SOP pueda ser transferida, la forma
en la que el Data Set es codificado en una secuencia de bytes debe ser fija, ambos por
acuerdo cuando el intercambio network es usado, o almacenados juntos con los datos
de uno. La forma de codificar es especificada por el Transfer Syntax.
Tres caractersticas tiene que ser definidas por la transfer syntax:
Como una Representacion del Valor es especificada.
La ordenacion de bytes de un n
umero m
ultiple de bytes (palabras, palabras
largas): little endian o big endian.
En caso de encapsulacion (compresion): el formato de compresi
on.
El manejo del transfer syntax es parte del proveedor del servicio. Sin embargo,
ambos procesos tienen que ser iniciados seg
un el transfer syntax, aceptable para
ambas partes.
Analogamente a una identificacion de Clase SOP, un transfer syntax es identificado por un UID.
r
31

Una visi
on general
Mirando la figura 2.13 se puede obtener una vision general del flujo de codificacion
y decodificacion. Los servicios proporcionados dentro del Dominio del Intercambio
tienen que garantizar que las Instancias SOP en ambas partes contienen la misma
informaci
on, independientemente de la representacion y metodo de transferencia.
El proceso de codificacion y decodificacion tiene dos etapas:
Primero se transfiere la representacion interna en el formato definido por DICOM

(Data Set) donde cada atributo es almacenado conforme al valor de representacion definido para ese atributo.
La segunda etapa transfiere el data set en una corriente de bytes que pueden
ser manejados por las capas mas bajas. Para la segunda etapa la ordenacion de
bytes tiene que ser utilizada como acuerdo con el Transfer Syntax.
La aplicacion que esta utilizando la informacion debe conocer el significado (semantica) de la informacion dentro del objeto dato.
Figura 2.13: Vision general de la codificacion y decodificacion de las instacias SOP
32
r
2.3.5.
2.3. ESTANDAR
DICOM
Conceptos de DICOM Network
En la anterior seccion se han discutido los conceptos de DICOM del dominio

de la aplicacion. Cuando se utiliza un mecanismo network para el intercambio de
informacion, el dominio del intercambio debe contener funciones requeridas para la
comunicacion: el dominio de la comunicacion; ver figura 2.14.
Figura 2.14: DICOM y el intercambio network
Entidad de la Aplicaci
on (Application Entity)
Una cuestion importante en las aplicaciones distribuidas en red es como las aplicaciones pueden contactar entre ellas. En DICOM Network, las partes se reconocen
mutuamente mediante las Entidades de la Aplicacion. Una Entidad de la Aplicaci
on
es aquella parte de un proceso que negocia con la comunicacion. Ella contiene el
Usuario de Servicio del proceso, conteniendo funciones para organizar conexiones y
transferencia de informacion. Una Entidad de la Aplicacion tiene un nombre, Ttulo
de la Aplicacion (Application Title), que tiene que se utilizado cuando se establece la
comunicacion.
r
33

Direcci
on de la Presentaci
on (Presentation Address)
Los Ttulos de la Aplicacion son nombres simbolicos para los procesos involucrados
en la comunicacion. En un sistema de red real, la direccion de red tiene que ser
suministrada. A esto se le llama la Direcci
on de la Presentaci
on. Se le llama as porque
el usuario del servicio es la capa de Aplicacion (OSI), el proveedor del servicio, la capa
de Presentacion (OSI) (y niveles mas bajos). La frontera entre ambos niveles es el
punto de acceso network donde los datos son transferidos desde la capa de aplicacion
a las capas de network. Cada punto de acceso en una red tiene una u
nica direccion.
El mapeo del Ttulo de la Aplicacion a la Direccion de la Presentacion no tiene
que ser u
nico, porque la Direccion de la Presentacion es utilizada para la iniciacion
de la conexion, etc. De cualquier manera en el nivel de aplicacion, el Ttulo de la
Aplicacion es usado normalmente para identificar una aplicacion como fuente o destino de informacion en un directorio o catalogo. Si esto no puede ser registrado sin
ambig
uedades la operacion de los sistemas puede llegar a ser un problema.
El formato de la Direccion de la Presentacion depende del protocolo de red utilizado. Los DICOM Networks son realizados en muchos casos utilizando el protocolo
TCP/IP. En este caso la Direccion de la Presentacion es mapeada a un TCP/IP socket. En caso de un protocolo OSI, debe utilizarse un OSI Presentation Service Address
Point (PSAP) valido.
Association Negotiation
La conexion para el intercambio de informacion entre dos Entidades de la Aplicacion es llamada Asociacion (Association). Para una Asociacion unas cuestiones
de comunicacion son fijados como el contexto en el cual la informacion puede tener
cambios. Este contexto, llamado Contexto de la Aplicaci
on (Application Context),
es definido en el estandar DICOM y ambas partes deben estar de acuerdo con la
actuacion conforme a la definicion del contexto.
Un Contexto de la Aplicacion es definido con un UID y durante la iniciacion de
una asociacion este UID es transferido a las partes. Por comparacion del UID de un
Contexto de la Aplicacion, la parte puede decidir si es capaz de manejar la peticion
aceptara el establecimiento de la asociacion o lo rechazara.
de una asociacion. El
El Contexto de la Aplicacion cubre la operatividad global para el intercambio
de informacion. Que tipo de informacion intercambia tendra lugar a traves de la
asociacion que esta definida por las Clases SOP y las Clases de Servicio de estas Clases
SOP. La parte iniciadora de la asociacion propone a la Clase SOP que sera utilizada,
el SCU / SCP para cada Clase SOP y la forma de representacion de la informacion.
34
r
2.3. ESTANDAR
DICOM
Dependiendo de las capacidades de la otra parte, aceptara o rechazara cada Clase

SOP individual.
Despues de este proceso de negociacion ambas partes conocen mutuamente las
capacidades y limitaciones. La autentica informacion distribuida puede tener lugar
conforme a las reglas de una Clase de Servicio y una Clase SOP definidas para estas
clases. Cuando una Asociacion no es muy larga se requiere la Asociacion que ha
terminado.
Presentation Context
Para cada Clase SOP negociada durante la iniciacion de la Asociacion tiene que
alcanzarse un acuerdo entre los procesos involucrados acerca del transfer syntax usado
entre los procesos. La parte iniciadora propone todos los transfer syntaxes, fijando
el Contexto de la Presentacion para esta Clase SOP. Despues de la negociacion una
Presentation Context para cada Clase SOP aceptada es establecida.
Una Presentation Context es identificada por un n
umero acordado entre las dos
partes. En el contexto de una aplicacion puede existir un n
umero de una Presentation
Context. El n
umero de la Presentation Context identifica la SOP Class para la cual
el intercambio de informacion tiene lugar.
El Contexto de Presentacion esta compuesto por dos UIDs, uno es el Transfer
Syntax, necesario para la posterior transmision del Data Set, y el otro el Abstract
Syntax, necesario para la correcta comunicacion entre las dos partes de la asociacion,
ya que este determina que operacion va a ser realizada. Figura 2.15.
Figura 2.15: Ejemplos de Contextos de Presentacion
Protocolos de Red
El actual Protocolo de Red tiene que cumplir con los servicios del estandar definidos
para el protocolo OSI. Ver figura 2.16.
r
35

Figura 2.16: Capas OSI
Para la capa de aplicacion dos grupos de servicios tienen que estar disponibles
para una implementacion DICOM: el protocolo de Control de Asociacion (ACSE) y
el protocolo de Mensajes DICOM (DIMSE). ACSE es un estandar del protocolo OSI
y DIMSE pone en practica los servicios DICOM.
El interfaz entre ACSE, DIMSE y la aplicacion, es la Interfaz DICOM como la
descrita en el estandar DICOM. Esta especificacion describe que parametros son
requeridos para cada funcion del ACSE y peticiones DIMSE. El ACSE, DIMSE y
el interfaz DICOM son partes del Contexto de Aplicacion.
El interfaz hacia la aplicacion(API) no es especificado en el estandar, pero depende
de la implementacion. En general este API proporciona funciones para conectarse con
otras aplicaciones, construir o tratar Instancias SOP y transferir estos a una aplicacion
remota.
TCP/IP Protocol Stack

La combinacion de TCP/IP y una extension para los servicios de aplicacion de OSI
es ampliamente usada para implementar DICOM a traves de las redes. Como no hay
36
r
2.3. ESTANDAR
DICOM
niveles mas altos definidos por TCP/IP, la operatividad de la aplicacion, presentacion

y sesion de la capa es requerida por DICOM, como se describe en el estandar DICOM.
Esta operatividad es combinada en una capa: la DICOM Upper Layer o DUL.
La DUL utiliza el mismo interface que el protocolo TCP/IP con respecto del
protocolo OSI. En el nivel mas bajo del DUL hay un interface para el nivel TCP.
La Asociacion DICOM entre las Entidades de Aplicacion es mapeada a una conexion
TCP. La Direccion de la Presentacion es mapeada a un n
umero de puerto TCP,
combinado con el n
umero de IP o nombre del servidor (Host name). Esta combinacion
del n
umero de puerto TCP y el n
umero de IP es llamada Direccion de Conexion
(Socket Address). En una red esta combinacion es siempre u
nica.
Una conexion TCP es definida por la combinaci
on de una Direccion de Conexion
local y una remota. Manteniendo los n
umeros de IP u
nicos de la red y el n
umero u
nico
de puerto en el sistema, cada conexion TCP es u
nica identificada por la combinacion.
La administracion de las conexiones se hace por una recurso llamado Interface de
Conexi
on (Socket Interface) que proporciona funciones para configurar las conexiones,
transferir cadenas de bits, etc.
El puerto TCP de la parte a la que se llama durante la inicializacion de la conexion,
debe ser conocido. Esto puede ser por un acuerdo en el n
umero de puerto entre las
dos aplicaciones, o por un n
umero de puerto, llamado n
umero de puerto notorio (well
known port number), reservado para las implementaciones de DICOM (n
umero de
puerto 104).
2.3.6.
Clases de Servicio soportados
DICOM tiene definidas un n

umero de Clases de Servicio. Pueden ser agrupadas
en un gran n
umero de categoras. Esta lista de Clases de Servicio crecera tal como
nuevas operatividades sean estandarizadas en el estandar DICOM.
Image Storage Service Classes

Esta primera categora contiene las Clases de Servicio negociadas con los datos
de imagen. Los datos de imagen son siempre encapsulados en un IOD compuesto y
utilizando los servicios compuestos. Las Clases de Servicio de este grupo son:
Storage Service Class, que consiste en Clases SOP para cada modalidad de
tipo de imagen: Computed Radiography (CR), Computed Tomography (CT),
Magnetic Resonance (MR), etc. Esta Clase de Servicio especifica el intercambio
r
37

Figura 2.17: Conexion TCP
de los datos a traves de la red. No especifica que tiene que hacerse con la imagen,
que tiene que ser gestionada por otras Clases de Servicio.
Query/Retrieve Service Class. Incluye las clases SOP FIND, MOVE y GET
para un n
umero de modelos de peticiones. La FIND puede ser utilizada para
solicitar una coleccion de imagenes. La MOVE y GET pueden ser usadas para
iniciar la transferencia. La actual transferencia se realiza utilizando la Storage
Service Class.
Study Contents Notification, es utilizada para notificar una administracion facil
de una imagen sobre las imagenes creadas durante un estudio y podran ser
utilizadas para iniciar la transferencia de los datos de imagen o para chequear
si todas las imagenes han sido completamente transferidas.
Management Service Classes

La administracion orientada a las Clases de Servicio se realiza utilizando una
mezcla de IODs normalizados con Servicios normalizados y una Clase de Servicio
Query que maneja informacion en sentido opuesto. Esta segunda categora consiste
en:
38
r
2.3. ESTANDAR
DICOM
Detached Patient Management maneja la informacion solicitada por la agenda

de visitas para una o mas modalidades. La informacion demografica del paciente
y los estudios de informacion son enviados desde los sistemas administrativos
(RIS) hasta la modalidad.
Detached Study Management recibe informacion de las series de imagenes creadas
de las modalidades y manda todos los datos adquiridos a un completo estudio
de imagenenes interdependientes y todos los otros tipos de informacion.
Detached Result Management es utilizada para estar al tanto de los informes e
impresiones del estudio.
Basic Worklist Management, es la u
nica Service Class no normalizada. Complementa a la Detached Patient, Study y Result Management Service Class con una
facil peticion] para ser utilizada para obtener informacion sobre una u
nica lista
de entidades de informacion. Esto permite una forma mas flexible de adquirir
informacion comparada con las otras Clases de Servicio.
Print Management se utiliza para administrar el proceso de formateo e impresion de una coleccion de imagenes en una cinta.
Media Storage Service Class

En Media Storage Services class son definidos un set de servicios que permiten el
intercambio de datos usando Media Storage. Media es usado por dos razones:
Las imagenes son almacenadas en Media para el intercambio entre dos procesos sin la especificacion sobre el tratamiento, solamente la transferencia de la
informacion.
Las imagenes son almacenadas para mostrarlas como Sesiones de Pelcula. El
proceso de recepcion debe manejar la informacion de la Gestion de la Impresion
en Media, y mantener sobre esta la informacion del estado del progreso del
trabajo de impresion.
El papel en el cual el proceso esta activado en esta Clase de Servicio no esta relacionado con el papel del compa
nero con la situacion de red, pero con las operaciones
sobre los medios de comunicacion. Tres papeles son definidos: el File-set Creator o
FSC, el File-set Reader o FSR y el File-set Updater o FSU, el nombre se refiere a la
operacion permitida.
Los Elementos de Servicio usados en las Clases SOP de esta Clase de Servicio
especifica las operaciones en las instancias de las Clases SOP como un archivo o como
r
39

una direccion completa de un archivo. Los IODs usados con estos servicios definen la
informacion para ser guardados en un archivo.
Esta Clase de Servicio detalla solo la informacion de almacenaje en un archivo,
independientemente del contenido. La excepcion es una Clase de Servicio especial
(Media Storage Directory Storage) la cual maneja informacion sobre el archivo y un
directorio (DICOMDIR).
Otras Clases SOP de Media Storage Service Class son identicas a las Clases SOP
usadas con el Network Storage Service Class para datos de imagen, Detached Patient
Management, Detached Study Management, Detached Result Management y Print
Management Service Classes. Las Clases SOP almacenadas en archivos pueden ser
usadas directamente por la Clase de Servicio de las Clases SOP correspondientes,
usando los servicios de Media Storage Service Class. Ver figura 2.18.
Figura 2.18: Definicion de objeto compartido con Media Service Class
Los procesos de ambos lados deben estar de acuerdo en que informacion es intercambiada por los medios de comunicacion especificando una lista de Clases SOP
y otras cuestiones. Como no existe ning
un mecanismo de negociacion de asociacion,
debe haber un arreglo que se conforma a un Perfil De aplicaci
on.
Verification Service Class

Finalmente, hay una Clase de Servicio que no se ajusta a ninguna de las categoras anteriores: la Verification Service Class. Esta Clase de Servicio es utilizada
para chequear si una asociacion puede establecerse entre dos procesos e intercambiar
una instruccion sin ning
un dato (C-ECHO), donde ning
un IOD esta involucrado. Esta
proyectado para propositos de chequeo en nivel de conectividad.
40
r
2.3.7.
2.3. ESTANDAR
DICOM
Conectividad
Antes de que las dos implementaciones de DICOM puedan ser conectadas entre
s, algo de investigacion es necesaria si la conexion es posible. Esto alcanza desde el
bajo nivel de conexion fsica hasta la implementacion de la misma Clase de Servicio
en el nivel de aplicacion.
El acercamiento a una conexion network es diferente comparado con un intercambio a traves de media. Durante la negociacion de la Asociacion en un entorno
network un n
umero de detalles pueden todava ser establecidos. En el caso de utilizar
media no es posible y debera ser dirigido de distinto modo.
DICOM solventa esta cuestion utilizando perfiles de sistema (system profiles) para
implementaciones y Perfiles de aplicacion (application Profiles) en un entorno de
intercambio media.
Conformance Statement
Un Perfil de Sistema (System Profile) contiene una lista de las funciones soportadas y limitaciones o extensiones de estas funciones. Juntos forman un perfil que se
debe ajustar al perfil de la parte que tendra que cooperar. Estos perfiles de sistema
son descritos en un documento que debe ser suplido con cada implementacion de
DICOM: la Conformance Statement. Figura 2.19
Figura 2.19: Conformance Statement con Perfil de Sistema
En el nivel de aplicacion una descripcion funcional de la Application Entity, las

Clases SOP soportadas y el papel que ambos sistemas desempe
nan son descritas.
r
41

Para la implementacion de los protocolos de red puede ser referido a documentacion

estandar apropiada, con constancia de las excepciones que restringen el uso en un entorno de red. Las posibilidades de una conexion fsica es tambien un tema que debe
ser dirigido.
Los objetos configurables de una implementacion, tales como el Ttulo de la Aplicacion (Application Title), la Direccion de la Presentacion (Presentation Address) de
ambas implementaciones y partes, que son mencionadas juntas con informacion de
como puede ser configurado. Otros objetos configurables como el tama
no del protocol
data unit (PDU) debe ser listado.
Finalmente el soporte para otros caracteres fijados, ademas del estandar ASCII
(tales como extensiones para idiomas Europeos, Japones, etc) descrito.
Comparando los Conformance Statements, puede ser verificada si la conectividad
a todos los niveles es posible. Si la implementacion de la informacion por todas las
partes involucradas es igual, no se puede asegurar por verificacion con la Conformance
Statement. Dependiendo de como de estricta pueda ser interpretada la semantica
de todos los atributos individuales, el nivel de interoperabilidad es mas predecible.
Actualmente no hay ning
un metodo para asegurar la interoperabilidad.
La Conformance Statements pueden a
nadir mas informacion describiendo en mas
detalle la informacion que manejan. Cuando esta indicado que relaciones estan disponibles
y que selecciones estan hechas por la implementacion comparada con el estandar, este
ayudara a incrementar la conectividad y la interoperatividad.
Perfiles de Aplicaci
on (Application Profiles)
Para media un perfil de sistema detallado tiene poco sentido porque la correspondencia no tendra lugar antes de que se conecten los sistemas, pero por el momento
el medio es llevado a otro sistema. En este caso ambos sistemas deben garantizar que
se ajustan a un formato generico que habilita la aplicacion que ambos implementan.
Este formato generico es llamado Perfil de la Aplicaci
on. Por ejemplo, un sistema
que genera datos de imagen en un medio debe hacerlo conforme a un Perfil de Aplicacion confirmado. Un sistema utilizando esta imagen puede confiar en este Perfil de
Aplicacion para resultar un exito.
Dos aspectos son importantes: el formato del medio y la extension de la informacion capturada en el medio. Un Perfil de Aplicacion asegura estos dos aspectos y
proporciona un tipo de etiqueta que puede ser adjuntada al sistema involucrado y al
medio que contiene los datos. Figura 2.20
El aspecto fsico del medio alude al formato definido en el estandar DICOM.
42
r
2.3. ESTANDAR
DICOM
Figura 2.20: Conformance Statement con Perfil de Aplicacion
La parte de informacion descrita por la Clase SOP es el segundo aspecto incluido

en el Perfil de la Aplicacion.
2.3.8.
Est
andar DICOM
El estandar DICOM esta dividido en varias partes, cada una de ellas describiendo
una cuestion importante tal como las Clases de Servicio, los IODs, temas relacionados
con Network y Media, etc. En la figura 2.21 se ve una vision general de la relacion
entre las diferentes partes.
Las partes de DICOM son 13: las 9 primeras son originales y las partes de la 10
a la 13 fueron propuestas mediante suplementos. La figura 2.21 muestra la relacion
entre las partes del estandar. La figura no debe tomarse como jerarqua; la porcion
de la izquierda representa las partes que definen la red y la comunicacion punto por
punto. La porcion derecha de la figura muestra las partes que soportan medios de
almacenamiento removibles. Las partes 1,2,3,5 y 6 son usadas en ambos ambientes.
En este apartado las partes de DICOM son abordadas en el mismo orden que los
temas planteados en los apartados anteriores. Puede ser usada como linea directiva
para empezar a leer las varias partes del estandar DICOM.
r
43

La parte 1 da una introduccion y una vision general del estandar DICOM y su

relacion con otros sistemas de informacion hallados en el entorno clnico.
La parte 2 define la comformidad (compatibilidad) con DICOM. El certificado de
conformidad (Conformance Statement) debe ser hecho p
ublico por cada fabricante (la
mayora estan en Internet). Este

especificara exactamente cuales clases de servicios
SOP son soportadas por sus dispositivos. Esto guiara a los usuarios a seleccionar productos que trabajen juntos. Al comprar un equipo el usuario debiera saber cuales son
las clases de servicios que necesita para su servicio medico. Esta labor es complicada
por lo que se recomienda a las instituciones de salud asesorarse por especialistas en
el estandar. Cada usuario debiera tener idealmente un perfil de conformidad (User
Conformance Profile) que especifique las clases que requiere.
Las Clases de Servicio y las Clases SOP incluidas en las Clases de Servicio estan
definidas en la parte 4, basadas en los modelos de la parte 3. Los roles de las SCP y
SCU son definidos aqu y se especifica el comportamiento esperado para cada rol en
cada servicio. Esto permite a los implementafores y usuarios entender que se espera
de un dispositivo que soporta una clase en particular. Para cada Clase de Servicio la
operatividad esta delineada siguiendo la descripcion de las Clases SOP individuales.
Para cada papel un proceso puede desempe
nar los requisitos dados por los dos con
detalles del uso de los atributos si es aplicable. Dependiendo del tipo de Clase de
Servicio (compuesta o normalizada) la descripcion es dando un peque
no contexto o
uno detallado. As mismo los temas que tienen que ser descritos por cada parte de la
Clase SOP en la Conformance Statement son listados. La parte 4 utiliza los IODs y
los Servicios definidos en las Partes 3, 7 y 10.
Los IODs utilizados por las Clases SOP son descritos en la Parte 3. Empieza con
la descripcion del IOD completo, dividiendolo en los grupos de IODs compuestos y
normalizados. De cada IOD se da una lista de Information Object Modules. La
u
ltima parte define los atributos individuales agrupados en detalle en los IOMs. Para
los IODs compuestos todos los detalles son listados en esta parte, para los IODs
normalizados el actual uso de los atributos depende del servicio aplicado y descrito
en la parte 4.
En la Parte 5 se describe la codificacion de las Instancias SOP en un conjunto de
datos. Las reglas para las numerosas Representaciones de Valores (Value Representation) y Transfer Syntaxes son definidas.
Los Elementos de Servicio utilizados por las Clases SOP son divididos en dos
partes, Parte 7 para los Servicios Network y la construccion de secuencias de comandos
y Parte 10 para los Servicios Media. En estas partes la codificacion del network
message header y media file header son definidos. El resultado es un mensaje o
archivo que puede ser manejado por el correspondiente mecanismo de intercambio.
44
r
2.3. ESTANDAR
DICOM
Figura 2.21: Relaciones entre las Partes del estandar DICOM.
Los dos grupos de menor nivel tratan con el intercambio fsico de datos. En la
Parte 8 las cuestiones de Protocolo de Red (Network Protocol) son descritas, la Parte
9 define la conexion punto-a-punto (point-to-point conexion) (raramente utilizada) y
la Parte 12 define las cuestiones del formato de Physical Media.
Todos los atributos y UIDs definidos por las varias partes del estandar DICOM son
listadas en el Diccionario de Datos (Data Dictionary) (Parte 6). Es el listado completo
de todos los elementos de datos junto con sus nombres numericos (o etiqueta), sus
nombres de texto, cual es su representacion (texto, n
umero de coma flotante, etc.), si
ellos contienen uno o mas tems (la multiplicidad de valor), y que los valores permitidos
estan para esos elementos que pueden contener solo ciertos valores.
Las cuestiones de Conformance son descritas en la Parte 2 incluyendo la manera
en que un Conformance Statement tiene que ser configurado. Los Perfiles de la Aplicaci
on utilizados para la Media exchange son discutidos en la Parte 12 junto con la
Application Profile layout.
La parte 8 define el soporte de red para cambiar Mensajes de DICOM. Actualmente, TCP/IP y protocolos ISO-OSI son soportados, pero la naturaleza del servicio
superior de capa definido en esta parte es tal que se debe posible expandir a otros
protocolos con facilidad relativa. Una vez fuera de la capa superior de DICOM, el
remanente del protocolo de comunicaciones (o TCP / IP u OSI) sigue los patrones
existentes.
r
45

2.3.9.
Instancias SOP de im
agenes DICOM
En el captulo precedente, se han explicado los conceptos DICOM sin describir en

detalle como se capturan las imagenes dentro de una instancia SOP. En este captulo
se ve con mas profundidad como se estructura la informacion. Se explicara la diferencia
entre los distintos tipos de imagenes, junto a la forma en que el proceso de creacion
crea los datos de la imagen. Finalmente, se vera que manera es la adecuada para usar
la informacion creada por un sistema.
Las clases SOP contienen una definicion de objeto (IOD) y servicios para ser aplicados a ese objeto. En el manejo de los datos de las imagenes, como lo descrito en
DICOM, esta solo limitado por la transferencia (clase de almacenamiento SOP) y por
el medio de almacenamiento. En este captulo, ademas de usar los terminos almacenamiento de clase e instancia SOP, el termino DICOM Image SOP Class/Instance,
se usa para referirse al proceso de los datos de la imagen.
DICOM no tiene forma de describir el tipo de manejo de datos de las imagenes;
el nombre de almacenamiento de clase SOP es poco claro y es confuso si se usa en
otros contextos.
2.3.10.
Modelo de informaci
on de las im
agenes
El manejo electronico de la informacion requiere un modelo para representar la

forma en que la informacion esta estructurada. Esta estructura es necesaria para
tener instancias uniformes y para hacer posible la descripcion de las relaciones entre
instancias de forma clara. Un modelo de informacion de imagen deriva de la forma
en que las imagenes se manejan en un departamento de radiologa. Las imagenes
recogidas de uno u otro aparato, son recopiladas en una carpeta perteneciente al
paciente correspondiente. Las imagenes son ordenadas en la carpeta conforme al tipo
de examen realizado (series de imagenes que estan relacionadas).
Los usuarios de cada tipo de aparato tienen su propia terminologa para esta
ordenacion, como escaner, rodaja, etc. Cuando los datos de las imagenes de diferentes
fuentes tienen que ser recogidas en un ambiente u
nico, debe ser posible ordenar los
datos de las imagenes de diferentes fuentes. Esto es solo posible cuando los datos
estan estructurados de acuerdo al mismo modelo de informacion.
46
r
2.3. ESTANDAR
DICOM
Mapping Real World Examinations

El modelo de informacion de imagen DICOM esta basado en suposiciones sobre
la forma en que la informacion de diferentes aparatos estan relacionados. Ver figura
2.22. Los cuatro niveles de este modelo de informacion son paciente, estudio, serie e
imagen.
Figura 2.22: Modelo de informacion
Nivel de paciente
El nivel del paciente contiene la identificacion y la informacion demografica de
este al cual el estudio le pertenece. Debido a que puede existir mas de un estudio, el
nivel del paciente es el nivel mas alto (cuando toda la informacion es recogida para
un solo paciente se lleva a una cuenta).
Sin embargo, es de practica normal usar el nivel del estudio para recoger la informacion manejada por varios sistemas para un u
nica respuesta a este estudio.
Nivel de estudio
El nivel de estudio es el nivel mas importante en el modelo de informacion. Un
estudio es el resultado de una contestacion a un cierto tipo de examen medico. Todas
las actividades en un departamento de radiologa se centran en el manejo correcto del
estudio. En un estudio, la informacion de identificacion se guarda y puede contener
referencias a informacion relacionada al mismo estudio en un sistema de administracion.
En general, una respuesta puede envolver procedimientos de diferentes maquinas.
Esto da a lugar a una serie de una o mas imagenes, dependiendo del protocolo definido
por el examen realizado. Todos los datos son recogidos juntos en el mismo estudio
r
47

principal. Un paciente puede tener muchos estudios como resultado de otros realizados
anteriormente.
Nivel de serie
Despues del nivel de estudio todas las imagenes se recogen. El nivel de serie identifica el tipo de aparato que crea las imagenes, la fecha y el tiempo de creacion de la
serie y los detalles del tipo de examen realizado y del equipo usado.
Realizar una lista de los terminos usados en los diferentes aparatos tiene que ser
cuidadosamente considerado. Puede haber palabras que aparentemente signifiquen lo
mismo, pero se usan con diferencias en distintos contextos. Las series siempre son
una coleccion de imagenes que provienen de una u
nico aparato. La forma en que
las imagenes estan agrupadas en series depende del uso medico que se les va a dar.
Como las imagenes son adquiridas por una maquina es menos importante para esta
agrupacion. Sin embargo, varios atributos definiran el tipo de adquisicion y se pueden
mostrar en la visualizacion. En algunos casos la relacion entre las imagenes se define
mediante la forma en que la adquisicion ha tenido lugar.
Cuando las adquisiciones en una secuencia tienen relacion espacial o temporal, las
imagenes resultantes de esta adquisicion pueden ser agrupadas en series. Una serie
nueva debe comenzar cuando la relacion existente entre imagenes ya no existe.
Otro criterio para agrupar imagenes puede ser coger los datos de una u
nica parte
del cuerpo hecho durante un estudio completo. Por ejemplo, cuando un aparato produce un n
umero de imagenes del estomago de un paciente desde diferentes posiciones y momentos, las imagenes pueden ser agrupadas en una serie. Algunos sistemas producen mas de una imagen al hacer una adquisicion de datos. Por ejemplo,
algunos escaneres se hacen con un sistema CT, las imagenes reconstruidas desde
cada escaneamiento son recogidas en series y tienen relacion espacial. El siguiente escaneamiento estara en una nueva serie, porque en muchos casos el proceso de escanear
se hace desde diferentes posiciones.
Tambien, en una serie, una imagen de referencia puede ser incluida como una descripcion de la posicion espacial de las rodajas individuales. Ver figura 2.23. Diferentes
reconstrucciones puede ser guardada en diferentes series.
Para cada tipo de aparato medico hay reglas definiendo los contenidos que una
serie debe describir. Las reglas usadas por un sistema dado son parte de un perfil de
sistema en el estatuto de conformidad DICOM.
48
r
2.3. ESTANDAR
DICOM
Figura 2.23: Ejemplo de mapeado de una imagen CT
Nivel de imagen
El nivel mas bajo del modelo de informacion es el nivel de imagen. Cada imagen
contiene la informacion de adquisicion y posicionamiento al igual que los datos propios
de la imagen. Dependiendo del tipo de aparato, el nivel de imagen contiene datos para
una sola imagen, dos imagenes (sistema de dos planos) o una coleccion de imagenes
cogidas en un corto espacio de tiempo (multiframe images).
El uso de multiframes images guarda la informacion duplicada en niveles mas altos,
pero es solo posible cuando la relacion entre los marcos (frames) pueden ser descritos
de una sola manera. Por ejemplo, los incrementos en los movimientos del sistema
y del tiempo son iguales para todas los marcos. Creando un multiframe images es
mas complejo y gasta mas recursos que creando una imagen u
nica. La relacion entre
marcos, la capacidad del aparato y la carga de datos producidos debera ser usada
para determinar si se debe aplicar una serie de imagenes simples o un multi marco
de imagenes.
2.3.11.
Instancias imagen SOP
El modelo de informacion mostrado en la figura 2.22 es una simplificacion del

modelo de informacion completo de imagen DICOM de la figura 2.23 Cada bloque
r
49

en este diagrama representa una entidad de informacion (ver IODs) del IOD compuesto. Las relaciones indican los puntos cardinales para cada relacion de la entidad
de informacion usada en una instancia SOP.
Cada instancia de imagen SOP tiene que contener la informacion estructurada de
acuerdo al modelo de informacion DICOM. Cada instancia de imagen SOP (simple
o multimarco) es una instancia compuesta SOP que contiene el arbol completo de
informacion del modelo de informacion. Todas las imagenes en una serie son de un
mismo paciente, estudio y serie; todas las series son del mismo paciente y estudio, etc.
En cada composicion, toda la informacion relacionada con la imagenes esta disponible.
Este formato hace mas facil el intercambio y el manejo (especialmente el almacenamiento) de la informacion pero incremente la carga de datos cuando se transfiere
un estudio completo.
En este caso las entidades de informacion del paciente y del estudio tienen m
ultiples instancias en la coleccion de las instancias SOP. En contraste, las instancias
normalizadas SOP (con entidades de informacion simples) usan referencias a otras
entidades de informacion, perteneciendo un protocolo mas eficiente, pero requiriendo
un manejo mas complejo.
2.3.12.
Relaciones e indentificaci
on
Cuando se recoge un grupo de Image SOP Instances las cuales tienen relacion entre
ellas, pero estan creadas desde diferentes aparatos, es importante ser capaz de marcar
las entidades de informacion en diferentes niveles. Son importantes dos aspectos:
1. Todas las modalidades deben tener un mapa (codigo) consistente de como pasar
de unos datos de imagen a una instancia SOP.
2. Las entidades de informacion individuales deben contener la identificacion suficiente de hacer un correcto marcado de las entidades de informacion equivalente
en otras instancias SOP.
Estructura de los datos de las im

agenes
El primer aspecto requiere que los datos producidos por los aparatos sean ordenados en series que tengan una relacion como la descrita en la seccion nivel de serie.
En los niveles de serie e imagen, la secuencia de imagenes dentro de una secuencia
debe ser identificada en un aparato.
50
r
2.3. ESTANDAR
DICOM
Figura 2.24: Modelo de informacion de una imagen compuesta DICOM

Las entidades de informacion sobre el nivel de serie debera contener informacion
perteneciente al estudio y al paciente que debe ser comparable con la informacion de
otros aparatos. La mayora de esta informacion viene de fuentes externas como un
sistema de planificacion. Puede ser suministrado al aparato por la interfaz de usuario
o mediante una conexion a un sistema de informacion.
Identificaci
on
Si los datos de imagen tienen que ser almacenados en sistemas los cuales ordenan
los datos examinando el contenido de la informacion de la entidad, debe haber un
consentimiento y un acuerdo para indentificar la informacion de la entidad por todos
los sistemas (aparatos, sistemas de almacenamiento, estaciones de trabajo, etc.) los
cuales manejan la informacion.
Visualizar la informacion es mas amplio que solo ordenar imagenes. La identificacion es tambien usada para acceder a los datos desde otros sistemas de informacion.
Los sistemas de informacion normalmente usan claves que no necesitan ser interpretadas por los seres humanos, pero tienen que ser u
nicos en el ambiente en el que son
usados.
El mecanismo DICOM que se ha definido para estas identificaciones son los UIDs.
Cada una de las entidades de informacion en el modelo de informacion tiene su propia
r
51

UID, excepto para la entidad de informacion del paciente. La forma en que la informacion debe ser identificada se define por otros sistemas de informacion (fuera del
visor DICOM) que tratan con la administracion paciente. En este caso se usa un
identificador ID para el paciente.
Identificaci
on del estudio
Como el estudio de un examen medico realizado por un doctor es el centro de
todas las actividades en un departamento de radiologa, debe ser reflejada en todas
las piezas de informacion las cuales estan relacionadas con el examen realizado.
Para DICOM esta informacion se identifica al nivel de estudio. En la mayora de
los casos el atributo UID de la instancia del estudio (Study Instance UID) identifica la
entidad del estudio de informacion del estudio perteneciente al resultado del examen
del mundo real.
Cuando este UID se usa de una forma consistente por todos los sistemas involucrados, no es difcil relacionar todas las piezas de informacion con los datos de la imagen
en la instancia DICOM SOP. Sin embargo, esto requiere una union entre todos los
sistemas involucrados para transferir la clave del sistema.
A parte de esta union, los UIDs tienen que ser soportados por todos los otros
sistemas, no solo los sistemas involucrados en el manejo de datos de imagenes. Un
sistema que genera los UIDs del estudio juega un mayor rol para distribuir el UID
a otros sistemas involucrados. Normalmente, esto debera hacerse por un Sistema de
Informacion Radiologico (RIS) o por un Sistema de Informacion de Hospital (HIS),
que normalmente puede no siempre soportar el concepto UID.
Cuando el soporte para el UID de la instancia del estudio no esta disponible,
no es posible usar este UID como union a toda la otra informacion. Tiene que ser
reemplazada en esos casos por otras claves. RIS usa actualmente una o mas claves
para acceder a su informacion almacenada, n
umero de registro del estudio, etc. Esas
claves se imprimen en papel que pertenece al estudio. Esta informacion tiene que ser
incluida en la entidad de informacion del estudio y usada como reemplazo al UID del
estudio.
Usar el UID del estudio como union con las partes relacionadas de la informacion es un aspecto importante para proporcionar un modelo de informacion DICOM
consistente, el cual puede ser expandido en otras partes de la informacion en un
departamento de radiologa.
Esta consistencia es muy difcil de mantener cuando el UID del estudio se reemplaza por un RIS o un metodo especfico de identificacion.
52
r
2.3. ESTANDAR
DICOM
Otras identificaciones
A parte de las claves del sistema, los usuarios necesitan acceder a la informacion
y quieren usar identificadores que tengan sentido como el nombre del paciente, su da
de nacimiento, fecha del estudio medico, etc.
Los aparatos medicos tienen que proporcionar una informacion lo mas consistente
posible para permitir una identificacion por parte de los humanos. La informacion de
identificacion puede ser proporcionada por una u
nica fuente cuando una union entre
sistemas es posible.
Por ejemplo, el RIS da el nombre del paciente, su fecha de nacimiento, etc, como
parte de la informacion para realizar un examen medico. Este metodo previene el
error de maquina y permite una forma mas eficiente de funcionamiento.
2.3.13.
Clasificaci
on de los datos de imagen
El modelo de informacion define el modelo jerarquico de las entidades de informacion para dejar claro como la informacion dentro de diferentes instancias SOP pueden
ser agrupadas en diferentes niveles. En este seccion la informacion de la instancia SOP
esta clasificada de acuerdo a las funciones que tiene, pero independientemente de su
lugar dentro del modelo de la informacion. Desde luego, hay una fuerte relacion entre
el proceso de modelado y el proceso de creacion. La siguiente seccion describe la forma
de producir los datos de la imagen.
En la figura 2.25 se muestra una descripcion de la clasificacion y la relacion con
la arquitectura del sistema de un aparato medico. Las diferentes clases son creadas
en diferentes momentos en el tiempo cuando se realiza un examen medico. Cada
subsistema a
nade atributos al resultado final: la instancia de imagen SOP.
Informaci
on del paciente
Esta clase contiene informacion sobre el paciente al que se le realiza un estudio. En
un departamento de radiologa la informacion del paciente se sabe por otras fuentes,
como sistemas de informacion o formularios en papel. Solo tiene que ser registrado
de una manera formal por un n
umero de atributos como nombre del paciente, ID del
paciente, fecha de nacimiento, etc.
La informacion en esta clase es estable, excepto por la correccion de errores de
escritura y cambios de nombre en caso de enlaces matrimoniales, etc. El mantenimien-
r
53

Figura 2.25: Clasificacion de la informacion de la imagen
to de esta informacion se hace por sistemas que act

uan como fuentes para aparatos
medicos.
Uno o mas atributos son clave para la informacion en otros sistemas de informacion. Otros atributos identifican al paciente como una persona o dan mas detalles
sobre su condicion. Un n
umero de esos atributos son muy importantes para el proceso completo de identificacion y conexion a otra informacion en un departamento de
radiologa.
Para permitir la identificacion del paciente y la revision de un estudio, el aparato
medico tiene que incluir esos atributos en las instancias SOP creadas.
Procesos en el hospital tambien tienen que enfrentarse con el manejo de la informacion en casos excepcionales. Por ejemplo, cuando un paciente desconocido es
examinado por emergencia, se deben realizar unos pasos para permitir que la informacion sea correctamente identificada cuando se conoce el nombre del paciente.
54
r
2.3. ESTANDAR
DICOM
Informaci
on del estudio
La informacion del estudio es una clase con una mezcla de informacion fuente. Por
un lado, la informacion sera suministrada desde un sistema como un RIS (Sistema de
Informacion Radiologico) que identifica el estudio a traves de mas de un sistema. Por
otro lado, el aparato medico a
nadira informacion sobre el paciente en el momento en
que el estudio se realiza. Informacion de otros sistemas incluyen una identificacion
del estudio. Un UID de una instancia de un estudio es la forma mas eficiente de
identificacion, pero tiene desventajas. Un atributo alternativo, llamado n
umero de
acceso, puede ser usado en un sistema RIS. En el caso de que no este disponible un
UID de la instancia del estudio desde fuera de un aparato medico, este tiene que
generar el UID de forma que garantice que es el u
nico en el sistema.
Cuando las imagenes de un estudio se copian desde un almacenamiento local
para un destino remoto, es muy importante que se use el mismo UID de la instancia
del estudio. Esto previene la existencia de imagenes con diferentes identificaciones
provinientes un mismo estudio. Tales imagenes nunca pueden ser recogidas juntas sin
la intervencion de un operador.
Otra informacion suministrada al aparato medico son los nombres de los medicos
solicitantes o la lectura de las imagenes y la informacion del paciente dinamica como
la edad, el peso, la ocupacion, etc.
La informacion incluida localmente por el aparato medico identifica el estudio
proporcionando un valor para el atributo ID del estudio y la fecha y hora actual
del estudio. El ID del estudio es solo relevante por el aparato usado para realizar el
examen medico.
Informaci
on de la serie
La clase de informacion de serie es la primera que es completamente generada por
el aparato medico. En esta clase el tipo de sistema, la localizacion y la identificacion
del sistema es dada. La identificacian de las series consiste de un UID de la instancia
de la serie, que u
nicamente identifica la serie en los datos de la imagen y una serie
en la zona usada ID que puede ser usado para hacer una secuencia con series en un
estudio. Los ID de las series tienen solo un significado para el aparato medico en
s mismo, no hay una regla dada para este uso.
Con la informacion de las series, se suministran mas detalles sobre la forma en
que las series son realizadas, la gente involucrada, la parte del cuerpo examinada, etc.
La parte de la informacion del equipo contiene informacion general sobre el sistema
usado por esta serie. Incluye informacion sobre la localizacion, la identificacion del
r
55

tipo y la serie, cuestiones de calibracion, etc. Estos datos pueden ser compartidos
por series pertenecientes al mismo estudio y realizados mediante el mismo aparato
medico.
Se usa un marco de referencia para agrupar imagenes que tienen relacion espacial
o temporal. Esto puede ser usado para dividir series en partes o a traves de mas de
una serie si se aplica la misma relacion. Tal relacion se identifica por un UID de marco
de referencia compartido entre las imagenes involucradas.
Informaci
on de la aplicaci
on
Los atributos en esta clase dan informacion sobre la imagen contenida en la instancia SOP requerida para el diagnostico y otras aplicaciones. Varios ejemplos, desde
un simple texto a
nadido como comentario, hasta detalles como el contraste, terapia
y dispositivos usados durante el reconocimiento medico.
Otro grupo describe la parte del cuerpo examinada usando valores codificados.
Los ajustes del valor de interes (VOI), en la mayora de los casos llamado anchura
de ventana y centro de ventana (window width y window center), son miembros muy
importantes de esta clase. El VOI es la seleccion fuera de la gama completa de los
valores de pixel que son clnicamente significativos cuando se muestra o se imprime la
imagen. Solo el rango especificado tiene que ser convertido a nivel de grises disponibles.
La informacion que dibuja lneas o agrega el texto a la imagen mostrada puede ser
en forma de matrices que tienen que ser agregadas a la muestra en un visualizador,
o ya aplicada a la matriz de pixel. Sumnistrando la superposicion como una informacion separada de los datos de imagen, la imagen puede ser mostrada con o sin la
superposicion, permitiendo que los datos de imagen puedan ser usados como entradas
para el tratamiento remoto.
Informaci
on adquirida
En esta clase de informacion se guardan los ajustes del equipo de adquisicion. El
grado de informacion depende del tipo de aparato y puede tener un rango desde unos
pocos atributos para un sistema sencillo, a una estructura compleja. Contiene detalles
del sistema de adquisicion como los valores usados de los rayos X por ejemplo.
Las imagenes resultantes de la misma adquisicion pueden ser identificadas con un
n
umero de adquisicion. Este agrupamiento depende del sistema y puede ser parte
de series sencillas, pero una adquisicion sencilla puede tambien resultar en m
ultiples series de imagenes, cada una con diferentes caractersticas. La adquisicion no
56
r
2.3. ESTANDAR
DICOM
tiene relacion con el modelo de informacion DICOM y no tiene un identificador UID

equivalente.
Informaci
on de la posici
on
Una clase importante es la informacion dada sobre el posicionamiento de la imagen
dentro del paciente.
Depende del tipo de aparato medico, de la forma en que se describe la matriz de
la imagen posicionada usando terminos sencillos como anterior, posterior, derecha, en
frente, etc. Se debe tener cuidado para asegurar que haya proporcionada informacion
suficiente con la imagen para que no haya visualizaciones ambiguas (sobre todo en
cuestiones de derecha e izquierda).
En una serie que tiene relacion espacial, como puede ser imagenes CT o MR, muchos mas detalles se tienen que suministrar sobre la posicion de las imagenes en el
espacio tridimensional del cuerpo del paciente. Esta informacion permite a sistemas
como planificadores de tratamiento de radioterapia usar el posicionamiento tridimensional para el procesamiento de los datos de las imagenes.
Otro uso de la informacion del posicionamiento es para sistemas de vasculacion
para describir los movimientos dinamicos.
Informaci
on de los datos de las im
agenes
Finalmente, los datos de las imagenes provenientes del sistema de adquisicion y
procesados para producir imagenes visibles en formato digital. Esta clase describe
detalles sobre como los datos de los pxeles deben ser interpretados, como el tama
no
de la matriz de pxeles, el valor representativo de pxel y como estos estan codificados.
Cuando los aparatos medicos son capaces de generar imagenes en color, tiene que
ser suministrada la informacion sobre como los datos son ordenados en diferentes
planos. A parte del formato de la informacion, esta clase contiene los datos de los
pxeles en un marco sencillo, en dos marcos para sistemas de dos planos o en multimarco. Cuando un multimarco se genera por un sistema de dos planos es posible
almacenar los marcos de los dos planos juntos. En este caso los marcos de los dos
planos se almacenan alternados (A-B-A-B-...). Para un multimarco las relaciones de
tiempo entre los marcos individuales se describen mediante otros atributos.
La imagen se identifica u
nicamente por el UID de la imagen. Como una instancia
SOP de una clase de imagen SOP siempre incluye una porcion de la imagen, el
r
57

UID de la imagen se usa tambien como UID de la instancia SOP. Este UID se usa
para identificar la instancia cuando se transfiere o se recupera desde un almacen de
imagenes o para identificar la entidad de la imagen usandola en un arbol jerarquico
de informacion.
2.3.14.
Extensi
on de la informaci
on
Para el almacenamiento de toda la informacion descrita en las clases de arriba

se definen atributos que se agrupan en IODs (Information Object Definitions) los
cuales dan una descripcion generica de las instancias SOP para cada tipo de aparato
medico. Los atributos que se usan actualmente deben ser descritos en el Estatuto de
Conformidad (perfil del sistema).
No siempre es posible guardar toda la informacion generada por un aparato en un
IOD estandar. En casos el equipo tiene nuevos campos los cuales necesitan informacion
adicional para alamacenarlos en un nuevo IOD. Se debe tener cuidado en que las partes
que usan esta informacion seran capaces de entender esta nueva informacion. Estos
detalles se tienen que publicar en el Estatuto de Conformidad. Si el uso se acepta, la
nueva informacion llega a formar parte del estandar.
La extension puede no influenciar la semantica de la informacion guardada en
los atributos estandares. Tiene que ser un subconjunto apropiado, compatible con el
IOD del que deriva. En otros casos, el equipo de un vendedor u
nico, puede a
nadir
informacion para ser usada solo en la combinacion de sistemas o solo por el mismo
sistema que ha generado los datos. En esta situacion, no existen detalles sobre la
informacion que tiene que ser publicada en el Estatuto de Conformidad. No hay
intencion por otras partes de usar esta informacion adicional.
Para permitir la extension de informacion, DICOM ha definido dos tipos de atributos: atributos estandar y privados.
Los primeros se usan para codificar los atributos descritos en el estandar IOD. Si
no hay extensiones o cambios en los IODs, la clase SOP es una clase SOP estandar.
Los segundos definen atributos o usan atributos estandarizados no pertenecientes
al IOD de una clase SOP especfica, no se pude seguir llamando clase estandar SOP
y depende del efecto que cambia a uno de los siguientes tipos:
Clase SOP extendida: cuando los atributos adicionales no cambian el uso de la

clase SOP. En este caso es un superconjunto, cuando se usa por sistemas los
cuales no son conscientes de las a
nadidos, se pueden ignorar y la imagen puede
ser manejada como se dice en la clase SOP estandar. Una clase SOP extendida
58
r
2.3. ESTANDAR
DICOM
usa el mismo UID que la clase SOP estandar. Las diferencias entre las dos clases
se muestra en el Estatuto de Conformidad.
Clase SOP especializada: cuando las adiciones cumplen con el modelo de informacion, pero la clase ya no es un superconjunto. Como consecuencia, el UID de
la clase SOP estandar puede no ser usado; se debe usar un UID privado para
esta clase SOP. Los socios que manejan las instancias SOP conocen el UID privado y pueden manejar la informacion. Otros no pueden aceptar la clase SOP
durante la negociacion de la asociacion o, cuando se abre un archivo DICOM
desde un medio DICOM.
Clases SOP privadas: no siguen el modelo de informacion DICOM y se usan
en un contexto completamente privado. Usan mecanismos proporcionados por
DICOM para transferir la informacion. Las clases SOP privadas usan UIDs
privados para prevenir usos incorrectos de la informacion.
Si una de las tres clases SOP arriba mencionadas se definen con la intencion de
llegar a ser parte del estandar DICOM, los detalles se publican en el Estatuto de
Conformidad. De otra forma, solo se usan en un ambiente cerrado.
2.3.15.
Tipos de im
agenes
DICOM define un n
umero de tipos de clases de imagenes SOP, dependiendo del
aparato medico que crea los datos de las imagenes. Cada tipo tiene su propio IOD
para a
nadir informacion especfica del aparato a la instancia de la imagen SOP.
Todas las instancias de las imagenes SOP comparten un mnimo juego de informacion que permite a una aplicacion visualizadora manejar las imagenes independientemente de su tipo.
Una clase de imagen SOP esta disponible para encapsular las imagenes que no
estan disponibles en el formato digital y s capturadas en formato de pelcula o de
vdeo.
Tipos gen
ericos de im
agenes
Las instancias de las clases de las imagenes SOP tienen un conjunto basico de
atributos; ver figura 2.26. El conjunto mnimo de atributos requeridos para una instancia de imagen SOP consiste en el siguiente grupo de atributos:
r
59

Atributos identificadores: UID de clase SOP, UID de la instancia del estudio,

UID de la instancia de la serie y UID de la instancia de la imagen (= UID de
la instancia SOP).
Tipo de aparato.
Descripcion de la matriz de pxeles: muestra por pxel, filas, columnas.
Interpretacion del valor del pxel: interpretacion fotometrica.
Codificacion de los pxeles: bits asignados, bits almacenados, bit alto, representacion de pixel, configuracion plana.
Matriz de pxeles: datos de pxel.
Este mnimo conjunto permite mostrar los datos de pxel y proporciona la identificacion en el nivel de sistema, para el caso de la instancia SOP para adherirla modelo
de la informacion. A
nadiendo mas informacion al menos para los tres primeros niveles del modelo de informacion, hace mas entendible a la instancia SOP. Los atributos
que identifican la instancia SOP para seres humanos y permiten que la imagen sea
mostrada.
Figura 2.26: Juego basico de atributos de las instancias de imagen SOP

A
nadiendo mas informacion para al menos los tres primeros niveles del modelos de
la informacon, hace la instancia SOP mas comprensible. Los atributos que identifican
60
r
2.3. ESTANDAR
DICOM
la instancia SOP para los seres humanos y permiten que la imagen sea visualizada
con los correctos ajustes de ventana son:
Nivel de paciente: nombre, ID, da de nacimiento, sexo.
Nivel de estudio: fecha del estudio, hora, nombre del medico, ID del estudio,
n
umero de acceso.
Nivel de serie: n
umero de serie, fabricante, nombre de la institucion.
Nivel de imagen: n
umero de imagen, tipo de imagen.
Ajustes de presentacion: ancho de ventana, centro de ventana.
Los atributos listados arriba son en la mayora de los casos atributos del tipo 2
(deben ser suministrados, pero pueden faltar) o del tipo 3 (opcionales).
Tipos de im
agenes especiales
El formato generico descrito arriba se usa en la definicion de cada clase SOP,
pero depende del tipo de modalidad, esto se extiende con la informacion entregada
sobre la adquisicion, etc. El n
umero de imagenes especializadas esta creciendo por
la aparicion de nuevas modalidades. Normalmente, las modalidades siguientes tienen
una definicion de la clase SOP de almacenamiento en el estandar DICOM:
Radiografa computada IOD (Computed Radiography IOD), usada por los sistemas radiograficos tradicionales que trabajan con fosforo que brilla al leerse
con sistemas como PCR.
Tomografa computada IOD (Computed Tomography IOD) para escaneres CT.
Para este tipo de aparatos el posicionamiento es importante, para montones de
imagenes, para crear vistas tridimensionales.
Resonancia magnetica IOD (Magnetic Resonance IOD) para sistemas MR. A
parte de la misma informacion que para escaneres CT tambien se da informacion
adicional sobre el protocolo de adquisicion.
Medicina nuclear IOD (Nuclear Medicine IOD) para camaras usan isotopos
radiactivos. Contienen imagenes de especial formato para este tipo de aparatos.
Las imagenes son en multimarco formato.
Ultrasonidos IOD (Ultrasound IOD) para este tipo de equipos. Estos contienen
detalles sobre la posicion y la adquisicion de la imagen. Las imagenes pueden
ser en color y se puede usar el multimarco.
r
61

Angiografa con rayos-X IOD (X-Ray Angiographic IOD) para sistemas digitales cardiologico y basculares. Este formato puede capturar una cadena en
multimarco o imagenes simples.
Radiofluoroscopa de rayos-X IOD (X-Ray Radiofluoroscopic IOD) para sistemas como sistemas angiograficos.
Por cada uno de los IODs, se describe una lista de modulos en el estandar DICOM.
El uso de unos ciertos modulos a veces dependen de capacidades o condiciones de ciertos sistemas. Los modulos se seleccionan, o bien desde un grupo de modulos comunes
usados para todos los IODs de almacenamiento SOP, o bien desde modulos especficos
para solo un tipo de IOD.
Estos modulos contienen atributos especiales para ese tipo de IOD. Esos modulos,
y a veces atributos individuales, los redefinen y extienden para el IOD generico. En
el estandar DICOM los IOD, IOM y los atributos se listan.
Imagen Secundaria de la Captura

La Clase SOP Secondary Capture es una especial Clase SOP de imagen. Es utilizado para el almacenamiento de imagenes en formato diferente al de DICOM, dentro
de un ambiente de DICOM convirtiendolas al formato de DICOM. De esta manera la
informacionde la imagen en formato diferente al de DICOM se puede combinar con la
informacion de la imagen de los sistemas DICOM que pertenecen al mismo estudio.
Esta Clase SOP incluye imagenes capturadas de equipos de pelcula digital, capturas de pantallas, etc. El Secondary Capture IOD no contiene ning
un detalle sobre
la modalidad y la adquisicion de los datos de la imagen. Da solamente los detalles
sobre como los datos de la imagen fueron capturados.
El IOD permite que la imagen sea manejada como cualquier otra modalidad. En
un n
umero de casos contiene solamente los valores del nivel de gris de una captura de
pantalla que pueda verse. Por ejemplo, una imagen hecha con una captura de pantalla
contiene solamente los niveles grises en la matriz del pixel (como una fotografa).
Pero, en otros casos, contiene una matriz verdadera del pixel que necesite un valor
de pixel a la conversion de gris, permitiendo la manipulacion de la representacion. Esto
permite utilizar la Clase SOP Secundary Capture para almacenar datos de la imagen
en modalidades para las cuales no hay IOD estandar disponible. Esto requiere el retiro
de toda la informacion relacionada modalidad de la adquisicion, de la colocacion y
otros. Solamente el paciente, el estudio, la serie, el recubrimiento, y otra informacion
adicional que este disponible.
62
r
2.3. ESTANDAR
DICOM
El formato permite la posibilidad de salvar una descarga de pantalla en una modalidad. Este metodo tiene la desventaja que la matriz de la imagen, en la mayora de
los casos, no es cuadrada y contiene la informacion del paciente y la otra informacion
que es duplicada por las cualidades estandares. Cuando esta exhibido sin medidas
especiales, mostrara la imagen con un formato reducido (en la mayora de los otros
casos la zona de visualizacion de la imagen es cuadrada) y mostrara la informacion
del paciente dos veces.
2.3.16.
Procesando imagen
Una tubera del procesamiento de una imagen describe los pasos del proceso que
traducen la informacion adquirida (por X-Ray, SR., ultrasonidos, equipo, etc.) a una
imagen presentada en un vdeo o muestra una pelcula. Algunos de los pasos del proceso dependen del sistema de la adquisicion, otros mejoran la presentacion, o utilizan
una serie de informacion adquirida para crear las imagenes derivadas (substraccion,
imagenes tridimensionales, etc.). Los siguientes pasos del proceso se han distinguido:
Pasos en el proceso de la adquisici

on que incluyen la conversion a los datos
digitales, correciones, reconstrucciones, etc. Estos pasos estan en la mayora de
los casos realizados por el sistema de la adquisicion.
Pasos intermedios del proceso para realzar la presentacion o crear la derivaron
de imagenes.
Pasos del proceso de la presentaci
on dando por resultado una imagen que es
mostrada o impresa.
Un n
umero de los pasos de proceso son realizados por el sistema de la adquisicion.
Otros pasos de proceso se pueden ejecutar en un sistema distribuido. En este caso
una transferencia de la informacion es necesaria. Esto requiere una definicion de la
informacion y un protocolo entre del ambos sistemas. Dos tipos de intercambio de
informacion pueden ser definidos:
Datos procesados de la imagen que necesita solamente la conversion apropiada

a los niveles grises para mostrarla.
Los datos de la imagen convenientes para la transformacion posterior van junto
con los parametros del proceso. Este grupo puede estar partido en:
usar datos procesados de la imagen o
r
63

Datos crudos(Raw) de la imagen que no es conveniente para la exhibicion

sin los pasos intermedios del proceso.
Los diversos tipos de pasos del proceso y de los datos transferidos de la imagen se
muestran en el cuadro 2.27.
Figura 2.27: Pasos del proceso y tipos de datos de la imagen
Datos Raw de la imagen

El intercambio de la informacion de la imagen en la tubera del proceso de la
imagen que contiene datos crudos (Raw) de la imagen necesitan cuidado adicional.
El proceso adicional es requerido para la correcta presentacion de la imagen.
El proceso para este tipo de imagenes incluye funciones tales como substraccion
digital, ciertos dominios de filtracion de frecuencia o combinar partes de imagenes a
una sola imagen mas grande.
Para este tipo de proceso los datos de la imagen tienen que estar acompa
nados
con la informacion de los pasos del proceso para que puedan ser invertidos, procesando parametros e indirectamente para los pasos que se realizaran, la adquisicion
adicional y colocado de la informacion, etc. Las Instancias SOP usadas para este tipo
de imagenes, no se piensan para el uso general, as que una Clase SOP especializada
o privada es necesaria. La informacion se divulga solamente a las partes implicadas.
Datos procesados de la imagen

La representacion correcta es un factor importante en la prevencion de la interpretacion incorrecta de una imagen cuando se muestra en diversos sistemas, con
diversos metodos y una variedad de entornos. La conversion gris de la escala debe
cuidarse de todo el comportamiento no linear del dispositivo de exhibicion, del entorno
y del ojo humano; vease la figura 2.28.
64
r

2.3. ESTANDAR
DICOM
Figura 2.28: Muestreo

El resultado de los pasos del proceso de la presentacion de una imagen es correcta
seg
un lo interpretado por el usuario del sistema de visualizacion.
La entrada de este proceso de presentacion requiere que los pasos del proceso que
preceden creen valores del pixel de tal manera que todos los valores del pixel tienen
un valor significativo unos con respecto a otros. Estos valores dependen del tipo de
sistema o/y del uso de los datos de la imagen.
En el caso de sistemas de la Rayos X los valores absolutos de los pixeles no son
significativos, solo el valor relativo se utiliza para la conversion a los niveles grises.
Para imagenes CT y MR los valores del pixel son un factor importante para el uso
clnico y se deben presentar junto con la imagen mostrada. Los pasos del proceso
deben tener cuidado con los valores proporcionados de pixel en la correcta escala.
Conversi
on y selecci
on de los valores del pixel
En un n
umero de situaciones los valores del pixel provistos por los pasos precedentes (adquisicion e intermedio del proceso) tienen que ser utilizados para la transformacion posterior. Esto requiere a veces otra relacion entre los valores de pixel seg
un
lo esperado por los pasos del proceso de la presentacion. Por ejemplo la relacion entre
los valores de pixel estan en una escala logartmica y no proporcional a las medidas
fsicas. Antes de que la conversion a los niveles grises pueda ocurrir un paso del proceso debe ocurrir, basado en los valores provistos junto con los valores del pixel; vease
el cuadro 2.29.
Seg
un algunos usos clnicos la exhibicion de la informacion adquirida tiene que ser
r
65

Figura 2.29: Datos de pixel con la conversion de los valores del pixel
ajustada a un subconjunto de la gama completa de los valores del pixel. El resultado
es la exhibicion de los valores del pixel relevante usnado la escala de nivel de grises.
Este subconjunto se llama una ventana, y se puede especificar por su valor de centro
y el tama
no de la ventana.
Las conversiones y las selecciones antedichas dependen del tipo de de sistemas y
el uso de los datos de la imagen. Algunos sistemas aplican ya estos ajustes a los datos
de la imagen antes de la transferencia. Otros sistemas transfieren los datos originales
de la imagen con una descripcion de las funciones que se aplicaran por el sistema de la
vision. En el primer caso que no hay reajuste posible, es conveniente para el sistema,
produciendo siempre las imagenes para un solo tipo de uso.
Pasos de la Presentaci
on
Los pasos de la presentacion convierten los valores del pixel a una imagen exhibida
en la pantalla o pelcula de video. Estos pasos tienen en cuenta los siguientes puntos:
Los valores del pixel no pueden tener ninguna relacion o valor semantico correcto
(no linear, no escalado, etc.).
Una gama de los valores del pixel debe ser presentada.
La representacion del valor del pixel en la pantalla o la pelcula de video debe
ser perceptualmente correcta.
Para una descripcion del proceso de la presentacion vease la figura 2.30.
Las primeras dos funciones dependen del contenido de la informacion de la imagen
y tienen que ser almacenadas en la Clase SOP. La funcion pasada es dependiente del
66
r
2.3. ESTANDAR
DICOM
Figura 2.30: Pasos del proceso de la presentacion de una imagen

dispositivo. El resultado de las primeras dos funciones debe dar lugar a una gama
de los valores del nivel de gris que se aseguran de que el resultado de la correccion
dependiente del dispositivo sea igual en diversos sistemas. Estas dos o tres funciones
tienen que ser aplicadas a los datos del pixel en un paso de proceso para prevenir la
perdida de calidad de la imagen debido a la acumulacion de errores de redondeo en
cada funcion.
Requisitos para el procesado de la imagen

La conclusion de la seccion anterior conduce al requisito de que los datos procesados de la imagen intercambiados entre los sistemas deben contener la suficiente
informacion para dar lugar a imagenes equivalentes cuando estan utilizados en diversos sistemas cada uno con su propia correccion del dispositivo. Esta informacion debe
ser estructurada de una manera tal que permita que una puesta en practica combine
todas las funciones necesarias en un paso.
En DICOM hay actualmente dos maneras de describir las funciones:
para una funcion linear es necesario dar factores (y = ax + b),
para la conversion no linear el mecanismo de una LUT esta disponible: para
cada gama de los valores de la entrada se almacena un valor de la salida. Un
ejemplo para una conversion no linear es las curvas redondeadas lisas para la
tapa y el fondo de una ventana; vease la figura 2.33
La u
ltima manera de describir una conversion no linear tiene una desventaja importante. Introduce cambios precipitados en el valor de la salida cuando la entrada
r
67

valora pasos en un lmite de la gama. Si una secuencia de estas tablas del look-up
(LUT) se esta utilizando, baja la calidad de la actual imagen. Tambien no permite
que la composicion de las funciones sea realizada en un paso (prevenir la perdida de
la calidad de la actual imagen). La carencia de las posibilidades para especificar una
funcion no lineal en forma de un formula matematica es una desventaja importante
de las definiciones actuales de DICOM.
Im
agenes Procesadas DICOM
Para las imagenes transferidas con DICOM, se definen un n
umero de modulos que
contienen la informacion para el paso de la presentacion descrita arriba:
M
odulo del pixel de la imagen que contiene los valores de la muestra del pixel, almacenado en una cadena de los datos del pixel, con las cualidades que
describen la codificacion y el formato de la matriz del pixel.
Modalidad LUT (MOD LUT) con una descripcion de la funcion para la conversion. Figura 2.30.
Valor de interes LUT (VOI LUT) con una descripcion de la funcion de seleccionar una ventana en la gama de los valores del pixel. Figura 2.30.
Sobreponga moduloslos cuales agregan la informacion grafica para ser mostrar
que sobrepone la imagen exhibida.
Dependiendo del requerimiento del procesado del modulo MOD LUT, el modulo
VOI LUT o ambos pueden estar presentes al lado del modulo del pixel de la imagen.
Un VOI LUT es muy probable estar presente para poder mostrar correctamente las
imagenes par ciertas aplicaciones clnicas.
La informacion puede contener lneas y crculos para mostrar el campo de interes,
o una bitmap con cadenas de caracteres para anotar la informacion en la imagen
mostrada. Esta informacion se provee como entidad separada. Cuando esta informacion se agrega a los datos del pixel se tienen muchas limitaciones con el uso de los
datos de la imagen. En este caso el valor de algunos de los pixeles se cambia al valor
del recubrimiento.
Paso de decodificar
El proceso de descodificacion de la matriz del pixel desde las cadenas del Cell
Pixel, es utilizando dos grupos de cualidades del Image Pixel Module. Vea la figura
2.31
68
r
2.3. ESTANDAR
DICOM
Figura 2.31: Decodificacion de los Datos de Pixel

Bits Allocated, Bits Stored, y High Bit para decodificar el Pixel Sample Values
desde Pixel Data Stream, y
Filas, columnas, muestras por pixel y configuracion planar para pedir las muestras del pixel en la matriz de la imagen.
Una sola muestra del valor del pixel se contiene en una celula de pixel (Cell Pixel).
Ademas del valor de la muestra, otro pixel de informacion puede ser almacenado en el
espacio no ocupado por la celula del pixel. La secuencia de los valores del Sample Pixel
se almacenan en la matriz del pixel con la dimension en la columna, fila, muestras
por atributos del pixel. Cuando se utiliza mas de un plano, la configuracion planar
describe como los valores de la muestra se ordenan en la secuencia de datos del pixel.
Los atributos del Pixel Representation contiene el formato de datos de los valores
de la muestra del pixel: enteros con signo o sin signo.
Paso de Normalizaci
on
Ocurre despues de decodificar la conversion de los valores del pixel significativo,
para un cierto tipo de Clase SOP de la imagen (Image SOP Class). El resultado es
una gama normalizada de los valores del pixel convenientes para la conversion a los
niveles grises y seg
un que espera para ese tipo de modalidad y de su uso clnico.
Por ejemplo, para los Rayos X, la intensidad es proporcional a los valores de pixel,
r
69

para los sistemas CT los valores de la muestra del pixel se convierten a la escala de
Hounsfield, etc.
En caso de que solamente una escala pueda ser utilizada, dos atributos son necesarios describir la funcion:Rescale Slope y Rescale Intercept; ver la figura 2.32
Figura 2.32: Modalidad dependiendo de la escala y la conversion
Cuando una conversion no linear tiene que ser aplicada se utiliza el mecanismo de
la tabla del look-up.
Paso de conversi
on a escala de grises
En la mayora de los casos la gama completa de los valores normalizados de la

muestra del pixel tiene que ser reducido a una gama secundaria que contenga la valiosa
informacion para el uso de la imagen. En su conversion, esta tiene que ser convertida a
la representacion del nivel gris. Para algunos usos mas entonces una gama secundaria
se selecciona. En ese caso, las ventanas separadas tienen que trazar diversas gamas
de niveles grises.
La ventana es descrita por dos atributos. Los dos atributos permiten solamente una
conversion linear del rango seleccionado, la conversion no linear se pueden alcanzar
por medio de una tabla look-up. Cuando no se utiliza ninguna tabla, las ventanas
son descritas por el valor de centro del pixel (centro de la ventana) y el tama
no de la
ventana (anchura de la ventana); ver figura 2.33.
70
r
2.3. ESTANDAR
DICOM
Figura 2.33: Conversion a escala de grises

Paso de Recubrimiento
Uno o mas modulos separados especifican donde los bitmap del recubrimiento se
deben colocar en la matriz de la imagen. Opcionalmente, el color de los contornos
puede ser especificado. Los bitmap que pertenecen a estas imagenes se pueden incluir
en la secuencia de datos del pixel o en matrices separadas del pixel.
En las posiciones correspondientes en la matriz del pixel, tienen que ser fijados los
valores para el contorno del recubrimiento antes de enviar la imagen del nivel gris al
paso siguiente.
Paso de la correcci
on del dispositivo
Los valores convertidos de la muestra del pixel tienen que ser corregidos para
alcanzar una comprension correcta de la imagen. Las correcciones son el dispositivo y
el entorno dependiente y tienen que ser determinadas por el calibrado del dispositivo
e incorporando el resultado de la calibracion como funcion de la correccion que se
aplicara a los valores del nivel gris.
Para prevenir la perdida de calidad debido a la ejecucion de las dos o tres funciones
(vease la figura 2.30) por separado, todas las funciones tienen que ser combinadas en
una tabla look-up que convierta los valores almacenados del pixel directamente
en una representacion perceptualmente correcta. Esto, sin embargo, funcionara solamente cuando todas las funciones se describen y no se almacenan matematicamente
en tablas look-up.
r
71

2.3.17.
Aplicaci
on de los Datos de las Imagenes
Las Clases SOP de la imagen estan en general generadas en modalidades. El

resultado se muestra en la impresion de la pelcula. Los sistemas del almacenaje
protegen las imagenes mientras tanto, o archivan estas imagenes para la referencia
ulteriormente.
En el intercambio de datos entre los sistemas, cada sistema puede tener diversas vistas de la informacion, aunque toda la informacion de la Image SOP Instance
este transferida entre cada sistema implicado. Incluso cuando un sistema en una cadena no esta utilizando la informacion, otro sistema que esta utilizando la informacion,
esta confiando en pasar la informacion completa de la cadena entera, vease la figura
2.34.
Figura 2.34: Ciclo de vida de la informacion de una Image SOP Instance
Sistemas de almacenamiento de im
agenes
Los sistemas de almacenamiento de imagenes usan un n
umero de atributos identificatorios para almacenar las instancias de imagen SOP.
En primer lugar, estos atributos se usan para recoger todos los datos de las
imagenes pertenecientes al mismo estudio. La instancia UID del estudio (Study Instance UID) es el atributo clave. Pero cuando este no se usa consistentemente, se
tienen que usar otros atributos como el ID del paciente, n
umero de acceso, etc.
En segundo lugar, unos atributos pueden ser usados por sistemas que quieren encontrar instancias de imagen SOP en el sistema de almacenamiento. La clave principal
72
r
2.3. ESTANDAR
DICOM
en este caso es la instancia UID del estudio y la instancia UID de la serie. Son posibles
tambien b
usquedas basadas en el nombre del paciente, fecha del estudio, etc.
Para el uso de sistemas de almacenamiento un valor muy significativo para estos
tipos de atributos se tiene que suministrar por los creadores de la instancia de la
imagen SOP. Los atributos que contiene los parametros de adquisicion y los datos de
la imagen se almacenan pero no tienen significado para un sistema de almacenamiento.
Estaciones de revisi
on
Una estacion de revision es basicamente usada para visualizar las imagenes hechas
en uno o varios aparatos. Recoge o busca las instancias de imagen SOP, en un sistema
de almacenamiento, perteneciente a un cierto estudio. Mostrara la imagen junto a la
informacion del paciente, ajustes de adquisicoon, informacion del diagnostico, etc.
Los ajustes para el proceso de presentacion, como los seleccionados en el aparato de
captura, son muy importantes. Cuando los pasos de presentacion se procesan de forma
correcta, los resultados mostrados deberan ser iguales a los originales mostrados por
el aparato medico de captura de la imagen.
Para informacion adicional de otros sistemas, se usan atributos identificadores
como la instancia UID del estudio.
Estaciones de procesamiento de im
agenes
Las estaciones de trabajo capaces de procesar los datos de las imagenes tienen requerimientos adicionales. Se necesitan los parametros de adquisicion y posicionamiento para la realizacion de pasos adicionales de procesamiento. Dependiendo del tipo
de procesamiento la entrada es un conjunto de imagenes procesadas o no procesadas.
En este caso, en la relacion entre las imagenes, es importante ordenar los datos de las
imagenes de forma correcta para el procesamiento.
Los resultados de este procesamiento son nuevos datos de pxeles que son almacenados en una nueva instancia de imagen SOP que tiene su propio ciclo de vida, en la
mayora de los casos, relaciones con los datos originales usados por la imagen.
r
73

Reutilizaci
on de datos
Una categora final de las aplicaciones es el sistema que ha creado la instancia de
imagen SOP. En este caso los datos antiguos de la imagen pueden ser usados cuando
hay una nueva visita del mismo paciente con el mismo tipo de examien. Los datos
de adquisicion y el posicionamiento pueden ser reutilizados, o la imagen puede ser
visualizada como una referencia para el nuevo examen.
Categoras de aplicaci
on
Como lo mostrado arriba, las exigencias de los sistemas individuales en el ciclo
de vida de una una instancia de imagen SOP son diferentes. Cuando un sistema
produce los datos de la imagen, debe estar alerta de que todos los sistemas que estan
intentando ser parte del ciclo de vida deben recibir suficiente informacion. El estatuto
de conformidad (conformance statement) debe describir, para cada tipo de sistema,
la informacion adecuada y que procesamiento no puede ser aplicado.
Para ayudar a la seleccion de estos tipos de sistemas, los requerimientos pueden
ser divididos en categoras de aplicacion. Una categora alta numerada incluye la
categora baja numerada. Se definen las siguientes categoras:
1. Categora de almacenamiento: solo identifica los atributos requeridos.

2. Categora de visualizacion: solo se requieren los atributos para una correcta
presentacion.
3. Procesamiento simple - medidas de volumen y distancia: requiere algunos atributos mas que describan que informacion esta en la imagen.
4. Procesamiento complejo - sustraccion de imagen y MRP: requiere informacion
especfica sobre el posicionamiento y relaciones.
2.3.18.
El futuro de DICOM
El alcance del problema de comunicacion de imagenes medicas es tan extenso,

que a
un hay mucho por hacer. Quiza primero es la demostracion de que DICOM
trabaja como una especificacion y un patron. En los u
ltimos 2 a
nos, el RSNA ha
ayudado a este papel. Con un contrato a Mallinckrodt una Institucion de Radiologa
para desarrollar el software, el RSNA, miembros de NEMA, y ACR han trabajado
sobre demostraciones de DICOM. Mallinckrodt provee los nodulos centrales de prueba
74
r
2.3. ESTANDAR
DICOM
(CTNS) que trabajan como servidores para retener imagenes y administrar la red.
Los fabricantes conectan a estos CTNS para usar su implementacion del Estandar
de DICOM, y usando el servicio clases, o envos, recibe, inquiere, o imprimen las
imagenes (imprimir sobre la pelcula que requiere un procesamiento mojado no es
factible en el area de diagnostico a causa de los requisitos de tubera). Los fabricantes
pueden escoger tambien enviar imagenes, o recibir imagenes de un fabricante diferente.
Algunos fabricantes pueden cumplir tambien una conexion al equipamiento en el area
Tecnica de documentos de prueba, y algunos pueden mostrar la implementacion de
la interfase HIS/RIS con apoyo del servicio de clases (el servicio de direccion clases).
Mediante un n
umero importante de esfuerzos independientes de implementacion, la
calidad del patron en suplementario hace efectiva la interoperatibilidad, que ya se ha
demostrado. El alcance de la imagen medica se extiende mas alla de las imagenes
radiologicas. Endoscopistas, patologos, dentistas, y dermatologos (por nombrar solo
cuatro justo areas de especialidad) todas trabajan con imagenes como parte de su
practica.
Recientemente, los representantes de las sociedades profesionales de estos grupos
han contado con un grupo de trabajo especial de ACR-NEMA para comenzar planificando, como ellos podran aprovechar del Trabajo de DICOM. El enfoque de DICOM
a objetos orientados a dise
no hace este proceso relativamente directo. Los miembros
de las sociedades profesionales pueden proveer la experiencia sobre la construccion
apropiada de objetos de informacion, y los grupos de ACR-NEMA pueden entonces
ayudar a implementarlos en el estandar de DICOM.
La mayora del nuevo equipamiento cardaco de los laboratorios producen imagenes
digitales, pero como con CT o MR, los fabricantes usan distintos formatos y medios
de almacenaje. El convencional 35 mm de pelcula evita este problema pero no es una
solucion eficaz en funcion de los costos cuando las imagenes estan en forma digital
para comenzar.
El almacenado de la informacion sobre alguna forma de medio removible. Esta es
necesaria a causa de la naturaleza no de red los laboratorios cardiacos y angiograficos,
y a causa de la necesidad de proveer de imagenes de cine a otros especialistas que
pueden un equipo solo. Se ha producido la parte 10 de DICOM que describe el Medio
de Almacenaje y el Formato de Archivos. Esta parte son unos conjunto de definiciones
de medios independiente. El formato de archivo describe como poner un conjunto de
datos de DICOM en un archivo junto con un directorio para indicar el contenido de
tales archivos. El formato de archivo incluye un area llamado Preambulo de Archivo
que es visto primero por el dispositivo que lee el archivo.
Cada aplicacion que necesita grabar archivos en un medio puede requerir medios
diferentes. Por ejemplo, la cardiologa necesita un medio de alta capacidad con acceso
rapido para pelcula de cine de 35 mm. Los especialistas de ultrasonidos no cardiacos,
sin embargo, probablemente no necesitaran tan alta capacidad, aunque ellos necesiten
r
75

capacidad de cine. Por esto, las partes 11 y 12 de DICOM definiran el Patron de

intercambio de Medios a todos la a los niveles. Cada aplicacion tendra un perfil
de aplicacion que sera un corte vertical a traves de todas las capas de DICOM.
De hecho, especificara para una aplicacion determinada, las clases SOP, sintaxis de
transferencia, estructura de directorios, archivo basico senice, formato de medios, y el
formato de medio necesitado. Estos perfiles son necesarios en parte porque, aunque la
comunicacion es sobre conexiones de red, la comunicacion fuera de lnea por medios
inhibe el proceso de negociacion.
Sin una duda, DICOM es de los mas ambiciosos proyectos en imagen medica
emprendido por la industria y sociedades profesionales. Es un patron complejo a
causa del tama
no de su contenido, pero es implementable y u
til. El estandar ofrece
un balance correcto entre el objetivo pragmatico de apoyo de rapida implementacion
en productos actuales y una fundacion modular solida que asegura una capacidad
para evolucionar y responder a futuras necesidades. La cantidad de trabajo ya hecha
sobre DICOM es una parte de la razon del interes desde otras especialidades que usan
imagenes. Mediante el uso de la experiencia disponible en sociedades profesionales,
han podido definirse objetos informativos y los servicios. Estos pueden hacer uso de
la estructura de DICOM para la implementacion.
DICOM se desarrollo con la idea de extension y la expansion, que ya sucede. A
pesar de esto, no es la intencion de los desarrolladores de DICOM dirigir toda la
informatica medica. El enfasis, anotado en el nombre, esta la imagen medica. Una
de las metas de los desarrolladores de DICOM es que otros deberan aprovechar el
trabajo ya hecho y los conceptos probados.
2.4.
Conclusiones
El estandar es un sistema de gestion de estudios e informes medicos sobre pacientes

muy u
til para la organizacion de estos. Permite el poder realizar estudios de pacientes
que esten a largas distancias y poder intercambiar datos de estudios medicos entre
hospitales, clnicas, centros de investigacion,. . .
Para estudiar el estandar a fondo hay que leer varias veces los conceptos, incluso
as pueden haber dudas sobre ciertos temas que trata DICOM.
DICOM a medida que pasa el tiempo se va afianzando mas en el campo de la
medicina digital, ya que es el mejor soporte para el intercambio de imagenes digitales
por la red.
76
r
Captulo 3
Libreras DCMTK de Offis
[KURA]
3.1.
Introducci
on
La tecnologa de la informacion y la comunicacion poco a poco esta llegando a ser

omnipresente en el cuidado de la salud. Los requerimientos para un rapido acceso a
los datos medicos en el momento necesario solo se puede conseguir mediante los standards. El standard de DICOM facilita el intercambio y el procesamiento de imagenes
biomedicas de forma digital. Los aparatos de adquisicion de imagenes, archivos de
imagenes y las estaciones de trabajo de diferentes vendedores, pueden estar conectadas en una infraestructura com
un e integradas con otros sistemas de informacion
(HIS/RIS). Nuevas oportunidades se alzan, no solo dentro del hospital,si no tambien para el intercambio de informacion entre diferentes clnicas y entre hospitales y
centros de investigacion.
3.2.
Estandarizaci
on de la Comunicaci
on de Imagenes M
edicas
Las tecnologas de informacion y comunicacion de las imagenes medicas esta cada

vez mas presente en los dominios administrativos de los hospitales. La velocidad de los
avances en soportes tecnologicos estan opuestos al requerimiento de una disponibilidad a largo plazo de datos medicos. El salvaguardar las inversiones para un n
umero
apropiado de a
nos es tambien un requisito indispensable dado el aumento de los costes
77
CAPITULO 3. LIBRERIAS DCMTK DE OFFIS
del sector de la medicina.

Estos requisitos pueden ser resueltos solamente con estandares. Desde que el sector
de medicina esta distribuido y estructurado, la estandardizacion de interfaces desde
niveles bajos a niveles tecnicos es de gran importancia, tambien para el desarrollo de
nuevos servicios, como por ejemplo la telemedicina.
Las siguientes organizaciones internacionales estan desarrollando el estandar para
la medicina informatica:
1. El Comit
e DICOM
El Comite DICOM ha publicado el estandar DICOM, que ha llegado a ser el
mas importante estandar de las imagenes medicas.
2. Comit
e Europeo de Normalizaci
on
El Comite Tecnico CEN/TC251 Informatica de la salud es un Comite Europeo para la estandarizacion de modelos de informacion desarrollados por los
sistemas de informacion medica, estandar para el conocimiento de representaciones y terminologias, y para la seguridad y porteccion de las imagenes y procesamiento de se
nales en medicina.
3. Organizaci
on internacional para la estandarizaci
on
El Comite ISO ISO/TC215 Informatica de la salud fue fundada en 1998 con
un alcance similar al de CEN/TC252, pero no limitado a Europa solo. En este
Comite, los modelos para los sistemas de informacion medica, as como los
estandares para el conocimiento de la representacion, terminologa, seguridad
en medicina seran desarrollados, basado en parte en los estandares de CEN.
3.3.
Descripci
on de DICOM seg
un Offis
La adquisicion de imagenes por aparatos, datos de imagenes, estaciones de trabajo, etc. de diferentes vendedores se pueden conectar en una infraestructura com
un
integrada con otros sistemas de informacion.
DICOM facilita el intercambio y procesamiento de imagenes medicas en forma
digital, as la informacion puede ser intercambiada entre hospitales, clnicas,. . .
DICOM es un estandar para una interoperatividad entre aparatos y aplicaciones,
es mas que un sistema de intercambio de imagenes medicas:
Transmision de imagenes, servicios de red.
78
r
DE DICOM SEGUN
OFFIS
3.3. DESCRIPCION
Formatos para el almacenamiento en intercambios.

Requiere conformidad entre aparatos y aplicaciones.
Estructuras de datos, formatos para las imagenes medicas digitales con sus datos
relacionados.
3.3.1.
Estructura de los datos en el est

andar DICOM
Un archivo (objeto) DICOM consiste en una lista de datos-elementos (atributos),

que contienen imagenes relacionadas con informacion:
Paciente: nombre, sexo, fecha de nacimiento,. . .

Medio y procedimiento en la adquisicion de la imagen: parametros de aparatos,
calibracion,. . .
Imagen: resolucion,. . .
3.3.2.
Servicios de Red
Estos servicios de red estan basados en el concepto de Cliente/Servidor. Antes de

que dos aplicaciones DICOM puedan intercambiar informacion, estos deben establecer
la conexion y estar deacuerdo en los siguientes parametros:
Quien es el cliente y quien es el servidor.

Que servicios DICOM son usados.
En que formato son transmitidos los datos (compresion-descompresion).
3.3.3.
Intercambio de medios de comunicaci

on
Ademas de la comunicacion de imagenes medicas sobre la red, el intercambio

de medios de comunicacion se ha hecho hueco en DICOM que fue integrado en el
estandar en 1996. Los campos de aplicacion son por ejemplo el almacenaje de pelculas
de angiografas en la cardiologa o el almacenaje de imagenes de ultrasonido. Para
asegurarse de que los medios de comunicacion de almacenaje DICOM son realmente
intercambiables, el estandar define los llamados perfiles de aplicacion que define:
r
79
que modalidades de imagenes pueden estar presentes en el medio

que formatos de codificacion y compresion pueden ser usados
que medio de almacenaje es usado
Cada medio DICOM contiene un llamado DICOM directorio ademas de los

archivos de imagen. Este directorio contiene la informacion mas importante (el nombre
paciente, la modalidad, identificadores u
nicos, etc.) para todas las imagenes en el
medio. Esto permite hojear o buscar rapidamente a traves de todas las imagenes del
medio sin tener que leer el archivo imagen completo.
3.3.4.
Declaraci
on de Conformidad
DICOM requiere que una Declaracion de Conformidad (Conformance Statement) sea escrita para cada dispositivo o aplicacion desarrollada con DICOM. El
formato y el contenido de esta declaracion son definidos en el estandar. Esto explica
que servicios DICOM y opciones son soportados, que extensiones y particularidades
han sido puestas en practica por el vendedor, y como el dispositivo se comunica con
otros sistemas DICOM. En la teora, comparando dos declaraciones de conformidad
permite determinar si dos dispositivos DICOM son capaces de comunicarse el uno
con otro. En la practica, sin embargo, las declaraciones de conformidad son solo comprensibles para expertos y son con frecuencia inadecuados.
DICOM ha llegado a ser un indispensable componente para la integracion de
sistemas de imagenes digitales en medicina. DICOM ofrece soluciones para una multitud de comunicaciones relacinados con las aplicaciones. La palabra DICOM por
si misma no garantiza una integracion de enchufar y listo de todos los sistemas de
informacion de un hospital. Esto requiere una combinacion cuidadosa de todas las
soluciones parciales ofrecidas por DICOM.
3.4.
Libreras DCMTK
[ANDRE] [BATE] [CEBAL99] [CEBAL00] [KRUG]

DCMTK es una coleccion de libreras y aplicaciones que implementan partes del
estandar DICOM. DCMTK incluye el software necesario para el examen, la construccion y la conversion de archivos de imagen DICOM, manejando los medios de
comunicacion, enviando y reciviendo imagenes sobre la conexion network, as como la demostracion de almacenaje de imagenes y bases de datos. Estas librerias
80
r
3.4. LIBRERIAS DCMTK
son un completo codigo fuente y han sido escritas en una mezcla de ANSI C y
C++. El Toolkit del DCMTK es un software libre y se puede descargar de la pagina
(http://dicom.offis.de/dcmtk.php.en).
DCMTK ha sido usado en numerosas demostraciones DICOM como proovedor
central, vendedor independiente, almacenaje de imagen y servidores worklist. Es usado
por hospitales y empresas en todo el mundo para una amplia variedad de propositos
desde ser una herramienta para pruebas de productos, a ser un componente basico
para proyectos de investigacion, prototipos y productos comerciales.
El software DCMTK puede ser compilado bajo el Windows NT o una amplia gama
de sistemas operativos Unix que incluyen Linux, Solaris, OSF/1, IRIX, FreeBSD y
MacOS X. Todo lo necesario para la configuracion y los makefiles son sumnirados. La
pagina oficial de Offis es www.offis.de
3.4.1.
Instalaci
on de libreras
El archivo necesario para la instalacion del Toolkit de Offis, depende del sistema operativo que estemos utilizando, si es Windows el archivo a descargar es
dcmtk351.zip, y si es un sistema UNIX es dcmtk351.tar.gz. La instalacion descrita
esta basada en el sistema Windows, bajo el entorno Visual C++.
Para realizar la instalacion de DCMTK hay que seguir unos pasos:
1. Se descomprime el archivo dcmtk351.zip, previamente descargado de la pagina

www.offis.de
2. Se abre el proyecto dcmtk.dsp, que se encuentra en X:\. . . \Toolkit\source\dcmtk
y se compila y linka con el Visual C++ 6, lo que genera los archivos .obj y las libreras (.lib) en la carpeta OpenSSL que hay en cada carpeta de las funciones
existentes en este Toolkit, las cuales pueden ser utilizadas en otros proyectos
incluyendolas en ellos.
3. Para poder generar los ejecutables de cada funcion, hay que incluir los ficheros de
cabezeras (.h) al Visual C++ 6. Aqu pinchando en Tools->Options->Directories>Include files, se pueden incluir todos .h del Toolkit, tan solo poniendo el Path
en el que se encuentran, por ejemplo: C:\Archivos de programa\Microsoft Visual Studio\My Proyect\dcmtk351\dcmtk\dcmnet\include.
4. Tambien es necesario dar el path donde se encuentran los .lib, que se hace
pinchando en Tools->Options->Directories->Library files, y se incluye el path.
De esta forma se incluyen los .lib y .h de forma permanente en el visual.
r
81
5. Para incluir las libreras en los proyectos hacer click en Proyect->Settings->Link,

y escribir la librera a incluir (por ejemplo: dcmnet.lib) antes de /nologo. De esta
forma si queremos generar el ejecutable de un fuente lo compilamos y linkamos.
Este Toolkit tiene diferentes funciones basadas en el estandar Dicom. Las funciones
son agrupadas en carpetas dependiendo de la funcion que desempe
nen. Vease la figura
3.1.
Config: Incluye los ficheros .h necesarios para la configuracion del toolkit.

Dcmdata: Contiene funciones para el tratamiento de los datos de los archivos
Dicom y Data Sets.
Dcmimage: Fuciones para el tratamiento de los datos de los pixel de una imagen.
Solo para imagenes Dicom sin comprimir.
Dcmimgle: Sirven para el tratamiento de la luminosidad de las imagenes.
Dcmjpeg: Son funciones para la compresion/descompresion de imagenes DICOM
a JPEG.
Dcmnet: Funciones para el transporte de los archivos Dicom a traves de la Red.
Dcmpstat: Funciones para el tratamiento de escalas de grises y estados de presentacion
Dcmsing: Para la creacion o supresion de una firma digital para un archivo
Dicom y su verificacion.
Dcmsr: Para la conversion de documentos Dicom SR (Structured Reporting) a
HTML, XML .
Dcmtls: Para la transmision segura de archivos Dicom por la Red.
Imagectn: Para el registro de archivos en una base de datos.
Wlistctn: Para implementar un SCP como una Base de Datos.
Nos centraremos en las funciones para el transporte de archivos y la compresion

a Jpeg.
82
r
Figura 3.1: Libreras DCMTK
3.4.2.
Dcmnet
Esta carpeta tiene las funciones para la conexion entre varias maquinas para crear
una asociacion entre ellas y poder transmitir los datos de los objetos DICOM.
Echoscu: Esta aplicacion implementa un Service Class User (SCU) para la verificacion SOP Class. Enva un mensage Dicom C-ECHO a un Service Class
Provider (SCP) y espera una respuesta.
Findscu: Esta aplicacion implementa un Service Class Query/Rerieve (peticion/recuperacion) y un Service Class Basic Worklist Management. Solo soporta
el mensage Dicom C-FIND, que enva una peticion al SCP y espera respuesta.
Movescu: Esta aplicacion implementa un SCP para el Service Class Query/Retrieve
y un SCU para el Storage Service Class. Para usar la funcionalidad Retrieve
(Recuperacion) usa el mensage Dicom C-MOVE que enva una peticion al SCP y
espera respuesta. El SCP aceptara la asociacion para recibir imagenes enviadas
como resultado de la peticion C-MOVE. El termino MOVE es poco apropiado,
ya que lo que hace es una copia de la imagen, la imagen nunca se borra del SCP.
Storescp: Implementa un Service Class Provider (SCP) para el Storage Service Class. Se pone a la escucha sobre un especfico puerto TCP/IP, para las
peticiones de asociacion que puedan llegar de un Storage SCU y puede recibir
imagenes seg
un el Storage Service Class.
Storescu: Implementa un Service Class User (SCU) para el Storage Service
r
83
Class. Se usa para transmitir imagenes Dicom. Enva un mensage C-STORE a

un Storage SCP y espera respuesta.
Aplicaci
on para ver la conectividad entre dos m
aquinas
Esta aplicacion es realizada sobre dos maquinas, una sera Galileo que actuara de
SCP y otra sera Gauss que sera el SCU. Pondremos la opcion -v la cual nos dira en
todo momento que asociacion se esta realizando, dando detalles sobre ella.
Paso 1o : Se realiza una aplicacion Dicom Storage/Verification Service Class Provider.
Un puerto se pone a la escucha (el puerto 104 es el mas utilizado en Dicom) para la
llegada de asociaciones.
Galileo:\ storescp -v 104
Paso 2o : La siguiente instruccion es para comenzar una aplicacion Dicom Verification Service Class User. Esto intenta construir una asociacion Dicom con una aplicacion que corra sobre Galileo, conectandolos por el puerto 104. Gauss enviara una
peticion C-ECHO y estara a la espera de una respuesta C-ECHO de Galileo. Esto es
solo para verificar que hay conexion entre las dos maquinas.
Gauss:\ echoscu -v Galileo 104
Paso3o : Se enva una imagen Dicom a Galileo (SCP), volviendo a intentar realizar
una asociacion Dicom con una aplicacion que corra sobre Galileo. Es enviada una
peticion C-STORE que contiene una imagen Dicom craneo.dcm y se espera una
respuesta C-STORE de Galileo.
Gauss:\ storescu -v Galileo 104 craneo.dcm
La imagen es guardada en el lugar de trabajo donde se este realizando la escucha

del puerto 104. Por ejemplo si se hace en un fichero C:\Dicom, la imagen es guardada
en ese fichero. El nombre que tiene la nueva imagen copiada en Gauss, es a priori su
UID, que es u
nico entre todas las images DICOM quetiene la maquina.
84
r
3.4.3.
Dcmjpeg
Esta carpeta tiene las funciones para la compresion con y sin perdidas de imagenes
jpeg.
Dcmcjpeg: Realiza la compresion de una imagen DICOM a una imagen JPEG.

Dcmdjpeg: Descomprime la imagen DICOM comprimida como JPEG.
Dcmj2pnm: Lee una imagen DICOM y convierte los datos de los pixel seg
un
las opciones del procesamiento de imagenes seleccionadas, PPM/PGM, BMP,
TIFF o JPEG.
Dcmmkdir: Crea un archivo DICOMDIR de los archivos DICOM especificados
seg
un la aplicacion Media de almacenaje.
3.4.4.
DicomScope
El DicomScope es un programa desarrollado en C++ con un GUI en Java, utiliza

las funciones DICOM dadas por las libreras DCMTK. Permite visualizar, imprimir,
almacenar, transmitir y recibir estudios, imagenes, estados de presentacion1 e informes
estructurados2 . Los informes estructurados (SR) consisten en informes completos de
diagnostico y resultados de un examen en particular.
La aplicacion tiene cuatro partes principales:
Browser (Navegador de estudios): El cual es la base de datos local de la aplicacion donde se encuentran los estudios (imagenes, structured reports,...) de la
aplicacion.
Viewer: Para tratar y mostrar imagenes Dicom, imagenes de escalas de grises,
estados de presentacion e informes estructurados.
Print: Administra e incluye los estudios para su impresion.
Process log: Muestra los procesos que se han llevado a cabo en la transmision
de archivos Dicom.
1
2
Presentation states
Structured Reports
r
85
Instalaci
on
Es necesario para la instalacion un sistema compatible con Java y Windows 32
bits, para esto ha y que descargar de internet la Maquina Virtual de Java. Antes de la
instalacion del DicomScope es necesaria la instalacion de Java 2 SDK o JRE(Java 2
Runtime Environment), para conseguir esto, se puede bajar de la pagina www.offis.de.
Una vez realizada esta tarea tan solo hay que ejecutar Setup y seguir las instrucciones
dadas.
Browser
Es la base de datos del DicomScope donde se almacenan los estudios Dicom. Tiene
una estructura de arbol en la que cada estudio es una rama, y puede tener varias ramas
a su vez, puede tener imagenes, informes estructurados, imagenes de escalas de grises
y estados de presentacion.
Figura 3.2: Base de Datos

Los nuevos estudios recibidos por Red o almacenados en la aplicacion, se diferencian de los otros porque aparece un smbolo deNew a su izquierda, una vez
visualizados estos, perderan el smbolo. Figura 3.2
Para enviar estudios a otra maquina, se elige el estudio que se quiere enviar y se
presiona la tecla send, entonces se abre una ventana en la que hay que se elige la
forma de enviar los estudios. Hay tres formas:
86
r
1. Transmision insegura, sin proteccion de los datos en transito.

2. Transmision TLS3 , en la que se utilizan certificados para la transmision de
datos.
3. Transmision TLS y encriptacion.
Para poder configurar a que maquinas son enviados los estudios y que puerto
se utiliza para la asociacion, se hace mediante el archivo DICOMscope.cfg que se
encuentra en X:\. . . \DICOMscope351, escribiendo a que hostname quiere ser enviado
y el port.
Este archivo DICOMscope.cfg, es un archivo de configuracion, en el que se puede
configurar todo lo relacionado con el DicomScope como la impresora que se va a usar,
la certificacion, nombre de usuario,. . . pero lo mas importante es la configuracion de
la transmision de datos por la red. Con ello se puede variar el ttulo de la asociacion
para la conexion entre maquinas, el hostname al que se van a enviar los objetos
Dicom, el puerto a utilizar en la comunicacion, si se utiliza el soporte TLS para una
comunicacion segura, etc.
Una cuestion importante en los archivos de configuracion es que las lneas que
empiezan por # son comentarios y estas no son consideradas para la configuracion de
la aplicacion. Vease figura 3.3
Figura 3.3: Archivo de configuracion de DicomScope

La configuracion realizada para la transmision de datos de Gauss a Galileo es
como sigue a continuacion:
3
Transport Layer Security
r
87
GAUSS
Type = Storage
Aetitle = Storage
Hostname = Galileo
MaxPDU = 32768
Port = 10004
ImplicitOnly = false
DisableNewVRs = false
Figura 3.4: Viewer

GALILEO
Type = Storage
Aetitle = Storage
Hostname = Gauss
MaxPDU = 32768
Port = 10004
ImplicitOnly = false
DisableNewVRs = false
BitPreservingMode = false
Viewer
Todas las instancias Dicom que se carguan, pasan a verse en el Viewer. Es una herramienta para tratar las imagenes Dicom y cambiar y editar informes estructurados,
88
r
incluso para verificarlos y crear firmas digitales. Ver figura 3.4
Print
Pueden ser enviadas imagenes Dicom a imprimir desde el Browser o la imagen
que se visualiza en el Viewer. Esto lleva la imagen al Print en el que se visualiza la
imagen que se va a imprimir. Figura 3.5
Figura 3.5: Print
Process Log
Se pueden ver los procesos se producen en la transmision de archivos Dicom. Al
iniciar el DicomScope se ve que hay dos procesos que estan realizandose. Figura 3.6
Uno es para que el DicomScope sirva como receptor de instancias Dicom con
transmision insegura, sin utilizar TLS. Este proceso utiliza la orden C-STORESCP,
con esto recibe y guarda en la base de datos los archivos Dicom mandados a
este equipo, utilizando el puerto 10004.
El otro proceso recibe las instancias Dicom utilizando TLS, de esta forma la
transmision de datos es segura. Tambien utiliza la orden C-STORESCP y el
puerto elegido es el 10007.
r
89
Figura 3.6: Process Log
3.5.
Conclusiones
Las libreras desarrolladas por Offis, implementan un gran n

umero de funciones
del estandar DICOM. Son unas libreras utilizadas por un gran n
umero de personas
que estan desarrollando aplicaciones con el estandar.
La gran ventaja de estas libreras es que son un producto freeware, es decir, que
son un producto gratuito.
Estas libreras estan desarrolladas enteramente en C/C++ y no es codigo facil el
que implementan, por esto es muy difcil trabajar con estas libreras ya que hay que
a
nadirle que se trabaja basandose en DICOM que es un estandar que hay que leer
varias veces para poder entenderlo completamente.
Son muy u
tiles para gente experta en C++ y Dicom, pero de lo contrario si se
intenta trabajar con estas libreras sin reunir uno de los dos requisitos puede llegar a
ser muy pesado.
90
r
Captulo 4
Programaci
on en JAVA
[BOBA00] [BOBA01] [LEMA] [PAJ] [JDK]
4.1.
Introducci
on
Java surgio en 1991 cuando un grupo de ingenieros de Sun Microsystems trataron

de dise
nar un nuevo lenguaje de programacion destinado a electrodomesticos. Debido
a la existencia de distintos tipos de CPUs y a los continuos cambios, era importante
conseguir una herramienta independiente del tipo de CPU utilizada. Se ejecuta sobre
una maquina hipotetica o virtual denominada Java Virtual Machine (JVM)1 . Es
la JVM quien interpreta el codigo neutro convirtiendolo a codigo particular de la
CPU utilizada. Cualquier aplicacion que se desarrolle cuelga (o se apoya, seg
un
como se quiera ver) en un gran n
umero de clases preexistentes (el API o Application
Programming Interface de Java).
La ejecucion de programas en Java tiene muchas posibilidades: ejecucion como
aplicacion independiente (Stand-alone Application), ejecucion como applet, ejecucion
como servlet, etc.. Un applet es una aplicacion especial que se ejecuta dentro de un
navegador o browser (por ejemplo Netscape Navigator o Internet Explorer) al cargar
una pagina HTML desde un servidor Web. El applet se descarga desde el servidor y
no requiere instalacion en el ordenador donde se encuentra el browser. Un servlet es
una aplicacion sin interface grafica que se ejecuta en un servidor de Internet.
Java permite facilmente el desarrollo tanto de arquitecturas cliente-servidor como
de aplicaciones distribuidas, consistentes en crear aplicaciones capaces de conectarse
a otros ordenadores y ejecutar tareas en varios ordenadores simultaneamente.
1
Maquina Virtual de Java
91
EN JAVA
CAPITULO 4. PROGRAMACION
Figura 4.1: Evolucion de Java

En definitiva Java es un lenguaje de programacion orientado a objetos, interpretado, independiente de la arquitectura y portable, fuertemente tipado, con gestion
automatica de la memoria (recogida de basura), con gestion de excepciones y concurrencia (multihilo) y principalmente con las caractersticas de encapsulacion, herencia
y polimorfismo.
El lenguaje Java es un lenguaje sencillo extendido mediante una serie de bibliotecas
o packages (paquetes), entre ellos los mas comunes son:
Package lang: clase con funcionaliddes basicas. E/S, excepciones, hilos.
Package util: Utilidades (n
umeros aleatorios, vectores).
Package net: Conectividad y trabajo con redes.
Package applet: Desarrollo de aplicaciones ejecutables en navegadores.
Package awt y swing: Desarrollo de interfaces graficas de usuario.
4.2.
Instalaci
on de la JVM
Hay dos instalaciones posibles de la JVM, o bien la instalacion del JRE2 , la cual
sirve para que se puedan ejecutar las apliaciones desarrolladas en Java pero no posee
2
92
Java Runtime Environment
r
DE LA JVM
4.2. INSTALACION
Figura 4.2: Bibliotecas de clases de Java

compilador para los ficheros fuente, o bien la instalacion del SDK que si tiene compilador para desarrollar aplicaciones.
Para el desarrollo de aplicaciones en Java, la instalacion debe comprender el SDK
que es un software libre y puede ser descargado de http://java.sun.com. Al instalar
el SDK, se crea una carpeta en el directorio raz (j2sdk1.4.1_03)3 , y dentro de esta
hay otra llamada bin que es la que contiene el compilador.
El siguiente paso es dar el PATH al compilador y crear un CLASSPATH que
contenga las libreras que vaya a utilizar el compilador. Los pasos a seguir difieren
dependiendo del sistema operativo que se utilize.
Los pasos a seguir en un sistema Windows de red (NT,2000,XP):
1. Pinchar en Inicio->Configuracion->Panel de Control->Sistema, ir a la pesta

na
Avanzado y click en Variables de Entorno.
2. En variables del sistema ir a la variable Path y escribir seguido a lo que haya el
camino a seguir hasta la carpeta bin del SDK:
C:\J2SDK1.4.1_03\BIN;
3. Para crear el Classpath, en variables del sistema dar a Nueva. . . y escribir en
nombre de variable:
CLASSPATH
y en valor de variable el camino hasta la carpeta lib donde esta dt.jar que son
las clases del JDK:
C:\j2sdk1.4.1_03\lib\dt.jar;.;
3
Para la versi
on 1.4.1
r
93
EN JAVA
el valor de ;.; es para poder compilar cualquier fichero fuente desde cualquier
directorio y no deba ser desde el directorio donde esta el compilador.
Los pasos a seguir en un sistema Windows9X o MSDOS:
1. Abrir el fichero Autoexec.bat que se encuentra en el directorio Raz del sistema,

pinchando en el con el boton derecho del raton y dejando pulsada la tecla Shift,
de esta forma sale el men
u contextual con la opcion Abrir con. . . , se pincha
esta opcion y se elige un editor de texto (por ejemplo el WordPad).
2. Una vez abierto en la lnea de SET PATH hay que incluir la carpeta del compilador:
SET PATH = . . . ;C:\J2SDK1.4.1-_03\Bin; %PATH %
3. Crear el CLASSPATH y dar le localizacion de las libreras del JDK, para ello
escribir debajo del PATH:
SET CLASSPATH = C:\j2sdk1.4.1_03\lib\dt.jar;.; %CLASSPATH %
4.3.
El compilador de Java
Es una herramienta del JDK o SDK4 , el JRE no compila. Realiza un analisis

del sintaxis del codigo escrito en los ficheros fuente de Java (con extension *.java). Si no encuentra errores en el codigo genera los ficheros compilados (con extension *.class).En el JDK de Sun dicho compilador se llama javac.exe. Java.exe es el
interprete para sistemas PC/Windows. Appletviewer.exe es un visualizador de applets.
Una vez compilado no debera ser necesaria ninguna modificacion por el hecho
de cambiar de procesador o de ejecutarlo en otra maquina. La clave consistio en
desarrollar un codigo neutro el cual estuviera preparado para ser ejecutado sobre
la JVM.
Para realizar una aplicacion con el compilador del SDK, se debe escribir el codigo
en Java en un editor de texto cualquiera como puede ser el Bloc de Notas. Una vez
escrito debe ser guardado el fichero con extension .java, por ejemplo nombre.java. La
compilacion debe realizarse con un shell de comandos, como el del MSDOS. Para
realizar la compilacion escribir:
4
94
JDK para las antiguas versiones y SDK para las nuevas versiones
r
4.4. VARIABLES Y TIPOS DE DATOS
X:\. . . \javac nombre.java

Con la compilacion se genera un archivo .class, en este caso sera nombre.class.
Despues ya se puede ejecutar o interpretar, para esto escribir en el Shell:
X:\. . . \java nombre
Todo ello se realiza en el directorio donde se encuentre el fichero fuente .java. Ver
figura 4.3
Figura 4.3: Compilacion y ejecucion

Java Sun ha realizado un API para la ayuda y consulta de las clases que se
pueden utilizar con el SDK. Esta ayuda es de importancia vital para el buen uso y
comprension de java. Ver http://java.sun.com
4.4.
4.4.1.
Variables y tipos de datos

Comentarios
Permiten documentar el codigo haciendolo mas legible a los progamadores.

//Comentario de una sola l
nea
/* Comentario que
aparece en varias l
neas*/
r
95
EN JAVA
4.4.2.
Identificadores
Los identificadores se utilizan como nombres de clase, metodo y variable. Un identificador puede ser cualquier sentencia descriptiva de letras en may
uscula o min
uscula,
n
umeros y los smbolos (_) y ($). Java diferencia entre may
usculas y min
usculas, lo
que significa que VALOR es un identificador diferente de Valor.
4.4.3.
Palabras clave reservadas
Las palabras clave reservadas son identificadores especiales que el lenguaje Java
se ha reservado para controlar como esta definido su programa. Se utilizan para identificar los tipos, modificadores y mecanismos para control de secuencia incorporados.
Estas palabras clave solo se pueden utilizar para su proposito original y no se pueden
utilizar como identificadores de nombres de variable, clase o metodo.Vease la lista 4.4
Figura 4.4: Palabras clave de Java
4.4.4.
Variables
La variable es la unidad basica de almacenamiento en un programa en Java. Una

variable se define mediante la combinacion de un identificador, un tipo y un ambito.
La forma basica de una declaracion de variable es:
tipo identificador [ = valor ] [, identificador [ = valor ] ... ] ;
El tipo puede ser: byte, short, int, long, char, float, double, boolean o el nombre
de una clase o interfaz.
96
r
4.4. VARIABLES Y TIPOS DE DATOS
Los bloques de sentencias compuestas en Java se delimitan con dos llaves . Las
variables de Java solo son validas desde el punto donde estan declaradas hasta el final
de la sentencia compuesta que la engloba. Se pueden anidar estas sentencias compuestas y cada una puede contener su propio conjunto de declaraciones de variables
locales. Sin embargo, no se puede declarar una variable con el mismo nombre que una
de un ambito superior.
Tipos
Enteros que son todos los tipos numericos de Java son valores con signo. Esta
ausencia de signo reduce el n
umero de tipos de entero a cuatro:
byte es un tipo de 8 bits con signo. Su rango comprende desde -128 a 127.Su
declaracion puede ser:
byte b;
byte c = 0x55;
short es un tipo de 16 bits con signo. Su rango comprende desde -32768 a
32767. Declaracion:
short s;
short t = 0x55aa;
int es un tipo de 32 bits con signo. Su rango comprende desde -2.147.483.648
a 2.147.483.647. Es el tipo mas utilizado habitualmente para almacenar
valores enteros simples.
int n;
int m = 10;
long es un tipo de 64 bits con signo. Hay algunas ocasiones en las que
un tipo int no es lo suficientemente grande como para guardar un valor
deseado.
long j;
Los n
umeros en coma flotante, tambien conocidos como n
umeros reales en otros
lenguajes, se utilizan cuando se calculan funciones que requieren precision fraccionaria. Hay dos clases de tipos en coma flotante, float y double:
float utiliza 32 bits para almacenar un valor.
float a;
float b = 10.5;
double utiliza 64 bits para almacenar un valor.
double p;
Logico o booleano, utiliza 1 bit, y solo puede tener dos valores TRUE o FALSE
r
97
EN JAVA
boolean p;
Caracteres, dado que Java utiliza Unicode para representar los caracteres de
una cadena, el tipo char es de 16 bits sin signo.
char a = h;
Conversiones
Hay situaciones en las cuales se tiene un valor de un tipo dado y se desea almacenar
ese valor en una variable de un tipo diferente. En algunos tipos es posible almacenar
simplemente el valor sin una conversion de tipos; lo que se denomina conversion
automatica. Esto solo es posible en Java si el compilador reconoce que la variable
destino tiene la suficiente precision para contener el valor origen, como almacenar un
valor byte en una variable int. A esto se le llama ensanchamiento o promocion, dado
que el tipo mas peque
no se ensancha o promociona al tipo compatible mas grande. Si
por el contrario, se desea asignar un valor de variable int a una variable byte se necesita
realizar una conversion de tipos explcita. A esto se le llama estrechamiento, dado que
se estrecha explcitamente el valor para que quepa en el destino. La conversion de un
tipo se realiza poniendo delante un nombre de tipo entre parentesis.
int a = 100;
byte b = (byte) a;
4.4.5.
Matrices o vectores
Las matrices son un tipo especial que agrupa un conjunto de variables del mismo
tipo. Si se desea crear una matriz de doce enteros, se crea un tipo especial, que es
una matriz de int.
int days[];
Para las matrices, hay un valor especial llamado null, que representa una matriz sin
ning
un valor. Se debe utilizar un operador especial, new (nuevo), para asignar el
espacio de una matriz. Para utilizar el operador new se debe promocionar un tipo
y un n
umero entero no negativo de elementos a asignar.
days = new int[12];
98
r
4.5.
4.5. OPERADORES
Operadores
Los operadores de Java son caracteres especiales que le dicen al compilador que
se desea realizar una operacion sobre algunos operandos.
4.5.1.
Operadores aritm
eticos
Los operadores aritmeticos se utilizan para operaciones matematicas, exactamente

de la misma manera en la que estan definidos en algebra. Los operandos deben ser
tipo numerico. No se pueden utilizar estos operadores con tipos boolean, pero se
pueden utilizar con tipos char, dado que el tipo char en Java es un subconjunto
de int.
Suma: +
Resta: Multiplicacion: *
Division: /
Resto: %
Operadores aritm
eticos unitarios
Preincremento: ++x
Postincremento: x++
Predecremento: - -x
Postdecremento: x- -
4.5.2.
Operadores de asignaci
on
normal: x = y
adiccion: x+=y o x=x+y
resta: x-=y o x=x-y
multiplicacion: x*=y o x=x*y
division: x/=y o x=x/y
r
99
EN JAVA
4.5.3.
Operadores a nivel de bit
Los tipos numericos enteros, long, int, short, char y byte tienen un conjunto adicional de operadores que pueden modificar e inspeccionar los bits que componen sus
valores.
El operador NOT unario, ~, invierte todos los bits de su operando.

El operador AND, &, combina los bits de manera que se obtiene un 1 si ambos
operandos son 1, obteniendo 0 en cualquier otro caso.
00101010 42
& 00001111 15
= 00001010 10
El operador OR, |, combina los bits de manera que se obtiene un 1 si cualquiera
de los operandos es un 1.
00101010 42
| 00001111 15
= 00101111 47
El operador XOR, ^, combina los bits de manera que se obtiene un 1 si cualquiera
de los operandos es un 1, pero no ambos, y cero en caso contrario.
El operador desplazamiento a la izquierda, ((, mueve hacia la izquierda todos los
bits del operando de la izquierda un n
umero de posiciones de bit especificado
en el operando de la derecha. Al realizarse el desplazamiento se pierden por el
extremo izquierdo del operando el n
umero de bits desplazados y se rellena el
operando con ceros por la derecha el mismo n
umero de bits.
))
El operador desplazamiento a la derecha, )), mueve hacia la derecha todos los

bits del operando de la izquierda un n
umero de posiciones de bit especificado
por el operando de la derecha.
4.5.4.
Operadores relacionales
Para comparar dos valores, Java tiene el siguiente conjunto de operadores relacionales
que describen igualdad y ordenamiento. Ver figura 4.5
100
r
4.6. CONTROL DEL FLUJO
Figura 4.5: Operaderes relacionales
4.5.5.
Operadores l
ogicos booleanos
Todos los operadores logicos booleanos combinan dos valores boolean para dar
como resultado un valor boolean. Ver 4.6
Figura 4.6: Operaderes logicos booleanos
4.6.
Control del flujo
El control del flujo es la manera que tiene un lenguaje de programacion de provocar

que el flujo de la ejecucion avance y se ramifique en funcion de los cambios de estado
de los datos.
4.6.1.
Instrucci
on condicional if-else
La construccion if-else provoca que la ejecucion atraviese un conjunto de estados

boolean que determinan que se ejecuten distintos fragmentos de codigo.
r
101
EN JAVA
if ( expresi
on-booleana ) sentencia1; [ else sentencia2; ]}
La clausula else es opcional. Cada una de las sentencias puede ser una sentencia
compuesta encerrada entre llaves, { }. Una expresion-booleana es cualquier expresion que devuelve un valor boolean. Podra ser una variable simple declarada como
boolean.
boolean datosdisponibles;
if (datosdisponibles)
ProcesarDatos();
else
esperarAMasDatos();
4.6.2.
Instrucci
on condicional switch
La sentencia switch proporciona una forma limpia de dirigir la ejecucion a partes

diferentes del codigo en base al valor de una variable o expresion. Esta es la forma
general de la sentencia switch:
switch ( expresi
on ){
case valor1:
instrucciones;
break;
case valor2:
instrucciones;
break;
default:
}
El valor de expresion se compara con cada uno de los valores literales de las sentencias case. Si coincide con alguno, se ejecuta el codigo que sigue a la sentencia case.
Si no coincide con ninguno de ellos, entonces se ejecuta la sentencia default (por defecto). La sentencia default es opcional. La sentencia break, comentada anteriormente,
hace, en este caso, que la ejecucion salte al final del switch. Si no se pone el break, la
ejecucion continuara en el siguiente case. . La sentencia break de Java esta dise
nada
para cubrir aquellos casos en los que saltar arbitrariamente a una porcion de codigo
es una constuccion valiosa y legtima para el control del flujo. El termino break se
refiere al acto de salirse de un bloque de codigo. Le dice al interprete que retome la
ejecucion pasado el final del bloque.
102
r
4.6.3.
4.6. CONTROL DEL FLUJO
Bucles
Un bucle es lo que llamamos ejecutar repetidamente el mismo bloque de codigo

hasta que cumpla una condicion de terminacion. Hay cuatro partes en cualquier bucle,
inicializacion, cuerpo, iteracion y terminacion . La inicializacion es el codigo que
establece las condiciones iniciales de un bucle. El cuerpo es la sentencia que queremos
repetir. La iteracion es el codigo que queremos ejecutar despues de cuerpo, pero antes
de entrar de nuevo en el bucle. Se utiliza a menudo para incrementar o decrementar
contadores e ndices. La terminacion es la expresion booleana que comprueba cada
vez a lo largo de un bucle para ver si ha llegado el momento de parar de iterar. Java
tiene tres construcciones para bucles: while, do-while y for.
Bucle while
Ejecuta una sentencia repetidamente mientras una expresion booleana sea verdadera. Esta es su forma general:
[ inicializaci
on; ]
while ( terminaci
on ) {
cuerpo;
[ iteraci
on; ]
}
Las partes inicializacion e iteracion son opcionales, y mientras la expresion terminacion devuelva un valor true, la sentencia cuerpo continuara ejecutandose.
Bucle do-while
La contruccion do-while se utiliza cuando se desea ejecutar el cuerpo de un
bucle while al menos una vez, incluso si la expresion booleana tiene el valor false la
primera vez. Es decir si se desea evaluar la expresion de terminacion al final del bucle
en vez de al principio como en el while.
[ inicializaci
on; ]
do { cuerpo; [ iteraci
on; ] } while ( terminaci
on );
r
103
EN JAVA
Bucle for
La sentencia for es una forma compacta de expresar un bucle.
for ( inicalizaci
on; terminaci
on; iteraci
on ) cuerpo;
Si las condiciones iniciales no provocan que la terminacion devuelva true la primera
vez, entonces la sentencia cuerpo e iteracion no se ejecutaran nunca. Ejemplo de un
bucle for:
for (int i = 1; i <= 10; i++)
System.out.println(i = + i);
4.6.4.
Otras instrucciones
return
Java utiliza una forma de subrutina llamada metodo para implementar una interfaz de procedimiento a las clases de objetos. En cualquier momento dentro de un
metodo, se puede utilizar la sentencia return para que la ejecucion salte y vuelva al
punto donde se llamo al metodo. Se utiliza para acarbar los metodos. Si es un metodo
void, la sentencia sera:
return;
continue
Del mismo modo que se desea salir prematuramente de un bucle (con break),
se podra desear continuar en el bucle, pero dejar de procesar el resto de codigo en
esta interacion en concreto. La sentencia continue de Java salta del cuerpo de bucle,
pero permaneciendo en el bucle.
for (int i = 0; i < 10; i++){
System.out.print(i + );
if (i % 2 == 0)
continue;
System.out.println( );
}
104
r
4.7.
4.7. CLASES
Clases
El elemento basico de la programacion orientada a objetos en Java es un clase.

Una clase define la forma y el comportamiento de un objeto. Cualquier concepto que
desee representar en su programa en Java esta encapsulado en una clase. Para crear
una clase solo se necesita un archivo fuente que contenga la palabra clave class seguida
de un identificador legal y un par de llaves para el cuerpo.
class punto{
}
Las clases de Java tpicas incluiran variables y metodos de instancia. Los programas
en Java completos constan por lo general de varias clases de Java de distintos archivos
fuente. Una clase define la estructura de un objeto y su interfaz funcional, conocida
como metodos. Cuando se ejecuta un programa en Java, el sistema utiliza definiciones
de clase para crear instancias de las clases, que son objetos reales. La forma general
de una clase se muestra a continuacion.
class nombre_de_clase extends nombre_de_superclase {

type variable_de_instancia1;
type variable_de_instancia2;
type variable_de_instanciaN;
type nombre_de_m
etodo1 (lista_de_par
ametros) {
cuerpo_del_m
etodo;
}
type nombre_de_m
etodo2 (lista_de_par
ametros) {
cuerpo_del_m
etodo;
}
type nombre_de_m
etodoN (lista_de_par
ametros) {
cuerpo_del_m
etodo;
}
}
Aqu, nombre_de_clase y nombre_de_superclase son identificadores. La palabra

clave extends se utiliza para indicar que nombre_de_clase sera una subclase de
nombre_de_superclase. Hay una clase incorporada, llamada Object (objeto), que
esta en la raz de la jerarqua de clases de Java. Si se desea realizar una subclase de
Object directamente, se puede omitir la clausula extends.
r
105
EN JAVA
4.7.1.
Referencias a objetos
Cada nueva clase que se crea a

nade otro tipo que se puede utilizar igual que los
tipos simples. Por lo tanto, cuando se declara una nueva variable, se puede utilizar un
nombre de clase como tipo. A estas variables se las conoce como referencias a objeto.
A cada instancia se le puede llamar tambien objeto. Cuando se declara que el
tipo de una variable es una clase, tiene como valor por omision el null, que es una
referencia al tipo Object, y, por lo tanto, es compatible en tipo con todas las otras
clases. El objeto null no tiene valor; es distinto del entero 0, igual que el false de
boolean. Este ejemplo declara una variable p cuyo tipo es de la clase Point.
Point p; //Aqu
la variable p tiene un valor null.
4.7.2.
Variables de una instancia
Los datos se encapsulan dentro de una clase declarando las variables dentro de las
llaves de apertura y cierre de la declaracion de la clase. A las variables que se declaran
en este ambito y fuera del ambito de un metodo concreto se las conoce como variables
de instancia. Este ejemplo declara una clase de nombre Point, con dos variables de
instancia enteras llamadas x e y.
class Point {
int x, y;
}
4.7.3.
Operador new
El operador new crea una u

nica instancia de una clase y devuelve una referencia a
ese objeto. Aqu se crea una nueva instancia de Point y se almacena en una variable
p.
Point p = new Point();
Aqu p referencia a una instancia de Point, pero realmente no lo contiene. Se

pueden crear m
ultiples referencias al mismo objeto.
106
r
4.7. CLASES

Point p2 = p;
4.7.4.
Operador(.)
El operador punto se utiliza para acceder a las variables de instancia y los metodos
contenidos en un objeto. Esta es la forma general de acceder a las variables de instancia
utilizando el operador punto.
p.x = 10;
p.y = 20;
System.out.println("x = " + p.x + " y = " + p.y);
4.7.5.
Declaraci
on de m
etodos
Los metodos son subrutinas unidas a una definicion de una clase especfica. Se
declaran dentro de una definicion de clase al mismo nivel que las variables de instancia.
Se debe llamar a los metodos en el contexto de una instancia concreta de esa clase.
En la declaracion de los metodos se define que devuelve un valor de un tipo
concreto y que tiene un conjunto de parametros de entrada.
tipo nombre_de_m
etodo ( lista_formal_de_par
ametros ) {
cuerpo_del_m
etodo;
}
Se podra crear un metodo en la clase Point que inicialice las variables de instancia
de la forma siguiente:
clase Point {
int x, y;
void init(int x, int y) {
this.x = x;
this.y = y;
}
}
r
107
EN JAVA
El m
etodo main()
Dado que no hay funciones globales en Java, se deba idear alguna manera de
iniciar un programa, de ah el sentido del metodo main, a partir de este metodo
es donde empiezan los programas. Esto es un concepto perdido en la creacion de
interfaces graficas. El metodo main es simplemente un lugar de inicio para que el
interprete comience. Un programa complejo tendra docenas de clases, y solo una de
ellas necesitara tener un metodo main.
4.7.6.
Llamada a m
etodos
Se llama a los metodos dentro de una instancia de un clase utilizando el operador

punto (.). La forma general de una llamada:
referencia_a_objeto . nombre_de_m
etodo ( lista_de_par
ametros );
En este caso, se puede llamar al metodo init sobre cualquier objeto Point.

p.init (10, 20);
4.7.7.
Constructores
Las clases pueden implementar un metodo especial llamado constructor. Un constructor es un metodo que inicializa un objeto inmediatamente despues de su creacion.
Tienen exactamente el mismo nombre de la clase en la que residen; de hecho no se
puede tener ning
un otro metodo que comparta su nombre con su clase. Una vez
definido, se llama automaticamente al constructor despues de crear el objeto, antes
de que termine el operador new.
class Point {
int x, y;
Point(int x, int y) {
this.x = x;
this.y = y;
}
}
108
r
4.7. CLASES
class PointCreate {
public static void main (String args[]) {
Point p = new Point(10, 20);
}
}
4.7.8.
Sobrecarga de m
etodos
Es posible y a menudo deseable crear mas de un metodo con el mismo nombre,

pero con listas de parametros distintas. A esto se le llama sobrecarga de metodo. Se
sobrecarga un metodo siempre que se crea un metodo en una clase que ya tiene un
metodo con el mismo nombre.
class Point {
int x, y;
this.x = x;
this.y = y;
}
Point() {
x = -1;
y = -1;
}
}
class PointCreateAlt {
public static void main (String args[]) {
}
}
Este ejemplo crea un objeto Point que llama al segundo constructor sin parametros
en vez de al primero.
4.7.9.
Operador this
Este
es un operador que utilizan las clases para hacerse referencias a s mismas. De
esta forma un objeto siempre puede tener referencias a sus variables. Muy utilizado
en los constructores.
r
109
EN JAVA
class Point {
int x, y;
this.x = x;
this.y = y;
}
Point() {
this(-1, -1);
}
}
4.7.10.
Herencia
La herencia es un concepto que relaciona clases una encima de otra de un manera jerarquica. Esto permite que los descendientes de una clase hereden todas las
variables y metodos de sus ascendientes, ademas de crear los suyos propios. A estos
descendientes se les llama subclases. Al padre inmediato de una clase se le llama su
superclase.
class Point3D extends Point {
int z;
Point3D(int x, int y, int z) {
this.x = x;
this.y = y;
this.z = z;
}
Point3D() {
this(-1, -1, -1);
}
}
La palabra clave extends se utiliza para indicar que se desea crear una subclase
de Point. No se necesita declarar las variables x e y en Point3D porque se haban
heredado de Point. Todas las variables x, y, z estan en el mismo ambito desde la
perspectiva de una instancia de Point3D.
super
Hay una variable especial en Java llamada super, que se refiere directamente a
los constructores de la superclase. Este ejemplo define una nueva version de Point3D
110
r
4.7. CLASES
que utiliza el constructor super para inicializar x e y.
class Point3D extends Point {

int z;
Point3D(int x, int y, int z) {
super(x, y);
// aqu
se llama al constructor Point(x, y)
this.z = z;
}
}
final
Todos los metodos y las variables de instancia se pueden sobrescribir por defecto.
Si se desea declarar que ya no se quiere permitir que las subclases sobrescriban las
variables o metodos, estos se pueden declarar como final. El modificador de tipo final
implica que todas las referencias futuras a este elemento se basaran en esta definicion.
Se puede utilizar final como modificador en declaraciones de metodo cuando se desea
no permitir que las subclases sobrescriban un metodo concreto.
static
A veces se desea crear un metodo que se utilize fuera del contexto de cualquier
instancia. Todo lo que se tiene que hacer es declarar estos metodos como static
(estatico). Los metodos estaticos solo pueden llamar a otros metodos static directamente, y no se pueden referir a this o super de ninguna manera. Las variables tambien
se pueden declarar como static, pero debe ser consciente que es equivalente a declararlas como variables globales, que son accesibles desde cualquier fragmento de codigo.
Se puede declarar un bloque static que se ejecuta una sola vez si se necesitan realizar
calculos para inializar las variables static.
abstract
Las clases abstractas son aquellas cuya descripcion es incompleta. Se definen utilizando la palabra reservada abstract. No proporcionan la implementacion de todos
sus metodos. Los metodos no implementados se declaran como abstract. Una clase
con un metodo abstracto tiene que declararse como abstract. Una clase abstracta no
puede instanciarse, es decir, no pueden crearse objetos de esa clase.
r
111
EN JAVA
4.8.
4.8.1.
Paquetes e interfaces
Paquetes
Los paquetes permiten agrupar una coleccion de clases e interfces funcionalmente

relacionadas asignandole un nombre.
Sentencia package
Lo primero que se permite en un archivo Java es una sentencia package, que le dice
al compilador en que paquete se deberan definir las clases incluidas. Si se omite la
sentencia package, las clase terminan en el paquete por defecto, que no tiene nombre.
El compilador Java utiliza directorios de sistema de archivos para almacenar paquetes.
Si se declara que una clase esta en dentro de un paquete llamado MiPaquete, entonces
el archivo fuente de esa clase se debe almacenar en un directorio llamado MiPaquete.
package nombrePaquete; //fichero como parte de un paquete
Sentencia import
Lo siguiente que se pone despues de una sentencia package y antes de las definiciones de clase en un archivo fuente en Java puede ser una lista de sentencias import.
Todas las clases interesantes estan almacenadas en alg
un paquete con nombre. Para
no tener que introducir el largo nombre de trayecto de paquete para cada clase, Java
incluye la sentencia import para que se puedan ver ciertas clases o paquetes enteros.
La forma general de la sentencia import:
import paquete1.[ paquete2 ].( nombre_clase | * );
paquete1 es el nombre de un paquete de alto nivel, paquete2 es el nombre de
un paquete opcional contenido en el paquete exterior separado por un punto (.). No
hay ning
un lmite practico a la profundidad de la jerarqua de paquetes. Finalmente,
nombre_clase explcito o un asterisco (*) que indica que el compilador Java debera
buscar este paquete completo.
import java.util.Date;
import java.io.*;
112
r
4.8.2.
4.8. PAQUETES E INTERFACES
Protecci
on de accesos
Hay cuatro niveles de proteccion en funcion de los atributos de acceso y de la

organizacion en paquetes y son publico, paquete, protegido y privado. Los atributos de
acceso son:
Si no se indica nada un miembro es accesible desde todo el paquete.

private: acceso solo desde dentro de una clase.
public: acceso desde cualquier lugar
protected: acceso en la clase, las subclases (en cualquier paquete) y desde las
clases del mismo paquete.
El control de acceso se aplica tanto a atributos como a metodos.
4.8.3.
Interfaces
Las interfaces son como las clases, pero sin variables de instancia y con metodos
declarados sin cuerpo. Las clases pueden inplementar varias interfaces. Para implementar una interfaz, todo lo que necesita una clase es una implementacion del conjunto completo de metodos de la interfaz. Las interfaces estan en una jerarqua distinta
de la de las clases, por lo que es posible que varias clases que no tengan la mas mnima relacion en cuanto a la jerarqua de clases implementen la misma interfaz. Por
defecto todos sus metodos son p
ublicos y abstractos, y sus atributos son p
ublicos y
constantes. Los metodos que se declaran no tienen sentencias de cuerpo. Un ejemplo
de una interfaz es:
interface Callback {
void callback(int param);
}
Una clase puede implementar varias interfaces, con la sentencia implements:
class NombredeClase implements Interfaz1 [,Interfaz2,...]{

//declaraci
on de m
etodos y atributos de la clase
}
r
113
EN JAVA
4.9.
Gesti
on de cadenas
Una cadena es una secuencia de caracteres. Las cadenas son una parte fundamental
de la mayora de los programas, as pues Java tiene varias caractersticas incorporadas
que facilitan la manipulacion de cadenas.
Java tiene una clase incorporada en el paquete java.lang que encapsula las estructuras de datos de una cadena. Esta clase, llamada String es la representacion
como objeto de una matriz de caracteres que no se puede cambiar.
4.9.1.
Constructores
Como con todas las otros clases, se pueden crear instancias de String con el operador new.
String s = new String();
Este ejemplo crea una instancia de String sin caracteres en ella. Para crear un
String inicializado con caracteres hay que pasarle una matriz de char al constructor.
char chars[] = { a,b,c};
String s = new String(chars); // s es la cadena "abc"
La mejor forma en Java de inicializar un String es:
String s = "mejor";
4.9.2.
M
etodos de String
length
La clase String ademas tiene sus propios metodos, uno de los mas habituales es
length, que devuelve el n
umero de caracteres de una cadena.
String s = "abc";
System.out.println(s.length()); // imprime 3
114
r
DE CADENAS
4.9. GESTION
Concatenaci
on
El u
nico operador que utiliza Java es + , y en los objetos String. El + act
ua como
operador de concatenacion en este caso en concreto para mejorar la legibilidad, por
ser operacion muy com
un.
String s = "El tiene " + edad + " a~
nos";
Comparaci
on de cadenas
Si se desean comparar dos cadenas para ver si son iguales, puede utilizar el metodo equals() de String. Devuelve true si las cadenas de caracteres comparadas son
iguales.
String coger= "dicom";
String hol= "dicom";
boolean compara = coger.equals(hol);//devuelve true
El metodo equals y el operador = = hacen dos pruebas completamente diferentes para la igualdad. Mientras que el metodo equals compara los caracteres contenidos en una String, el operador = = compara dos referencias de objeto para ver si
se refieren a la misma instancia.
Extracci
on de caracteres
Para extraer un u
nico caracter de una cadena, se puede referir a un caracter
indexado mediante el metodo charAt:
"abc".charAt(1) // devolver
a b
La primera posicion de una cadena es la posicion 0.
4.9.3.
Conversi
on a String
Todos los objetos tienen el metodo toString() heredado de Object, de esta forma
cualquier objeto puede ser convertido en cadena. Ejemplo de int a String.
r
115
EN JAVA
int entero = 5;
String cadena = new Integer(entero).toString();
4.10.
Gesti
on de excepciones
Una excepcion es una condicion anormal que surge en una secuencia de codigo
durante la ejecucion. La gestion de excepciones de Java lleva la gestion del error
en tiempo de ejecucion al mundo orientado a objetos. Una excepcion de Java es un
objeto que describe una condicion excepcional que se ha producido en un fragmento
de codigo.
Los objetos de excepcion los crea automaticamente el interprete de Java como
respuesta a alguna condicion excepcional. Como ejemplo tomamos una division por
cero. Cuando el interprete de Java intenta ejecutar la division, observa que el denominador es cero y construye un nuevo objeto de excepcion para que se detenga este
codigo y se trate esta condicion de error. Una vez detenido el flujo del codigo en el
operador de division, se buscara en la pila de llamadas actual cualquier gestor de
excepciones (pila que contiene un registro de las llamadas a metodo). Un gestor de
excepciones es algo establecido para tratar inmediatamente la condicion excepcional.
Si no codificamos un gestor de excepciones, se ejecutara el gestor en tiempo de ejecucion por defecto. El gestor por defecto imprime el valor String de la excepcion y el
trazado de la pila del lugar donde se produjo la excepcion.
Figura 4.7: Propagacion de excepciones
116
r
4.10.1.
DE EXCEPCIONES
4.10. GESTION
try y catch
Es mas practico manejar y gestionar las excepciones. Se puede utilizar la palabra

clave try para especificar un bloque de codigo que se debera proteger frente a todas
las excepciones. A continuacion inmediatamente del bloque try, se debe incluir la
clausula catch que especifica el tipo de excepcion que se desea captar y en este bloque
se define como se trata la excepcion.
class Exc {
public static void main(String args[]) {
try {
int d = 0;
int a = 42;
} catch (ArithmeticException e) {
System.out.println("divisi
on por cero");
}
}
}
ArithmeticException es una subclase especial de Exception, que describe mas

especficamente el tipo de error que se ha producido. El ambito de la clausula catch
esta restringido a las sentencias especificadas por la sentencia try precedente.
En algunos casos, la misma secuencia de codigo puede activar mas de una condicion
excepcional. Se pueden tener varias clausulas catch en una fila. Se inspecciona cada
uno de estos tipos de excepcion en el orden en que estan y el primero que coincida se
ejecuta.
4.10.2.
throw
La sentencia throw se utiliza para lanzar explcitamente una excepcion. El flujo de

la ejecucion se detiene inmediatamente despues de la sentencia throw, y no se llega a
la sentencia siguiente. Se inspecciona el bloque try que la engloba mas cercano para
ver si tiene una clausula catch cuyo tipo coincida con el de la instancia Throwable. Si
la encuentra, el control se transfiere a esa sentencia. Si no, se inspecciona el siguiente
bloque try que la engloba, y as sucesivamente, hasta que le gestor de excepcion mas
externo detiene el programa e imprime el trazado de la pila hasta la sentencia throw.
r
117
EN JAVA
4.10.3.
finally
Es el bloque de codigo que se ejecuta siempre haya o no excepcion. Se puede

utilizar la palabra clave finally par identificar dicho bloque de codigo. Incluso aunque
so coincida ninguna de las clausulas catch, se ejecutara el bloque finally antes del
codigo que esta despues del final del bloque try completo.
4.10.4.
Gesti
on incompleta de las excepciones
Si un metodo no gestiona o captura todas las excepciones que se pueden generar,

debe ser especificado mediante throws:
import java.io.*;
public class PruebaExcepciones {
public static char leer() throws IOException {
return (char) System.in.read();
}
try {
char car=leer();
System.out.println("Caracter: "+car);
} catch (IOException e) {
System.out.println("Error de entrada de datos");
}
}
}
4.11.
Hilos
La programacion multihilo es un paradigma conceptual de la programacion en el

cual se dividen los programs en dos o mas procesos que se pueden ejecutar en paralelo.
En un momento dado pueden haber datos de entrada de usuario a los que responder,
animaciones y visualizaciones de interfaz de usuario, tambien calculos grandes que
podran tardar varios segundos en terminar, y nuestros programas tendran que tratar
con estos temas sin provocar retrasos desagradables al usuario.
Lo interesante de todos estos procesos en paralelo es que la mayor parte de ellos
realmente no necesitan los recursos completos de la computadora durante su vida
operativa. El problema en los entornos de hilo u
nico tradicionales es que se tiene que
118
r
4.11. HILOS
esperar a que se terminen cada una de estas tareas antes de proseguir con la siguiente.
Aunque la CPU este libre la mayor parte del tiempo, tiene que colocar las tareas en
la cola ordenadamente.
Los sistemas multihilo aprovechan la circunstancia de que la mayora de los hilos
computacionales invierten la mayor parte del tiempo esperando a que un recurso quede
disponible, o bien esperando a que se cumpla alguna condicion de temporizacion. Se
puede describir todas las tareas como hilos de control independientes, conmutando de
manera automatica entre una tarea que este lista para pasar a un modo de espera, y
otra que s tenga algo que hacer, consiguoendo realizar una cantidad mayor de trabajo
en el mismo intervalo de tiempo.
Prioridades de hilo
El interprete de Java utiliza prioridades para determinar como debe comportarse
cada hilo con respecto a los demas. Las prioridades de hilo son valores entre 1 y 10
que indican la prioridad relativa de un hilo con respecto a los demas.
Sincronizaci
on
Ya que los hilos permiten y potencian el comportamiento asncrono de los programas, debe existir alguna manera de forzar el sincronismo all donde sea necesario.
Java incorpora una version rebuscada de un modelo clasico para la sincronizacion,
el monitor. La mayor parte de los sistemas multihilo implementan los monitores a
modo de objetos, pero Java proporciona una solucion mas elegante: no existe la clase
monitor, cada objeto lleva asociado su propio monitor implcito, en el que puede entrar sin mas que hacer una llamada a los metodos synchronized del objeto. Una vez
que el hilo esta dentro del metodo synchronized, ning
un otro hilo puede efectuar una
llamada a otro metodo synchronized sobre el mismo objeto.
Una vez que el programa se ha dividido en sus partes logicas, a modo de hilo, es
preciso definir exactamente como se comunicaran entre si dichos hilos. Java utiliza
los metodos wait y notify para el intercambio de informacion entre hilos.
4.11.1.
Thread
En Java los hilos se representa mediante una clase. La clase Thread encapsula
todo el control necesario sobre los hilos. Hay que tomar la precaucion de distinguir
claramente un objeto Thread de un hilo en ejecucion. Un objeto Thread se define
r
119
EN JAVA
como el panel de control o proxy de un hilo en ejecucion. En el objeto Thread hay

metodos que controlan si el hilo se esta ejecutando, esta durmiendo, en suspenso o
detenido. La clase Thread es la u
nica manera de controlar el comportamiento de los
hilos. En la siguiente instruccion se muestra como acceder al hilo en ejecucion actual:
Thread t = Thread.currentThread();//el hilo actual se almacena t
4.11.2.
Runnable
Si se tener mas de un hilo necesitamos crear otra instancia de Thread. Cuando

se construye una nueva instancia de Thread, es necesario decir que codigo ejecutar
en el nuevo hilo de control. Se puede comenzar un hilo sobre cualquier objeto que
implemente la interfaz Runnable.
Runnable es una interfaz simple que abstrae la nocion de que se desea que alg
un
codigo se ejecute asncronamente. Para implementar Runnable, a una clase le basta
con implementar un solo metodo llamado run. Este es un ejemplo que crea un nuevo
hilo.
class ThreadDemo implements Runnable {

ThreadDemo() {
Thread ct = Thread.currentThread();
Thread t = new Thread(this, "demo Thread");
System.out.println("hilo actual: " + ct);
System.out.println("Hilo creado: " + t);
t.start();
try {
Thread.sleep(3000);
} catch (interrupteExecption e) {
System.out.println("Interrumpido");
}
System.out.println("saliendo del hilo main");
}
public void run() {
try {
for (int y = 5; y > 0; y--) {
System.out.println(" " + i);
Thread.sleep(1000);
}
} catch (InterruptedException e) {
System.out.println("hijo interrumpido");
120
r
4.11. HILOS
}
System.out.println("saliendo del hilo hijo");
}
public static void main (String args [])
new ThreadDemo();
}
El hilo main crea un nuevo objeto Thread, con new Thread (this, Demo Thread),
pasa this como primer argumento para indicar que el nuevo hilo llame al metodo run
sobre este objeto. A continuacion se llama a start, lo que inicia el hilo t en la
ejecucion a partir del metodo run. En estos momentos hay dos hlos en ejecucion,
uno ct que contin
ua con el programa principal, lo que le lleva al primer try, y el
segundo salta desde start() al metodo run(). Despues, el hilo main se duerme durante
3000 milisegundos antes de imprimir un mensaje y despues termina. Demo Thread
todava esta contando desde cinco cuando sucede esto. Se contin
ua ejecutando hasta
que termina con el bucle de run. Esta es la salida despues de cinco segundos:
C:\> java ThreadDemo

Hilo actual: Thread[main, 5, main]
Hilo creado: Thread[demo Thread, 5, main]
5
4
3
saliendo del hilo main
2
1
saliendo del hilo hijo
4.11.3.
Prioridades de los hilos
El planificador de hilos hace uso de las prioridades de los mismos para decidir
cuando debe dejar a cada hilo que se ejecute, de manera que los hilos con mayor prioridad deben ejecutarse mas a menudo que lo de menor prioridad. Cuando
esta ejecutandose un hilo de baja prioridad, y otro de mayor prioridad se despierta
de su sue
no, o de la espera por un operacion de E/S, debe dejarse que se ejecute de
manera inmediata, desalojando al hilo de menor prioridad. Cuando los hilos son de
igual prioridad deben desalojarse los unos a los otros, cada cierto tiempo, utilizando
el algoritmo circular round-robin para gestionar el acceso al la CPU.
r
121
EN JAVA
4.11.4.
Sincronizaci
on
Cuando dos o mas hilos necesitan acceder de manera simultanea a un recurso de

datos compartido necesitan asegurarse de que solo uno de ellos accede al mismo cada
vez. Java proporciona un soporte u
nico, el monitor, es un objeto que se utiliza como
cerrojo exclusivo. Solo uno de los hilos puede ser el propietario de un monitor en
un instante dado. Los restantes hilos que estuviesen intentando acceder al monitor
bloqueado quedan en suspenso hasta que el hilo propietario salga del monitor.
Todos los objetos de Java disponen de un monitor propio implcitamente asociado
a ellos. La manera de acceder a un objeto monitor es llamando a un metodo marcado
con la palabra clave synchronized. Durante todo el tiempo en que un hilo permanezca
en un metodo sincronizado, los demas hilos que intenten llamar a un metodo sincronizado sobre la misma instancia tendran que esperar. Para salir del monitor y
permitir el control del objeto al siguiente hilo en espera, el propietario del monitor
solo tiene que volver del metodo
Sentencia synchronized
Si se utiliza una clase que no fue dise
nada para accesos multihilo y, por ello,
se dispone de metodos no sincronizados que manipulan el estado interno,se puede
envolver la llamada al metodo en un bloque sincronizado. El formato general de la
sentencia sincronizada es el siguiente:
synchronized(objeto) sentencia;
En el ejemplo, objeto es cualquier referencia al objeto, y sentencia suele ser un
bloque que incluye una llamada al metodo de objeto, que solo tendra lugar una vez
que el hilo haya entrado con exito en el monitor de objeto.
4.11.5.
Comunicaci
on entre hilos
Java proporciona un mecanismo elegante de comunicacion entre procesos, a traves

de los metodos wait, notify y notifyAll. Estos metodos se implementan como metodos
de final en Object, de manera que todas las clases disponen de ellos. Cualquiera de
los tres metodos solo puede ser llamado desde dentro de un metodo synchronized.
wait: le indica al hilo en curso que abandone el monitor y se vaya a dormir hasta
que otro hilo entre en el mismo monitor y llame a notify.
122
r
4.11. HILOS
notify: despierta al primer hilo que realizo una llamada a wait sobre el mismo
objeto.
notifyAll_: despierta todos los hilos que realizaron una llamada a wait sobre el
mismo objeto. El hilo con mayor prioridad de los despertados es el primero en
ejecutarse.
4.11.6.
M
etodos
M
etodos de clase
Estos son los metodos estaticos que deben llamarse de manera directa en la clase
Thread.
currentThread: el metodo estatico devuelve el objeto Thread que representa al
hilo que se ejecuta actualmente.
yield: este metodo hace que el interprete cambie de contexto entre el hilo actual
y el siguiente hilo ejecutable disponible. Es una manera de asegurar que los hilos
de menor prioridad no sufran inanicion.
Sleep(int n): el metodo sleep provoca que el interprete ponga al hilo en curso
a dormir durante n milisegundos. Una vez transcurridos los n milisegundos,
dicho hilo volvera a estar disponible para su ejecucion. Los relojes asociados a
la mayor parte de los interpretes Java nos seran capaces de obtener precisiones
mayores de 10 milisegundos.
M
etodos de instancia
Estos son los metodos que deben llamarse desde instancias u objetos de la clase
Thread.
start: indica al interprete de Java que cree un contexto de hilo del sistema
y comience a ejecutarlo. A continuacion, el metodo run objeto de este hilo
sera llamado en el nuevo contexto del hilo. Debe tomarse la precaucion de no
llamar al metodo start mas de una vez sobre un objeto hilo dado.
run: constituye el cuerpo de un hilo en ejecucion. Este es el u
nico metodo de
la interfaz Runnable. Es llamado por el metodo start despues de que el hilo
apropiado del sistema se haya inicializado. Siempre que el metodo run devuelva
el control, el hilo actual se detendra.
r
123
EN JAVA
stop: provoca que el hilo se detenga de manera inmediata. A menudo constituye

una manera brusca de detener un hilo, especialmente si este metodo se ejecuta
sobre el hilo en curso. En tal caso, la lnea inmediatamente posterior a la llamada
al metodo stop no llega a ejecutarse jamas, pues el contexto del hilo muere antes
de que stop devuelva el control.
suspend: es distinto de stop. suspend toma el hilo y provoca que se detenga su
ejecucion sin destruir el hilo de sistema subyacente, ni el estado del hilo anteriormente en ejecucion. Si la ejecucion de un hilo se suspende, puede llamarse a
resume sobre el mismo hilo para lograr que vuelva a ejecutarse de nuevo.
resume: se utiliza para revivir un hilo suspendido.
setPriority(int p): asigna al hilo la prioridad indicada por el valor entero pasado
como parametro.
getPriority: devuelve la prioridad del hilo en curso, que es un valor entre 1 y 10.
setName(String nombre): identifica al hilo con un nombre mnemonico. De esta
manera se facilita la depuracion de programas multihilo.
getName: devuelve el valor actual, de tipo cadena, asignado como nombre al
hilo mediante setName.
4.12.
Utilidades
La biblioteca de clases de Java contiene un conjunto de clases de utilidades utilizadas en todos los paquetes principales de Java. Estas clases estan almacenadas en
los paquetes java.lang y java.util. Se utilizan para almacenar conjuntos de objetos,
realizar la interfaz con funciones del sistema de bajo nivel, funciones matematica,
generacion de n
umeros aleatorios y manipulacion de fecha/hora.
4.12.1.
Envolturas
Number
La clase abstracta Number representa una interfaz a todos los tipos escalares
estandar: long, int, float y double. Number tiene metodos de acceso que devuelven el
valor posiblemente redondeado del objeto de cada uno de los objetos simples:
doubleValue() devuelve un double.
124
r
4.12. UTILIDADES
floatValue() devuelve un float.

intValue() devuelve un int.
longValue() devuelve un long.
Double y Float
Double y Float son subclases de Number. Ambas clases tienen dos constructores
para inicializarlas con valores double y float, o, lo que es muy practico, se pueden
inicializar con una representacion tipo String del valor:
Double d1 = new Double(3.14159);

Double d2 = new Double("314159E-5");
Integer y Long
La clase Integer es una envoltura alrededor de int, short y byte. Long es una
envoltura alrededor del tipo long. Ademas de los metodos heredados de Number
tienen otros muy u
tiles:
parseInt(String) convierte la variable String en el valor int que representa.

parseInt(String, base) hace lo mismo que el metodo anterior, pero especifica una
base distinta de la decima.
toString(int) convierte el int que se pasa al metodo en su representacion como
cadena.
toString(int, base) igual al anterior, pero puedo cambiar de base.
Character
Character es una envoltura simple alrededor de un char. Tiene varios metodos
u
tiles static, que se pueden utilizar para probar varias condiciones de un caracter:
isLowerCase(char ch) devolvera true si el caracter es una letra min

uscula.
isUpperCase(char ch) lo mismo pero para letras may
usculas.
r
125
EN JAVA
isDigit(char ch) e isSpace(char ch) devuelven true para caracteres numericos y

espacios en blanco respectivamente.
toLowerCase(char ch) y toUpperCase(char ch) convierten entre may
uscula y
min
uscula y viceversa.
Boolean
Boolean es un envoltorio muy fino alrededor de valores boolean, que solo es u
til
para situaciones de paso por referencia.
4.12.2.
Enumeraciones
Java tiene matrices para almacenar grupos de datos de tipo similar, que son muy
u
tiles para modelos simples de acceso a datos. Sin embargo, las enumeraciones ofrecen
una manera mas completa y orientada a objetos para almacenar conjuntos de datos
de tipo similar. Las enumeraciones tienen su propia asignacion de memoria y posibilidad de una nueva asignacion para ampliarlas. Tienen interfaces de metodo para su
iteracion y recorrido. Se pueden indexar mediante algo mas complejo y u
til que los
simples enteros.
Interfaz de enumeraci
on
Enumeracion es una interfaz simple que permite enumerar todos los elementos de
cualquier conjunto de objetos. Especifica dos metodos. El primero, un metodo boolean
llamado hasMoreElements, devuelve true cuando todava quedan mas elementos que
extraer. El segundo, nextElement devuelve una referencia a objeto generica cuyo tipo
hay que convertir al tipo de clase de la cual el objeto es una instancia.
Vector
Un Vector es una matriz ampliable de referencias a objeto. Internamente, un
Vector implementa una estrategia de crecimiento para minimizar la reasignacion y el
espacio desperdiciado. Los objetos se pueden almacenar al final de un Vector utilizando el metodo addElement o en un ndice dado mediante el metodo insertElement. Se
puede almacenar una matriz en un Vector utilizando el metodo copyInto. Una vez se
ha almacenado un conjunto de objetos en un Vector, se puede utilizar para buscar un
126
r
4.12. UTILIDADES
elemento en concreto utilizando los metodos contains, indexOf, o lastIndexOf. Tambien se puede extraer un objeto de una posicion especfica de un Vector utilizando los
metodos elementAt, firstElement y lastElement.
4.12.3.
Runtime
La clave Runtime encapsula el proceso del interprete de Java que se ejecuta. No se

puede crear una instancia de Runtime; sin embargo, se puede obtener una referencia
al objeto Runtime que se esta ejecutando actualmente llamando la metodo estatico
Runtime.getRuntime. Una vez tenga el descriptor del proceso en ejecucion, puede
llamar a varios metodos que controlan el estado y comportamiento de la maquina
virtual de Java.
Runtime rt = Runtime.getRuntime();
rt.exec("c:\\CntVirRel.exe");
Mediante Runtime se puede ejecutar cualquier aplicacion, mediante el metodo
exec().
4.12.4.
System
La clase System contiene un conjunto curiosos de funciones y variables globales.

La entrada y salida estandar del interprete de Java se almacena en las variables in y
out.
System.out.println("Este es un ejemplo");
Con el metodo println() se saca por pantalla los argumentos introducidos.
4.12.5.
Date
La clase Date se utiliza para presentar una fecha y una hora. Se pueden manipular
el da, mes, a
no, da de la semana, horas, minutos y segundos. Hay varios constructores
para objetos Date. El mas simple, Date(), inicializa el objeto con la fecha y hora
actual. Hay tres constructores mas que ofrecen niveles de especificidad mayores para
la precision que se desea para la hora:
r
127
EN JAVA
Date(a
no, mes, da) establecera la hora a las 00:00:00 del da especificado.
Date(a
no, mes, da, horas, minutos) fijara la fecha y hora, dejando los segundos
a 0.
Date(a
no, mes, da, horas, minutos, segundos) establecera la hora exacta.
4.13.
Entrada/Salida
La mayora de los programas no pueden alcanzar sus metas sin acceder a datos
externos. Estos datos se recuperan a partir de un origen de entrada. Los resultados
de un programa se envan a un destino de salida. La nocion generica de una fuente
de entrada puede representar muchos tipos de entrada distintos: desde un archivo de
disco, un teclado o un conector (socket) de red. Estas abstracciones son una manera
limpia de tratar la E/S sin necesitar que todo el codigo comprenda la diferencia entre
un teclado y una red.
Java llama flujo a esta abstraccion y la implementa con varias clases del paquete
java.io. El flujo de E/S representa todos los orgenes y destinos de los datos detras de
una interfaz uniforme. La entrada esta encapsulada en la clase InputStream y la salida
en la clase OutputStream. Estas dos clases abstractas son las que todos los objetos
deberan referenciar cuando tratan la E/S en general. Sus metodos mas importantes
son read() y write(int b); son metodos abstractos que definen la funcion basica de
lectura/escritura de un byte.
Figura 4.8: Flujos estandar
4.13.1.
File
Un File es el u
nico objeto del paquete de E/S que referencia a un archivo de
disco real. La clase File no especifica como se recupera o almacena la informacion en
los archivos; solo describe las propiedades de un objeto archivo. Los archivos son un
origen y un destino primario de los datos dentro de la mayora de los programas.
Los objetos archivo se pueden crear utilizando uno de los tres constructores
disponibles. El ejemplo siguiente crea tres archivo: f1, f2 y f3. El primer objeto File
se construye utilizando un trayecto de directorio como u
nico argumento. El segundo
128
r
4.13. ENTRADA/SALIDA
se crea utilizando dos argumentos, el trayecto y el nombre de archivo. El tercero se

crea utilizando el trayecto de archivo asignado a f1 y un nombre de archivo; f3 refiere
al mismo archivo que f2.
File f1 = new File("/");
File f2 = new File("/","autoexec.bat");
File f3 = new File(f1, "autoexec.bat");
Directorios
Un directorio es un File que contiene una lista de otros archivos y directorios.
Cuando se crea un Objeto File y es un directorio, el metodo isDirectory devolvera true.
En este caso, se puede llamar al metodo list sobre ese objeto para extraer la lista de
los otros archivos y directorios que contiene. Si se llama al metodo list sobre un
objeto File que no sea un directorio se provoca una NullPointerException en tiempo
de ejecucion.
import java.io.File;
class Dirlist {
String dirname = "/java";
File f1 = new File(dirname);
if (f1.isDirectory()) {
System.out.println("Directorio de " + dirname);
String s[] = f1.list();
for (int y = 0; i < s.length; y++) {
System.out.println(s[i] + " es un directorio");
}
} else {
System.out.println(dirname + " no es un directorio");
}
}
}
La ejecucion de este programa lista el contenido del directorio /java del PC.
FilenameFilter
A menudo se desea limitar el n
umero de archivos devueltos por el metodo list
para que se incluyan u
nicamente aquellos archivos que cumplan un cierto patron
r
129
EN JAVA
de nombre de archivo. Con este fin, el paquete java.io incluye una interfaz llamada
FilenameFilter. Un objeto que implemente FilenameFilter tiene un u
nico metodo,
accept, al que se llama una vez por cada archivo de una lista. El metodo accept
devuelve el valor true si se debiera incluir el archivo en la lista. El ejemplo siguiente
ampla el programa anterior restringiendo la visibilidad de los nombres de archivo
devueltos por el metodo list. La restriccion se aplica a archivos con nombres que
terminan con la extension de archivo que se pasa como parametro cuando se construye
le objeto:
import java.io.*;
public class OnlyExt implements FilenameFilter {
String ext;
public OnlyExt(String ext) {
this.ext = "." + ext;
}
public boolean accept (File dir, String name) {
return name.endsWith(ext);
}
}
4.13.2.
InputStream
InputStream es una clase abstracta que define el modelo de Java para el flujo de
entrada. Todos los metodos de esta clase lanzaran una IOException si se producen
condiciones de error. Este es un breve resumen de los metodos de InputStream:
read() devuelve una representacion como entero del siguiente byte de entrada
disponible.
read(byte[]) intenta leer hasta b.length bytes situandolos en b y devuelve el
n
umero real de bytes que se leyeron con exito.
read(byte b[], int off, int len) intenta leer hasta len bytes situandolos en b comenzando en b[off], y devuelve el n
umero de bytes que se leyeron con exito.
skip(long n) omite n bytes de la entrada, y devuelve el n
umero de bytes que se
han omitido.
available() devuelve el n
umero de bytes de entrada disponibles actualmente para
su lectura.
close() cierra el origen de entrada. Los intentos de lectura posteriores generaran
una IOException.
130
r
mark(int limitelectura) coloca una marca en el punto actual del flujo de entrada
que seguira siendo valida hasta que se lean limitelectura bytes.
reset() devuelve el puntero de entrada ala marca establecida previamente.
markSupported() devuelve true si se admiten mark/reset en este flujo.
4.13.3.
OutputStream
Igual que InputStream, OutputStream es una clase abstracta que define el flujo
de salida. Todos los metodos de esta clase devuelven un valor void y lanzan una
IOException en caso de error. Esta es una lista de los metodos de OutputStream:
write(int b) escribe un u
nico byte en un flujo de salida. Observar que el parametro
en un int, lo que permite que se llame a write con expresiones sin tener que convertir su tipo a byte.
write(byte b[]) escribe una matriz completa de bytes en un flujo de salida.
write(byte b[], int off, int len) escribe len bytes de la matriz b, comenzando a
partir de b[off].
flush() inicializa el estado de la salida de manera que se limpian todos los buffers.
close() cierra el flujo de salida. Los intentos de escritura posteriores generaran
una IOException.
4.13.4.
Flujo de archivo
FileInputStream
La clase FileInputStream utiliza archivos de datos reales como base del flujo de
entrada. El ejemplo siguiente crea dos FileInputStreams que estan utilizando el mismo
archivo de disco real.
InputStream f0 = new FileInputStream("/autoexec.bat");

File f = new file("/autoexec.bat");
InputStream f1 = new FileInputStream(f);
r
131
EN JAVA
FileOutputStream
FileOutputStream comparte el mismo estilo de constructores que FileInputStream.
Sin embargo, la creacion de FileOutputStream no depende de que el archivo ya exista. FiliOutputStream creara el archivo antes de abrirlo como salida cuando se crea
el objeto. Si se intenta abrir un archivo de solo lectura como punto final de un FiliOutputStream, se lanzara una IOException.
ByteArrayInputStream
ByteArrayInputStream (flujo de entrada de matriz de bytes) es una implementacion
de un flujo de entrada que utiliza una matriz de bytes como origen. Esta clase tiene
dos constructores, y ambos necesita una matriz de bytes que proporcione el origen de
los datos.
ByteArrayOutputStream
ByteArrayOutputStream tiene dos constructores. En la primera forma, se crea un
buffer de 32 bytes. En la segunda, se crea un buffer con un tama
no igual al argumento
en bytes, que en este ejemplo es 1024 bytes:
OutputStream out0 = new ByteArrayOutputStream();

OutputStream out1 = new ByteArrayOutputStream(1024);
4.13.5.
Flujos filtrados
Los flujos filtrados amplan los flujos basicos, proporcionando una sincronizacion.
En un sistema de E/S multihilo, se pueden producir resultados inesperados cuando
se permite que m
ultiples hilos operen sobre el mismo flujo. Aunque es posible tener
hilos m
ultiples en Java leyendo o escribiendo en el mismo flujo, hay una buena razon
para permitir que solo un hilo tenga acceso directo a un flujo de E/S u
nico. Todos
los constructores y metodos proporcionados en esta clase son identicos a los mencionados anteriormente para InputStream y OutputStream, a excepcion de que estan
sincronizados.
132
r
BufferedOutputStream
La salida a BufferedOutputStream es identica a cualquier OutputStream con la
excepcion de que se a
nade un metodo de entrada con buffer, la salida con buffer no
proporciona ninguna funcionalidad adicional. En Java, los buffers para la salida estan
ah para incrementar el rendimiento.
4.13.6.
SequenceInputStream
La clase SequenceInputStream (flujo de entrada secuencial) admite la utilidad

original de concatenar m
ultiples InputStreams en uno solo. La construccion de un
Sequence es diferente de cualquier otro InputStream. Un constructor SequenceInputStream utiliza como argumento un par de InputStreams o una Enumeration de
InputStreams:
SequenceInputStream(Enumeration e);
SequenceInputStream(InputStream s0, InputStream s1);
PrintStream
La clase PrintStream proporciona todas las utilidades de formato que hemos estado utilizando desde el principio del libro de los descriptores de archivo de System.
Pensabas que se introduca System.out.println sin pensar demasiado en las clases
que proporcionaban el formato de la salida que se presentaba. PrintStream tiene
dos constructores, PrintStream(OutputStream sal) y PrintStream(OutputStream sal,
boolean auto), donde auto controla si java vaca el flujo de salida cuando vaya a la
salida un caracter de lnea nueva \n.
Los objetos PrintStream de Java admiten los metodos print y println para todos los tipos, incluyendo Object. Si un argumento no se un tipo simple, los metodos
PrintStream llaman al metodo toString del objeto y a continuacion imprimen el resultado.
4.13.7.
Ejemplo
Este primer ejemplo se muestra una forma comoda y eficaz para la lectura ficheros
que en este caso se leen los datos del fichero LeeFichero.java y se imprimen por la
consola.
r
133
EN JAVA
import java.io.*;
public class LeeFichero {
public static void main(String[] argumentos) {
final int TAMANIO_BUFFER = 64;
byte buffer[] = new byte[TAMANIO_BUFFER];
int NumBytes;
try {
FileInputStream FicheroOrigen = new FileInputStream
("LeeFichero.java");
try {
do {
NumBytes = FicheroOrigen.read(buffer);
System.out.print(new String(buffer,0,NumBytes));
} while (NumBytes == TAMANIO_BUFFER);
FicheroOrigen.close();
} catch (IOException e){
System.out.println("Error leyendo los datos o
cerrando el fichero");
}
} catch (FileNotFoundException e) {
System.out.println("Fichero no encontrado");
}
}
}
En este ejemplo todo lo que se escriba en la consola se va introduciendo en un

archivo de salida que se llama Salida.txt.
import java.io.*;
public class EscribeFichero {
public static void main(String[] argumentos) {
final int TAMANIO_BUFFER = 64;
byte buffer[] = new byte[TAMANIO_BUFFER];
134
r
4.14. TRABAJO EN RED
int NumBytes;
try {
FileOutputStream FicheroDestino = new FileOutputStream
("Salida.txt");
try {
do {
NumBytes = System.in.read(buffer);
FicheroDestino.write(buffer,0,NumBytes);
} while (buffer[0] != Character.LINE_SEPARATOR);
FicheroDestino.close();
} catch (IOException e){
System.out.println("Error escribiendo los datos
o cerrando el fichero");
}
} catch (FileNotFoundException e) {
System.out.println("Fichero no encontrado");
}
}
}
4.14.
Trabajo en Red
Este captulo cubre el paquete java.net. La integracion de Java con la red se

ha hecho legendaria, gracias en gran parte a esta biblioteca de clases. Java admite el
protocolo de TCP/IP de Internet ampliando la interfaz de E/S de flujo ya establecida,
presentada en el captulo anterior, y a
nadiendo las caractersticas que se necesitan
para crear objetos de E/S a traves de la red. Java admite las familias de protocolo
TCP y UDP. TCP se utiliza para E/S fiable de tipo secuencial a traves de la red.
UDP admite un modelo mas rapido, punto a punto y orientado a datagrama.
Un aspecto que hay que tener en cuenta cuando se programan comunicaciones con
TCP es la eficiencia que se consigue. Cuando se va a traspasar una gran cantidad de
informacion (por ejemplo, un fichero video), si no necesitamos tiempo real, TCP es un
protocolo adecuado, puesto que el tiempo necesario para establecer la comunicacion
es desprediable respecto al utilizado para la transmitir los datos. En el otro extremo,
si necesitamos una gran cantidad de cominicaciones cortas en las que la fiabilidad no
r
135
EN JAVA
es muy importante , TCP no es un protocolo adecuado;sera mucho mejor UDP.
4.14.1.
InetAddress
Independientemente de si se realiza una llamada telefonica, se enva un correo

electronico o se establece una conexion a traves de Internet, las direcciones son fundamentales. Java admite los nombres de Internet a traves de la clase InetAddress.
Las direcciones de Internet, reducidas a su nivel mas bajo, estan formadas por un
identificador de nodo de 32 bits y un selector de puerto de ese nodo de 32 bits. En Internet el direccionamiento lo gestionan servidores de nombres que traducen nombres
habituales y faciles de recordar a sus correspondientes direcciones de 32 bits.
La clase InetAddress no tiene constructores visibles. Para crear un objeto InetAddress, se tiene que utilizar uno de los metodos de fabrica disponibles. Estos metodos
son simplemente metodos estaticos que devuelven una instancia de la clase en la que
residen. En este caso, InetAddress tiene tres metodos, getLocalHost, getByName y
getAllByName, que se pueden utilizar para crear instancias de InetAddress.
InetAddress ip = InetAddress.getLocalHost();
La clase InetAddress tambien tiene unos cuantos metodos no estaticos, que se

pueden utilizar sobre los objetos devueltos por los metodos que se acaban de mencionar:
getHostName() devuelve una cadena que representa el nombre de nodo asociado

con el objeto InetAddress.
getAddress() devuelve una matriz de bytes de cuatro elementos que representa
la direccion en Internet del objeto en el orden de red.
toString() devuelve una cadena que contiene el nombre del nodo y la direccion
IP.
4.14.2.
Datagramas
Los datagramas son bloques de informacion del tipo lanzar y olvidar que se
transfieren a traves de la red. Para la mayora de los programas de la red, el utilizar
un flujo TCP/IP en vez de un datagrama UPD es mas sencillo y hay menos posibilidades de tener problemas. Sin embargo, cuando se requiere un rendimiento optimo, y
136
r
esta justificado el tiempo adicional que supone el realizar la verificacion de los datos,
los datagramas son un mecanismo realmente u
til.
Cuando se ha lanzado un datagrama hacia su destino, no hay ninguna seguridad
de que llegue o incluso de que haya alguien all para cogerlo. Igualmente, cuando se
recibe un datagrama, no es seguro que no se haya da
nado por el camino o que el que
lo haya enviado este todava ah para recibir una respuesta.
DatagramPacket
Se pueden crear los DatagramPackets utilizando dos constructores. El primero
utiliza solamente un buffer de bytes y una longitud. Ese utiliza para recibir datos a
traves de un DatagramSocket. El segundo a
nade una especificacion de direccion de
destino y un puerto, que es utilizada por un DatagramSocket para determinar donde
se enviaran los datos del paquete. Considerar que estas dos formas equivalen a crear
un un buzon de entrada en el primer caso, y a rellenar y poner una direccion en un
sobre en el segundo. Estos son los prototipos de los dos constructores:
DatagramPacket(byte ibuf[], int ilong);

DatagramPacket(byte ibuf[], int ilong, InetAddress idir,
int ipuerto);
Hay varios metodos de acceder al estado interno de un DatagramPacket. Permiten

un acceso completo a la direccion de destino y n
umero de puerto de un paquete,
ademas de a sus datos y su longitud. A continuacion se presenta un resumen de cada
uno de ellos:
getAddress() devuelve la InetAddress de destino. Se utiliza habitualmente para

envos.
getPort() devuelve el n
umero entero de puerto de destino. Se utiliza para envos.
getData() devuelve la matriz de bytes de los datos contenidos en el datagrama.
Se utiliza para recuperar los datos del datagrama despues de haberlo recibido.
getLength() devuelve la longitud de los datos validos contenidos en la matriz
de bytes que se devolveran con el metodo getData. Habitualmente no coincide
con la longitud de la matriz de bytes.
r
137
EN JAVA
4.14.3.
Conectores
Socket cliente
Los conectores (sockets), o los conectores TCP/IP en concreto, se utilizan para
implementar conexiones basadas en flujo, punto a punto, bidireccionales y fiables entre
nodos de Internet. Se puede utilizar un conector para conectar el sistema de E/S de
Java a otros programas que pueden residir en la maquina local o en cualquier otra
maquina de Internet. La clase Socket, a diferencia de DatagramSocket, implementa
una conexion continua muy fiable entre el cliente y el servidor.
Al crear un objeto conector tambien se establece la conexion entre direcciones de
Internet. No hay metodos ni constructores que muestren explcitamente los detalles
del establecimiento de la conexion del cliente. Se puedan utilizar dos constructores
para crear conectores:
Socket(String nodo, int puerto) crea un conector que conecta el nodo local con
el nodo y puerto nombrados.
Socket(InetAddress direccion, int puerto) crea un conector utilizando un objeto
InetAddress ya existente y un puerto.
En un conector se puede examinar en cualquier momento la informacion de direccion y puerto asociada con el utilizando los metodos siguientes:
getInetAddress() devuelve la InetAddress asociada con el objeto Socket.
getPort() devuelve el puerto remoto al que esta conectado este objeto Socket.
getLocalPort() devuelve el puerto local al que esta conectado este objeto Socket.
Cuando se ha creado el objeto Socket, tambien puede ser examinado para acceder
a los flujos de entrada y salida asociados con el. Todos estos metodos pueden lanzar
una IOException si se han invalidado los conectores debido a una perdida de conexion
en la red. Estos flujos se utilizan exactamente igual que los flujos de E/S que hemos
visto en el captulo anterior para enviar y recibir datos:
getInputStream() devuelve el InputStream asociado con este conector.
getOutputStream() devuelve el OutputStream asociado con este conector.
close() cierra el InputStream y el OutputStream.
138
r
Socket servidor
Los ServerSockets se deben utilizar para crear servidores de Internet. Estos servidores no son necesariamente maquinas, de hecho son programas que estan esperando
a que programas cliente locales o remotos se conecten a ellos en puertos p
ublicos.
Los ServerSockets son bastante diferentes de los Sockets normales. Cuando se crea un
ServerSocket, se registrara en el sistema que tiene interes en conexiones de cliente.
Tiene un metodo adicional, accept, que es una llamada que se bloquea ya que espera
que un cliente inicie la comunicacion y despues devuelve un Socket normal.
Los dos constructores de ServerSocket reflejan el n
umero del puerto en el que
se desean aceptar las conexiones y, opcionalmente, durante cuanto tiempo se desea
esperar a que se deje de utilizar el puerto. Ambos constructores pueden lanzar una
IOExeption bajo condiciones adversas. Estos son los dos prototipos:
ServerSocket(int puerto) crea un conector de servidor en el puerto especificado.

ServerSocket(int puerto, int n
umero) crea un conector de servidor en el puerto
especificado esperando n
umero milisegundos si el puerto se esta utilizando.
Funcionalmente, el metodo accept de un ServerSocket es una llamada que se bloquea y que espera que un cliente inicie la comunicacion y despues devuelve un Socket
normal. Despues, este conector se utiliza para la comunicacion con el cliente.
4.14.4.
Conexi
on
Conexi
on cliente
Lo primero debe ser crear un objeto socket diciendo con que servidor y por que
puerto se realiza la conexion. Despues para que haya una comunicacion entre las dos
maquinas es necesario abrir dos flujos uno de entrada y otro de salida, en los que por
ellos se realiza el intercambio de informacion. Es recomendable utilizar el buffer para
la transferencia de la informacion. Por u
ltimo una vez se quiera desconectar, se debe
cerrar el socket.
Socket conexion = new Socket(servidor, puerto);

DataInputStream in = new DataInputStream(new BufferedInputStream
(conexion.getInputStream()));
DataOutStream out = new DataOutputStream(new BufferedOutputStream
r
139
EN JAVA
(conexion.getOutputStream()));
//...
conexion.close();
Conexi
on servidor
Es muy interesante que el servidor sea multihilo para que pueda atender varias
peticiones de clientes distintos a la vez, por lo que la clase del servidor tiene que
derivarse de la clase Thread. Para abrir el socket del servidor vale con pasarle que
puerto es utilizado para la trasnmision de datos. Este puerto debe ponerse a la escucha
de posibles peticiones de los clientes. Tambien se deben declarar los flujos de entrada
y salida de datos.
ServerSocket conexion = new ServerSocket(puerto);

conexion.accept();
conexion.start();//start de Thread crea nuevo hilo y va a run()
//...
public void run(){
DataInputStream in = new DataInputStream(new BufferedInputStream
(conexion.getInputStream()));
DataOutStream out = new DataOutputStream(new BufferedOutputStream
(conexion.getOutputStream()));
//...
4.15.
Interfaces Gr
aficas de Usuario
4.15.1.
Componentes AWT
Los componentes de AWT estan en el paquete java.AWT. y son utlizados para la

creacion de GUIs5 . Un componente (component) es una clase abstracta que encapsula
todos los atributos de un componente visual. Todos los elementos de la interfaz de
usuario que se visualizan en la pantalla y que interactuan con un usuario son subclases
de component.
Subclases de Component:
5
140
Graphics User Interfaces
r
4.15. INTERFACES GRAFICAS

DE USUARIO
Container (contenedor). Contendra metodos adicionales que permiten que otros

componentes se aniden dentro de el.
Panel. Es una subclase de container. Se pueden a
nadir otros componentes a
panel mediante el metodo add (a
nadir), modificar estos componentes con move
(desplazar), resize (cambiar el tama
no).
Canvas (lienzo). En el se puede pintar cualquier componente.
Label (etiqueta). Es una subclase de canvas.
Button (boton). Componente que se puede utilizar para ejecutar alguna accion
cuando el usuario lo pulsa y lo libera.
Checkbox (cuadro de comprobacion). Se utiliza para seleccionar una condicion
booleana. Cuando se construye un checkbox se le pasa un string y opcionalmente
un boolean que especifica el estado inicial de la marca de comprobacion. Se
puede establecer y obtener el estado actual de la marca de comprobacion con
los metodos setstate y getestate respectivamente.
Checkboxgroup. Permite crear un grupo de opciones que solo se pueden seleccionar de una en una. Los metodos getcheckboxgroup y secheckboxgroup se
utilizan para obtener y establecer el grupo al que pertenece un chekbox.
Getcurrent, setcurrent. Obtienen y establecen, respectivamente, el checkbox seleccionado actualmente.
Choice (opcion). Se utiliza para crear un men
u de seleccion emergente. El metodo additem (a
nadir elemento) a
nade nuevas cadenas a la clase choice.
Countitems (contar elementos). Devuelve el numero de elementos de el men
u de
opciones.
List (lista). Proporciona una lista de seleccion compacta, de elecciones m
ultiples
y de desplazamiento.
Scrollbar (barras de desplazamiento). Se utiliza para seleccionar valores continuos entre un mnimo y un maximo especificados.
Textfield (campo de texto). Implementa un area de entrada de texto de una sola
lnea.
Seteditable. Congela el contenido del textfield.
Iseditable. Comprueba la posibilidad de edicion.
Gettext. Obtiene el valor actual del campo.
Settext. Establece el valor actual.
r
141
EN JAVA
Setechocaracter. Establece el caracter u

nico que mostrara el textfield para todos
los caracteres que se introduzcan, muy u
til para esconder codigos o informacion
secreta.
Textarea (area de texto). Es un editor de texto muy simple.
Appendtext. A
nade su parametro string al final del buffer.
Inserttext. Inserta su string en una posicion dada, de base 0 que comienza al
principio del buffer.
Replacetext. Copia caracteres del string a partir del primer ndice y hasta el
segundo.
Figura 4.9: Jerarqua de componentes del AWT
4.15.2.
Organizaci
on
Cada objeto container tiene un gestor de organizacion, Layoutmanager. Java tiene

varias clases de layoutmanager predefinidas:
Flowlayout (organizacion continuada). Los componentes se colocan desde la
esquina superior izquierda, de izquierda a derecha y de arriba a abajo.
Borderlayout (organizacion con limites). Tiene cuatro componentes estrechos y
de anchura fija en los extremos, y un area grande en el centro que se amplia y
contrae en dos dimensiones, cada una de estas areas tiene un nombre que es un
string: north, south, easty, west, representan los cuatro lados y center el area
del centro.
142
r
4.15. INTERFACES GRAFICAS

DE USUARIO
Insets (recuadros). Se utiliza para recuadrar un panel.

Cardlayout (organizacion con tarjetas).
Window (ventana). Parecido a panel con la excepcion de que crea su propia
ventana de nivel superior, en vez de estar contenida dentro de otro panel.
Frame (marco). Tiene una barra de ttulo, esquinas para cambiar el tama
no y
una barra de men
u.
4.15.3.
Componentes de men
u
Cada ventana de nivel superior, puede tener una barra de men

u asociada con
ella. Un objeto menubar (barra de men
u) puede contener varios objetos men
u en
el. Los men
us tienen una lista de objetos menuitem (elemento de men
u) dentro de
ellos. Men
u, es una subclase de menuitem, lo que permite anidar submenus de forma
jerarquica.
4.15.4.
Componentes Swing
Las componentes Swing se identifican porque pertenecen al paquete javax.swing.

Son contenedores como el AWT pero que continen otros componentes. Estos componentes se pueden a
nadir al contenedor y para ciertas operaciones se puedan tratar
como un todo. Mediante un gestor de dise
no controlan la disposicion(layout) de estos componentes en la pantalla. Ejemplos de estos componentes son JPanel, JFrame,
JApplet. . .
Administrador de dise
no
Tipos de dise
nos y composiciones:
FlowLayout: Los componentes se ponen de izquierda a derecha hasta llenar la

lnea, y se pasa a la siguiente. Cada lnea se centra.
BorderLayout: Se ponen los componentes en un lateral o en el centro. Se indica
con una direccion:East, West, North, South, Center.
GridLayout: Se colocan los componentes en una rejilla rectangular (filas x columnas). Se a
naden en orden izquierda-derecha y arriba-abajo.
r
143
EN JAVA
Figura 4.10: Componentes Swing

Para poner un layout se utiliza el metodo setLayout():
GridLayout nuevolayout = new GridLayout(3,2);

setLayout(nuevolayout);
Figura 4.11: Layout de Swing
4.15.5.
Eventos
Cualquier componente puede gestionar eventos sobrescribiendo ciertos metodos

llamados por la implementacion por defecto de metodo handleevent (gestionar evento)
de component, se llama a dicho metodo con una instancia de la clase event (evento).
Estos son algunos ejemplos:
144
r
4.16. ENCRIPTACION
MouseEnter se le llama cuando el raton entra por primera vez en un component.

MouseExit se le llama cuando el raton abandona el componente.
MouseMove se le llama cuando se mueve por el componente.
MouseDown se le llama cuando se pulsa primero cualquier boton del raton.
MouseDrag se le llama cuando el raton se mueve con un boton pulsado.
MouseUp se le llama cuando se libera el raton.
Keydown se le llama cuando se pulsa una tecla.
Keyup se le llama cuando se libera una tecla.
Shifthdown comprueba si esta pulsada la tecla shift.
Controldown comprueba si esta pulsada la tecla control.
A los eventos relacionados con el raton, se les llama con una copia del evento
original y la ubicacion (x, y) del evento.
4.16.
Encriptaci
on
[ENCRI]
El soporte que da el JDK a la criptografa se divide en dos grandes bloques, el
JCA Java Cryptography Architecture y el JCE Java Cryptography Extension.
La primera parte nos define las bases del soporte criptografico de Java, y la segunda
nos provee de los algoritmos necesarios para poder encriptar y desencriptar datos.
Debido a las leyes de los Estados Unidos, que prohiben exportar software de
encriptacion de datos, el JCE no viene incluido en el JDK, y existen restricciones
para bajarlo de la site de SUN, pero existen paquetes de terceros, desarrollados fuera
de los Estados Unidos, que implementan todas las especificaciones del JCE y que no
estan sujetos a sus restricciones legales, como por ejemplo la librera CRYPTICS.
4.16.1.
Arquitectura Criptogr
afica de Java (JCA)
El JCA, se refiere al marco para acceder y desarrollar la funcionalidad criptografica

de Java. Incluye todo el API relativo a la criptografa ( el paquete java.security y sus
r
145
EN JAVA
subpaquetes), as como una serie de especificaciones a tener en cuenta por los programadores que quieran crear extensiones criptograficas (como la librera CRYPTICS,
etc).
La arquitectura criptografica de Java ha sido dise
nada teniendo en cuenta los principios de independencia de la implementacion e interoperabilidad. La independencia
de la implementacion se consigue introduciendo el concepto de Proveedor (Cryptography Package Provider). El termino Proveedor se refiere a un paquete o grupo
de paquetes que que implementan algoritmos criptograficos especficos.
El JDK 1.1 viene con un proveedor por defecto llamado SUN, el cual incluye
una implementacion del algoritmo DSA y una implementacion de los algoritmos de
Hashing MD5 y SHA-1. En el JDK se pueden instalar uno o mas paquetes proveedores.
SecureRandom
La clase SecureRandom es un generador de n
umeros pseudo-aleatorio. Para crear
objetos SecureRandom usaremos uno de los siguientes constructores:
SecureRandom(): crea un objeto secure random y lo inicializa automaticamente.

SecureRandom(byte[]): crea un objeto secure random y lo inicializa utilizando
la semilla indicada en el array de bytes.
Una vez tenemos un objeto SecureRandom, podemos utilizar los siguientes metodos:
setSeed(byte[]): Reinicializa el SecureRandom utilizando la semilla indicada en

el array de bytes.
setSeed(long): Reinicializa el SecureRandom utilizando los ocho bytes del long
indicado.
next(int):Devuelve un entero conteniendo el n
umero indicado de bits pseudoaleatorios.
Key
El interface Key es el interface de mas alto nivel de todas las claves y define la
funcionalidad compartida por todas las claves.
146
r
4.16. ENCRIPTACION
PublicKey y PrivateKey
Los interfaces PublicKey y PrivateKey son interfaces sin metodos, que derivan de
la interface Key, utilizados solamente para comprobacion de tipos.
KeyPair
La clase KeyPair es simplemente un contenedor de un par de claves (una p
ublica
y una privada). Tiene dos metodos:
PrivateKey getPrivate(): Devuelve la clave privada.
PublicKey getPublicKey(): Devuelve la clave p
ublica.
KeyPairGenerator
La clase KeyPairGenerator se utiliza para crear un par de claves. Para crear
objetos KeyParGenerator usaremos uno de los siguientes metodos:
KeyPairGenerator getInstance(String algorithm): crea un generador de claves
utilizando el algoritmo criptografico indicado.
KeyPairGenerator getInstance(String algorithm, String provider): crea un generador de claves utilizando el algoritmo criptografico indicado del proveedor
indicado.
Identity
La clase Identity se utiliza para manejar identidades. Para crear identidades usaremos el constructor siguiente:
Identity(String nombre): crea una identidad con el nombre indicado.
Signer
La clase Signer deriva de la clase Identity, y se utiliza para manejar identidades
capaces de firmar datos.
r
147
EN JAVA
Signature
La clase Signature se utiliza para crear o verificar firmas. Para crear objetos Signature usaremos uno de los siguientes metodos:
Signature getInstance(String algorithm): crea un objeto firma utilizando el algoritmo criptografico indicado.
Signature getInstance(String algorithm, String provider): crea un objeto firma
utilizando el algoritmo criptografico indicado del proveedor indicado.
4.16.2.
Extensi
on criptogr
afica de Java (JCE)
El JCE extiende el proveedor SUN e incluye una implementacion de los algoritmos DES, 3DES, los modos ECB y CBC, y el estilo de relleno PKCS#5. Para utilizar
otros algoritmos deberemos utilizar otro proveedor que los implemente. (Para utilizar
el algoritmo RSA nosotros utilizaremos la libreria CRYPTIX).
SecretKey
La interface SecretKey es una interface sin metodos, que deriva de la interface
Key, utilizada solamente para comprobacion de tipos.
KeyGenerator
La clase KeyGenerator se utiliza para crear una clave secreta. Para crear objetos
KeyGenerator usaremos uno de los siguientes metodos:
KeyGenerator getInstance(String algorithm): crea un generador de claves utilizando el algoritmo criptografico indicado.
KeyGenerator getInstance(String algorithm, String provider): crea un generador
de claves utilizando el algoritmo criptografico indicado del proveedor indicado.
148
r
4.17. CONCLUSIONES
Cipher
La clase Cipher se utiliza para cifrar o descifrar datos. Para crear objetos Cipher
usaremos uno de los siguientes metodos:
Cipher getInstance(String algorithm): crea un objeto Cipher utilizando el algoritmo criptografico indicado.
Cipher getInstance(String algorithm, String provider): crea un objeto Cipher
utilizando el algoritmo criptografico indicado, del proveedor indicado.
4.17.
Conclusiones
El lenguaje Java puede no ser tan potente como lo pueda ser C++ gracias a los
punteros, pero la forma de programar es mucho mas simple, rapida y encapsulada de
lo que puede ser C++. Es un lenguaje orientado a objetos mas sencillo de aprender
que C++, y ademas es mas rapido y eficiente. Tambien hay que mencionar que con
Java se pueden hacer dos tipos de programas, aplicaciones completas y Applets. Es
un sistema multihilo y es facel de aprender como administrar las prioridades de los
hilos. Da mejor soporte para las aplicaciones para internet, ya que uno de los campos
mas fuertes de este leguaje son los Applets. Las conexiones y envo de informacion a
traves de la red es verdaderamente muy facil.
En la creacion de GUI, java ha avanzado mucho con los nuevos componentes
Swing haciendo mas facil la programaion de estos. Gracias a la M
aquina Virtual
de Java, todas las aplicaciones desarrollas en este lenguaje pueden funcionar bajo
cualquier plataforma o sistema operativo, siendo por lo tanto multiplataforma. El
u
nico impedimento de esto es que para que funcionen las aplicaciones previamente
hay que instalar la JVM, lo que trae consigo una molestia mas para los usuarios de
estos programas.
r
149
Captulo 5
Estudio de libreras JDT
[SOFT] [TIANI]
5.1.
Introducci
on
Java DICOM Toolkit es la ayuda para un programador en JAVA para construir

una aplicacion que siga lo marcado por el estandar DICOM 3.0. Combina las ventajas
y la fuerza de DICOM y JAVA en una API muy facil de usar. Proporciona numerosas
clases y metodos que simplifican la programacion de aplicaciones DICOM.
JDT1 es el primer equipo de desarrollo de software DICOM que esta implementado totalmente en JAVA. Con esto, los desarrolladores DICOM pueden beneficiarse de
las numerosas ventajas del lenguaje de programacion JAVA y desplegarlo en DICOM
applets, aplicaciones independientes JAVA y en software de servidor. JDT viene con
una API bien documentada que ha sido dise
nada para hacer que la estructura compleja del estandar DICOM sea mas accesible para los desarrolladores. JDT funciona
sobre JDK 1.1.X y JAVA 2.
5.2.
Terminologa
En esta seccion se usa palabras como conjunto de datos (Dataset) y atributos.

Conjunto de datos se usa para identificar una coleccion de atributos DICOM. Un
1
Java Dicom Toolkit
151
CAPITULO 5. ESTUDIO DE LIBRERIAS JDT
atributo se identifica por su par (n

umero de grupo, n
umero de elemento), y tiene un
cierto tipo DICOM (value representation - VR).
5.3.
5.3.1.
Datasets o conjunto de datos

Introducci
on
En JDT, todos los conjuntos de datos estan representados por com.archimed.

dicom.DicomObject. Esta clase es una subclase de com.archimed.dicom.GroupList.
Basicamente es donde residen los atributos DICOM com.archimed.dicom.TagValue.
5.3.2.
Manipulaci
on de los atributos
Un conjunto de datos DICOM es representado por un objeto de la clase DicomObject. Los diferentes atributos de estos conjuntos de datos estan internamente almacenados en el DicomObject como objetos com.archimed.dicom.Tagvalue. El objeto
TagValue contiene un par (grupo,elemento) y los valores del atributo estan almacenados en un Vector. El tama
no del Vector corresponde a la multiplicidad del atributo.
El tipo JAVA que representa el valor de un atributo depende del tipo DICOM (Value Representation - VR) definido para ese atributo especfico. Las tablas 5.1 y 5.2
muestra la equivalencia entre los tipos DICOM y sus correspondientes tipos JAVA.
Figura 5.1: Conversion entre tipo Java y tipo DICOM
152
r
5.3. DATASETS O CONJUNTO DE DATOS
Manipulaci
on de atributos simples
Hay un n
umero de metodos set/get en DicomObject con los que se pueden meter,
sacar o modificar los atributos guardados en un DicomObject. La forma de hacer
esto es con la clase com.archimed.dicom.DDict. La clase DDict tiene una constante
definida para cada atributo definido en el estandar DICOM. Por ejemplo:
DDict.dPatientName
DDict.dAccessionNumber
Esas constantes pueden ser usadas en los metodos set/get del DicomObject:
Person p = (Person)dcm.get(DDict.dPatientName);
Integer acnumber = (Integer)dcm.get(DDict.dAccessionNumber);
dcm.set(DDict.dPatientName, new Person("Fernando"));
dcm.set(DDict.dAccessionNumber, new Integer(12345));
El metodo set implcitamente convierte el valor del argumento dado al tipo DICOM
correcto.
Tambien se puede acceder a los atributos de un DicomObject a traves del par
(grupo.elemento).
Person p = (Person)dcm.get ge(0x0010, 0x0010);
Integer acnumber = (Integer)dcm.get ge(0x0008,0x0050,
DDict.dAccessionNumber);
dcm.set ge(0x0010, 0x0010, new Person("Fernando"));
dcm.set ge(0x0008, 0x0050, new Integer(12345));
Hay tambien dos metodos get que convierten directamente a String o int:
String s = dcm.getS(DDict.dPatientName);
int i = dcm.getI(DDict.dAccessionNumber);
Para manipular atributos con una multiplicidad mayor de uno, se usan los metodos get/set con un argumento adicional. La multiplicidad de un atributo se obtiene
con getSize(). Por ejemplo, suponiendo que un DicomObject dcm contiene un atributo ImageType con multiplicidad 2 y valores DERIVED/SECONDARY, entonces se
puede coger esos valores de la siguiente forma:
r
153
int multiplicity = dcm.getSize(DDict.dImageType);

//devuelve el valor 2
String str1 = (String)dcm.get(DDict.dImageType,0);
//devuelve el valor DERIVED
String str2 = (String)dcm.get(DDict.dImageType,1);
//devuelve el valor SECONDARY
Insertando el valor de un atributo ocurre lo mismo:
dcm.set(DDict.dImageType,0,"DERIVED");
dcm.set(DDict.dImageType,1,"SECONDARY");
Secuencias
Las secuencias se tratan de una forma parecida que los valores de multiplicidad
mayor de uno. Cuando un atributo en un DicomObject representa una secuencia (tipo
SQ DICOM), entonces los items de la secuencia pueden ser insertados y cogidos
con los mismos metodos get/set del DicomObject que ahora aceptan y devuelven los
DicomObejcts completos. Por ejemplo, suponiendo que el DicomObject dcm contiene
un atributo DirectoryRecordSequence con un cierto n
umero de items:
int numberofitems = dcm.getSize(DDict.dDirectoryRecordSequence);

DicomObject item0 = (DicomObject)dcm.get
(DDict.dDirectoryRecordSequence,0);
DicomObject item1 = (DicomObject)dcm.get
(DDict.dDirectoryRecordSequence,1);
Para a
nadir un valor a una secuencia, simplemente se usa el metodo set que tiene
el DicomObject que representa el item y el ndice del item.
Son accesibles con las mismas funciones get/set de las secuencias como las usadas en los datasets de los DicomObject. Esto provee a las secuencias de la misma
funcionalidad que los DicomObject.
Para un rapido acceso, hay una utilidad de la clase com.archimed.dicom.tools.
Sequences que contiene varios metodos para acceder a las secuencias. Tambien cuida
de todas las diferentes excepciones encontradas. El nombre elegido para los metodos
son muy similares que los encontrados en el DicomObject.
Comentarios:
154
r
las longitudes de los grupos no se almacenan en un DicomObject, se calculan

cuando se necesitan, as que no hay acceso a ellos.
cuando usamos set para insertar valores de atributos, los valores se alamacenan
por referencia y no se copian.
cuando usamos get para sacar valores de atributos, se devuelve una referencia
al valor.
Manipulaci
on de grupos de atributos
Para usuarios que quieran manipular los grupos enteros del conjunto de datos,
hay el acceso al grupo proporcionado por com.archimed.dicom.GroupList, el cual es
la superclase de com.archimed.DicomObject. Un grupo es un conjunto de atributos
que tienen el mismo n
umero de grupo en su par (grupo,elemento).
DicomObject copyGroup(int groupnr)
Copia el grupo con el n

umero groupnr y lo devuelve como un DicomObject nuevo.
Notar que solo se hace una copia no profunda, solo se copian referencias a los atributos.
void addGroups(DicomObject o)
Agrega a todos los grupos encontrados en o a este dataset. Solamente agregan

a los grupos que no estaban ya presentes en este dataset. Una vez mas solamente se
hace una copia baja o no profunda.
DicomObject removeGroup(int groupnr)
Suprime un grupo entero con el n

umero groupnr de este dataset. Y lo devuelve
como un DicomObject.
5.3.3.
Entrada/Salida de los datasets DICOM
Hay varias formas de leer o escribir datasets DICOM a y desde InputStreams /

OutputStreams. En ambos casos hay un metodo basico y algunos metodos mas que
permiten especificar todas las clases de parametros.
r
155
Leer datasets
void read(java.io.InputStream in)
Este metodo lee todos los atributos DICOM desde un inputStream de un DicomObject. El inputStream puede contener tanto un archivo DICOM como un conjunto
de datos (datasets) DICOM. Cuando el inputStream contiene un archivo de la parte
10 DICOM, se lee y se almacena la Meta File Information en un DicomObject separado que se puede coger mediante getFileMetaInformation(). La transfer syntax se
asume que es Implicit VR Little Endian cuando el inputStream contiene un conjunto de datos DICOM. Cuando el inputStream contiene un archivo de la parte 10 de
DICOM, el transfer syntax se detecta desde la File Meta Information.
void read(java.io.InputStream in, boolean process)

Este metodo hace igual que el anterior pero ademas permite especificar si analizar
o saltar datos de pxel. Esto ahorra el tiempo de transformacion en el que no se
necesita los datos de pxel.
void read(java.io.InputStream in, int ts, boolean process)

En el parametro ts se puede especificar que transfer syntax se usa. Este parametro
puede venir dado cuando se conoce por adelantado con que transfer syntax se codifico el dataset.
Escribir datasets
void write(java.io.OutputStream out, boolean f)
Este
es el metodo mas basico de la exportacion. Si el argumento f se fija como
true, el dataset se codifica en un archivo de la parte 10 de Dicom (archivo Dicom).
En este caso, la File Meta Information se usa si esta presente, o se crea cuando
es necesitada. Observar que la creacion de la meta information puede lanzar una
excepcion, cuando los atributos requeridos faltan (SOP Class UID, SOP Instance
UID).
void write(java.io.OutputStream out, boolean f,

int ts, boolean seq_undef)
156
r
Los parametros adicionales ts y seq_undef se pueden utilizar para escribir

conjunto de datos casi en todos los posibles tipos de DICOM. Los parametros ts y
seqUndef pueden ser usados para insertar la Transfer Syntax. Toda posible combinacion de parametros ts y f se permiten, pero no todas las combinaciones siguen los
dictados del estandar de DICOM. Si se escribe un conjunto de datos con f false y ts
otra cosa que no sea Implicit VR Little Endian, sera imposible para otras aplicaciones
decodificarlo ya que no pueden detectar el Transfer Syntax usado. El parametro seqUndef indica al escribir secuencias si se usa longitud undefinida (true) o definida
(false).
Visualizaci
on de datasets
DicomObject contiene dos metodos para mostrar todos los atributos contenidos
en un OutputStream de forma ordenada para que el ser humano sea capaz de leerlo.
void dumpVRs(java.io.OutputStream os)
void dumpVRs(java.io.OutputStream os, boolean metainfo)
Poner metainfo como true si se quiere ver la File Meta Information.
Ejemplos
Estos trozos de codigo demuestran el facil uso de JDT. Con solo unas lneas de
codigo, es posible construir soluciones DICOM poderosas.
El codigo siguiente lee un archivo DICOM desde un archivo y muestra los atributos
(incluidos los contenidos en la meta information si existe) por la pantalla.
DicomObject dcm = new DicomObject;
dcm.read(new FileInputStream("foo.dcm"));
dcm.dumpVRs(System.out, true);
El siguiente ejemplo lee los datos de un archivo y lo escribe en otro archivo usando
una transfer syntax y una secuencia de codificacion especficas.
DicomObject dcm = new DicomObject;
dcm.read(new FileInputStream("in.dcm"));
dcm.write(new FileOutputStream("out.dcm"), true,
TransferSyntax.ExplicitVRBigEndian, true);
r
157
5.3.4.
M
etodos u
tiles
Enumeraci
on de los atributos de un dataset
Con el metodo enumerateVRs es posible conseguir una enumeracion (clase de java)
de todos los atributos sontenidos en un DicomObject.
Enumeration e = dcm.enumerateVRs(false);
enumerateVRs() devuelve una enumeracion de todos los atributos de dcm como

objetos TagValue. TagValue tiene metodos para coger el valor y el par (grupo,elemento)
de un atributo.
File Meta Information

DicomObject fmi = dcm.getFileMetaInformation();
Devuelve la File Meta Information del DicomObject dcm si existe. Se puede usar
ahora fmi para a
nadir o alterar atributos especficos de esta informacion como se
quiera.
Informaci
on general
Unos pocos metodos de com.archimed.dicom.GroupList proporcionan informacion
general sobre un conjunto de datos:
int numberOfElements(): devuelve el n

umero total de atributos.
int numberOfGroups(): devuelve el n
umero total de grupos.
boolean isEmpty(): devuelve si el GroupList contiene alg
un atributo.
boolean containsGroup(int g): devuelve si el GroupList contiene el grupo especificado.
158
r
5.4.
5.4. DEPOSITOS
Dep
ositos
Hay unas clases en el paquete com.archimed.dicom que hacen mas facil a los programadores usar los data elements y los registros UIDs.
5.4.1.
Clase DDict: dep

osito de atributos
La clase com.archimed.dicom.DDict es un almacen de los VRs (value representations) y los data elements. Contiene un n
umero de constantes que representan los
diferentes VRs y un gran conjunto de constantes para los data elements:
DDict.tPN //representa el tipo DICOM PERSON.

DDict.tUS //representa el tipo DICOM UNSIGNED SHORT.
DDict.dAccesionNumber //representa el atributo AccessionNumber.
DDict.dPatientName //representa el atributo PatientName.
Los m
etodos de DDict
La clase DDict tiene metodos para obtener el par (grupo,elemento) de un atributo,
un tipo de atributo, una descripcion del atributo y para consultar una constante DDict
del atributo basada en su par (grupo,elemento).
static int getGroup(int dct)
Devuelve el n
umero de grupo para una constante DDict que representa un atributo.
static int getElement(int dct)
Devuelve el n
umero de elemento para una constante DDict que representa un
atributo.
static int getTypeCode(int dct)
r
159
Devuelve el tipo para una constante DDict que representa un atributo. Los elementos de datos que no estan en la lista de arriba tendran un DDict.tUNKNOWN.
static java.lang.String getDescription(int dct)
Da una descripcion elaborada para una constante DDict que representa un atributo.
static int lookupDDict(int g, int e)
Devuelve la constante DDict que representa el atributo con n

umero de grupo g
y n
umero de elemento e. Si no se encuentran constantes, el metodo devolvera DDict
.dUNDEFINED.
5.4.2.
Clase UID: dep

ositos UID
La clase com.archimed.dicom.UID contiene un deposito de los UIDs DICOM registrados (Parte 6 DICOM).Las constantes que representan los UIDs y que tienen que
ser usadas a traves de JDT se definen en subclases de UID:
com.archimed.dicom.TransferSyntax: constantes que representan las transfer syntax.

com.archimed.dicom.SOPClass: constantes que representan las clases SOP.
com.archimed.dicom.MetaSOPClass: constantes que representan las clases Meta
SOP.
com.archimed.dicom.SOPInstance: constantes que representan las instancias SOP.
El objeto com.archimed.dicom.UIDEntry representa un u

nico identificador y se
obtiene con la clase UID de dos formas. Usando una constante de una de las subclases
UID:
UIDEntry entry = UID.getUIDEntry(TransferSyntax.JPEGBaseline);
o usando una cadena UID:
160
r
5.5. IMAGENES
EN JDT
UIDEntry entry = UID.getUIDEntry("1.2.840.10008.1.2.4.50");
Cada uno de esos metodos de consulta devuelve un objeto UIDEntry, el cual es

un contenedor de varias propiedades del identificador u
nico especfico. Esos atributos
pueden ser obtenidos usando los metodos get.
5.5.
Im
agenes en JDT
Esta parte habla de las capacidades de imagen de JDT. Todas las clases relacionadas con las imagenes pueden ser encontradas en el paquete com.archimed.dicom.image.
5.5.1.
La clase DicomImage
La clase base para las imagenes es com.archimed.dicom.image.DicomImage. A

parte de los metodos set/get basicos para manipular los datos, inherentes al DicomObject, contiene otras formas de coger e insertar los atributos requeridos (tipo
1 y tipo 2) que son comunes a todos los DICOM Image Modality IODs (ver parte
3 de DICOM). Cuando se escribe una DicomImage en un outputstream, no hay un
reconocimiento de si todos los atributos requeridos estan presentes.
5.6.
5.6.1.
Gua para usuarios de JDT

Insertar datos que no son de imagen
DicomImage contiene un n
umero de metodos para insertar los atributos requeridos
que no estan relacionados con los datos de imagen. Una corta descripcion son estos
metodos:
void patientData(String patientName, String patientID, String birthDate, String

sex): inserta los datos del paciente.
void generalStudyData(String instanceUID, String date, String time, String physName, String studyID, String orderNumber): inserta los atributos del estudio
general.
r
161
generalSeriesData(String modality, String instanceUID, String seriesNumber):

a
nade los datos generales de serie.
generalEquipmentData(String manufacturer): a
nade datos sobre el equipo utilizado.
generalImageData(String imageNumber): a
nade datos de imagen.
sopCommonData(String sopClassUID, String sopInstanceUID): inserta los datos
comunes SOP. SOP Class UID es tpicamente uno de las diferentes image storage
SOP Classes, que pueden ser encontrados en com.archimed.dicom.SOPClass.
5.6.2.
Insertar datos de imagen con los m

etodos de DicomImage
Hay tambien metodos en com.archimed.dicom.image.DicomImage que pueden ser

usados para insertar los datos de los pxeles de la imagen. La clase contiene metodos
para imagenes en escala de grises, en paleta de colores y en RGB. Una definicion de
todos los parametros pueden ser encontrados en la API.
DicomImage dcmi = new DicomImage();

byte[] pixels = new byte[640*480]; // rellena este array con p
xeles.
byte[] red = new byte[256]; // rellena este array con un LUT rojo.
byte[] green = new byte[256]; // rellena este array con un LUT verde.
byte[] blue = new byte[256]; // rellena este array con un LUT azul.
dcmi.imagePixelData(480, 640, pixels, red, green, blue);
Esto da una DicomImage con una interpretacion fotometrica PALETTE COLOR,

tama
no 640x480 y con una profundidad de pixel de 8.
5.6.3.
Insertando los datos de imagen con ImageProducer
Hay otra forma de insertar los datos de la imagen. Dado una ImageProducer ip,
construyendo un objeto ImageIO y usando el metodo setImageProducer() para copiar
los datos de imagen desde la ImageProducer a la DicomImage:
DicomImage dcmi = new DicomImage();

ImageIO imgio = new ImageIO(dcmi);
imgio.setImageProducer(ip);
162
r
5.6. GUIA PARA USUARIOS DE JDT
Cuando se llama al metodo setImageProducer(), todos los datos se copian dentro

de la DicomImage.
Obteniendo una ImageProducer desde una DicomImage es tambien posible. Todo
marco simple de una imagen DICOM se puede coger como una ImageProducer usando
uno de los metodos siguientes:
java.awt.image.ImageProducer getImageProducer()
java.awt.image.ImageProducer getImageProducer(int i)
java.util.Vector getImageProducers()
Para imagenes de escalas de grises con profundidad de pixel mayor que 8 bits, hay
un color model (clase de java) especial com.archimed.dicom.image.GrayColorModel.
Este color model se usa en combinacion con un array int de pxeles, para producir
imagenes de 256 grises sin perdida de datos. Con este GrayColorModel, tambien es
posible meter el Window/Level usado en la produccion de la imagen.
no-comprimido transfer syntax, una imagen: un array de bytes que mantiene el

formato original de los datos de pixel definido en el estandar DICOM, ejemplos:
imagen MONOCHROME2, 8 bits asignados, 8 bits alamcenados: 1 elemento del array de bytes por pixel.
imagen MONOCHROME2, 16 bits asignados, 12 bits alamcenados: 2 elementos consecutivos del array de bytes por pixel.
imagen MONOCHROME2, 12 bits asignados, 12 bits alamcenados: 1 elemento y medio del array de bytes por pixel.
imagen RGB, configuracion plana color por pixel: 3 bytes consecutivos
representando 1 pixel.
imagen RGB, configuracion plana color por plano: el array de bytes esta dividivo en 3 partes de igual longitud cada una representando un color de
plano (Red-Green-Blue).
Los array de bytes se cogen e insertan con los metodos get(DDict. dPixelData)
y set(DDict.dPixelData,byte array) respectivamente.
no-comprimido transfer syntax, varias imagenes: un array de bytes que contienen
marcos consecutivos.
comprimido transfer syntax, una imagen: un array de bytes en el formato original de compresion.
r
163
5.6.4.
Compresi
on
Los datos de pxel de una imagen DICOM se almacena en el atributo DDict.dPixelData.

Cuando una imagen DICOM comprimida se lee desde un inputstream, los pixeldata
no se decodifican pero se almacenan internamente en arrays de bytes en su formato
de compresion por razones de rendimineto. El tipo de codificacion puede ser sacado
de la sintaxis de transferencia en el File Meta Information.
DcmObject dcm = new DicomObject();
dcm.read(new FileInputStream("c://encodedimage.dcm"));
DicomObject fmi = dcm.getFileMetaInformation();
UIDEntry tsentry = UID.getUIDEntry(fmi.get(DDict.
dTransferSyntaxUID));
System.out.println("encoding: "+ tsentry.getName());
Una utilidad de la clase com.archimed.dicom.codec.Compression proporciona un
n
umero de decodificadores:
JPEG baseline
JPEG lossless
RLE Lossless
Todos los decodificadores estan limitados a 8 bits por pxel. El decodificador JPEG
puede manejar 1 o 3 muestras por pxel. RLE es solo capaz de descomprimir 1 muestra
por pxel. El camino mas facil para descomprimir imagen entera DICOM es construir
un objeto Compression desde un DicomObject y despues llamar al metodo decom
press. Este
descodifica los datos del array de pxeles del DicomObject y los reemplaza
por los datos descomprimidos.
En el caso de una imagen DICOM multimarco, se puede decodificar el array de
bytes correspondioente a un marco individual. Primero obteniendo un array de bytes
de un marco con get(DDict.dPixelData, index of frame) y luego usando el metodo
estatico decompressframe() del objeto Compression para obtener un array de bytes
decodificado desde el array de bytes comprimido.
static byte[] decompressframe(int encoding, byte[] frame,
int width, int heigth);
Los argumentos de codificacion, ancho y alto que tienen que ser suministrados
para usar decompressframe() se encuentran en la imagen DICOM original.
164
r
5.7.
DE UNA CONEXION
5.7. CREACION
Creaci
on de una conexi
on
Para establecer una asociacion con una entidad del par DICOM, se hace uso
las clases del paquete com.archimed.dicom.network.. Es necesario un iniciador de la
asociacion y un receptor de la asociacion.
5.7.1.
Iniciador de la asociaci
on
Pasos a seguir para crear un iniciador de una asociacion DICOM.
1. Hacer una conexion TCP/IP con la entidad del par DICOM que hace uso las
clases estandares de java.net. En este ejemplo el servidor es Fourier y el puerto
104.
Socket s = new Socket("Fourier",104);
2. Crear un objeto Association con los Input and Output Streams derivadas de
Socket.
InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();
Association as = new Association(in,out);
3. Preparar un objeto Request con los parametros necesarios para establecer una
asociacion. Los parametros son al menos un ttulo de la entidad de la aplicacion
llamada (called), un ttulo de la entidad de la aplicacion llamar (calling) y un
abstract syntax con un sintaxis de transferencia. En el ejemplo el ttulo de la
entidad called es hola y el calling es Servicio. Estos ttulos no deben ser mas
de largos de 16 caracteres. Conectamos con hola para almacenar una imagen
secundaria de la captura con Implicit Little Endian transfer syntax.
Request request = new Request();
request.setCalledTitle("hola");
request.setCallingTitle("Servicio");
int[] transfersyntaxes = {TransferSyntax.
ImplicitVRLittleEndian};
request.addPresentationContext(SOPClass.
SecondaryCaptureImageStorage, transfersyntaxes);
4. Se enva la peticion a la entidad del par DICOM y recibe la respuesta.
r
165
as.sendAssociateRequest(request);
Response response = as.receiveAssociateResponse();
5. Analiza la respuesta. Se comprueba si se acepta, se rechaza o se aborta nuestra
peticion.
if (response instanceof Reject)
{
System.out.println("petici
on de asociaci
on rechazada");
System.out.println(response);
}
else if (response instanceof Abort)
{
on de asociaci
on abortada");
}
else
{
on de asociaci
on aceptada");
Acknowledge ack = (Acknowledge)response;
if (ack.getPresentationContexts() != 1)
{
System.out.println("n
umero incorrecto de Contexto
de Presentaci
on");
throw something;
}
int result = ack.getResult(0);
if (result == Acknowledge.ACCEPTANCE)
{
System.out.println("Contexto de Presentaci
on para
Secondary Capture aceptada");
}
else if (result == Acknowlege.ABSTRACT_SYNTAX_NOT_SUPPORTED)
{
System.out.println("Secondary Capture no soportada");
}
else if (result == Ackn...
...
}
6. En este punto se tiene una asociacion valida para el Secondary Capture Image
Storage y podemos enviar imagenes SC a la entidad del par DICOM.
DicomObject cstorerequest;
166
r
DE UNA CONEXION
5.7. CREACION
DicomObject cstoreresponse;
DicomObject scimage;
// crear una petici

on C-STORE en la variable cstorerequest
// y una instancia SOP Secondary Capture en la variable scimage.
...
// enviar la imagen al par de entidad DICOM
as.send(SOPClass.SecondaryCapture,cstorerequest,scimage);
// recibir la respuesta C-STORE desde el par de entidad DICOM.
cstoreresponse = as.receiveCommand();
// analizar cstoreresponse para ver si la imagen SC enviada,
// se ha guardado bien.
...
7. Acabar asociacion.
as.sendReleaseRequest();
as.receiveReleaseResponse();
5.7.2.
Receptor de la asociaci
on
Cuando una aplicacion act

ua como receptor de la asociacion, espera conexiones
entrantes de TCP/IP con el metodo de accept() de java.net.ServerSocket y dedica un
hilo para cada conexion entrante. En este ejemplo se empieza con el punto donde una
entidad del par DICOM ha hecho una conexion de TCP/IP, dando por resultado un
objeto valido de java.net.Socket que es devuelto por el metodo accept(). El codigo del
ejemplo se ejecuta normalmente en diferentes hilos en los cuales el metodo accept()
los ejecuta.
Pasos a seguir para crear un receptor de una asociacion DICOM.
1. Obtener el InputStream/OutputStream del objeto de java.net.Socket devuelto
por el accept() y crear un nuevo objeto Association.
r
167
// s es el Socket devuelto por accept()

InputStream in = s.getInputStream();
OutputStream out = s.getOutputStream();
Association as = new Association(in,out);
2. Se lee la peticion de asociacion y se crea la respuesta apropiada para la peticion.
Se hace en el ejemplo el servicio Service Class Provider for Secondary Capture
Image Storage y Verification y nuestro ttulo de la entidad de aplicacion es
= hola. No se comprueba el ttulo de la entidad de aplicacion del llamador
(calling title).
Request request = as.receiveAssociateRequest();
System.out.println("incoming association request");
System.out.println(request);
int[] abstractsyntaxes = {SOPClass.
SecondaryCaptureImageStorage,SOPClass.Verification};
Response response = ResponsePolicy.
prepareResponse(request,"hola",null,abstractsyntaxes,
TransferSyntax.ImplicitVRLittleEndian,true);
as.sendAssociateResponse(response);
3. Si la respuesta es un Reject (Rechazo) se cierra la conexion. Si la respuesta
es Acknowlwdge (Reconocida) se entra es un lazo que reciba y procese la
verificacion o Secondary Capture Image Storage relacionado con el comando
DIMSE. El lanzamiento de la asociacion tambien se maneja en el lazo.
if (response instanceof Reject)
{
System.out.println("Petici
on de asociaci
on Rechazada");
s.close();
return;
}
else if (response instanceof Acknowledge)
{
int result;
com.archimed.dicom.DicomObject dcm;
String sopclass;
// Para un mejor manejo se almacena los
//SOP Class UIDs de SC y Verification en variables
String sc_sopclass = UID.getUIDEntry(SOPClass.
SecondaryCaptureImageStorage).getValue();
String ve_sopclass = UID.getUIDEntry(SOPClass.Verification).
getValue();
168
r
DE UNA CONEXION
5.7. CREACION
while (true)
{
result = as.peek();
if (result == Association.PDATA_PDU)
{
dcm = as.receiveCommand();
sopclass = dcm.getS(DDict.dAffectedSOPClassUID);
if(sopclass.equals(sc_sopclass)
{
// Se chequea para ver si es una v
alida petici
on
// C-STORE, si es as
se leen los datos con
// receiveData(), se procesan los datos para el
// almacenaje y se env
a una respuesta C-STORE
}
else if (sopclass.equals(ve_sopclass)
{
// Chequear si es una petici
on v
alida C-ECHO
// y enviar respuesta C-ECHO
}
else
{
System.out.println("sopclass " + sopclass +
" no negociada, abortado");
as.sendAbort(Abort.DICOM_UL_SERVICE_USER,
Abort.REASON_NOT_SPECIFIED);
s.close();
return;
}
}
else if (result == Association.RELEASE_REQUEST)
{
as.receiveReleaseRequest();
as.sendReleaseResponse();
s.close();
System.out.println("asociaci
on acabada");
return;
}
else if (result == Association.ABORT)
{
Abort abort = as.receiveAbort();
s.close();
System.out.println("asociaci
on acabada por el par");
System.out.println(abort);
r
169
return;
}
}
}
5.8.
5.8.1.
Estructura de JDT
Arbol
de clases
class java.lang.Object
class com.archimed.dicom.network.Association
class java.awt.image.ColorModel (implements java.awt.Transparency)
class com.archimed.dicom.image.GrayColorModel
class com.archimed.dicom.codec.Compression
class com.archimed.dicom.DDate
class com.archimed.dicom.DDateRange
class com.archimed.dicom.DDict
class com.archimed.dicom.DDictEntry
class com.archimed.dicom.Debug
class com.archimed.dicom.network.DimseUtil
class com.archimed.dicom.network.ExtendedNegotiation
class com.archimed.dicom.GroupList
class com.archimed.dicom.DicomObject
class com.archimed.dicom.image.DicomImage
class com.archimed.dicom.image.SCImage
class com.archimed.dicom.image.ImageIO
class com.archimed.dicom.Jdt
170
r
5.8. ESTRUCTURA DE JDT
class com.archimed.dicom.Offsets
class com.archimed.dicom.Person
class com.archimed.dicom.network.Request
class com.archimed.dicom.network.Response
class com.archimed.dicom.network.Abort
class com.archimed.dicom.network.Acknowledge
class com.archimed.dicom.network.Reject
class com.archimed.dicom.network.ResponsePolicy
class com.archimed.dicom.tools.Sequences
class com.archimed.dicom.TagValue
class java.lang.Throwable (implements java.io.Serializable)
class java.lang.Exception
class com.archimed.dicom.DicomException
class com.archimed.dicom.IllegalValueException
class com.archimed.dicom.UnknownUIDException
class com.archimed.dicom.UID
class com.archimed.dicom.MetaSOPClass
class com.archimed.dicom.SOPClass
class com.archimed.dicom.SOPInstance
class com.archimed.dicom.TransferSyntax
class com.archimed.dicom.UIDEntry
class com.archimed.dicom.image.WL
5.8.2.
Packages
Com.archimed.dicom.network
Abort (Abortar): Representa el aborto de una asociacion. Los dos parametros
son, la fuente y la razon del aborto.
r
171
Acknowledge (Reconocer): Estos objetos tienen los parametros de la asociacion

Acknowledge, contiene todos los contextos de presentacion del Acknowledge y
son numerados desde 0 hasta el no de contextos de presentacion menos uno.
Puede actuar como receptor de asociacion o como iniciador de la asociacion.
Association (Asociacion): Contiene metodos para construir y destruir una asociacion entre dos entidades de aplicacion DICOM y mandar/recibir comandos
y datos (data sets) una vez que la asociacion esta establecida.
DimseUtil: Las funciones DICOM que pueden hacerse.
ExtendedNegotiation: Representa los datos de negociacion para un sintaxis abstracto
Reject (Rechazo): Representa el rechazo de una asociacion. Sus parametros son
fuente, resultado y razon.
Request (peticion): Representa todos los parametros relevantes de una asociacion
Request. Contiene todos los contextos de presentacion y son numerados desde 0
hasta el no de contextos de presentacion menos uno. Puede actuar como receptor
de asociacion o como iniciador de la asociacion.
Response (Respuesta): Representa una respuesta de un par de entidades DICOM.
Las clases implementadas son: Reject, Acknowledge y Abort.
ResponsePolicy: contiene dos tipos de metodos:
Metodos para creacion de objetos Response, basados en una peticon dada
y una poltica de aceptacion de la asociacion.
Metodos para el analisis de respuestas Acknowledge, en el contexto de una
peticion dada.
Com.archimed.dicom.codec
Compression (compresion): Es una clase que proporciona metodos para la descompresion de datos de Pixel. DICOM soporta muchos tipos de tecnicas de
compresion.
Com.archimed.dicom.image
DicomImage: Esta clase provee de metodos para construir una imagen Dicom.
GrayColorModel: Esta clase representa un ColorModel para el empleo con imagenes
de Escala de gris.
172
r
5.8. ESTRUCTURA DE JDT
ImageIO: Es una clase que proporciona metodos de convertir datos de imagen

almacenados a un ImageProducer (Productor de imagen) y viceversa.
SCImage: Esta clase proporciona metodos para construir una imagen SC.
WL: Es un contenedor basico para un par Ventana/Nivel.
Com.archimed.dicom.tools
Sequences: Estos objetos proveen los atajos para coger/poner valores dentro de secuencias. La conversion de valores esta hecha usando el esquema de
conversion DicomType-JavaType dada en la clase DicomObject.
Com.archimed.dicom
DDate: Esta clase representa la fecha de un objeto, conteniendo el da, mes y
a
no. Se ha desarollado en correspondencia al tipo Dicom DA. Es u
til, cuando
se quiere buscar en una gama de fechas.
DDateRange: Esta clase representa la gama de fechas.
DDict: Esta clase provee de un diccionario (Diccionario de datos Dicom) para
los VRs y todos los elementos de datos. Cada par (grupo,elemento) es accesible por una variable static int. Por ejemplo, (0010,0010) es representado por
DDic.dPatientName.
DDictEntry: Un objeto para una etiqueta que puede ser almacenado en el diccionario de datos.
Debug: Proporciona una variable static int por si hay que imprimir informacion
de reparacion de los errores a System.err.
DicomObject: Esta es la clase base de todos los datasets. Los metodos de acceso
proporcionados aqu son el modo de obtener/poner elementos de dato (data
elements) dentro de un objeto Dicom (DicomObject).
GroupList: Provee de metodos para el acceso de datos por grupo.
Jdt: Para obtener informacion sobre este Jdt
MetaSOPClass: Extension de la clase UID.
Offsets (Compensacion): Esta clase proporciona utilidades para calcular compensaciones en un DicomObject que va a ser escrito.
Person: Esta clase representa el PN (Person Name) en Dicom.
r
173
SOPClass: Extension de la clase UID.

SOPInstance: Extension de la clase UID.
TagValue: Representa un par (grupo, elemento) y su valor.
TransferSintax: Extension de la clase UID.
UID: Esta clase contiene un deposito de todos los UIDs Dicom certificados.
Cada UID esta en funcion del Transfer Syntax, SOPClass, MetaSOPClass y
SOPInstance.
UIDEntry: Representa la entrada de un UID en el deposito, almacenandose.
DicomExcepcion: Indica que la aplicacion ha violado la estructura y codificacion
del Dicom Data.
IllegalValueExcepcion: Indica que un valor ilegal es ledo durante una asociacion
o cuando un valor ilegal es argumento de un metodo.
UnknownUIDExcepcion: Indica que el UID incluido no esta definido en la clase
UID.
5.9.
Conclusiones
Una vez trabajado y experimentado con los dos toolkit de DICOM (dcmtk y JDT),
se llegan a las siguientes conclusiones:
El toolkit dcmtk351 cuenta con la ventaja de ser un producto gratuito, pero si
no se es un gran experto en materia DICOM y en programacion en C++, la profundizacion de su estudio es muy complicada y engorrosa, debido a la poca documentacion
proporcionada con dicha herramienta y a la gran dificultad y amplitud del codigo.
Por el contrario, JDT es un producto no gratuito, pero cuenta con las grandes
ventajas que el toolkit dcmtk351 no tiene. Lo primero a se
nalar es que el lenguaje
de programacion es JAVA, con las ventajas que conlleva con respecto a C++. Por
otro lado, contiene una documentacion amplia y muy bien estructurada, gracias a la
utilidad de javadocs, lo que facilita enormemente el trabajo y su comprension. JDT
contiene un arbol de clases, informacion de los diferentes packages, informacion sobre
las clases y sus metodos.
La eleccion despues de trabajar con los dos Toolkit ha sido el Java Dicom Toolkit
(JDT), ya que es mas facil de utilizar y debido a la creacion de un Cliente/Servidor
para la Red, las aplicaciones en Java son mas faciles y potentes.
174
r
5.9. CONCLUSIONES
Figura 5.2: Conversion de tipo DICOM a tipo Java
r
175
Captulo 6
Desarrollo de aplicaci
on
6.1.
Introducci
on
En este captulo se describen las herramientas usadas para la implementacion de

la aplicacion DICOM, tanto del cliente como del servidor.
Para estas dos aplicaciones hay que elegir el entorno de desarrollo a utilizar.
Pueden ser utilizados m
ultiples sistemas como TextPad, Visual J++, el propio JDK
o JBuilder.
El primero en analizar es el que viene incluido en el SDK, que es el JDK. Este

compilador es utilizable con cualquier editor de texto, pero es inadecuado para proyectos largos, por su pesadez textual y poca ayuda. Este compilador fue el primero en
utilizarse, pero debido a la extension del proyecto realizado se tuvo que mirar otros
compiladores.
El Visual J++ es el entorno de trabajo de Java proporcionado por Microsoft.
Tambien se utilizo pero al querer que el programa fuera multiplataforma y no perder
el potencial de Java, se decidio cambiar a otro entorno.
El TextPad fue el elegido para la creacion de la aplicacion Servidor, ya que es
un compilador parecido al JDK, pero con mas ayudas y menos pesadez a la hora de
programar.
El JBuilder de Borland fue utilizado para deserrollar el Cliente, ya que trae un
buen soporte a para la implementacion de las GUIs. Este

entorno de desarrollo es
mucho mas completo, especfico y con muchas mas prestaciones que Visual J++.
177

CAPITULO 6. DESARROLLO DE APLICACION
Por lo tanto para el desarrollo del Servidor se utiliza el compilador TextPad 4.7.0,
las libreras SDK v1.4.1, el paquete JCE para la encriptacion/desencriptacion y las
libreras DICOM JDT, mediante las cuales se va a implementar la aplicacion DICOM.
Para el desarrollo del Cliente es necesaria la utilizacion del entorno de desarrollo
JBuilder (version 7.0 Enterprise, pero compatible con la 8.0 y 9.0), las libreras del
SDK v1.4.1, el paquete JCE1 y las libreras DICOM JDT.
6.2.
Uso de SDK
6.2.1.
Introducci
on
En esta seccion se van a ver los aspectos mas importantes para la compilacion de
archivos fuentes y se van a describir las herramientas mas utilizadas en el trabajo con
Java.
Para poder realizar aplicaciones en Java es necesaria la instalacion de las librerias de SDK. Este paquete de libreras viene con la Maquina Virtual de Java, para
poder desde cualquier archivo fuente (.java) poder crear una apliacion. Esta maquina
virtual tambien es valida para poder visualizar y que se puedan ejecutar programas
desarrollados en java.
6.2.2.
Instalaci
on en Windows 98
La instalacion puede ser o bien solo de la Maquina Virtual de Java(JRE Java Enviroment Enterprise), para poder ejecutar programas de Java pero no poder compilar
ficheros fuente, o bien la instalacion de las libreras y la MVJ para poder ejecutar y
compilar programas Java.
M
aquina Virtual de Java
Para la instalacion de la Maquina Virtual de Java se debe descargar de la pagina
http://java.sun.com, teniendo que elegir la opcion del JRE para Windows. Una vez
descargado el archivo j2re-1_4_1_03-windows-i586-i.exe, se procede a la instalacion
la cual es muy sencilla. Unicamente

hay que ejecutar el archivo nombrado, de esta
1
178
Java Cryptography Extension
r
6.2. USO DE SDK
forma la JVM esta instalada y podemos ejecutar correctamente cualquier aplicacion

desarrollada en Java.
SDK
La instalacion a realizar son de las libreras de la u
ltima version SDK 1.4.1 que se
puede descargar de la pagina (http://java.sun.com). Con la instalacion de las libreras
viene incluida la JVM2 .
El primer paso a realizar es descargar el archivo, eligiendo la opcion SDK para
Windows. Este archivo se llama j2sdk-1_4_1_03-windows-i586.exe.
El siguiente paso es ejecutar el archivo, de esta forma se generan las libreras y
los ejecutables de las utilidades que ofrece Java, como son el compilador javac.exe, el
javadocs,. . .
El tercer paso es el mas importantes ya que aunque se tengan las libreras y los
ejecutables, hay que decir a la computadora donde estan. Este paso es el que diferencia
Windows 95/98 con Windows NT/2000/XP. En Windows 98 hay que dar el PATH de
donde se encuentran los ejecutables y hay que crear un CLASSPATH donde debemos
dar el camino para llegar a las libreras del SDK. Los pasos para realizar esto son:
1. En el directorio raz del sistema operativo C:\, se encuentra el archivo Autoexec.bat. Este archivo se carga cuando se inicia la computadora. Para modificarlo, hay que abrir el archivo con un editor de texto, esto se puede hacer
haciendo click derecho mientras se pulsa Shift, y se elige Abrir con. . . . Saldra un
men
u y se debe elegir un editor de texto, por ejemplo el Bloc de Notas.
2. Una vez abierto, nos disponemos a escribir en el PATH. Hay una lnea en la
que pone SET PATH, pues en esa lnea debemos incluir el directorio bin del
sdk1.4.1. con lo que quedara:
SET PATH = . . . ;C:\J2SDK1.4.1_03\BIN; %Path %
3. Ahora hay que crear el CLASSPATH. Para realizar esto hay que escribir el final
del fichero:
SET CLASSPATH = C:\j2sdk1.4.1_03\lib\dt.jar;.; %Classpath %
4. Salir guardando los cambios del fichero.
De esta forma quedan instaladas las libreras del SDK y la Maquina Virtual de
Java.
2
Java Virtual Machine
r
179

Para utilizar las libreras en cualquier fichero fuente, basta realizar un import del
paquete o clase a utilizar. Para poder trabajar con SDK es muy importante disponer
de la ayuda del API de la pagina web http://java.sun.com. La figura 6.1 muestra la
organizacion de esta API.
Figura 6.1: API de SDK 1.4.1
JCE
El JCE (Java Cryptography Extension) es un paquete especial de Java, el cual es
necesario para la encriptacion y desencriptacion de la informacion que se transfiere
en las asociaciones realizadas en la aplicacion desarrollada.
Para la instalacion hay que seguir una serie de pasos:
1. Bajarse este paquete de internet, de las posibles paginas como http://java.sun.com
o bien http://snad.ncsl.nist.gov.
2. Descomprimir el archivo descargado, el jce-b1.1-socket.zip. El lugar donde hemos
descomprimido nosotros es en C:\JAVA
180
r
6.2. USO DE SDK
3. A
nadir en el CLASSPATH:
SET CLASSPATH = C:\j2sdk1.4.1_03\lib\dt.jar;C:\JAVA\JCE;
C:\JAVA\JCE\DemoApps;C:\JAVA\JCE\Server;C:\JAVA\JCE\SCM;
C:\JAVA\JCE\rfm;C:\JAVA\JCE\jaudio;.; %Classpath %
4. Poner en el PATH:
SET PATH = . . . ;C:\J2SDK1.4.1_03\BIN;C:\JAVA\JCE\jaudio; %Path %
5. Crear una carpeta llamada .jce en C:\ y copiar en este directorio el .jce que
viene en el archivo descargado de internet, que esta dentro de la carpeta JCE.
Gracias al paquete JCE, se puede encriptar y desencriptar en alto grado.
6.2.3.
Instalaci
on en Windows 2000
M
aquina Virtual de Java
1. Descargar de la pagina http://java.sun.com, teniendo que elegir la opcion del
JRE para Windows.
2. Una vez descargado el archivo j2re-1_4_1_03-windows-i586-i.exe, se procede
a la instalacion la cual es muy sencilla. Unicamente

hay que ejecutar el archivo
nombrado, de esta forma la JVM esta instalada y podemos ejecutar correctamente cualquier aplicacion desarrollada en Java.
SDK
1. Descargar el archivo eligiendo la opcion SDK para Windows. Este archivo se
llama j2sdk-1_4_1_03-windows-i586.exe.
2. Ejecutar el archivo de esta forma se generan las libreras y los ejecutables de
las utilidades que ofrece Java, como son el compilador javac.exe, el javadocs,
jar.exe,. . .
3. Entrar en Inicio->Configuraci
on->Panel de Control->Sistema->Avanzado->Variables
de Entorno
4. En Variables del Sistema buscar la variable Path y pulsar Editar. . .
5. Seguido de lo que ponga escribir: C:\J2SDK1.4.1\03\BIN;
6. Pulsar Nueva. . . , y en nombre de variable escribir classpath y en valor de variable
escribir C:\j2sdk1.4.1_03\lib\dt.jar;.;
r
181

7. Como u
ltimo paso dar a Aceptar tres veces secuencialmente para que los cambios
se apliquen.
JCE
1. Bajarse este paquete de internet, de las posibles paginas como http://java.sun.com
o bien http://snad.ncsl.nist.gov.
2. Descomprimir el archivo descargado, el jce-b1.1-socket.zip. El lugar donde hemos
descomprimido nosotros es en C:\JAVA
3. A
nadir en el CLASSPATH, en variables de entorno:
SET CLASSPATH = C:\j2sdk1.4.1_03\lib\dt.jar;C:\JAVA\JCE;
C:\JAVA\JCE\DemoApps;C:\JAVA\JCE\Server;C:\JAVA\JCE\SCM;
C:\JAVA\JCE\rfm;C:\JAVA\JCE\jaudio;.; %Classpath %
4. Poner en el PATH, variables de entorno:
SET PATH = . . . ;C:\J2SDK1.4.1_03\BIN;C:\JAVA\JCE\jaudio; %Path %
5. Crear una carpeta llamada .jce en C:\ y copiar en este directorio el .jce que
viene en el archivo descargado de internet, que esta dentro de la carpeta JCE.
6.2.4.
Utilidades del SDK
Compilador
Es una herramienta del JDK o SDK3 . Realiza un analisis del sintaxis del codigo escrito en los ficheros fuente de Java (con extension *.java). Si no encuentra errores en el
codigo genera los ficheros compilados (con extension *.class). En el JDK de Sun dicho
compilador se llama javac.exe. Java.exe es el interprete para sistemas PC/Windows.
Una vez compilado no debera ser necesaria ninguna modificacion por el hecho
de cambiar de procesador o de ejecutarlo en otra maquina. La clave consistio en
desarrollar un codigo neutro el cual estuviera preparado para ser ejecutado sobre
la JVM.
Para realizar una aplicacion con el compilador del SDK, se debe escribir el codigo
en Java en un editor de texto cualquiera como puede ser el Bloc de Notas. Una vez
escrito debe ser guardado el fichero con extension .java, por ejemplo nombre.java. La
3
182
JDK para las antiguas versiones y SDK para las nuevas versiones
r
6.2. USO DE SDK
compilacion debe realizarse con un shell de comandos, como el del MSDOS. Para
realizar la compilacion escribir:
X:\. . . \javac nombre.java
Figura 6.2: Compilacion con SDK

Con la compilacion se genera un archivo .class, en este caso sera nombre.class.
Despues ya se puede ejecutar o interpretar, para esto escribir en el Shell:
X:\. . . \java nombre
Todo ello se realiza en el directorio donde se encuentre el fichero fuente .java.
Javadocs
En el dise
no del lenguaje se ha tenido en cuenta la documentacion de los programas
y el mantenimiento de dicha documentacion. La documentacion y el codigo se incluyen
dentro del mismo fichero.
El tipo de comentario especfico para documentar debe ser:
/** Comentario de documentaci
on */
La generacion de la documentacion se realiza en formato HTML. Se pueden crear
etiquetas de documentacion, que luego en la documentacion en HTML, saldra como
un peque
no apartado, esto se realiza poniendo @ delante de la lnea que queramos
que sea una etiqueta.
r
183

Figura 6.3: Api generada con Javadocs
Los comentarios deben aparecer inmediatamente antes de los elementos a comentar. La utilidad de documentacion javadoc es un programa que se suministra dentro
de la distribucion de J2SE4 .
/**
* La clase <em> Storagescp </em> es utilizada para poner al Servidor
DICOM a la escucha de asociaciones.
* @author Fernando Ballesteros Herranz
* @version Beta
*
*/
Modo de uso:
Javadoc [opciones] [paquetes] [archivosFuente] [@ficheros]
Hay mas de 40 opciones (consultar API) que modifican el funcionamiento de
Javadoc.
4
184
Java 2 Standard Edition
r
6.2. USO DE SDK
jar
Esta utilidad es usada para generar archivos .jar que contienen todas las clases
de la aplicacion realizada. Esto se realiza para su posterior distribucion. Ejecutando
el .jar generado, la MVJ podra ejecutar el programa desarrollado.
El formato basico del comando para crear un fichero JAR es:
jar cf fichero-jar fichero(s)-de entrada
Este comando tiene varias opciones y argumentos:
c - indica que se quiere crear un fichero JAR.

f - indica que quieres que la salida vaya a un fichero en vez de a stdout.
v - produce un salida verbosa en stderr (en version 1.1) o stdout (en version 1.2)
mientras se construye el fichero. La salida verbosa te dice el nombre de cada
fichero a
nadido al fichero JAR.
0 - indica que no quieres que el fichero JAR sea comprimido.
M - indica que no se debera producir el fichero de manifiesto por defecto.
m - utilizada para incluir informacion de manifiesto desde un fichero de manifiesto existente. El formato utilizado por esta opcion es: jar cmf existingmanifest output-file input-file(s)
x - indica que quieres extraer los ficheros de un archivo JAR.
u - actualiza el fichero JAR existente.
fichero-file es el nombre que se quiere para el fichero JAR resultante. Puedes
utilizar cualquier nombre de fichero. Por convencion, a los ficheros JAR se les
da la extension .jar, aunque no es obligatorio.
El argumento fichero(s)-de entrada es una lista delimitada por espacios de uno
o mas ficheros que deben ser situados dentro de tu fichero JAR. Este argumento
puede tener simbolo del comodn *. Si alguno de los fichero(s)-de entrada, es un
directorio, el contenido de dicho directorio se a
nadira al fichero JAR recursivamente.
Este comando generara un fichero JAR comprimido y lo situara en el directorio

actual. El comando tambien genera un fichero de manifiesto, por defecto. METAINF/MANIFEST.MF, para el archivo JAR.
r
185

Los pasos seguidos para crear el JAR de nuestra aplicacion Servidor. Estos pasos
se realizan en el Shell de comandos de MSDOS:
1. Crear un archivo nuevo (incluyendo las clases y otros recursos que te interesen
empaquetar).
jar Main.jar c:\encri.class c:\Connection.class c:\Storagescu.class
c:\Storagescp.class
2. Extraer el archivo MANIFEST.MF del archivo .jar creado:
jar xvf Main.jar META-INF/MANIFEST.MF
3. Modicar dicho archivo (en alg
un editor de texto corriente). Lo que se hace es
agregar la lnea siguiente al archivo MANIFEST.MF (este paso no se hace en
MSDOS):
Main-Class: Storagescp
4. Actualizar el .jar con el archivo MANIFEST.MF modificado:
jar -uvfm Main.jar META-INF/MANIFEST.MF
5. Probar el funcionamiento del .jar:
java -jar prueba.jar o bien haciendo doble click sobre el fichero Main.jar.
6.3.
6.3.1.
Uso de TextPad
Introducci
on
TextPad es un editor que incluye un compilador de java. En este apartado se ve

las caractersticas de este editor y su relacion con java.
6.3.2.
Caractersticas
TextPad es un poderoso editor de programas dise

nado para proporcionar potencia y funcionabilidad para satisfacer los requisitos mas exigentes. Archivos enormes
pueden ser editados (hasta los lmites de memoria virtual). El interfaz m
ultiple de
documento de Windows permite editar m
ultiples archivos simultaneamente, con hasta 2 vistas en cada fichero. El texto puede ser copiado y pegado entre los archivos.
Ademas de las capacidades de copiado y pegado, se pueden corregir los errores de
186
r
6.3. USO DE TEXTPAD
tipeo mas comunes con comandos, y transportar palabras, caracteres y lneas. El texto puede ubicarse automaticamente en el margen, o en una columna especificada, si
no cabe en una lnea. Cualquier cambio puede ser deshecho o hecho de nuevo. Las
combinaciones con frecuencia usadas de comandos se pueden salvar como macros. El
programa posee herramientas personalizables y opciones de b
usquedas. Ver figura 6.4
Figura 6.4: Entorno de trabajo de TextPad 4.7.0
6.3.3.
Uso con Java
Con este editor se pueden escribir documentos fuentes de java. Para crearlos tan
solo hay que grabarlos con la extension .java.
El TextPad tambien tiene un compilador de java, aunque carece de maquina virtual para ejecutar programas desarrollados en java y de las libreras. Este compilador
solo funciona con la instalacion previa de las libreras del JDK o SDK.
Una vez instaladas las libreras, para instalar el TextPad tan solo hay que ejecutar
el archivo Setup del programa.
r
187

El compilador muestra que errores ocurren en la compilacion y si no ocurre ning

un
error genera el archivo .class.
No tiene ayudas para java. Es un editor en el que viene incluido un compilador de
java. No es bueno para la creacion de interfaces graficas, por esto en nuestra aplicacion
solo ha sido utilizado para la creacion del Servidor DICOM, ya que este no necesita
interfaz de usuario, es una aplicacion que se administra ella sola sin necesidad de
intervencion directa.
6.4.
6.4.1.
Uso de JBuilder
Introducci
on
En esta seccion se van a ver los aspectos mas importantes del JBuilder 7.0 Enterprise. Este entorno de desarrollo esta orientado a la creacion de interfaces graficas,
por este motivo la mayor parte de la aplicacion cliente DICOM ha sido desarrollada
con el JBuilder. La aplicacion del cliente es compatible con las nuevas versiones que
han ido saliendo a lo largo del a
no del JBuilder como las versiones 8.0 y 9.0.
6.4.2.
Instalaci
on
La instalacion es muy sencilla tan solo hay que seguir estos pasos:
1. Ir a la pagina web de JBuilder www.borland.com y descargar la version de

JBuilder deseada.
2. Pedir un archivo de activacion. Para esto hay que registrarse.
3. Colocar el archivo de activacion recibido en la carpeta de usuario si se utiliza
Windows NT/2000 o colocarla en la carpeta Windows si se trabaja en Windows
95/98.
4. Ejecutar el JBuilder y cuando pida un archivo de activacion indicarle la ruta a
seguir para llegar a este.
5. Una vez hecho esto se tiene un programa de prueba de 1 mes, pero si se consigue
un archivo jbuilder.jar sustituto al que venga con la aplicacion, este se debe sobrescribir sobre el existente, que esta locacizado en . . . /JBuilder/bin/jbuilder.jar.
188
r
6.4.3.
6.4. USO DE JBUILDER
JDK y JBuilder
Al instalarse el JBuilder, instala por defecto el JDK v1.3.1 y utiliza estas libreras
para compilar.
En nuestra aplicacion ha sido necesaria la utilizacion de las JDK 1.4.1, por lo que
hay que cambiar la referencia de las libreras. Para cambiar las JDK 1.3.1 a las JDK
1.4.1 hay realizar una peque
na configuracion dentro del JBuilder.
1. Entrar en Herramientas
2. Pinchar en Configurar JDK. . .
Figura 6.5: Configuracion de JDK

3. Pulsar el boton Cambiar. . .
4. Elegir en el arbol que se abre al directorio donde se encuentren las nuevas
libreras en nuestro caso C:/j2sdk1.4.1_03
5. Pulsar Aceptar
r
189

Figura 6.6: Designacion de nuevas JDK

Con esto hecho, las aplicaciones que se realicen a partir de este momento se apoyaran en las nuevas libreras designadas. Ver figura 6.6
6.4.4.
Creaci
on de aplicaciones en JBuilder
Se va a crear un simple editor de texto para ver como se realiza una aplicacion en
el JBuilder. A partir de este ejemplo es posible realizar aplicaciones mas completas y
complejas. Tan solo recordar que el JBuilder esta orientado a la creacion de interfaces
de usuario y con esto desarrollamos nuestra aplicaion Cliente DICOM.
Pasos:
Paso 1: Creaci
on de un proyecto
Para crear un proyecto se usa el asistente para proyectos y el asistente para aplicaciones, de esta forma:
1. Pulsar Archivo->Nuevo Proyecto

2. Realizar los siguientes pasos:
190
r
Figura 6.7: Asistente para proyectos

Nombre: Editor de Texto. (As se llamara el proyecto y la carpeta donde
se encontrara el proyecto)
Tipo (tipo de archivo): .jpx
Seleccionar la opcion Generar archivo de notas del proyecto. Al seleccionar esta opcion, el asistente para proyectos crea un archivo HTML para
las notas del proyecto y lo a
nade al mismo.
3. Aceptar con las opciones por defecto de los pasos 1 ,2 y 3. Ver figura 6.7
Para ajustar las propiedades del proyecto hay que entrar en Proyecto->Propiedades
del Proyecto. . . . En nuestro caso ajustaremos el Estilo de c
odigo a Adaptador est
andar
Una vez creado nuestro proyecto, pasamos a crear una aplicacion dentro del proyecto mediante el asistente para aplicaciones:
1. Pinchar en Archivo->Nuevo.
2. Hacer doble click sobre el icono Aplicacion para abrir el Asistente para aplicaciones. Ver figura 6.8
3. Poner el nombre del paquete igual al nombre del proyecto creado, y el nombre
de la clase el que se quiera. (Tener en cuenta que este nombre sera el nombre
de la clase principal)
4. Pulsar Siguiente para ir al Paso 2. Marcar la opcion de Generar comentarios de
cabezera
r
191

Figura 6.8: Galera de objetos

5. Poner nombre de clase y de Ttulo (este sera el ttulo que aparecera en la barra de
ttulo de la aplicacion). Marcar las 5 opciones que hay: Generar barra de men
u,
Generar barra de herramientas, Generar barra de estado, Generar cuadro Acerca
de y Centrar marco en la pantalla. De esta forma se genera automaticamente el
codigo mas general correspondiente a las opciones seleccionadas. Ver figura 6.9
6. Pulsar en Finalizar. Se a
nade al proyecto un archivo .java y archivos de imagen.
7. Guardar el proyecto utilizando Archivo->Guardar Proyecto.
8. Pulsar la pesta
na Dise
no del archivo abierto, TextEditFrame.java. La pesta
na
Dise
no, ubicada en la parte inferior de la ventana del Visualizador de aplicaciones, abre el dise
nador de interfaces de usuario. Ver figura 6.10 Se puede
observar cambios en el IDE de JBuilder:
En el panel de contenido aparece el dise
nador de interfaces.
El arbol de componentes aparece en el panel de estructura.
El Inspector aparece a la derecha del dise
nador.
Paso 2: A
nadir
area de texto
En este paso se crea un area de texto que rellena por completo el marco de la
interfaz de usuario entre la barra de men
us y la barra de estado. Para lograrlo, el
gestor de dise
no del contenedor principal de la interfaz de usuario debe utilizar BorderLayout. Como consecuencia de la utilizacion del Asistente para aplicaciones, el
principal contenedor de esta interfaz de usuario, que aparece como this en el arbol de
192
r
Figura 6.9: Asistente para aplicaciones

componentes, contiene un JPanel denominado contentPane que ya se ha cambiado a
BorderLayout. Lo u
nico que hay que hacer ahora es a
nadir los componentes del area
de texto a contentPane.
Para ello, se a
nade un panel de desplazamiento en el contentPane y despues se
coloca un componente de area de texto dentro del panel de desplazamiento. El panel
de desplazamiento proporciona barras de desplazamiento al area de texto.
1. Hacer click en la pesta

na TextEditFrame del editor, y a continuacion seleccionar
la pesta
na Dise
no.
2. Hacer click en el componente contentPane del arbol de componentes para seleccionarlo, como se muestra a continuacion. Figura 6.11.
3. Pulsar la pesta
na Contenedores Swing en la paleta de componentes y seleccionar
el componente JScrollPane.
4. Hacer click en el centro de contentPane del dise
nador de interfaces. Esto coloca el
componente JScrollPane en el panel de contenido y debera darle una restriccion
de centro BorderLayout, haciendo que ocupe completamente el area situada
entre la barra de herramientas y la barra de desplazamiento. Otra forma es
seleccionando Edicion->Deshacer.
5. Seleccionar el nuevo componente jScrollPane1 en el arbol de componentes.
r
193

Figura 6.10: Vista en dise

no
6. Fijarse en el valor de la propiedad constraints del Inspector y compruebar que
se le esta asignando el valor Center. Si no es as, seleccionar Center de la lista
desplegable.
7. Pulsar la pesta
na Swing en la paleta y seleccionar el componente JTextArea.
8. Hacer click sobre el componente jScrollPanel en el arbol de componentes o
arrastrarlo al dise
nador de interfaces para colocar JTextArea en el panel de
desplazamiento.
9. En el Inspector, hacer click con el boton derecho sobre la propiedad text y
seleccionar Borrar el valor de la propiedad para eliminar es jTextArea1 del
area de texto.
10. Por u
ltimo, se deben definir algunas propiedades en jTextArea1 para que se
ajusten automaticamente las lneas de texto y se haga en los espacios entre
palabras. En el Inspector, asignar los siguientes valores:
lineWrap = true
wrapStyleWord = true
background = white
A continuacion, compilar el programa y ejecutarlo para ver que aspecto ofrece:
194
r
Figura 6.11: contentPane

1. Seleccionar Proyecto->Ejecutar Make del proyecto en el men
u. Esto compila
todos los archivos del proyecto y crea un archivo TextEdit -> Class.class y un
TextEditFrame.class en una carpeta de clases dentro de la carpeta de proyectos.
Debera compilarse sin errores.
2. Hacer click en el boton Ejecutar en la barra de herramientas de JBuilder o
seleccionar Ejecutar->Ejecutar proyecto en el men
u. Ahora la interfaz de usuario
ofrece un aspecto similar al de la figura 6.12
3. En la aplicacion Editor de texto, seleccione Archivo->Salir para cerrar la
ventana de ejecucion.
Paso 3: Crear men

us
En este paso se van a crear estos men
us:

na Dise
no de TextEditFrame.java si a
un no esta seleccionada.
r
195

Figura 6.12: Editor de texto ejecutado
Figura 6.13: Men

u
2. Hacer doble click sobre jMenuBar1 en la carpeta Menu del arbol de componentes
para abrir el dise
nador de men
us. (Tambien puede seleccionar un elemento de
men
u del arbol de componentes y pulsar Intro)
3. Seleccionar el elemento de men
u Archivo->Salir en el dise
nador de men
us o
jMenuFileExit en el arbol de componentes. El dise
nador de men
us resaltara el
elemento seleccionado.
4. Hacer click en el boton Insertar elemento de men
u de la barra de herramientas
del dise
nador de men
us, o pulse la tecla Insert del teclado. Encima de Salir
se introduce un nuevo elemento de men
u resaltado y vaco.
5. Escribir Nuevo en el area resaltada.
6. Pulsar Flecha abajo para aceptar la nueva entrada y bajar al siguiente elemento
(en este caso, el elemento de men
u Salir).
196
r
7. Hacer click derecho en Salir y seleccionar Insertar elemento de men

u en el
men
u contextual. Escribir Abrir.
8. De la misma forma, a
nadir los elementos de men
u Guardar y Guardar como.
9. Seleccionar Salir y hacer click en el boton Separador de la barra de herramientas
para insertar una barra. El men
u Archivo ya esta terminado.
10. Hacer click derecho en la barra principal de men
us y seleccionar Insertar men
u.
As se crea un men
u entre los men
us Archivo y Ayuda. Escribir Edicion como
nombre de este men
u.
11. Pulsar Intro para descender hacia la siguiente entrada vaca. No es necesario
pulsar Insert aqu porque este men
u no contiene ning
un elemento despues de la
entrada actual. Sugerencia: Para borrar una entrada, seleccionar y hacer click
en el boton Borrar de la barra de herramientas, o pulsar la tecla Supr dos
veces. La primera vez que se pulsa la tecla Supr se borra el texto de la entrada.
La segunda vez elimina la entrada del men
u.
12. Proseguir con la construccion del men
u Edicion tal y como se indica en la imagen
6.14, a
nadiendo tres elementos: Fuente (JBuilder SE y Enterprise), Color de
texto y Color de fondo. Si alguna entrada tiene una longitud superior al area
de edicion, el texto se desplazara automaticamente a medida que se escriba.
Cuando se pulse Intro, el dise
nador de men
us ajustara el ancho del men
u para
mostrar el elemento mas largo de la lista.
Figura 6.14: Editor

13. Cerrar el dise
nador de men
us con un doble clic en cualquier componente de la
seccion de la interfaz de usuario del arbol de componentes. Esto hara que el
panel de contenido cambie al dise
r
197

14. Guardar el archivo y ejecutar la aplicacion. Ahora la interfaz de usuario ofrecera un aspecto similar al de la figura 6.14.
Paso 4: A
nadir un cuadro de di
alogo Selector de fuentes
Se comienza a enlazar los sucesos de men
u, empezando con el elemento de men
u Edici
on->Fuente que es el que va a mostrar el cuadro de dialogo Selector de fuentes.
En primer lugar, para poder utilizar esta opcion de men
u, se debe a
nadir un
componente cuadro de dialogo Selector de fuentes a la clase TextEditFrame:
1. Abrir TextEditFrame.java en el dise
2. Seleccionar la pesta
na Mas dbSwing de la paleta de componentes y hacer click
en el componente FontChooser.
3. Hacer click en cualquier lugar del arbol de componentes o en el dise
nador de
interfaces, para a
nadir el FontChooser al dise
no. Esto situara el componente
dentro de la clase como fontChooser1 y lo mostrara en la carpeta Otros del
arbol de componentes.
Solo se ve el componente cuadro de dialogo en el arbol de componentes, no en el
dise
Creacion de un suceso para el elemento de men
u Edici
on->Fuente, que lanzara el
Selector de fuentes:
u Edici
on->Fuente en el arbol de componentes.
Debera ser jMenuItem5 (en el segundo nodo de men
u, llamado jMenu1). Se
observa que la propiedad text para este elemento de men
u del Inspector dice
Fuente. No importa si su elemento de men
u Fuente tiene un n
umero diferente
a este. Pero aseg
urarse de seleccionar el correspondiente al men
u Fuente.
na sucesos en el Inspector, y hacer doble click en el campo de valor (la segunda columna) del suceso actionPerformed. En los men
us,
botones y otros muchos componentes de la interfaz de usuario de Java, actionPerformed es el suceso principal de usuario, que debera capturar para responder al usuario cuando utiliza el men
u o el boton. El nombre del metodo de
tratamiento de sucesos aparece en el campo de valor. Si el metodo no existe
todava, esta operacion muestra el nombre propuesto por defecto para el nuevo
metodo de gestion del suceso. Para este nuevo manejador de sucesos, el nombre
propuesto es jMenuItem5 actionPerformed. Figura 6.15
198
r
Figura 6.15: actionPerformed

3. Hacer doble click en el valor de este suceso, o pulsar Intro para crear el suceso.
Si el metodo de tratamiento del suceso es nuevo, esta operacion generara un stub
vaco para el metodo en el codigo fuente. Independientemente de si el metodo
es nuevo o ya existe, el foco de ventana cambiara a codigo fuente en el editor y
colocara el cursor dentro del metodo de tratamiento de sucesos. En el caso de
un metodo nuevo de tratamiento de sucesos, como es el caso, vera que la seccion
principal del metodo no contiene todava codigo alguno.
4. Escribir esta lnea de codigo en el cuerpo de este nuevo metodo vaco (entre las
llaves de apertura y cierre): fontChooser1.showDialog();
Ahora el metodo debera parecerse a este:
void jMenuItem5_actionPerformed(ActionEvent e) {
fontChooser1.showDialog();
}
5. Guardar y ejecutar la aplicacion. El elemento de men
u Edici
on->Fuente debera abrir el cuadro de dialogo Selector de fuentes. Si no, compruebar que la
propiedad frame tiene el valor this. Aunque se intente cambiar la fuente, no
sucedera nada. Esto se debe a que no se utiliza el resultado del FontChooser
para cambiar el texto del area de edicion. Esto sera lo siguiente que se haga.
6. Cerrar la aplicacion EditorDeTexto.
r
199

Paso 5: Vinculaci
on de sucesos de elemento de men
u al cuadro de di
alogo
Selector de fuentes
Se va a utilizar el cuadro de dialogo Selector de fuentes para modificar la propiedad
font de textArea1.

na Fuente y seleccionar el metodo de tratamiento del suceso del elemento de men
u Fuente (jMenuItem5_actionPerformed(ActionEvent
e))) recien creado.
Figura 6.16: jMenu

2. Introducir este codigo en el metodo de tratamiento de sucesos para el elemento de men
u Fuente (jMenuItem5), entre las llaves de apertura y cierre, asegurandose de reemplazar el codigo antiguo fontChooser1.showDialog();:
// Gestiona el elemento de men
u "Edici
on Fuente"
// Obtiene la fuente existente en el
area de texto
// y la lleva al Selector de fuente antes de mostrarlo
200
r
// para que se modifique la fuente

// que ya existe
fontChooser1.setSelectedFont(jTextArea1.getFont());
//
//
//
if
Obtiene la nueva fuente del Selector de fuentes

Comprueba primero el valor devuelto por showDialog() para
ver si el usuario puls
o Aceptar.
(fontChooser1.showDialog()) {
// Asigna a la fuente de jTextArea1 el valor

// seleccionado por el usuario antes de pulsar Aceptar
jTextArea1.setFont(fontChooser1.getSelectedFont());
}
//pinta el men
u de nuevo una vez que el elemento se
//ha seleccionado
this.repaint();
//Vuelve a dibujar el texto correctamente si hay
//texto selecionado al cambiar la fuente.
jTextArea1.repaint();
Todo el metodo debe tener el siguiente aspecto:
u "Edici
on Fuente"
// Obtiene la fuente existente en el
area de texto
// y la lleva al Selector de fuente antes de mostrarlo
// para que se modifique la fuente
// que ya existe
fontChooser1.setSelectedFont(jTextArea1.getFont());
//
//
//
if
Obtiene la nueva fuente del Selector de fuentes.

Comprueba primero el valor devuelto por showDialog() para
ver si el usuario puls
o Aceptar.
(fontChooser1.showDialog()) {
// Asigna a la fuente de jTextArea1 el valor

// seleccionado por el usuario antes de pulsar Aceptar
jTextArea1.setFont(fontChooser1.getSelectedFont());
}
//pinta el men
u de nuevo una vez que el elemento se
//ha seleccionado
this.repaint();
//Vuelve a dibujar el texto correctamente si hay texto
//selecionado al cambiar la fuente.
r
201

jTextArea1.repaint();
}
3. Guardar y ejecutar la aplicacion y escribir algo en el area de texto.
4. Seleccionar el texto y utilizar el elemento de men
u Edici
on->Fuente para cambiar la fuente. En esta aplicacion, se cambia la fuente de la totalidad del area de
texto (no solamente del texto seleccionado). No espere que la configuracion de
fuentes se mantenga. No introduciremos codigo para activar esa caracterstica.
Paso 6: Vinculaci
on de sucesos de elementos de men
u a JColorChooser
A continuacion se crean los sucesos de men
u Edici
on->Color de texto y Edici
on>Color de fondo y se los vincula con el cuadro de dialogo JColorChooser de Swing.
Al no necesitar asignar valores a ninguna de las propiedades de JColorChooser en
el dise
nador, no es preciso a
nadirlo a la interfaz de usuario del dise
nador. Puede llamarse directamente desde el manejador del suceso actionPerformed() de un elemento
de men
u del siguiente modo:
1. Vuelva al dise
nador de TextEditFrame.java.
2. Seleccionar el segundo elemento de men
u del arbol de componentes en Edicion
(jMenuItem6) que tiene escrito Color de texto en la propiedad actionCommand.
3. Seleccionar la pesta
na Sucesos en el Inspector y haga click tres veces en el suceso
actionPerformed() para crear el manejador del suceso:
void jMenuItem6\verb_actionPerformed(ActionEvent e) {
}
4. A
nadir el codigo siguiente en el stub del manejador del suceso:
//Gestiona el elemento de men
u "Color de texto"
Color color = JColorChooser.showDialog(this,"Color de texto",
jTextArea1.getForeground());
if (color != null) {
jTextArea1.setForeground(color);
}
//pinta el men
u de nuevo una vez que el elemento
//se ha seleccionado
this.repaint();
202
r
5. Volver al dise
nador.
6. Seleccionar el tercer elemento de men
u en el arbol de componentes, en Edicion
(menuItem7), que debe tener la etiqueta Color de fondo en la propiedad
actionCommand. Crear un suceso actionPerformed() para el, tal como hizo con
jMenuItem6
7. Insertar el siguiente codigo en el suceso actionPerformed() de jMenuItem7:
u "Color de fondo"
Color color = JColorChooser.showDialog(this,"Color de fondo",
jTextArea1.getBackground());
if (color != null) {
jTextArea1.setBackground(color);
}
//pinta el men
u de nuevo una vez que el elemento
//se ha seleccionado
this.repaint();
8. Guardar el archivo, compilar y ejecutar la aplicacion. Escribir texto y hacer
pruebas con los colores de primer plano y de fondo.
Paso 7: Adicci
on de un manejador a un suceso de men
u para borrar el
area de texto
Se va a capturar el elemento de men
u Archivo->Nuevo con un manejador que borra
el contenido del area de texto.
1. Vuelva al dise
nador.
u Archivo->Nuevo del arbol de componentes
(jMenuItem1).
3. Crear un suceso actionPerformed() e introducir en el este codigo:
u Archivo|Nuevo.
// Borra el texto del
area del texto.
jTextArea1.setText("");
4. Guardar y ejecutar la aplicacion, escribir algo en el area de texto y ver que sucede
al seleccionar Archivo->Nuevo. Debera borrarse el contenido. Observar que no
se pregunta si se desea guardar el archivo antes. Para poder tratar este aspecto,
se tiene que configurar la infraestructura para la lectura y escritura de archivos
de texto, para controlar si el archivo ha cambiado y necesita guardarse.
r
203

Paso 8: A
nadir un cuadro de di
alogo selector de archivos
Se va a enlazar el elemento de men
u Archivo->Abrir con un manejador de un suceso
que presenta al usuario un JFileChooser (cuadro de dialogo para abrir archivos) para
archivos de texto. Cuando el usuario selecciona un archivo y hace click en Aceptar
el manejador del suceso abre el archivo de texto y coloca su contenido dentro de
JTextArea.
1. Volver al dise
nador y seleccionar el componente JFileChooser de la ficha Swing
Containers de la paleta de componentes.
2. Hacer click en la carpeta IU del arbol de componentes para colocar el componente.
u Archivo->Abrir en el arbol de componentes
(jMenuItem2).
4. Crear un suceso actionPerformed() e introducir este codigo:
//Gestionar el elemento de men
u Archivo|Abrir.
//Utilizar la versi
on OPEN del cuadro de di
alogo, comprobar
//el valor devuelto de Aceptar/Cancelar
if (JFileChooser.APPROVE_OPTION == jFileChooser1.
showOpenDialog(this)) {
// Muestra el nombre del directorio y archivos abiertos en
//la barra de estado.
statusBar.setText("Abierto "+jFileChooser1.getSelectedFile().
getPath());
// El c
odigo debe ir aqu
para cargar realmente el texto
// en el TextArea.
}
5. Salvar y ejecutar la aplicacion. En el men
u Archivo->Abrir, seleccionar un archivo y pulsar aceptar. Debe aparecer el nombre del archivo y el directorio completo
en la lnea de estado en la parte inferior de la ventana. Sin embargo, el area de
texto seguira vaca.
6. Cerrar la aplicacion EditorDeTexto antes de continuar.
204
r
Paso 9: A
nadir c
odigo para leer texto de un archivo
Se va a a
nadir codigo para leer el texto del archivo seleccionado por el usuario y
ponerlo en el JTextArea.
En primer lugar, hay que a
nadir un nuevo metodo a la clase para realizar la
operacion de apertura del archivo. Este metodo se llamara openFile().
1. Cambiar el editor a TextEditFrame.java e introducir el siguiente metodo openFile(). Se puede poner en cualquier lugar de la clase (fuera de otros metodos).
Un buen lugar para ubicarlo es justo despues del codigo del metodo jbInit() y
justo antes del suceso jMenuFileExit_actionPerformed().
// Abrir el archivo con nombre; lee el texto del archivo al
//jTextArea1; informar a la barra de estado.
void openFile(String fileName)
{
try
{
// Abrir un archivo con nombre.
File file = new File(fileName);
// Obtener el tama~
no del archivo abierto.
int size = (int)file.length();
// Asignar cero a un contador para realizar un recuento de
// los caracteres que se han le
do del archivo.
int chars_read = 0;
// Crear un lector de entrada basado en el archivo,
//para leer los datos.
// FileReader gestiona las conversiones de c
odigo de
//caracteres internacionales.
FileReader in = new FileReader(file);
// Crea una matriz de caracteres del tama~
no del archivo,
// para utilizarla como b
ufer de datos, en el que leer
// los datos del texto.
char[] data = new char[size];
// Leer todos los caracteres disponibles en el b
ufer.
while(in.ready()) {
// Incrementar el recuento de cada car
acter le
do,
// y acumularlos en el b
ufer de datos.
r
205

chars_read += in.read(data, chars_read, size - chars_read);

}
in.close();
// Crear una cadena temporal que contenga los datos,
// y asignar la cadena a JTextArea.
jTextArea1.setText(new String(data, 0, chars_read));
statusBar.setText("Abierto "+fileName);
}
catch (IOException e)
{
statusBar.setText("Error al abrir "+fileName);
}
}
2. A
nadir la importacion siguiente a la lista de importaciones de la parte superior
del archivo:
import java.io.*;
3. Hacer click en el manejador del suceso de Archivo->Abrir (jMenuItem2_ actionPerformed(ActionEvent)) del panel de estructura para buscarlo rapidamente en
el codigo fuente.
4. Reemplazar el codigo fuente en el manejador del suceso de Archivo->Abrir if()
que contena previamente:
statusBar.setText("Abierto "+jFileChooser1.getSelectedFile().
getPath());
// El c
odigo debe ir aqu
para cargar realmente el texto
// desde el archivo al JTextArea.
con este nuevo metodo openFile(), empleando el nombre de directorio y archivo
concatenados.
// Llamar a openFile para intentar cargar el texto desde el
//archivo al JTextArea
openFile(jFileChooser1.getSelectedFile().getPath());
//pinta el men
u de nuevo una vez que el elemento se ha
//seleccionado
this.repaint();
206
r
5. Probar el programa ahora y ver si funciona. Guardar y ejecutar el programa,

y abrir un archivo de texto en el editor. El editor de textos debe tener alg
un
contenido.
Paso 10: Adicci

on de c
odigo a los elementos de men
u para guardar un
archivo
Ahora se precisa un codigo que vuelva a grabar el archivo a disco cuando se
seleccione Archivo->Guardar y Archivo->Guardar como. . .
Para ello, es necesario a
nadir una variable de instancia String para almacenar el
nombre del archivo abierto, ademas de a
nadir metodos para escribir de nuevo el texto
en este y en otros archivos.
1. Hacer click en jFileChooser1 en el panel de estructura. Esto llevara a la u

ltima entrada de la lista de declaraciones de variables de instancia (dado que
jFileChooser1 fue la u
ltima declaracion realizada).
2. A
nadir las siguientes declaraciones al final de la lista despues de jFileChooser1:
String currFileName = null; //V
a completa con nombre de archivo.
//null significa nuevo / sin t
tulo.
boolean dirty = false; // True significa texto modificado.
3. Hacer click en el metodo openFile(String fileName) del panel de estructura
para buscarlo rapidamente en el codigo fuente. Situar el cursor en el metodo, a
continuacion de la lnea siguiente que se lee el archivo en JTextArea:
jTextArea1.setText(new String(data, 0, chars_read));
4. Insertar el siguiente codigo en esta posicion:
// Almacenar en cach
e el nombre de archivo abierto
//actualmente para utilizarlo al guardar...
this.currFileName = fileName;
// ...y marcar la sesi
on de modificaci
on como borrada
this.dirty = false;
5. Crear un metodo saveFile() al que se pueda llamar desde el manejador del suceso
de Archivo->Guardar. Puede ser colocado justo despues del metodo openFile().
Este metodo escribe el nombre de archivo en la barra de estado al guardar.
r
207

// Guardar archivo actual; gestionar los que no tienen

//nombre de archivo; informar a la barra de estado.
boolean saveFile() {
//Gestionar donde a
un no exista nombre de archivo.
if (currFileName == null) {
return saveAsFile();
}
try
{
// Abrir el archivo del nombre actual.
File file = new File (currFileName);
// Crear un escritor de salida que escribir
a ese archivo.
// FileWriter gestiona las conversiones de c
odigos de
//caracteres internacionales.
FileWriter out = new FileWriter(file);
String text = jTextArea1.getText();
out.write(text);
out.close();
this.dirty = false;
// Muestra el nombre del directorio y archivos abiertos
//en la barra de estado.
statusBar.setText("Error al guardar "+currFileName);
return true;
}
catch(IOException e) {
statusBar.setText("Error al guardar "+currFileName);
}
return false;
}
6. Crear el metodo saveAsFile() al que se llama desde saveFile() si no existe nombre de archivo actual. Se utilizara tambien desde el men
u Archivo->Guardar
como. . . . A
nadir el codigo siguiente justo a continuacion del metodo saveFile():
// Guardar el archivo actual, preguntando al usuario el
//nuevo nombre de destino.
// Informar a la barra de estado.
boolean saveAsFile() {
//Utilizar la versi
on SAVE del cuadro de di
alogo,
//comprobar el valor devuelto de Aceptar/Cancelar
208
r
showSaveDialog(this)) {
// Asignar al nombre de archivo actual la selecci
on
//del usuario
// a continuaci
on realizar un saveFile normal
currFileName = jFileChooser1.getSelectedFile().getPath();
//pinta el men
u de nuevo una vez que el elemento se ha
//seleccionado
this.repaint();
return saveFile();
}
else {
this.repaint();
return false;
}
}
7. Volver al dise
nador y crear un manejador del suceso actionPerformed() para el
elemento de men
u Archivo->Guardar (jMenuItem3). Insertar el siguiente codigo:
u Archivo|Guardar.
saveFile();
8. Crear un manejador de sucesos actionPerformed() para el elemento de men
u Archivo>Guardar como. . . (jMenuItem4) e introducir este codigo:
u Archivo|Guardar como.
saveAsFile();
9. Guardar y compilar el archivo. Ejecutarlo e intentar guardar texto en un archivo.
Paso 11: Adicci

on de c
odigo para comprobar si se ha modificado un archivo
El programa debe controlar si un archivo se ha modificado desde que se creo,
abrio o guardo de forma que pueda preguntar al usuario si debe guardarse antes
cerrar el archivo o salir del programa. Para ello, se a
nadira una variable de tipo
booleano denominada dirty.
1. Hacer click en el siguiente metodo del manejador del suceso de Archivo->Nuevo

en el panel de estructura: jMenuItem1_actionPerformed(ActionEvent e)
r
209

2. A
nadir el codigo siguiente al final de este metodo para borrar el contenido de
las variables dirty y currFileName. Colocarlo inmediatamente detras de la lnea
jTextArea1.setText();, y antes de la llave de cierre.
// borra el nombre de archivo actual y define el
// archivo como limpio:
currFileName = null;
dirty = false;
Se utiliza el componente cuadro de dialogo JOptionPane para presentar un
cuadro de mensaje de confirmacion para constatar si el usuario desea guardar un
archivo modificado antes de cerrarlo cuando selecciona Archivo->Abrir, Archivo>Nuevo o Archivo->Salir. Este cuadro de dialogo se abre con una llamada a
un metodo de clase en JOptionPane, por lo que no es necesario a
nadir un
componente JOptionPane al programa.
3. A
nadir el metodo okToAbandon() siguiente al codigo fuente. Puede situar este
metodo justo a continuacion del metodo saveAsFile():
// Comprobar si el archivo se ha modificado.
// Si es as
obtener del usuario una decisi
on ">Guardar?
// s
/no/cancelar".
boolean okToAbandon() {
int value = JOptionPane.showConfirmDialog(this,
">Guardar cambios?", "Editor de texto", JOptionPane.
YES_NO_CANCEL_OPTION) ;
switch (value) {
case JOptionPane.YES_OPTION:
// s
, por favor guardar cambios
return saveFile();
case JOptionPane.NO_OPTION:
// no, abandonar modificaciones
//por ejemplo devolver true sin guardar
return true;
case JOptionPane.CANCEL_OPTION:
default
// cancelar
return false;
}
}
4. Situar las llamadas a este metodo okToAbandon() en la parte superior de los
manejadores de los sucesos de Archivo->Nuevo y Archivo->Abrir, as como en
el manejador del suceso de Archivo->Salir generado por el asistente. En cada
210
r
caso, compruebe el valor que devuelve okToAbandon() y realice solamente la

operacion si el valor devuelto es true.
A continuacion aparecen los manejadores de los sucesos modificados:
En el caso de Archivo->Nuevo encerrar el codigo de la seccion principal
del metodo en un nuevo if, de manera que ese codigo se ejecute solamente
si okToAbandon() devuelve true. El metodo modificado debe tener el
siguiente aspecto:
u Archivo|Nuevo.
if (okToAbandon()) {
// borrar el texto del TextArea
jTextArea1.setText(("");
// borra el nombre de archivo actual y define
// el archivo como limpio:
currFileName = null;
dirty = false;
}
}
En el caso de Archivo->Abrir, realizar el mismo cambio o, sencillamente,
regresar inmediatamente del metodo si okToAbandon() devuelve false.
El metodo modificado debe tener el siguiente aspecto:
u Archivo|Abrir.
return;
}
//Utiliza la versi
on OPEN del cuadro de di
alogo,
// comprueba el valor devuelto de Aceptar/Cancelar
showOpenDialog(this)) {
// Llamar a openFile para intentar cargar el texto
// desde el archivo hasta TextArea
openFile(jFileChooser1.getSelectedFile().getPath());
}
this.repaint();
}
En el caso de Archivo->Salir, escribir una comprobacion de okToAbandon()
antes de la lnea de codigo que sale de la aplicacion. El metodo modificado
debe tener el siguiente aspecto:
//Realizar Archivo | Salir
public void jMenuFileExit_actionPerformed(ActionEvent e) {
r
211

System.exit(0);
}
}
Ahora, estos metodos de tratamiento de los sucesos de men
u realizan su
funcion solo si okToAbandon() devuelve true.
5. Guardar y ejecutar el programa e intentar abrir, editar y guardar varios archivos.
Con estos pasos se tiene un conocimiento basico de como crear un GUI (graphical
user interface) que es nuestro punto basico para construir nuestra aplicacion DICOM.
6.5.
Instalaci
on de JDT
Estas son las libreras de Java utilizadas que implementan funciones del estandar
DICOM. Es necesario hacer una instalacion manual como la realizada con las JDK.
Tambien al realizar el programa se han utilizado las libreras JDT que se distribuyen
de forma gratuita por lo que tienen un perodo de validez, este perodo se acaba el
22 de Abril del 2003, pues bien para poder utilizarlas, lo que hacemos es retrasar el
reloj del ordenador hasta el 22 Abril del 2002 y as tenemos un a
no completo para
poder utilizar las libreras.
Para realizar la instalacion es com
un en todos los sistemas operativos el crear una
carpeta que se llame como se quiera, en nuestro caso se llama classpath. En esta
carpeta hay que guardar los archivos enviados por softlink que son jdt.jar y jdt.key.
La pagina para hacer la peticion de las libreras es www.softlink.be.
En nuestro caso hemos creado una carpeta llamada classpath en el disco D:\, por
lo que hay que copiar los archivos jdt.jar y jdt.key en D:\classpath.
6.5.1.
Instalaci
on en Windows 95/98
Para la instalacion de las libreras JDT en este sistema operativo, hay que abrir el
archivo autoexe.bat que se encuentra en C:\ con un editor de texto (click derecho
sobre el archivo mientras se deja pulsado Shift, y elegimos el Bloc de Notas). En la
variable classpath creada anteriormente cuando instalamos las libreras JDK, hay que
escribir el path o camino para llegar a los archivos de las libreras JDT. En nuestro
caso es:
212
r
DE JDT
6.5. INSTALACION
D:\classpath\jdt.key;D:\classpath\jdt.jar;
Una vez realizado esto, hay que hacer una copia del archivo jdt.key en los
directorios donde haya archivos fuente que utilicen estas libreras. Por ejemplo si
tenemos en la carpeta C:\java un archivo fuente main.java que utilice estas libreras,
hay que poner en la carpeta al archivo jdt.key.
6.5.2.
Instalaci
on en Windows NT/2000/XP
Para la instalacion de JDT, hay que entrar en las variables de entorno. Para llegar
a las variables de entorno ir a Inicio->Configuraci
on->Panel de Control->Sistema>Avanzado->Variables de entorno. . . y en variables del sistema pinchar en la variable
classpath creada anteriormente, ah a
nadir:
D:\classpath\jdt.key;D:\classpath\jdt.jar;
Una vez realizado esto, hay que hacer una copia del archivo jdt.key en los
directorios donde haya archivos fuente que utilicen estas libreras. Por ejemplo si
tenemos en la carpeta C:\java un archivo fuente main.java que utilice estas libreras,
hay que poner en la carpeta al archivo jdt.key.
6.5.3.
Incluir JDT en JBuilder
Una vez instaladas las libreras ahora hay que incluir las libreras en el proyecto
que se este realizando una aplicacion DICOM. Este proceso es el mismo para cualquier
tipo de libreras que se quieran utilizar. Para ello hay que realizar los siguientes pasos:
1. En la barra de herramientas seleccionar Proyecto

2. Propiedades del proyecto. . .
3. Ahora en la esta
na de Vas de acceso y dentro de esta en la pesta
na de Bibliotecas
necesarias, se pulsa A
nadir. . . y seguidamente Nuevo. . . . Mediante el asistente
de bibliotecas se a
naden las de JDT:
Nombre: JDT
Ubicacion: Directorio Inicial
Pulsar A
nadir. . .
Selecionar el camino hasta las libreras JDT que en nuestro caso son:
r
213

Figura 6.17: Bibliotecas

D:\classpath\jdt.jar
D:\classpath\jdt.key
D:\classpath\
Aceptar
4. Asegurarse que las bibliotecas se han a
nadido bien entrando en Herramientas>Configurar bibliotecas. . .
Figura 6.18: Configurar bibliotecas

5. Hecho esto ahora podemos a
nadir las clases de estas bibliotecas a nuestro codigo
fuente sin que de error. Por ejemplo:
import com.archimed.dicom.*;
214
r
DE SERVIDOR DICOM
Fernando Ballesteros Herranz 6.6. IMPLEMENTACION
Con esto podemos declarar nuevos objetos de las clases de JDT, por ejemplo:
DicomObject CT = new DicomObject();
Las libreras instaladas ya son utilizables en el proyecto y se puede trabajar con
ellas.
6.6.
6.6.1.
Implementaci
on de Servidor DICOM
Introducci
on
La aplicacion Servidor DICOM implementa todas las funciones DICOM que puede
realizar un servidor con las libreras JDT. Se ha realizado un programa multiplataforma que estara en ejecucion indefinidamente y que el mismo es capaz de administrarse
sin mantenimiento exterior.
El programa se ha elaborado con Java usando el TextPad como compilador con
el soporte las libreras SDK 1.4.1 y JDT de DICOM.
El servidor realizado da m
ultiples elementos servicio a los clientes como son CSTORE, C-MOVE, C-FIND, C-GET y C-CANCEL. Con estos elementos de servicio
se ha podido implementar las funciones query, guardar, enviar, editar y listar una los
archivos Dicom que se encuentran en el servidor. Todos estos servicios de red estan
codificados mediante algoritmos DES5 de encriptacion.
El servidor DICOM realizado es multiusuario (multihilo), lo que quiere decir que
si hay varios clientes intentando acceder al servidor y haciendo peticiones al este,
el mismo administra las peticiones en diferentes hilos y as puede dar servicios a
diferentes clientes a la vez.
El servidor va dando informes sobre lo que se va desrrollando e informacion acerca
de los servicios que esta realizando y le estan pidiendo los clientes.
Vamos a analizar cada funcion que realiza el servidor. Los pasos previos a todas las
funciones es el que se eralice una asociacion entre cliente y servidor y esten deacuerdo
en la informacion que van a compartir.
5
Digital Encription Standard
r
215

6.6.2.
Listar
EL servidor a peticion del cliente, realiza una lista de los archivos Dicom contenidos
en la base de datos. Esta lista es enviada y codificada por el servidor a los clientes
que la soliciten.
Figura 6.19: Listado en Servidor

El codigo en Java es el siguiente:
String dirname = "/BaseDeDatos";

File f1 = new File(dirname);
if(f1.isDirectory()){
String si[] = f1.list();
int j = si.length;
int i = 0;
String cadena = new Integer(j).toString();
ps.println(j);
Integer numero = new Integer(cadena);
j = numero.intValue();
for(i=0;i<(j);i++){
//Para leer cada archivo de base de datos y
//ver cuantas imagenes tiene
FileInputStream fin = new FileInputStream
("c://BaseDeDatos//"+si[i]);
DicomObject scimage = new DicomObject();
scimage.read(fin,true);
int a = scimage.getI(DDict.dNumberOfFrames);
if(a>30){
a=1;
}
fin.close();
216
r
DE SERVIDOR DICOM
System.out.println(si[i]);
ps.println(si[i]);
ps.println(a);
}
return;
Donde primero se mira cuantos archivos Dicom hay en la base de datos y luego
sabiendo este n
umero se van listando. Tambien es importante saber cuantas imagenes
tiene cada archivo Dicom ya que es una informacion que el cliente debe de conocer.
Toda esta informacion es enviada al cliente cada vez que hace una peticion de la base
de datos.
6.6.3.
Enviar
Esta funcion es muy inportante ya que es la base de la transmision de los objetos

Dicom. El servidor enva al cliente el archivo pedido. Esta funcion suele realizarse
despues de hacer una peticion de lista para ver que archivos hay en la base de datos,
una vez que se ven cuales hay, el cliente pide un archivo y el servidor se lo enva.
Figura 6.20: El servidor enva objeto Dicom

La implementacion es muy extensa pero la base es:
.......
fin.close();
.......
as.send(SOPClass.CTImageStorage,cstorerequest,scimage);
.......
r
217

Donde lo primero que se hace es crear un objeto Dicom DicomObject scimage =

new DicomObject() en el que almacena la informacion del archivo (este proceso se
realiza con las funciones de JDT que tienen en cuenta que lo que se debe almacenar
debe tener la estructura definida por el estandar). Despues la instancia es enviada
mediante el metodo send() de un objeto de la clase Association incluida en el JDT.
6.6.4.
Guardar
Cuando el cliente enva archivos Dicom al servidor, este debe saber administrar
la forma de guardarlo sabiendo que nombre debe dar al archivo recibido y donde se
producira su almacenaje.
Figura 6.21: El servidor recibe objeto Dicom

El codigo fuente es muy extenso pero para entender la forma de realizarse esta
funcion vale con:
.......
DicomObject im = new DicomObject();
.......
//recibe los VRs
im = as.receiveData();
im.write(fin,true);
fin.close();
.......
Para esto se ha tenido que crear un objeto Dicom DicomObject im = new DicomObject() que sera quien reciba los datos que se estan recibiendo del cliente va
network. Estos datos son los data sets con los valores correspondientes del archivo
Dicom. El objeto Dicom recibe los datos mediante el metodo receiveData() de la clase
218
r
DE SERVIDOR DICOM
Association y luego los guarda para no perderlos y as crear un nuevo archivo Dicom
en la base de datos del servidor. Esto se realiza con im.write(fin,true), siendo fin el
objeto tipo archivo donde se guarda el objeto Dicom.
6.6.5.
Query/Retrieve
El servidor da informacion o partes de informacion de los archivos Dicom almacenados en la base de datos. Esta funcion es muy importante y u
til para saber que
archivos queremos ya que nos da la informacion del estudio realizado.
La informacion que da el servidor de nuestra apliacion es:
Fecha del estudio: Da-Mes-A

no
Nombre del paciente
Edad
Sexo
N
umero de celulas y de virus
N
umero de imagenes que tiene cada archivo
Esta informacion es de suma importancia para tener conocimiento del estudio que
queremos analizar, modificar, borrar o eliminar.
La implementacion del codigo:
.......
FileInputStream fin = new FileInputStream("c://BaseDeDatos//"+nombre);
String nombres = scimage.getS(DDict.dPatientName);
ps.println(nombres);
String nombr = scimage.getS(DDict.dPatientAge);
.......
ps.println(nombr);
String nom = scimage.getS(DDict.dPatientSex);
ps.println(nom);
String dia = scimage.getS(DDict.dPlanes);
ps.println(dia);
r
219

String mes = scimage.getS(DDict.dAccessionNumber);

ps.println(mes);
String ano = scimage.getS(DDict.dAcquisitionNumber);
ps.println(ano);
.......
Se abre un FileInputStream para el archivo del que se quiera obtener la informacion

y se crea un objeto Dicom para leer la informacion del archivo que tiene formato Dicom
seg
un el estandar. Una vez leido el archivo Dicom, se leen las partes que nos interesan
del objeto Dicom y son enviadas al cliente.
6.6.6.
Editar
Esta funcion permite modificar los archivos Dicom del servidor sin necesidad el
cliente de tener que traerse todo el archivo Dicom. Es muy u
til para modificar los
estudios de los pacientes o poner notas que los medicos creen convenientes, de una
forma rapida y sencilla.
Los datos que se pueden modificar en nuestra aplicacion son:

no
Nombre del paciente
Edad
Sexo
El codigo es:
.......
String nomb = in.readLine();
String archiv = in.readLine();
String edad = in.readLine();
String sexo = in.readLine();
String dia = in.readLine();
String mes = in.readLine();
String ano = in.readLine();
FileInputStream fin = new FileInputStream
("c://BaseDeDatos//"+archiv);
220
r
DE SERVIDOR DICOM
.......
scimage.set(DDict.dPatientName,nomb);
scimage.set(DDict.dPatientAge,edad);
scimage.set(DDict.dPatientSex,sexo);
scimage.set(DDict.dPlanes,dia);
scimage.set(DDict.dAccessionNumber,mes);
scimage.set(DDict.dAcquisitionNumber,ano);
FileOutputStream salvar = new FileOutputStream
("c://BaseDeDatos//"+archiv);
scimage.write(salvar,true);
.......
De esta forma se reciben los datos que el cliente quiere modificar del archivo que
desee y mediante el metodo set de la clase DicomObject se van modificando los datos.
Una vez hecho esto se deben guardar los cambios realizados en el objeto con el metodo
write().
6.6.7.
Encriptaci
on/Desencriptaci
on
La encriptacion realizada en la aplicacion tanto de servidor como de cliente esta basada en los algoritmos DES.
En la criptografa tradicional, (tambien llamada criptografa de clave secreta)
tanto el emisor como el receptor poseen una misma clave o password. El emisor utiliza
esta clave para cifrar el mensaje obteniendose el mensaje cifrado, que es ilegible.
El receptor utiliza la misma clave utilizada para el cifrado para descifrar el mensaje
y obtener as el mensaje original. Si esta clave es conocida u
nicamente por emisor
y receptor, se asegura que el mensaje recibido es el original y que es enviado por la
u
nica persona (ademas del receptor), que tiene la clave.
La criptografa realizada en esta aplicacion solo se ha realizado en la informacion
o partes de informacion de los objetos Dicom y en los elementos de servicio que se
deseaban realizar. No se ha aplicado en la transmision de archivos Dicom enteros ya
que las libreras JDT no lo soportan.
La implementacion del algoritmo es de caractersticas faciles:
.......
byte caracterEncriptacion=n;
r
221

String cadenaEncriptada="";
int caracterEncriptado=0;
String cadenaDesencriptada="";
String encriptar(String cadenaEncriptar)
{
// Encriptaci
on seg
un los algoritmos DES
// Devuelve la cadena encriptada
for (int x=0;x<cadenaEncriptar.length();x++)
{
caracterEncriptado=cadenaEncriptar.charAt(x)
^ caracterEncriptacion;
cadenaEncriptada+=(char)caracterEncriptado;
}
return(cadenaEncriptada);
}
String desencriptar(String cadenaEncriptada)
{
// Desencriptaci
on seg
un los algoritmos DES
// Devuelve la cadena desencriptada
for (int x=0;x<cadenaEncriptada.length();x++)
{
caracterEncriptado=cadenaEncriptada.charAt(x)
^ caracterEncriptacion;
cadenaDesencriptada+=(char)caracterEncriptado;
}
return(cadenaDesencriptada);
}
.......
6.7.
6.7.1.
Implementaci
on de Cliente DICOM
Introducci
on
Esta aplicacion sigue todos los pasos del estandar DICOM en la implementacion de
las funciones. Se ha querido realizar un programa multiplataforma y que este deacuerdo con las especificaciones requeridas.
Este programa ha sido elaborado en Java en el entorno JBuilder con soporte de
222
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
libreras SDK 1.4.1 y JDT de DICOM.

La aplicacion tiene varias partes. Lo primero, y a traves de los componentes de
javax.swing es construir un marco que concuerde con las expectativas. En nuestro caso
se ha dispuesto varias pesta
nas que albergan paneles mediante las clases JTabbedPane
y JPanel para que quede una estructura de interfaz de cliente DICOM.
De esta forma se puede poner en cada panel lo deseado. En nuestro caso se ha
dispuesto de los paneles que aparecen en la figura: panelCliente-Servidor, panelProcesamiento, panelVisorDicom y panelCrearDicom.
Vamos a ver para que sirven cada uno de estos paneles y una peque
na muestra de
como han sido implementados.
6.7.2.
Panel Cliente-Servidor
Figura 6.22: Panel Ciente-Servidor

Este panel sirve para comunicarse con el Servidor Dicom. Mediante este panel se
puede solicitar al servidor una lista de los archivos que tenga en la base de datos,
r
223

se puede coger cualquier archivo de esa base de datos, se pueden enviar archivos a
la base de datos, se pueden modificar estos archivos desde el cliente y se puede ver
partes de la informacion que contienen estos archivos Dicom que estan en la base de
daros del servidor. Ver figura 6.22
Antes de realizar cualquier accion en este panel, se debe escribir el nombre del
servidor del que queremos tener estos servicios.
Base de Datos
Mediante el boton Base De Datos, se hace una peticion al servidor de los archivos
que contenga. Estos archivos contenidos en la base de datos del servidor, se muestran
en el cliente en un arbol, en el que se ve tambien por cuantas imagenes esta compuesto
el archivo. Ver figura 3.2.
Para que el funcionamiento de este boton sea correcto, hay que poner el nombre
del servidor con el que queremos crear una asociacion en el espacio creado para ello.
Despues de presionar el boton Base De Datos, saldra una orden a su derecha que nos
dira Haz click en Dicom, entonces hay que hacer click en la palabra Dicom que
esta escrita en el arbol.
La implementacion consta basicamente:
jTree1.addMouseListener(ml);
// Al pulsar la tecla, haga la peticion de la lista.
String servidor = textoServidor.getText();
Storagescu BasedeDatos = new Storagescu(servidor,104,
"storecp","storecu");
BasedeDatos.lista();
//creamos arbol y lisening
createNodes(top);
jTree1.setEditable(true);
jTree1.getSelectionModel().setSelectionMode
(TreeSelectionModel.SINGLE_TREE_SELECTION);
jTree1.setShowsRootHandles(true);
jTree1.addTreeSelectionListener(new javax.swing.event.
TreeSelectionListener() {
public void valueChanged(TreeSelectionEvent e) {
jTree1_valueChanged(e);
}
});
224
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
jScrollPane9.setVerticalScrollBarPolicy(JScrollPane.
VERTICAL_SCROLLBAR_ALWAYS);
jScrollPane9.setViewportBorder(BorderFactory.
createEtchedBorder());
jScrollPane9.setBounds(new Rectangle(313, 308, 378, 255));
Al pulsar el boton Base de Datos, creamos un listening para el raton para actuar
con sus eventos, pedimos una lista al servidor sobre su base de datos y creamos un
arbol de los archivos.
Figura 6.23: Boton Base De Datos y Enviar
Enviar
Para enviar estudios o archivos Dicom al servidor para que los almacene en la base
de datos, implementamos este boton, el boton Enviar. Ver figura 6.23.
Para enviar los datos, primero hay que poner el nombre del servidor con el que
queremos conectar en el JTextArea que hemos creado para ello. Este boon cogera con
que servidor queremos conectarnos y nos abrira un browser para buscar el archivo
que queremos enviar.
r
225

El codigo para esto es:

open();
.......
Storagescu enviar = new Storagescu(servidor,104,
"storecp","storecu",openFileName);
.......
int ok=enviar.store();
if(ok==enviar.STORE_OK)
etiquetaEnvio.setText("Enviado con
exito");
else
etiquetaEnvio.setText("Enviado sin
exito");
Donde los parametros del objeto enviar de la clase Storagescu son los datos necesarios para enviar el archivo mas tarde mediante el metodo store() de la clase Storagescu.
Coger
Este boton ha sido implementado para poder hacer peticiones al servidor de que
enve al cliente el archivo marcado en el arbol. El archivo enviado por el servidor se
guardara en el cliente y podra ser visualizado en el panel Visor Dicom. Ver figura
6.24.
Figura 6.24: Boton Coger

La implementacion es muy extensa pero lo basico en el GUI:
String archivo = textoArchivo.getText();
Storagescu Coger = new Storagescu(servidor,104,
"storecp","storecu",archivo);
Coger.coger();
226
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Coge el nombre del servidor al que esta conectado y el nombre del archivo que se
quiere traer, luego se crea un objeto de la clase Storagescu que es la encargada de
establecer la asociacion con el servidor. Este objeto llama a la funcion coger() que
la que hace el elemento de servicio necesario para traer el archivo especificado del
servidor.
Editar
Su funcion es modificar los datos de los archivos que estan en el servidor sin
tener que traernos el objeto entero. Cada vez que se pinche sobre un archivo se trae
la informacion necesaria no todo el archivo. La informacion que se trae y se puede
modificar es:

no
Nombre del paciente
Edad
Sexo
Para modificar estos datos hay que escribir en los espacios JTextField (ver figura
6.25) dispuestos para ver y para escribir en ellos. Para que las modificaciones se
conserven, hay que escribir los datos que se quieran en los campos y darle al boton
Editar, de esta forma se modifican los datos de los arhivos Dicom del Servidor.
El codigo de la GUI es basicamente:
String nombre = TextoNombre.getText();

String archivo = textoArchivo.getText();
String edad = TextoEdad.getText();
String sexo = TextoSexo.getText();
String dia = TextoDia.getText();
String mes = TextoMes.getText();
String ano = TextoAno.getText();
Storagescu Poner = new Storagescu(servidor,104,"storecp",
"storecu",archivo,nombre,edad,sexo,dia,mes,ano);
Poner.poner();
r
227

Figura 6.25: Boton Editar

Donde se cogen mediante el metodo getText() los datos modificados y luego se
crea un objeto de la clase Storagescu con un constructor en el que se le pasan todos
los datos. Finalmente se utiliza el metodo poner() de la clase Storagescu que ha sido
creada por nosotros.
6.7.3.
Panel VisorDicom
Este panel sirve para poder visualizar todo tipo de archivos DICOM: archivos
comprimidos, no comprimidos, en color, en escala de grises y de una o varias imagenes,
tambien es capaz de insertar datos de texto en los campos ya existentes de un archivo
228
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Figura 6.26: Panel Visor DICOM

DICOM y de crear nuevos campos e insertar datos en ellos.
Se ha conseguido a traves de la implementacion de una clase llamada Imagedos
en el proyecto de JBuilder, la cual nos va a permitir en u
ltima instancia ser capaces
de visualizar la imagen de los archivos DICOM. Ver figura 6.26
Visualizar datos
Esta clase tiene un constructor de la forma public Imagedos(DicomObject dcm) al
cual vamos a llamar y a pasarle un objeto de la clase DicomObject.
Este parametro que se pasa es un archivo DICOM sacado de archivos .dcm (formato DICOM).
La forma de pasar de un archivo .dcm a una instancia de la clase DicomImage
(subclase de DicomObject) se consigue mediante este codigo, implementado en nuestra clase principal MarcoCuatro.java en el metodo open():
r
229

.......
if (JFileChooser.APPROVE OPTION == jFileChooser1.
showOpenDialog(this))
openFileName = jFileChooser1.getSelectedFile().
getAbsolutePath();
f = new File(openFileName);
fin = new FileInputStream(f);
bis = new BufferedInputStream(fin);
dcm.read(bis, true);
.......
Donde con la primera lnea de codigo conseguimos que se abra un selector de

archivos, donde elegimos el archivo DICOM deseado. Con la lnea it openFileName
= jFileChooser1.getSelectedFile().getAbsolutePath(); conseguimos guardar el camino
completo del archivo, el cual necesitamos para crear un objeto de la clase File, depues
uno de la clase FileInputStream y finalmente uno de la clase BufferedInputStream para
poder usar el metodo read de la clase DicomObject, el cual lee desde el BufferedInputStream el archivo DICOM.
De esta forma tenemos en dcm (DicomImage dcm = new DicomImage();) nuestro archivo DICOM .dcm.
Para sacar los datos de texto de este archivo DICOM usamos:
ReSystemOut systemArea = new ReSystemOut(areaTextoDatosDicom);

dcm.dumpVRs(systemArea,true);
Donde la clase ReSystemOut es una implementacion realizada para poder mostrar

estos datos en un objeto de la clase JTextArea, que es lo que nos interesa para poder
visualizar estos datos en nuestro GUI (en este caso en la instancia areaTextoDatosDicom de JTextArea).
El paso siguiente es coger los datos reunidos en este objecto. Para ello necesitamos
la clase Imagedos. Llamamos a su constructor public Imagedos(DicomObject dcm) con
lo que tenemos un objeto de esta clase:
imagedcm = new Imagedos(dcm);
Mediante el metodo getBufferedImage(int numeroDeImagen) podemos sacar las

imagenes y poderlas visualizar de esta forma:
230
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
imagen = imagedcm.getBufferedImage(numeroImagen);
etiquetaMostrarImagen.setIcon(new ImageIcon(imagen));
Donde etiquetaMostrarImagen es un objeto de la clase JLabel la cual mediante el

metodo setIcon(ImageIcon a) puede mostrar nuestras imagenes. La instancia de la
clase ImageIcon se crea como se ve arriba mediante su constructor.
Hacer zoom in o zoom out

Una vez visualizada la imagen, se ha dotado de la posibilidad de hacer zoom de
dos formas diferentes:
1. Botones Zoom In y Zoom Out. Ver figura 6.27
Figura 6.27: Zoom In y Zoom Out

La implementacion basica es (para el caso de Zoom In):
int altura = zoomImagen.getHeight(null);
int anchura = zoomImagen.getWidth(null);
zoomImagen = imagen.getScaledInstance(anchura*2,altura*2,
imagen.SCALE DEFAULT);
etiquetaMostrarImagen.setIcon(new ImageIcon(zoomImagen));
Donde con getHeight y getWidth (metodos de la clase Image) sacamos la altura
y anchura de la imagen zoomImagen. Y mediante el metodo getScaledInstance
hacemos una imagen a escala de la anterior, para lo que necesitamos nuevos
datos de alto/ancho, que despues con el metodo antes visto setIcon podemos
visualizamos en el mismo objeto JLabel, etiquetaMostrarImagen.
2. Mediante eventos de raton:
En este caso se ha conseguido que mediante dos cliqueos con el raton sobre
la imagen se haga zoom in de la zona selecionada. Se hace, creando para la
r
231

Figura 6.28: Zoom con eventos

JLabel deseada (etiquetaMostrarImagen), un codigo que sea capaz de recoger
un evento, en este caso el chasquido del raton. La implementacion es:
etiquetaMostrarImagen.addMouseListener(new MouseAdapter()
{
public void mousePressed(MouseEvent e)
{
try
if(x1==-1&y1==-1)
{
x1 = e.getX();
y1 = e.getY();
}else if(x2==-1&y2==-1)
{
x2 = e.getX();
int ancho = Math.abs(x2) - Math.abs(x1);
int alto = y2 - y1;
ancho = Math.abs(ancho);
alto = Math.abs(alto);
zoomBufferedImagen = ImageToBufferedImage.
toBufferedImage(zoomImagen);
232
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
if((x1>x2)&(y1>y2))
{
zonaBImagen= zoomBufferedImagen.getSubimage
(x2,y2,ancho,alto);
}if((x1<x2)&(y1>y2))
{
(x1,y2,ancho,alto);
}if((x1<x2)&(y1>y2))
{
(x1,y1,ancho,alto);
}if((x1>x2)&(y1<y2))
{
(x2,y1,ancho,alto);
}
Image zonaZoomImage = zonaBImagen.
getScaledInstance(4*ancho,4*alto,Image.SCALE DEFAULT);
Marco PantallaCompleta marcoZonaZoom = new Marco
PantallaCompleta(zonaZoomImage);
Dimension dlgSize = marcoZonaZoom.getPreferredSize();
Dimension frmSize = getSize();
Point loc = getLocation();
marcoZonaZoom.setLocation((frmSize.width - dlgSize.
width) / 2 + loc.x, (frmSize.height - dlgSize.height)
/ 2 + loc.y);
marcoZonaZoom.setModal(true);
marcoZonaZoom.pack();
}
}
});
Donde se crea un listener de evento MouseEvent el cual nos permite saber la

posicion del raton en el momento que este es pulsado, por lo que podemos sacar
la zona de interes (mediante los metodos getX() y getY() ) y donde Marco
PantallaCompleta es una clase que permite visualizar imagenes en un panel
aparte.
Tambien, si se quisiese detectar, por ejemplo el movimiento del raton sobre un
componente o el rotar de la rueda central del raton se pueden usar clases del
mismo paquete MouseAdapter, MouseEvent, MouseMotionAdapter o/y MouseWheelEvent para tener efectos homologos a lo anteriormente visto.
r
233

Visualizar todas las im

agenes
Ya se ha comentado la forma de conseguir visualizar los datos de la imagen de los
archivos DICOM, pero tambien sabemos que un archivo DICOM puede contener mas
de una imagen, por lo que debemos ser capaces de visualizarlas todas y cada una de
ellas.
Figura 6.29: Botones Siguiente y Anterior

Al abrir un archivo DICOM se muestra en pantalla (en una instancia de la clase
JLabel) la primera imagen y en el caso de que haya mas de una imagen en dicho
archivo, los botones Siguiente, Anterior y Seguidas realizaran las funciones siguientes.
1. Botones Siguiente y Anterior:

Estos dos botones permiten ver, si existe, la imagen siguiente o la anterior
como indica su nombre. La implementacion es muy sencilla. Primero, se ve
si hay mas de una imagen mediante la captura del dato del objeto DICOM
dcm.getI(DDict.dNumberOfFrames) y si existe, se muestra en pantalla. Ver figura 6.29.
La parte importante de esta implementacion es:
void botonImagenSiguiente actionPerformed(ActionEvent e)
{
.....
.....
numeroImagen++;
imagen=imagedcm.getBufferedImage(numeroImagen);
etiquetaMostrarImagen.setIcon(new ImageIcon(imagen));
.....
.....
}
Donde imagedcm es un objeto de la clase Imagedos que puede coger la imagen
de n
umero seleccionada mediante el int numeroImagen.
234
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Figura 6.30: Boton Seguidas

2. Boton Seguidas:
Se basa en lo anterior, pero se consigue que las imagenes pasen una detras de
otra (formando una pelcula). La pelcula se para si se pulsa con el raton sobre
el panel donde aparece esta secuencia. Ver figura 6.30
Se va a ver una parte importante de la implementacion:
void botonImagenesSeguidas actionPerformed(ActionEvent e)

{
.....
.....
Image [] secuencia = new Image[dcm.getI(DDict.
dNumberOfFrames)];
for(int n=0;n<dcm.getI(DDict.dNumberOfFrames);n++)
{);
secuencia[n]=imagedcm.getBufferedImage(n);
System.out.println(n);
}cargado = true;
ImageSequenceTimer controller = new ImageSequenceTimer();
controller.secuencia(secuencia,dcm.getI(DDict.
dNumberOfFrames));
.....
.....
}
Donde, como se puede ver, se cargan todas las imagenes en un array de Images
y mas tarde se crea una instancia de la clase ImageSequenceTimer con la cual
se crea el panel donde se va a visualizar la secuencia.
r
235

Figura 6.31: Boton Guardar JPEG

Guardar im
agenes como JPEG
Se puede guardar la imagen visualizada en formato JPG mediante las posibilidades
de JDK 1.4.1. Esta funcion solo se encuentra en esta version del API JAVA, por lo
que aqu vemos el porque del uso de esta version.
Para implementar esto necesitamos importar el paquete:
import javax.imageio.*;
Debido a que en este se encuentra lo buscado, que es el metodo de la clase
javax.imageio.ImageIO que nos permite guardar los datos de una instancia de la
clase Image en un archivo de formato JPEG. La implementacion esencial es:
void botonGuardarIamgenComoJpg actionPerformed(
ActionEvent e){
.....
.....
showSaveDialog(this))
{
String salvarJPG = jFileChooser1.getSelectedFile().
getAbsolutePath();
FileOutputStream salvar = new FileOutputStream
(salvarJPG);
File save = new File(salvarJPG);
BufferedOutputStream salida = new BufferedOutputStream
(salvar);
javax.imageio.ImageIO.write(imagen,"JPEG",save);
}
.....
.....
}
236
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Donde la lnea de codigo mas importante es javax.imageio.ImageIO.write(imagen,

JPEG,save); que realiza la funcion deseada.
Meter y modificar datos de texto en el archivo DICOM

En un archivo DICOM, como sabemos tenemos datos de imagen y tambien de
texto, es decir el nombre del paciente, que aparato ha realizado la captura de la imagen. . . . La funcion, que se ha hecho para esta GUI y para este panel, es la capacidad
de poder a
nadir datos de texto al archivo visualizado.
Esto se puede hacer de dos formas diferentes. Se puede insertar datos en campos
ya existentes, como el nombre del paciente, o se puede crear nuestro propio campo
como por ejemplo n
umero de moleculas infectadas.
Del primer tipo se han dispuesto una serie de campos, los cuales pueden ser validos
o no. En este aspecto deben ser los profesionales de la medicina los que deben suministar informacion para saber los datos que quieren insertar para poder adaptarnos
a ellos.
Ya se vio de que manera se puede visualizar todos los datos del archivo DICOM.
Aqu vamos a cambiar o meter nuevos datos en determinados campos y podremos
visualizar si estas modificaciones se llegan a producir.
Para esto se han dispuesto dos instancias de la clases JComboBox, dos botones
de la clase JButton para insertar y para ver lo insertado y de dos objetos JTextArea
siendo estas las zonas de visualizacion. Todo esto se puede ver en la figura 6.32
Figura 6.32: Insertar y ver datos

La forma de implementar esto es creando dos instancias de la clase JComboBox
con los campos adecuados:
private JComboBox jComboBox1
r
237

= new JComboBox(opcionesCombobox);
Siendo en este caso opcionesCombobox:
String[] opcionesCombobox = {"dAdditionalPatientHistory"

,"dBeamName","dBitsAllocated","dBodyPartExamined"
,"dContrastAllergies","dHistogramData","dImageComments",
"dInterventionDrugName","dModality","dPatientName","dPixelData"
,"dROIArea","dSeriesNumber","dSmokingStatus","dNumberOfFrames"};
Por lo que al pinchar sobre la flecha del combobox, aparecen todos estos campos. Ahora hay que interconectarlos para que al seleccionar uno y escribir sobre las
JTextArea se inserte y visualicen los datos.
Para insertar:
void botonInsertarDato actionPerformed(ActionEvent e)
{
try
{
String opcion = (String)jComboBox1.getSelectedItem();
String dato = areaTextoInsertarDato.getText();
if(opcion=="dPatientName")
dcm.set(DDict.dPatientName, new Person(dato));
.....
Donde new Person(dato) es el dato del nombre del paciente que se inserta en el
campo del archivo DICOM DDict.dPatientName.
Hecho esto, el dato estara en el objeto DicomImage pero no todava en el
archivo .dcm, para lo que se implementa estas otras lneas de codigo:
FileOutputStream save = new FileOutputStream(openFileName);
dcm.write(save,true);
Siendo write un metodo de la clase DicomObject que lo que hace es escribir a
traves de un FileOutputStream todos los datos de la instancia DicomImage en
un archivo .dcm que, si no existe, crea uno.
Para ver lo insertado:
238
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
void botonVerDato actionPerformed(ActionEvent e)

{
String opcion2 = (String)jComboBox2.getSelectedItem();
if(opcion2=="dPatientName")
{
String cadena = dcm.getS(DDict.dPatientName);
areaTextoVerDato.setText(dcm.getS(DDict.dPatientName));
.....
Para ver que el funcionamiento de lo anterior es correcto se puede volver a abrir
el archivo DICOM y se podra observar que el nombre del paciente ha cambiado
o aparece cosa que antes no hara. La figura ?? siguiente pretende ser un ejemplo
de lo descrito.
C
omo a
nadir campos nuevos al archivo DICOM
Existe la posibilidad de crear nosotrosmismos nuestros propios campos, para utilizar seg
un convenga.
Se ha visto como insertar datos en los campos del archivo DICOM existentes ya,
como el sexo del paciente, nombre del fabricante, ID del paciente, etc, pero es muy
importante ser capaces de crear nuestros propios campos, como por ejemplo el n
umero
de virus, diagnostico del medico, y en definitiva, los que se crean convenientes.
Para ello se han dispuesto en la GUI ciertos botones (figura 6.33) que son capaces
hacer este servicio.
Figura 6.33: Crear campos nuevos
r
239

Se tiene la posibilidad de crear campos donde se albergan datos de tipo Integer o

datos de tipo String, es decir, campos para datos numericos y campos para datos de
texto.
El codigo crear campo numerico basicamente es:
void jButton6 actionPerformed(ActionEvent e)

{
.......
DDictEntry entrarDDict1 = new DDictEntry(new Integer(
campoGrupoNumero.getText()) .intValue(), new Integer
(campoElementoNumero.getText()).intValue(), DDict.tUS,
campoNuevoNumero.getText(),"1");
diccionario.addEntry(entrarDDict1);
dcm.set ge(new Integer(campoGrupoNumero.getText()).
intValue(),new Integer(campoElementoNumero.getText()).
intValue(),new Integer(numero.getText()));
.......
}
Este es el codigo que se ejecuta en el momento en que el boton es pulsado.

Lo primero que se hace es crear una instancia de la clase DDictEntry. Al pasar
los parametros fijamos el n
umero de grupo, el n
umero de elemento, la descripcion del
campo y el tipo de dato DICOM que se puede meter en este campo.
Una vez hecho esto, creamos un objeto de la clase DDict, en la cual vamos a
insertar nuestro nuevo campo por medio del metodo addEntry(DDictEntry a).
En este momento tenemos la posibilidad de poder meter en el objeto de la clase
DicomObject (dcm) el nuevo dato mediante el metodo it set_ge(grupo,elemento,dato),
que en este caso debe ser un Integer ya que el tipo US DICOM es tipo Integer en
Java. Ver tablas de conversion 5.1 y 5.2.
Para el caso de insertar un campo que alberge un dato de tipo String se ha
procedido de la misma forma:
void jButton5 actionPerformed(ActionEvent e)

{
.......
DDictEntry entrarDDict2 = new DDictEntry(new Integer(
campoGrupoTexto.getText()) .intValue(), new Integer (
240
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Figura 6.34: Nuevo campo insertado

campoElementoTexto.getText()).intValue(), DDict.tST,
campoNuevoTexto.getText(),"1");
diccionario.addEntry(entrarDDict2);
dcm.set ge(new Integer(campoGrupoTexto.getText()).intValue(),
new Integer(campoElementoTexto.getText()).intValue(),
new Integer(numero.getText()));
.......
}
Donde lo u
nico que cambia es el tipo de dato que vamos a insertar, por lo que el
tercer parametro que se pasa al constructor de la clase DDictEntry es DDict.tST.
6.7.4.
Panel Procesamiento
Este panel sirve para poder procesar una imagen mediante un algoritmo desarrollado por el GVA. Este panel visualiza la imagen de origen a procesar y ejecuta el
r
241

algoritmo de procesamiento y cuando acaba este se visualiza en el panel de imagen

procesada (a la derecha).
Figura 6.35: Panel Procesamiento

Esta panel funciona si esta instalado previamente el MATLAB, el programa utilizado para el tratamiento de las imagenes.
Introducci
on del algoritmo en la aplicaci
on
Pasos a seguir:
1. Lo primero que se debe hacer es poner en las variables de entorno los caminos
para encontrar las libreras necesarias:
C:/AWouter/bin/win32; C:/AWouter; C:/matlab6p5/bin/win32;
Esto significa que antes se ha debido copiar en estas carpetas los archivos solicitados.
En la carpeta C:/AWouter se deben copiar los archivos applylut.dll y dataread.dll.
242
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
2. Despues se debe ejecutar el setup mglinstaller.exe que instala las libreras necesarias de Matlab.
3. Se debe copiar el ejecutable en la carpeta C:/AWouter.
4. Copiar los archivos
5. Despues se tiene que crear una carpeta donde se ponen las libreras para solo
este algoritmo:
C:/matlab6p5/toolbox/images/images/private y se incluyen en esta bwlabel1.dll
y bwlabel2.dll.
Si hubiera alg
un error con los ficheros MSVCRTD.DLL y MSVCIRTD.DLL,
copiarlos en las carpetas C:\WINNT\system32, en C:\AWouter y en C:\Matlab6p5\win32.
Esto es a nivel de sistema. Una vez hecho esto se debe realizar una implementacion
para que este algoritmo se pueda ejecutar desde nuestro GUI (graphical user interface). Para hacer esto se dan estos pasos:
En el panel de procesamiento se han creado dos JLabel donde poner las imagenes
de origen y la de salida o procesada. Se ha incluido ademas un JTextArea para decir el
camino y el nombre de la imagen procesada y dos botones, uno para abrir la imagen
a procesar y otro para empezar el procesamiento. Figura 6.35.
Pasos en JBuider7.0:
1. Incluir en el proyecto los archivos CntVirRel.exe y files.txt mediante el boton

que se muestra en la figura 6.36.
2. Se ha implementado de la siguiente forma:
Boton Imagen a tratar. Figura 6.37
void botonSeleccionImagen actionPerformed(ActionEvent e)
{
.....
fotoEntradaCamino = jFileChooser1.getSelectedFile().
getAbsolutePath();
ImageIcon iconoEntrada = new ImageIcon(fotoEntradaCamino);
imagenEntrada = iconoEntrada.getImage();
etiquetaImagenEntrada.setIcon(iconoEntrada);
String caminoFicheroTxt = "files.txt";
File filesTxt= new File(caminoFicheroTxt);
FileOutputStream chorro = new FileOutputStream(filesTxt);
PrintStream escribirEnArchivo = new PrintStream(chorro);
r
243

Figura 6.36: Boton para a

nadir archivos al proyecto
escribirEnArchivo.println(fotoEntradaCamino);
imagenProcesada = textoImagenSalida.getText();
escribirEnArchivo.println(imagenProcesada);
etiquetaSeleccionImagen.setText(fotoEntradaCamino);
......
Donde se muestra la imagen de entrada (setIcon) y se escribe el camino
de entrada y de salida en el fichero files.txt de donde despues con el boton
que se ve a continuacion se saca esta informacion.
Figura 6.37: Boton para abrir imagen a procesar

En el boton Procesar imagen. Figura 6.38.
void botonProcesamiento actionPerformed(ActionEvent e)
{
Process p = Runtime.getRuntime().exec
("c:/AWouter/CntVirRel.exe");
int valorRetorno = p.waitFor();
ImageIcon iconoSalida = new ImageIcon
(textoImagenSalida.getText());
etiquetaImagenSalida.setIcon(iconoSalida);
.....
244
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Donde las clases importantes son Process con su metodo getRuntime().exec()

para ejecutar en este caso un archivo .exe y tambien el metodo waitFor()
que hace que la ejecucion del codigo se pare hasta que el proceso no finalize.
Figura 6.38: Boton para procesar imagen
6.7.5.
Panel Crear DICOM
La funcion de este panel es la de poder crear un archivo DICOM a partir de

imagenes de formato jpeg y datos de texto.
Los datos de texto como el nombre del paciente, el aparato que hace la imagen,
la parte del cuerpo examinada, etc, se insertan de la forma vista en el Panel Visor
Dicom.
La parte nueva con respecto al panel de visualizacion de archivos DICOM es la
zona de meter los datos de imagenes nuestras en formato jpeg dentro del nuevo archivo
DICOM.
Estructura del Panel Crear DICOM

Este panel consta de varias partes:
1. Zona de visualizacion de imagenes a insertar. Figura 6.40
2. Zona de insercion de datos de texto. Figura 6.41
Inserci
on de una sola imagen
En esta parte vamos a ver la forma de como insertar los datos de una sola imagen.
r
245

Figura 6.39: Panel Crear DICOM

Lo primero que se hace es visualizar la imagen a insertar en el area destinada
mediante el boton Abrir imagen y despues mediante los botones Monochrome o RGB
metemos la imagen seg
un sea en escala de grises o en color respectivamente.
Al abrir la imagen se graba en una instancia de la clase Image (Image imagenJPG;)
con la que se trabaja de esta manera:
1. Boton Monochrome:
La implementacion de la funcion de este boton es de la forma:
void botonCrearDicomGris actionPerformed(ActionEvent e)
{
.......
String rutaArchivoDicomGuardar = jFileChooser1.
getSelectedFile().getAbsolutePath();
int[] pix = image2IntArray(imagenJPG);
dcmNueva.set(DDict.dSOPClassUID,"1.2.840.10008.5.1.4.1.1.7");
dcmNueva.set(DDict.dSOPInstanceUID,"1.2.840.10008.5.1.4.1.1.7");
246
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Figura 6.40: Imagen para crear un archivo Dicom

dcmNueva.imagePixelData(imagenJPG.getHeight(null),imagenJPG.
getWidth(null),8,8,7,pix);
dcmNueva.write(salvar,true);
.......
}
Donde image2IntArray es un metodo que mediante la clase PixelGrabber es
capaz de coger los datos de la imagen pixel a pixel, por lo que el resultado es
un array de int donde se encuentran estos datos.
Las dos lneas siguientes se colocan debido a que son datos que se deben encontrar obligatoriamente en un archivo DICOM, ya que sin ellos no es posible
crear el archivo.
Mas tarde, en nuestra instancia de la clase DicomImage (DicomImage dcmNueva = new DicomImage();) se insertan estos datos de imagen mediante el
metodo de esta clase imagePixelData(int filas, int columnas, int planarConf,
int[] pixelData).
Una vez hecho esto se puede comprobar que los resultados son satisfactorios al
ir al panel VisorDicom y tratar de abrir el archivo creado, donde s3e pueden
ver los resultados. Figura 6.42
r
247

Figura 6.41: Datos de texto a insertar

2. Boton RGB:
Para el caso de la imagen en color se realiza de la misma forma. La diferencia
es que se usa otra implemtentacion del metodo imagePixelData ya que es un
metodo sobrecargado y se utiliza debido al cambio de parametros que se pasan
a este:
imagePixelData(int rows, int cols, int planarConf,
int[] pixelData);
Por lo que queda de la siguiente manera:
dcmNueva.imagePixelData(imagenJPG.getHeight(null),
imagenJPG.getWidth(null),0,pix);
Los resultados se pueden comprobar igualmente visualizando el archivo creado.
Figura 6.43.
Compresi
on de archivos Dicom Monochrome
Se ha visto como crear un archivo DICOM de escala de grises, pero al hacer esto
se tiene un problema: el tama
no de los archivos es muy grande debido a que no se ha
248
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Figura 6.42: Comprobacion de la creacion de archivo Dicom en escala de grises

realizado ning
un tipo de compresion a los datos de pxel, por lo que el espacio que
ocupan es bastante grande.
Para ello se ha recurrido a la clase de la API de JDT llamada Compression, la
cual proporcina metodos para realizar compresiones de estos datos.
Para realizar la compresion se act
ua de la siguiente forma:
void botonComprir actionPerformed(ActionEvent e)

{
.......
Compression c = new Compression(dcmNueva);
c.compress(TransferSyntax.JPEGLossless);
.......
}
Se crea una instancia de la clase Compression (c) que despues usa su metodo
compress, el cual necesita saber el tipo de compresion a usar. En este momento se
r
249

Figura 6.43: Comprobacion de la creacion de archivo Dicom en RGB

tiene que decir que el u
nico tipo de compresion que realiza este servicio es el se
nalado
arriba, TransferSyntax.JPEGLossless, mientras que con los otros tipos no se consigue
lo buscado con la limitacion de que funciona solo con imagenes monochrome.
La diferencia de tama
no de un archivo comprimido a uno sin comprimir es:
No comprimido: tama
no = X
Comprimido: tama
no = X / 2
Inserci
on de varias im
agenes
Para este caso se ha introducido en un array de Image todas las imagenes que se
quieren insertar en el archivo DICOM.
Una vez insertadas, se procede a sacar los datos de pxel de estas instancias Image.
En este caso se van a guardar estos datos en una matriz de bytes en vez de array int.
250
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Teniendo la matriz de bytes (byte[][]), se contin

ua uniendo todos estos bytes en
un solo array de bytes (byte[]) donde van uno detras de otro.
Una vez hecho esto se procede a insertar estos datos en el archivo DICOM a crear.
Para todo esto se usan diferentes botones que realizan las diferentes funciones
vistas antes:
1. Boton No de imagenes: donde se se

nala el n
umero de imagenes que vamos a
insertar. En el codigo se da valor a una variable que es utilizada para saber el
n
umero de instancias Image que se deben guardar en el array Image[].
La implementacion es:
void iniciarArrayImages actionPerformed(ActionEvent e)
{
imagenSecuencia = new Image [new Integer(
datoPantalla.getText()).intValue()];
}
2. Boton Abrir imagenes a insertar: mediante este boton se van almacenando en
el array las imagenes, hasta que se almacena la u
ltima, y es en este momento
cuando aparece un nuevo cuadro que te pregunta por el lugar y el nombre donde
insertar este arhivo DICOM. La implementacion basica es:
void botonAbrirImagen actionPerformed(ActionEvent e)
{
........
imagenSecuencia[numeroDeImagen] = imagenJPG;
numeroDeImagen++;
int imagenesTotales = new Integer(datoPantalla.
getText()).intValue();
if(numeroDeImagen == imagenesTotales)
{
byte[][] secuenciaBytes = new byte
[imagenesTotales][];
int n,nBytes=0;
for(n=0;n<imagenesTotales;n++)
{
byte[] ver = image2ByteArray(imagenSecuencia[n]);
secuenciaBytes[n]=image2ByteArray
(imagenSecuencia[n]);
}
arrayDeArrayDeBytes=secuenciaBytes;
byte[] todoJunto = unirBytesArray(secuenciaBytes,
r
251

imagenesTotales);
todosBytesJuntos = todoJunto;
showSaveDialog(this))
{
try
{
String rutaArchivoDicomGuardar = jFileChooser1.
getSelectedFile().getAbsolutePath();
........
dcmNueva.imagePixelData(imagenJPG.getHeight(null),
imagenJPG.getWidth(null),8,8,7,todosBytesJuntos);
........
dcmNueva.write(salvar,true);
........
}
}
}
Como se ve en este codigo, una vez recogidas todas las instancias Image en el
array, se pasa a sacar de cada objeto Image sus datos de pxel y se reunen en
una matriz de bytes llamada arrayDeArrayDeBytes.
Una vez hecho esto, se unen esos array de bytes en uno solo mediante el metodo
unirBytesArray(byte[][] secuencia, int numeroDeImagenes), el cual es el dato a
insertar en nuestro archivo DICOM, donde se recogen todas nuestras imagenes.
Comprimir archivo DICOM de varias im

agenes monochrome
Este archivo esta sin compresion. Se puede realizar una compresion como la indicada antes y la reduccion de tama
no es de la relacion 2 a 1 aproximadamente, es decir
el tama
no del archivo comprimido es la segunda parte del archivo sin comprimir.
El u
nico sistema de compresion soportado sigue siendo JPEGLossless de estas
libreras y mas particularmente de la clase Compression.
252
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Figura 6.44: Generacion de ejecutables
6.7.6.
Distribuci
on e instalaci
on de la aplicaci
on
Generaci
on de ejecutables
Una vez creada la version Beta de nuestra aplicacion Cliente DICOM es importante
poder distribuirla para que sea ejecutada sobre cualquier sistema operativo, siendo
de esta manera una aplicacion multiplataforma.
Figura 6.45: Creador de ejecutables

Para la generacion de los ejecutables, JBuilder cuenta con un asistente el Creador
de ejecutables nativos. Ver figura 6.44.
r
253

Pasos a seguir:
1. Seleccionar Asistentes->Creador de ejecutables nativos. . .
2. Escribir el nombre del ejecutable. En nuestro caso DICOM.
3. Seleccionar: incluir siempre todas las clases y recursos.
4. Seleccionar: JDT e incluir siempre todas las clases y recursos.
5. Pulsar Siguiente en los pasos 4 y 5, con las opciones marcadas por defecto.
6. Marcar en el paso 6 los ejecutables que queramos crear dependiendo del sistema
operativo en el que se vaya a utilizar.
7. Pulsar Finalizar
8. Una vez realizado esto, se generara en el panel de proyectos un archivo que
se llama igual a como habamos llamado al ejecutable que queremos generar.
Entonces lo marcamos y pulsamos en Proyecto->Generar Make del proyecto,
de esta forma se generaran los ejecutables que pueden ser para Windows, para
Linux, para Solaris, para Mac/OS y multiplataforma como el .jar.
Figura 6.46: Marcas de la creacion de ejecutables

De esta forma conseguimos que el programa este en un solo ejecutable.
Para el caso del servidor se puede o bien crear el recopilatorio .jar o bien ejecutar
cuando se quiera poner el funcionamiento el .class, ya que el servidor se debe poner
solo una vez en funcionamiento y no hace falta ning
un tipo de administracion.
Para crear el .jar de una aplicion no basada en GUI se hace de la forma descrita
en el apartado de Utilidades de SDK, utilizando la utilidad jar.
254
r
DE CLIENTE DICOM
6.7. IMPLEMENTACION
Instalaci
on
Para la instalacion de la aplicacion cliente hay que seguir los siguientes pasos:
1. Instalacion de la Maquina Virtual de Java.

2. Creacion de carpeta que se llame BaseDeDatos en la raz, es decir, para
sistema Windows es C:\. En esta carpeta es donde llegaran los estudios DICOM
que queramos coger del servidor.
3. Poner el programa DICOM en un lugar de facil ejecucion.
4. Instalacion del Panel Procesamiento.
5. Retrasar el reloj del ordenador al a
no 2002, si se utiliza la version de prueba
Beta.
Para poner el programa, tan solo hay que ejecutar el programa cliente, en nuestro
caso CuatroW.exe
Para la instalacion del servidor DICOM:
1. Instalacion del SDK entero.

2. Instalacion de libreras JDT.
3. Creacion de carpeta que se llame BaseDeDatos en la raz, es decir, para
sistema Windows es C:\. Esta carpeta es donde se deben encontrar los estudios
de la base de datos del servidor.
4. Retrasar el reloj del ordenador al a
no 2002, si se utiliza la version de prueba
Beta.
5. Poner los .class que en este caso son Storagescp.class, Storagescu.class, Connection.class y Encri.class en la raz que en Windows es C:\.
Para poner el servidor en funcionamiento, abrir un Shell de comandos, y ejecutar

en C:\:
java Storagescp
De esta forma saldra un mensaje que pone Puerto 104 a la escucha.
r
255

6.8.
Conclusiones
El programa realizado es una muestra clara de que el estandar DICOM es operativo

y muy u
til a la hora de la administracion de estudios medicos desde diferentes puntos
a grandes distancias.
Esta aplicacion es una version beta de un posible programa mucho mas avanzado
que de soporte a mas funciones del estandar DICOM. Ha sido desarrollado en Java
por lo cual hace que sea un sistema multiplataforma y mas eficiente.
Cierto es que utilizando las libreras JDT se han detectado limitaciones no respecto
a lo establecido en el estandar sino con la encriptacion de los datos de los pacientes
por la red.
A pesar de ello, se trata de una tecnologa que esta madurando con mucha rapidez,
estabilidad y fiabilidad. Cabe esperar que en los proximos a
nos DICOM vaya a ser
cada vez mas utlilizado en el ambito de la medicina y la investigacion.
El u
nico inconveniente de esta aplicacion es que es una version beta, y por ella sola
no funciona, debe ser retrasado el reloj de la maquina sobre la que estemos trabajando
al a
no 2002, para as tener un a
no de utilidad este programa. Si se quieren mas a
nos
tan solo habra que retrasar el reloj mas tiempo atras.
256
r
Ap
endice A
Administraci
on de sistemas
[GUNT] [LEBLA] [RUSSE97] [STIN]
En este apendice se recopilan los aspectos mas importantes en el amplio mundo
de Windows NT 4.0 y Windows 2000 para que cualquier persona con un mnimo de
conocimientos en informatica sea capaz de manejar esta plataforma.
A.1.
Introducci
on a Windows NT y 2000
A.1.1.
Presentaci
on del sistema operativo NT
Tanto el sistema operativo Windows NT 4.0 como el sistema operativo Windows

2000, tienen semejanza en su forma interna, ya que el Kernel es muy semejante. Cada
vez que se refiera a sistemas operativos NT, se incluyen Windows NT 4.0 y Windows
2000.
El sistema operativo NT fue desarrollado por Microsoft para superar los obstaculos
impuestos por la vieja arquitectura de sus sistemas operativos MSDOS y Windows.
NT es un sistema operativo completo, que puede ser instalado sobre un equipo nuevo
sin necesidad de software adicional, como le ocurre a Windows 3.x, y que ofrece nuevas
tecnologas para el desarrollo y ejecucion de todo tipo de aplicaciones.
Algunas de sus caractersticas mas importantes son:
Robustez. NT es un sistema operativo estable y robusto, que impide a las
aplicaciones mal escritas estropear al resto del sistema.
257

DE SISTEMAS Fernando Ballesteros Herranz
APENDICE
A. ADMINISTRACION
Seguridad. NT ha sido escrito para satisfacer criterios de seguridad tpicos
de organismos oficiales y empresas cuyos datos y aplicaciones deben quedar a
salvo de accesos no autorizados. Practicamente cada objeto del sistema posee
un esquema de seguridad asociado que indica que usuarios pueden acceder al
objeto y con que privilegios pueden acceder.
Portabilidad. El dise
no de NT permite que se pueda adaptar facilmente a otras
arquitecturas para las que no fue originalmente desarrollado. Actualmente soporta las arquitecturas de Intel X86, MIPS, Alpha y PowerPC. Su dise
no modular y el estar escrito en lenguaje facilmente portable, como es el C, permite
esta rapida migracion.
Compatibilidad con las aplicaciones Windows. La capacidad de NT para ejecutar aplicaciones MSDOS y Windows permite disponer de gran cantidad de
software escrito que permite sacar rendimienteo al sistema sin tener que migrar las aplicaciones. Incluso las nuevas aplicaciones Win32 corren en modo
nativo en las diferentes plataformas de NT, simplemente recompilandolas para
cada plataforma, o incluso a traves de los emuladores-compiladores JIT (Just
In Time) como son el X86, distribuido gratuitamente para las plataformas no
Intel soportadas.
Velocidad. NT esta desarrollado para hacer frente a las aplicaciones que necesitan gran cantidad de recursos y altas velocidades de ejecucion, tpicas de entornos cliente/servidor y de ingeniera, como pueden ser servidores de recursos
de red, de bases de datos y programas de calculo cientfico y dise
no grafico.
A.1.2.
Sistemas de archivos
Hay varios tipos de gestores de archivos para los equipos, estos son utilizados
dependiendo del sistema operativo y la gestion realizada por el administrador de la
red:
FAT: 16 bits, es compatible con Windows 95/98/NT/2000/XP y MS-DOS. Es
el mas utilizado en la gestion de los archivos en los disquetes. Los cl
uster son
de 32 KB, esto quiere decir que los datos se guardan en paquetes de 32 KB. Un
fichero que ocupe 33KB, ocupara 2 cl
uster, por lo que se desperdician 31 KB
del 2o cl
uster.
FAT 32: 32 bits, compatible con Windows 95/98/2000/XP. Mas eficiente que
las particiones FAT.
NTFS: Utilizado por los sistemas basados en Red, Windows NT/2000/XP. Los
cl
uster son de menor tama
no, son de 4 KB, de esta forma se aprovecha mejor
el espacio en el disco.
258
r
A WINDOWS NT Y 2000
A.1. INTRODUCCION
Ext 32: sistema de gestion de archivos utilizado por equipos Unix y sistema
operativo Linux.
Hay mas tipos de gestores de archivos, solo se han se

nalado los que pueden ser
interesantes en una administracion de equipos de una Red basada en Windows y a lo
sumo la utilizacion de Samba para la compatibilidad con equipos con Linux.
A.1.3.
El interfaz de usuario de NT
NT hereda los interfases de usuario desarrollados para la familia Windows. Por

ejemplo en las versiones 3.X de NT se utilizan el administrador de programas y demas
elementos del Windows 3.X, mientras que en NT 4.0 se emplea el nuevo interfase de
Windows 95/98. Esto permite reducir la curva de aprendizaje para el nuevo sistema
operativo. NT saca un mejor provecho que los diferentes Windows a la ejecucion de
aplicaciones en multitarea real, permitiendo ejecutar varias aplicaciones simultaneamente, conmutando rapidamente entre ellas.
NT puede ejecutar varios tipos de aplicaciones:
Aplicaciones MSDOS. La mayor parte de las aplicaciones MSDOS corren sin

problemas.Solo aquellas que acceden directamente a recursos especficos, como
pueden ser el puerto serie o el paralelo, o que intentan capturar las interrupciones basicas de MSDOS, no funcionan. Tpico ejemplo de estas aplicaciones
son las que funcionan con llaves de proteccion del tipo mochila que no estan
especficamente preparadas para NT.
Aplicaciones Windows de 16 bits. La mayor parte de las aplicaciones de 16 bits
funcionan sin problemas bajo Windows NT. Algunas aplicaciones, que utilizan
llamadas no documentadas a las APIs de Windows, o que hacen suposiciones
sobre los recursos de Windows que son solo validos en Windows 3.x fallan al
ejecutarse sobre NT.
Aplicaciones Win32. Son las nuevas aplicaciones desarrolladas para Windows 95
y NT. Las aplicaciones Win32 eliminan gran parte de los problemas que tenan
las aplicaciones Win16, que estan basadas en el modelo plano de memoria, que
permite a las aplicaciones disponer de hasta 2 gigabytes de datos. Las aplicaciones Win32 se ejecutan siempre como multitarea real, en espacios de memoria
separados que evitan que el mal funcionamiento de una de ellas repercuta en las
demas. Ademas las aplicaciones Win32 hacen uso de las nuevas APIs Win32,
mas potentes y flexibles, con capacidad de ejecucion de m
ultiples hilos. Esto
permite a las aplicaciones ejecutar tareas de fondo, como la revision ortografica, recalculo, repaginacion e impresion tpica de los procesadores de texto y de
r
259

APENDICE
A. ADMINISTRACION
las hojas de calculo. Esto evita al usuario largos tiempos de espera en su trabajo
habitual.
Aplicaciones POSIX. Son aplicaciones basadas en el estandar com
un POSIX,
un subconjunto de las APIs de UNIX. El susbsistema POSIX emula el comportamiento de las aplicaciones UNIX, incluyendo elementos como el uso de
enlaces (links) para los ficheros. Para desarrollar aplicaciones POSIX para NT
se puede utilizar el compilador que se distribuye en el kit de recursos, o una
nueva distribucion del popular GCC de GNU (distribucion Cignus) que incluye
un soporte mucho mas avanzado tanto de aplicaciones Win32 como de aplicaciones POSIX. Este compilador se puede encontrar en los espejos de GNU en
la red.
Aplicaciones OS/2. Se pueden ejecutar aplicaciones OS/2 de modo texto. Las
aplicaciones basadas en Presentation Manager se pueden ejecutar utilizando un
modulo adicional disponible a traves de Microsoft.
A.2.
La red Microsoft Windows
Para ver el funcionamiento de la red Microsoft hay que distinguir dos partes:
La parte fsica de la red. El funcionamiento basico de la red Microsoft, basado

en el protocolo Netbeui, supone que todos los miembros de la red estan interconectados entre s. Esto implica que no hay barreras del tipo conmutadores
o encaminadores de red entre las diversas partes de la red. Cuando aparece
este tipo de elementos se utilizan otros protocolos, como el TCP/IP o el IPX,
que encapsulan el protocolo Netbeui, permitiendo la integracion del la red local
dentro de una red mas compleja.
Para la parte logica de la red, el esquema de red de Microsoft permite trabajar
de dos modos diferentes: como grupos de trabajo y como dominios.
A.2.1.
Los grupos de trabajo
En los grupos de trabajos los servidores y estaciones de trabajo configuran una red
local del tipo de igual a igual. En este modo de funcionamiento, en principio todos los
ordenadores pueden ser clientes y servidores simultaneamente. Los grupos de trabajo
fueron introducidos por Microsoft cuando introdujo en el mercado Windows para
Trabajo en Grupo. Este esquema de funcionamiento es bastante sencillo, ya que no
precisa de la existencia de la figura del administrador del grupo.
260
r
A.2. LA RED MICROSOFT WINDOWS
Todos los ordenadores a priori se comportan de la misma forma, pudiendo acceder

todos ellos a los demas ordenadores de la red. Esto no impide que dentro de un grupo
de trabajo se puedan introducir maquinas configuradas exclusivamente como clientes
o como servidores.
A.2.2.
Los dominios NT
El sistema de dominios en NT hereda la funcionalidad que permita obtener los

dominios Lan Manager de Microsoft. El esquema de dominios aporta grandes ventajas
en la seguridad de la red, aunque a
nade mayor carga administrativa. En un grupo de
trabajo, al no existir la figura del administrador, deben ser los propios usuarios los que
se encarguen de la configuracion de la seguridad. El sistema de dominios introduce la
figura del administrador. Este

es el responsable de mantener la seguridad del dominio,
dando de alta a los usuarios y asignandoles privilegios de acceso a los recursos del
dominio.
Un dominio esta compuesto por al menos un controlador primario del dominio
y por estaciones de trabajo que act
uan como clientes del dominio. El controlador
principal del dominio va a ser el ordenador que va a almacenar la base de datos
de usuarios y de ordenadores del dominio. Un dominio puede tener varios tipos de
clientes:
Clientes Windows para trabajo en Grupo, Windows 95/98, Windows NT/2000

Workstation y Server.
Ordenadores con MSDOS o Windows 3.1, con el cliente de red Microsoft instalado.
Ordenadores con OS/2 o Macintosh
Otros tipos de ordenadores, por ejemplo los que usan LAN Manager para UNIX,
o con el software de SMB (por ejemplo Samba).
A.2.3.
Uso de los dominios de NT
El sistema de dominios introduce una mayor carga administrativa sobre el sistema

de grupos de trabajo cuando la red es peque
na. El sistema de dominios necesita una
mayor planificacion inicial frente al grupo de trabajo, ya que el administrador debe
dar de alta a los usuarios y equipos. Sin embargo, al ampliar la red esa mayor carga
administrativa inicial se traduce en una mayor simplicidad de la administracion de una
red corporativa. Cuando el n
umero de ordenadores y de usuarios de la red comienza a
r
261

APENDICE
A. ADMINISTRACION
superar las decenas, la estructura creada por el dominio aporta numerosas ventajas.
La primera y mas importante es la seguridad del dominio.
En un dominio la base de datos de usuarios y de equipos es u
nica, y esta centralizada. A cada usuario se le asigna una cuenta que le identifica en el dominio. En
principio la autenticidad del usuario esta garantizada por el uso de su contrase
na.
Esto facilita al usuario el acceso a los recursos del dominio, ya que la mayor parte
de las veces no necesitara introducir su contrase
na. El esquema de dominios permite
ademas crear grupos de usuarios. Los grupos de usuarios facilitan la administracion
de los dominios ya que permite asignar seguridad, aplicaciones y otros recursos del
dominio a grupos de usuarios con caractersticas comunes. El sistema de grupos de
usuarios es muy flexible, permitiendo adaptar el dominio a la estructura corporativa.
Un usuario del dominio puede pertenecer a varios grupos, de manera que cada uno
de los grupos a los que pertenece le permita realizar una serie de tareas diferentes.
El sistema de dominios simplifica la administracion de servidores y estaciones de
trabajo. A medida que se a
naden estaciones y servidores al dominio, el administrador
utiliza las herramientas administrativas para darlos de alta en el dominio. Cuando
un equipo es dado de alta en el dominio puede comunicarse de una manera segura
con los demas miembros del dominio. De esta manera puede reconocer a los demas
usuarios y equipos del dominio. Esta tarea es realmente sencilla. Durante el proceso
de instalacion de una estacion de trabajo o servidor NT, aparece un cuadro de dialogo
en el que se da la oportunidad de a
nadir el equipo al dominio. Para a
nadir el equipo
basta escribir el nombre del dominio y nombre de usuario y contrase
na con privilegios
de administrador valido en el dominio. El proceso de instalacion se pone en contacto
con el controlador del dominio y da de alta al ordenador en el dominio. Una vez que se
ha dado de alta en el dominio, el programa de instalacion configura automaticamente
el sistema para que sea miembro del dominio. El proceso completo se desarrolla en
pocos segundos y sin intervencion del usuario.
El sistema de dominios simplifica enormemente la gestion de grandes dominios, ya
que los cambios introducidos en la configuracion del dominio se reflejan automaticamente en todos los miembros del dominio. Si por ejemplo se a
nade un nuevo equipo
al dominio, queda disponible para el uso por los demas miembros del dominio.
A.2.4.
Elementos de un dominio
En un dominio se pueden integrar varios tipos de servidores y de clientes. En todo

dominio puede haber:
Un controlador principal del dominio. Es obligatorio, ya que es el equipo que

mantiene la base de datos del dominio. Este servidor debe ser obligatoriamente
262
r
un NT Server configurado como controlador principal del dominio.

Controladores de reserva del dominio. Puede haber varios en el dominio. Su
labor consiste en ayudar al controlador principal en caso de sobrecarga o mal
funcionamiento de este. Es recomendable siempre tener al menos un controlador de reserva correctamente configurado, ya que de este modo se asegura que
siempre los usuarios podran iniciar sesion correctamente en el dominio.
Estaciones de trabajo. Son los clientes del dominio, y pueden ser de diferentes
tipos (Windows, Os/2, etc.)
Servidores NT. Se puede configurar NT Server en el modo servidor. En este
modo, el servidor no colabora en la validacion de los inicios de sesion por parte
de los usuarios, con lo que la carga del servidor es menor. Este modo se suele
utilizar para configurar servidores de ficheros y aplicaciones, como servidores
SQL y de Internet. Ademas, un NT Server configurado como servidor mantiene
su propia base de datos, ademas de poder acceder a la del dominio. Esto permite
tener cuentas separadas de las del dominio. El uso fundamental que se puede
dar a esta funcionalidad consiste en crear grupos de usuarios ajenos al dominio,
que se pueden eliminar facilmente sin mas que eliminar el servidor.
Otros tipos de servidores. Hay varios sistemas operativos que de alguna forma
pueden acceder al dominio NT, normalmente con sus propias herramientas de
integracion. Por ejemplo, desde que Microsoft hizo p
ublico el protocolo SMB,
hay sistemas que soportan parte de la funcionalidad de este protocolo, aunque
no se pueden construir controladores de dominio con otros sistemas operativos.
A.2.5.
El sistema de recursos de red
En una red Microsoft se pueden compartir varios tipos de recursos, como pueden
ser impresoras y unidades de red. En una red Microsoft el nombre de los recursos
sigue el siguiente convenio:
\\servidor\recurso
escrito en el formato UNC (Universal Name Convention). Servidor es el nombre
del servidor que comparte el recurso. Recurso es el nombre que se le da al recurso.
En el caso de recursos del tipo unidad de red, detras del nombre de recurso se puede
poner la ruta completa de directorios, y el nombre de un archivo cuando nos estamos
refiriendo a un archivo remoto, de este modo:
\\servidor\recurso\directorio\directorio\fichero.exetension
Ademas de poder compartir unidades de disco e impresoras, se pueden compartir
r
263

APENDICE
A. ADMINISTRACION
otro tipo de recursos, como unidades CD-ROM, modems, fax (con el software adecuado, no incluido en NT), y otros tipos de recursos especiales, como pueden ser las
tuberas creadas entre el controlador del dominio y los ordenadores conectados a el.
Para crear los recursos se deben utilizar las herramientas apropiadas en cada caso:
Para unidades de red, se utiliza el explorador de Windows NT, o el administrador de archivos (Winfile.exe)
Para compartir impresoras se utiliza el administrador de impresion.
Para tipos especiales de recursos, normalmente hay herramientas especiales que
lo hacen. Normalmente todos los recursos compartidos aparecen en los listados
de recursos de red de todos los clientes. Se puede modificar el nombre de recurso
para que no aparezca en los listados de recursos. A este tipo de recursos se les
llama recursos compartidos en modo administrativo.
Para compartir un recurso en modo administrativo basta con a

nadir un signo $ al
final del nombre de recurso:
Por ejemplo, siempre que se inicia NT, el sistema de red comparte automaticamente en modo administrativo las unidades de disco. As por ejemplo tendremos:
\\servidor\c$
\\servidor\d$
compartidas automaticamente al arrancar el ordenador. Luego se pueden dejar
de compartir, si fuese necesario. Ademas NT a
nade los permisos correspondientes
para que solo tengan acceso los administradores. Para ver los recursos compartidos
en modo administrativo se puede:
Abrir el Panel de Control, en el icono Servidor, y ver los recursos compartidos.

Abrir el Administrador de Servidores de NT Server, y seleccionando un servidor
o estacion de trabajo, ver los recursos compartidos.
Este mecanismo permite de una manera muy comoda acceder a los administradores a los diferentes discos de todas las estaciones de trabajo del dominio,
para realizar labores de copia de ficheros, instalacion de aplicaciones, y otras
tareas. Para conectarse a un recurso compartido en modo administrativo, ya
que su nombre no aparece en los listados de recursos, debemos seleccionarlo
manualmente:
264
r
Escribiendo su nombre directamente, en el cuadro de dialogo Conectarse

a una unidad de red.
Utilizando NET USE \\servidor\recurso$.
Otra forma de acceder los administradores a los discos de las estaciones de trabajo
del dominio es:
1. click derecho en Mis Sitios de Red

2. elegir Conectar a unidad de red. . .
3. se abre ventana con dos campos a rellenar:
Uno es Unidad donde pondremos el nombre de como ese recurso compartido en modo administrador se llamara en nuestro ordenador. En Mi
PC aparecera este como si fuera una unidad mas de nuestro ordenador.
Otro es Carpeta, donde se debe escribir a que maquina queremos acceder
y a que recurso. Esto se hace escribiendo: //Servidor/recurso_compartido$
Figura A.1: Conectar a unidad de red
Este
es un buen metodo para escanear con antivirus las maquinas desde otras
maquinas.
r
265

APENDICE
A. ADMINISTRACION
A.2.6.
Inicio de sesi
on en un grupo de trabajo
Cuando un usuario va a acceder a una red, lo primero que debe realizar es un inicio
de sesion. El inicio de sesion consiste en que el usuario debe introducir un nombre de
usuario y una contrase
na, que seran utilizados por el sistema para acceder a la red.
Ya que en el grupo de trabajo no hay servidores dedicados a validar los inicios de
sesion, el inicio de sesion en Windows para trabajo en grupo es simple. El inicio de
sesion es un mero anuncio de que el usuario se dispone a utilizar los recursos de red.
No se realiza ninguna comprobacion de seguridad, es decir, cualquier usuario puede
iniciar sesion con cualquier nombre dentro del grupo de trabajo. No existe ning
un
mecanismo que impida al usuario iniciar sesion de red.
Durante el inicio de sesion en un grupo de trabajo, al usuario se le pide su nombre de usuario y su contrase
na. En Windows para Trabajo en Grupo el nombre de
usuario se utiliza como identificador del usuario, aunque no hay ninguna garanta de
la verdadera identidad del usuario. La contrase
na facilitada por el usuario se utiliza
para dos tareas:
Cuando se acceden a los recursos de red protegidos por contrase

na, Windows
para Trabajo en Grupo facilita esta contrase
na en primer lugar. Si la contrase
na
no es valida, mediante un cuadro de dialogo se pedira al usuario la contrase
na
correcta para acceder al recurso.
La contrase
na ademas se utiliza para encriptar el archivo de contrase
nas, que
normalmente se llamara nombre.pwl, donde nombre es el nombre del usuario.
En este archivo se guardan las contrase
nas utilizadas por el usuario para acceder
a los recursos de red.
Si un usuario ha olvidado la contrase

na, no podra desbloquear el archivo de contrase
nas. Normalmente puede iniciar sesion con otro nombre de usuario, y borrar el
antiguo archivo de contrase
nas, con lo que de nuevo podra iniciar sesion en el sistema
con su nombre de usuario habitual.
El esquema de contrase
nas de los grupos de trabajo suele ser bastante engorroso,
ya que cuando la contrase
na de un recurso cambia obliga a difundir de nuevo las
contrase
nas a los usuarios interesados. Ademas los archivos de contrase
nas son muy
faciles de desbloquear, existiendo en Internet numerosas utilidades que lo hacen. Windows para trabajo en grupo es bastante difcil de cerrar, para impedir el acceso al
sistema y a la red de un usuario que no tiene permiso para ello.
266
r
A.2.7.
Inicio de sesi
on en un dominio
Aparentemente el metodo de inicio de sesion en un dominio NT es similar al

utilizado en un grupo de trabajo. El usuario tiene que realizar el proceso de inicio de
sesion o logon, suministrando un nombre de usuario y una contrase
na valida para el
dominio.
El proceso de inicio de sesion en un dominio es mas sofisticado:
El usuario proporciona el nombre de usuario y la contrase

na en el cliente del
dominio. Dependiendo del cliente, este procedimiento puede ser mas o menos
seguro. Por ejemplo, en Windows para trabajo en grupo se siguen los mismos
pasos que para el inicio de sesion de red normal, aunque la contrase
na para el
dominio hay que proporcionarla en un cuadro de dialogo separado, para mayor
seguridad. En Windows NT, el proceso de inicio de sesion automaticamente
registra al usuario en el dominio, y requiere el uso de una combinacion especial
de teclas: Ctrl+Alt+Suprimir.
El cliente solicita el inicio de sesion al servidor controlador del dominio. En este
momento el servidor enva al cliente un conjunto de datos. Este esquema de
validacion es un esquema de tipo desafo/respuesta.
El cliente encripta los datos enviados por el servidor con la contrase
na que le ha
suministrado el usuario. Este nuevo conjunto de datos es enviado al servidor.
El servidor encripta los datos originales, con la contrase
na del usuario que guarda en la base de datos de NT. Ahora compara ambos conjuntos de datos.
Si los datos codificados por el servidor y por el cliente coinciden, el servidor
valida al usuario para acceder al dominio.
Durante el proceso de inicio de sesion, la contrase

na del usuario no viaja por la
red, ya que con el sistema de reto, lo que viajan son paquetes de datos codificados,
pero no la contrase
na que los codifica. Este sistema tiene un punto vulnerable, ya que
en el servidor se almacenan las contrase
nas de todos los usuarios en la base de datos
de usuarios. Sin embargo, se han introducido mejoras en el sistema de gestion de la
base de datos, que hace muy difcil el acceso a las contrase
nas incluso para los propios
administradores de NT. Estas mejoras fueron introducidas con el Service Pack 3 para
NT Server.
El inicio de sesion en el dominio solo se produce una vez. Es decir, una vez que
un usuario ha iniciado sesion en un dominio, no necesita suministrar de nuevo su
contrase
na para acceder a los diferentes recursos del dominio. En todo momento, la
validacion del usuario se va a realizar a traves de los controladores y servidores.
r
267

APENDICE
A. ADMINISTRACION
El sistema de seguridad de NT no solo permite gestionar el acceso de los usuarios
a los recursos, sino que incluso se pueden crear grupos de usuarios a los que se les
asignan privilegios, por lo que la gestion de la seguridad se simplifica dentro del
dominio.
A.2.8.
Los controladores de dominio
Todo dominio tiene una base de datos de usuarios. La copia original de esta base
de datos reside en el controlador principal del dominio. En esta base de datos quedan
registradas todas las caractersticas de los usuarios, sus cuentas, y de los ordenadores
que forman parte del dominio.
Ademas del controlador principal del dominio, puede haber dentro de un dominio
varios controladores secundarios del dominio. En estos controladores se mantiene una
copia de la base de datos de usuarios del dominio. Si el controlador del dominio
esta muy cargado o simplemente esta inactivo, cualquier controlador del dominio
puede validar el inicio de sesion en el dominio.
El proceso de inicio de sesion en los controladores del dominio comienza en el
cliente por obtener la lista de controladores del dominio. Para ello el servicio Examinador de computadoras obtiene dicha lista, bien mediante una pregunta por difusion
(broadcast), o bien preguntando a los servidores WINS del dominio. Una vez obtenida
la lista, el cliente enva una peticion de inicio de sesion a los diferentes controladores
del dominio. El cliente elegira al primer controlador de dominio que le conteste para
intentar el proceso de inicio de sesion. Este metodo asegura que siempre el cliente
pueda iniciar sesion en el dominio.
El mantenimiento de la base de datos del dominio es automatico. Las herramientas administrativas de NT permiten modificar la base de datos, mediante el Administrador de usuarios para dominios.
Los cambios se realizan siempre sobre el controlador principal del dominio, y son
enviados automaticamente a los demas controladores del dominio. Hay que tener en
cuenta que esto se realiza con una peque
na demora temporal, que se puede reducir
sincronizando los servidores con el administrador de servidores.
A.2.9.
Diferencias entre NT Workstation y NT Server
El sistema operativo Windows NT se comercializa en dos versiones: Workstation

y Server.
268
r
A.3. EL ADMINISTRADOR DE USUARIOS
La version Workstation esta pensada para configurar puestos de trabajo, donde

se ejecutaran las aplicaciones de usuarios. NT Workstation es una plataforma que
incluye todos los elementos para trabajar con aplicaciones Windows y para trabajar
en red. Incluye una pila completa TCP/IP.
NT Server esta preparado para configurar servidores. Aunque realmente los n
ucleos
de NT Server y Workstation son muy parecidos, la version Server incluye una serie de
mejoras en el n
ucleo y en los diferentes modulos del sistema que lo hacen mas robusto
en tareas de servidor de red. NT Server da mayor prioridad a los accesos mediante
red frente a las aplicaciones de usuario que se ejecutan en el servidor. Ademas NT
Server no tiene el lmite de 10 conexiones simultaneas de red que tiene NT Workstation. NT Server ofrece mayor seguridad en el almacenamiento de datos, ya que posee
caractersticas avanzadas de tolerancia a fallos que no han sido incluidas en la version
Workstation.
A.3.
El Administrador de usuarios
En NT hay dos tipos de usuarios, aquellos que pertenecen a una maquina que
corre NT WK o Server y aquellos que pertenecen a un dominio NT. Para cada uno de
estos tipos de usuarios existe una herramienta de administracion: el administrador de
usuarios incluido en NT Workstation y el administrador de usuarios para dominios
incluido en NT Server (ver figura A.2).
Figura A.2: Administrador de Usuarios

El funcionamiento de ambos es muy similar, pero el administrador de usuarios
r
269

APENDICE
A. ADMINISTRACION
para dominios dispone de mas opciones. Por ello, se describira el administrador de
usuarios para dominios.
Las tareas que se pueden realizar con el administrador de usuarios:
A
nadir, modificar y eliminar usuarios del dominio.
A
nadir, modificar y eliminar grupos locales y globales del dominio.
Fijar el plan de cuentas y contrase
nas en el dominio.
Fijar la poltica de derechos de usuario en el dominio.
Establecer el sistema de auditoria en el dominio.
Establecer relaciones de confianza entre dominios.
A.3.1.
Creaci
on y modificaci
on de usuarios en el dominio
Crear un usuario nuevo

Para crear un usuario se pulsa Usuarios\Nuevo y se completa el cuadro de
dialogo. (Ver figura A.3).
Figura A.3: Administrador de Usuarios; usuario nuevo
En este cuadro hay que rellenar una serie de campos:
270
r
Nombre de usuario Es el identificador que representa al usuario en el dominio.

Debe ser una palabra completa, sin espacios en blanco ni caracteres especiales,
de hasta 14 caracteres. este identificador debe ser u
nico en el dominio. Se le
suele conocer tambien como nombre de cuenta o login. Este identificador es
el que se debe suministrar, junto con la contrase
na, para iniciar sesion en un
dominio NT.
Nombre completo Es el nombre completo del usuario. Si este usuario es una persona se suele escribir el nombre y apellidos.
Descripci
on Conviene a
nadir una descripcion de la labor, grupo de personas o departamento al que pertenecen el usuario, sobre todo si la base de datos de
usuarios en el dominio es grande.
Contrase
na Aqu se debe escribir la contrase
na para el usuario. Puede incluir espacios, may
usculas y min
usculas, e incluso caracteres especiales. NT admite
hasta 14 caracteres. Cuando se va escribiendo aparecen asteriscos, y una vez
completada en el cuadro aparece una lnea de asteriscos, siempre de la misma
longitud.
Repetir contrase
na Hay que introducir de nuevo la contrase
na, para comprobar
que se ha escrito correctamente.
Tras estos campos aparecen una serie de botones activables:
El usuario debe cambiar su contrase

na La primera vez que inicia sesion en NT
se va a solicitar que introduzca una nueva contrase
na. Habitualmente los administradores crean los usuarios nuevos con contrase
nas del tipo cambiame, que
obligan al nuevo usuario a cambiar su contrase
na al iniciar sesion por primera
vez.
El usuario no puede cambiar su contrase
na Se utiliza en tareas administrativas especiales, y bloquea el cambio de contrase
na por parte del usuario.
La contrase
na nunca caduca Desactiva la caducidad de contrase
nas para esta
usuario. Se utiliza normalmente solo para algunos usuarios que lo necesitan.
Cuenta desactivada Permite bloquear la cuenta facilmente sin borrarla. Se suele
utilizar cuando el usuario no va a iniciar sesion durante un periodo de tiempo
o cuando se va a cambiar la configuracion o entorno del usuario y se necesita
que no pueda acceder temporalmente al sistema.
Al final del cuadro de dialogo aparecen varios botones (ver figura A.3).
r
271

APENDICE
A. ADMINISTRACION
Figura A.4: Administrador de Usuarios; usuario nuevo; grupos
Grupos Permite establecer los grupos a los que pertenece un usuario (ver figura
A.4). En NT hay dos tipos de grupos:
Grupos globales Validos para dominios en los que se confan. Aparecen marcados con el icono de grupo global.
Grupos locales Son grupos locales al servidor o estacion de trabajo.
Perfil Permite controlar las caractersticas del entorno de un usuario (figura A.5).
Se puede establecer:
Perfil Nombre del fichero que representa el perfil del usuario para NT. Hay que
escribir un fichero en formato UNC (Univer name convention), es decir:
\\servidor\recurso\directorio\fichero.bat.
Figura A.5: Administrador de Usuarios; usuario nuevo; perfil
272
r
Archivo de inicio Asigna un archivo que se ejecutara al iniciar la sesion de red

en el dominio. El archivo debe residir en el servidor que valida el inicio de
sesion. Este fichero se debe hallar en la carpeta NETLOGON del servidor
que valida el inicio de sesion.
Directorio de trabajo Admite dos modalidades de uso.
Ruta de acceso local Utilizar una ruta local al ordenador en que se inicia la sesion.
Conectar una letra de unidad a una unidad de red del tipo \\servidor\recurso.
A El directorio de trabajo es el que aparece por defecto en los cuadros de
dialogo de guardar un fichero en una aplicacion Windows.
Horas En el boton Horas podemos acceder al cuadro de dialogo de Horas de inicio
de sesion (ver figura A.6). En este cuadro de dialogo se pueden fijar las horas
de inicio de sesion en los servidores del dominio, en intervalos de 1 hora, para
cada da de la semana. En principio una vez iniciada la sesion el usuario puede
seguir trabajando en los servidores, aunque se puede modificar esto, para que
los servidores cierren la sesion del usuario al terminar las horas permitidas,
mediante el cuadro de dialogo Plan de cuentas en el men
u de Directivas del
Administrador de Usuarios.
Figura A.6: Administrador de Usuarios; usuario nuevo; horas
Iniciar desde Este cuadro de dialogo permite seleccionar los ordenadores desde los
cuales un usuario puede iniciar sesion. Se pueden especificar hasta 8 ordenadores
que ejecuten NT, o permitir el inicio en todos los ordenadores del dominio. Ver
figura A.7.
r
273

APENDICE
A. ADMINISTRACION
Figura A.7: Administrador de Usuarios; usuario nuevo; iniciar de sesion
Cuenta El cuadro de dialogo Informacion de cuenta permite especificar el tipo de

cuenta y su duracion. Se puede elegir que la cuenta caduque en una fecha determinada o que no tenga caducidad. Tambien se puede especificar si es una
cuenta global o local. Ver figura A.8.
Figura A.8: Administrador de Usuarios; usuario nuevo; cuenta
Marcado El cuadro de dialogo de Marcado permite especificar las propiedades de

marcado para el usuario. Figura A.9.
Modificar un usuario
Utilizando el men
u Usuario\Propiedades o haciendo doble clic sobre un usuario
o grupo se puede modificar el mismo.
Al modificar un usuario se acceden a los mismos cuadros de dialogo empleados
al crearlo salvo que ahora aparece una casilla para cuentas bloqueadas. Si el bloqueo
274
r
Figura A.9: Administrador de Usuarios; usuario nuevo; marcado
de cuentas esta activado en el dominio y el usuario ha fallado el n

umero de veces
limitado para ese dominio, esta casilla aparece activada. Al desactivarla, la cuenta
del usuario es desbloqueada.
Nota importante: existe una ligera demora al cambiar las propiedades de un
usuario o grupo del dominio, debido a que la base de datos de usuarios del dominio
tarda unos minutos en actualizarse en los controladores secundarios. Se puede forzar
la actualizacion inmediata mediante la sincronizacion manual de los servidores.
A.3.2.
Creaci
on de grupos
Para un NT Workstation (o Server configurado como servidor) el administrador

de usuarios permite crear grupos locales, que solo tienen validez en el propio ordenador. El administrador de usuarios para dominios permite crear dos tipos de grupos:
globales y locales.
Los grupos locales pueden obtener permisos en los servidores del dominio propio.
Pueden ser miembros de los grupos locales los miembros del dominio, los grupos
globales del dominio y los grupos globales de otros dominios en los que se confa.
Los grupos globales tienen como miembros a los usuarios del dominio y se pueden
utilizar tanto en los servidores del dominio como en las estaciones de trabajo del
dominio. Tambien se pueden usar en otros dominios en los que se confa.
r
275

APENDICE
A. ADMINISTRACION
Creaci
on de un grupo global nuevo
Para a
nadir un grupo global nuevo se selecciona el men
u Usuario\Grupo Global nuevo y se proporcionan en el cuadro de dialogo el nombre del grupo y una
descripcion opcional. Podemos ademas a
nadir usuarios al grupo.
Creaci
on de un grupo local nuevo
Para a
nadir un grupo local nuevo se selecciona el men
u Usuario\Grupo Local nuevo y se proporcionan en el cuadro de dialogo el nombre del grupo y una
descripcion opcional. Podemos ademas a
nadir usuarios al grupo.
Usos de grupos locales y globales

Cuando se crea un dominio el programa de instalacion de NT crea una serie de
grupos globales y locales del dominio. Tambien se crea la cuenta del administrador
del dominio, y se a
nade al grupo administradores del dominio.
El grupo administradores que se ha creado permite administrar todos los servidores del dominio. NT a
nade al grupo local administradores el grupo administradores
del dominio. De igual manera ocurre con el grupo de usuarios e invitados. Cuando una
estacion de trabajo es a
nadida al dominio, NT a
nade automaticamente los tres grupos
globales del dominio (administradores, usuario e invitados del dominio) a los grupos
locales correspondientes de la estacion de trabajo. Los grupos locales se utilizan para
asignar tareas especiales en las estaciones de trabajo o servidores del dominio. Por
ejemplo se pueden crear los grupos especiales para trabajar con el recurso como una
impresora laser en color, cuyo acceso queremos restringir. Uno lo podemos llamar
Administradores de laser color y otro Usuarios de laser color. Ahora basta dar
permisos de impresion al grupo Usuarios de laser color y control total al grupo
Administradores de laser color. Para a
nadir usuarios a estos grupos bastara a
nadir
al grupo Administradores de laser color el grupo Administradores del dominio y
al grupo Usuarios de laser color los miembros del dominio autorizados a imprimir
en ella. Este u
ltimo paso lo podemos hacer de un medio mas eficiente si creamos un
grupo global Usuarios de impresora laser color y a
nadimos este grupo al grupo local Usuarios de laser color. Para dar permisos de impresion a los usuarios y grupos
utilizaremos el Administrador de Impresion de dicha impresora, accesible desde el
men
u de inicio Configuraci
on\Impresoras
Cada usuario en NT debe pertenecer a uno o varios grupos globales o locales,
indistintamente. Los grupos locales se definen en cada estacion de trabajo NT o en
cada servidor.
276
r
A.4.
A.4. PERMISOS Y SEGURIDAD
Permisos y seguridad
En NT se pueden fijar una serie de directivas comunes para todo el dominio. Entre
estas se puede fijar el plan de cuentas para el dominio, que fija propiedades de las
cuentas tales como la poltica de contrase
nas, el plan de derechos de usuarios, que
permite asignar determinados permisos genericos usuarios o grupos del dominio, o el
plan de auditoria, que permite activar los elementos del sistema de auditoria en el
dominio.
A.4.1.
Administraci
on del plan de cuentas
Desde el men
u Directivas\Cuentas podemos acceder al cuadro de dialogo Plan
de cuentas.
En este cuadro podemos fijar las limitaciones de las contrase
nas y el sistema de
bloque de cuentas. Cuando se ha seleccionado caducidad para la contrase
na de un
usuario, la contrase
na utilizara las opciones elegidas en este cuadro de dialogo. Se
puede elegir:
Duracion maxima de la contrase

na, en das.
Duracion mnima de la contrase
na, para que el usuario cambie dos veces su
contrase
na y vuelva a usar la contrase
na antigua.
Longitud mnima de la contrase
na. Las contrase
nas con mas de 6 caracteres son
difciles de saltar por metodos de asalto masivo (crackers), tambien llamados de
fuerza bruta. Esto es u
til en redes conectadas a Internet.
Historia de la contrase
na, que obliga al usuario a no repetir las u
ltimas contrase
nas.
Bloqueo de Cuentas El sistema de bloqueo de cuentas permite a los controladores
de dominio reaccionar frente a los intentos fallidos de iniciar sesion en el dominio.
Si se activa el bloque de cuentas entonces al alcanzarse el numero de intentos
especificado la cuenta es bloqueada. Si el n
umero de intentos fallidos no alcanza
al especificado, el usuario puede esperar el tiempo fijado en restablecer cuenta
para poder volver a intentarlo. Fijando por ejemplo estos parametros a 4 intentos
y 10 minutos suele bastar para disuadir de accesos no autorizados. Una vez
bloqueada la cuenta se puede elegir entre desbloqueo automatico o manual, con
intervencion del administrador del dominio.
r
277

APENDICE
A. ADMINISTRACION
Tambien en este cuadro de dialogo se puede seleccionar si los usuarios remotos
seran desconectados de los servidores al acabar su tiempo de conexion y si un usuario
debe iniciar sesion en una estacion de trabajo para poder cambiar su contrase
na.
A.4.2.
Administraci
on del plan de derechos de usuarios
Los derechos de usuarios son una serie de permisos que no se aplican sobre un
objeto concreto, como un fichero, impresora o directorio, sino que se aplican al sistema
completo. Estos permisos tienen prioridad sobre los permisos asignados sobre los
objetos del sistema. Se pueden asignar a cada tipo de derecho de usuario los usuarios
o grupos de usuarios a los que se necesite otorgar ese derecho.
Los derechos de usuarios pueden ser modificados desde el cuadro de dialogo Plan
de derechos de usuarios accesible desde el men
u Directivas\Derechos de usuarios. Ver figura A.10.
Figura A.10: Administrador de Usuario; directivas; plan de derechos de usuarios
Si se activa la casilla Mostrar derechos de usuario avanzados se pueden ver

algunos derechos de usuarios mas especficos. Normalmente los derechos de usuario
asignados por NT asignan derechos suficientes a los grupos de usuarios creados por
NT. Cuando se instalan algunos servicios, como servidores de correo, de Web y similares suele ser necesario cambiar algunos de estos derechos. Los mas frecuentes suelen
ser:
Iniciar sesion como servicio. Permite asignar un usuario a un servicio. Suele

ser usuario en servidores de ficheros tipo FTP, Gopher y Web, ya que permite
asignar permisos a los ficheros para ese usuario, limitando el acceso a otros
ficheros del sistema. Tambien lo usa el servicio de duplicacion de directorios.
278
r
A.5. PERMISOS Y SEGURIDAD EN NT
Iniciar sesion como proceso por lotes. Este derecho esta pensado para los servicios que atienden las peticiones de usuarios en forma de transacciones, como
por ejemplo servidores POP3 y otros. Actualmente no esta implementado en
el sistema operativo, pero algunos servicios verifican que el usuario posea este
derecho antes de atender su peticion.
A.5.
Permisos y seguridad en NT
El sistema de seguridad de NT se beneficia de la estructura orientada al objeto de

NT. En NT todos los elementos del sistema, como pueden ser archivos, directorios,
unidades de disco, impresoras,... se consideran objetos. Un objeto es un elemento
del sistema operativo dotado de una serie de propiedades comunes a todos los objetos
de su mismo tipo. En NT cada objeto del sistema tiene incorporada su seguridad de
manera que el sistema puede determinar para cada objeto los permisos y modo de
acceso permitidos a cada usuario.
En NT no existe una herramienta que centralice el sistema de seguridad, sino
que para cada tipo de objeto la herramienta que permite modificar sus propiedades
tambien modifica su seguridad. Las principales herramientas administrativas que fijan
la seguridad de los objetos son el administrador de usuarios, el administrador de
impresion y el administrador de servidores.
A.5.1.
Los perfiles de usuario en NT
Los perfiles de usuario de NT permiten especificar las opciones del entorno para
cada usuario de Windows NT. En Windows 3.x estas opciones habitualmente se guardaban en archivos .ini que eran archivos de texto normalmente compartidos por todos
los usuarios de la aplicacion. En NT todas las opciones y configuraciones del sistema
y de las aplicaciones se guardan en el registro.
El registro es una base de datos jerarquizada donde se guarda toda la informacion
de configuracion. En NT existe un registro completo para el sistema y uno para cada
uno de los usuarios que han iniciado sesion en el sistema, que son los llamados perfiles
de usuario.
Cuando un usuario inicia una sesion por primera vez en NT, el sistema crea un
registro personalizado para el usuario. Si no se ha definido previamente un perfil para
el usuario, el sistema utilizara una copia del perfil de usuario por defecto. Tanto los
perfiles de usuario como el perfil de usuario por defecto se puede editar para establecer
de antemano las opciones del entorno de usuario.
r
279

APENDICE
A. ADMINISTRACION
A.5.2.
Perfiles de usuario frente a perfiles obligatorios
Cuando un usuario inicia sesion en un NT el sistema busca su perfil. Este perfil

existira si el usuario ya ha iniciado anteriormente sesion en NT. En caso de que no
tenga perfil utiliza una copia del perfil de usuario por defecto. Las modificaciones que
realice el usuario en su entorno se guardaran en esta copia del perfil.
Se puede modificar este mecanismo para asignar un perfil concreto al usuario. Esto
se hace con el administrador de usuarios, que permite asignar un fichero de perfil,
creado con el editor de perfiles, al usuario. Se pueden elegir dos tipos de perfiles:
perfil de usuario. El sistema crea un perfil para el usuario basandose en este

fichero. Este proceso solo se realiza la primera vez que el usuario inicio sesion
en la maquina.
perfil obligatorio. El sistema crea un perfil para el usuario basandose en este
fichero cada vez que el usuario inicia sesion en el sistema, de manera que el
usuario pierde la configuracion. Esto permite que el usuario parta de un entorno
estandar cada vez que inicia sesion.
Se pueden eliminar perfiles antiguos de usuarios del sistema. Para ello, deberemos
abrir el men
u Opciones/Eliminar perfil del icono Instalaci
on de Windows
en la carpeta principal del administrador de programas.
A.5.3.
Tipos de perfiles de usuarios
En NT se pueden definir tres tipos de perfiles de usuario:
Local Este perfil es especfico del ordenador en el que se ha creado. El usuario solo
puede acceder al perfil local al iniciar sesion interactiva en el ordenador en el
que reside el perfil.
M
ovil Este tipo de perfil puede ser usado por el usuario en cualquier NT del dominio.
Es parecido al perfil movil de Windows 95, pero es mas completo.
Obligatorio Son perfiles moviles que el usuario no puede modificar. Normalmente
son asignados a un usuario o grupos de usuario por el administrador.
En el perfil de NT 4.0 se guardan opciones como:
280
r
A.5. PERMISOS Y SEGURIDAD EN NT
Todas las opciones definidas por el usuario en el explorador de NT

Las opciones de la barra de tareas.
Las opciones de impresion de red.
Las conexiones de red persistentes.
Algunas configuraciones de los accesorios y el sistema de ayuda.
Las opciones de las aplicaciones Win32
A.5.4.
El directorio de perfiles en NT
El directorio \Winnt\Profiles almacena los perfiles locales para cada usuario, en

directorios separados cuyo nombre se crea a partir del nombre del usuario. Este directorio contiene ademas un perfil por defecto, en Default User, que se aplica a todo
usuario que inicia sesion interactiva por primera vez y no dispone de perfil, y un directorio llamado All Users que es accesible dentro del elemento programas del men
u de
inicio de todos los usuarios que inician sesion en el sistema. Esta carpeta guarda las
carpetas de programas comunes a todos los usuarios.
En el directorio del perfil se almacena:
Un fichero con las claves del registro correspondientes al usuario. Este fichero
se llama: Ntuser.dat
Un fichero log, que mantiene los cambios efectuados en el registro. Se llama
:NTuser.dat.log. Cuando el usuario cierra sesion, el fichero NTuser.dat se actualiza con los cambios introducidos en NTuser.dat.log. En el caso de que existan
problemas al actualizar el fichero NTuser.dat, los cambios se actualizaran en el
siguiente inicio de sesion.
Directorios de datos, enlaces directos y aplicaciones, como son el Escritorio,
carpeta Personal, carpeta Favoritos, carpeta Enviar a y otras carpetas ocultas.
Los perfiles moviles de NT 4.0 permiten mantener de forma centralizada y sincronizada las preferencias y opciones del entorno de un usuario. Cuando un usuario
inicia sesion en NT el sistema comprueba si el usuario dispone de un perfil movil:
Esto lo averigua buscando en la informacion del usuario. Si el campo Directorio del
perfil tiene asignado un directorio, NT sabe que el usuario tiene un perfil movil.
Una vez que NT ha identificado un perfil como movil, copia el perfil completo desde el servidor hasta el directorio \Windir\profiles local. El usuario puede modificar
y usar su entorno. Al cerrar la sesion, el perfil central se actualiza con los cambios
introducidos por el usuario.
r
281

APENDICE
A. ADMINISTRACION
A.5.5.
Creaci
on de un perfil en NT 4.0
El metodo de creacion de perfiles se realiza mediante el icono de sistema del panel

de control y por el editor de directivas del sistema POLEDIT.EXE.
Los pasos a seguir son sencillos:
Si vamos a mantener un gran grupo de perfiles conviene crear un recurso compartido de tipo unidad de red en un servidor adecuado. No es necesario que sea
el controlador de dominio. Por ejemplo:
\\servidor\perfiles
Configuramos la seguridad del recurso para que los usuarios tengan acceso a su
perfil.
Iniciamos sesion con una cuenta con privilegios de administrador.
Modificamos el entorno (opciones, accesos directos, etc).
Ahora se abre el icono Sistema del Panel de Control, en la pesta
na Perfiles de
usuario. Se selecciona el perfil del usuario actual y se pulsa Copiar a . Ver
figura A.11.
Figura A.11: Panel de Control; Sistema; Perfiles de Usuario; Copiar a
El boton permitir usar a indica a los usuarios o grupos de usuarios que

se les permite usar el perfil. Este boton se usa con perfiles asignados a grupos
del tipo obligatorio, ya que si un usuario no pertenece a un grupo que tenga
permiso para usar el perfil, no podra cargarlo.
282
r
Fernando Ballesteros HerranzA.6. EL EDITOR DE DIRECTIVAS POLEDIT.EXE

Se copia el perfil al servidor, indicando la ruta al directorio que contiene el perfil.
Por ejemplo:
\\servidor\Perfiles\NombreUsuario
Se abre el administrador de usuarios y se edita la propiedad Perfil del usuario.
En el directorio del perfil se escribe la ruta al perfil.
Se comprueba ahora en el Panel de Control\Sistema\Perfiles que se trata
de un perfil movil.
Perfiles Obligatorios
Para asignar un perfil a un usuario de manera que el usuario no pueda actualizar
el perfil con los cambios introducidos se utiliza el perfil obligatorio. Los perfiles obligatorios ayudan al administrador a gestionar los perfiles, ya que aseguran que el usuario
cada vez que inicia la sesion encuentre un entorno coherente. Esto suele ser necesario
cuando los usuarios son inexpertos o por simples motivos de seguridad. Cuando el administrador debe mantener una gran cantidad de cuentas de usuarios, puede asignar
perfiles obligatorios a un grupo. Por ejemplo, puede crear un perfil para los usuarios
del grupo Neumatica, de manera que todos ellos tengan el mismo perfil.
Para crear un perfil obligatorio hay que:
Renombrar el fichero NTuser.dat a NTuser.man.

Indicar la extension man en el directorio del perfil.
\\servidor\Perfiles\NombreUsuario.man
Este u
ltimo paso impide en NT 4.0 que el usuario pueda iniciar sesion con el perfil
cache si el perfil principal no esta disponible (el servidor de perfiles esta fuera de
servicio).
A.6.
El editor de directivas POLEDIT.EXE
Las directivas del sistema permiten a los administradores controlar la configuracion y la capacidad de modificar el entorno por parte de los usuarios, o lo que es
lo mismo imponer ciertas reestricciones a los mismo. Esto puede ser realizado de una
forma centralizada para todo el dominio sobre:
r
283

APENDICE
A. ADMINISTRACION
Ordenadores Se puede modificar la configuracion predeterminada de los servidores
y estaciones de trabajo.
Usuarios Se puede eliminar la capacidad de un usuario para acceder a partes delicadas de la configuracion del sistema, como es la configuracion de red o partes
del escritorio de NT.
Grupos Se pueden asignar configuraciones para grupos de usuarios, lo que simplifica
notablemente la administracion del dominio.
A.6.1.
Funcionamiento de las directivas
El modo de trabajo de las directivas del sistema consiste en modificar ciertas claves
del registro, que son las que cierran el paso a las partes del registro mas sensibles.
Las herramientas de administracion y el panel de control utilizan estas claves para
permitir o denegar el acceso del usuario para la modificacion de estas partes. Cuando
se manejan directivas del sistema y perfiles de usuario hay que tener en cuenta que:
Las directivas del sistema complementan a los perfiles, ya que tambien a

naden
claves al registro. El perfil del usuario normalmente almacena informacion de
configuracion que no compromete la seguridad del sistema.
Las directivas del usuario se aplican a
nadiendo las claves despu
es de haber
cargado el perfil de usuario. Esto permite que independientemente de la configuracion almacenada en el perfil del usuario, se puedan aplicar las restricciones
de seguridad necesarios para el usuario. Las directivas del sistema por tanto se
aplican a
nadiendo o alterando las claves del registro tras la carga del perfil.
A.6.2.
Creaci
on de las directivas del sistema para un dominio
La herramienta que permite modificar las directivas del sistema es el Editor de

Directivas del sistema POLEDIT.EXE (ver figura A.12). Las directivas del sistema se
pueden aplicar sobre el sistema actual, aunque cuando realmente se saca provecho de
las directivas del sistema es cuando se definen directivas para un dominio completo.
Crear y modificar directivas para un dominio completo es sencillo. Para ello se
deben seguir estos pasos:
Se crea una nueva directiva con el men

u Archivo\nueva directiva del editor
de directivas.
284
r
Fernando Ballesteros HerranzA.6. EL EDITOR DE DIRECTIVAS POLEDIT.EXE
Figura A.12: El editor de directivas del sistema
Se modifica convenientemente la directiva, a

nadiendo usuarios, grupos y computadoras.
La directiva se guarda en el fichero ntconfig.pol. Este fichero se debe guarda en
el directorio de archivos de inicio de sesion (scripts) de todos los controladores
de dominio.
A.6.3.
Modo de funcionamiento de las directivas
El editor de directivas trabaja modificando las claves del registro. Para ello al crear
una nueva directiva el editor carga desde unas plantillas un conjunto de directivas.
Por defecto, el editor de directivas dispone de tres plantillas:
common.adm Contiene configuracion com

un a NT 4.0 y Windows 95.
winnt.adm Contiene configuracion solo de Windows NT.
windows.adm Contiene configuracion solo de Windows 95. Esta plantilla debe a
nadirla
manualmente un administrador desde el subdirectorio \Windir\inf.
El arbol de directivas muestra conjuntos de directivas que se pueden activar. Cada

una de las directivas puede tener un estado:
Activado (casilla marcada). El editor de directivas modificara convenientemente las claves del registro para aplicar la directiva.
Desactivado (casilla en blanco). El editor de directivas modificara convenientemente las claves del registro para no aplicar la directiva.
Sin cambios (casilla en gris). Es editor de directivas no realizara ninguna
modificacion en el registro.
r
285

APENDICE
A. ADMINISTRACION
El ejemplo mas sencillo es la directiva que indica el protector de pantallas que
debe usar un usuario. Por defecto el usuario utiliza el protector de pantallas que dicta
su perfil, que puede haber sido fijado por el propio usuario, residir en un perfil movil,
en un perfil obligatorio o haber sido creado por defecto automaticamente. Al activar
esta directiva se puede modificar el comportamiento, obligando a un usuario a utilizar
otro protector de pantalla (quizas el que tiene el logotipo corporativo y obliga a usar
contrase
na). En este caso de no activarse la directiva se utilizara la del perfil. Figura
A.13.
Figura A.13: El Editor de Directivas del Sistema, Equipo
A.6.4.
Directivas para sistemas, usuarios y grupos
Se pueden crear tres tipos de directivas:

Directivas para sistemas Permiten gestionar facilmente varios ordenadores, ya que
la informacion almacenada en las directivas del dominio son asumidas por todos
los sistemas cuando se incorporan al dominio al arrancar.
Usuarios Es el modo mas sencillo de gestionar la seguridad de un usuario.
Grupos Cuando el n
umero de usuarios es grande se puede dividir la configuracion
en grupos.
286
r
A.7. EL PROTOCOLO TCP/IP
Hay que tener en cuanta que las directivas se aplican de modo acumulativo. Si un
usuario pertenece a varios grupos para los que se han fijado directivas, el orden de
aplicacion se obtiene seg
un se halla fijado en el cuadro de dialogo directivas de
grupo
A.7.
El protocolo TCP/IP
A.7.1.
Introducci
on
El protocolo TCP/IP nacio de los trabajos del ARPA (Advanced Research Project
Agency)del Departamento de Defensa de los EEUU, durante las decadas de los 60 y
70. A traves de las universidades y centros de investigacion se trato de construir una
red que fuese capaz de resistir las cadas parciales de la misma (por ejemplo en caso
de guerra). As surgio ARPANET, la primera red de intercambio de paquetes.
En 1974 V. Cerf y R. Kahn propusieron un nuevo conjunto de protocolos basicos
de red que solventaban gran parte de los problemas de los protocolos usados en
ARPANET. As se pusieron los cimientos de los protocolos IP (Internet Protocol) y
TCP (Transmission Control Protocol). En 1980 se comenzo la migracion de los aproximadamente 100 servidores que formaban la red ARPANET a los nuevos protocolos.
En 1983 el Departamento de Defensa estandarizo el protocolo TCP/IP como protocolo basico de red. Rapidamente otras agencias del gobierno adoptaron el protocolo,
lo que obligo a las empresas proveedoras de equipos a implementarlo en sus sistemas
operativos y equipos de comunicaciones. Ademas el Departamento de Defensa impulso el protocolo TCP/IP al recomendar a la Universidad de Berkeley la inclusion
del protocolo en la distribucion BSD 4.2 del UNIX.
A.7.2.
El protocolo TCP/IP frente a otros protocolos
El sistema operativo NT da soporte directamente a tres protocolos de red: NETBEUI, usado en las redes de Microsoft e IBM principalmente, IPX/SPX, usado en
las redes Novell Netware y el TCP/IP, parte basica de las redes UNIX, y principal
protocolo de la Internet.
Cada uno de estos protocolos tiene sus propias ventajas e inconvenientes. De un
modo general se recomienda cada uno de estos protocolos:
Netbeui Para compartir ficheros e impresoras en redes sencillas. Para este tipo de
r
287

APENDICE
A. ADMINISTRACION
redes se muestra muy eficaz, dada su practicamente nula necesidad de configuracion. No es encaminable.
IPX/SPX De aplicacion en redes en las que existan servidores Novell Netware. Tiene
un buen rendimiento en ficheros e impresion y poca dificultad de administracion.
TCP/IP Es el que peor rendimiento ofrece para uso en ficheros e impresion, pero es
el que presenta mayores herramientas para crear grandes redes de ordenadores.
Es encaminable y es imprescindible en Internet. Microsoft ha implementado
todas las caractersticas de Netbios dentro del protocolo TCP/IP. Es el que
obliga al mayor esfuerzo administrativo.
A.7.3.
Elementos del protocolo TCP/IP
Una red de ordenadores esta compuesta de dos partes: la red fsica en s y el protocolo que utilizan los ordenadores para comunicarse entre s. La red fsica esta compuesta normalmente de una serie de subredes, a las que se conectan los diferentes
equipos (ordenadores, impresoras...).
Esta red puede tener una topologa muy variada. Actualmente existen dos tipos
de topologas:
Ethernet, que es del tipo bus, Token Ring, que tiene topologa de testigo y utiliza topologa de bus con paso de testigo. El protocolo TCP/IP fue desarrollado
inicialmente para Ethernet , pero admite sin problemas las otras dos tecnologas.
Actualmente se esta imponiendo la tecnologa Ethernet en las redes peque
nas, sobre todo sobre cableado de par trenzado (10 Base T), y por su bajo coste y buen
rendimiento.Normalmente una red tpica estara compuesta por una serie de ordenadores conectados entre s, ademas de impresoras y otros elementos de la red.
Cada ordenador tendra al menos una tarjeta de red. Esta red se puede unir a otras
redes o al resto de la Internet a traves de puentes, encaminadores y otros tipos de
enlaces.
El protocolo TCP/IP permite identificar cada elemento de la red y proporciona
los mecanismos para el intercambio de informacion entre estos elementos.
El protocolo TCP/IP esta formado por un protocolo generico de envo y recepcion
de paquetes, llamado IP por ser el protocolo nativo de Internet (Internet Protocol),
sobre el que se construyen otros protocolos de mayor nivel. El mas importante de
ellos, el protocolo TCP (Transmission Control Protocol), da nombre, junto con el IP,
al protocolo TCP/IP. A su vez estos protocolos pueden incluir subprotocolos dentro
de ellos. Esto se vera claramente en el protocolo TCP.
288
r
Cada paquete enviado a traves de la red tiene un formato especfico. Si usamos

el protocolo Ethernet de transmision, cada paquete esta compuesto de una cabecera
Ethernet y de un campo de datos. La cabecera Ethernet origen y la de destino. Las
direcciones Ethernet estan compuestos por un n
umero de 6 bytes. Este n
umero es
asignado a cada tarjeta de manera u
nica. Cuando dos ordenadores de la red deben
intercambiar paquetes Ethernet, deben escribir la direccion origen y destino en ellos.
Como en una red Ethernet los paquetes viajan por toda la red, las tarjetas de red solo
atienden a aquellos paquetes cuya direccion destino coincide con su direccion Ethernet. Existe un metodo para que una tarjeta enve paquetes a todos los ordenadores.
Este mecanismo es conocido como difusion de paquetes (Broadcast). Cuando la direccion destino son 6 bytes a 0 [cerciorarse si son a 0 o a 255], todas las tarjetas procesan
el paquete. Este mecanismo es usado habitualmente por los protocolos de red para
comunicarse dentro de una red local, pero tiene el inconveniente de que sobrecarga la
re, por lo que debe ser evitado en la medida de lo posible.
Los protocolos token ring y token bus se comportan de modo analogo. El campo
de datos contiene el paquete IP. Cada paquete IP esta compuesto de una cabecera y
un campo de datos.
En el origen del protocolo TCP/IP, el TCP era el protocolo usado, pero luego se
extendio el protocolo IP con nuevos protocolos como son el Protocolo de Control de
Mensajes de Internet (ICMP), los protocolos de resolucion de direcciones directo e
inverso (ARP y RARP) y el protocolo de Datagramas de Usuario (UDP).
A.7.4.
El sistema de direcciones del protocolo IP
A cada servidor de la red TCP/IP se le asigna al menos una direccion IP, que
es un n
umero de 4 octetos. En la red Internet no hay dos ordenadores con el mismo
n
umero IP. En caso de necesidad se pueden asignar mas n
umeros IP a ese ordenador.
Ademas cada direccion IP tiene un nombre asociado. Ese nombre esta formado por el
nombre del servidor, que es u
nico dentro de una subred, y por el nombre del dominio,
que identifica a la subred dentro del conjunto de las subredes de Internet. La forma
de asignar IP, nombres y nombres de dominio en Internet sigue una serie de criterios
que permiten el encaminamiento de los paquetes IP por la red y la traduccion de
nombres de ordenadores en n
umeros IP.
En Internet hay tres tipos de organizaciones de IP:
Organizaciones tipo A El primer octeto del IP es el mismo para toda la organizacion. La organizacion asigna del IP es el mismo para toda la organizacion.
La organizacion asigna al resto de los octetos a cada IP de su organizacion. La
organizacion dispone de direcciones para asignar. Este tipo de organizaciones
r
289

APENDICE
A. ADMINISTRACION
solo se asignan a pases.
Organizaci
on tipo B Los dos primeros octetos del IP estan fijos. La organizacion
dispone de 65536 direcciones IP para asignar. Suelen ser organizaciones de
tama
no medio (universidades, grandes empresas).
Organizaci
on tipo C Se fijan los tres primeros octetos, dejando 256 posibles direcciones.Se utilizan en peque
nos proveedores de servicios Internet (ISP).
Resoluci
on de nombres en el protocolo IP
Cuando dos ordenadores se quieren comunicar mediante el protocolo IP, deben

conocer ambos sus respectivas direcciones IP. Por ejemplo, si se desea conectar desde
un ordenador a otro mediante un cliente del protocolo de transferencia de ficheros
(FTP), debemos suministrar al cliente la direccion IP de destino. Dado que los
n
umeros IP son difciles de recordar, en Internet se dispone de un mecanismo que
permite asociar nombres significativos a cada IP. Por ejemplo, el servidor de FTP de
una organizacion podra llamarse ftp.organizacion, donde organizacion es el nombre
del dominio de dicha organizacion. Se puede emplear el archivo HOSTS de cada servidor para incluir en el una lista de direcciones IP con su nombre correspondiente. De
esta manera se puede proporcionar al cliente FTP el nombre ftp.organizacion como
IP de destino, y el protocolo IP se encarga de obtener el n
umero IP. A este mecanismo
se le llama resolucion de nombres.
Dado que mantener una lista de direcciones IP y nombres es complicado (habra
que duplicar los archivos HOSTS por todos los servidores), en Internet se ha creado un
mecanismo de resolucion de nombres automatico: el Servicio de Nombres de Dominio
(DNS). En cada dominio hay al menos un servidor de nombres de dominio, que
mantiene una lista de todas las direcciones IP del dominio y sus nombres asociados.
Incluso podemos incluir varios nombres para una misma direccion IP (por ejemplo
en los servidores de FTP y WWW de la organizacion residen en el mismo servidor,
podemos incluir los nombres ftp.organizacion y www.organizacion en el servidor de
nombres. Ademas en Internet, los servidores de nombres estan organizados de una
forma jerarquica, de manera que si el nombre buscado no pertenece al dominio del
ordenador, el servidor DNS puede buscar en otros servidores DNS de otros dominios
hasta encontrar el servidor DNS del dominio destino, y de el recuperar la direccion IP
de destino. Este mecanismo es generalmente muy rapido (menor que unos 2 segundos
la b
usqueda con exito y unos 10 o 20 una b
usqueda con resultado negativo), ya que
los servidores DNS poseen mecanismos de cache.
290
r
A.7.5.
El mecanismo de difusi
on (broadcast) en el protocolo
IP
El protocolo IP al igual que el protocolo Ethernet tambien dispone de un mecanismo de difusion (broadcast), que permite enviar paquetes desde un ordenador a todos
los ordenadores de la red. Cada tipo de subred (A,B o C)tiene una mascara de subred
asociada (255.0.0.0 para la A, 255.255.0.0 para la B y 255.255.255.0 para la C) que
determina las direcciones IP que escuharan los paquetes de difusion. El protocolo de
difusion es ampliamente usado por Netbios sobre TCP/IP en la implementacion de
Microsoft, lo que permite emular al protocolo TCP/Ipde Windows el comportamiento
del protocolo Netbeui.
El protocolo de difusion de paquetes tiene dos grandes desventajas: la primera
es que sobrecarga la red. Por ello en las redes basadas en Windows se introduce el
protocolo WINS, que intenta evitar en la medida de lo posible el envo de paquetes de
difusion. La segunda desventaja es que los puentes y encaminadores que comunican
las subredes, si entienden el protocolo IP, no permiten el paso de paquetes de difusion.
A.7.6.
Implementaci
on del protocolo TCP/IP en NT
La implementacion del protocolo TCP/IP en NT persigue dos metas: implementar completamente el protocolo TCP/IP en NT, tanto a nivel de protocolos
(IP,TCP;UDP,etc) como la inclusion de los servicios mas habituales (FTP, TELNET
(Cliente solo), SNMP y otros). Por otro lado permite utilizar el protocolo TCP/IP como u
nico protocolo de la red, ya que los servicios de Netbios sobre TCP/IP permiten
la comparticion de ficheros e impresoras en la red Windows.
La mayor parte de los clientes TCP/IP tienen version para NT. Se esta haciendo
un gran esfuerzo a su vez para dotar a NT de todos los servidores tpicos de Internet.
Hay servidores de dominio p
ublico de FTP, DNS, Gopher, TELNET, SMTP, POP3
Y WEB, aparte de las propias incluidas en el NT Server. ademas existen versiones
comerciales de dichos servidores, normalmente mas potentes y seguras.
A.7.7.
Configuraci
on del protocolo TCP/IP en NT
Antes de proceder a la instalacion del protocolo TCP/IP en NT hay que averiguar

una serie de parametros, que deben ser suministrados por el administrador de la red.
Si en la red ademas existe un servidor DHCP probablemente no sea necesario conocer
ning
un parametro, ya que el protocolo se configurara automaticamente. Para a
nadir el
protocolo TCP/IP se pulsa el boton Agregar software dentro del cuadro de dialogo
r
291

APENDICE
A. ADMINISTRACION
Red del Panel de Control (ver figura A.14).
Figura A.14: Panel de control. Red
En NT 3.51 debemos elegir la opcion Protocolo TCP/IP y elementos relacionados. En estecuadro de dialogo nos aparecen las opciones que se pueden instalar. En
Nt 4.0 se elige en Panel decontrol\Red\Protocolos\Agregar el Protocolo TCP/IP y
elementos relacionados. Figura A.15.
En este cuadro se pueden se
nalar las opciones a instalar. Las mas comunes son
las utilidades de conectividad (clientes ftp, telnet, finger, etc.), y son basicamente las
u
nicas necesarias. En este cuadro de dialogo tambien se puede seleccionar la configuracion automatica va el protocolo DHCP. En NT 4.0 el cuadro de dialogo se ha
modificado de manera que ahora la configuracion del protocolo TCP/IP esta organizada por bloques funcionales. En el caso de configuracion manual debemos conocer
una serie de parametros. El primero es la direccion IP del ordenador. En NT se puede
asignar una direccion IP a cada adaptador de red instalado, e incluso a un mismo
adaptador se le pueden asignar varias direcciones IP. Esto u
ltimo se usa en Internet
para crear servidores virtuales. Luego se debe incluir una de las tres mascaras de
subred posibles, para redes de tipo A, B o C. Si la red en la que se halla conectado
el ordenador esta conectada con otras redes va una pasarela (gateway), que puede
292
r
Figura A.15: Panel de control. Red. Protocolos. Agregar protocolo TCP/IP
ser un puente o encaminador, hay que incluir su direccion en la casilla para puerta
de enlace.
Si en la red hay servidores WINS, podemos incluir la direccion de un servidor
WINS primario y otro secundario.
Si en la red hay un servidor DNS (obligatorio en las redes conectadas a Internet)
podemos completar las opciones de DNS.
Como nombre de host, NT por defecto usa el de Windows, pero debera coincidir
con el que se le ha asignado en el servidor de nombres. En la lista Orden de b
usqueda
del servicio de nombres de dominio debemos proporcionar una lista con las direcciones IP de los servidores de nombres que debe usar. Se pueden incluir servidores
de nuestra red y de otras, aunque suelen ser mas lentos. Debemos a
nadir a la casilla
nombre de dominio el nombre de dominio de la subred local. Si no se proporciona
un dominio, el protocolo TCP/IP usa por defecto el dominio local.
Podemos a
nadir otros dominios para que se usen por defecto, a
nadiendo entradas
a la lista orden de b
usqueda del sufijo de dominio.
Se pueden configurar varias opciones avanzadas para cada adaptador de red o pulsando el boton avanzadas del cuadro de dialogo Configuraci
on de TCP/IP,
en la seccion Direccion IP (ver figura A.16).
Tambien se puede activar el protocolo PPTP (Point to Point Tunneling Protocol)
r
293

APENDICE
A. ADMINISTRACION
Figura A.16: Protocolo TCP/IP, Direccion IP, Avanzado
que es el Protocolo de T
unel Punto a Punto. Este protocolo permite construir redes
privadas seguras dentro de redes de transmision p
ublicas, siendo capaz de encapsular
los diferentes protocolos de red empleados en NT, como son NETBEUI, TCP/IP y
IPX/SPX. Este protocolo utiliza cifrado de los paquetes, y algoritmos de clave p
ublica
que hacen muy difcil examinar los paquetes enviados a traves de una red como puede
ser Internet. En este cuadro se pueden:
Asignar m
ultiples direcciones IP a un mismo adaptador. Esto se usa cuando
un mismo adaptador de red debe poseer varias direcciones IP. En Internet es
muy com
un el asignar m
ultiples direcciones IP a un adaptador. El mejor uso
de este mecanismo consiste en reservar una direccion IP y un nombre de ordenador para cada servicio Internet que se instale en el servidor. Si por ejemplo
se planea instalar un servidor FTP y un servidor WWW sobre el servidor, se
deben reservar dos direcciones separadas de la principal del servido, e instalar
cada uno de los servicios en cada direccion. De esta manera es muy facil llevarse
294
r
todo es servicio a un nuevo servidor cuando por sobrecarga del servidor no se

puede hacer frente a las solicitudes efectuadas por los clientes de este servicio.
A
nadir nuevas pasarelas o puertas de enlace para ese adaptador. Ver figura
A.17.
Figura A.17: Protocolo TCP/IP, Direccion IP, Avanzadas
Activar el agente de Proxy WINS, para lo cual la red debe disponer de servidor
WINS. Un agente de proxy WINS es un equipo que permite que otros equipos
que no estan configurados para acceder a un servidor WINS puedan acceder a
los nombres contenidos en ese servidor WINS. Normalmente esta situacion se da
cuando el servidor WINS esta en una red remota, por lo que los equipos de la red
local que no tienen activado el cliente WINS no pueden acceder a los nombres
registrados en ese servidor. Al activar el proxy WINS las peticiones de b
usqueda
y registro de nombres Windows realizadas en modo local (va broadcast) son
atendidas y redirigidas sobre el servidor WINS por el servidor proxy WINS.
Configurar los parametros de red de Windows, que funcionan con el protocolo
Netbios sobre TCP/IP. El archivo En NT 4.0 se ha introducido el agente Rele de
DHCP. Normalmente el protocolo DHCP funciona sobre una red local, ya que
se trabaja siempre en modo de difusion de paquetes (broadcast). En este modo
los paquetes no pueden saltar los encaminadores, salvo que estos soporten el
protocolo de reenvo de paquetes BOOTP. Si es necesario que en una red se
tenga acceso a un servidor DHCP remoto, se puede instalar un rele DHCP,
que es un servicio que se conecta con un servidor DHCP remoto para realizar la
configuracion dinamica en la red local. Se pueden a
nadir en el cuadro de dialogo
de Rele DHCP varios servidores DHCP, as como configurar los parametros de
funcionamiento del rele.
r
295

APENDICE
A. ADMINISTRACION
En el cuadro de dialogo de Enrutamiento (encaminamiento) se puede activar
el encaminamiento IP, si se disponen de 2 o mas direcciones IP en el ordenador. Esta
situacion es habitual cuando se disponen de dos tarjetas de red, cada una conectada
a una red fsica diferente. Ver figura A.18.
Figura A.18: Protocolo TCP/IP, Enrutamiento
296
r
Bibliografa
[ANDRE] Andrews, Mark. Aprenda Visual C++ Ya. McGraw-Hill, 1999.
[BARBA] Barba Mir, C. A prop
osito del est
andar DICOM 3.0. Hospital Clnico
Universitario Lozano Blesa (Zaragoza).
http://www.hcu-lblesa.es/mane/noticia/didcom3.htm
[BATE] Bates, Jon. & Tompkins, Tim. Microsoft Visual C++ 6. 2000, Prentice
Hall.
s. & Sancho ,Adela. Comunicaciones y Bases de
[BOBA00] Bobadilla, Jesu
datos con Java a traves de ejemplos. 2003, Ra-Ma
s. Java a traves de ejemplos. 2003, Ra-Ma
[BOBA01] Bobadilla, Jesu
s, A. &
[CASCA] Cascales, B. & Lucas, P. & Mira, JM. & Pallare
A
Sanchez-Pedreno, S. LTEXuna imprenta en sus manos. 2000, ADI

[CEBAL99] Ceballos, F. Javier. Visual C++. Aplicaciones para Win32. RAMA, 1999. ISBN: 84-7897-350-8
[CEBAL00] Ceballos, F. Javier. Visual C++. Programaci
on avanzada en Win32.
RA-MA, 1999. ISBN: 84-7897-344-3
[DICOM] DICOM Standard . School of Psychology, University of Nottingham, University Park, Nottingham, NG7 2RD, UK,2003.
http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html
[ENCRI] Encriptacion en Java.
http://www3.uji.es/~vcholvi/teaching/java/cap.12.1/Cap.12.1.html
[GUNT] Gunter, D. & Burnett, S. Gua de integraci
on de Windows NT y Unix.
McGraw-Hill, 1998.
[HORI] Hori, S. & Prior, F. & Dean Bidgood, W. & Parisot, C. & Claeys,
G. DICOM: An introduction to the standard.
http://www.dicomanalyser.co.uk/html/introduction.htm
297
BIBLIOGRAFIA
[JDK] API 1.4.1 .

http://java.sun.com/j2se/1.4.1/docs/api/
[KRUG] Krugglinski, David J. & Shepher, G. & Wingo, S. Programaci
on
avanzada con Microsoft Visual C++. 2002, McGraw-Hill
[KURA] Offis Dicom. Kuratorium OFFIS e.V, 2003.
http://dicom.offis.de/index.php.en
[LEBLA] LeBlanc, Dee-Ann. Administraci
on de sistemas Linux (La Biblia). 2000,
Anaya
[LEMA] Lemay, Laura. & L. Perkins, Charles. Aprendiendo Java 1.1 en 21
das. 1997, Prentice Hall
[NEMA] DICOM . NEMA, Suite 1847, 2003.
http://medical.nema.org/
[PAJ] Pajares, G. & de la Cruz, JM. & Molina, JM. & Cuadrado, J. &
pez, A. Imagenes Digitales. Procesamiento pr
Lo
actico con Java. 2003, Ra-Ma
[PASCU00] Pascual, J. & Charte, F. & J. Segarra, M. & De Antonio, A.
& A. Clavijo, J. Programaci
on avanzada en Windows 2000 con Visual C++
y MFC. 2000, McGraw-Hill ISBN: 84-481-2532-0
[REVET97] Revet, B. DICOM Cook Book for implementation in Modalities.
Philips Medical Systems, Version 1.1., 1997.
ftp://ftp-wjq.philips.com/medical/interoperability/out/DICOM_
Information/CookBook.pdf
ftp://ftp.philips.com/pub/ms/dicom/DICOM_Information/CookBook.pdf
[RUSSE97] Russel, C. & Crawford, S. Gua completa de Microsoft Windows
NT 4.0 Server. McGraw-Hill, 1997. ISBN: 1-57231-333-1
[SOFT] SoftLink . SoftLink, 2002.
http://www.softlink.be/
[STIN] Stinson, C. & Siechert, C. Running Microsoft Windows 2000 Profesional.
2000, McGraw-Hill
[TIANI] Tiani Pacs. JDicom: JavaTM DICOM Tools,2003.
http://www.tiani.com/JDicom/
[TJAND99] Tjandra, D. & Wong, S. A Digital Library for Biomedical Imaging
on the Internet. IEEE Communications Magazine, 1999.
http://www.comsoc.org/pubs/free/private/1999/jan/Tjandra.html
298
r

DICOM gestión imágenes

Cargado por

Información del documento

Descripción original:

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DICOM gestión imágenes

Cargado por

Copyright:

Formatos disponibles

Desarrollo de aplicaciones DICOM para la gestion

Fernando Ballesteros Herranz

En los momentos de crisis, s

Dedicado a mis padres Juli y Heliodoro, mi ta Encarni, mi hermana Helena y

Agradecer a Carlos Platero, Roberto Gonzalez y Miguel Angel

El estandar DICOM (Digital Imaging and Communications in Medicine) nacio en

The standard DICOM (Digital Imaging and Communications in Medicine) was

1.1. Marco del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2. Objetivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3. Sumario del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2. Librera de Imagenes Medicas . . . . . . . . . . . . . . . . . . . . . .

2.2.1. Libreras de Imagenes Medicas . . . . . . . . . . . . . . . . . .

2.2.2. Arquitecturas para libreras digitales de imagenes . . . . . . .

2.3. Estandar DICOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.2. Historia de DICOM . . . . . . . . . . . . . . . . . . . . . . . .

2.3.3. Procesamiento Distribuido . . . . . . . . . . . . . . . . . . . .

2.3.4. Conceptos generales de DICOM . . . . . . . . . . . . . . . . .

2.3.5. Conceptos de DICOM Network . . . . . . . . . . . . . . . . .

2.3.6. Clases de Servicio soportados . . . . . . . . . . . . . . . . . .

Fernando Ballesteros Herranz

2.3.8. Estandar DICOM . . . . . . . . . . . . . . . . . . . . . . . . .

2.3.9. Instancias SOP de imagenes DICOM . . . . . . . . . . . . . .

2.3.10. Modelo de informacion de las imagenes . . . . . . . . . . . . .

2.3.11. Instancias imagen SOP . . . . . . . . . . . . . . . . . . . . . .

2.3.12. Relaciones e indentificacion . . . . . . . . . . . . . . . . . . .

2.3.13. Clasificacion de los datos de imagen . . . . . . . . . . . . . . .

2.3.14. Extension de la informacion . . . . . . . . . . . . . . . . . . .

2.3.15. Tipos de imagenes . . . . . . . . . . . . . . . . . . . . . . . .

2.3.16. Procesando imagen . . . . . . . . . . . . . . . . . . . . . . . .

2.3.17. Aplicacion de los Datos de las Imagenes . . . . . . . . . . . .

2.3.18. El futuro de DICOM . . . . . . . . . . . . . . . . . . . . . . .

3. Libreras DCMTK de Offis

3.2. Estandarizacion de la Comunicacion de Imagenes Medicas . . . . . .

3.3. Descripcion de DICOM seg

3.3.1. Estructura de los datos en el estandar DICOM . . . . . . . . .

3.3.2. Servicios de Red . . . . . . . . . . . . . . . . . . . . . . . . .

3.3.3. Intercambio de medios de comunicacion . . . . . . . . . . . . .

3.3.4. Declaracion de Conformidad . . . . . . . . . . . . . . . . . . .

3.4. Libreras DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fernando Ballesteros Herranz

3.4.1. Instalacion de libreras . . . . . . . . . . . . . . . . . . . . . .

4.2. Instalacion de la JVM . . . . . . . . . . . . . . . . . . . . . . . . . .

4.3. El compilador de Java . . . . . . . . . . . . . . . . . . . . . . . . . .

4.4. Variables y tipos de datos . . . . . . . . . . . . . . . . . . . . . . . .

4.4.3. Palabras clave reservadas . . . . . . . . . . . . . . . . . . . . .

4.4.5. Matrices o vectores . . . . . . . . . . . . . . . . . . . . . . . .

4.5.1. Operadores aritmeticos . . . . . . . . . . . . . . . . . . . . . .

4.5.2. Operadores de asignacion

4.5.3. Operadores a nivel de bit . . . . . . . . . . . . . . . . . . . . . 100

Fernando Ballesteros Herranz

4.6.1. Instruccion condicional if-else . . . . . . . . . . . . . . . . . . 101

Fernando Ballesteros Herranz

4.9.3. Conversion a String . . . . . . . . . . . . . . . . . . . . . . . . 115

Fernando Ballesteros Herranz

4.13.3. OutputStream . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

5. Estudio de libreras JDT

5.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Fernando Ballesteros Herranz

5.2. Terminologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Fernando Ballesteros Herranz

5.9. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177