desarrollo de aplicaciones dicom para la gestión de ... · dedicado a mis padres juli y heliodoro,...

Desarrollo de aplicaciones DICOM para la gestionde imagenes biomedicas

Fernando Ballesteros Herranz

Octubre 2003

“En los momentos de crisis, solo la imaginacion es mas importante que elconocimiento”

(Albert Einstein)“Lo unico 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

dıa, y cuando el sol brilla, brilla mas radiante aun”(SamSagaz Gamyi)

Dedicado a mis padres Juli y Heliodoro, mi tıa Encarni, mi hermana Helena yespecialmente a mi novia Araceli por todo el apoyo y la ayuda que me ha prestadoen la realizacion de este proyecto durante este largo tiempo.

Tambien lo dedico a mis companeros de proyecto, Ricardo, David, Marta, Ivan,Jose, Bakali, Thomas, Wouter y Jeroen con los que tanto momentos buenos he pasadoy a un companero de fatigas a lo largo de toda la carrera, Pedro Luıs.

Agradecer a Carlos Platero, Roberto Gonzalez y Miguel Angel Sanchez-Uran laconfianza depositada en mı y la guıa que han sido para mı en la realizacion de esteproyecto y la posibilidad que me han dado de poder aprender.

Resumen

El estandar DICOM (Digital Imaging and Communications in Medicine) nacio enel ano 1993, a partir de un redisenado completo de la publicacion normalizada No33-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 archivosDICOM, que son imagenes biomedicas con un informe cada uno del estudio realizado.

Se ha realizado una aplicacion basandonos en el estandar, que permita compartirarchivos en un entorno distribuido; dicho de otra manera, una aplicacion que permitaa los clientes visualizar, mandar y recibir los archivos contenidos de un servidor.

El presente trabajo, describe un sistema multiplataforma desarrollado para elmanejo, procesamiento y auditorıa de Imagenes de Diagnostico Medico a traves deredes (Intra o Internet). El sistema esta basado en un diseno Cliente/Servidor ori-entado a objetos, para el cual se utilizo como lenguaje de programacion JAVA, y serealizo de acuerdo a la norma DICOM 3.0.

Para la realizacion de la aplicacion se ha trabajado con librerıas JDT (Java DicomToolkit), con las librerıas JDK 1.4.1., en el entorno JBuilder Enterprise 7. Ha sidodesarrollada enteramente en JAVA y puede ser utilizable en cualquier sistema opera-tivo.

Como parte del proyecto fin de carrera, tambien se han realizado las tareas deadministracion de sistemas (Windows NT, 2000 y Linux) y mantenimiento del servidorWeb Apache (www.elai.upm.es) del departamento.

http://www.elai.upm.es

Abstract

The standard DICOM (Digital Imaging and Communications in Medicine) wasborn in the year 1993, from complete re-designed of the normalized publication No33-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 offiles 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 sharefiles in a distributed environment; said otherwise, an application that it allows theclients 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 wasused as language of programming JAVA, and were realized in agreement to the normDICOM 3.0.

For the accomplishment of the application one has worked with libraries JDT (JavaDicom Toolkit), with the libraries JDK 1.4.1., in the environment JBuilder Enterprise7. 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 (WindowsNT, 2000 and Linux) and the maintenance of the department Apache Web server(www.elai.upm.es).


Indice general

1. Introduccion 1

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

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

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

2. El Estado de la tecnica 5

2.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2. Librerıa de Imagenes Medicas . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1. Librerıas de Imagenes Medicas . . . . . . . . . . . . . . . . . . 7

2.2.2. Arquitecturas para librerıas 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

i

INDICE GENERAL Fernando Ballesteros Herranz

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. Librerıas DCMTK de Offis 77

3.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

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

3.3. Descripcion de DICOM segun 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. Librerıas DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

ii GVA-ELAI-UPM r©PFC0075-2003

Fernando Ballesteros Herranz INDICE GENERAL

3.4.1. Instalacion de librerıas . . . . . . . . . . . . . . . . . . . . . . 81

3.4.2. Dcmnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.4.3. Dcmjpeg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.4.4. DicomScope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

3.5. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4. Programacion 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

GVA-ELAI-UPM r©PFC0075-2003 iii


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 GVA-ELAI-UPM r©PFC0075-2003


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

GVA-ELAI-UPM r©PFC0075-2003 v


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 menu . . . . . . . . . . . . . . . . . . . . . . 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 librerıas JDT 151

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

vi GVA-ELAI-UPM r©PFC0075-2003


5.2. Terminologıa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . 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. Guıa 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

GVA-ELAI-UPM r©PFC0075-2003 vii


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

6. Desarrollo de aplicacion 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. Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . 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 GVA-ELAI-UPM r©PFC0075-2003


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. Administracion 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

GVA-ELAI-UPM r©PFC0075-2003 ix


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

x GVA-ELAI-UPM r©PFC0075-2003


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

GVA-ELAI-UPM r©PFC0075-2003 xi

Indice de figuras

2.1. Clasificacion de las imagenes medicas . . . . . . . . . . . . . . . . . . 7

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 Fernando Ballesteros Herranz

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. Librerıas DCMTK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

3.2. Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

3.3. Archivo de configuracion de DicomScope . . . . . . . . . . . . . . . . 87

3.4. Viewer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

xiv GVA-ELAI-UPM r©PFC0075-2003

Fernando Ballesteros Herranz 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. Jerarquıa 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

GVA-ELAI-UPM r©PFC0075-2003 xv


6.7. Asistente para proyectos . . . . . . . . . . . . . . . . . . . . . . . . . 191

6.8. Galerıa de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

6.9. Asistente para aplicaciones . . . . . . . . . . . . . . . . . . . . . . . . 193

6.10. Vista en diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

6.11. contentPane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195

6.12. Editor de texto ejecutado . . . . . . . . . . . . . . . . . . . . . . . . 196

6.13. Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 envıa 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 GVA-ELAI-UPM r©PFC0075-2003

Fernando Ballesteros Herranz 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 anadir 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

GVA-ELAI-UPM r©PFC0075-2003 xvii


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 GVA-ELAI-UPM r©PFC0075-2003

Capıtulo 1

Introduccion

DICOM1 es un estandar en comunicacion e imagenes en medicina, que facilita elmanejo de informacion medica entre hospitales y centros de investigacion.

La gran importancia de este estandar es que da la posibilidad de interconectarsistemas informaticos de diferentes fabricantes y hace posible la comunicacion entreellos; en un hospital donde los aparatos medicos son de muchas marcas diferentesdebido a la especializacion.

DICOM hace posible que los archivos medicos puedan viajar de forma segura entrehospitales, centros de investigacion y departamentos. Luego esa informacion puede servista remotamente para que los medicos puedan diagnosticar desde su casa y buscardiferentes opiniones de otros expertos de una forma rapida y sencilla.

La creciente utilizacion de sistemas de adquisicion y tratamiento digital de imagenesmedicas ha hecho necesaria la adopcion de un estandar que posibilite el intercambiode estas. Las imagenes medicas son muy importantes para los diagnosticos de pa-cientes, tratamientos terapeuticos y evaluacion de resultados. Gracias a las nuevastecnicas de imagenes digitales, tales como la topografıa computarizada, angiografıapor sustraccion digital, resonancia magnetica y ası sucesivamente, han reducido lasdosis de radiacion a los pacientes y los cortes anatomicos.

DICOM poco a poco se esta introduciendo en todo el ambito sanitario, y que sinduda facilitara el manejo de la informacion medica.

Los objetivos del estandar son:

Lograr una interfaz comun para todos los dispositivos de imagenes (tomografıa,

1Digital Imaging and Communications in Medicine

1

CAPITULO 1. INTRODUCCION Fernando Ballesteros Herranz

resonancia magnetica, ultrasonido, rayos x, etc.)

Intentar desligar Dicom de las instituciones que lo desarrollan para que real-mente pueda ser un estandar independiente.

Dicom 3.0 debe ser aplicable a toda la esfera de las imagenes medicas, desde sutransmision 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 efi-ciente y que soporte una amplia variedad de tecnologıas de red basadas ennormas OSI, CSMA/CD, ATM, X.25, etc. Y TCP/IP como protocolo de trans-porte, que es abierto y compatible con las redes que se estan instalando en loscentros sanitarios.

Los estandares de codificacion de la informacion y los datos resultantes de uti-lizar los Objetos de Informacion (imagenes, informes, etc.) con las Clases deServicio (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 transmi-tida 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 librerıas DCMTK2

en tercer lugar, estudio de librerıas JDT3

y en cuarto lugar, desarrollo de la aplicacion.

El presente trabajo ha sido realizado en etapas, la primera de las cuales consistio enel estudio de la norma DICOM 3.0, base fundamental de este trabajo.

2DICOM Toolkit3Java DICOM Toolkit

2 GVA-ELAI-UPM r©PFC0075-2003

Fernando Ballesteros Herranz 1.2. OBJETIVOS DEL PROYECTO

La siguiente etapa fue el estudio y prueba de las librerıas DCMTK desarrolladasen C++ y de las cuales se vieron aplicaciones como DicomScope o la conectividadentre dos maquinas.

Luego se estudio el Toolkit de Java, y paralelamente este lenguaje de programacionorientado a objetos.

Una vez visto que las librerıas JDT son las que mas nos interesaron, se llevo acabo la implementacion de nuestra aplicacion.

La aplicacion que se ha creado esta desarrollada en lenguaje Java,con la her-ramienta JBuilder Enterprise 7 y el editor TextPad, bajo plataforma Intel y sistemaoperativo Windows 2000.

Tambien se han estado haciendo labores de mantenimiento de la red del laboratoriodel Grupo de Vision Artificial(GVA) del Departamento de Electronica, Automaticae Informatica Industrial y la web (www.elai.upm.es) del departamento.

Cabe resenar, que tratandose de un proyecto realizado en el ambito de la investi-gacion, la mejor forma ha sido escribirlo en formato LATEX.

1.2. Objetivos del proyecto

Este proyecto trata de ser una guıa 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 serıa mas util para eldesarrollo de una aplicacion final, en la que los principales servicios que proporcionael estandar puedan ser operativos y utilizables para la medicina del nuevo siglo, yaque DICOM ha tenido un importante avance en el ultimo ano.

1.3. Sumario del proyecto

Este proyecto se encuentra dividido por capıtulos y apendices que pretendenmostrar los trabajos y conocimientos adquiridos durante el ano de trabajo.

De esta forma, en el capıtulo 2 se desarrolla la base teorica del estandar DICOM,y es parte fundamental para la comprension del trabajo realizado y desarrollo de lasaplicaciones, es posible que requiera mas de una lectura para entender el estandar.

GVA-ELAI-UPM r©PFC0075-2003 3


CAPITULO 1. INTRODUCCION Fernando Ballesteros Herranz

En el capıtulo 3, se explica la instalacion y utilizacion de las librerıas de C++proporcionadas por OffisDicom, ası como una pequena aplicacion realizada con ellas,para la transmision de objetos Dicom por la red. Tambien se describe, la utilizacion deuna aplicacion desarrollada parte en Java parte con las librerıas de C++. Esta apli-cacion es el DicomScope, y se explica el funcionamiento de cada parte del programay la transmision de estudios por red.

El 4 es una guıa para aprender a programar en Java, tanto conceptos sencilloscomo los mas complicados como los hilos, los sockets y la encriptacion. Este capıtuloes fundamental para entender los siguientes capıtulos ya que el programa y las librerıasutilizadas estan desarrollas en Java.

El estudio de las librerıas JDT y las funciones que implementan del estandarDicom estan explicadas en el capıtulo 5.

Finalmente en el capıtulo 6, se explica el camino seguido y la forma de uso delprograma desarrollado en java y utilizando las librerıas JDT ası como las conclusionesfinales.

El apendice A pretende ser una pequena guıa para la administracion de sistemasWindows de Red, basada en la experiencia a lo largo del proyecto.


Capıtulo 2

El Estado de la tecnica

2.1. Introduccion

En este capıtulo se hace una introduccion a los conceptos y el estado actual en elque se encuentran:

Imagenes medicas distribuidas

Estandar DICOM

La primera parte es la relativa a la distribucion de imagenes medicas donde severa el estado en el que se encuentran las tecnicas de distribucion de imagenes, prin-cipalmente a traves de Internet, como las librerıas digitales de imagenes medicas.

En la segunda parte se van a explicar los conceptos definidos en el estandarDICOM, partiendo de un modelo de proceso distribuido.

Finalmente, se llegara a la explicacion de los conceptos de DICOM Network, pararealizar la conectividad entre las maquinas y la explicacion de los servicios que elestandar ofrece.

5

CAPITULO 2. EL ESTADO DE LA TECNICA Fernando Ballesteros Herranz

2.2. Librerıa de Imagenes Medicas

[BOBA00] [TJAND99]

Los sistemas tradicionales de gestion de imagenes medicas, tales como los sis-temas de visualizacion y de archivo y comunicacion, estan basados en estaciones detrabajo especializadas y sistemas de arquitectura cerrada. La tecnologıa de Internetesta siendo explorada para la distribucion eficiente y rentable de imagenes medicas.

Las imagenes medicas son el corazon de los diagnosticos de pacientes, tratamientosterapeuticos, planificacion quirurgica, muestreo de enfermedades, y a largo plazo pararepetir evaluaciones de resultados. En las pasadas tres decadas, ha habido tremen-dos cambios con la llegada de nuevas tecnicas como la tomografıa computarizada(CT), resonancia magnetica (MRI), resonancia espectroscopica (MRS), resonanciamagnetica funcional (fMRI), angiografıa por sustraccion digital (DSA), tomografıapor emision de positrones (PET), magnetic source imagin (MSI), y ası sucesivamente.

Estas modalidades de imagenes digitales, que actualmente constituyen alrededordel 30 por ciento de los analisis de imagenes medicas en los Estados Unidos, hanrevolucionado la manera de adquirir imagenes de pacientes. Han proporcionado unmetodo no invasivo para ver cortes transversales anatomicos y estados fisiologicos, yhan reducido la dosis de radiacion a los pacientes y los traumas de reconocimiento. Elotro 70 por ciento de analisis de imagenes de craneo, torax, pecho, abdomen, y huesoestan hechas en los convencionales rayos X o radiografıa digital (CR). Diferentes tiposde pelıculas digitalizadoras, como los escaner, camaras de estado solido, escaner detambor (drum scanner) y vıdeo camaras, se usan rutinariamente para convertir laspelıculas 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 medicasconforme al contenido anatomico (estructural) o fisiologico (funcional) de las imagenesgeneradas. Cada una de estas modalidades de imagen proporciona una funcion ycaracterısticas unicas que no pueden ser reemplazadas por las otras modalidades. Ladimension de una imagen digital se encuentra entre 128 x 128 pixels (p.e., PET ytomografıa computarizada por emision de fotones simples –SPECT– de modalidadesde medicina nuclear) y 4000 x 5000 pixels (p.e., mamografıa).

Estos avances en la tecnologıa de la imagen van a continuar. Sin embargo, la reor-ganizacion y rediseno de los sistemas de sanidad esta cambiando el foco de la imagendigital de la generacion y adquisicion de imagenes al post-tratamiento y gestion dedatos de imagen. El motivo de este cambio es para poder obtener el mayor beneficioposible de los datos que ya existen. Los nuevos cambios principales de la proximadecada se centraran en la recogida, archivo, indexado, comunicacion y gestion delos datos de imagenes multimedia para una mejor rentabilidad en educacion medica,investigacion clınica y diagnostico.


Fernando Ballesteros Herranz 2.2. LIBRERIA DE IMAGENES MEDICAS

Figura 2.1: Clasificacion de las imagenes medicas

Los FS-PACS (full-scale Picture Archiving and Communication Systems), tam-bien llamados en castellano “sistemas de archivo y comunicacion de imagenes a granescala”, son el metodo predominante para la gestion de informacion de imagenes enlos hospitales. Un FS-PACS consiste en una integracion de PACS, en informacionadministrativa dependiente del Servicio de Radiologıa (en ingles, Radiology Infor-mation System –RIS–) e informacion del hospital (en ingles, Hospital InformationSystem –HIS–). Los FS-PACS de un hospital de tamano medio (alrededor de 600-800camas) podrıan requerir 1 Terabyte de datos digitales por ano en su librerıa o archivode imagenes. Desde 1995 ha habido mas de 50 instalaciones de FS-PACS en todo elmundo, con cientos de PACS y aun mas mini-PACS en el funcionamiento cotidiano.Los PACS estan disenados para revisiones diagnosticas por radiologos y cardiologos,pero estos sistemas tampoco estan disenados para funcionar correctamente en unadistribucion de imagenes medicas, esto es, comunicando imagenes medicas y datosrelacionados a otros especialistas como medicos e investigadores. Un sistema abiertocon mecanismos omnipresentes de acceso seguros podrıa permitir a los usuarios uti-lizar completamente la funcionabilidad de la librerıa digital de imagenes medicas demanera rentable. Las tecnologıas de Internet y la red mundial WWW proporcionanuna plataforma ideal para el desarrollo de librerıas de imagenes medicas.

2.2.1. Librerıas de Imagenes Medicas

Cuando se disena, gestiona y utiliza una librerıa digital de imagenes medicas enInternet hay que tener en cuenta una serie de puntos que se presentan a continuacion.



Datos centralizados o datos distribuidos

La decision de adoptar una base de datos centralizada frente a una arquitecturade objetos distribuidos esta basada en varias consideraciones, como el tamano de labase de datos, datos localizados o distribuidos, el numero de usuarios, y los serviciosrequeridos.

La arquitectura de los PACS estandar esta basada en el modelo de base de datoscentralizada, y esto tambien se aplica a otros sistemas integrados de sanidad, talescomo el Registro Computerizado de Pacientes (en ingles, computerized patient record–CPR–) y el HIS. Incluso los mas recientes desarrollos de los FS-PACS todavıa consol-idan informacion en un gran registro centralizado. En general, los PACS son sistemascerrados, facilitando servicios a un numero limitado de estaciones de trabajo, confrecuencia a traves de conexiones de alta velocidad tales como ATM (AsynchronousTransfer Mode) o Ethernet de 100 Mb/s. Los usuarios necesitan acceso instantaneoa imagenes de alta resolucion para revision de diagnosticos y revisiones clınicas.

A diferencia, una librerıa de imagenes medicas basada en Internet puede necesi-tar soportar un gran numero de peticiones. La informacion puede ser distribuida atraves de diferentes departamentos y hospitales, o incluso para revisiones externas yconsultas privadas.

La arquitectura de objetos distribuidos es mas apropiada para gestionar tales en-tornos de informacion heterogeneos y distribuidos. El modelado de datos es separadode los clientes, y la logica comercial es desempenada en los servidores medios. El sis-tema distribuido puede aumentar proporcionalmente a un gran numero de usuarios,ofreciendo un funcionamiento y fiabilidad mejorados, y aplicando coherencia a losdatos. Un punto a tener en cuenta con los objetos distribuidos es el coste y comple-jidad adicional cuando se anaden servidores medios.

Servidor de imagenes basado en PACS o basado en Internet

Los controladores de PACS son programas de aplicacion del servidor disenadospara acceso rapido desde las imagenes archivadas hasta las estaciones especializadasde visualizacion para lectura de diagnosticos. La practica comun para facilitar accesoa traves de Internet a los archivos de imagenes en PACS es a traves de un servidorHTTP configurado para comunicarse con los controladores de PACS. El usuario envıapeticiones al servidor, el cual en turnos pregunta al controlador de PACS por elconjunto de imagenes correspondientes. Los controladores de PACS, sin embargo, noestan disenados para procesar un gran numero de solicitudes. La carga de trabajoextra generada por el servidor HTTP degrada el funcionamiento en conjunto de loscontroladores de PACS.



Otro tema relativo al acceso a las imagenes en PACS a traves de Internet es elsoporte del navegador para la resolucion de imagenes medicas. Las imagenes medicasson almacenadas como imagenes en escala de grises, con resoluciones entre 12 y 16bits/pixel. Las estaciones de trabajo de visualizacion estan especıficamente disenadaspara visionar imagenes de alta resolucion. Por el contrario, los navegadores de Inter-net corren en monitores que no soportan mas 256 niveles de escala de grises. Parasolucionar este problema, un modulo de aplicacion muestrea las imagenes en PACS auna resolucion menor para visionarlas en los navegadores. La adiccion de tal modulode aplicacion hace que el diseno y integracion de los PACS sea mas difıcil, y reduceen conjunto el funcionamiento del sistema.

En resumen, un controlador de PACS esta disenado para un acceso a imagenrapido para un numero reducido de usuarios (p.e., radiologos y cardiologos). Por elcontrario, un servidor de Internet puede manipular un gran numero de peticiones,debido a su naturaleza deslocalizada. Por lo tanto, la librerıa digital de imagenesmedicas basada en Internet deberıa ser disenada con el servidor de Internet comocomponente principal y central, antes que modulos de aplicacion centralizados en loscontroladores de PACS.

Grandes clientes o pequenos clientes

El visionado de imagenes en PACS requiere costosas estaciones de trabajo hechasa medida, configuradas con multiples monitores de alta resolucion, de 1000 x 1500a 4000 x 4000 pixels de resolucion. Los programas de aplicacion estan desarrolladosespecıficamente para correr en tales estaciones de trabajo. Como las estaciones detrabajo son anadidas o modificadas, la instalacion, integracion y las actualizacionesde software son gastos costosos que hay que considerar. A veces, las estaciones detrabajo pueden necesitar ser redisenadas para soportar una nueva operatividad.

Por otra parte, los navegadores de Internet pueden funcionar en ordenadores per-sonales relativamente economicos. Los documentos hypermedia y las imagenes sonalmacenadas en servidores. En el nivel mas sencillo, los documentos son textos planoscon hyperlinks incrustados a imagenes y otros recursos. Con la llegada de lenguajesde programacion basados en Internet, tales como Java, los navegadores tienen may-or grado de operatividad. Las nuevas caracterısticas son anadidas a una localizacioncentralizada, resultando en menos costos y mantenimiento mas facil. Los navegadoresde Internet tambien permiten acceso omnipresente a imagenes medicas a traves deplataformas de multiples clientes, mientras se mantiene un interface de usuario medi-anamente coherente. Sin embargo, la baja resolucion de las imagenes y la capacidadpara mostrar niveles de grises de los navegadores limita su uso a lecturas de diagnosti-co aproximadas.



Visualizacion 2D o visualizacion 3D

Los PACS estan disenados para soportar varios modelos de visualizacion de imagenes2D, que pueden simular a las radiografıas convencionales. Las caracterısticas anadidasa la visualizacion de imagenes digitales incluye soporte de zoom, de rotacion, ajustespanoramicos, de ventana, de nivel. Recientes avances en hardware y lenguajes paraimagenes 3D facilitan el movimiento hacia la visualizacion 3D.

La pregunta es si hay una necesidad de facilitar visualizacion 3D online en PACSo librerıas de imagenes medicas. Los Radiologos estan entrenados con la habilidadde reconstruir mentalmente la imagen 3D a partir de cortes de imagenes en 2D. Elcomplejo proceso de visualizacion en 3D no anade ninguna nueva informacion y podrıaincluso disminuir su lectura eficiente. Por otro lado, la visualizacion online es util parala interpretacion combinada o correlacion de imagenes 3D anatomicas o fisiologicas, odatos metabolicos, y para operaciones en tiempo real de terapia de imagenes guiadasy procedimientos quirurgicos. El desafıo que se presenta es debido no solo al grantamano de las imagenes medicas, sino tambien a la complejidad de las relacionesentre los distintos datos.

La implementacion del las capacidades de visualizacion en los PACS o en unalibrerıa de imagenes digitales serıa probablemente una decision estrategica de comouno deberıa expandir los servicios del sistema a otras disciplinas. Un modelo operativoconsiste en anadir un servidor de visualizacion potente en una arquitectura ThreeTiered y transmitir los resultados de la visualizacion a las estaciones clientes a travesde redes de alta velocidad. La ventaja de esta configuracion es la reduccion de cargacomputacional de las estaciones clientes.

Recuperacion por el contenido de la imagen

El diseno original de los PACS es para soportar el estudio de imagenes; de estamanera, las imagenes son recuperadas basandose en claves, tales como el nombredel paciente o el identificador del hospital. La gestion de documentos de imagenesta basado en sistemas de archivos planos. La ventaja es el simple diseno de modeladode datos. Este enfoque carece de la capacidad de buscar e indexar las grandes bases dedatos de PACS por el contenido (p.e., las caracterısticas de la imagen o las relacionesde nombre). Esto impide grandemente la utilidad de los PACS para otras operacionesclınicas, tales como referencias online.

La recuperacion de imagenes por su contenido (BCIR - Content-based image re-trieval) ha sido la llave para la actividad en la investigacion de una librarıa digital deimagenes. Las actuales tecnicas de desarrollo en librerıas digitales pueden ser adap-tadas a los PACS. Muchas de las tecnicas existentes, sin embargo, se ocupan de la



busqueda a traves de caracterısticas comunes de las imagenes, tales como el color, for-ma, textura, o una combinacion de estas. Pero en el dominio de las imagenes medicas,deben ser disenados todavıa mas algoritmos especıficos para la extraccion de carac-terısticas y modelos de datos mas complejos y costosos para tomar ventaja de la ricainformacion contenida en las librerıas de imagenes medicas.

Privacidad y seguridad de las imagenes medicas

La privacidad del paciente y la seguridad de la informacion medica es una cuestionimportante que tiene que ser considerada cuando se trata con librerıas de imagenesdigitales basadas en Internet. Para diagnosis, consulta, o investigacion, las imagenesmedicas y los datos del paciente pueden ser distribuidos a instituciones externas fueradel hospital o clınica del paciente.

La seguridad punto a punto (point-to-point) se consigue generalmente a travesde la encriptacion. Los actuales algoritmos de encriptacion son robustos y los su-ficientemente fuertes para una amplia aceptacion por las comunidades industrial ygubernamental. La cuestion es integrar la tecnologıa de codificacion en la librerıadigital, con un mınimo 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 paracada usuario.

Funcionamiento y fiabilidad

Los usuarios de PACS necesitan acceso rapido a las imagenes medicas para lec-turas y diagnosticos primarios, y para ello a menudo se necesitan redes de alta ve-locidad (p.e., ATM y 100 Base T). Los PACS son esencialmente sistemas cerradoscon un pequeno numero de usuarios, asegurando de ese modo un buen funcionamien-to comparado con los sistemas basados en Internet. La estrecha relacion existenteentre las aplicaciones de visualizacion y el modelo de datos incrementa ademas elfuncionamiento. Con mas nodos siendo anadidos a Internet, la librerıa digital basadaen esta necesita considerar esta cuestion de funcionamiento. La librerıa digital deimagenes medicas debe ser capaz de organizar las peticiones clınicas no primarias-como tareas principales. Una librerıa digital de imagenes deberıa ser disenada paralecturas secundarias o busquedas de datos por referencia.

Implementando una librerıa digital de imagenes con una intranet se puede lograrun funcionamiento comparable a los tradicionales sistemas de PACS, mientras econ-omizamos con el uso de ordenadores de escritorio economicos en lugar de estaciones



Figura 2.2: Arquitectura de una libreria digital de imagenes

de trabajo de alta calidad. El exito del funcionamiento de los sistemas basados enInternet es ademas el uso de aplicaciones ejecutandose dentro del navegador, talescomo applets de Java. Por esta razon, los algoritmos que requieren extensos calculos,tales como la manipulacion de imagenes, no se ejecutan eficientemente en el entornodel navegador.

Los sistemas PACS estan creados para funcionar de manera continua, con unafiabilidad de 24 x 71. La tecnologıa en auge basada en Internet, que es relativamentenueva, tiene todavıa que solucionar el tema de la fiabilidad. La actual implementacionde una Maquina Virtual de Java tiene todavıa que probarse para su fiabilidad enlargos periodos de tiempo. Se han realizado muchos trabajos en gestion de sistemastradicionales de funcionamiento de red, pero para sistemas de objetos distribuidos,tales como CORBA, muy poco esta disponible en terminos de interfaces de gestionde sistemas y herramientas.

2.2.2. Arquitecturas para librerıas digitales de imagenes

Arquitectura de Base Centralizada de Datos

Hay que discutir dos arquitecturas; un modelo de base centralizada de datos yuna arquitectura de objetos distribuidos. La figura 2.2 ilustra la arquitectura generalde un sistema centralizado de datos. Este sistema frecuentemente contiene servidoresde aplicaciones de bases de datos y proporciona capacidad de acceder a Internet.Debido a su gran tamano, los estudios de imagenes son archivados en un medio de

1Funcionamiento continuo de 24 horas por 7 dıas a la semana.



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

El enfoque centralizado es extensamente utilizado en los RIS, HIS, y otros sis-temas 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 dedesarrollo y mantenimiento.

Los datos multimedia de una librerıa digital de imagenes consisten en datos de losarchivos de imagenes de PACS, RIS, HIS, bases de datos clınicas, o archivos externos.Esta naturaleza de los datos es inherentemente multimedia, consistiendo en imagenesmedicas, historiales medicos, demografıas, dictados de voz, e indicaciones biomedicas.Los datos pueden ser almacenados en un archivo del sistema, o en bases de datosrelacionadas. Una tecnologıa para aplicaciones en Internet que esta en auge son lasbases de datos de objetos. Los protocolos estandar de informacion medica, tales comoDICOM (Digital Imaging and Communication in Medicine) y HL7 (Health LevelSeven), proporcionan un metodo a los datos para ser compartidos y archivados.

El servidor de Internet funciona como proxy para las peticiones de los usuarios. Elnavegador genera peticiones HTTP (Hypertext Transfer Protocol) en representaciondel usuario en el servidor de Internet. Sucesivamente, el servidor Web envıa la peticiona una maquina de reglas, la cual procesa la peticion, construye los tipos de datosrequeridos, y devuelve una respuesta al servidor HTTP y al usuario. Las maquinasde reglas tienen varias funciones, incluyendo un mecanismo de filtrado de preguntaso 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 usuariosacceden a tal sistema. La informacion puede ser presentada en el formato HTML (Hy-pertext Markup Language). Los documentos pueden ser gestionados estaticamente in-tegrando los procesos del servidor, tales como el CGI (Common Gateway Interface).El reciente desarrollo de XML (Extended Markup Language) favorecera las capaci-dades avanzadas del navegador proporcionando caracteres definidos por el usuario.El surgimiento de los lenguajes de programacion basados en Internet, tales como Ja-va, permiten capacitar al navegador para cargar y ejecutar dinamicamente pequenasaplicaciones, llamadas applets. Ventajas de este metodo es la gestion de aplicacionescentralizadas y un interface coherente a traves de multiples plataformas. Existenvarias desventajas en el uso de Java y el navegador; el funcionamiento se convierte enun problema cuando los applets son interpretados dinamicamente por el navegador.Por esta razon, los applets de Java estan restringidos en tamano y complejidad.



Arquitectura de Objetos Distribuidos

Mientras las bases de datos centralizadas ofrecen simplicidad en el desarrollo ybajo coste de mantenimiento, no trabajan bien con cargas de trabajo grandes y sis-temas heterogeneos. Sin embargo, existe una resistencia en las organizaciones medi-cas actualmente a ser atadas en una arquitectura basada en la solucion de un unicovendedor. Los sistemas existentes de soporte de almacenamiento de datos necesitanprotocolos y modelos de datos comunes para facilitar transacciones con las bases dedatos. Los problemas surgen cuando las fuentes de datos existentes utilizan protoco-los y modelos de datos diferentes. Ademas de esto, las transacciones son realizadascontra una unica base centralizada. Un sistema centralizado con un amplio numerode usuarios aplica una considerable carga de trabajo en el servidor. Una parada en elservidor detiene el sistema entero.

La tecnologıa de objetos distribuidos soluciona estas cuestiones definiendo el mid-dleware (infraestructura) entre el cliente y la fuente heterogenea de datos, y automa-tizando muchas tareas de desarrollo tales como inscripcion, localizacion, activacion ydemultiplexado de objetos. Los objetos distribuidos son similares a las abstraccionesde objetos en los lenguajes de programacion. Los objetos distribuidos proporcionanun conjunto de campos y metodos accesibles a los clientes. Una framework (sistema)es proporcionado para la gestion de objetos distribuidos. Los objetos proveen a losusuarios un modelo virtual de la fuente de datos, permitiendo una integracion demodelos de datos y protocolos heterogeneos. El framework puede replicar dinamica-mente a los objetos, facilitando un reequilibrio automatico y una tolerancia a falloslimitada.


Fernando Ballesteros Herranz 2.3. ESTANDAR DICOM

2.3. Estandar DICOM

[NEMA] [DICOM] [HORI] [KURA] [REVET97]

En esta seccion se va a hacer un estudio del estandar de comunicacion e imagenesdigitales en medicina DICOM 2.

2.3.1. Introduccion

El uso de la informatica en aplicaciones clınicas es una constante hoy en dıa,especialmente en el campo del diagnostico por imagen. El uso de la imagen digitalse ha ido imponiendo debido a los avances tecnologicos, ya que suponen una mejorcalidad de la misma y la posibilidad de transmitirla a distintos puntos de manerainmediata. El problema fundamental para su empleo es la correcta interpretacionde la informacion. Es por ello que la ACR3 (American College of Radiology) y laNEMA4(National Electrical Manufacturers Association) iniciaron un proyecto parala elaboracion de un estandar para la transferencia de imagenes y la informacionasociada a ellas que, tras varios intentos dio origen al formato DICOM 3.0, que es elestandar habitualmente utilizado por las firmas digitales.

El estandar se ha desarrollado para encontrar las necesidades que fabricantes yusuarios tienen con el equipamiento de imagen medica para la interconexion de dispos-itivos sobre redes estandares. Sus partes multiples proveen medios para la expansiony actualizacion, y el diseno del estandar se apunto para permitir el desarrollo sim-plificado para todo tipo de imagen medica. DICOM tambien provee medios por losque los usuarios de equipamiento de imagen pueden intercambiar informacion de dis-positivos diferentes. Las futuras adiciones a DICOM incluyen apoyo para la creacionde archivos sobre medios extraibles (tales como discos opticos y cinta magnetica),las nuevas estructuras de radiografıa como angiografıa, y extiende el control de ladocumentacion impresa.

En 1992 en la reunion anual de la Sociedad de Radiologıa de America del Norte(RSNA), en la parte 1 (Introduccion y Descripcion) y en la 8 (Soporte de Comu-nicaciones de Red e intercambio de Mensaje) del DICOM de ACR-NEMA (Imagenmedica y Comunicaciones en la Medicina) el Estandar se habıa 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 mensajesde la version previa 2.0 de ACR-NEMA. Mientras estas no eran implementaciones

2Digital Imaging and Communication in Medicine3Asociacion de Colegios de Radiologıa4Asociacion Nacional de Fabricantes Electricos



que incluıan todas las estructuras de datos de DICOM, mostraron que el apoyo dered era operacional y podrıa 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 enencuentros mensuales. Se termino en septiembre de 1993, donde las versiones finalesde muchas de las partes habıan experimentado la prueba de implementacion real a lolargo de 1993 para asegurar que la calidad de estandar serıa demostrada por productosreales en el encuentro de 1.993.

La creciente utilizacion de sistemas de adquisicion y tratamiento digital de ImagenesMedicas ha hecho necesaria la adopcion de estandares que posibiliten el intercambiode estas tanto dentro de las propias instituciones como fuera de ellas.

El estandar DICOM 3.0 nace en el ano 1993, a partir de un rediseno completo dela Publicacion Normalizada No 300-19885 de ACR-NEMA y pertenece al campo de laInformatica Medica por lo que, en principio, esta norma se solapa con otras de estecampo.

En primer lugar, dejar claro que DICOM 3.0 es aplicable a toda la esfera de lasImagenes Medicas, desde la transmision hasta el tratamiento e impresion, independi-entemente de la “especialidad medica” que la exporte.

En segundo lugar, y quizas lo mas importante a dıa de hoy, indicar que aunque laNorma tiene el potencial de facilitar la realizacion de trabajos con PACS, la utilizacionde la Norma DICOM 3.0 no garantiza, por si misma que se cumplan todos los objetivosque se intentan lograr en un sistemas de gestion de imagenes. Se facilita, pero no segarantiza, la interoperatividad en un entorno multi-vendedor.

En tercer lugar, quedan por delimitar elementos importantes de informacion aso-ciada a la propia imagen, por lo que se prevee numerosas extensiones que den soportea futuras aplicaciones.

El avance de la estandarizacion poco a poco va siendo una realidad:

Se homogeneızan los estandares de codificacion de la informacion y del conjuntode datos resultantes de utilizar los Objetos de Informacion (imagenes) con lasClases de Servicio (impresion, almacenamiento, etc), ası como se especificanvarias tecnicas de compresion normalizadas (JPEG con y sin perdidas).

Se muestran las reglas de codificacion que se deben cumplir para construir unsecuencia de datos para ser transmitida como un mensaje.

5Digital Imaging and Communications Standard: version 2.0



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 Sis-temas Abiertos) para asegurar una comunicacion eficiente y que soporte unaamplia variedad de tecnologıas de red basadas en normas internacionales co-mo la ISO 8802-3 CSMA/CD (la famosa red Ethernet), ATM (muy en bogaactualmente), X.25, etc. Y como protocolo de transporte se puede utilizar elfamoso TCP/IP que hay que recordar que es un protocolo de proposito gener-al, por lo que el sistema, en este apartado, es realmente abierto y compatiblecon la mayorıa de las redes que se estan instalando actualmente en los centrossanitarios.

2.3.2. Historia de DICOM

En un esfuerzo para desarrollar unos medios estandar para que usuarios de equipamien-to de imagen medica (tal como TAC, resonancia magnetica, medicina nuclear, y ultra-sonidos) puedan intercambiar imagenes u otros dispositivos entre estas maquinas, elColegio Estadounidense de Radiologıa (ACR) y la Asociacion Nacional de FabricantesElectricos (NEMA) formo un comite conjunto a principios de 1983. La mision de estegrupo, el Comite para estandarizar las comunicaciones y la Imagen digital de ACR-NEMA, estuvo en hallar o desarrollar una interfase entre el equipamiento y cualquierotro dispositivo que el usuario quiera conectar. Ademas de las especificaciones parala conexion de hardware, el estandar se desarrollarıa para incluir un diccionario delos elementos de datos necesitados para interpretacion y la exhibicion de imagenes.

La comision inspecciono muchos patrones de interfase existentes, pero no se encon-tro ninguno que fuera enteramente satisfactorio. En algunos, sin embargo, se encon-traron ideas utiles. La Asociacion Estadounidense de Fısicos en la Medicina (AAPM)habıa, un ano antes, desarrollado un formato estandar para grabar imagenes sobrela cinta magnetica. La porcion de cabecera contendrıa una descripcion de la imagenjunto con los elementos de datos (tal como nombre paciente) para identificarlo. Elconcepto de usar elementos de longitud variable identificados con una etiqueta o lallave (el nombre del elemento) se creyo que era particularmente importante y fueadoptado por la comision.

Despues de 2 anos de trabajo, la version primera del estandar, ACR-NEMA 300-1985 (tambien llamado ACR-NEMA Version 1.0) se distribuyo en 1985 en la reunionanual del RSNA y publicada por NEMA. Como con muchas versiones primeras, seencontraron errores y sugirieron mejoras. La comision habıa creado un grupo de tra-bajo (WG) VI para mejorar el estandar una vez se publico. Este WG contesto muchaspreguntas de desarrolladores potenciales y comenzo trabajando sobre cambios paramejorar el estandar. En 1988, ACRNEMA 300-1988 (o Version 2.0 de ACR-NEMA)



se publico. Uso sustancialmente la misma especificacion de hardware que la Version1.0, pero se agrego nuevos elementos de datos y se fijaron un numero de errores einconsistencias.

El problema era que por 1988 muchos usuarios quisieron una interfase entre dis-positivos y una red. Mientras esto podrıa realizarse con la Version 2.0, el estandarcarecio de partes necesarias para la comunicacion robusta de red. Por ejemplo, unopodrıa enviar a un dispositivo un mensaje que contenga informacion de cabecera yuna imagen, pero el dispositivo no sabrıa necesariamente que hacer con los datos. LaVersion 2.0 de ACR-NEMA no era disenada para conectar equipamiento directamentea una red, resolver estos problemas significaban cambios importantes al estandar. Lacomision habıa adoptado la idea que las futuras versiones del Estandar de ACR-NEMA tendrıan compatibilidad con las versiones anteriores, y esto puso algunasrestricciones al WG VI.

En una decision importante para el estandar, se decidio que el desarrollo de unainterfase para el apoyo de red requerirıa demasiados parches sumados a la Version2.0. El proceso entero tuvo que ser redisenado, y el metodo adoptado fue el de objetoorientado a diseno.

Ademas, un examen completo de los tipos de servicios necesitados para comunicarcon redes diferentes mostro que definiendo un servicio basico permitirıa que la capasuperior procesara las comunicaciones (la capa de aplicacion) para hablar con unnumero de protocolos diferentes de red. Estos protocolos se modelan como una seriede capas, frecuentemente referida a como“stacks”. En la Version existente 2.0 el“stac”definido en una conexion punto a punto era uno. Dos de los otros se eligieron conbase en la popularidad y futura expansion: El Protocolo de Control de Transmision /Internet de Protocolo (TCP / IP)6 y la Organizacion Internacional de Estandares deInterconexion de Sistemas7 (ISO-OSI). La figura 2.3 muestra un diagrama del modelode comunicacion desarrollado. La filosofıa basica de diseno era que una aplicacion deimagen medica determinada (fuera del alcance del estandar) podrıa comunicar sobrecualquier de los stacks de otro dispositivo que use la misma stack. Con la adherenciaal estandar, serıa posible cambiar las comunicaciones de stacks sin tener que pararevisar los programas de computadora de la aplicacion.

Despues de tres de anos de trabajo, WG VI, con valiosas sugerencias de la industriay la academia, ha completado DICOM de ACR-NEMA (tambien llamado DICOM3.0). Es un estandar de tamano mayor que las versiones 1.0 o 2.0, pero tambiensoporta muchas caracterısticas de las versiones anteriores.

6Transfer Control Protocol / Internet Protocol7International Standard Organization - Open Systems Interconnection



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 yterminologıa usada en el estandar DICOM. Figura 2.4.

Con un simple modelo de un proceso distribuido se puede explicar el mecanismoy terminologıa usada en el estandar DICOM.

Figura 2.4: Procesamiento distribuido

Un proceso distribuido esta formado al menos por dos procesos que comparteninformacion y confiando en la operatividad de uno en el otro. Un numero de procesosdistribuidos actuando juntos proporcionan servicios para sistemas en entornos comodepartamentos de radiologıa. Figura 2.5.

Antes de que los procesos puedan actuar juntos una serie de temas tienen que ser



Figura 2.5: Transmision

tratados. Tienen que estar de acuerdo en el papel (rol) que cada uno desempenara,tener una vision equivalente de la informacion y seleccionar las operaciones que cadaparte realizara.

Primeramente, el papel de cada parte debe ser definido como cliente o como servi-dor. La parte que utiliza la operatividad de la otra, tiene el papel de cliente. Laparte contraria actuando sobre un modelo concertado tiene el papel de servidor. Elfuncionamiento de ambas partes viene definida por la relacion que comparten. Larelacion define que parte y bajo que condicion toma la iniciativa en el proceso. Enmuchos casos los clientes provocan el proceso, pero a veces lo hace el servidor.

Ademas de los papeles que desempenan, ambas partes tienen que estar de acuer-do en la informacion que intercambian. La informacion esta definida por el contextodel servicio que el proceso distribuido esta realizando. Cada proceso individual ten-dra una vision selectiva de esta informacion, pero la vision tiene que ser coherente enla totalidad del contexto.

La operacion define como debe ser procesada la informacion intercambiada en laotra parte, tal como almacenar informacion, devolver un resultado, etc.

La combinacion del contexto, relacion, operaciones e informacion es la piedra fun-damental del procesamiento distribuido y tiene que ser definida antes de que unaaplicacion pueda ser realizada. Todos estas cuestiones son parte del dominio de laaplicacion(application domain) de los procesos distribuidos. Estos no se ocupan dela forma en que la informacion es intercambiada actualmente, pero cuentan con losservicios de menor nivel (p.e. TCP/IP) suministrados por el dominio del intercam-bio(exchange domain) para poder hacer frente al intercambio.

Ambas partes, cliente y servidor, tienen que ser capaces de emitir peticiones a losservicios de menor nivel. Los servicios de menor nivel llevaran el intercambio y estanocultos para el dominio de la aplicacion del cliente o servidor. La parte que solicita



los servicios es el usuario del servicio (service user). El equivalente es el proveedor delservicio (service provider). Ambas partes pueden tener distintas implementaciones,pero comparten el mismo conocimiento sobre como se intercambian los datos (proto-colo) y tienen el mismo interface logico (formato de peticion) entre sı. Ambas partesdeben determinar como viene representada la informacion en el formato de bit/byte.El proveedor del servicio debe determinar en que formato la informacion fue trans-ferida y convertida a la representacion esperada por el dominio de la aplicacion. Larepresentacion es conocida entre el usuario y el proveedor del servicio en cada parte.Despues del intercambio, la informacion presentada a los procesos utilizando la infor-macion es igual en ambas partes, independientemente de como fuera intercambiada.

El intercambio fısico entre los proveedores del servicio puede ser vıa network omedia. Cada mecanismo tiene su propia forma de manejar el conocimiento de larepresentacion.

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-



cambio actualmente usado.

Los objetos (pacientes, imagenes, reportes,etc.) y sus interrelaciones son descritosmediante modelos de entidad-relacion. El primer modelo fue definido para la radi-ologıa. Otras disciplinas medicas han pedido su incorporacion al estandar.

DICOM utiliza su propia terminologıa para describir el contexto, relaciones,asociaciones,etc. El primer paso es el mismo modelo que para el procesamiento distribuido con latransformacion de la figura 2.6 en la figura 2.7 aplicando los terminos equivalentes deDICOM.

Figura 2.7: Clases de Servicio de DICOM

Se considero que la mejor manera de desarrollar las estructuras de datos era eldiseno orientado a objetos. Los objetos definidos en los modelos son llamadosentidades.los atributos describen las caracterısticas de un objeto. Cuando se dan valores a losatributos de un objeto, defiendo un objeto reas, existente, se habla de una instancia delobjeto. Los objetos de agrupan en clases, segun su tipo. Las clases se comunican entresı, mediante mensajes. DICOM define las clases de objetos y sus mensajse permitidosen lo que es llamado SOP(Service-Object Pair). Cuando un equipo especifica quees compatible con una clase SOP, es posible saber de forma no ambigua como seentenderan sus datos, ya sea por el proveedor de los servicios de la clase : SCP(ServiceClass Provider) o por el usuario de los servicios de la clase: el SCU (Service Class



User). Para realizar una asociacion, lo primero es que SCU y SCP esten deacuerdoen 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 Ser-vicio. La Clase de Servicio describe explıcitamente los papeles que ambas partes de-sempenan. 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 (ServiceClass Provider) (servidor). No hay que confundir SCU y SCP con el usuario delservicio 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 deServicio de Par Objeto (Service Object Pair Class) o Clase SOP (SOP Class). Encada definicion de Clase SOP una unica Definicion de Objeto de Informacion (Infor-mation Object Definition) o IOD es combinado con uno o mas servicios. Para cadauno de estos servicios los detalles de los papeles de ambas partes que tienen quedesempenar son invariables. Mas de una Clase SOP puede existir en una Clase deServicio cuando mas de un IOD esta implicado. Una Clase de Servicio entiende larelacion de informacion definida en diferentes IODs.

Una Clase SOP identifica las capacidades del proceso distribuido especıfico deuna Clase de Servicio. Cuando las partes estan de acuerdo en utilizar una ClaseSOP, ambas partes deben asegurar que desempenaran sus papeles como se describen,utilizando el contexto de la Clase de Servicio incluida. Antes de que la informacionse intercambie puede tener lugar la identificacion de la Clase SOP, que es una parteimportante que tiene que ser realizada al principio. El mecanismo usado depende deltipo de intercambio: “network” o “media”.

Utilizando la Clase de Servicio y otras definiciones derivadas, las partes en elentorno de un proceso distribuido funcionan juntas mediante los servicios propor-cionados por el dominio del intercambio.

Definiciones de Objeto de Informacion (Information Objects Definitions)

La parte de informacion de una Clase SOP es definida en los IODs. Un IOD esuna coleccion de partes de informacion relacionada, agrupadas en Entidades de Infor-macion (Information Entities) o atributos. Cada entidad contiene informacion sobreun unico objeto (mundo real) como un paciente, una imagen, etc. Dependiendo del



contexto definido por la Clase de Servicio, un IOD consiste en una entidad de in-formacion unica llamada IOD normalizado (normalized IOD) o una combinacion deentidades de informacion llamada IOD compuesto (composite IOD). Las Clases deServicio que llevan a cabo funciones de administracion (en su mayor parte cuestionessimples) utilizan IODs normalizados, aquellas que manejan el flujo de imagenes (es-tructura compleja de informacion) utilizan IODs compuestos. Cada Clase SOP esdefinido 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 IODscompuestos es descrita en el modelo de informacion (information model) pertenecientea la Clase de Servicio. Con IODs normalizados (solo una entidad de informacion) nohay ninguna necesidad de estructuracion. Las relaciones en otras piezas de informacionestan hechas aludiendo a esa informacion.

Las entidades de informacion consisten en atributos, describiendo una unica partede informacion, p.e., el nombre de un paciente. Los atributos que tienen una relacionestan agrupados en modulos de informacion de objetos o IOMs (Information ObjectModules). Los IOMs estan definidos de tal manera que pueden ser usados en mas deun IOD. Estos IOMs tambien tienen la ventaja de que las descripciones semanticasde los atributos descritos pueden ser agrupados juntos. La figura 2.8 representa unavision general de estas relaciones.

Un ejemplo de una IOD compuesto, imagen IOD esta representada en la Figura2.9.



Figura 2.9: Ejemplo de un IOD de imagen compuesto

Atributos

Los atributos son la entidad de informacion basica y tienen que ser descritosen detalle.Figura 2.10. Las siguientes caracterısticas o campos de un atributo estandefinidas en el estandar DICOM:

un unico Nombre de Atributo (Attribute Name) (legible por el ser humano).

una unica Etiqueta de Atributo (Attribute Tag) (legible por los sistemas deinformacion).

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 lasClases SOP, Clases de Servicio, papel que desempena, etc.).

El tipo de clase especifica el uso de los atributos especificados en las Clases SOPy el papel del SCU o del SCP. Dependiendo de la situacion, cada atributo es forzado



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 condiciona-dos por la situacion en la que el IOD esta siendo usado. Por ejemplo, un analisis uti-lizando 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 losatributos 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 In-formacion (IODs) para una Clase SOP definida. El grupo de elementos de serviciopertenece 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 Elemen-tos de Servicio de DICOM. Algunos Elementos de Servicio estan proyectados parausarse con IODs compuestos, otros para uso con IODs normalizados. Una terceracategorıa, medios de almacenamiento (storage media) relacionados con Elementosde Servicio, manejando instancias de Clases SOP normalizadas o compuestas comoarchivos. Una Clase SOP utiliza uno o mas elementos de servicio.

El contexto descrito por la Clase de Servicio esta limitado cuando se utilizanIODs compuestos (p.e., transferir imagen). Elementos de Servicio semejantes tienenun significado complejo, p.e., STORE, FIND, MOVE. No hay ninguna relacion asum-ida entre los Elementos de Servicio individuales en una secuencia cuando se utilizanClases de Servicio compuestos. Si existe una relacion, es fuera del alcance de la Clasede Servicio y deberıa estar definida en el proceso fluyente utilizando las Clases deServicio.



En contraste, las Clases de Servicio utilizando IODs normalizados tienen un con-texto mas amplio, como funciones directivas. Estas utilizan los Elementos de Servicioprimitivos 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 procedimientode ambas partes, utilizando los Elementos de Servicio para controlarlos.

Cada Clase SOP utiliza uno o mas Elementos de Servicio de cada uno de los gru-pos compuestos (C-XXXX) o de los grupos normalizados (N-XXXX). Los siguientesElementos de Servicio estan disponibles: C-STORE, C-FIND, C-MOVE, C-GET, C-CANCEL, C-ECHO, N-GET, N-SET, N-ACTION, N-CREATE, N-DELETE y N-EVENT-REPORT. Las semanticas de los Elementos de Servicio dependen de la Clase de Ser-vicio 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 tratamien-to con archivos.

Gracias a las Clases de Servivio (mensajes DICOM) hay una comunicacion entreambas partes. Antes de poder lograr el intercambio de informacion entre dos ClasesSOP, debe establecerse entre ellas una Asociacion (Association en DICOM), donde senegocia para establecer las posibilidades de trabajo de cada parte. Una vez establecidala asociacion, si esta fue satisfactoria puede establecerse el intercambio de mensajes atraves de los DIMSE- DICOM Service Element- (DIMSE-C en este caso, que soportaoperaciones con Instancias Compuestas SOP).

Los mensajes entre dos aplicaciones DICOM estan codificados y son enviados enforma de Data Set que esta compuesto de Command Elements y deben tener unaestructura como la que se muestra en la figura 2.11.

La norma establece que la estructura del mensaje y set de comandos sea pordefecto: - Tags en orden Creciente, - Little Endian, -VR Implıcito.

La transferencia de mensajes entre aplicaciones DICOM se establece mediante elflujo de Data y Command Elements ordenados segun el Tag y codificados.

Si en el Data Set vienen ya implicitos los datos que quieren ser pasados de unequipo a otro, este se compone de Data Elements y su estructura es segun la figura2.12. Este es el modo en que se codifican los mensajes para transferir los estudios yla informacion de un equipo a otro.

Tanto el Command Set como el Data Set son “cola” de Command Elements8 o

8Elementos de Comandos DICOM (Store, Find, etc.)



Figura 2.11: Estructura del mensaje DICOM

Data Elements9 respectivamente. En ambos casos, la estructura del elemento es lamisma, difiriendo simplemente en el numero de grupo y en algunos casos en el VR.

Tag: es un par ordenado de numeros de 16 bits codificados en hexadecimal.El primero de ellos hace referencia al Grupo, mientras el segundo se refiere alElemento, y son leıdos 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 segun la cualse especifica el tipo de dato que se leera en el Value Field. En la Parte6 de lanorma 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 (segun sea VR, Explıcitoo Implıcito). Contiene un numero par que indica la extension del campo ValueField, donde se hallan contenidos los datos propiamente dichos.

Value Field: aquı se encuentra un numero par de elementos conteniendo el/losvalor/es. Es el dato propiamente dicho, cuya ındole esta determinada por loscampos anteriores.

9Codificacion de datos (Fecha de Estudio, Modalidad de Estudio, etc.)



Figura 2.12: Estructura del Data Element

Instancias SOP (SOP Instances)

El esqueleto de las definiciones citadas anteriormente toma forma cuando se uti-lizan en un proceso distribuido. Despues del acuerdo que mantienen las Clases SOP(e implıcitamente la Clase de Servicio), y como los papeles de la SCU y la SCP estandivididos, las instancias de la clase SOP pueden ser distribuidas entre las dos partes.Los Atributos tienen que ser proporcionados con los valores correctos y almacenadoen la Instancia SOP como se especifica en la definicion de los atributos.

Despues de recopilar la informacion, esta sera codificada a los formatos definidospor 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 ele-ment. Este “data set” es manejado por el proveedor del servicio de intercambio, el cualgarantiza que la parte contraria recibe identico data set. Las diferencias en la repre-sentacion 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 necesitay actuar como acuerdo de la semantica de la Clase SOP.

Identificacion

Como parte del proceso de creacion de una Instancia SOP, una identificacion esgenerada como atributo de la SOP Instance. La identificacion es pretendida para la



utilizacion por los sistemas de informacion antes que por los humanos y tiene doscaracterısticas: la identificacion de la clase (class identification) y la identificacion dela instancia (instance identification).

Esta identificacion tiene que ser usada en un entorno de muchos vendedores endistintas partes del mundo. Para asegurar la unicidad de cada identificacion en todoel mundo, un mecanismo es utilizado para generar una cadena de caracteres, llamadaIdentificador Unico o UID (Unique Identifier), tal y como sigue:

<root>.<suffix>

La parte de root es proporcionada por una autoridad que garantice que nadiemas utilizara este root. Este numero sera asignado por estandares de organizacionesy companıas tales como Philips u hospitales, que deberan asegurar que permaneceunico a lo largo de sus propios sistemas. Utilizando un sistema de identificacion unico,cada sistema tendra un unico root a lo largo de todo el mundo. El suffix tiene que sercreado dinamicamente por el sistema en la creacion de la instancia.

Un vez que una instancia es identificada por un UID, esta debe ser utilizadaconsistentemente. Si se crean copias o la instance es reproducida sin ninguna modifi-cacion, debera tener el mismo UID, de lo contrario dos piezas de identica informacioncoexistirıan con diferentes identificaciones, lo que podrıa conducir a confusion.

Relaciones

Ademas de la identificacion de la Clase SOP y la Instancia SOP, los UIDs tambiense utilizan para identificar una relacion entre instancias. En una instancia compuesta(composite instance) que contiene una secuencia de imagenes, la Entidad de Infor-macion (Information Entity) que contiene la informacion de la secuencia sera comunpara todas aquellas instancias. En este caso solo un UID es requerido, el atributo porsı mismo identifica que tipo de entidad de informacion es identificada.

En el caso de instancias normalizadas (normalized instances), solo son posiblesreferencias a instancias fuera de sı mismas, aquı la combinacion de una identificacionde una clase y una instancia es requerida. Este es tambien el caso de imagenes queestan 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 tieneningun significado, y no puede ser utilizado para clasificar, etc. Utilizando otro meto-do, atributos mas significativos tales como la fecha y la hora y los numeros de lasecuencia, la relacion entre la informacion puede ser establecida.



Representacion del Valor (Value Representation)

Para cada atributo un Representacion del Valor (VR) es definido. Una Repre-sentacion del Valor describe como un atributo es codificado en un Data Element(elemento de dato). El conocimiento de la Representacion del Valor es compartidopor las partes en el intercambio de informacion, el proceso de codificacion y decod-ificacion 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 diccionariode datos que contiene todos los posibles atributos de intercambio o incluyendo la rep-resentacion del valor como una parte del data element. El ultimo metodo incrementalos gastos de intercambio de informacion, pero es mucho mas flexible comparado conel uso de un diccionario de datos compartido. Especialmente en un entorno de muchosproveedores, sincronizar el diccionario de datos es difıcil.

Cuando la Representacion del Valor es incluido, el mensaje es codificado con unVR explıcito (explicit VR). En el otro caso, la codificacion tiene lugar con un VRimplıcito (implicit VR).

Transfer Syntax

Antes de que la Data Set de una Instancia SOP pueda ser transferida, la formaen la que el Data Set es codificado en una secuencia de bytes debe ser fija, ambos poracuerdo cuando el intercambio network es usado, o almacenados juntos con los datosde uno. La forma de codificar es especificada por el Transfer Syntax.

Tres caracterısticas tiene que ser definidas por la transfer syntax:

Como una Representacion del Valor es especificada.

La ordenacion de bytes de un numero multiple de bytes (palabras, palabraslargas): little endian o big endian.

En caso de encapsulacion (compresion): el formato de compresion.

El manejo del “transfer syntax” es parte del proveedor del servicio. Sin embargo,ambos procesos tienen que ser iniciados segun el “transfer syntax”, aceptable paraambas partes.

Analogamente a una identificacion de Clase SOP, un ´´transfer syntax” es iden-tificado por un UID.



Una vision general

Mirando la figura 2.13 se puede obtener una vision general del flujo de codificaciony decodificacion. Los servicios proporcionados dentro del Dominio del Intercambiotienen que garantizar que las Instancias SOP en ambas partes contienen la mismainformacion, 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 repre-sentacion definido para ese atributo.

La segunda etapa transfiere el data set en una corriente de bytes que puedenser manejados por las capas mas bajas. Para la segunda etapa la ordenacion debytes tiene que ser utilizada como acuerdo con el Transfer Syntax.

La aplicacion que esta utilizando la informacion debe conocer el significado (semanti-ca) de la informacion dentro del objeto dato.

Figura 2.13: Vision general de la codificacion y decodificacion de las instacias SOP



2.3.5. Conceptos de DICOM Network

En la anterior seccion se han discutido los conceptos de DICOM del dominiode la aplicacion. Cuando se utiliza un mecanismo “network” para el intercambio deinformacion, el dominio del intercambio debe contener funciones requeridas para lacomunicacion: el dominio de la comunicacion; ver figura 2.14.

Figura 2.14: DICOM y el intercambio “network”

Entidad de la Aplicacion (Application Entity)

Una cuestion importante en las aplicaciones distribuidas en red es como las apli-caciones pueden contactar entre ellas. En DICOM Network, las partes se reconocenmutuamente mediante las Entidades de la Aplicacion. Una Entidad de la Aplicaciones aquella parte de un proceso que negocia con la comunicacion. Ella contiene elUsuario de Servicio del proceso, conteniendo funciones para organizar conexiones ytransferencia de informacion. Una Entidad de la Aplicacion tiene un nombre, Tıtulode la Aplicacion (Application Title), que tiene que se utilizado cuando se establece lacomunicacion.



Direccion de la Presentacion (Presentation Address)

Los Tıtulos de la Aplicacion son nombres simbolicos para los procesos involucradosen la comunicacion. En un sistema de red real, la direccion de red tiene que sersuministrada. A esto se le llama la Direccion de la Presentacion. Se le llama ası porqueel usuario del servicio es la capa de Aplicacion (OSI), el proveedor del servicio, la capade Presentacion (OSI) (y niveles mas bajos). La frontera entre ambos niveles es elpunto de acceso network donde los datos son transferidos desde la capa de aplicaciona las capas de network. Cada punto de acceso en una red tiene una unica direccion.

El mapeo del Tıtulo de la Aplicacion a la Direccion de la Presentacion no tieneque ser unico, porque la Direccion de la Presentacion es utilizada para la iniciacionde la conexion, etc. De cualquier manera en el nivel de aplicacion, el Tıtulo de laAplicacion es usado normalmente para identificar una aplicacion como fuente o des-tino de informacion en un directorio o catalogo. Si esto no puede ser registrado sinambiguedades la operacion de los sistemas puede llegar a ser un problema.

El formato de la Direccion de la Presentacion depende del protocolo de red uti-lizado. Los DICOM Networks son realizados en muchos casos utilizando el protocoloTCP/IP. En este caso la Direccion de la Presentacion es mapeada a un TCP/IP sock-et. En caso de un protocolo OSI, debe utilizarse un OSI Presentation Service AddressPoint (PSAP) valido.

Association Negotiation

La conexion para el intercambio de informacion entre dos Entidades de la Apli-cacion es llamada Asociacion (Association). Para una Asociacion unas cuestionesde comunicacion son fijados como el contexto en el cual la informacion puede tenercambios. Este contexto, llamado Contexto de la Aplicacion (Application Context),es definido en el estandar DICOM y ambas partes deben estar de acuerdo con laactuacion conforme a la definicion del contexto.

Un Contexto de la Aplicacion es definido con un UID y durante la iniciacion deuna asociacion este UID es transferido a las partes. Por comparacion del UID de unContexto de la Aplicacion, la parte puede decidir si es capaz de manejar la peticionde una asociacion. El aceptara el establecimiento de la asociacion o lo rechazara.

El Contexto de la Aplicacion cubre la operatividad global para el intercambiode informacion. Que tipo de informacion intercambia tendra lugar a traves de laasociacion que esta definida por las Clases SOP y las Clases de Servicio de estas ClasesSOP. 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.



Dependiendo de las capacidades de la otra parte, aceptara o rechazara cada ClaseSOP individual.

Despues de este proceso de negociacion ambas partes conocen mutuamente lascapacidades y limitaciones. La autentica informacion distribuida puede tener lugarconforme a las reglas de una Clase de Servicio y una Clase SOP definidas para estasclases. Cuando una Asociacion no es muy larga se requiere la Asociacion que haterminado.

Presentation Context

Para cada Clase SOP negociada durante la iniciacion de la Asociacion tiene quealcanzarse un acuerdo entre los procesos involucrados acerca del transfer syntax usadoentre los procesos. La parte iniciadora propone todos los transfer syntaxes, fijandoel Contexto de la Presentacion para esta Clase SOP. Despues de la negociacion unaPresentation Context para cada Clase SOP aceptada es establecida.

Una Presentation Context es identificada por un numero acordado entre las dospartes. En el contexto de una aplicacion puede existir un numero de una PresentationContext. El numero de la Presentation Context identifica la SOP Class para la cualel intercambio de informacion tiene lugar.

El Contexto de Presentacion esta compuesto por dos UIDs, uno es el TransferSyntax, necesario para la posterior transmision del Data Set, y el otro el AbstractSyntax, 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 definidospara el protocolo OSI. Ver figura 2.16.



Figura 2.16: Capas OSI

Para la capa de aplicacion dos grupos de servicios tienen que estar disponiblespara una implementacion DICOM: el protocolo de Control de Asociacion (ACSE) yel protocolo de Mensajes DICOM (DIMSE). ACSE es un estandar del protocolo OSIy DIMSE pone en practica los servicios DICOM.

El interfaz entre ACSE, DIMSE y la aplicacion, es la Interfaz DICOM como ladescrita en el estandar DICOM. Esta especificacion describe que parametros sonrequeridos para cada funcion del ACSE y peticiones DIMSE. El ACSE, DIMSE yel interfaz DICOM son partes del Contexto de Aplicacion.

El interfaz hacia la aplicacion(API) no es especificado en el estandar, pero dependede la implementacion. En general este API proporciona funciones para conectarse conotras aplicaciones, construir o tratar Instancias SOP y transferir estos a una aplicacionremota.

TCP/IP Protocol Stack

La combinacion de TCP/IP y una extension para los servicios de aplicacion de OSIes ampliamente usada para implementar DICOM a traves de las redes. Como no hay



niveles mas altos definidos por TCP/IP, la operatividad de la aplicacion, presentaciony 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 delprotocolo 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 conexionTCP. La Direccion de la Presentacion es mapeada a un numero de puerto TCP,combinado con el numero de IP o nombre del servidor (Host name). Esta combinaciondel numero de puerto TCP y el numero de IP es llamada Direccion de Conexion(Socket Address). En una red esta combinacion es siempre unica.

Una conexion TCP es definida por la combinacion de una Direccion de Conexionlocal y una remota. Manteniendo los numeros de IP unicos de la red y el numero unicode puerto en el sistema, cada conexion TCP es unica identificada por la combinacion.La administracion de las conexiones se hace por una recurso llamado Interface deConexion (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 numero de puerto entre lasdos aplicaciones, o por un numero de puerto, llamado numero de puerto notorio (wellknown port number), reservado para las implementaciones de DICOM (numero depuerto 104).

2.3.6. Clases de Servicio soportados

DICOM tiene definidas un numero de Clases de Servicio. Pueden ser agrupadasen un gran numero de categorıas. Esta lista de Clases de Servicio crecera tal comonuevas operatividades sean estandarizadas en el estandar DICOM.

Image Storage Service Classes

Esta primera categorıa contiene las Clases de Servicio negociadas con los datosde imagen. Los datos de imagen son siempre encapsulados en un IOD compuesto yutilizando los servicios compuestos. Las Clases de Servicio de este grupo son:

Storage Service Class, que consiste en Clases SOP para cada modalidad detipo de imagen: Computed Radiography (CR), Computed Tomography (CT),Magnetic Resonance (MR), etc. Esta Clase de Servicio especifica el intercambio



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 GETpara un numero de modelos de peticiones. La FIND puede ser utilizada parasolicitar una coleccion de imagenes. La MOVE y GET pueden ser usadas parainiciar la transferencia. La actual transferencia se realiza utilizando la StorageService Class.

Study Contents Notification, es utilizada para notificar una administracion facilde una imagen sobre las imagenes creadas durante un estudio y podrıan serutilizadas para iniciar la transferencia de los datos de imagen o para chequearsi todas las imagenes han sido completamente transferidas.

Management Service Classes

La administracion orientada a las Clases de Servicio se realiza utilizando unamezcla de IODs normalizados con Servicios normalizados y una Clase de ServicioQuery que maneja informacion en sentido opuesto. Esta segunda categorıa consisteen:



Detached Patient Management maneja la informacion solicitada por la agendade visitas para una o mas modalidades. La informacion demografica del pacientey los estudios de informacion son enviados desde los sistemas administrativos(RIS) hasta la modalidad.

Detached Study Management recibe informacion de las series de imagenes creadasde las modalidades y manda todos los datos adquiridos a un completo estudiode imagenenes interdependientes y todos los otros tipos de informacion.

Detached Result Management es utilizada para estar al tanto de los informes eimpresiones del estudio.

Basic Worklist Management, es la unica Service Class no normalizada. Comple-menta a la Detached Patient, Study y Result Management Service Class con unafacil peticion] para ser utilizada para obtener informacion sobre una unica listade entidades de informacion. Esto permite una forma mas flexible de adquiririnformacion comparada con las otras Clases de Servicio.

Print Management se utiliza para administrar el proceso de formateo e impre-sion 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 elintercambio de datos usando Media Storage. Media es usado por dos razones:

Las imagenes son almacenadas en Media para el intercambio entre dos proce-sos sin la especificacion sobre el tratamiento, solamente la transferencia de lainformacion.

Las imagenes son almacenadas para mostrarlas como Sesiones de Pelıcula. Elproceso de recepcion debe manejar la informacion de la Gestion de la Impresionen Media, y mantener sobre esta la informacion del estado del progreso deltrabajo de impresion.

El papel en el cual el proceso esta activado en esta Clase de Servicio no esta rela-cionado con el papel del companero con la situacion de red, pero con las operacionessobre los medios de comunicacion. Tres papeles son definidos: el File-set Creator oFSC, el File-set Reader o FSR y el File-set Updater o FSU, el nombre se refiere a laoperacion permitida.

Los Elementos de Servicio usados en las Clases SOP de esta Clase de Servicioespecifica las operaciones en las instancias de las Clases SOP como un archivo o como



una direccion completa de un archivo. Los IODs usados con estos servicios definen lainformacion 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 undirectorio (DICOMDIR).

Otras Clases SOP de Media Storage Service Class son identicas a las Clases SOPusadas con el Network Storage Service Class para datos de imagen, Detached PatientManagement, Detached Study Management, Detached Result Management y PrintManagement Service Classes. Las Clases SOP almacenadas en archivos pueden serusadas 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 in-tercambiada por los medios de comunicacion especificando una lista de Clases SOPy otras cuestiones. Como no existe ningun mecanismo de negociacion de asociacion,debe haber un arreglo que se conforma a un Perfil De aplicacion.

Verification Service Class

Finalmente, hay una Clase de Servicio que no se ajusta a ninguna de las cat-egorıas anteriores: la Verification Service Class. Esta Clase de Servicio es utilizadapara chequear si una asociacion puede establecerse entre dos procesos e intercambiaruna instruccion sin ningun dato (C-ECHO), donde ningun IOD esta involucrado. Estaproyectado para propositos de chequeo en nivel de conectividad.



2.3.7. Conectividad

Antes de que las dos implementaciones de DICOM puedan ser conectadas entresı, algo de investigacion es necesaria si la conexion es posible. Esto alcanza desde elbajo nivel de conexion fısica hasta la implementacion de la misma Clase de Servicioen el nivel de aplicacion.

El acercamiento a una conexion “network” es diferente comparado con un inter-cambio a traves de “media”. Durante la negociacion de la Asociacion en un entornonetwork un numero de detalles pueden todavıa ser establecidos. En el caso de utilizarmedia no es posible y deberıa ser dirigido de distinto modo.

DICOM solventa esta cuestion utilizando perfiles de sistema (system profiles) paraimplementaciones y Perfiles de aplicacion (application Profiles) en un entorno deintercambio “media”.

Conformance Statement

Un Perfil de Sistema (System Profile) contiene una lista de las funciones sopor-tadas y limitaciones o extensiones de estas funciones. Juntos forman un perfil que sedebe ajustar al perfil de la parte que tendra que cooperar. Estos perfiles de sistemason descritos en un documento que debe ser suplido con cada implementacion deDICOM: 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, lasClases SOP soportadas y el papel que ambos sistemas desempenan son descritas.



Para la implementacion de los protocolos de red puede ser referido a documentacionestandar apropiada, con constancia de las excepciones que restringen el uso en un en-torno de red. Las posibilidades de una conexion fısica es tambien un tema que debeser dirigido.

Los objetos configurables de una implementacion, tales como el Tıtulo de la Apli-cacion (Application Title), la Direccion de la Presentacion (Presentation Address) deambas implementaciones y partes, que son mencionadas juntas con informacion decomo puede ser configurado. Otros objetos configurables como el tamano del protocoldata 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 conectividada todos los niveles es posible. Si la implementacion de la informacion por todas laspartes involucradas es igual, no se puede asegurar por verificacion con la ConformanceStatement. Dependiendo de como de estricta pueda ser interpretada la semanticade todos los atributos individuales, el nivel de interoperabilidad es mas predecible.Actualmente no hay ningun metodo para asegurar la interoperabilidad.

La Conformance Statements pueden anadir mas informacion describiendo en masdetalle la informacion que manejan. Cuando esta indicado que relaciones estan disponiblesy que selecciones estan hechas por la implementacion comparada con el estandar, esteayudara a incrementar la conectividad y la interoperatividad.

Perfiles de Aplicacion (Application Profiles)

Para “media” un perfil de sistema detallado tiene poco sentido porque la corre-spondencia no tendra lugar antes de que se conecten los sistemas, pero por el momentoel medio es llevado a otro sistema. En este caso ambos sistemas deben garantizar quese ajustan a un formato generico que habilita la aplicacion que ambos implementan.Este formato generico es llamado Perfil de la Aplicacion. Por ejemplo, un sistemaque genera datos de imagen en un medio debe hacerlo conforme a un Perfil de Apli-cacion confirmado. Un sistema utilizando esta imagen puede confiar en este Perfil deAplicacion para resultar un exito.

Dos aspectos son importantes: el formato del medio y la extension de la infor-macion capturada en el medio. Un Perfil de Aplicacion asegura estos dos aspectos yproporciona un tipo de etiqueta que puede ser adjuntada al sistema involucrado y almedio que contiene los datos. Figura 2.20

El aspecto fısico del medio alude al formato definido en el estandar DICOM.



Figura 2.20: Conformance Statement con Perfil de Aplicacion

La parte de informacion descrita por la Clase SOP es el segundo aspecto incluidoen el Perfil de la Aplicacion.

2.3.8. Estandar DICOM

El estandar DICOM esta dividido en varias partes, cada una de ellas describiendouna cuestion importante tal como las Clases de Servicio, los IODs, temas relacionadoscon Network y Media, etc. En la figura 2.21 se ve una vision general de la relacionentre las diferentes partes.

Las partes de DICOM son 13: las 9 primeras son originales y las partes de la 10a la 13 fueron propuestas mediante suplementos. La figura 2.21 muestra la relacionentre las partes del estandar. La figura no debe tomarse como jerarquıa; la porcionde la izquierda representa las partes que definen la red y la comunicacion punto porpunto. La porcion derecha de la figura muestra las partes que soportan medios dealmacenamiento 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 lostemas planteados en los apartados anteriores. Puede ser usada como linea directivapara empezar a leer las varias partes del estandar DICOM.



La parte 1 da una introduccion y una vision general del estandar DICOM y surelacion con otros sistemas de informacion hallados en el entorno clınico.

La parte 2 define la comformidad (compatibilidad) con DICOM. El certificado deconformidad (Conformance Statement) debe ser hecho publico por cada fabricante (lamayorıa estan en Internet). Este especificara exactamente cuales clases de serviciosSOP son soportadas por sus dispositivos. Esto guiara a los usuarios a seleccionar pro-ductos que trabajen juntos. Al comprar un equipo el usuario debiera saber cuales sonlas clases de servicios que necesita para su servicio medico. Esta labor es complicadapor lo que se recomienda a las instituciones de salud asesorarse por especialistas enel estandar. Cada usuario debiera tener idealmente un perfil de conformidad (UserConformance Profile) que especifique las clases que requiere.

Las Clases de Servicio y las Clases SOP incluidas en las Clases de Servicio estandefinidas en la parte 4, basadas en los modelos de la parte 3. Los roles de las SCP ySCU son definidos aquı y se especifica el comportamiento esperado para cada rol encada servicio. Esto permite a los implementafores y usuarios entender que se esperade un dispositivo que soporta una clase en particular. Para cada Clase de Servicio laoperatividad esta delineada siguiendo la descripcion de las Clases SOP individuales.Para cada papel un proceso puede desempenar los requisitos dados por los dos condetalles del uso de los atributos si es aplicable. Dependiendo del tipo de Clase deServicio (compuesta o normalizada) la descripcion es dando un pequeno contexto ouno detallado. Ası mismo los temas que tienen que ser descritos por cada parte de laClase SOP en la Conformance Statement son listados. La parte 4 utiliza los IODs ylos Servicios definidos en las Partes 3, 7 y 10.

Los IODs utilizados por las Clases SOP son descritos en la Parte 3. Empieza conla descripcion del IOD completo, dividiendolo en los grupos de IODs compuestos ynormalizados. De cada IOD se da una lista de “Information Object Modules”. Laultima parte define los atributos individuales agrupados en detalle en los IOMs. Paralos IODs compuestos todos los detalles son listados en esta parte, para los IODsnormalizados el actual uso de los atributos depende del servicio aplicado y descritoen la parte 4.

En la Parte 5 se describe la codificacion de las Instancias SOP en un conjunto dedatos. Las reglas para las numerosas Representaciones de Valores (Value Representa-tion) y “Transfer Syntaxes” son definidas.

Los Elementos de Servicio utilizados por las Clases SOP son divididos en dospartes, Parte 7 para los Servicios Network y la construccion de secuencias de comandosy Parte 10 para los Servicios Media. En estas partes la codificacion del “networkmessage header” y “media file header” son definidos. El resultado es un mensaje oarchivo que puede ser manejado por el correspondiente mecanismo de intercambio.



Figura 2.21: Relaciones entre las Partes del estandar DICOM.

Los dos grupos de menor nivel tratan con el intercambio fısico de datos. En laParte 8 las cuestiones de Protocolo de Red (Network Protocol) son descritas, la Parte9 define la conexion punto-a-punto (point-to-point conexion) (raramente utilizada) yla Parte 12 define las cuestiones del formato de Physical Media.

Todos los atributos y UIDs definidos por las varias partes del estandar DICOM sonlistadas en el Diccionario de Datos (Data Dictionary) (Parte 6). Es el listado completode todos los elementos de datos junto con sus nombres numericos (o etiqueta), susnombres de texto, cual es su representacion (texto, numero de coma flotante, etc.), siellos contienen uno o mas ıtems (la multiplicidad de valor), y que los valores permitidosestan para esos elementos que pueden contener solo ciertos valores.

Las cuestiones de Conformance son descritas en la Parte 2 incluyendo la maneraen que un Conformance Statement tiene que ser configurado. Los Perfiles de la Apli-cacion 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. Actual-mente, TCP/IP y protocolos ISO-OSI son soportados, pero la naturaleza del serviciosuperior de capa definido en esta parte es tal que se debe posible expandir a otrosprotocolos con facilidad relativa. Una vez fuera de la capa superior de DICOM, elremanente del protocolo de comunicaciones (o TCP / IP u OSI) sigue los patronesexistentes.



2.3.9. Instancias SOP de imagenes DICOM

En el capıtulo precedente, se han explicado los conceptos DICOM sin describir endetalle como se capturan las imagenes dentro de una instancia SOP. En este capıtulose ve con mas profundidad como se estructura la informacion. Se explicara la diferenciaentre los distintos tipos de imagenes, junto a la forma en que el proceso de creacioncrea los datos de la imagen. Finalmente, se vera que manera es la adecuada para usarla informacion creada por un sistema.

Las clases SOP contienen una definicion de objeto (IOD) y servicios para ser apli-cados a ese objeto. En el manejo de los datos de las imagenes, como lo descrito enDICOM, esta solo limitado por la transferencia (clase de almacenamiento SOP) y porel medio de almacenamiento. En este capıtulo, ademas de usar los terminos almace-namiento 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 enotros contextos.

2.3.10. Modelo de informacion de las imagenes

El manejo electronico de la informacion requiere un modelo para representar laforma en que la informacion esta estructurada. Esta estructura es necesaria paratener instancias uniformes y para hacer posible la descripcion de las relaciones entreinstancias de forma clara. Un modelo de informacion de imagen deriva de la formaen que las imagenes se manejan en un departamento de radiologıa. Las imagenesrecogidas de uno u otro aparato, son recopiladas en una carpeta perteneciente alpaciente correspondiente. Las imagenes son ordenadas en la carpeta conforme al tipode examen realizado (series de imagenes que estan relacionadas).

Los usuarios de cada tipo de aparato tienen su propia terminologıa para estaordenacion, como escaner, rodaja, etc. Cuando los datos de las imagenes de diferentesfuentes tienen que ser recogidas en un ambiente unico, debe ser posible ordenar losdatos de las imagenes de diferentes fuentes. Esto es solo posible cuando los datosestan estructurados de acuerdo al mismo modelo de informacion.



Mapping Real World Examinations

El modelo de informacion de imagen DICOM esta basado en suposiciones sobrela forma en que la informacion de diferentes aparatos estan relacionados. Ver figura2.22. Los cuatro niveles de este modelo de informacion son paciente, estudio, serie eimagen.

Figura 2.22: Modelo de informacion

Nivel de paciente

El nivel del paciente contiene la identificacion y la informacion demografica deeste al cual el estudio le pertenece. Debido a que puede existir mas de un estudio, elnivel del paciente es el nivel mas alto (cuando toda la informacion es recogida paraun solo paciente se lleva a una cuenta).

Sin embargo, es de practica normal usar el nivel del estudio para recoger la infor-macion manejada por varios sistemas para un unica respuesta a este estudio.

Nivel de estudio

El nivel de estudio es el nivel mas importante en el modelo de informacion. Unestudio es el resultado de una contestacion a un cierto tipo de examen medico. Todaslas actividades en un departamento de radiologıa se centran en el manejo correcto delestudio. En un estudio, la informacion de identificacion se guarda y puede contenerreferencias a informacion relacionada al mismo estudio en un sistema de adminis-tracion.

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 definidopor el examen realizado. Todos los datos son recogidos juntos en el mismo estudio



principal. Un paciente puede tener muchos estudios como resultado de otros realizadosanteriormente.

Nivel de serie

Despues del nivel de estudio todas las imagenes se recogen. El nivel de serie iden-tifica el tipo de aparato que crea las imagenes, la fecha y el tiempo de creacion de laserie 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 sercuidadosamente considerado. Puede haber palabras que aparentemente signifiquen lomismo, pero se usan con diferencias en distintos contextos. Las series siempre sonuna coleccion de imagenes que provienen de una unico aparato. La forma en quelas 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 estaagrupacion. Sin embargo, varios atributos definiran el tipo de adquisicion y se puedenmostrar en la visualizacion. En algunos casos la relacion entre las imagenes se definemediante la forma en que la adquisicion ha tenido lugar.

Cuando las adquisiciones en una secuencia tienen relacion espacial o temporal, lasimagenes resultantes de esta adquisicion pueden ser agrupadas en series. Una serienueva debe comenzar cuando la relacion existente entre imagenes ya no existe.

Otro criterio para agrupar imagenes puede ser coger los datos de una unica partedel cuerpo hecho durante un estudio completo. Por ejemplo, cuando un aparato pro-duce un numero de imagenes del estomago de un paciente desde diferentes posi-ciones y momentos, las imagenes pueden ser agrupadas en una serie. Algunos sis-temas producen mas de una imagen al hacer una adquisicion de datos. Por ejemplo,algunos escaneres se hacen con un sistema CT, las imagenes reconstruidas desdecada escaneamiento son recogidas en series y tienen relacion espacial. El siguiente es-caneamiento estara en una nueva serie, porque en muchos casos el proceso de escanearse hace desde diferentes posiciones.

Tambien, en una serie, una imagen de referencia puede ser incluida como una de-scripcion de la posicion espacial de las rodajas individuales. Ver figura 2.23. Diferentesreconstrucciones puede ser guardada en diferentes series.

Para cada tipo de aparato medico hay reglas definiendo los contenidos que unaserie debe describir. Las reglas usadas por un sistema dado son parte de un perfil desistema en el estatuto de conformidad 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 imagencontiene la informacion de adquisicion y posicionamiento al igual que los datos propiosde la imagen. Dependiendo del tipo de aparato, el nivel de imagen contiene datos parauna sola imagen, dos imagenes (sistema de dos planos) o una coleccion de imagenescogidas 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 descritosde una sola manera. Por ejemplo, los incrementos en los movimientos del sistemay del tiempo son iguales para todas los marcos. Creando un multiframe images esmas complejo y gasta mas recursos que creando una imagen unica. La relacion entremarcos, la capacidad del aparato y la carga de datos producidos deberıa ser usadapara determinar si se debe aplicar una serie de imagenes simples o un multi marcode imagenes.

2.3.11. Instancias imagen SOP

El modelo de informacion mostrado en la figura 2.22 es una simplificacion delmodelo de informacion completo de imagen DICOM de la figura 2.23 Cada bloque



en este diagrama representa una entidad de informacion (ver IODs) del IOD com-puesto. Las relaciones indican los puntos cardinales para cada relacion de la entidadde informacion usada en una instancia SOP.

Cada instancia de imagen SOP tiene que contener la informacion estructurada deacuerdo al modelo de informacion DICOM. Cada instancia de imagen SOP (simpleo multimarco) es una instancia compuesta SOP que contiene el arbol completo deinformacion del modelo de informacion. Todas las imagenes en una serie son de unmismo 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 almace-namiento) de la informacion pero incremente la carga de datos cuando se transfiereun estudio completo.

En este caso las entidades de informacion del paciente y del estudio tienen multi-ples instancias en la coleccion de las instancias SOP. En contraste, las instanciasnormalizadas SOP (con entidades de informacion simples) usan referencias a otrasentidades de informacion, perteneciendo un protocolo mas eficiente, pero requiriendoun manejo mas complejo.

2.3.12. Relaciones e indentificacion

Cuando se recoge un grupo de Image SOP Instances las cuales tienen relacion entreellas, pero estan creadas desde diferentes aparatos, es importante ser capaz de marcarlas entidades de informacion en diferentes niveles. Son importantes dos aspectos:

1. Todas las modalidades deben tener un mapa (codigo) consistente de como pasarde unos datos de imagen a una instancia SOP.

2. Las entidades de informacion individuales deben contener la identificacion sufi-ciente de hacer un correcto marcado de las entidades de informacion equivalenteen otras instancias SOP.

Estructura de los datos de las imagenes

El primer aspecto requiere que los datos producidos por los aparatos sean orde-nados 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 secuenciadebe ser identificada en un aparato.



Figura 2.24: Modelo de informacion de una imagen compuesta DICOM

Las entidades de informacion sobre el nivel de serie deberıa contener informacionperteneciente al estudio y al paciente que debe ser comparable con la informacion deotros aparatos. La mayorıa de esta informacion viene de fuentes externas como unsistema de planificacion. Puede ser suministrado al aparato por la interfaz de usuarioo mediante una conexion a un sistema de informacion.

Identificacion

Si los datos de imagen tienen que ser almacenados en sistemas los cuales ordenanlos datos examinando el contenido de la informacion de la entidad, debe haber unconsentimiento y un acuerdo para indentificar la informacion de la entidad por todoslos sistemas (aparatos, sistemas de almacenamiento, estaciones de trabajo, etc.) loscuales manejan la informacion.

Visualizar la informacion es mas amplio que solo ordenar imagenes. La identifi-cacion es tambien usada para acceder a los datos desde otros sistemas de informacion.Los sistemas de informacion normalmente usan claves que no necesitan ser interpre-tadas por los seres humanos, pero tienen que ser unicos en el ambiente en el que sonusados.

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



UID, excepto para la entidad de informacion del paciente. La forma en que la infor-macion debe ser identificada se define por otros sistemas de informacion (fuera delvisor DICOM) que tratan con la administracion paciente. En este caso se usa unidentificador ID para el paciente.

Identificacion del estudio

Como el estudio de un examen medico realizado por un doctor es el centro detodas las actividades en un departamento de radiologıa, debe ser reflejada en todaslas piezas de informacion las cuales estan relacionadas con el examen realizado.

Para DICOM esta informacion se identifica al nivel de estudio. En la mayorıa delos casos el atributo UID de la instancia del estudio (Study Instance UID) identifica laentidad del estudio de informacion del estudio perteneciente al resultado del examendel mundo real.

Cuando este UID se usa de una forma consistente por todos los sistemas involucra-dos, no es difıcil relacionar todas las piezas de informacion con los datos de la imagenen la instancia DICOM SOP. Sin embargo, esto requiere una union entre todos lossistemas involucrados para transferir la clave del sistema.

A parte de esta union, los UIDs tienen que ser soportados por todos los otrossistemas, no solo los sistemas involucrados en el manejo de datos de imagenes. Unsistema que genera los UIDs del estudio juega un mayor rol para distribuir el UIDa otros sistemas involucrados. Normalmente, esto deberıa hacerse por un Sistema deInformacion 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 serreemplazada en esos casos por otras claves. RIS usa actualmente una o mas clavespara acceder a su informacion almacenada, numero de registro del estudio, etc. Esasclaves se imprimen en papel que pertenece al estudio. Esta informacion tiene que serincluida en la entidad de informacion del estudio y usada como reemplazo al UID delestudio.

Usar el UID del estudio como union con las partes relacionadas de la informa-cion es un aspecto importante para proporcionar un modelo de informacion DICOMconsistente, el cual puede ser expandido en otras partes de la informacion en undepartamento de radiologıa.

Esta consistencia es muy difıcil de mantener cuando el UID del estudio se reem-plaza por un RIS o un metodo especıfico de identificacion.



Otras identificaciones

A parte de las claves del sistema, los usuarios necesitan acceder a la informaciony quieren usar identificadores que tengan sentido como el nombre del paciente, su dıade nacimiento, fecha del estudio medico, etc.

Los aparatos medicos tienen que proporcionar una informacion lo mas consistenteposible para permitir una identificacion por parte de los humanos. La informacion deidentificacion puede ser proporcionada por una unica fuente cuando una union entresistemas es posible.

Por ejemplo, el RIS da el nombre del paciente, su fecha de nacimiento, etc, comoparte de la informacion para realizar un examen medico. Este metodo previene elerror de maquina y permite una forma mas eficiente de funcionamiento.

2.3.13. Clasificacion de los datos de imagen

El modelo de informacion define el modelo jerarquico de las entidades de informa-cion para dejar claro como la informacion dentro de diferentes instancias SOP puedenser agrupadas en diferentes niveles. En este seccion la informacion de la instancia SOPesta clasificada de acuerdo a las funciones que tiene, pero independientemente de sulugar dentro del modelo de la informacion. Desde luego, hay una fuerte relacion entreel proceso de modelado y el proceso de creacion. La siguiente seccion describe la formade producir los datos de la imagen.

En la figura 2.25 se muestra una descripcion de la clasificacion y la relacion conla arquitectura del sistema de un aparato medico. Las diferentes clases son creadasen diferentes momentos en el tiempo cuando se realiza un examen medico. Cadasubsistema anade atributos al resultado final: la instancia de imagen SOP.

Informacion del paciente

Esta clase contiene informacion sobre el paciente al que se le realiza un estudio. Enun departamento de radiologıa la informacion del paciente se sabe por otras fuentes,como sistemas de informacion o formularios en papel. Solo tiene que ser registradode una manera formal por un numero de atributos como nombre del paciente, ID delpaciente, fecha de nacimiento, etc.

La informacion en esta clase es estable, excepto por la correccion de errores deescritura y cambios de nombre en caso de enlaces matrimoniales, etc. El mantenimien-



Figura 2.25: Clasificacion de la informacion de la imagen

to de esta informacion se hace por sistemas que actuan como fuentes para aparatosmedicos.

Uno o mas atributos son clave para la informacion en otros sistemas de informa-cion. Otros atributos identifican al paciente como una persona o dan mas detallessobre su condicion. Un numero de esos atributos son muy importantes para el proce-so completo de identificacion y conexion a otra informacion en un departamento deradiologıa.

Para permitir la identificacion del paciente y la revision de un estudio, el aparatomedico tiene que incluir esos atributos en las instancias SOP creadas.

Procesos en el hospital tambien tienen que enfrentarse con el manejo de la in-formacion en casos excepcionales. Por ejemplo, cuando un paciente desconocido esexaminado por emergencia, se deben realizar unos pasos para permitir que la infor-macion sea correctamente identificada cuando se conoce el nombre del paciente.



Informacion del estudio

La informacion del estudio es una clase con una mezcla de informacion fuente. Porun lado, la informacion sera suministrada desde un sistema como un RIS (Sistema deInformacion Radiologico) que identifica el estudio a traves de mas de un sistema. Porotro lado, el aparato medico anadira informacion sobre el paciente en el momento enque el estudio se realiza. Informacion de otros sistemas incluyen una identificaciondel estudio. Un UID de una instancia de un estudio es la forma mas eficiente deidentificacion, pero tiene desventajas. Un atributo alternativo, llamado numero deacceso, puede ser usado en un sistema RIS. En el caso de que no este disponible unUID de la instancia del estudio desde fuera de un aparato medico, este tiene quegenerar el UID de forma que garantice que es el unico en el sistema.

Cuando las imagenes de un estudio se copian desde un almacenamiento localpara un destino remoto, es muy importante que se use el mismo UID de la instanciadel estudio. Esto previene la existencia de imagenes con diferentes identificacionesprovinientes un mismo estudio. Tales imagenes nunca pueden ser recogidas juntas sinla intervencion de un operador.

Otra informacion suministrada al aparato medico son los nombres de los medicossolicitantes o la lectura de las imagenes y la informacion del paciente dinamica comola edad, el peso, la ocupacion, etc.

La informacion incluida localmente por el aparato medico identifica el estudioproporcionando un valor para el atributo ID del estudio y la fecha y hora actualdel estudio. El ID del estudio es solo relevante por el aparato usado para realizar elexamen medico.

Informacion de la serie

La clase de informacion de serie es la primera que es completamente generada porel aparato medico. En esta clase el tipo de sistema, la localizacion y la identificaciondel sistema es dada. La identificacian de las series consiste de un UID de la instanciade la serie, que unicamente identifica la serie en los datos de la imagen y una serieen la zona usada ID que puede ser usado para hacer una secuencia con series en unestudio. Los ID de las series tienen solo un significado para el aparato medico ensı mismo, no hay una regla dada para este uso.

Con la informacion de las series, se suministran mas detalles sobre la forma enque 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 sistemausado por esta serie. Incluye informacion sobre la localizacion, la identificacion del



tipo y la serie, cuestiones de calibracion, etc. Estos datos pueden ser compartidospor series pertenecientes al mismo estudio y realizados mediante el mismo aparatomedico.

Se usa un marco de referencia para agrupar imagenes que tienen relacion espacialo temporal. Esto puede ser usado para dividir series en partes o a traves de mas deuna serie si se aplica la misma relacion. Tal relacion se identifica por un UID de marcode referencia compartido entre las imagenes involucradas.

Informacion de la aplicacion

Los atributos en esta clase dan informacion sobre la imagen contenida en la in-stancia SOP requerida para el diagnostico y otras aplicaciones. Varios ejemplos, desdeun simple texto anadido como comentario, hasta detalles como el contraste, terapiay 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 mayorıa de los casos llamado anchurade ventana y centro de ventana (window width y window center), son miembros muyimportantes de esta clase. El VOI es la seleccion fuera de la gama completa de losvalores de pixel que son clınicamente significativos cuando se muestra o se imprime laimagen. Solo el rango especificado tiene que ser convertido a nivel de grises disponibles.

La informacion que dibuja lıneas o agrega el texto a la imagen mostrada puede seren 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 infor-macion separada de los datos de imagen, la imagen puede ser mostrada con o sin lasuperposicion, permitiendo que los datos de imagen puedan ser usados como entradaspara el tratamiento remoto.

Informacion adquirida

En esta clase de informacion se guardan los ajustes del equipo de adquisicion. Elgrado de informacion depende del tipo de aparato y puede tener un rango desde unospocos atributos para un sistema sencillo, a una estructura compleja. Contiene detallesdel sistema de adquisicion como los valores usados de los rayos X por ejemplo.

Las imagenes resultantes de la misma adquisicion pueden ser identificadas con unnumero de adquisicion. Este agrupamiento depende del sistema y puede ser partede series sencillas, pero una adquisicion sencilla puede tambien resultar en multi-ples series de imagenes, cada una con diferentes caracterısticas. La adquisicion no



tiene relacion con el modelo de informacion DICOM y no tiene un identificador UIDequivalente.

Informacion de la posicion

Una clase importante es la informacion dada sobre el posicionamiento de la imagendentro del paciente.

Depende del tipo de aparato medico, de la forma en que se describe la matriz dela imagen posicionada usando terminos sencillos como anterior, posterior, derecha, enfrente, etc. Se debe tener cuidado para asegurar que haya proporcionada informacionsuficiente con la imagen para que no haya visualizaciones ambiguas (sobre todo encuestiones de derecha e izquierda).

En una serie que tiene relacion espacial, como puede ser imagenes CT o MR, mu-chos mas detalles se tienen que suministrar sobre la posicion de las imagenes en elespacio tridimensional del cuerpo del paciente. Esta informacion permite a sistemascomo planificadores de tratamiento de radioterapia usar el posicionamiento tridimen-sional para el procesamiento de los datos de las imagenes.

Otro uso de la informacion del posicionamiento es para sistemas de vasculacionpara describir los movimientos dinamicos.

Informacion de los datos de las imagenes

Finalmente, los datos de las imagenes provenientes del sistema de adquisicion yprocesados para producir imagenes visibles en formato digital. Esta clase describedetalles sobre como los datos de los pıxeles deben ser interpretados, como el tamanode la matriz de pıxeles, el valor representativo de pıxel y como estos estan codificados.

Cuando los aparatos medicos son capaces de generar imagenes en color, tiene queser suministrada la informacion sobre como los datos son ordenados en diferentesplanos. A parte del formato de la informacion, esta clase contiene los datos de lospıxeles en un marco sencillo, en dos marcos para sistemas de dos planos o en mul-timarco. Cuando un multimarco se genera por un sistema de dos planos es posiblealmacenar los marcos de los dos planos juntos. En este caso los marcos de los dosplanos se almacenan alternados (A-B-A-B-...). Para un multimarco las relaciones detiempo entre los marcos individuales se describen mediante otros atributos.

La imagen se identifica unicamente por el UID de la imagen. Como una instanciaSOP de una clase de imagen SOP siempre incluye una porcion de la imagen, el



UID de la imagen se usa tambien como UID de la instancia SOP. Este UID se usapara identificar la instancia cuando se transfiere o se recupera desde un almacen deimagenes o para identificar la entidad de la imagen usandola en un arbol jerarquicode informacion.

2.3.14. Extension de la informacion

Para el almacenamiento de toda la informacion descrita en las clases de arribase definen atributos que se agrupan en IODs (Information Object Definitions) loscuales dan una descripcion generica de las instancias SOP para cada tipo de aparatomedico. Los atributos que se usan actualmente deben ser descritos en el Estatuto deConformidad (perfil del sistema).

No siempre es posible guardar toda la informacion generada por un aparato en unIOD estandar. En casos el equipo tiene nuevos campos los cuales necesitan informacionadicional para alamacenarlos en un nuevo IOD. Se debe tener cuidado en que las partesque usan esta informacion seran capaces de entender esta nueva informacion. Estosdetalles se tienen que publicar en el Estatuto de Conformidad. Si el uso se acepta, lanueva informacion llega a formar parte del estandar.

La extension puede no influenciar la semantica de la informacion guardada enlos atributos estandares. Tiene que ser un subconjunto apropiado, compatible con elIOD del que deriva. En otros casos, el equipo de un vendedor unico, puede anadirinformacion para ser usada solo en la combinacion de sistemas o solo por el mismosistema que ha generado los datos. En esta situacion, no existen detalles sobre lainformacion que tiene que ser publicada en el Estatuto de Conformidad. No hayintencion por otras partes de usar esta informacion adicional.

Para permitir la extension de informacion, DICOM ha definido dos tipos de atrib-utos: atributos estandar y privados.

Los primeros se usan para codificar los atributos descritos en el estandar IOD. Sino hay extensiones o cambios en los IODs, la clase SOP es una clase SOP estandar.

Los segundos definen atributos o usan atributos estandarizados no pertenecientesal IOD de una clase SOP especıfica, no se pude seguir llamando clase estandar SOPy depende del efecto que cambia a uno de los siguientes tipos:

Clase SOP extendida: cuando los atributos adicionales no cambian el uso de laclase SOP. En este caso es un superconjunto, cuando se usa por sistemas loscuales no son conscientes de las anadidos, se pueden ignorar y la imagen puedeser manejada como se dice en la clase SOP estandar. Una clase SOP extendida



usa el mismo UID que la clase SOP estandar. Las diferencias entre las dos clasesse muestra en el Estatuto de Conformidad.

Clase SOP especializada: cuando las adiciones cumplen con el modelo de infor-macion, pero la clase ya no es un superconjunto. Como consecuencia, el UID dela clase SOP estandar puede no ser usado; se debe usar un UID privado paraesta clase SOP. Los socios que manejan las instancias SOP conocen el UID pri-vado y pueden manejar la informacion. Otros no pueden aceptar la clase SOPdurante la negociacion de la asociacion o, cuando se abre un archivo DICOMdesde un medio DICOM.

Clases SOP privadas: no siguen el modelo de informacion DICOM y se usanen un contexto completamente privado. Usan mecanismos proporcionados porDICOM para transferir la informacion. Las clases SOP privadas usan UIDsprivados para prevenir usos incorrectos de la informacion.

Si una de las tres clases SOP arriba mencionadas se definen con la intencion dellegar a ser parte del estandar DICOM, los detalles se publican en el Estatuto deConformidad. De otra forma, solo se usan en un ambiente cerrado.

2.3.15. Tipos de imagenes

DICOM define un numero de tipos de clases de imagenes SOP, dependiendo delaparato medico que crea los datos de las imagenes. Cada tipo tiene su propio IODpara anadir informacion especıfica del aparato a la instancia de la imagen SOP.

Todas las instancias de las imagenes SOP comparten un mınimo juego de infor-macion que permite a una aplicacion visualizadora manejar las imagenes independi-entemente de su tipo.

Una clase de imagen SOP esta disponible para encapsular las imagenes que noestan disponibles en el formato digital y sı capturadas en formato de pelıcula o devıdeo.

Tipos genericos de imagenes

Las instancias de las clases de las imagenes SOP tienen un conjunto basico deatributos; ver figura 2.26. El conjunto mınimo de atributos requeridos para una in-stancia de imagen SOP consiste en el siguiente grupo de atributos:



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 dela instancia SOP).

Tipo de aparato.

Descripcion de la matriz de pıxeles: muestra por pıxel, filas, columnas.

Interpretacion del valor del pıxel: interpretacion fotometrica.

Codificacion de los pıxeles: bits asignados, bits almacenados, bit alto, repre-sentacion de pixel, configuracion plana.

Matriz de pıxeles: datos de pıxel.

Este mınimo conjunto permite mostrar los datos de pıxel y proporciona la identi-ficacion en el nivel de sistema, para el caso de la instancia SOP para adherirla modelode la informacion. Anadiendo mas informacion al menos para los tres primeros nive-les del modelo de informacion, hace mas entendible a la instancia SOP. Los atributosque identifican la instancia SOP para seres humanos y permiten que la imagen seamostrada.

Figura 2.26: Juego basico de atributos de las instancias de imagen SOP

Anadiendo mas informacion para al menos los tres primeros niveles del modelos dela informacon, hace la instancia SOP mas comprensible. Los atributos que identifican



la instancia SOP para los seres humanos y permiten que la imagen sea visualizadacon los correctos ajustes de ventana son:

Nivel de paciente: nombre, ID, dıa de nacimiento, sexo.

Nivel de estudio: fecha del estudio, hora, nombre del medico, ID del estudio,numero de acceso.

Nivel de serie: numero de serie, fabricante, nombre de la institucion.

Nivel de imagen: numero de imagen, tipo de imagen.

Ajustes de presentacion: ancho de ventana, centro de ventana.

Los atributos listados arriba son en la mayorıa de los casos atributos del tipo 2(deben ser suministrados, pero pueden faltar) o del tipo 3 (opcionales).

Tipos de imagenes 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 entregadasobre la adquisicion, etc. El numero de imagenes especializadas esta creciendo porla aparicion de nuevas modalidades. Normalmente, las modalidades siguientes tienenuna definicion de la clase SOP de almacenamiento en el estandar DICOM:

Radiografıa computada IOD (Computed Radiography IOD), usada por los sis-temas radiograficos tradicionales que trabajan con fosforo que brilla al leersecon sistemas como PCR.

Tomografıa computada IOD (Computed Tomography IOD) para escaneres CT.Para este tipo de aparatos el posicionamiento es importante, para montones deimagenes, para crear vistas tridimensionales.

Resonancia magnetica IOD (Magnetic Resonance IOD) para sistemas MR. Aparte de la misma informacion que para escaneres CT tambien se da informacionadicional sobre el protocolo de adquisicion.

Medicina nuclear IOD (Nuclear Medicine IOD) para camaras usan isotoposradiactivos. 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 contienendetalles sobre la posicion y la adquisicion de la imagen. Las imagenes puedenser en color y se puede usar el multimarco.



Angiografıa con rayos-X IOD (X-Ray Angiographic IOD) para sistemas dig-itales cardiologico y basculares. Este formato puede capturar una cadena enmultimarco o imagenes simples.

Radiofluoroscopıa de rayos-X IOD (X-Ray Radiofluoroscopic IOD) para sis-temas 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 cier-tos sistemas. Los modulos se seleccionan, o bien desde un grupo de modulos comunesusados para todos los IODs de almacenamiento SOP, o bien desde modulos especıficospara 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. Enel 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 uti-lizado para el almacenamiento de imagenes en formato diferente al de DICOM, dentrode un ambiente de DICOM convirtiendolas al formato de DICOM. De esta manera lainformacionde la imagen en formato diferente al de DICOM se puede combinar con lainformacion de la imagen de los sistemas DICOM que pertenecen al mismo estudio.

Esta Clase SOP incluye imagenes capturadas de equipos de pelıcula digital, cap-turas de pantallas, etc. El Secondary Capture IOD no contiene ningun detalle sobrela modalidad y la adquisicion de los datos de la imagen. Da solamente los detallessobre como los datos de la imagen fueron capturados.

El IOD permite que la imagen sea manejada como cualquier otra modalidad. Enun numero de casos contiene solamente los valores del nivel de gris de una captura depantalla que pueda verse. Por ejemplo, una imagen hecha con una captura de pantallacontiene solamente los niveles grises en la matriz del pixel (como una fotografıa).

Pero, en otros casos, contiene una matriz verdadera del pixel que necesite un valorde pixel a la conversion de gris, permitiendo la manipulacion de la representacion. Estopermite utilizar la Clase SOP Secundary Capture para almacenar datos de la imagenen modalidades para las cuales no hay IOD estandar disponible. Esto requiere el retirode toda la informacion relacionada modalidad de la adquisicion, de la colocacion yotros. Solamente el paciente, el estudio, la serie, el recubrimiento, y otra informacionadicional que este disponible.



El formato permite la posibilidad de salvar una descarga de pantalla en una modal-idad. Este metodo tiene la desventaja que la matriz de la imagen, en la mayorıa delos casos, no es cuadrada y contiene la informacion del paciente y la otra informacionque es duplicada por las cualidades estandares. Cuando esta exhibido sin medidasespeciales, mostrara la imagen con un formato reducido (en la mayorıa de los otroscasos la zona de visualizacion de la imagen es cuadrada) y mostrara la informaciondel paciente dos veces.

2.3.16. Procesando imagen

Una tuberıa del procesamiento de una imagen describe los pasos del proceso quetraducen la informacion adquirida (por X-Ray, SR., ultrasonidos, equipo, etc.) a unaimagen presentada en un vıdeo o muestra una pelıcula. Algunos de los pasos del pro-ceso dependen del sistema de la adquisicion, otros mejoran la presentacion, o utilizanuna 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 adquisicion que incluyen la conversion a los datosdigitales, correciones, reconstrucciones, etc. Estos pasos estan en la mayorıa delos casos realizados por el sistema de la adquisicion.

Pasos intermedios del proceso para realzar la presentacion o crear la derivaronde imagenes.

Pasos del proceso de la presentacion dando por resultado una imagen que esmostrada o impresa.

Un numero 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 casouna transferencia de la informacion es necesaria. Esto requiere una definicion de lainformacion y un protocolo entre del ambos sistemas. Dos tipos de intercambio deinformacion pueden ser definidos:

Datos procesados de la imagen que necesita solamente la conversion apropiadaa los niveles grises para mostrarla.

Los datos de la imagen convenientes para la transformacion posterior van juntocon los parametros del proceso. Este grupo puede estar partido en:

• usar datos procesados de la imagen o



• Datos “crudos”(Raw) de la imagen que no es conveniente para la exhibicionsin los pasos intermedios del proceso.

Los diversos tipos de pasos del proceso y de los datos transferidos de la imagen semuestran 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 tuberıa del proceso de laimagen 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 substracciondigital, ciertos dominios de filtracion de frecuencia o combinar partes de imagenes auna sola imagen mas grande.

Para este tipo de proceso los datos de la imagen tienen que estar acompanadoscon la informacion de los pasos del proceso para que puedan ser invertidos, proce-sando parametros e indirectamente para los pasos que se realizaran, la adquisicionadicional y colocado de la informacion, etc. Las Instancias SOP usadas para este tipode imagenes, no se piensan para el uso general, ası que una Clase SOP especializadao 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 in-terpretacion incorrecta de una imagen cuando se muestra en diversos sistemas, condiversos metodos y una variedad de entornos. La conversion gris de la escala debecuidarse de todo el comportamiento no linear del dispositivo de exhibicion, del entornoy del ojo humano; vease la figura 2.28.



Figura 2.28: Muestreo

El resultado de los pasos del proceso de la presentacion de una imagen es correctasegun lo interpretado por el usuario del sistema de visualizacion.

La entrada de este proceso de presentacion requiere que los pasos del proceso quepreceden creen valores del pixel de tal manera que todos los valores del pixel tienenun valor significativo unos con respecto a otros. Estos valores dependen del tipo desistema 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 sonsignificativos, 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 usoclınico y se deben presentar junto con la imagen mostrada. Los pasos del procesodeben tener cuidado con los valores proporcionados de pixel en la correcta escala.

Conversion y seleccion de los valores del pixel

En un numero de situaciones los valores del pixel provistos por los pasos prece-dentes (adquisicion e intermedio del proceso) tienen que ser utilizados para la trans-formacion posterior. Esto requiere a veces otra relacion entre los valores de pixel segunlo esperado por los pasos del proceso de la presentacion. Por ejemplo la relacion entrelos valores de pixel estan en una escala logarıtmica y no proporcional a las medidasfısicas. Antes de que la conversion a los niveles grises pueda ocurrir un paso del pro-ceso debe ocurrir, basado en los valores provistos junto con los valores del pixel; veaseel cuadro 2.29.

Segun algunos usos clınicos la exhibicion de la informacion adquirida tiene que ser



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 resultadoes 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 centroy el tamano de la ventana.

Las conversiones y las selecciones antedichas dependen del tipo de de sistemas yel uso de los datos de la imagen. Algunos sistemas aplican ya estos ajustes a los datosde la imagen antes de la transferencia. Otros sistemas transfieren los datos originalesde la imagen con una descripcion de las funciones que se aplicaran por el sistema de lavision. 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 Presentacion

Los pasos de la presentacion convierten los valores del pixel a una imagen exhibidaen la pantalla o pelıcula 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 pelıcula de video debeser 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 imageny tienen que ser almacenadas en la Clase SOP. La funcion pasada es dependiente del



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 gamade los valores del nivel de gris que se aseguran de que el resultado de la correcciondependiente del dispositivo sea igual en diversos sistemas. Estas dos o tres funcionestienen que ser aplicadas a los datos del pixel en un paso de proceso para prevenir laperdida de calidad de la imagen debido a la acumulacion de errores de redondeo encada funcion.

Requisitos para el procesado de la imagen

La conclusion de la seccion anterior conduce al requisito de que los datos proce-sados de la imagen intercambiados entre los sistemas deben contener la suficienteinformacion para dar lugar a imagenes equivalentes cuando estan utilizados en diver-sos sistemas cada uno con su propia correccion del dispositivo. Esta informacion debeser estructurada de una manera tal que permita que una puesta en practica combinetodas 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: paracada gama de los valores de la entrada se almacena un valor de la salida. Unejemplo para una conversion no linear es las curvas redondeadas lisas para latapa y el fondo de una ventana; vease la figura 2.33

La ultima manera de describir una conversion no linear tiene una desventaja im-portante. Introduce cambios precipitados en el valor de la salida cuando la entrada



valora pasos en un lımite 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 permiteque la composicion de las funciones sea realizada en un paso (prevenir la perdida dela calidad de la actual imagen). La carencia de las posibilidades para especificar unafuncion no lineal en forma de un formula matematica es una desventaja importantede las definiciones actuales de DICOM.

Imagenes Procesadas DICOM

Para las imagenes transferidas con DICOM, se definen un numero de modulos quecontienen la informacion para el paso de la presentacion descrita arriba:

Modulo del pixel de la imagen que contiene los valores de la muestra del pix-el, almacenado en una cadena de los datos del pixel, con las cualidades quedescriben la codificacion y el formato de la matriz del pixel.

Modalidad LUT (MOD LUT) con una descripcion de la funcion para la conver-sion. Figura 2.30.

Valor de interes LUT (VOI LUT) con una descripcion de la funcion de selec-cionar una ventana en la gama de los valores del pixel. Figura 2.30.

Sobreponga moduloslos cuales agregan la informacion grafica para ser mostrarque sobrepone la imagen exhibida.

Dependiendo del requerimiento del procesado del modulo MOD LUT, el moduloVOI 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 lasimagenes par ciertas aplicaciones clınicas.

La informacion puede contener lıneas y cırculos para mostrar el campo de interes,o una bitmap con cadenas de caracteres para anotar la informacion en la imagenmostrada. Esta informacion se provee como entidad separada. Cuando esta informa-cion se agrega a los datos del pixel se tienen muchas limitaciones con el uso de losdatos de la imagen. En este caso el valor de algunos de los pixeles se cambia al valordel recubrimiento.

Paso de decodificar

El proceso de descodificacion de la matriz del pixel desde las cadenas del CellPixel, es utilizando dos grupos de cualidades del Image Pixel Module. Vea la figura2.31



Figura 2.31: Decodificacion de los Datos de Pixel

Bits Allocated, Bits Stored, y High Bit para decodificar el Pixel Sample Valuesdesde Pixel Data Stream, y

Filas, columnas, muestras por pixel y configuracion planar para pedir las mues-tras 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 elespacio no ocupado por la celula del pixel. La secuencia de los valores del Sample Pixelse almacenan en la matriz del pixel con la dimension en la columna, fila, muestraspor atributos del pixel. Cuando se utiliza mas de un plano, la configuracion planardescribe 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 valoresde la muestra del pixel: enteros con signo o sin signo.

Paso de Normalizacion

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 esuna gama normalizada de los valores del pixel convenientes para la conversion a losniveles grises y segun que espera para ese tipo de modalidad y de su uso clınico.Por ejemplo, para los Rayos X, la intensidad es proporcional a los valores de pixel,



para los sistemas CT los valores de la muestra del pixel se convierten a la escala deHounsfield, etc.

En caso de que solamente una escala pueda ser utilizada, dos atributos son nece-sarios 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 dela tabla del “look-up”.

Paso de conversion a escala de grises

En la mayorıa de los casos la gama completa de los valores normalizados de lamuestra del pixel tiene que ser reducido a una gama secundaria que contenga la valiosainformacion para el uso de la imagen. En su conversion, esta tiene que ser convertida ala representacion del nivel gris. Para algunos usos mas entonces una gama secundariase selecciona. En ese caso, las ventanas separadas tienen que trazar diversas gamasde niveles grises.

La ventana es descrita por dos atributos. Los dos atributos permiten solamente unaconversion linear del rango seleccionado, la conversion no linear se pueden alcanzarpor medio de una tabla “look-up”. Cuando no se utiliza ninguna tabla, las ventanasson descritas por el valor de centro del pixel (centro de la ventana) y el tamano de laventana (anchura de la ventana); ver figura 2.33.



Figura 2.33: Conversion a escala de grises

Paso de Recubrimiento

Uno o mas modulos separados especifican donde los bitmap del recubrimiento sedeben colocar en la matriz de la imagen. Opcionalmente, el color de los contornospuede ser especificado. Los bitmap que pertenecen a estas imagenes se pueden incluiren 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 losvalores para el contorno del recubrimiento antes de enviar la imagen del nivel gris alpaso siguiente.

Paso de la correccion del dispositivo

Los valores convertidos de la muestra del pixel tienen que ser corregidos paraalcanzar una comprension correcta de la imagen. Las correcciones son el dispositivo yel entorno dependiente y tienen que ser determinadas por el calibrado del dispositivoe incorporando el resultado de la calibracion como funcion de la correccion que seaplicara 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 enuna tabla “look-up” que convierta los valores almacenados del pixel directamenteen una representacion perceptualmente correcta. Esto, sin embargo, funcionara sola-mente cuando todas las funciones se describen y no se almacenan matematicamenteen tablas “look-up”.



2.3.17. Aplicacion de los Datos de las Imagenes

Las Clases SOP de la imagen estan en general generadas en modalidades. Elresultado se muestra en la impresion de la pelıcula. Los sistemas del almacenajeprotegen las imagenes mientras tanto, o archivan estas imagenes para la referenciaulteriormente.

En el intercambio de datos entre los sistemas, cada sistema puede tener diver-sas vistas de la informacion, aunque toda la informacion de la Image SOP Instanceeste transferida entre cada sistema implicado. Incluso cuando un sistema en una cade-na 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 figura2.34.

Figura 2.34: Ciclo de vida de la informacion de una Image SOP Instance

Sistemas de almacenamiento de imagenes

Los sistemas de almacenamiento de imagenes usan un numero de atributos iden-tificatorios para almacenar las instancias de imagen SOP.

En primer lugar, estos atributos se usan para recoger todos los datos de lasimagenes pertenecientes al mismo estudio. La instancia UID del estudio (Study In-stance UID) es el atributo clave. Pero cuando este no se usa consistentemente, setienen que usar otros atributos como el ID del paciente, numero de acceso, etc.

En segundo lugar, unos atributos pueden ser usados por sistemas que quieren en-contrar instancias de imagen SOP en el sistema de almacenamiento. La clave principal



en este caso es la instancia UID del estudio y la instancia UID de la serie. Son posiblestambien busquedas basadas en el nombre del paciente, fecha del estudio, etc.

Para el uso de sistemas de almacenamiento un valor muy significativo para estostipos de atributos se tiene que suministrar por los creadores de la instancia de laimagen SOP. Los atributos que contiene los parametros de adquisicion y los datos dela imagen se almacenan pero no tienen significado para un sistema de almacenamiento.

Estaciones de revision

Una estacion de revision es basicamente usada para visualizar las imagenes hechasen uno o varios aparatos. Recoge o busca las instancias de imagen SOP, en un sistemade almacenamiento, perteneciente a un cierto estudio. Mostrara la imagen junto a lainformacion del paciente, ajustes de adquisicoon, informacion del diagnostico, etc.

Los ajustes para el proceso de presentacion, como los seleccionados en el aparato decaptura, son muy importantes. Cuando los pasos de presentacion se procesan de formacorrecta, los resultados mostrados deberıan ser iguales a los originales mostrados porel aparato medico de captura de la imagen.

Para informacion adicional de otros sistemas, se usan atributos identificadorescomo la instancia UID del estudio.

Estaciones de procesamiento de imagenes

Las estaciones de trabajo capaces de procesar los datos de las imagenes tienen re-querimientos adicionales. Se necesitan los parametros de adquisicion y posicionamien-to para la realizacion de pasos adicionales de procesamiento. Dependiendo del tipode 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 lasimagenes de forma correcta para el procesamiento.

Los resultados de este procesamiento son nuevos datos de pıxeles que son almace-nados en una nueva instancia de imagen SOP que tiene su propio ciclo de vida, en lamayorıa de los casos, relaciones con los datos originales usados por la imagen.



Reutilizacion de datos

Una categorıa final de las aplicaciones es el sistema que ha creado la instancia deimagen SOP. En este caso los datos antiguos de la imagen pueden ser usados cuandohay una nueva visita del mismo paciente con el mismo tipo de examien. Los datosde adquisicion y el posicionamiento pueden ser reutilizados, o la imagen puede servisualizada como una referencia para el nuevo examen.

Categorıas de aplicacion

Como lo mostrado arriba, las exigencias de los sistemas individuales en el ciclode vida de una una instancia de imagen SOP son diferentes. Cuando un sistemaproduce los datos de la imagen, debe estar alerta de que todos los sistemas que estanintentando ser parte del ciclo de vida deben recibir suficiente informacion. El estatutode 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 puedenser divididos en categorıas de aplicacion. Una categorıa alta numerada incluye lacategorıa baja numerada. Se definen las siguientes categorıas:

1. Categorıa de almacenamiento: solo identifica los atributos requeridos.

2. Categorıa de visualizacion: solo se requieren los atributos para una correctapresentacion.

3. Procesamiento simple - medidas de volumen y distancia: requiere algunos atrib-utos mas que describan que informacion esta en la imagen.

4. Procesamiento complejo - sustraccion de imagen y MRP: requiere informacionespecıfica 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 aun hay mucho por hacer. Quiza primero es la demostracion de que DICOMtrabaja como una especificacion y un patron. En los ultimos 2 anos, el RSNA haayudado a este papel. Con un contrato a Mallinckrodt una Institucion de Radiologıapara desarrollar el software, el RSNA, miembros de NEMA, y ACR han trabajadosobre demostraciones de DICOM. Mallinckrodt provee los nodulos centrales de prueba



(CTNS) que trabajan como servidores para retener imagenes y administrar la red.Los fabricantes conectan a estos CTNS para usar su implementacion del Estandarde DICOM, y usando el servicio clases, o envıos, recibe, inquiere, o “imprimen” lasimagenes (imprimir sobre la pelıcula que requiere un procesamiento mojado no esfactible en el area de diagnostico a causa de los requisitos de tuberıa). Los fabricantespueden escoger tambien enviar imagenes, o recibir imagenes de un fabricante diferente.Algunos fabricantes pueden cumplir tambien una conexion al equipamiento en el areaTecnica de documentos de prueba, y algunos pueden mostrar la implementacion dela interfase HIS/RIS con apoyo del servicio de clases (el servicio de direccion clases).Mediante un numero importante de esfuerzos independientes de implementacion, lacalidad del patron en suplementario hace efectiva la interoperatibilidad, que ya se hademostrado. El alcance de la imagen medica se extiende mas alla de las imagenesradiologicas. Endoscopistas, patologos, dentistas, y dermatologos (por nombrar solocuatro justo areas de especialidad) todas trabajan con imagenes como parte de supractica.

Recientemente, los representantes de las sociedades profesionales de estos gruposhan contado con un grupo de trabajo especial de ACR-NEMA para comenzar planifi-cando, como ellos podrıan aprovechar del Trabajo de DICOM. El enfoque de DICOMa objetos orientados a diseno hace este proceso relativamente directo. Los miembrosde las sociedades profesionales pueden proveer la experiencia sobre la construccionapropiada de objetos de informacion, y los grupos de ACR-NEMA pueden entoncesayudar a implementarlos en el estandar de DICOM.

La mayorıa del nuevo equipamiento cardıaco de los laboratorios producen imagenesdigitales, pero como con CT o MR, los fabricantes usan distintos formatos y mediosde almacenaje. El convencional 35 mm de pelıcula evita este problema pero no es unasolucion eficaz en funcion de los costos cuando las imagenes estan en forma digitalpara comenzar.

El almacenado de la informacion sobre alguna forma de medio removible. Esta esnecesaria 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 quepueden un equipo solo. Se ha producido la parte 10 de DICOM que describe el Mediode Almacenaje y el Formato de Archivos. Esta parte son unos conjunto de definicionesde medios independiente. El formato de archivo describe como poner un conjunto dedatos de DICOM en un archivo junto con un directorio para indicar el contenido detales archivos. El formato de archivo incluye un area llamado Preambulo de Archivoque es visto primero por el dispositivo que lee el archivo.

Cada aplicacion que necesita grabar archivos en un medio puede requerir mediosdiferentes. Por ejemplo, la cardiologıa necesita un medio de alta capacidad con accesorapido para pelıcula de cine de 35 mm. Los especialistas de ultrasonidos no cardiacos,sin embargo, probablemente no necesitarıan tan alta capacidad, aunque ellos necesiten



capacidad de cine. Por esto, las partes 11 y 12 de DICOM definiran el Patron deintercambio de Medios a todos la a los niveles. Cada aplicacion tendra un perfilde 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 detransferencia, estructura de directorios, archivo basico senice, formato de medios, y elformato de medio necesitado. Estos perfiles son necesarios en parte porque, aunque lacomunicacion es sobre conexiones de red, la comunicacion fuera de lınea por mediosinhibe el proceso de negociacion.

Sin una duda, DICOM es de los mas ambiciosos proyectos en imagen medicaemprendido por la industria y sociedades profesionales. Es un patron complejo acausa del tamano de su contenido, pero es implementable y util. El estandar ofreceun balance correcto entre el objetivo pragmatico de apoyo de rapida implementacionen productos actuales y una fundacion modular solida que asegura una capacidadpara evolucionar y responder a futuras necesidades. La cantidad de trabajo ya hechasobre DICOM es una parte de la razon del interes desde otras especialidades que usanimagenes. Mediante el uso de la experiencia disponible en sociedades profesionales,han podido definirse objetos informativos y los servicios. Estos pueden hacer uso dela estructura de DICOM para la implementacion.

DICOM se desarrollo con la idea de extension y la expansion, que ya sucede. Apesar de esto, no es la intencion de los desarrolladores de DICOM dirigir toda lainformatica medica. El enfasis, anotado en el nombre, esta la imagen medica. Unade las metas de los desarrolladores de DICOM es que otros deberıan aprovechar eltrabajo ya hecho y los conceptos probados.

2.4. Conclusiones

El estandar es un sistema de gestion de estudios e informes medicos sobre pacientesmuy util para la organizacion de estos. Permite el poder realizar estudios de pacientesque esten a largas distancias y poder intercambiar datos de estudios medicos entrehospitales, clınicas, centros de investigacion,. . .

Para estudiar el estandar a fondo hay que leer varias veces los conceptos, inclusoası pueden haber dudas sobre ciertos temas que trata DICOM.

DICOM a medida que pasa el tiempo se va afianzando mas en el campo de lamedicina digital, ya que es el mejor soporte para el intercambio de imagenes digitalespor la red.


Capıtulo 3

Librerıas DCMTK de Offis

[KURA]

3.1. Introduccion

La tecnologıa de la informacion y la comunicacion poco a poco esta llegando a seromnipresente en el cuidado de la salud. Los requerimientos para un rapido acceso alos datos medicos en el momento necesario solo se puede conseguir mediante los stan-dards. El standard de DICOM facilita el intercambio y el procesamiento de imagenesbiomedicas de forma digital. Los aparatos de adquisicion de imagenes, archivos deimagenes y las estaciones de trabajo de diferentes vendedores, pueden estar conec-tadas en una infraestructura comun e integradas con otros sistemas de informacion(HIS/RIS). Nuevas oportunidades se alzan, no solo dentro del hospital,si no tam-bien para el intercambio de informacion entre diferentes clınicas y entre hospitales ycentros de investigacion.

3.2. Estandarizacion de la Comunicacion de Ima-

genes Medicas

Las tecnologıas de informacion y comunicacion de las imagenes medicas esta cadavez mas presente en los dominios administrativos de los hospitales. La velocidad de losavances en soportes tecnologicos estan opuestos al requerimiento de una disponibili-dad a largo plazo de datos medicos. El salvaguardar las inversiones para un numeroapropiado de anos es tambien un requisito indispensable dado el aumento de los costes

77

CAPITULO 3. LIBRERIAS DCMTK DE OFFIS Fernando Ballesteros Herranz

del sector de la medicina.

Estos requisitos pueden ser resueltos solamente con estandares. Desde que el sectorde medicina esta distribuido y estructurado, la estandardizacion de interfaces desdeniveles bajos a niveles tecnicos es de gran importancia, tambien para el desarrollo denuevos servicios, como por ejemplo la telemedicina.

Las siguientes organizaciones internacionales estan desarrollando el estandar parala medicina informatica:

1. El Comite DICOMEl Comite DICOM ha publicado el estandar DICOM, que ha llegado a ser elmas importante estandar de las imagenes medicas.

2. Comite Europeo de NormalizacionEl Comite Tecnico CEN/TC251 “Informatica de la salud” es un Comite Eu-ropeo para la estandarizacion de modelos de informacion desarrollados por lossistemas de informacion medica, estandar para el conocimiento de representa-ciones y terminologias, y para la seguridad y porteccion de las imagenes y proce-samiento de senales en medicina.

3. Organizacion internacional para la estandarizacionEl Comite ISO ISO/TC215 “Informatica de la salud” fue fundada en 1998 conun alcance similar al de CEN/TC252, pero no limitado a Europa solo. En esteComite, los modelos para los sistemas de informacion medica, ası como losestandares para el conocimiento de la representacion, terminologıa, seguridaden medicina seran desarrollados, basado en parte en los estandares de CEN.

3.3. Descripcion de DICOM segun Offis

La adquisicion de imagenes por aparatos, datos de imagenes, estaciones de tra-bajo, etc. de diferentes vendedores se pueden conectar en una infraestructura comunintegrada con otros sistemas de informacion.

DICOM facilita el intercambio y procesamiento de imagenes medicas en formadigital, ası la informacion puede ser intercambiada entre hospitales, clınicas,. . .

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.


Fernando Ballesteros Herranz 3.3. DESCRIPCION DE DICOM SEGUN OFFIS

Formatos para el almacenamiento en intercambios.

Requiere conformidad entre aparatos y aplicaciones.

Estructuras de datos, formatos para las imagenes medicas digitales con sus datosrelacionados.

3.3.1. Estructura de los datos en el estandar 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 deque dos aplicaciones DICOM puedan intercambiar informacion, estos deben establecerla 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 comunicacion

Ademas de la comunicacion de imagenes medicas sobre la red, el intercambiode medios de comunicacion se ha hecho hueco en DICOM que fue integrado en elestandar en 1996. Los campos de aplicacion son por ejemplo el almacenaje de pelıculasde angiografıas en la cardiologıa o el almacenaje de imagenes de ultrasonido. Paraasegurarse de que los medios de comunicacion de almacenaje DICOM son realmenteintercambiables, el estandar define los llamados “perfiles de aplicacion” que define:



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 losarchivos de imagen. Este directorio contiene la informacion mas importante (el nombrepaciente, la modalidad, identificadores unicos, etc.) para todas las imagenes en elmedio. Esto permite hojear o buscar rapidamente a traves de todas las imagenes delmedio sin tener que leer el archivo imagen completo.

3.3.4. Declaracion de Conformidad

DICOM requiere que una “Declaracion de Conformidad” (Conformance State-ment) sea escrita para cada dispositivo o aplicacion desarrollada con DICOM. Elformato y el contenido de esta declaracion son definidos en el estandar. Esto explicaque servicios DICOM y opciones son soportados, que extensiones y particularidadeshan sido puestas en practica por el vendedor, y como el dispositivo se comunica conotros sistemas DICOM. En la teorıa, comparando dos declaraciones de conformidadpermite determinar si dos dispositivos DICOM son capaces de comunicarse el unocon otro. En la practica, sin embargo, las declaraciones de conformidad son solo com-prensibles para expertos y son con frecuencia inadecuados.

DICOM ha llegado a ser un indispensable componente para la integracion desistemas de imagenes digitales en medicina. DICOM ofrece soluciones para una mul-titud de comunicaciones relacinados con las aplicaciones. La palabra “DICOM” porsi misma no garantiza una integracion “de enchufar y listo” de todos los sistemas deinformacion de un hospital. Esto requiere una combinacion cuidadosa de todas lassoluciones parciales ofrecidas por DICOM.

3.4. Librerıas DCMTK

[ANDRE] [BATE] [CEBAL99] [CEBAL00] [KRUG]

DCMTK es una coleccion de librerıas y aplicaciones que implementan partes delestandar DICOM. DCMTK incluye el software necesario para el examen, la con-struccion y la conversion de archivos de imagen DICOM, manejando los medios decomunicacion, enviando y reciviendo imagenes sobre la conexion network, ası co-mo la demostracion de almacenaje de imagenes y bases de datos. Estas librerias


Fernando Ballesteros Herranz 3.4. LIBRERIAS DCMTK

son un completo codigo fuente y han sido escritas en una mezcla de ANSI C yC++. 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 proovedorcentral, vendedor independiente, almacenaje de imagen y servidores worklist. Es usadopor hospitales y empresas en todo el mundo para una amplia variedad de propositosdesde ser una herramienta para pruebas de productos, a ser un componente basicopara proyectos de investigacion, prototipos y productos comerciales.

El software DCMTK puede ser compilado bajo el Windows NT o una amplia gamade sistemas operativos Unix que incluyen Linux, Solaris, OSF/1, IRIX, FreeBSD yMacOS X. Todo lo necesario para la configuracion y los makefiles son sumnirados. Lapagina oficial de Offis es www.offis.de

3.4.1. Instalacion de librerıas

El archivo necesario para la instalacion del Toolkit de Offis, depende del sis-tema operativo que estemos utilizando, si es Windows el archivo a descargar esdcmtk351.zip, y si es un sistema UNIX es dcmtk351.tar.gz. La instalacion descritaesta 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 paginawww.offis.de

2. Se abre el proyecto dcmtk.dsp, que se encuentra en X:\. . . \Toolkit\source\dcmtky se compila y linka con el Visual C++ 6, lo que genera los archivos .obj y las li-brerıas (.lib) en la carpeta “OpenSSL” que hay en cada carpeta de las funcionesexistentes en este Toolkit, las cuales pueden ser utilizadas en otros proyectosincluyendolas en ellos.

3. Para poder generar los ejecutables de cada funcion, hay que incluir los ficheros decabezeras (.h) al Visual C++ 6. Aquı pinchando en Tools->Options->Directories->Include files, se pueden incluir todos .h del Toolkit, tan solo poniendo el Pathen el que se encuentran, por ejemplo: C:\Archivos de programa\Microsoft Vi-sual Studio\My Proyect\dcmtk351\dcmtk\dcmnet\include.

4. Tambien es necesario dar el path donde se encuentran los .lib, que se hacepinchando 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.


http://dicom.offis.de/dcmtk.php.en

http://www.offis.de

http://www.offis.de


5. Para incluir las librerıas en los proyectos hacer click en Proyect->Settings->Link,y escribir la librerıa a incluir (por ejemplo: dcmnet.lib) antes de /nologo. De estaforma si queremos generar el ejecutable de un fuente lo compilamos y linkamos.

Este Toolkit tiene diferentes funciones basadas en el estandar Dicom. Las funcionesson agrupadas en carpetas dependiendo de la funcion que desempenen. Vease la figura3.1.

Config: Incluye los ficheros .h necesarios para la configuracion del toolkit.

Dcmdata: Contiene funciones para el tratamiento de los datos de los archivosDicom 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 DICOMa 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 pre-sentacion

Dcmsing: Para la creacion o supresion de una firma digital para un archivoDicom y su verificacion.

Dcmsr: Para la conversion de documentos Dicom SR (Structured Reporting) aHTML, 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 compresiona Jpeg.



Figura 3.1: Librerıas DCMTK

3.4.2. Dcmnet

Esta carpeta tiene las funciones para la conexion entre varias maquinas para crearuna asociacion entre ellas y poder transmitir los datos de los objetos DICOM.

Echoscu: Esta aplicacion implementa un Service Class User (SCU) para la ver-ificacion SOP Class. Envıa un mensage Dicom C-ECHO a un Service ClassProvider (SCP) y espera una respuesta.

Findscu: Esta aplicacion implementa un Service Class Query/Rerieve (peti-cion/recuperacion) y un Service Class Basic Worklist Management. Solo soportael mensage Dicom C-FIND, que envıa una peticion al SCP y espera respuesta.

Movescu: Esta aplicacion implementa un SCP para el Service Class Query/Retrievey un SCU para el Storage Service Class. Para usar la funcionalidad Retrieve(Recuperacion) usa el mensage Dicom C-MOVE que envıa una peticion al SCP yespera respuesta. El SCP aceptara la asociacion para recibir imagenes enviadascomo 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 Ser-vice Class. Se pone a la escucha sobre un especıfico puerto TCP/IP, para laspeticiones de asociacion que puedan llegar de un Storage SCU y puede recibirimagenes segun el Storage Service Class.

Storescu: Implementa un Service Class User (SCU) para el Storage Service



Class. Se usa para transmitir imagenes Dicom. Envıa un mensage C-STORE aun Storage SCP y espera respuesta.

Aplicacion para ver la conectividad entre dos maquinas

Esta aplicacion es realizada sobre dos maquinas, una sera Galileo que actuara deSCP y otra sera Gauss que sera el SCU. Pondremos la opcion -v la cual nos dira entodo 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 lallegada de asociaciones.

Galileo:\ storescp -v 104

Paso 2o: La siguiente instruccion es para comenzar una aplicacion Dicom Verifi-cation Service Class User. Esto intenta construir una asociacion Dicom con una apli-cacion que corra sobre Galileo, conectandolos por el puerto 104. Gauss enviara unapeticion C-ECHO y estara a la espera de una respuesta C-ECHO de Galileo. Esto essolo para verificar que hay conexion entre las dos maquinas.

Gauss:\ echoscu -v Galileo 104

Paso3o: Se envıa una imagen Dicom a Galileo (SCP), volviendo a intentar realizaruna asociacion Dicom con una aplicacion que corra sobre Galileo. Es enviada unapeticion C-STORE que contiene una imagen Dicom “craneo.dcm” y se espera unarespuesta 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 escuchadel puerto 104. Por ejemplo si se hace en un fichero C:\Dicom, la imagen es guardadaen ese fichero. El nombre que tiene la nueva imagen copiada en Gauss, es a priori suUID, que es unico entre todas las images DICOM quetiene la maquina.



3.4.3. Dcmjpeg

Esta carpeta tiene las funciones para la compresion con y sin perdidas de imagenesjpeg.

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 segunlas opciones del procesamiento de imagenes seleccionadas, PPM/PGM, BMP,TIFF o JPEG.

Dcmmkdir: Crea un archivo DICOMDIR de los archivos DICOM especificadossegun la aplicacion Media de almacenaje.

3.4.4. DicomScope

El DicomScope es un programa desarrollado en C++ con un GUI en Java, utilizalas funciones DICOM dadas por las librerıas DCMTK. Permite visualizar, imprimir,almacenar, transmitir y recibir estudios, imagenes, estados de presentacion1 e informesestructurados2. Los informes estructurados (SR) consisten en informes completos dediagnostico 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 apli-cacion donde se encuentran los estudios (imagenes, structured reports,...) de laaplicacion.

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 transmisionde archivos Dicom.

1Presentation states2Structured Reports



Instalacion

Es necesario para la instalacion un sistema compatible con Java y Windows 32bits, para esto ha y que descargar de internet la Maquina Virtual de Java. Antes de lainstalacion del DicomScope es necesaria la instalacion de Java 2 SDK o JRE(Java 2Runtime 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 instruccionesdadas.

Browser

Es la base de datos del DicomScope donde se almacenan los estudios Dicom. Tieneuna estructura de arbol en la que cada estudio es una rama, y puede tener varias ramasa su vez, puede tener imagenes, informes estructurados, imagenes de escalas de grisesy estados de presentacion.

Figura 3.2: Base de Datos

Los nuevos estudios recibidos por Red o almacenados en la aplicacion, se difer-encian de los otros porque aparece un sımbolo de“New” a su izquierda, una vezvisualizados estos, perderan el sımbolo. Figura 3.2

Para enviar estudios a otra maquina, se elige el estudio que se quiere enviar y sepresiona la tecla send, entonces se abre una ventana en la que hay que se elige laforma de enviar los estudios. Hay tres formas:


http://java.sun.com/j2se/1.4.1/download.html.


1. Transmision insegura, sin proteccion de los datos en transito.

2. Transmision TLS3 , en la que se utilizan certificados para la transmision dedatos.

3. Transmision TLS y encriptacion.

Para poder configurar a que maquinas son enviados los estudios y que puertose utiliza para la asociacion, se hace mediante el archivo “DICOMscope.cfg” que seencuentra en X:\. . . \DICOMscope351, escribiendo a que hostname quiere ser enviadoy el port.

Este archivo DICOMscope.cfg, es un archivo de configuracion, en el que se puedeconfigurar 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 dela transmision de datos por la red. Con ello se puede variar el tıtulo de la asociacionpara la conexion entre maquinas, el hostname al que se van a enviar los objetosDicom, el puerto a utilizar en la comunicacion, si se utiliza el soporte TLS para unacomunicacion segura, etc.

Una cuestion importante en los archivos de configuracion es que las lıneas queempiezan por # son comentarios y estas no son consideradas para la configuracion dela 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 escomo sigue a continuacion:

3Transport Layer Security



GAUSSType = StorageAetitle = StorageHostname = GalileoMaxPDU = 32768Port = 10004ImplicitOnly = falseDisableNewVRs = false

Figura 3.4: Viewer

GALILEOType = StorageAetitle = StorageHostname = GaussMaxPDU = 32768Port = 10004ImplicitOnly = falseDisableNewVRs = falseBitPreservingMode = false

Viewer

Todas las instancias Dicom que se carguan, pasan a verse en el Viewer. Es una her-ramienta para tratar las imagenes Dicom y cambiar y editar informes estructurados,



incluso para verificarlos y crear firmas digitales. Ver figura 3.4

Print

Pueden ser enviadas imagenes Dicom a imprimir desde el Browser o la imagenque se visualiza en el Viewer. Esto lleva la imagen al Print en el que se visualiza laimagen 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. Aliniciar 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 contransmision 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 aeste equipo, utilizando el puerto 10004.

El otro proceso recibe las instancias Dicom utilizando TLS, de esta forma latransmision de datos es segura. Tambien utiliza la orden C-STORESCP y elpuerto elegido es el 10007.



Figura 3.6: Process Log

3.5. Conclusiones

Las librerıas desarrolladas por Offis, implementan un gran numero de funcionesdel estandar DICOM. Son unas librerıas utilizadas por un gran numero de personasque estan desarrollando aplicaciones con el estandar.

La gran ventaja de estas librerıas es que son un producto “freeware”, es decir, queson un producto gratuito.

Estas librerıas estan desarrolladas enteramente en C/C++ y no es codigo facil elque implementan, por esto es muy difıcil trabajar con estas librerıas ya que hay queanadirle que se trabaja basandose en DICOM que es un estandar que hay que leervarias veces para poder entenderlo completamente.

Son muy utiles para gente experta en C++ y Dicom, pero de lo contrario si seintenta trabajar con estas librerıas sin reunir uno de los dos requisitos puede llegar aser muy pesado.


Capıtulo 4

Programacion en JAVA

[BOBA00] [BOBA01] [LEMA] [PAJ] [JDK]

4.1. Introduccion

Java surgio en 1991 cuando un grupo de ingenieros de Sun Microsystems trataronde disenar un nuevo lenguaje de programacion destinado a electrodomesticos. Debidoa la existencia de distintos tipos de CPUs y a los continuos cambios, era importanteconseguir una herramienta independiente del tipo de CPU utilizada. Se ejecuta sobreuna “maquina hipotetica o virtual” denominada Java Virtual Machine (JVM)1. Esla JVM quien interpreta el codigo neutro convirtiendolo a codigo particular de laCPU utilizada. Cualquier aplicacion que se desarrolle “cuelga” (o se apoya, seguncomo se quiera ver) en un gran numero de clases preexistentes (el API o ApplicationProgramming Interface de Java).

La ejecucion de programas en Java tiene muchas posibilidades: ejecucion comoaplicacion independiente (Stand-alone Application), ejecucion como applet, ejecucioncomo servlet, etc.. Un applet es una aplicacion especial que se ejecuta dentro de unnavegador o browser (por ejemplo Netscape Navigator o Internet Explorer) al cargaruna pagina HTML desde un servidor Web. El applet se descarga desde el servidor yno requiere instalacion en el ordenador donde se encuentra el browser. Un servlet esuna aplicacion sin interface grafica que se ejecuta en un servidor de Internet.

Java permite facilmente el desarrollo tanto de arquitecturas cliente-servidor comode aplicaciones distribuidas, consistentes en crear aplicaciones capaces de conectarsea otros ordenadores y ejecutar tareas en varios ordenadores simultaneamente.

1Maquina Virtual de Java

91

CAPITULO 4. PROGRAMACION EN JAVA Fernando Ballesteros Herranz

Figura 4.1: Evolucion de Java

En definitiva Java es un lenguaje de programacion orientado a objetos, interpre-tado, independiente de la arquitectura y portable, fuertemente tipado, con gestionautomatica de la memoria (recogida de basura), con gestion de excepciones y concur-rencia (multihilo) y principalmente con las caracterısticas de encapsulacion, herenciay polimorfismo.

El lenguaje Java es un lenguaje sencillo extendido mediante una serie de bibliotecaso packages (paquetes), entre ellos los mas comunes son:

Package lang: clase con funcionaliddes basicas. E/S, excepciones, hilos.

Package util: Utilidades (numeros 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. Instalacion de la JVM

Hay dos instalaciones posibles de la JVM, o bien la instalacion del JRE2, la cualsirve para que se puedan ejecutar las apliaciones desarrolladas en Java pero no posee

2Java Runtime Environment


Fernando Ballesteros Herranz 4.2. INSTALACION DE LA JVM

Figura 4.2: Bibliotecas de clases de Java

compilador para los ficheros fuente, o bien la instalacion del SDK que si tiene compi-lador para desarrollar aplicaciones.

Para el desarrollo de aplicaciones en Java, la instalacion debe comprender el SDKque es un software libre y puede ser descargado de http://java.sun.com. Al instalarel SDK, se crea una carpeta en el directorio raız (j2sdk1.4.1_03)3, y dentro de estahay otra llamada “bin” que es la que contiene el compilador.

El siguiente paso es dar el PATH al compilador y crear un CLASSPATH quecontenga las librerıas que vaya a utilizar el compilador. Los pasos a seguir difierendependiendo 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 pestanaAvanzado y click en Variables de Entorno.

2. En variables del sistema ir a la variable Path y escribir seguido a lo que haya elcamino 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 ennombre de variable:

CLASSPATH

y en valor de variable el camino hasta la carpeta lib donde esta dt.jar que sonlas clases del JDK:

C:\j2sdk1.4.1_03\lib\dt.jar;.;

3Para la version 1.4.1


http://java.sun.com/j2se/1.4.2/download.html


el valor de ;.; es para poder compilar cualquier fichero fuente desde cualquierdirectorio y no deba ser desde el directorio donde esta el compilador.

Los pasos a seguir en un sistema Windows´9X o MSDOS:

1. Abrir el fichero Autoexec.bat que se encuentra en el directorio Raız del sistema,pinchando en el con el boton derecho del raton y dejando pulsada la tecla Shift,de esta forma sale el menu contextual con la opcion “Abrir con. . . ”, se pinchaesta opcion y se elige un editor de texto (por ejemplo el WordPad).

2. Una vez abierto en la lınea de SET PATH hay que incluir la carpeta del com-pilador:

SET PATH = . . . ;C:\J2SDK1.4.1-_03\Bin;%PATH%

3. Crear el CLASSPATH y dar le localizacion de las librerıas del JDK, para elloescribir 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 analisisdel sintaxis del codigo escrito en los ficheros fuente de Java (con extension *.ja-va). Si no encuentra errores en el codigo genera los ficheros compilados (con exten-sion *.class).En el JDK de Sun dicho compilador se llama javac.exe. Java.exe es elinterprete para sistemas PC/Windows. Appletviewer.exe es un visualizador de applets.

Una vez compilado no deberıa ser necesaria ninguna modificacion por el hechode cambiar de procesador o de ejecutarlo en otra maquina. La clave consistio endesarrollar un codigo “neutro” el cual estuviera preparado para ser ejecutado sobrela JVM.

Para realizar una aplicacion con el compilador del SDK, se debe escribir el codigoen Java en un editor de texto cualquiera como puede ser el “Bloc de Notas”. Una vezescrito debe ser guardado el fichero con extension .java, por ejemplo nombre.java. Lacompilacion debe realizarse con un “shell” de comandos, como el del MSDOS. Pararealizar la compilacion escribir:

4JDK para las antiguas versiones y SDK para las nuevas versiones


Fernando Ballesteros Herranz 4.4. VARIABLES Y TIPOS DE DATOS

X:\. . . \javac nombre.java

Con la compilacion se genera un archivo .class, en este caso serıa 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. Verfigura 4.3

Figura 4.3: Compilacion y ejecucion

Java Sun ha realizado un API para la ayuda y consulta de las clases que sepueden utilizar con el SDK. Esta ayuda es de importancia vital para el buen uso ycomprension de java. Ver http://java.sun.com

4.4. Variables y tipos de datos

4.4.1. Comentarios

Permiten documentar el codigo haciendolo mas legible a los progamadores.

//Comentario de una sola lınea

/* Comentario que

aparece en varias lıneas*/


http://java.sun.com/j2se/1.4.1/docs/api/


4.4.2. Identificadores

Los identificadores se utilizan como nombres de clase, metodo y variable. Un iden-tificador puede ser cualquier sentencia descriptiva de letras en mayuscula o minuscula,numeros y los sımbolos (_) y ($). Java diferencia entre mayusculas y minusculas, loque 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 Javase ha reservado para controlar como esta definido su programa. Se utilizan para iden-tificar los tipos, modificadores y mecanismos para control de secuencia incorporados.Estas palabras clave solo se pueden utilizar para su proposito original y no se puedenutilizar 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. Unavariable 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 nombrede una clase o interfaz.


Fernando Ballesteros Herranz 4.4. VARIABLES Y TIPOS DE DATOS

Los bloques de sentencias compuestas en Java se delimitan con dos llaves . Lasvariables de Java solo son validas desde el punto donde estan declaradas hasta el finalde la sentencia compuesta que la engloba. Se pueden anidar estas sentencias com-puestas y cada una puede contener su propio conjunto de declaraciones de variableslocales. Sin embargo, no se puede declarar una variable con el mismo nombre que unade un ambito superior.

Tipos

Enteros que son todos los tipos numericos de Java son valores con signo. Estaausencia de signo reduce el numero de tipos de entero a cuatro:

• byte es un tipo de 8 bits con signo. Su rango comprende desde -128 a 127.Sudeclaracion puede ser:

byte b;

byte c = 0x55;

• short es un tipo de 16 bits con signo. Su rango comprende desde -32768 a32767. Declaracion:

short s;

short t = 0x55aa;

• int es un tipo de 32 bits con signo. Su rango comprende desde -2.147.483.648a 2.147.483.647. Es el tipo mas utilizado habitualmente para almacenarvalores enteros simples.

int n;

int m = 10;

• long es un tipo de 64 bits con signo. Hay algunas ocasiones en las queun tipo int no es lo suficientemente grande como para guardar un valordeseado.

long j;

Los numeros en coma flotante, tambien conocidos como numeros reales en otroslenguajes, se utilizan cuando se calculan funciones que requieren precision frac-cionaria. 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



boolean p;

Caracteres, dado que Java utiliza Unicode para representar los caracteres deuna 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 almacenarese valor en una variable de un tipo diferente. En algunos tipos es posible almacenarsimplemente el valor sin una conversion de tipos; lo que se denomina conversionautomatica. Esto solo es posible en Java si el compilador reconoce que la variabledestino tiene la suficiente precision para contener el valor origen, como almacenar unvalor byte en una variable int. A esto se le llama ensanchamiento o promocion, dadoque el tipo mas pequeno se ensancha o promociona al tipo compatible mas grande. Sipor el contrario, se desea asignar un valor de variable int a una variable byte se necesitarealizar una conversion de tipos explıcita. A esto se le llama estrechamiento, dado quese estrecha explıcitamente el valor para que quepa en el destino. La conversion de untipo 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 mismotipo. Si se desea crear una matriz de doce enteros, se crea un tipo especial, que esuna “matriz de int”.

int days[];

Para las matrices, hay un valor especial llamado null, que representa una matriz sinningun valor. Se debe utilizar un operador especial, “new” (nuevo), para asignar elespacio de una matriz. Para utilizar el operador “new” se debe promocionar un tipoy un numero entero no negativo de elementos a asignar.

days = new int[12];


Fernando Ballesteros Herranz 4.5. OPERADORES

4.5. Operadores

Los operadores de Java son caracteres especiales que le dicen al compilador quese desea realizar una operacion sobre algunos operandos.

4.5.1. Operadores aritmeticos

Los operadores aritmeticos se utilizan para operaciones matematicas, exactamentede la misma manera en la que estan definidos en algebra. Los operandos deben sertipo numerico. No se pueden utilizar estos operadores con tipos “boolean”, pero sepueden utilizar con tipos “char”, dado que el tipo “char” en Java es un subconjuntode “int”.

Suma: +

Resta: -

Multiplicacion: *

Division: /

Resto: %

Operadores aritmeticos unitarios

Preincremento: ++x

Postincremento: x++

Predecremento: - -x

Postdecremento: x- -

4.5.2. Operadores de asignacion

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



4.5.3. Operadores a nivel de bit

Los tipos numericos enteros, long, int, short, char y byte tienen un conjunto adi-cional de operadores que pueden modificar e inspeccionar los bits que componen susvalores.

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 ambosoperandos 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 cualquierade 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 cualquierade los operandos es un 1, pero no ambos, y cero en caso contrario.

El operador desplazamiento a la izquierda, ((, mueve hacia la izquierda todos losbits del operando de la izquierda un numero de posiciones de bit especificadoen el operando de la derecha. Al realizarse el desplazamiento se pierden por elextremo izquierdo del operando el numero de bits desplazados y se rellena eloperando con ceros por la derecha el mismo numero de bits.

)) El operador desplazamiento a la derecha, )), mueve hacia la derecha todos losbits del operando de la izquierda un numero de posiciones de bit especificadopor el operando de la derecha.

4.5.4. Operadores relacionales

Para comparar dos valores, Java tiene el siguiente conjunto de operadores relacionalesque describen igualdad y ordenamiento. Ver figura 4.5


Fernando Ballesteros Herranz 4.6. CONTROL DEL FLUJO

Figura 4.5: Operaderes relacionales

4.5.5. Operadores logicos booleanos

Todos los operadores logicos booleanos combinan dos valores boolean para darcomo 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 provocarque el flujo de la ejecucion avance y se ramifique en funcion de los cambios de estadode los datos.

4.6.1. Instruccion condicional if-else

La construccion “if-else” provoca que la ejecucion atraviese un conjunto de estadosboolean que determinan que se ejecuten distintos fragmentos de codigo.



if ( expresion-booleana ) sentencia1; [ else sentencia2; ]}

La clausula else es opcional. Cada una de las sentencias puede ser una sentenciacompuesta encerrada entre llaves, { }. Una expresion-booleana es cualquier expre-sion que devuelve un valor boolean. Podrıa ser una variable simple declarada comoboolean.

boolean datosdisponibles;

if (datosdisponibles)

ProcesarDatos();

else

esperarAMasDatos();

4.6.2. Instruccion condicional switch

La sentencia switch proporciona una forma limpia de dirigir la ejecucion a partesdiferentes del codigo en base al valor de una variable o expresion. Esta es la formageneral de la sentencia switch:

switch ( expresion ){

case valor1:

instrucciones;

break;

case valor2:

instrucciones;

break;

default:

}

El valor de expresion se compara con cada uno de los valores literales de las sen-tencias 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 defec-to). 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, laejecucion continuara en el siguiente case. . La sentencia “break” de Java esta disenadapara cubrir aquellos casos en los que saltar arbitrariamente a una porcion de codigoes una constuccion valiosa y legıtima para el control del flujo. El termino break serefiere al acto de salirse de un bloque de codigo. Le dice al interprete que retome laejecucion pasado el final del bloque.


Fernando Ballesteros Herranz 4.6. CONTROL DEL FLUJO

4.6.3. Bucles

Un bucle es lo que llamamos ejecutar repetidamente el mismo bloque de codigohasta que cumpla una condicion de terminacion. Hay cuatro partes en cualquier bucle,inicializacion, cuerpo, iteracion y terminacion . La inicializacion es el codigo queestablece las condiciones iniciales de un bucle. El cuerpo es la sentencia que queremosrepetir. La iteracion es el codigo que queremos ejecutar despues de cuerpo, pero antesde entrar de nuevo en el bucle. Se utiliza a menudo para incrementar o decrementarcontadores e ındices. La terminacion es la expresion booleana que comprueba cadavez a lo largo de un bucle para ver si ha llegado el momento de parar de iterar. Javatiene tres construcciones para bucles: while, do-while y for.

Bucle while

Ejecuta una sentencia repetidamente mientras una expresion booleana sea ver-dadera. Esta es su forma general:

[ inicializacion; ]

while ( terminacion ) {

cuerpo;

[ iteracion; ]

}

Las partes inicializacion e iteracion son opcionales, y mientras la expresion termi-nacion 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 unbucle while al menos una vez, incluso si la expresion booleana tiene el valor false laprimera vez. Es decir si se desea evaluar la expresion de terminacion al final del bucleen vez de al principio como en el while.

[ inicializacion; ]

do { cuerpo; [ iteracion; ] } while ( terminacion );



Bucle for

La sentencia “for” es una forma compacta de expresar un bucle.

for ( inicalizacion; terminacion; iteracion ) cuerpo;

Si las condiciones iniciales no provocan que la terminacion devuelva true la primeravez, entonces la sentencia cuerpo e iteracion no se ejecutaran nunca. Ejemplo de unbucle 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 in-terfaz de procedimiento a las clases de objetos. En cualquier momento dentro de unmetodo, se puede utilizar la sentencia “return” para que la ejecucion salte y vuelva alpunto donde se llamo al metodo. Se utiliza para acarbar los metodos. Si es un metodovoid, la sentencia serıa:

return;

continue

Del mismo modo que se desea salir prematuramente de un bucle (con “break”),se podrıa desear continuar en el bucle, pero dejar de procesar el resto de codigo enesta 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(‘‘ ’’);

}


Fernando Ballesteros Herranz 4.7. CLASES

4.7. 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 quedesee representar en su programa en Java esta encapsulado en una clase. Para crearuna clase solo se necesita un archivo fuente que contenga la palabra clave class seguidade un identificador legal y un par de llaves para el cuerpo.

class punto{

}

Las clases de Java tıpicas incluiran variables y metodos de instancia. Los programasen Java completos constan por lo general de varias clases de Java de distintos archivosfuente. Una clase define la estructura de un objeto y su interfaz funcional, conocidacomo metodos. Cuando se ejecuta un programa en Java, el sistema utiliza definicionesde clase para crear instancias de las clases, que son objetos reales. La forma generalde 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_metodo1 (lista_de_parametros) {

cuerpo_del_metodo;

}

type nombre_de_metodo2 (lista_de_parametros) {

cuerpo_del_metodo;

}

type nombre_de_metodoN (lista_de_parametros) {

cuerpo_del_metodo;

}

}

Aquı, nombre_de_clase y nombre_de_superclase son identificadores. La palabraclave “extends” se utiliza para indicar que nombre_de_clase sera una subclase denombre_de_superclase. Hay una clase incorporada, llamada “Object” (objeto), queesta en la raız de la jerarquıa de clases de Java. Si se desea realizar una subclase deObject directamente, se puede omitir la clausula extends.



4.7.1. Referencias a objetos

Cada nueva clase que se crea anade otro tipo que se puede utilizar igual que lostipos simples. Por lo tanto, cuando se declara una nueva variable, se puede utilizar unnombre 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 eltipo de una variable es una clase, tiene como valor por omision el “null”, que es unareferencia al tipo “Object”, y, por lo tanto, es compatible en tipo con todas las otrasclases. El objeto “null” no tiene valor; es distinto del entero 0, igual que el “false” deboolean. 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 lasllaves de apertura y cierre de la declaracion de la clase. A las variables que se declaranen este ambito y fuera del ambito de un metodo concreto se las conoce como variablesde instancia. Este ejemplo declara una clase de nombre Point, con dos variables deinstancia enteras llamadas x e y.

class Point {

int x, y;

}

4.7.3. Operador new

El operador new crea una unica instancia de una clase y devuelve una referencia aese objeto. Aquı se crea una nueva instancia de Point y se almacena en una variablep.

Point p = new Point();

Aquı p referencia a una instancia de Point, pero realmente no lo contiene. Sepueden crear multiples referencias al mismo objeto.




Point p2 = p;

4.7.4. Operador(.)

El operador punto se utiliza para acceder a las variables de instancia y los metodoscontenidos en un objeto. Esta es la forma general de acceder a las variables de instanciautilizando el operador punto.

p.x = 10;

p.y = 20;

System.out.println("x = " + p.x + " y = " + p.y);

4.7.5. Declaracion de metodos

Los metodos son subrutinas unidas a una definicion de una clase especıfica. Sedeclaran 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 tipoconcreto y que tiene un conjunto de parametros de entrada.

tipo nombre_de_metodo ( lista_formal_de_parametros ) {

cuerpo_del_metodo;

}

Se podrıa crear un metodo en la clase Point que inicialice las variables de instanciade la forma siguiente:

clase Point {

int x, y;

void init(int x, int y) {

this.x = x;

this.y = y;

}

}



El metodo main()

Dado que no hay funciones globales en Java, se debıa idear alguna manera deiniciar un programa, de ahı el sentido del metodo main, a partir de este metodoes donde empiezan los programas. Esto es un concepto perdido en la creacion deinterfaces graficas. El metodo main es simplemente un lugar de inicio para que elinterprete comience. Un programa complejo tendra docenas de clases, y solo una deellas necesitara tener un metodo main.

4.7.6. Llamada a metodos

Se llama a los metodos dentro de una instancia de un clase utilizando el operadorpunto (.). La forma general de una llamada:

referencia_a_objeto . nombre_de_metodo ( lista_de_parametros );

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 con-structor 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 sepuede tener ningun otro metodo que comparta su nombre con su clase. Una vezdefinido, se llama automaticamente al constructor despues de crear el objeto, antesde que termine el operador new.

class Point {

int x, y;

Point(int x, int y) {

this.x = x;

this.y = y;

}

}



class PointCreate {

public static void main (String args[]) {

Point p = new Point(10, 20);


}

}

4.7.8. Sobrecarga de metodos

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. Sesobrecarga un metodo siempre que se crea un metodo en una clase que ya tiene unmetodo 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 parametrosen vez de al primero.

4.7.9. Operador this

Este es un operador que utilizan las clases para hacerse referencias a sı mismas. Deesta forma un objeto siempre puede tener referencias a sus variables. Muy utilizadoen los constructores.



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 man-era jerarquica. Esto permite que los descendientes de una clase hereden todas lasvariables y metodos de sus ascendientes, ademas de crear los suyos propios. A estosdescendientes se les llama subclases. Al padre inmediato de una clase se le llama susuperclase.

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 subclasede Point. No se necesita declarar las variables x e y en Point3D porque se habıanheredado de Point. Todas las variables x, y, z estan en el mismo ambito desde laperspectiva de una instancia de Point3D.

super

Hay una variable especial en Java llamada “super”, que se refiere directamente alos constructores de la superclase. Este ejemplo define una nueva version de Point3D



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 lasvariables o metodos, estos se pueden declarar como final. El modificador de tipo finalimplica 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 deseano permitir que las subclases sobrescriban un metodo concreto.

static

A veces se desea crear un metodo que se utilize fuera del contexto de cualquierinstancia. Todo lo que se tiene que hacer es declarar estos metodos como “static”(estatico). Los metodos estaticos solo pueden llamar a otros metodos static directa-mente, y no se pueden referir a this o super de ninguna manera. Las variables tambiense pueden declarar como static, pero debe ser consciente que es equivalente a declarar-las 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 realizarcalculos para inializar las variables static.

abstract

Las clases abstractas son aquellas cuya descripcion es incompleta. Se definen uti-lizando la palabra reservada abstract. No proporcionan la implementacion de todossus metodos. Los metodos no implementados se declaran como abstract. Una clasecon un metodo abstracto tiene que declararse como abstract. Una clase abstracta nopuede instanciarse, es decir, no pueden crearse objetos de esa clase.



4.8. Paquetes e interfaces

4.8.1. Paquetes

Los paquetes permiten agrupar una coleccion de clases e interfces funcionalmenterelacionadas asignandole un nombre.

Sentencia package

Lo primero que se permite en un archivo Java es una sentencia package, que le diceal compilador en que paquete se deberıan definir las clases incluidas. Si se omite lasentencia 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, entoncesel 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 defini-ciones de clase en un archivo fuente en Java puede ser una lista de sentencias import.Todas las clases interesantes estan almacenadas en algun paquete con nombre. Parano tener que introducir el largo nombre de trayecto de paquete para cada clase, Javaincluye 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 deun paquete opcional contenido en el paquete exterior separado por un punto (.). Nohay ningun lımite practico a la profundidad de la jerarquıa de paquetes. Finalmente,nombre_clase explıcito o un asterisco (*) que indica que el compilador Java deberıabuscar este paquete completo.

import java.util.Date;

import java.io.*;


Fernando Ballesteros Herranz 4.8. PAQUETES E INTERFACES

4.8.2. Proteccion de accesos

Hay cuatro niveles de proteccion en funcion de los atributos de acceso y de laorganizacion en paquetes y son publico, paquete, protegido y privado. Los atributos deacceso 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 lasclases 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 metodosdeclarados sin cuerpo. Las clases pueden inplementar varias interfaces. Para imple-mentar una interfaz, todo lo que necesita una clase es una implementacion del conjun-to completo de metodos de la interfaz. Las interfaces estan en una jerarquıa distintade la de las clases, por lo que es posible que varias clases que no tengan la mas mıni-ma relacion en cuanto a la jerarquıa de clases implementen la misma interfaz. Pordefecto todos sus metodos son publicos y abstractos, y sus atributos son publicos yconstantes. Los metodos que se declaran no tienen sentencias de cuerpo. Un ejemplode una interfaz es:

interface Callback {

void callback(int param);

}

Una clase puede implementar varias interfaces, con la sentencia implements:

class NombredeClase implements Interfaz1 [,Interfaz2,...]{

//declaracion de metodos y atributos de la clase

}



4.9. Gestion de cadenas

Una cadena es una secuencia de caracteres. Las cadenas son una parte fundamentalde la mayorıa de los programas, ası pues Java tiene varias caracterısticas incorporadasque facilitan la manipulacion de cadenas.

Java tiene una clase incorporada en el paquete “java.lang” que encapsula las es-tructuras de datos de una cadena. Esta clase, llamada String es la representacioncomo 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 oper-ador new.

String s = new String();

Este ejemplo crea una instancia de String sin caracteres en ella. Para crear unString 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. Metodos de String

length

La clase String ademas tiene sus propios metodos, uno de los mas habituales eslength, que devuelve el numero de caracteres de una cadena.

String s = "abc";

System.out.println(s.length()); // imprime 3


Fernando Ballesteros Herranz 4.9. GESTION DE CADENAS

Concatenacion

El unico operador que utiliza Java es + , y en los objetos String. El + actua comooperador de concatenacion en este caso en concreto para mejorar la legibilidad, porser operacion muy comun.

String s = "El tiene " + edad + " a~nos";

Comparacion de cadenas

Si se desean comparar dos cadenas para ver si son iguales, puede utilizar el meto-do equals() de String. Devuelve “true” si las cadenas de caracteres comparadas soniguales.

String coger= "dicom";

String hol= "dicom";

boolean compara = coger.equals(hol);//devuelve true

El metodo “equals” y el operador “= =” hacen dos pruebas completamente difer-entes para la igualdad. Mientras que el metodo equals compara los caracteres con-tenidos en una String, el operador = = compara dos referencias de objeto para ver sise refieren a la misma instancia.

Extraccion de caracteres

Para extraer un unico caracter de una cadena, se puede referir a un caracterindexado mediante el metodo charAt:

"abc".charAt(1) // devolvera ’b’

La primera posicion de una cadena es la posicion 0.

4.9.3. Conversion a String

Todos los objetos tienen el metodo toString() heredado de Object, de esta formacualquier objeto puede ser convertido en cadena. Ejemplo de int a String.



int entero = 5;

String cadena = new Integer(entero).toString();

4.10. Gestion de excepciones

Una excepcion es una condicion anormal que surge en una secuencia de codigodurante la ejecucion. La gestion de excepciones de Java lleva la gestion del erroren tiempo de ejecucion al mundo orientado a objetos. Una excepcion de Java es unobjeto que describe una condicion excepcional que se ha producido en un fragmentode codigo.

Los objetos de excepcion los crea automaticamente el interprete de Java comorespuesta a alguna condicion excepcional. Como ejemplo tomamos una division porcero. Cuando el interprete de Java intenta ejecutar la division, observa que el denom-inador es cero y construye un nuevo objeto de excepcion para que se detenga estecodigo y se trate esta condicion de error. Una vez detenido el flujo del codigo en eloperador de division, se buscara en la pila de llamadas actual cualquier gestor deexcepciones (pila que contiene un registro de las llamadas a metodo). Un gestor deexcepciones es algo establecido para tratar inmediatamente la condicion excepcional.Si no codificamos un gestor de excepciones, se ejecutara el gestor en tiempo de eje-cucion por defecto. El gestor por defecto imprime el valor String de la excepcion y eltrazado de la pila del lugar donde se produjo la excepcion.

Figura 4.7: Propagacion de excepciones


Fernando Ballesteros Herranz 4.10. GESTION DE EXCEPCIONES

4.10.1. try y catch

Es mas practico manejar y gestionar las excepciones. Se puede utilizar la palabraclave try para especificar un bloque de codigo que se deberıa proteger frente a todaslas excepciones. A continuacion inmediatamente del bloque try, se debe incluir laclausula catch que especifica el tipo de excepcion que se desea captar y en este bloquese 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("division por cero");

}

}

}

ArithmeticException es una subclase especial de Exception, que describe masespecıficamente el tipo de error que se ha producido. El ambito de la clausula catchesta restringido a las sentencias especificadas por la sentencia try precedente.

En algunos casos, la misma secuencia de codigo puede activar mas de una condicionexcepcional. Se pueden tener varias clausulas catch en una fila. Se inspecciona cadauno de estos tipos de excepcion en el orden en que estan y el primero que coincida seejecuta.

4.10.2. throw

La sentencia throw se utiliza para lanzar explıcitamente una excepcion. El flujo dela ejecucion se detiene inmediatamente despues de la sentencia throw, y no se llega ala sentencia siguiente. Se inspecciona el bloque try que la engloba mas cercano paraver si tiene una clausula catch cuyo tipo coincida con el de la instancia Throwable. Sila encuentra, el control se transfiere a esa sentencia. Si no, se inspecciona el siguientebloque try que la engloba, y ası sucesivamente, hasta que le gestor de excepcion masexterno detiene el programa e imprime el trazado de la pila hasta la sentencia throw.



4.10.3. finally

Es el bloque de codigo que se ejecuta siempre haya o no excepcion. Se puedeutilizar la palabra clave finally par identificar dicho bloque de codigo. Incluso aunqueso coincida ninguna de las clausulas catch, se ejecutara el bloque finally antes delcodigo que esta despues del final del bloque try completo.

4.10.4. Gestion 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 elcual 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 quepodrıan tardar varios segundos en terminar, y nuestros programas tendran que tratarcon estos temas sin provocar retrasos desagradables al usuario.

Lo interesante de todos estos procesos en paralelo es que la mayor parte de ellosrealmente no necesitan los recursos completos de la computadora durante su vidaoperativa. El problema en los entornos de hilo unico tradicionales es que se tiene que


Fernando Ballesteros Herranz 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 enla cola ordenadamente.

Los sistemas multihilo aprovechan la circunstancia de que la mayorıa de los hiloscomputacionales invierten la mayor parte del tiempo esperando a que un recurso quededisponible, o bien esperando a que se cumpla alguna condicion de temporizacion. Sepuede describir todas las tareas como hilos de control independientes, conmutando demanera automatica entre una tarea que este lista para pasar a un modo de espera, yotra que sı tenga algo que hacer, consiguoendo realizar una cantidad mayor de trabajoen el mismo intervalo de tiempo.

Prioridades de hilo

El interprete de Java utiliza prioridades para determinar como debe comportarsecada hilo con respecto a los demas. Las prioridades de hilo son valores entre 1 y 10que indican la prioridad relativa de un hilo con respecto a los demas.

Sincronizacion

Ya que los hilos permiten y potencian el comportamiento asıncrono de los pro-gramas, 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 amodo de objetos, pero Java proporciona una solucion mas elegante: no existe la clasemonitor, cada objeto lleva asociado su propio monitor implıcito, en el que puede en-trar sin mas que hacer una llamada a los metodos synchronized del objeto. Una vezque el hilo esta dentro del metodo synchronized, ningun otro hilo puede efectuar unallamada a otro metodo synchronized sobre el mismo objeto.

Una vez que el programa se ha dividido en sus partes logicas, a modo de hilo, espreciso definir exactamente como se comunicaran entre si dichos hilos. Java utilizalos 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 encapsulatodo el control necesario sobre los hilos. Hay que tomar la precaucion de distinguirclaramente un objeto Thread de un hilo en ejecucion. Un objeto Thread se define



como el panel de control o proxy de un hilo en ejecucion. En el objeto Thread haymetodos que controlan si el hilo se esta ejecutando, esta durmiendo, en suspenso odetenido. La clase Thread es la unica manera de controlar el comportamiento de loshilos. 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. Cuandose construye una nueva instancia de Thread, es necesario decir que codigo ejecutaren el nuevo hilo de control. Se puede comenzar un hilo sobre cualquier objeto queimplemente la interfaz Runnable.

Runnable es una interfaz simple que abstrae la nocion de que se desea que alguncodigo se “ejecute” asıncronamente. Para implementar Runnable, a una clase le bastacon implementar un solo metodo llamado run. Este es un ejemplo que crea un nuevohilo.

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");



}

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 runsobre este objeto. A continuacion se llama a start, lo que inicia el hilo “t” en laejecucion a partir del metodo run. En estos momentos hay dos hlos en ejecucion,uno “ct” que continua con el programa principal, lo que le lleva al primer try, y elsegundo salta desde start() al metodo run(). Despues, el hilo main se duerme durante3000 milisegundos antes de imprimir un mensaje y despues termina. Demo Threadtodavıa esta contando desde cinco cuando sucede esto. Se continua ejecutando hastaque 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 decidircuando debe dejar a cada hilo que se ejecute, de manera que los hilos con may-or prioridad deben ejecutarse mas a menudo que lo de menor prioridad. Cuandoesta ejecutandose un hilo de baja prioridad, y otro de mayor prioridad se despiertade su sueno, o de la espera por un operacion de E/S, debe dejarse que se ejecute demanera inmediata, desalojando al hilo de menor prioridad. Cuando los hilos son deigual prioridad deben desalojarse los unos a los otros, cada cierto tiempo, utilizandoel algoritmo circular round-robin para gestionar el acceso al la CPU.



4.11.4. Sincronizacion

Cuando dos o mas hilos necesitan acceder de manera simultanea a un recurso dedatos compartido necesitan asegurarse de que solo uno de ellos accede al mismo cadavez. Java proporciona un soporte unico, el monitor, es un objeto que se utiliza comocerrojo exclusivo. Solo uno de los hilos puede ser el propietario de un monitor enun instante dado. Los restantes hilos que estuviesen intentando acceder al monitorbloqueado quedan en suspenso hasta que el hilo propietario salga del monitor.

Todos los objetos de Java disponen de un monitor propio implıcitamente asociadoa ellos. La manera de acceder a un objeto monitor es llamando a un metodo marcadocon la palabra clave synchronized. Durante todo el tiempo en que un hilo permanezcaen un metodo sincronizado, los demas hilos que intenten llamar a un metodo sin-cronizado sobre la misma instancia tendran que esperar. Para salir del monitor ypermitir el control del objeto al siguiente hilo en espera, el propietario del monitorsolo tiene que volver del metodo

Sentencia synchronized

Si se utiliza una clase que no fue disenada para accesos multihilo y, por ello,se dispone de metodos no sincronizados que manipulan el estado interno,se puedeenvolver la llamada al metodo en un bloque sincronizado. El formato general de lasentencia sincronizada es el siguiente:

synchronized(objeto) sentencia;

En el ejemplo, objeto es cualquier referencia al objeto, y sentencia suele ser unbloque que incluye una llamada al metodo de objeto, que solo tendra lugar una vezque el hilo haya entrado con exito en el monitor de objeto.

4.11.5. Comunicacion entre hilos

Java proporciona un mecanismo elegante de comunicacion entre procesos, a travesde los metodos wait, notify y notifyAll. Estos metodos se implementan como metodosde final en Object, de manera que todas las clases disponen de ellos. Cualquiera delos 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 hastaque otro hilo entre en el mismo monitor y llame a notify.



notify: despierta al primer hilo que realizo una llamada a wait sobre el mismoobjeto.

notifyAll_: despierta todos los hilos que realizaron una llamada a wait sobre elmismo objeto. El hilo con mayor prioridad de los despertados es el primero enejecutarse.

4.11.6. Metodos

Metodos de clase

Estos son los metodos estaticos que deben llamarse de manera directa en la claseThread.

currentThread: el metodo estatico devuelve el objeto Thread que representa alhilo que se ejecuta actualmente.

yield: este metodo hace que el interprete cambie de contexto entre el hilo actualy el siguiente hilo ejecutable disponible. Es una manera de asegurar que los hilosde menor prioridad no sufran inanicion.

Sleep(int n): el metodo sleep provoca que el interprete ponga al hilo en cursoa dormir durante n milisegundos. Una vez transcurridos los n milisegundos,dicho hilo volvera a estar disponible para su ejecucion. Los relojes asociados ala mayor parte de los interpretes Java nos seran capaces de obtener precisionesmayores de 10 milisegundos.

Metodos de instancia

Estos son los metodos que deben llamarse desde instancias u objetos de la claseThread.

start: indica al interprete de Java que cree un contexto de hilo del sistemay comience a ejecutarlo. A continuacion, el metodo run objeto de este hilosera llamado en el nuevo contexto del hilo. Debe tomarse la precaucion de nollamar al metodo start mas de una vez sobre un objeto hilo dado.

run: constituye el cuerpo de un hilo en ejecucion. Este es el unico metodo dela interfaz Runnable. Es llamado por el metodo start despues de que el hiloapropiado del sistema se haya inicializado. Siempre que el metodo run devuelvael control, el hilo actual se detendra.



stop: provoca que el hilo se detenga de manera inmediata. A menudo constituyeuna manera brusca de detener un hilo, especialmente si este metodo se ejecutasobre el hilo en curso. En tal caso, la lınea inmediatamente posterior a la llamadaal metodo stop no llega a ejecutarse jamas, pues el contexto del hilo muere antesde que stop devuelva el control.

suspend: es distinto de stop. suspend toma el hilo y provoca que se detenga suejecucion sin destruir el hilo de sistema subyacente, ni el estado del hilo anteri-ormente en ejecucion. Si la ejecucion de un hilo se suspende, puede llamarse aresume 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 pasadocomo 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 estamanera se facilita la depuracion de programas multihilo.

getName: devuelve el valor actual, de tipo cadena, asignado como nombre alhilo mediante setName.

4.12. Utilidades

La biblioteca de clases de Java contiene un conjunto de clases de utilidades uti-lizadas en todos los paquetes principales de Java. Estas clases estan almacenadas enlos 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 numeros aleatorios y manipulacion de fecha/hora.

4.12.1. Envolturas

Number

La clase abstracta Number representa una interfaz a todos los tipos escalaresestandar: long, int, float y double. Number tiene metodos de acceso que devuelven elvalor posiblemente redondeado del objeto de cada uno de los objetos simples:

doubleValue() devuelve un double.


Fernando Ballesteros Herranz 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 constructorespara inicializarlas con valores double y float, o, lo que es muy practico, se puedeninicializar 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 unaenvoltura alrededor del tipo long. Ademas de los metodos heredados de Numbertienen otros muy utiles:

parseInt(String) convierte la variable String en el valor int que representa.

parseInt(String, base) hace lo mismo que el metodo anterior, pero especifica unabase distinta de la decima.

toString(int) convierte el int que se pasa al metodo en su representacion comocadena.

toString(int, base) igual al anterior, pero puedo cambiar de base.

Character

Character es una envoltura simple alrededor de un char. Tiene varios metodosutiles static, que se pueden utilizar para probar varias condiciones de un caracter:

isLowerCase(char ch) devolvera true si el caracter es una letra minuscula.

isUpperCase(char ch) lo mismo pero para letras mayusculas.



isDigit(char ch) e isSpace(char ch) devuelven true para caracteres numericos yespacios en blanco respectivamente.

toLowerCase(char ch) y toUpperCase(char ch) convierten entre mayuscula yminuscula y viceversa.

Boolean

Boolean es un envoltorio muy fino alrededor de valores boolean, que solo es utilpara situaciones de paso por referencia.

4.12.2. Enumeraciones

Java tiene matrices para almacenar grupos de datos de tipo similar, que son muyutiles para modelos simples de acceso a datos. Sin embargo, las enumeraciones ofrecenuna manera mas completa y orientada a objetos para almacenar conjuntos de datosde tipo similar. Las enumeraciones tienen su propia asignacion de memoria y posibil-idad de una nueva asignacion para ampliarlas. Tienen interfaces de metodo para suiteracion y recorrido. Se pueden indexar mediante algo mas complejo y util que lossimples enteros.

Interfaz de enumeracion

Enumeracion es una interfaz simple que permite enumerar todos los elementos decualquier conjunto de objetos. Especifica dos metodos. El primero, un metodo booleanllamado hasMoreElements, devuelve true cuando todavıa quedan mas elementos queextraer. El segundo, nextElement devuelve una referencia a objeto generica cuyo tipohay 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, unVector implementa una estrategia de crecimiento para minimizar la reasignacion y elespacio desperdiciado. Los objetos se pueden almacenar al final de un Vector utilizan-do el metodo addElement o en un ındice dado mediante el metodo insertElement. Sepuede almacenar una matriz en un Vector utilizando el metodo copyInto. Una vez seha almacenado un conjunto de objetos en un Vector, se puede utilizar para buscar un


Fernando Ballesteros Herranz 4.12. UTILIDADES

elemento en concreto utilizando los metodos contains, indexOf, o lastIndexOf. Tam-bien se puede extraer un objeto de una posicion especıfica de un Vector utilizando losmetodos elementAt, firstElement y lastElement.

4.12.3. Runtime

La clave Runtime encapsula el proceso del interprete de Java que se ejecuta. No sepuede crear una instancia de Runtime; sin embargo, se puede obtener una referenciaal objeto Runtime que se esta ejecutando actualmente llamando la metodo estaticoRuntime.getRuntime. Una vez tenga el descriptor del proceso en ejecucion, puedellamar a varios metodos que controlan el estado y comportamiento de la maquinavirtual de Java.

Runtime rt = Runtime.getRuntime();

rt.exec("c:\\CntVirRel.exe");

Mediante Runtime se puede ejecutar cualquier aplicacion, mediante el metodoexec().

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 yout.

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 manipularel dıa, mes, ano, dıa de la semana, horas, minutos y segundos. Hay varios constructorespara objetos Date. El mas simple, Date(), inicializa el objeto con la fecha y horaactual. Hay tres constructores mas que ofrecen niveles de especificidad mayores parala precision que se desea para la hora:



Date(ano, mes, dıa) establecera la hora a las 00:00:00 del dıa especificado.

Date(ano, mes, dıa, horas, minutos) fijara la fecha y hora, dejando los segundosa 0.

Date(ano, mes, dıa, horas, minutos, segundos) establecera la hora exacta.

4.13. Entrada/Salida

La mayorıa de los programas no pueden alcanzar sus metas sin acceder a datosexternos. Estos datos se recuperan a partir de un origen de entrada. Los resultadosde un programa se envıan a un destino de salida. La nocion generica de una fuentede entrada puede representar muchos tipos de entrada distintos: desde un archivo dedisco, un teclado o un conector (socket) de red. Estas abstracciones son una maneralimpia de tratar la E/S sin necesitar que todo el codigo comprenda la diferencia entreun teclado y una red.

Java llama flujo a esta abstraccion y la implementa con varias clases del paquetejava.io. El flujo de E/S representa todos los orıgenes y destinos de los datos detras deuna interfaz uniforme. La entrada esta encapsulada en la clase InputStream y la salidaen la clase OutputStream. Estas dos clases abstractas son las que todos los objetosdeberıan referenciar cuando tratan la E/S en general. Sus metodos mas importantesson read() y write(int b); son metodos abstractos que definen la funcion basica delectura/escritura de un byte.

Figura 4.8: Flujos estandar

4.13.1. File

Un File es el unico objeto del paquete de E/S que referencia a un archivo dedisco real. La clase File no especifica como se recupera o almacena la informacion enlos archivos; solo describe las propiedades de un objeto archivo. Los archivos son unorigen y un destino primario de los datos dentro de la mayorıa de los programas.

Los objetos archivo se pueden crear utilizando uno de los tres constructoresdisponibles. El ejemplo siguiente crea tres archivo: f1, f2 y f3. El primer objeto Filese construye utilizando un trayecto de directorio como unico argumento. El segundo


Fernando Ballesteros Herranz 4.13. ENTRADA/SALIDA

se crea utilizando dos argumentos, el trayecto y el nombre de archivo. El tercero secrea utilizando el trayecto de archivo asignado a f1 y un nombre de archivo; f3 refiereal 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 delos otros archivos y directorios que contiene. Si se llama al metodo list sobre unobjeto File que no sea un directorio se provoca una NullPointerException en tiempode 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 numero de archivos devueltos por el metodo listpara que se incluyan unicamente aquellos archivos que cumplan un cierto patron



de nombre de archivo. Con este fin, el paquete java.io incluye una interfaz llamadaFilenameFilter. Un objeto que implemente FilenameFilter tiene un unico metodo,accept, al que se llama una vez por cada archivo de una lista. El metodo acceptdevuelve el valor true si se debiera incluir el archivo en la lista. El ejemplo siguienteamplıa el programa anterior restringiendo la visibilidad de los nombres de archivodevueltos por el metodo list. La restriccion se aplica a archivos con nombres queterminan con la extension de archivo que se pasa como parametro cuando se construyele 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 deentrada. Todos los metodos de esta clase lanzaran una IOException si se producencondiciones de error. Este es un breve resumen de los metodos de InputStream:

read() devuelve una representacion como entero del siguiente byte de entradadisponible.

read(byte[]) intenta leer hasta b.length bytes situandolos en b y devuelve elnumero real de bytes que se leyeron con exito.

read(byte b[], int off, int len) intenta leer hasta len bytes situandolos en b comen-zando en b[off], y devuelve el numero de bytes que se leyeron con exito.

skip(long n) omite n bytes de la entrada, y devuelve el numero de bytes que sehan omitido.

available() devuelve el numero de bytes de entrada disponibles actualmente parasu lectura.

close() cierra el origen de entrada. Los intentos de lectura posteriores generaranuna IOException.



mark(int limitelectura) coloca una marca en el punto actual del flujo de entradaque 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 flujode salida. Todos los metodos de esta clase devuelven un valor void y lanzan unaIOException en caso de error. Esta es una lista de los metodos de OutputStream:

write(int b) escribe un unico byte en un flujo de salida. Observar que el parametroen un int, lo que permite que se llame a write con expresiones sin tener que con-vertir 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 apartir 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 generaranuna IOException.

4.13.4. Flujo de archivo

FileInputStream

La clase FileInputStream utiliza archivos de datos reales como base del flujo deentrada. El ejemplo siguiente crea dos FileInputStreams que estan utilizando el mismoarchivo de disco real.

InputStream f0 = new FileInputStream("/autoexec.bat");

File f = new file("/autoexec.bat");

InputStream f1 = new FileInputStream(f);



FileOutputStream

FileOutputStream comparte el mismo estilo de constructores que FileInputStream.Sin embargo, la creacion de FileOutputStream no depende de que el archivo ya ex-ista. FiliOutputStream creara el archivo antes de abrirlo como salida cuando se creael objeto. Si se intenta abrir un archivo de solo lectura como punto final de un Fil-iOutputStream, se lanzara una IOException.

ByteArrayInputStream

ByteArrayInputStream (flujo de entrada de matriz de bytes) es una implementacionde un flujo de entrada que utiliza una matriz de bytes como origen. Esta clase tienedos constructores, y ambos necesita una matriz de bytes que proporcione el origen delos datos.

ByteArrayOutputStream

ByteArrayOutputStream tiene dos constructores. En la primera forma, se crea unbuffer de 32 bytes. En la segunda, se crea un buffer con un tamano igual al argumentoen 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 amplıan los flujos basicos, proporcionando una sincronizacion.En un sistema de E/S multihilo, se pueden producir resultados inesperados cuandose permite que multiples hilos operen sobre el mismo flujo. Aunque es posible tenerhilos multiples en Java leyendo o escribiendo en el mismo flujo, hay una buena razonpara permitir que solo un hilo tenga acceso directo a un flujo de E/S unico. Todoslos constructores y metodos proporcionados en esta clase son identicos a los men-cionados anteriormente para InputStream y OutputStream, a excepcion de que estansincronizados.



BufferedOutputStream

La salida a BufferedOutputStream es identica a cualquier OutputStream con laexcepcion de que se anade un metodo de entrada con buffer, la salida con buffer noproporciona ninguna funcionalidad adicional. En Java, los buffers para la salida estanahı para incrementar el rendimiento.

4.13.6. SequenceInputStream

La clase SequenceInputStream (flujo de entrada secuencial) admite la utilidadoriginal de concatenar multiples InputStreams en uno solo. La construccion de unSequence es diferente de cualquier otro InputStream. Un constructor SequenceIn-putStream utiliza como argumento un par de InputStreams o una Enumeration deInputStreams:

SequenceInputStream(Enumeration e);

SequenceInputStream(InputStream s0, InputStream s1);

PrintStream

La clase PrintStream proporciona todas las utilidades de formato que hemos es-tado utilizando desde el principio del libro de los descriptores de archivo de System.Pensabas que se introducıa “System.out.println” sin pensar demasiado en las clasesque proporcionaban el formato de la salida que se presentaba. PrintStream tienedos constructores, PrintStream(OutputStream sal) y PrintStream(OutputStream sal,boolean auto), donde auto controla si java vacıa el flujo de salida cuando vaya a lasalida un caracter de lınea nueva “\n”.

Los objetos PrintStream de Java admiten los metodos print y println para to-dos los tipos, incluyendo Object. Si un argumento no se un tipo simple, los metodosPrintStream llaman al metodo toString del objeto y a continuacion imprimen el re-sultado.

4.13.7. Ejemplo

Este primer ejemplo se muestra una forma comoda y eficaz para la lectura ficherosque en este caso se leen los datos del fichero LeeFichero.java y se imprimen por laconsola.



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 unarchivo 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];


Fernando Ballesteros Herranz 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 capıtulo cubre el paquete java.net. La integracion de Java con la red seha hecho legendaria, gracias en gran parte a esta biblioteca de clases. Java admite elprotocolo de TCP/IP de Internet ampliando la interfaz de E/S de flujo ya establecida,presentada en el capıtulo anterior, y anadiendo las caracterısticas que se necesitanpara crear objetos de E/S a traves de la red. Java admite las familias de protocoloTCP 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 conTCP es la eficiencia que se consigue. Cuando se va a traspasar una gran cantidad deinformacion (por ejemplo, un fichero video), si no necesitamos tiempo real, TCP es unprotocolo adecuado, puesto que el tiempo necesario para establecer la comunicaciones 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



es muy importante , TCP no es un protocolo adecuado;serıa mucho mejor UDP.

4.14.1. InetAddress

Independientemente de si se realiza una llamada telefonica, se envıa un correoelectronico o se establece una conexion a traves de Internet, las direcciones son fun-damentales. 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 unidentificador de nodo de 32 bits y un selector de puerto de ese nodo de 32 bits. En In-ternet el direccionamiento lo gestionan servidores de nombres que traducen nombreshabituales y faciles de recordar a sus correspondientes direcciones de 32 bits.

La clase InetAddress no tiene constructores visibles. Para crear un objeto InetAd-dress, se tiene que utilizar uno de los metodos de fabrica disponibles. Estos metodosson simplemente metodos estaticos que devuelven una instancia de la clase en la queresiden. En este caso, InetAddress tiene tres metodos, getLocalHost, getByName ygetAllByName, que se pueden utilizar para crear instancias de InetAddress.

InetAddress ip = InetAddress.getLocalHost();

La clase InetAddress tambien tiene unos cuantos metodos no estaticos, que sepueden utilizar sobre los objetos devueltos por los metodos que se acaban de men-cionar:

getHostName() devuelve una cadena que representa el nombre de nodo asociadocon el objeto InetAddress.

getAddress() devuelve una matriz de bytes de cuatro elementos que representala direccion en Internet del objeto en el “orden de red”.

toString() devuelve una cadena que contiene el nombre del nodo y la direccionIP.

4.14.2. Datagramas

Los datagramas son bloques de informacion del tipo “lanzar y olvidar” que setransfieren a traves de la red. Para la mayorıa de los programas de la red, el utilizarun flujo TCP/IP en vez de un datagrama UPD es mas sencillo y hay menos posibili-dades de tener problemas. Sin embargo, cuando se requiere un rendimiento optimo, y



esta justificado el tiempo adicional que supone el realizar la verificacion de los datos,los datagramas son un mecanismo realmente util.

Cuando se ha lanzado un datagrama hacia su destino, no hay ninguna seguridadde que llegue o incluso de que haya alguien allı para cogerlo. Igualmente, cuando serecibe un datagrama, no es seguro que no se haya danado por el camino o que el quelo haya enviado este todavıa ahı para recibir una respuesta.

DatagramPacket

Se pueden crear los DatagramPackets utilizando dos constructores. El primeroutiliza solamente un buffer de bytes y una longitud. Ese utiliza para recibir datos atraves de un DatagramSocket. El segundo anade una especificacion de direccion dedestino y un puerto, que es utilizada por un DatagramSocket para determinar dondese enviaran los datos del paquete. Considerar que estas dos formas equivalen a crearun “un buzon de entrada” en el primer caso, y a rellenar y poner una direccion en unsobre 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. Permitenun acceso completo a la direccion de destino y numero de puerto de un paquete,ademas de a sus datos y su longitud. A continuacion se presenta un resumen de cadauno de ellos:

getAddress() devuelve la InetAddress de destino. Se utiliza habitualmente paraenvıos.

getPort() devuelve el numero entero de puerto de destino. Se utiliza para envıos.

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 matrizde bytes que se devolverıan con el metodo getData. Habitualmente no coincidecon la longitud de la matriz de bytes.



4.14.3. Conectores

Socket cliente

Los conectores (sockets), o los conectores TCP/IP en concreto, se utilizan paraimplementar conexiones basadas en flujo, punto a punto, bidireccionales y fiables entrenodos de Internet. Se puede utilizar un conector para conectar el sistema de E/S deJava a otros programas que pueden residir en la maquina local o en cualquier otramaquina de Internet. La clase Socket, a diferencia de DatagramSocket, implementauna conexion continua muy fiable entre el cliente y el servidor.

Al crear un objeto conector tambien se establece la conexion entre direcciones deInternet. No hay metodos ni constructores que muestren explıcitamente los detallesdel establecimiento de la conexion del cliente. Se puedan utilizar dos constructorespara crear conectores:

Socket(String nodo, int puerto) crea un conector que conecta el nodo local conel nodo y puerto nombrados.

Socket(InetAddress direccion, int puerto) crea un conector utilizando un objetoInetAddress ya existente y un puerto.

En un conector se puede examinar en cualquier momento la informacion de direc-cion 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 accedera los flujos de entrada y salida asociados con el. Todos estos metodos pueden lanzaruna IOException si se han invalidado los conectores debido a una perdida de conexionen la red. Estos flujos se utilizan exactamente igual que los flujos de E/S que hemosvisto en el capıtulo 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.



Socket servidor

Los ServerSockets se deben utilizar para crear servidores de Internet. Estos servi-dores no son necesariamente maquinas, de hecho son programas que estan esperandoa que programas cliente locales o remotos se conecten a ellos en puertos publicos.Los ServerSockets son bastante diferentes de los Sockets normales. Cuando se crea unServerSocket, 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 esperaque un cliente inicie la comunicacion y despues devuelve un Socket normal.

Los dos constructores de ServerSocket reflejan el numero del puerto en el quese desean aceptar las conexiones y, opcionalmente, durante cuanto tiempo se deseaesperar a que se deje de utilizar el puerto. Ambos constructores pueden lanzar unaIOExeption bajo condiciones adversas. Estos son los dos prototipos:

ServerSocket(int puerto) crea un conector de servidor en el puerto especificado.

ServerSocket(int puerto, int numero) crea un conector de servidor en el puertoespecificado esperando numero milisegundos si el puerto se esta utilizando.

Funcionalmente, el metodo accept de un ServerSocket es una llamada que se blo-quea y que espera que un cliente inicie la comunicacion y despues devuelve un Socketnormal. Despues, este conector se utiliza para la comunicacion con el cliente.

4.14.4. Conexion

Conexion cliente

Lo primero debe ser crear un objeto socket diciendo con que servidor y por quepuerto se realiza la conexion. Despues para que haya una comunicacion entre las dosmaquinas es necesario abrir dos flujos uno de entrada y otro de salida, en los que porellos se realiza el intercambio de informacion. Es recomendable utilizar el buffer parala transferencia de la informacion. Por ultimo una vez se quiera desconectar, se debecerrar el socket.

Socket conexion = new Socket(servidor, puerto);

DataInputStream in = new DataInputStream(new BufferedInputStream

(conexion.getInputStream()));

DataOutStream out = new DataOutputStream(new BufferedOutputStream



(conexion.getOutputStream()));

//...

conexion.close();

Conexion servidor

Es muy interesante que el servidor sea multihilo para que pueda atender variaspeticiones de clientes distintos a la vez, por lo que la clase del servidor tiene quederivarse de la clase Thread. Para abrir el socket del servidor vale con pasarle quepuerto es utilizado para la trasnmision de datos. Este puerto debe ponerse a la escuchade posibles peticiones de los clientes. Tambien se deben declarar los flujos de entraday 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 Graficas de Usuario

4.15.1. Componentes AWT

Los componentes de AWT estan en el paquete java.AWT. y son utlizados para lacreacion de GUIs5. Un componente (component) es una clase abstracta que encapsulatodos los atributos de un componente visual. Todos los elementos de la interfaz deusuario que se visualizan en la pantalla y que interactuan con un usuario son subclasesde component.

Subclases de Component:

5Graphics User Interfaces


Fernando Ballesteros Herranz 4.15. INTERFACES GRAFICAS DE USUARIO

Container (contenedor). Contendra metodos adicionales que permiten que otroscomponentes se aniden dentro de el.

Panel. Es una subclase de container. Se pueden anadir otros componentes apanel mediante el metodo add (anadir), modificar estos componentes con move(desplazar), resize (cambiar el tamano).

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 accioncuando el usuario lo pulsa y lo libera.

Checkbox (cuadro de comprobacion). Se utiliza para seleccionar una condicionbooleana. Cuando se construye un checkbox se le pasa un string y opcionalmenteun boolean que especifica el estado inicial de la marca de comprobacion. Sepuede establecer y obtener el estado actual de la marca de comprobacion conlos metodos setstate y getestate respectivamente.

Checkboxgroup. Permite crear un grupo de opciones que solo se pueden selec-cionar de una en una. Los metodos getcheckboxgroup y secheckboxgroup seutilizan para obtener y establecer el grupo al que pertenece un chekbox.

Getcurrent, setcurrent. Obtienen y establecen, respectivamente, el checkbox se-leccionado actualmente.

Choice (opcion). Se utiliza para crear un menu de seleccion emergente. El meto-do additem (anadir elemento) anade nuevas cadenas a la clase choice.

Countitems (contar elementos). Devuelve el numero de elementos de el menu deopciones.

List (lista). Proporciona una lista de seleccion compacta, de elecciones multiplesy de desplazamiento.

Scrollbar (barras de desplazamiento). Se utiliza para seleccionar valores contin-uos entre un mınimo y un maximo especificados.

Textfield (campo de texto). Implementa un area de entrada de texto de una solalınea.

Seteditable. Congela el contenido del textfield.

Iseditable. Comprueba la posibilidad de edicion.

Gettext. Obtiene el valor actual del campo.

Settext. Establece el valor actual.



Setechocaracter. Establece el caracter unico que mostrara el textfield para todoslos caracteres que se introduzcan, muy util para esconder codigos o informacionsecreta.

Textarea (area de texto). Es un editor de texto muy simple.

Appendtext. Anade su parametro string al final del buffer.

Inserttext. Inserta su string en una posicion dada, de base 0 que comienza alprincipio del buffer.

Replacetext. Copia caracteres del string a partir del primer ındice y hasta elsegundo.

Figura 4.9: Jerarquıa de componentes del AWT

4.15.2. Organizacion

Cada objeto container tiene un gestor de organizacion, Layoutmanager. Java tienevarias clases de layoutmanager predefinidas:

Flowlayout (organizacion continuada). Los componentes se colocan desde laesquina superior izquierda, de izquierda a derecha y de arriba a abajo.

Borderlayout (organizacion con limites). Tiene cuatro componentes estrechos yde anchura fija en los extremos, y un area grande en el centro que se amplia ycontrae en dos dimensiones, cada una de estas areas tiene un nombre que es unstring: north, south, easty, west, representan los cuatro lados y center el areadel centro.


Fernando Ballesteros Herranz 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 propiaventana de nivel superior, en vez de estar contenida dentro de otro panel.

Frame (marco). Tiene una barra de tıtulo, esquinas para cambiar el tamano yuna barra de menu.

4.15.3. Componentes de menu

Cada ventana de nivel superior, puede tener una barra de menu asociada conella. Un objeto menubar (barra de menu) puede contener varios objetos menu enel. Los menus tienen una lista de objetos menuitem (elemento de menu) dentro deellos. Menu, es una subclase de menuitem, lo que permite anidar submenus de formajerarquica.

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 compo-nentes se pueden anadir al contenedor y para ciertas operaciones se puedan tratarcomo un todo. Mediante un gestor de diseno controlan la disposicion(layout) de es-tos componentes en la pantalla. Ejemplos de estos componentes son JPanel, JFrame,JApplet. . .

Administrador de diseno

Tipos de disenos y composiciones:

FlowLayout: Los componentes se ponen de izquierda a derecha hasta llenar lalınea, y se pasa a la siguiente. Cada lınea se centra.

BorderLayout: Se ponen los componentes en un lateral o en el centro. Se indicacon una direccion:“East”, “West”, “North”, “South”, “Center”.

GridLayout: Se colocan los componentes en una rejilla rectangular (filas x colum-nas). Se anaden en orden izquierda-derecha y arriba-abajo.



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 metodosllamados 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:


Fernando Ballesteros Herranz 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 eventooriginal y la ubicacion (x, y) del evento.

4.16. Encriptacion

[ENCRI]

El soporte que da el JDK a la criptografıa se divide en dos grandes bloques, elJCA “Java Cryptography Architecture” y el JCE “Java Cryptography Extension”.La primera parte nos define las bases del soporte criptografico de Java, y la segundanos provee de los algoritmos necesarios para poder encriptar y desencriptar datos.

Debido a las leyes de los Estados Unidos, que prohiben exportar software deencriptacion de datos, el JCE no viene incluido en el JDK, y existen restriccionespara bajarlo de la site de SUN, pero existen paquetes de terceros, desarrollados fuerade los Estados Unidos, que implementan todas las especificaciones del JCE y que noestan sujetos a sus restricciones legales, como por ejemplo la librerıa CRYPTICS.

4.16.1. Arquitectura Criptografica de Java (JCA)

El JCA, se refiere al marco para acceder y desarrollar la funcionalidad criptograficade Java. Incluye todo el API relativo a la criptografıa ( el paquete java.security y sus



subpaquetes), ası como una serie de especificaciones a tener en cuenta por los progra-madores que quieran crear extensiones criptograficas (como la librerıa CRYPTICS,etc).

La arquitectura criptografica de Java ha sido disenada teniendo en cuenta los prin-cipios de independencia de la implementacion e interoperabilidad. La independenciade la implementacion se consigue introduciendo el concepto de “Proveedor” (Cryp-tography Package Provider). El termino “Proveedor” se refiere a un paquete o grupode paquetes que que implementan algoritmos criptograficos especıficos.

El JDK 1.1 viene con un proveedor por defecto llamado “SUN”, el cual incluyeuna implementacion del algoritmo DSA y una implementacion de los algoritmos deHashing MD5 y SHA-1. En el JDK se pueden instalar uno o mas paquetes proveedores.

SecureRandom

La clase SecureRandom es un generador de numeros pseudo-aleatorio. Para crearobjetos 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 utilizandola semilla indicada en el array de bytes.

Una vez tenemos un objeto SecureRandom, podemos utilizar los siguientes meto-dos:

setSeed(byte[]): Reinicializa el SecureRandom utilizando la semilla indicada enel array de bytes.

setSeed(long): Reinicializa el SecureRandom utilizando los ocho bytes del longindicado.

next(int):Devuelve un entero conteniendo el numero indicado de bits pseudo-aleatorios.

Key

El interface Key es el interface de mas alto nivel de todas las claves y define lafuncionalidad compartida por todas las claves.


Fernando Ballesteros Herranz 4.16. ENCRIPTACION

PublicKey y PrivateKey

Los interfaces PublicKey y PrivateKey son interfaces sin metodos, que derivan dela interface Key, utilizados solamente para comprobacion de tipos.

KeyPair

La clase KeyPair es simplemente un contenedor de un par de claves (una publicay una privada). Tiene dos metodos:

PrivateKey getPrivate(): Devuelve la clave privada.

PublicKey getPublicKey(): Devuelve la clave publica.

KeyPairGenerator

La clase KeyPairGenerator se utiliza para crear un par de claves. Para crearobjetos KeyParGenerator usaremos uno de los siguientes metodos:

KeyPairGenerator getInstance(String algorithm): crea un generador de clavesutilizando el algoritmo criptografico indicado.

KeyPairGenerator getInstance(String algorithm, String provider): crea un gen-erador de claves utilizando el algoritmo criptografico indicado del proveedorindicado.

Identity

La clase Identity se utiliza para manejar identidades. Para crear identidades us-aremos 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 identidadescapaces de firmar datos.



Signature

La clase Signature se utiliza para crear o verificar firmas. Para crear objetos Sig-nature usaremos uno de los siguientes metodos:

Signature getInstance(String algorithm): crea un objeto firma utilizando el al-goritmo criptografico indicado.

Signature getInstance(String algorithm, String provider): crea un objeto firmautilizando el algoritmo criptografico indicado del proveedor indicado.

4.16.2. Extension criptografica de Java (JCE)

El JCE extiende el proveedor “SUN” e incluye una implementacion de los algorit-mos DES, 3DES, los modos ECB y CBC, y el estilo de relleno PKCS#5. Para utilizarotros algoritmos deberemos utilizar otro proveedor que los implemente. (Para utilizarel algoritmo RSA nosotros utilizaremos la libreria CRYPTIX).

SecretKey

La interface SecretKey es una interface sin metodos, que deriva de la interfaceKey, utilizada solamente para comprobacion de tipos.

KeyGenerator

La clase KeyGenerator se utiliza para crear una clave secreta. Para crear objetosKeyGenerator usaremos uno de los siguientes metodos:

KeyGenerator getInstance(String algorithm): crea un generador de claves uti-lizando el algoritmo criptografico indicado.

KeyGenerator getInstance(String algorithm, String provider): crea un generadorde claves utilizando el algoritmo criptografico indicado del proveedor indicado.


Fernando Ballesteros Herranz 4.17. CONCLUSIONES

Cipher

La clase Cipher se utiliza para cifrar o descifrar datos. Para crear objetos Cipherusaremos uno de los siguientes metodos:

Cipher getInstance(String algorithm): crea un objeto Cipher utilizando el algo-ritmo criptografico indicado.

Cipher getInstance(String algorithm, String provider): crea un objeto Cipherutilizando 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 lospunteros, pero la forma de programar es mucho mas simple, rapida y encapsulada delo que puede ser C++. Es un lenguaje orientado a objetos mas sencillo de aprenderque C++, y ademas es mas rapido y eficiente. Tambien hay que mencionar que conJava se pueden hacer dos tipos de programas, aplicaciones completas y Applets. Esun sistema multihilo y es facel de aprender como administrar las prioridades de loshilos. Da mejor soporte para las aplicaciones para internet, ya que uno de los camposmas fuertes de este leguaje son los Applets. Las conexiones y envıo de informacion atraves de la red es verdaderamente muy facil.

En la creacion de GUI, java ha avanzado mucho con los nuevos componentesSwing haciendo mas facil la programaion de estos. Gracias a la Maquina Virtualde Java, todas las aplicaciones desarrollas en este lenguaje pueden funcionar bajocualquier plataforma o sistema operativo, siendo por lo tanto multiplataforma. Elunico impedimento de esto es que para que funcionen las aplicaciones previamentehay que instalar la JVM, lo que trae consigo una molestia mas para los usuarios deestos programas.


Capıtulo 5

Estudio de librerıas JDT

[SOFT] [TIANI]

5.1. Introduccion

Java DICOM Toolkit es la ayuda para un programador en JAVA para construiruna aplicacion que siga lo marcado por el estandar DICOM 3.0. Combina las ventajasy la fuerza de DICOM y JAVA en una API muy facil de usar. Proporciona numerosasclases y metodos que simplifican la programacion de aplicaciones DICOM.

JDT1 es el primer equipo de desarrollo de software DICOM que esta implementa-do totalmente en JAVA. Con esto, los desarrolladores DICOM pueden beneficiarse delas numerosas ventajas del lenguaje de programacion JAVA y desplegarlo en DICOMapplets, aplicaciones independientes JAVA y en software de servidor. JDT viene conuna API bien documentada que ha sido disenada para hacer que la estructura com-pleja del estandar DICOM sea mas accesible para los desarrolladores. JDT funcionasobre JDK 1.1.X y JAVA 2.

5.2. Terminologıa

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

1Java Dicom Toolkit

151

CAPITULO 5. ESTUDIO DE LIBRERIAS JDT Fernando Ballesteros Herranz

atributo se identifica por su par (numero de grupo, numero de elemento), y tiene uncierto tipo DICOM (value representation - VR).

5.3. Datasets o conjunto de datos

5.3.1. Introduccion

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. Manipulacion de los atributos

Un conjunto de datos DICOM es representado por un objeto de la clase Dico-mObject. Los diferentes atributos de estos conjuntos de datos estan internamente al-macenados en el DicomObject como objetos com.archimed.dicom.Tagvalue. El objetoTagValue contiene un par (grupo,elemento) y los valores del atributo estan almacena-dos en un Vector. El tamano del Vector corresponde a la multiplicidad del atributo.El tipo JAVA que representa el valor de un atributo depende del tipo DICOM (Val-ue Representation - VR) definido para ese atributo especıfico. Las tablas 5.1 y 5.2muestra la equivalencia entre los tipos DICOM y sus correspondientes tipos JAVA.

Figura 5.1: Conversion entre tipo Java y tipo DICOM


Fernando Ballesteros Herranz 5.3. DATASETS O CONJUNTO DE DATOS

Manipulacion de atributos simples

Hay un numero de metodos set/get en DicomObject con los que se pueden meter,sacar o modificar los atributos guardados en un DicomObject. La forma de haceresto es con la clase com.archimed.dicom.DDict. La clase DDict tiene una constantedefinida 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 implıcitamente convierte el valor del argumento dado al tipo DICOMcorrecto.

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 meto-dos get/set con un argumento adicional. La multiplicidad de un atributo se obtienecon getSize(). Por ejemplo, suponiendo que un DicomObject dcm contiene un atrib-uto ImageType con multiplicidad 2 y valores DERIVED/SECONDARY, entonces sepuede coger esos valores de la siguiente forma:



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 multiplicidadmayor de uno. Cuando un atributo en un DicomObject representa una secuencia (tipoSQ DICOM), entonces los “items” de la secuencia pueden ser insertados y cogidoscon los mismos metodos get/set del DicomObject que ahora aceptan y devuelven losDicomObejcts completos. Por ejemplo, suponiendo que el DicomObject dcm contieneun atributo DirectoryRecordSequence con un cierto numero 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 anadir un valor a una secuencia, simplemente se usa el metodo set que tieneel DicomObject que representa el item y el ındice del item.

Son accesibles con las mismas funciones get/set de las secuencias como las us-adas en los datasets de los DicomObject. Esto provee a las secuencias de la mismafuncionalidad 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 cuidade todas las diferentes excepciones encontradas. El nombre elegido para los metodosson muy similares que los encontrados en el DicomObject.

Comentarios:



las longitudes de los grupos no se almacenan en un DicomObject, se calculancuando se necesitan, ası que no hay acceso a ellos.

cuando usamos set para insertar valores de atributos, los valores se alamacenanpor referencia y no se copian.

cuando usamos get para sacar valores de atributos, se devuelve una referenciaal valor.

Manipulacion 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 esla superclase de com.archimed.DicomObject. Un grupo es un conjunto de atributosque tienen el mismo numero de grupo en su par (grupo,elemento).

DicomObject copyGroup(int groupnr)

Copia el grupo con el numero 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 agregana los grupos que no estaban ya presentes en este dataset. Una vez mas solamente sehace una copia baja o no profunda.

DicomObject removeGroup(int groupnr)

Suprime un grupo entero con el numero “groupnr” de este dataset. Y lo devuelvecomo 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 quepermiten especificar todas las clases de parametros.



Leer datasets

void read(java.io.InputStream in)

Este metodo lee todos los atributos DICOM desde un inputStream de un Dico-mObject. El inputStream puede contener tanto un archivo DICOM como un conjuntode datos (datasets) DICOM. Cuando el inputStream contiene un archivo de la parte10 DICOM, se lee y se almacena la Meta File Information en un DicomObject sep-arado que se puede coger mediante getFileMetaInformation(). La transfer syntax seasume que es Implicit VR Little Endian cuando el inputStream contiene un conjun-to de datos DICOM. Cuando el inputStream contiene un archivo de la parte 10 deDICOM, 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 analizaro saltar datos de pıxel. Esto ahorra el tiempo de transformacion en el que no senecesita los datos de pıxel.

void read(java.io.InputStream in, int ts, boolean process)

En el parametro “ts” se puede especificar que transfer syntax se usa. Este parametropuede venir dado cuando se conoce por adelantado con que transfer syntax se codif-ico 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 cuandoes necesitada. Observar que la creacion de la meta information puede lanzar unaexcepcion, cuando los atributos requeridos faltan (SOP Class UID, SOP InstanceUID).

void write(java.io.OutputStream out, boolean f,

int ts, boolean seq_undef)



Los parametros adicionales “ts” y “seq_undef” se pueden utilizar para escribirconjunto de datos casi en todos los posibles tipos de DICOM. Los parametros ts yseqUndef pueden ser usados para insertar la Transfer Syntax. Toda posible combi-nacion de parametros ts y f se permiten, pero no todas las combinaciones siguen losdictados del estandar de DICOM. Si se escribe un conjunto de datos con f “false” y tsotra cosa que no sea Implicit VR Little Endian, sera imposible para otras aplicacionesdecodificarlo ya que no pueden detectar el Transfer Syntax usado. El parametro se-qUndef indica al escribir secuencias si se usa longitud undefinida (true) o definida(false).

Visualizacion de datasets

DicomObject contiene dos metodos para mostrar todos los atributos contenidosen 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 lıneas decodigo, 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 usandouna transfer syntax y una secuencia de codificacion especıficas.

DicomObject dcm = new DicomObject;

dcm.read(new FileInputStream("in.dcm"));

dcm.write(new FileOutputStream("out.dcm"), true,

TransferSyntax.ExplicitVRBigEndian, true);



5.3.4. Metodos utiles

Enumeracion 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 comoobjetos 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 usarahora fmi para anadir o alterar atributos especıficos de esta informacion como sequiera.

Informacion general

Unos pocos metodos de com.archimed.dicom.GroupList proporcionan informaciongeneral sobre un conjunto de datos:

int numberOfElements(): devuelve el numero total de atributos.

int numberOfGroups(): devuelve el numero total de grupos.

boolean isEmpty(): devuelve si el GroupList contiene algun atributo.

boolean containsGroup(int g): devuelve si el GroupList contiene el grupo especi-ficado.


Fernando Ballesteros Herranz 5.4. DEPOSITOS

5.4. Depositos

Hay unas clases en el paquete com.archimed.dicom que hacen mas facil a los pro-gramadores usar los data elements y los registros UIDs.

5.4.1. Clase DDict: deposito de atributos

La clase com.archimed.dicom.DDict es un almacen de los VRs (value representa-tions) y los data elements. Contiene un numero de constantes que representan losdiferentes 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 metodos 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 DDictdel atributo basada en su par (grupo,elemento).

static int getGroup(int dct)

Devuelve el numero de grupo para una constante DDict que representa un atrib-uto.

static int getElement(int dct)

Devuelve el numero de elemento para una constante DDict que representa unatributo.

static int getTypeCode(int dct)



Devuelve el tipo para una constante DDict que representa un atributo. Los ele-mentos 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 atrib-uto.

static int lookupDDict(int g, int e)

Devuelve la constante DDict que representa el atributo con numero de grupo “g”y numero de elemento “e”. Si no se encuentran constantes, el metodo devolvera DDict.dUNDEFINED.

5.4.2. Clase UID: depositos UID

La clase com.archimed.dicom.UID contiene un deposito de los UIDs DICOM reg-istrados (Parte 6 DICOM).Las constantes que representan los UIDs y que tienen queser usadas a traves de JDT se definen en subclases de UID:

com.archimed.dicom.TransferSyntax: constantes que representan las transfer syn-tax.

com.archimed.dicom.SOPClass: constantes que representan las clases SOP.

com.archimed.dicom.MetaSOPClass: constantes que representan las clases MetaSOP.

com.archimed.dicom.SOPInstance: constantes que representan las instancias SOP.

El objeto com.archimed.dicom.UIDEntry representa un unico identificador y seobtiene con la clase UID de dos formas. Usando una constante de una de las subclasesUID:

UIDEntry entry = UID.getUIDEntry(TransferSyntax.JPEGBaseline);

o usando una cadena UID:


Fernando Ballesteros Herranz 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 esun contenedor de varias propiedades del identificador unico especıfico. Esos atributospueden ser obtenidos usando los metodos get.

5.5. Imagenes en JDT

Esta parte habla de las capacidades de imagen de JDT. Todas las clases rela-cionadas 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. Aparte de los metodos set/get basicos para manipular los datos, inherentes al Di-comObject, contiene otras formas de coger e insertar los atributos requeridos (tipo1 y tipo 2) que son comunes a todos los DICOM Image Modality IODs (ver parte3 de DICOM). Cuando se escribe una DicomImage en un outputstream, no hay unreconocimiento de si todos los atributos requeridos estan presentes.

5.6. Guıa para usuarios de JDT

5.6.1. Insertar datos que no son de imagen

DicomImage contiene un numero de metodos para insertar los atributos requeridosque no estan relacionados con los datos de imagen. Una corta descripcion son estosmetodos:

void patientData(String patientName, String patientID, String birthDate, Stringsex): inserta los datos del paciente.

void generalStudyData(String instanceUID, String date, String time, String phys-Name, String studyID, String orderNumber): inserta los atributos del estudiogeneral.



generalSeriesData(String modality, String instanceUID, String seriesNumber):anade los datos generales de serie.

generalEquipmentData(String manufacturer): anade datos sobre el equipo uti-lizado.

generalImageData(String imageNumber): anade datos de imagen.

sopCommonData(String sopClassUID, String sopInstanceUID): inserta los datoscomunes SOP. SOP Class UID es tıpicamente uno de las diferentes image storageSOP Classes, que pueden ser encontrados en com.archimed.dicom.SOPClass.

5.6.2. Insertar datos de imagen con los metodos de DicomIm-age

Hay tambien metodos en com.archimed.dicom.image.DicomImage que pueden serusados para insertar los datos de los pıxeles de la imagen. La clase contiene metodospara imagenes en escala de grises, en paleta de colores y en RGB. Una definicion detodos 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,tamano 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 copiarlos datos de imagen desde la ImageProducer a la DicomImage:

DicomImage dcmi = new DicomImage();

ImageIO imgio = new ImageIO(dcmi);

imgio.setImageProducer(ip);


Fernando Ballesteros Herranz 5.6. GUIA PARA USUARIOS DE JDT

Cuando se llama al metodo setImageProducer(), todos los datos se copian dentrode la DicomImage.

Obteniendo una ImageProducer desde una DicomImage es tambien posible. Todomarco simple de una imagen DICOM se puede coger como una ImageProducer usandouno 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, hayun color model (clase de java) especial com.archimed.dicom.image.GrayColorModel.Este color model se usa en combinacion con un array int de pıxeles, para producirimagenes de 256 grises sin perdida de datos. Con este GrayColorModel, tambien esposible meter el Window/Level usado en la produccion de la imagen.

no-comprimido transfer syntax, una imagen: un array de bytes que mantiene elformato original de los datos de pixel definido en el estandar DICOM, ejemplos:

• imagen MONOCHROME2, 8 bits asignados, 8 bits alamcenados: 1 ele-mento del array de bytes por pixel.

• imagen MONOCHROME2, 16 bits asignados, 12 bits alamcenados: 2 ele-mentos consecutivos del array de bytes por pixel.

• imagen MONOCHROME2, 12 bits asignados, 12 bits alamcenados: 1 ele-mento y medio del array de bytes por pixel.

• imagen RGB, configuracion plana color por pixel: 3 bytes consecutivosrepresentando 1 pixel.

• imagen RGB, configuracion plana color por plano: el array de bytes esta di-vidivo en 3 partes de igual longitud cada una representando un color deplano (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 contienenmarcos consecutivos.

comprimido transfer syntax, una imagen: un array de bytes en el formato orig-inal de compresion.



5.6.4. Compresion

Los datos de pıxel de una imagen DICOM se almacena en el atributo DDict.dPixelData.Cuando una imagen DICOM comprimida se lee desde un inputstream, los pixeldatano se decodifican pero se almacenan internamente en arrays de bytes en su formatode compresion por razones de rendimineto. El tipo de codificacion puede ser sacadode 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 unnumero de decodificadores:

JPEG baseline

JPEG lossless

RLE Lossless

Todos los decodificadores estan limitados a 8 bits por pıxel. El decodificador JPEGpuede manejar 1 o 3 muestras por pıxel. RLE es solo capaz de descomprimir 1 muestrapor pıxel. El camino mas facil para descomprimir imagen entera DICOM es construirun objeto Compression desde un DicomObject y despues llamar al metodo decom-press. Este descodifica los datos del array de pıxeles del DicomObject y los reemplazapor los datos descomprimidos.

En el caso de una imagen DICOM multimarco, se puede decodificar el array debytes correspondioente a un marco individual. Primero obteniendo un array de bytesde un marco con get(DDict.dPixelData, ¡index of frame¿) y luego usando el metodoestatico decompressframe() del objeto Compression para obtener un array de bytesdecodificado 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 suministradospara usar decompressframe() se encuentran en la imagen DICOM original.


Fernando Ballesteros Herranz 5.7. CREACION DE UNA CONEXION

5.7. Creacion de una conexion

Para establecer una asociacion con una entidad del par DICOM, se hace usolas clases del paquete com.archimed.dicom.network.. Es necesario un iniciador de laasociacion y un receptor de la asociacion.

5.7.1. Iniciador de la asociacion

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 lasclases estandares de java.net. En este ejemplo el servidor es “Fourier” y el puerto104.

Socket s = new Socket("Fourier",104);

2. Crear un objeto “Association” con los Input and Output Streams derivadas deSocket.

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 unaasociacion. Los parametros son al menos un tıtulo de la entidad de la aplicacionllamada (called), un tıtulo de la entidad de la aplicacion llamar (calling) y unabstract syntax con un sintaxis de transferencia. En el ejemplo el tıtulo de laentidad called es “hola” y el calling es “Servicio”. Estos tıtulos no deben ser masde largos de 16 caracteres. Conectamos con “hola” para almacenar una imagensecundaria 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 envıa la peticion a la entidad del par DICOM y recibe la respuesta.



as.sendAssociateRequest(request);

Response response = as.receiveAssociateResponse();

5. Analiza la respuesta. Se comprueba si se acepta, se rechaza o se aborta nuestrapeticion.

if (response instanceof Reject)

{

System.out.println("peticion de asociacion rechazada");

System.out.println(response);

}

else if (response instanceof Abort)

{

System.out.println("peticion de asociacion abortada");


}

else

{

System.out.println("peticion de asociacion aceptada");

Acknowledge ack = (Acknowledge)response;

if (ack.getPresentationContexts() != 1)

{

System.out.println("numero incorrecto de Contexto

de Presentacion");

throw something;

}

int result = ack.getResult(0);

if (result == Acknowledge.ACCEPTANCE)

{

System.out.println("Contexto de Presentacion 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 ImageStorage y podemos enviar imagenes SC a la entidad del par DICOM.

DicomObject cstorerequest;



DicomObject cstoreresponse;

DicomObject scimage;

// crear una peticion 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 asociacion

Cuando una aplicacion actua como receptor de la asociacion, espera conexionesentrantes de TCP/IP con el metodo de accept() de java.net.ServerSocket y dedica unhilo para cada conexion entrante. En este ejemplo se empieza con el punto donde unaentidad del par DICOM ha hecho una conexion de TCP/IP, dando por resultado unobjeto valido de java.net.Socket que es devuelto por el metodo accept(). El codigo delejemplo 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 devueltopor el accept() y crear un nuevo objeto Association.



// 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 CaptureImage Storage y Verification” y nuestro tıtulo de la entidad de aplicacion es= “hola”. No se comprueba el tıtulo 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 respuestaes “Acknowlwdge” (Reconocida) se entra es un lazo que reciba y procese laverificacion o Secondary Capture Image Storage relacionado con el comandoDIMSE. El lanzamiento de la asociacion tambien se maneja en el lazo.

if (response instanceof Reject)

{

System.out.println("Peticion de asociacion 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();



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 valida peticion

// 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 peticion valida 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("asociacion acabada");

return;

}

else if (result == Association.ABORT)

{

Abort abort = as.receiveAbort();

s.close();

System.out.println("asociacion acabada por el par");

System.out.println(abort);



return;

}

}

}

5.8. Estructura de JDT

5.8.1. 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


Fernando Ballesteros Herranz 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 parametrosson, la fuente y la razon del aborto.



Acknowledge (Reconocer): Estos objetos tienen los parametros de la asociacionAcknowledge, contiene todos los contextos de presentacion del Acknowledge yson 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 aso-ciacion entre dos entidades de aplicacion DICOM y mandar/recibir comandosy 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 ab-stracto

Reject (Rechazo): Representa el rechazo de una asociacion. Sus parametros sonfuente, resultado y razon.

Request (peticion): Representa todos los parametros relevantes de una asociacionRequest. Contiene todos los contextos de presentacion y son numerados desde 0hasta el no de contextos de presentacion menos uno. Puede actuar como receptorde 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 daday una polıtica de aceptacion de la asociacion.

• Metodos para el analisis de respuestas Acknowledge, en el contexto de unapeticion dada.

Com.archimed.dicom.codec

Compression (compresion): Es una clase que proporciona metodos para la de-scompresion de datos de Pixel. DICOM soporta muchos tipos de tecnicas decompresion.

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 imagenesde Escala de gris.


Fernando Ballesteros Herranz 5.8. ESTRUCTURA DE JDT

ImageIO: Es una clase que proporciona metodos de convertir datos de imagenalmacenados 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 den-tro de secuencias. La conversion de valores esta hecha usando el esquema deconversion DicomType-JavaType dada en la clase DicomObject.

Com.archimed.dicom

DDate: Esta clase representa la fecha de un objeto, conteniendo el dıa, mes yano. Se ha desarollado en correspondencia al tipo Dicom DA. Es util, cuandose 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) paralos VRs y todos los elementos de datos. Cada par (grupo,elemento) es accesi-ble por una variable static int. Por ejemplo, (0010,0010) es representado porDDic.dPatientName.

DDictEntry: Un objeto para una etiqueta que puede ser almacenado en el dic-cionario de datos.

Debug: Proporciona una variable static int por si hay que imprimir informacionde reparacion de los errores a System.err.

DicomObject: Esta es la clase base de todos los datasets. Los metodos de accesoproporcionados aquı son el modo de obtener/poner elementos de dato (dataelements) 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 com-pensaciones en un DicomObject que va a ser escrito.

Person: Esta clase representa el PN (Person Name) en Dicom.



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 ySOPInstance.

UIDEntry: Representa la entrada de un UID en el deposito, almacenandose.

DicomExcepcion: Indica que la aplicacion ha violado la estructura y codificaciondel Dicom Data.

IllegalValueExcepcion: Indica que un valor ilegal es leıdo durante una asociaciono cuando un valor ilegal es argumento de un metodo.

UnknownUIDExcepcion: Indica que el UID incluido no esta definido en la claseUID.

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 sino se es un gran experto en materia DICOM y en programacion en C++, la profun-dizacion de su estudio es muy complicada y engorrosa, debido a la poca documentacionproporcionada 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 grandesventajas que el toolkit dcmtk351 no tiene. Lo primero a senalar es que el lenguajede programacion es JAVA, con las ventajas que conlleva con respecto a C++. Porotro lado, contiene una documentacion amplia y muy bien estructurada, gracias a lautilidad de javadocs, lo que facilita enormemente el trabajo y su comprension. JDTcontiene un arbol de clases, informacion de los diferentes packages, informacion sobrelas 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/Servidorpara la Red, las aplicaciones en Java son mas faciles y potentes.


Fernando Ballesteros Herranz 5.9. CONCLUSIONES

Figura 5.2: Conversion de tipo DICOM a tipo Java


Capıtulo 6

Desarrollo de aplicacion

6.1. Introduccion

En este capıtulo se describen las herramientas usadas para la implementacion dela aplicacion DICOM, tanto del cliente como del servidor.

Para estas dos aplicaciones hay que elegir el entorno de desarrollo a utilizar.Pueden ser utilizados multiples sistemas como TextPad, Visual J++, el propio JDKo JBuilder.

El primero en analizar es el que viene incluido en el SDK, que es el JDK. Estecompilador es utilizable con cualquier editor de texto, pero es inadecuado para proyec-tos largos, por su pesadez textual y poca ayuda. Este compilador fue el primero enutilizarse, pero debido a la extension del proyecto realizado se tuvo que mirar otroscompiladores.

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 perderel potencial de Java, se decidio cambiar a otro entorno.

El TextPad fue el elegido para la creacion de la aplicacion Servidor, ya que esun compilador parecido al JDK, pero con mas ayudas y menos pesadez a la hora deprogramar.

El JBuilder de Borland fue utilizado para deserrollar el Cliente, ya que trae unbuen soporte a para la implementacion de las GUIs. Este entorno de desarrollo esmucho mas completo, especıfico y con muchas mas prestaciones que Visual J++.

177

CAPITULO 6. DESARROLLO DE APLICACION Fernando Ballesteros Herranz

Por lo tanto para el desarrollo del Servidor se utiliza el compilador TextPad 4.7.0,las librerıas SDK v1.4.1, el paquete JCE para la encriptacion/desencriptacion y laslibrerıas DICOM JDT, mediante las cuales se va a implementar la aplicacion DICOM.

Para el desarrollo del Cliente es necesaria la utilizacion del entorno de desarrolloJBuilder (version 7.0 Enterprise, pero compatible con la 8.0 y 9.0), las librerıas delSDK v1.4.1, el paquete JCE1 y las librerıas DICOM JDT.

6.2. Uso de SDK

6.2.1. Introduccion

En esta seccion se van a ver los aspectos mas importantes para la compilacion dearchivos fuentes y se van a describir las herramientas mas utilizadas en el trabajo conJava.

Para poder realizar aplicaciones en Java es necesaria la instalacion de las libre-rias de SDK. Este paquete de librerıas viene con la Maquina Virtual de Java, parapoder desde cualquier archivo fuente (.java) poder crear una apliacion. Esta maquinavirtual tambien es valida para poder visualizar y que se puedan ejecutar programasdesarrollados en java.

6.2.2. Instalacion en Windows 98

La instalacion puede ser o bien solo de la Maquina Virtual de Java(JRE Java En-viroment Enterprise), para poder ejecutar programas de Java pero no poder compilarficheros fuente, o bien la instalacion de las librerıas y la MVJ para poder ejecutar ycompilar programas Java.

Maquina Virtual de Java

Para la instalacion de la Maquina Virtual de Java se debe descargar de la paginahttp://java.sun.com, teniendo que elegir la opcion del JRE para Windows. Una vezdescargado el archivo “j2re-1_4_1_03-windows-i586-i.exe”, se procede a la instalacionla cual es muy sencilla. Unicamente hay que ejecutar el archivo nombrado, de esta

1Java Cryptography Extension



Fernando Ballesteros Herranz 6.2. USO DE SDK

forma la JVM esta instalada y podemos ejecutar correctamente cualquier aplicaciondesarrollada en Java.

SDK

La instalacion a realizar son de las librerıas de la ultima version SDK 1.4.1 que sepuede descargar de la pagina (http://java.sun.com). Con la instalacion de las librerıasviene incluida la JVM2.

El primer paso a realizar es descargar el archivo, eligiendo la opcion SDK paraWindows. 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 librerıas ylos ejecutables de las utilidades que ofrece Java, como son el compilador javac.exe, eljavadocs,. . .

El tercer paso es el mas importantes ya que aunque se tengan las librerıas y losejecutables, hay que decir a la computadora donde estan. Este paso es el que diferenciaWindows 95/98 con Windows NT/2000/XP. En Windows 98 hay que dar el PATH dedonde se encuentran los ejecutables y hay que crear un CLASSPATH donde debemosdar el camino para llegar a las librerıas del SDK. Los pasos para realizar esto son:

1. En el directorio raız del sistema operativo “C:\”, se encuentra el archivo “Au-toexec.bat”. Este archivo se carga cuando se inicia la computadora. Para mod-ificarlo, hay que abrir el archivo con un editor de texto, esto se puede hacerhaciendo click derecho mientras se pulsa Shift, y se elige Abrir con. . . . Saldra unmenu 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 lınea en laque pone “SET PATH”, pues en esa lınea debemos incluir el directorio bin delsdk1.4.1. con lo que quedarıa:

SET PATH = . . . ;C:\J2SDK1.4.1_03\BIN;%Path%

3. Ahora hay que crear el CLASSPATH. Para realizar esto hay que escribir el finaldel 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 librerıas del SDK y la Maquina Virtual deJava.

2Java Virtual Machine




Para utilizar las librerıas en cualquier fichero fuente, basta realizar un import delpaquete o clase a utilizar. Para poder trabajar con SDK es muy importante disponerde la ayuda del API de la pagina web http://java.sun.com. La figura 6.1 muestra laorganizacion 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 esnecesario para la encriptacion y desencriptacion de la informacion que se transfiereen 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.como bien http://snad.ncsl.nist.gov.

2. Descomprimir el archivo descargado, el jce-b1.1-socket.zip. El lugar donde hemosdescomprimido nosotros es en C:\JAVA




http://snad.ncsl.nist.gov/madvtg/Java/download.html


3. Anadir 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 queviene 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. Instalacion en Windows 2000

Maquina Virtual de Java

1. Descargar de la pagina http://java.sun.com, teniendo que elegir la opcion delJRE para Windows.

2. Una vez descargado el archivo “j2re-1_4_1_03-windows-i586-i.exe”, se procedea la instalacion la cual es muy sencilla. Unicamente hay que ejecutar el archivonombrado, de esta forma la JVM esta instalada y podemos ejecutar correcta-mente cualquier aplicacion desarrollada en Java.

SDK

1. Descargar el archivo eligiendo la opcion SDK para Windows. Este archivo sellama “j2sdk-1_4_1_03-windows-i586.exe”.

2. Ejecutar el archivo de esta forma se generan las librerıas y los ejecutables delas utilidades que ofrece Java, como son el compilador javac.exe, el javadocs,jar.exe,. . .

3. Entrar en Inicio->Configuracion->Panel de Control->Sistema->Avanzado->Variablesde 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 variableescribir C:\j2sdk1.4.1_03\lib\dt.jar;.;




7. Como ultimo paso dar a Aceptar tres veces secuencialmente para que los cambiosse apliquen.

JCE

1. Bajarse este paquete de internet, de las posibles paginas como http://java.sun.como bien http://snad.ncsl.nist.gov.

2. Descomprimir el archivo descargado, el jce-b1.1-socket.zip. El lugar donde hemosdescomprimido nosotros es en C:\JAVA

3. Anadir 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 queviene 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 es-crito en los ficheros fuente de Java (con extension *.java). Si no encuentra errores en elcodigo genera los ficheros compilados (con extension *.class). En el JDK de Sun dichocompilador se llama javac.exe. Java.exe es el interprete para sistemas PC/Windows.

Una vez compilado no deberıa ser necesaria ninguna modificacion por el hechode cambiar de procesador o de ejecutarlo en otra maquina. La clave consistio endesarrollar un codigo “neutro” el cual estuviera preparado para ser ejecutado sobrela JVM.

Para realizar una aplicacion con el compilador del SDK, se debe escribir el codigoen Java en un editor de texto cualquiera como puede ser el “Bloc de Notas”. Una vezescrito debe ser guardado el fichero con extension .java, por ejemplo nombre.java. La

3JDK para las antiguas versiones y SDK para las nuevas versiones



http://snad.ncsl.nist.gov/madvtg/Java/download.html


compilacion debe realizarse con un “shell” de comandos, como el del MSDOS. Pararealizar la compilacion escribir:

X:\. . . \javac nombre.java

Figura 6.2: Compilacion con SDK

Con la compilacion se genera un archivo .class, en este caso serıa 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 diseno del lenguaje se ha tenido en cuenta la documentacion de los programasy el mantenimiento de dicha documentacion. La documentacion y el codigo se incluyendentro del mismo fichero.

El tipo de comentario especıfico para documentar debe ser:

/** Comentario de documentacion */

La generacion de la documentacion se realiza en formato HTML. Se pueden crearetiquetas de documentacion, que luego en la documentacion en HTML, saldra comoun pequeno apartado, esto se realiza poniendo @ delante de la lınea que queramosque sea una etiqueta.



Figura 6.3: Api generada con Javadocs

Los comentarios deben aparecer inmediatamente antes de los elementos a comen-tar. La utilidad de documentacion javadoc es un programa que se suministra dentrode 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 deJavadoc.

4Java 2 Standard Edition



jar

Esta utilidad es usada para generar archivos .jar que contienen todas las clasesde la aplicacion realizada. Esto se realiza para su posterior distribucion. Ejecutandoel .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 cadafichero anadido al fichero JAR.

0 - indica que no quieres que el fichero JAR sea comprimido.

M - indica que no se deberıa producir el fichero de manifiesto por defecto.

m - utilizada para incluir informacion de manifiesto desde un fichero de man-ifiesto existente. El formato utilizado por esta opcion es: jar cmf existing-manifest 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. Puedesutilizar cualquier nombre de fichero. Por convencion, a los ficheros JAR se lesda la extension .jar, aunque no es obligatorio.

El argumento fichero(s)-de entrada es una lista delimitada por espacios de unoo mas ficheros que deben ser situados dentro de tu fichero JAR. Este argumentopuede tener simbolo del comodın *. Si alguno de los fichero(s)-de entrada, es undirectorio, el contenido de dicho directorio se anadira al fichero JAR recursiva-mente.

Este comando generara un fichero JAR comprimido y lo situara en el directorioactual. El comando tambien genera un fichero de manifiesto, por defecto. META-INF/MANIFEST.MF, para el archivo JAR.



Los pasos seguidos para crear el JAR de nuestra aplicacion Servidor. Estos pasosse realizan en el Shell de comandos de MSDOS:

1. Crear un archivo nuevo (incluyendo las clases y otros recursos que te interesenempaquetar).

jar Main.jar c:\encri.class c:\Connection.class c:\Storagescu.classc:\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 algun editor de texto corriente). Lo que se hace esagregar la lınea siguiente al archivo MANIFEST.MF (este paso no se hace enMSDOS):

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. Uso de TextPad

6.3.1. Introduccion

TextPad es un editor que incluye un compilador de java. En este apartado se velas caracterısticas de este editor y su relacion con java.

6.3.2. Caracterısticas

TextPad es un poderoso editor de programas disenado para proporcionar poten-cia y funcionabilidad para satisfacer los requisitos mas exigentes. Archivos enormespueden ser editados (hasta los lımites de memoria virtual). El interfaz multiple dedocumento de Windows permite editar multiples archivos simultaneamente, con has-ta 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


Fernando Ballesteros Herranz 6.3. USO DE TEXTPAD

tipeo mas comunes con comandos, y transportar palabras, caracteres y lıneas. El tex-to puede ubicarse automaticamente en el margen, o en una columna especificada, sino cabe en una lınea. Cualquier cambio puede ser deshecho o hecho de nuevo. Lascombinaciones con frecuencia usadas de comandos se pueden salvar como macros. Elprograma posee herramientas personalizables y opciones de busquedas. 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 tansolo hay que grabarlos con la extension .java.

El TextPad tambien tiene un compilador de java, aunque carece de maquina vir-tual para ejecutar programas desarrollados en java y de las librerıas. Este compiladorsolo funciona con la instalacion previa de las librerıas del JDK o SDK.

Una vez instaladas las librerıas, para instalar el TextPad tan solo hay que ejecutarel archivo Setup del programa.



El compilador muestra que errores ocurren en la compilacion y si no ocurre ningunerror genera el archivo .class.

No tiene ayudas para java. Es un editor en el que viene incluido un compilador dejava. No es bueno para la creacion de interfaces graficas, por esto en nuestra aplicacionsolo ha sido utilizado para la creacion del Servidor DICOM, ya que este no necesitainterfaz de usuario, es una aplicacion que se administra ella sola sin necesidad deintervencion directa.

6.4. Uso de JBuilder

6.4.1. Introduccion

En esta seccion se van a ver los aspectos mas importantes del JBuilder 7.0 Enter-prise. 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 desarrolladacon el JBuilder. La aplicacion del cliente es compatible con las nuevas versiones quehan ido saliendo a lo largo del ano del JBuilder como las versiones 8.0 y 9.0.

6.4.2. Instalacion

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 deJBuilder 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 utilizaWindows NT/2000 o colocarla en la carpeta Windows si se trabaja en Windows95/98.

4. Ejecutar el JBuilder y cuando pida un archivo de activacion indicarle la ruta aseguir para llegar a este.

5. Una vez hecho esto se tiene un programa de prueba de 1 mes, pero si se consigueun archivo jbuilder.jar sustituto al que venga con la aplicacion, este se debe so-brescribir sobre el existente, que esta locacizado en . . . /JBuilder/bin/jbuilder.jar.


http://www.borland.com/products/downloads

Fernando Ballesteros Herranz 6.4. USO DE JBUILDER

6.4.3. JDK y JBuilder

Al instalarse el JBuilder, instala por defecto el JDK v1.3.1 y utiliza estas librerıaspara compilar.

En nuestra aplicacion ha sido necesaria la utilizacion de las JDK 1.4.1, por lo quehay que cambiar la referencia de las librerıas. Para cambiar las JDK 1.3.1 a las JDK1.4.1 hay realizar una pequena 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 nuevaslibrerıas en nuestro caso C:/j2sdk1.4.1_03

5. Pulsar Aceptar



Figura 6.6: Designacion de nuevas JDK

Con esto hecho, las aplicaciones que se realicen a partir de este momento se apo-yaran en las nuevas librerıas designadas. Ver figura 6.6

6.4.4. Creacion de aplicaciones en JBuilder

Se va a crear un simple editor de texto para ver como se realiza una aplicacion enel JBuilder. A partir de este ejemplo es posible realizar aplicaciones mas completas ycomplejas. Tan solo recordar que el JBuilder esta orientado a la creacion de interfacesde usuario y con esto desarrollamos nuestra aplicaion Cliente DICOM.

Pasos:

Paso 1: Creacion de un proyecto

Para crear un proyecto se usa el asistente para proyectos y el asistente para apli-caciones, de esta forma:

1. Pulsar Archivo->Nuevo Proyecto

2. Realizar los siguientes pasos:



Figura 6.7: Asistente para proyectos

Nombre: Editor de Texto. (Ası se llamara el proyecto y la carpeta dondese encontrara el proyecto)

Tipo (tipo de archivo): .jpx

Seleccionar la opcion “Generar archivo de notas del proyecto”. Al selec-cionar esta opcion, el asistente para proyectos crea un archivo HTML paralas notas del proyecto y lo anade 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->Propiedadesdel Proyecto. . . . En nuestro caso ajustaremos el Estilo de codigo a Adaptador estandar

Una vez creado nuestro proyecto, pasamos a crear una aplicacion dentro del proyec-to mediante el asistente para aplicaciones:

1. Pinchar en Archivo->Nuevo.

2. Hacer doble click sobre el icono Aplicacion para abrir el Asistente para aplica-ciones. Ver figura 6.8

3. Poner el nombre del paquete igual al nombre del proyecto creado, y el nombrede la clase el que se quiera. (Tener en cuenta que este nombre sera el nombrede la clase principal)

4. Pulsar Siguiente para ir al Paso 2. Marcar la opcion de Generar comentarios decabezera



Figura 6.8: Galerıa de objetos

5. Poner nombre de clase y de Tıtulo (este sera el tıtulo que aparecera en la barra detıtulo de la aplicacion). Marcar las 5 opciones que hay: Generar barra de menu,Generar barra de herramientas, Generar barra de estado, Generar cuadro Acercade y Centrar marco en la pantalla. De esta forma se genera automaticamente elcodigo mas general correspondiente a las opciones seleccionadas. Ver figura 6.9

6. Pulsar en Finalizar. Se anade al proyecto un archivo .java y archivos de imagen.

7. Guardar el proyecto utilizando Archivo->Guardar Proyecto.

8. Pulsar la pestana Diseno del archivo abierto, TextEditFrame.java. La pestanaDiseno, ubicada en la parte inferior de la ventana del Visualizador de apli-caciones, abre el disenador de interfaces de usuario. Ver figura 6.10 Se puedeobservar cambios en el IDE de JBuilder:

En el panel de contenido aparece el disenador de interfaces.

El arbol de componentes aparece en el panel de estructura.

El Inspector aparece a la derecha del disenador.

Paso 2: Anadir area de texto

En este paso se crea un area de texto que rellena por completo el marco de lainterfaz de usuario entre la barra de menus y la barra de estado. Para lograrlo, elgestor de diseno del contenedor principal de la interfaz de usuario debe utilizar Bor-derLayout. Como consecuencia de la utilizacion del Asistente para aplicaciones, elprincipal contenedor de esta interfaz de usuario, que aparece como this en el arbol de



Figura 6.9: Asistente para aplicaciones

componentes, contiene un JPanel denominado contentPane que ya se ha cambiado aBorderLayout. Lo unico que hay que hacer ahora es anadir los componentes del areade texto a contentPane.

Para ello, se anade un panel de desplazamiento en el contentPane y despues secoloca un componente de area de texto dentro del panel de desplazamiento. El panelde desplazamiento proporciona barras de desplazamiento al area de texto.

1. Hacer click en la pestana TextEditFrame del editor, y a continuacion seleccionarla pestana Diseno.

2. Hacer click en el componente contentPane del arbol de componentes para se-leccionarlo, como se muestra a continuacion. Figura 6.11.

3. Pulsar la pestana Contenedores Swing en la paleta de componentes y seleccionarel componente JScrollPane.

4. Hacer click en el centro de contentPane del disenador de interfaces. Esto coloca elcomponente JScrollPane en el panel de contenido y deberıa darle una restriccionde centro BorderLayout, haciendo que ocupe completamente el area situadaentre la barra de herramientas y la barra de desplazamiento. Otra forma esseleccionando Edicion->Deshacer.

5. Seleccionar el nuevo componente jScrollPane1 en el arbol de componentes.



Figura 6.10: Vista en diseno

6. Fijarse en el valor de la propiedad constraints del Inspector y compruebar quese le esta asignando el valor “Center”. Si no es ası, seleccionar Center de la listadesplegable.

7. Pulsar la pestana Swing en la paleta y seleccionar el componente JTextArea.

8. Hacer click sobre el componente jScrollPanel en el arbol de componentes oarrastrarlo al disenador de interfaces para colocar JTextArea en el panel dedesplazamiento.

9. En el Inspector, hacer click con el boton derecho sobre la propiedad text yseleccionar “Borrar” el valor de la propiedad para eliminar es “jTextArea1” delarea de texto.

10. Por ultimo, se deben definir algunas propiedades en jTextArea1 para que seajusten automaticamente las lıneas de texto y se haga en los espacios entrepalabras. 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:



Figura 6.11: contentPane

1. Seleccionar Proyecto->Ejecutar Make del proyecto en el menu. Esto compilatodos los archivos del proyecto y crea un archivo TextEdit -> Class.class y unTextEditFrame.class en una carpeta de clases dentro de la carpeta de proyectos.Deberıa compilarse sin errores.

2. Hacer click en el boton “Ejecutar” en la barra de herramientas de JBuilder oseleccionar Ejecutar->Ejecutar proyecto en el menu. Ahora la interfaz de usuarioofrece un aspecto similar al de la figura 6.12

3. En la aplicacion “Editor de texto”, seleccione Archivo->Salir para cerrar laventana de ejecucion.

Paso 3: Crear menus

En este paso se van a crear estos menus:

1. Hacer click en la pestana Diseno de TextEditFrame.java si aun no esta selec-cionada.



Figura 6.12: Editor de texto ejecutado

Figura 6.13: Menu

2. Hacer doble click sobre jMenuBar1 en la carpeta Menu del arbol de componentespara abrir el disenador de menus. (Tambien puede seleccionar un elemento demenu del arbol de componentes y pulsar Intro)

3. Seleccionar el elemento de menu Archivo->Salir en el disenador de menus ojMenuFileExit en el arbol de componentes. El disenador de menus resaltara elelemento seleccionado.

4. Hacer click en el boton Insertar elemento de menu de la barra de herramientasdel disenador de menus, o pulse la tecla “Insert” del teclado. Encima de Salirse introduce un nuevo elemento de menu resaltado y vacıo.

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 menu Salir).



7. Hacer click derecho en Salir y seleccionar Insertar elemento de menu en elmenu contextual. Escribir “Abrir”.

8. De la misma forma, anadir los elementos de menu “Guardar” y “Guardar como”.

9. Seleccionar Salir y hacer click en el boton Separador de la barra de herramientaspara insertar una barra. El menu Archivo ya esta terminado.

10. Hacer click derecho en la barra principal de menus y seleccionar Insertar menu.Ası se crea un menu entre los menus Archivo y Ayuda. Escribir Edicion comonombre de este menu.

11. Pulsar Intro para descender hacia la siguiente entrada vacıa. No es necesariopulsar Insert aquı porque este menu no contiene ningun elemento despues de laentrada actual. Sugerencia: Para borrar una entrada, seleccionar y hacer clicken el boton Borrar de la barra de herramientas, o pulsar la tecla “Supr” dosveces. La primera vez que se pulsa la tecla Supr se borra el texto de la entrada.La segunda vez elimina la entrada del menu.

12. Proseguir con la construccion del menu Edicion tal y como se indica en la imagen6.14, anadiendo tres elementos: Fuente (JBuilder SE y Enterprise), Color detexto y Color de fondo. Si alguna entrada tiene una longitud superior al areade edicion, el texto se desplazara automaticamente a medida que se escriba.Cuando se pulse Intro, el disenador de menus ajustara el ancho del menu paramostrar el elemento mas largo de la lista.

Figura 6.14: Editor

13. Cerrar el disenador de menus con un doble clic en cualquier componente de laseccion de la interfaz de usuario del arbol de componentes. Esto hara que elpanel de contenido cambie al disenador de interfaces.



14. Guardar el archivo y ejecutar la aplicacion. Ahora la interfaz de usuario ofre-cera un aspecto similar al de la figura 6.14.

Paso 4: Anadir un cuadro de dialogo Selector de fuentes

Se comienza a enlazar los sucesos de menu, empezando con el elemento de menu Edi-cion->Fuente que es el que va a mostrar el cuadro de dialogo Selector de fuentes.

En primer lugar, para poder utilizar esta opcion de menu, se debe anadir uncomponente cuadro de dialogo Selector de fuentes a la clase TextEditFrame:

1. Abrir TextEditFrame.java en el disenador de interfaces.

2. Seleccionar la pestana Mas dbSwing de la paleta de componentes y hacer clicken el componente FontChooser.

3. Hacer click en cualquier lugar del arbol de componentes o en el disenador deinterfaces, para anadir el FontChooser al diseno. Esto situara el componentedentro de la clase como fontChooser1 y lo mostrara en la carpeta Otros delarbol de componentes.

Solo se ve el componente cuadro de dialogo en el arbol de componentes, no en eldisenador de interfaces.

Creacion de un suceso para el elemento de menu Edicion->Fuente, que lanzara elSelector de fuentes:

1. Seleccionar el elemento de menu Edicion->Fuente en el arbol de componentes.Deberıa ser jMenuItem5 (en el segundo nodo de menu, llamado jMenu1). Seobserva que la propiedad text para este elemento de menu del Inspector dice“Fuente”. No importa si su elemento de menu Fuente tiene un numero diferentea este. Pero asegurarse de seleccionar el correspondiente al menu Fuente.

2. Hacer click en la pestana sucesos en el Inspector, y hacer doble click en el cam-po de valor (la segunda columna) del suceso actionPerformed. En los menus,botones y otros muchos componentes de la interfaz de usuario de Java, action-Performed es el suceso principal de usuario, que deberıa capturar para respon-der al usuario cuando utiliza el menu o el boton. El nombre del metodo detratamiento de sucesos aparece en el campo de valor. Si el metodo no existetodavıa, esta operacion muestra el nombre propuesto por defecto para el nuevometodo de gestion del suceso. Para este nuevo manejador de sucesos, el nombrepropuesto es jMenuItem5 actionPerformed. Figura 6.15



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 stubvacıo para el metodo en el codigo fuente. Independientemente de si el metodoes nuevo o ya existe, el foco de ventana cambiara a codigo fuente en el editor ycolocara el cursor dentro del metodo de tratamiento de sucesos. En el caso deun metodo nuevo de tratamiento de sucesos, como es el caso, vera que la seccionprincipal del metodo no contiene todavıa codigo alguno.

4. Escribir esta lınea de codigo en el cuerpo de este nuevo metodo vacıo (entre lasllaves de apertura y cierre): fontChooser1.showDialog();

Ahora el metodo deberıa parecerse a este:

void jMenuItem5_actionPerformed(ActionEvent e) {

fontChooser1.showDialog();

}

5. Guardar y ejecutar la aplicacion. El elemento de menu Edicion->Fuente de-berıa abrir el cuadro de dialogo Selector de fuentes. Si no, compruebar que lapropiedad frame tiene el valor this. Aunque se intente cambiar la fuente, nosucedera nada. Esto se debe a que no se utiliza el resultado del FontChooserpara cambiar el texto del area de edicion. Esto sera lo siguiente que se haga.

6. Cerrar la aplicacion “EditorDeTexto”.



Paso 5: Vinculacion de sucesos de elemento de menu al cuadro de dialogoSelector de fuentes

Se va a utilizar el cuadro de dialogo Selector de fuentes para modificar la propiedadfont de textArea1.

1. Hacer click en la pestana Fuente y seleccionar el metodo de tratamiento del suce-so del elemento de menu Fuente (jMenuItem5_actionPerformed(ActionEvente))) recien creado.

Figura 6.16: jMenu

2. Introducir este codigo en el metodo de tratamiento de sucesos para el elemen-to de menu Fuente (jMenuItem5), entre las llaves de apertura y cierre, ase-gurandose de reemplazar el codigo antiguo fontChooser1.showDialog();:

// Gestiona el elemento de menu "Edicion 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());

// Obtiene la nueva fuente del Selector de fuentes

// Comprueba primero el valor devuelto por showDialog() para

// ver si el usuario pulso Aceptar.

if (fontChooser1.showDialog()) {

// Asigna a la fuente de jTextArea1 el valor

// seleccionado por el usuario antes de pulsar Aceptar

jTextArea1.setFont(fontChooser1.getSelectedFont());

}

//pinta el menu 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:


// Gestiona el elemento de menu "Edicion 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());

// Obtiene la nueva fuente del Selector de fuentes.

// Comprueba primero el valor devuelto por showDialog() para

// ver si el usuario pulso Aceptar.

if (fontChooser1.showDialog()) {

// Asigna a la fuente de jTextArea1 el valor

// seleccionado por el usuario antes de pulsar Aceptar

jTextArea1.setFont(fontChooser1.getSelectedFont());

}

//pinta el menu 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();

}

3. Guardar y ejecutar la aplicacion y escribir algo en el area de texto.

4. Seleccionar el texto y utilizar el elemento de menu Edicion->Fuente para cam-biar la fuente. En esta aplicacion, se cambia la fuente de la totalidad del area detexto (no solamente del texto seleccionado). No espere que la configuracion defuentes se mantenga. No introduciremos codigo para activar esa caracterıstica.


Paso 6: Vinculacion de sucesos de elementos de menu a JColorChooser

A continuacion se crean los sucesos de menu Edicion->Color de texto y Edicion->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 enel disenador, no es preciso anadirlo a la interfaz de usuario del disenador. Puede lla-marse directamente desde el manejador del suceso actionPerformed() de un elementode menu del siguiente modo:

1. Vuelva al disenador de TextEditFrame.java.

2. Seleccionar el segundo elemento de menu del arbol de componentes en Edicion(jMenuItem6) que tiene escrito “Color de texto” en la propiedad actionCom-mand.

3. Seleccionar la pestana Sucesos en el Inspector y haga click tres veces en el sucesoactionPerformed() para crear el manejador del suceso:

void jMenuItem6\verb’_’actionPerformed(ActionEvent e) {

}

4. Anadir el codigo siguiente en el stub del manejador del suceso:

//Gestiona el elemento de menu "Color de texto"

Color color = JColorChooser.showDialog(this,"Color de texto",

jTextArea1.getForeground());

if (color != null) {

jTextArea1.setForeground(color);

}

//pinta el menu de nuevo una vez que el elemento

//se ha seleccionado

this.repaint();



5. Volver al disenador.

6. Seleccionar el tercer elemento de menu en el arbol de componentes, en Edicion(menuItem7), que debe tener la etiqueta “Color de fondo” en la propiedadactionCommand. Crear un suceso actionPerformed() para el, tal como hizo conjMenuItem6

7. Insertar el siguiente codigo en el suceso actionPerformed() de jMenuItem7:

// Gestiona el elemento de menu "Color de fondo"

Color color = JColorChooser.showDialog(this,"Color de fondo",

jTextArea1.getBackground());

if (color != null) {

jTextArea1.setBackground(color);

}

//pinta el menu de nuevo una vez que el elemento

//se ha seleccionado

this.repaint();

8. Guardar el archivo, compilar y ejecutar la aplicacion. Escribir texto y hacerpruebas con los colores de primer plano y de fondo.


Paso 7: Adiccion de un manejador a un suceso de menu para borrar elarea de texto

Se va a capturar el elemento de menu Archivo->Nuevo con un manejador que borrael contenido del area de texto.

1. Vuelva al disenador.

2. Seleccionar el elemento de menu Archivo->Nuevo del arbol de componentes(jMenuItem1).

3. Crear un suceso actionPerformed() e introducir en el este codigo:

// Gestiona el elemento de menu 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 sucedeal seleccionar Archivo->Nuevo. Deberıa borrarse el contenido. Observar que nose 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 archivosde texto, para controlar si el archivo ha cambiado y necesita guardarse.




Paso 8: Anadir un cuadro de dialogo selector de archivos

Se va a enlazar el elemento de menu Archivo->Abrir con un manejador de un sucesoque presenta al usuario un JFileChooser (cuadro de dialogo para abrir archivos) paraarchivos de texto. Cuando el usuario selecciona un archivo y hace click en Aceptarel manejador del suceso abre el archivo de texto y coloca su contenido dentro deJTextArea.

1. Volver al disenador y seleccionar el componente JFileChooser de la ficha SwingContainers de la paleta de componentes.

2. Hacer click en la carpeta IU del arbol de componentes para colocar el compo-nente.

3. Seleccionar el elemento de menu Archivo->Abrir en el arbol de componentes(jMenuItem2).

4. Crear un suceso actionPerformed() e introducir este codigo:

//Gestionar el elemento de menu Archivo|Abrir.

//Utilizar la version OPEN del cuadro de dialogo, 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 codigo debe ir aquı para cargar realmente el texto

// en el TextArea.

}

5. Salvar y ejecutar la aplicacion. En el menu Archivo->Abrir, seleccionar un archi-vo y pulsar aceptar. Debe aparecer el nombre del archivo y el directorio completoen la lınea de estado en la parte inferior de la ventana. Sin embargo, el area detexto seguira vacıa.

6. Cerrar la aplicacion “EditorDeTexto” antes de continuar.



Paso 9: Anadir codigo para leer texto de un archivo

Se va a anadir codigo para leer el texto del archivo seleccionado por el usuario yponerlo en el JTextArea.

En primer lugar, hay que anadir un nuevo metodo a la clase para realizar laoperacion de apertura del archivo. Este metodo se llamara openFile().

1. Cambiar el editor a TextEditFrame.java e introducir el siguiente metodo open-File(). 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() yjusto 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 codigo de

//caracteres internacionales.

FileReader in = new FileReader(file);

// Crea una matriz de caracteres del tama~no del archivo,

// para utilizarla como bufer de datos, en el que leer

// los datos del texto.

char[] data = new char[size];

// Leer todos los caracteres disponibles en el bufer.

while(in.ready()) {

// Incrementar el recuento de cada caracter leıdo,

// y acumularlos en el bufer de datos.



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. Anadir la importacion siguiente a la lista de importaciones de la parte superiordel archivo:import java.io.*;

3. Hacer click en el manejador del suceso de Archivo->Abrir (jMenuItem2_ action-Performed(ActionEvent)) del panel de estructura para buscarlo rapidamente enel codigo fuente.

4. Reemplazar el codigo fuente en el manejador del suceso de Archivo->Abrir if()que contenıa previamente:



statusBar.setText("Abierto "+jFileChooser1.getSelectedFile().

getPath());

// El codigo debe ir aquı para cargar realmente el texto

// desde el archivo al JTextArea.

con este nuevo metodo openFile(), empleando el nombre de directorio y archivoconcatenados.

// Llamar a openFile para intentar cargar el texto desde el

//archivo al JTextArea

openFile(jFileChooser1.getSelectedFile().getPath());

//pinta el menu de nuevo una vez que el elemento se ha

//seleccionado

this.repaint();



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 alguncontenido.


Paso 10: Adiccion de codigo a los elementos de menu para guardar unarchivo

Ahora se precisa un codigo que vuelva a grabar el archivo a disco cuando seseleccione Archivo->Guardar y Archivo->Guardar como. . .

Para ello, es necesario anadir una variable de instancia String para almacenar elnombre del archivo abierto, ademas de anadir metodos para escribir de nuevo el textoen este y en otros archivos.

1. Hacer click en jFileChooser1 en el panel de estructura. Esto llevara a la ulti-ma entrada de la lista de declaraciones de variables de instancia (dado quejFileChooser1 fue la ultima declaracion realizada).

2. Anadir 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 estructurapara buscarlo rapidamente en el codigo fuente. Situar el cursor en el metodo, acontinuacion de la lınea 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 cache el nombre de archivo abierto

//actualmente para utilizarlo al guardar...

this.currFileName = fileName;

// ...y marcar la sesion de modificacion como borrada

this.dirty = false;

5. Crear un metodo saveFile() al que se pueda llamar desde el manejador del sucesode Archivo->Guardar. Puede ser colocado justo despues del metodo openFile().Este metodo escribe el nombre de archivo en la barra de estado al guardar.



// Guardar archivo actual; gestionar los que no tienen

//nombre de archivo; informar a la barra de estado.

boolean saveFile() {

//Gestionar donde aun 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 escribira ese archivo.

// FileWriter gestiona las conversiones de codigos 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 nom-bre de archivo actual. Se utilizara tambien desde el menu Archivo->Guardarcomo. . . . Anadir 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 version SAVE del cuadro de dialogo,

//comprobar el valor devuelto de Aceptar/Cancelar




showSaveDialog(this)) {

// Asignar al nombre de archivo actual la seleccion

//del usuario

// a continuacion realizar un saveFile normal

currFileName = jFileChooser1.getSelectedFile().getPath();

//pinta el menu de nuevo una vez que el elemento se ha

//seleccionado

this.repaint();

return saveFile();

}

else {

this.repaint();

return false;

}

}

7. Volver al disenador y crear un manejador del suceso actionPerformed() para elelemento de menu Archivo->Guardar (jMenuItem3). Insertar el siguiente codigo:

//Gestionar el elemento de menu Archivo|Guardar.

saveFile();

8. Crear un manejador de sucesos actionPerformed() para el elemento de menu Archivo->Guardar como. . . (jMenuItem4) e introducir este codigo:

//Gestionar el elemento de menu Archivo|Guardar como.

saveAsFile();

9. Guardar y compilar el archivo. Ejecutarlo e intentar guardar texto en un archivo.


Paso 11: Adiccion de codigo 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 antescerrar el archivo o salir del programa. Para ello, se anadira una variable de tipobooleano denominada dirty.

1. Hacer click en el siguiente metodo del manejador del suceso de Archivo->Nuevoen el panel de estructura: jMenuItem1_actionPerformed(ActionEvent e)



2. Anadir el codigo siguiente al final de este metodo para borrar el contenido delas variables dirty y currFileName. Colocarlo inmediatamente detras de la lıneajTextArea1.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 uncuadro de mensaje de confirmacion para constatar si el usuario desea guardar unarchivo modificado antes de cerrarlo cuando selecciona Archivo->Abrir, Archivo->Nuevo o Archivo->Salir. Este cuadro de dialogo se abre con una llamada aun metodo de clase en JOptionPane, por lo que no es necesario anadir uncomponente JOptionPane al programa.

3. Anadir el metodo okToAbandon() siguiente al codigo fuente. Puede situar estemetodo justo a continuacion del metodo saveAsFile():

// Comprobar si el archivo se ha modificado.

// Si es ası obtener del usuario una decision ">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 losmanejadores de los sucesos de Archivo->Nuevo y Archivo->Abrir, ası como enel manejador del suceso de Archivo->Salir generado por el asistente. En cada



caso, compruebe el valor que devuelve okToAbandon() y realice solamente laoperacion 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 principaldel metodo en un nuevo if, de manera que ese codigo se ejecute solamentesi okToAbandon() devuelve “true”. El metodo modificado debe tener elsiguiente aspecto:


// Gestiona el elemento de menu 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:


// Gestiona el elemento de menu Archivo|Abrir.


return;

}

//Utiliza la version OPEN del cuadro de dialogo,

// 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 lınea de codigo que sale de la aplicacion. El metodo modificadodebe tener el siguiente aspecto:

//Realizar Archivo | Salir

public void jMenuFileExit_actionPerformed(ActionEvent e) {




System.exit(0);

}

}

Ahora, estos metodos de tratamiento de los sucesos de menu realizan sufuncion 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 (graphicaluser interface) que es nuestro punto basico para construir nuestra aplicacion DICOM.

6.5. Instalacion de JDT

Estas son las librerıas de Java utilizadas que implementan funciones del estandarDICOM. Es necesario hacer una instalacion manual como la realizada con las JDK.Tambien al realizar el programa se han utilizado las librerıas JDT que se distribuyende forma gratuita por lo que tienen un perıodo de validez, este perıodo se acaba el22 de Abril del 2003, pues bien para poder utilizarlas, lo que hacemos es retrasar elreloj del ordenador hasta el 22 Abril del 2002 y ası tenemos un ano completo parapoder utilizar las librerıas.

Para realizar la instalacion es comun en todos los sistemas operativos el crear unacarpeta que se llame como se quiera, en nuestro caso se llama “classpath”. En estacarpeta hay que guardar los archivos enviados por softlink que son jdt.jar y jdt.key.La pagina para hacer la peticion de las librerıas es www.softlink.be.

En nuestro caso hemos creado una carpeta llamada classpath en el disco D:\, porlo que hay que copiar los archivos jdt.jar y jdt.key en D:\classpath.

6.5.1. Instalacion en Windows 95/98

Para la instalacion de las librerıas JDT en este sistema operativo, hay que abrir elarchivo “autoexe.bat” que se encuentra en C:\ con un editor de texto (click derechosobre el archivo mientras se deja pulsado “Shift”, y elegimos el Bloc de Notas). En lavariable classpath creada anteriormente cuando instalamos las librerıas JDK, hay queescribir el path o camino para llegar a los archivos de las librerıas JDT. En nuestrocaso es:


http://www.softlink.be/jdttrial.htm

Fernando Ballesteros Herranz 6.5. INSTALACION DE JDT

D:\classpath\jdt.key;D:\classpath\jdt.jar;

Una vez realizado esto, hay que hacer una copia del archivo “jdt.key” en losdirectorios donde haya archivos fuente que utilicen estas librerıas. Por ejemplo sitenemos en la carpeta C:\java un archivo fuente main.java que utilice estas librerıas,hay que poner en la carpeta al archivo “jdt.key”.

6.5.2. Instalacion en Windows NT/2000/XP

Para la instalacion de JDT, hay que entrar en las variables de entorno. Para llegara las variables de entorno ir a Inicio->Configuracion->Panel de Control->Sistema->Avanzado->Variables de entorno. . . y en variables del sistema pinchar en la variableclasspath creada anteriormente, ahı anadir:

D:\classpath\jdt.key;D:\classpath\jdt.jar;

Una vez realizado esto, hay que hacer una copia del archivo “jdt.key” en losdirectorios donde haya archivos fuente que utilicen estas librerıas. Por ejemplo sitenemos en la carpeta C:\java un archivo fuente main.java que utilice estas librerıas,hay que poner en la carpeta al archivo “jdt.key”.

6.5.3. Incluir JDT en JBuilder

Una vez instaladas las librerıas ahora hay que incluir las librerıas en el proyectoque se este realizando una aplicacion DICOM. Este proceso es el mismo para cualquiertipo de librerıas 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 estana de Vıas de acceso y dentro de esta en la pestana de Bibliotecasnecesarias, se pulsa Anadir. . . y seguidamente Nuevo. . . . Mediante el asistentede bibliotecas se anaden las de JDT:

Nombre: JDT

Ubicacion: Directorio Inicial

Pulsar Anadir. . .

Selecionar el camino hasta las librerıas JDT que en nuestro caso son:



Figura 6.17: Bibliotecas

• D:\classpath\jdt.jar

• D:\classpath\jdt.key

• D:\classpath\

Aceptar

4. Asegurarse que las bibliotecas se han anadido bien entrando en Herramientas->Configurar bibliotecas. . .

Figura 6.18: Configurar bibliotecas

5. Hecho esto ahora podemos anadir las clases de estas bibliotecas a nuestro codigofuente sin que de error. Por ejemplo:

import com.archimed.dicom.*;


Fernando Ballesteros Herranz 6.6. IMPLEMENTACION DE SERVIDOR DICOM

Con esto podemos declarar nuevos objetos de las clases de JDT, por ejemplo:

DicomObject CT = new DicomObject();

Las librerıas instaladas ya son utilizables en el proyecto y se puede trabajar conellas.

6.6. Implementacion de Servidor DICOM

6.6.1. Introduccion

La aplicacion Servidor DICOM implementa todas las funciones DICOM que puederealizar un servidor con las librerıas JDT. Se ha realizado un programa multiplatafor-ma que estara en ejecucion indefinidamente y que el mismo es capaz de administrarsesin mantenimiento exterior.

El programa se ha elaborado con Java usando el TextPad como compilador conel soporte las librerıas SDK 1.4.1 y JDT de DICOM.

El servidor realizado da multiples elementos servicio a los clientes como son C-STORE, C-MOVE, C-FIND, C-GET y C-CANCEL. Con estos elementos de serviciose ha podido implementar las funciones query, guardar, enviar, editar y listar una losarchivos Dicom que se encuentran en el servidor. Todos estos servicios de red estancodificados mediante algoritmos DES5 de encriptacion.

El servidor DICOM realizado es multiusuario (multihilo), lo que quiere decir quesi 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 adiferentes clientes a la vez.

El servidor va dando informes sobre lo que se va desrrollando e informacion acercade 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 lasfunciones es el que se eralice una asociacion entre cliente y servidor y esten deacuerdoen la informacion que van a compartir.

5Digital Encription Standard



6.6.2. Listar

EL servidor a peticion del cliente, realiza una lista de los archivos Dicom contenidosen la base de datos. Esta lista es enviada y codificada por el servidor a los clientesque 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();



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 luegosabiendo este numero se van listando. Tambien es importante saber cuantas imagenestiene 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 basede datos.

6.6.3. Enviar

Esta funcion es muy inportante ya que es la base de la transmision de los objetosDicom. El servidor envıa al cliente el archivo pedido. Esta funcion suele realizarsedespues 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 envıa.

Figura 6.20: El servidor envıa objeto Dicom

La implementacion es muy extensa pero la base es:

.......



fin.close();

.......

as.send(SOPClass.CTImageStorage,cstorerequest,scimage);

.......



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 serealiza con las funciones de JDT que tienen en cuenta que lo que se debe almacenardebe tener la estructura definida por el estandar). Despues la instancia es enviadamediante el metodo send() de un objeto de la clase Association incluida en el JDT.

6.6.4. Guardar

Cuando el cliente envıa archivos Dicom al servidor, este debe saber administrarla forma de guardarlo sabiendo que nombre debe dar al archivo recibido y donde seproducira su almacenaje.

Figura 6.21: El servidor recibe objeto Dicom

El codigo fuente es muy extenso pero para entender la forma de realizarse estafuncion 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 Di-comObject() que sera quien reciba los datos que se estan recibiendo del cliente vıanetwork. Estos datos son los data sets con los valores correspondientes del archivoDicom. El objeto Dicom recibe los datos mediante el metodo receiveData() de la clase



Association y luego los guarda para no perderlos y ası crear un nuevo archivo Dicomen la base de datos del servidor. Esto se realiza con im.write(fin,true), siendo fin elobjeto 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 alma-cenados en la base de datos. Esta funcion es muy importante y util para saber quearchivos queremos ya que nos da la informacion del estudio realizado.

La informacion que da el servidor de nuestra apliacion es:

Fecha del estudio: Dıa-Mes-Ano

Nombre del paciente

Edad

Sexo

Numero de celulas y de virus

Numero de imagenes que tiene cada archivo

Esta informacion es de suma importancia para tener conocimiento del estudio quequeremos 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);



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 informaciony se crea un objeto Dicom para leer la informacion del archivo que tiene formato Dicomsegun el estandar. Una vez leido el archivo Dicom, se leen las partes que nos interesandel objeto Dicom y son enviadas al cliente.

6.6.6. Editar

Esta funcion permite modificar los archivos Dicom del servidor sin necesidad elcliente de tener que traerse todo el archivo Dicom. Es muy util para modificar losestudios de los pacientes o poner notas que los medicos creen convenientes, de unaforma rapida y sencilla.

Los datos que se pueden modificar en nuestra aplicacion son:


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);





.......

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 quedesee 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 metodowrite().

6.6.7. Encriptacion/Desencriptacion

La encriptacion realizada en la aplicacion tanto de servidor como de cliente esta basa-da en los algoritmos DES.

En la criptografıa tradicional, (tambien llamada criptografıa de “clave secreta”)tanto el emisor como el receptor poseen una misma clave o password. El emisor utilizaesta 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 mensajey obtener ası el mensaje original. Si esta clave es conocida unicamente por emisory receptor, se asegura que el mensaje recibido es el original y que es enviado por launica persona (ademas del receptor), que tiene la clave.

La criptografıa realizada en esta aplicacion solo se ha realizado en la informaciono partes de informacion de los objetos Dicom y en los elementos de servicio que sedeseaban realizar. No se ha aplicado en la transmision de archivos Dicom enteros yaque las librerıas JDT no lo soportan.

La implementacion del algoritmo es de caracterısticas faciles:

.......

byte caracterEncriptacion=’n’;



String cadenaEncriptada="";

int caracterEncriptado=0;

String cadenaDesencriptada="";

String encriptar(String cadenaEncriptar)

{

// Encriptacion segun 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)

{

// Desencriptacion segun 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. Implementacion de Cliente DICOM

6.7.1. Introduccion

Esta aplicacion sigue todos los pasos del estandar DICOM en la implementacion delas funciones. Se ha querido realizar un programa multiplataforma y que este deacuer-do con las especificaciones requeridas.

Este programa ha sido elaborado en Java en el entorno JBuilder con soporte de


Fernando Ballesteros Herranz 6.7. IMPLEMENTACION DE CLIENTE DICOM

librerıas SDK 1.4.1 y JDT de DICOM.

La aplicacion tiene varias partes. Lo primero, y a traves de los componentes dejavax.swing es construir un marco que concuerde con las expectativas. En nuestro casose ha dispuesto varias pestanas que albergan paneles mediante las clases JTabbedPaney 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 hadispuesto de los paneles que aparecen en la figura: panelCliente-Servidor, panelProce-samiento, panelVisorDicom y panelCrearDicom.

Vamos a ver para que sirven cada uno de estos paneles y una pequena muestra decomo 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 sepuede solicitar al servidor una lista de los archivos que tenga en la base de datos,



se puede coger cualquier archivo de esa base de datos, se pueden enviar archivos ala base de datos, se pueden modificar estos archivos desde el cliente y se puede verpartes de la informacion que contienen estos archivos Dicom que estan en la base dedaros del servidor. Ver figura 6.22

Antes de realizar cualquier accion en este panel, se debe escribir el nombre delservidor del que queremos tener estos servicios.

Base de Datos

Mediante el boton Base De Datos, se hace una peticion al servidor de los archivosque contenga. Estos archivos contenidos en la base de datos del servidor, se muestranen el cliente en un arbol, en el que se ve tambien por cuantas imagenes esta compuestoel archivo. Ver figura 3.2.

Para que el funcionamiento de este boton sea correcto, hay que poner el nombredel 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 nosdira “Haz click en Dicom”, entonces hay que hacer click en la palabra Dicom queesta 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);

}

});



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 actuarcon sus eventos, pedimos una lista al servidor sobre su base de datos y creamos unarbol 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 basede 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 quequeremos conectar en el JTextArea que hemos creado para ello. Este boon cogera conque servidor queremos conectarnos y nos abrira un browser para buscar el archivoque queremos enviar.



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 nece-sarios para enviar el archivo mas tarde mediante el metodo store() de la clase Stor-agescu.

Coger

Este boton ha sido implementado para poder hacer peticiones al servidor de queenvıe al cliente el archivo marcado en el arbol. El archivo enviado por el servidor seguardara en el cliente y podra ser visualizado en el panel Visor Dicom. Ver figura6.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();



Coge el nombre del servidor al que esta conectado y el nombre del archivo que sequiere traer, luego se crea un objeto de la clase Storagescu que es la encargada deestablecer la asociacion con el servidor. Este objeto llama a la funcion coger() quela que hace el elemento de servicio necesario para traer el archivo especificado delservidor.

Editar

Su funcion es modificar los datos de los archivos que estan en el servidor sintener que traernos el objeto entero. Cada vez que se pinche sobre un archivo se traela informacion necesaria no todo el archivo. La informacion que se trae y se puedemodificar es:


Nombre del paciente

Edad

Sexo

Para modificar estos datos hay que escribir en los espacios JTextField (ver figura6.25) dispuestos para ver y para escribir en ellos. Para que las modificaciones seconserven, hay que escribir los datos que se quieran en los campos y darle al botonEditar, 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();



Figura 6.25: Boton Editar

Donde se cogen mediante el metodo getText() los datos modificados y luego secrea un objeto de la clase Storagescu con un constructor en el que se le pasan todoslos datos. Finalmente se utiliza el metodo poner() de la clase Storagescu que ha sidocreada por nosotros.

6.7.3. Panel VisorDicom

Este panel sirve para poder visualizar todo tipo de archivos DICOM: archivoscomprimidos, 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



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 Imagedosen el proyecto de JBuilder, la cual nos va a permitir en ultima instancia ser capacesde 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) alcual 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 (for-mato 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 nues-tra clase principal MarcoCuatro.java en el metodo open():



.......

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 lınea de codigo conseguimos que se abra un selector dearchivos, donde elegimos el archivo DICOM deseado. Con la lınea it openFileName= jFileChooser1.getSelectedFile().getAbsolutePath(); conseguimos guardar el caminocompleto del archivo, el cual necesitamos para crear un objeto de la clase File, depuesuno de la clase FileInputStream y finalmente uno de la clase BufferedInputStream parapoder usar el metodo read de la clase DicomObject, el cual lee desde el BufferedIn-putStream el archivo DICOM.

De esta forma tenemos en “dcm” (DicomImage dcm = new DicomImage();) nue-stro 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 mostrarestos datos en un objeto de la clase JTextArea, que es lo que nos interesa para podervisualizar estos datos en nuestro GUI (en este caso en la instancia areaTextoDatos-Dicom de JTextArea).

El paso siguiente es coger los datos reunidos en este objecto. Para ello necesitamosla clase Imagedos. Llamamos a su constructor public Imagedos(DicomObject dcm) conlo que tenemos un objeto de esta clase:

imagedcm = new Imagedos(dcm);

Mediante el metodo getBufferedImage(int numeroDeImagen) podemos sacar lasimagenes y poderlas visualizar de esta forma:



imagen = imagedcm.getBufferedImage(numeroImagen);

etiquetaMostrarImagen.setIcon(new ImageIcon(imagen));

Donde etiquetaMostrarImagen es un objeto de la clase JLabel la cual mediante elmetodo setIcon(ImageIcon a) puede mostrar nuestras imagenes. La instancia de laclase 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 dedos 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 alturay anchura de la imagen zoomImagen. Y mediante el metodo getScaledInstancehacemos una imagen a escala de la anterior, para lo que necesitamos nuevosdatos de alto/ancho, que despues con el metodo antes visto setIcon podemosvisualizamos en el mismo objeto JLabel, etiquetaMostrarImagen.

2. Mediante eventos de raton:

En este caso se ha conseguido que mediante dos cliqueos con el raton sobrela imagen se haga “zoom in” de la zona selecionada. Se hace, creando para la



Figura 6.28: Zoom con eventos

JLabel deseada (etiquetaMostrarImagen), un codigo que sea capaz de recogerun 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);



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 laposicion del raton en el momento que este es pulsado, por lo que podemos sacarla zona de interes (mediante los metodos getX() y getY() ) y donde MarcoPantallaCompleta es una clase que permite visualizar imagenes en un panelaparte.

Tambien, si se quisiese detectar, por ejemplo el movimiento del raton sobre uncomponente o el rotar de la rueda central del raton se pueden usar clases delmismo paquete MouseAdapter, MouseEvent, MouseMotionAdapter o/y Mouse-WheelEvent para tener efectos homologos a lo anteriormente visto.



Visualizar todas las imagenes

Ya se ha comentado la forma de conseguir visualizar los datos de la imagen de losarchivos DICOM, pero tambien sabemos que un archivo DICOM puede contener masde una imagen, por lo que debemos ser capaces de visualizarlas todas y cada una deellas.

Figura 6.29: Botones Siguiente y Anterior

Al abrir un archivo DICOM se muestra en pantalla (en una instancia de la claseJLabel) la primera imagen y en el caso de que haya mas de una imagen en dichoarchivo, 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 anteriorcomo indica su nombre. La implementacion es muy sencilla. Primero, se vesi hay mas de una imagen mediante la captura del dato del objeto DICOMdcm.getI(DDict.dNumberOfFrames) y si existe, se muestra en pantalla. Ver figu-ra 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 imagende numero seleccionada mediante el int numeroImagen.



Figura 6.30: Boton Seguidas

2. Boton Seguidas:

Se basa en lo anterior, pero se consigue que las imagenes pasen una detras deotra (formando una pelıcula). La pelıcula se para si se pulsa con el raton sobreel 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 Imagesy mas tarde se crea una instancia de la clase ImageSequenceTimer con la cualse crea el panel donde se va a visualizar la secuencia.



Figura 6.31: Boton Guardar JPEG

Guardar imagenes como JPEG

Se puede guardar la imagen visualizada en formato JPG mediante las posibilidadesde JDK 1.4.1. Esta funcion solo se encuentra en esta version del API JAVA, por loque 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 clasejavax.imageio.ImageIO que nos permite guardar los datos de una instancia de laclase 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);

}

.....

.....

}



Donde la lınea 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 detexto, es decir el nombre del paciente, que aparato ha realizado la captura de la ima-gen. . . . La funcion, que se ha hecho para esta GUI y para este panel, es la capacidadde poder anadir datos de texto al archivo visualizado.

Esto se puede hacer de dos formas diferentes. Se puede insertar datos en camposya existentes, como el nombre del paciente, o se puede crear nuestro propio campocomo por ejemplo numero de moleculas infectadas.

Del primer tipo se han dispuesto una serie de campos, los cuales pueden ser validoso no. En este aspecto deben ser los profesionales de la medicina los que deben sum-inistar informacion para saber los datos que quieren insertar para poder adaptarnosa 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 podremosvisualizar si estas modificaciones se llegan a producir.

Para esto se han dispuesto dos instancias de la clases JComboBox, dos botonesde la clase JButton para insertar y para ver lo insertado y de dos objetos JTextAreasiendo 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 JComboBoxcon los campos adecuados:

private JComboBox jComboBox1



= 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 cam-pos. Ahora hay que interconectarlos para que al seleccionar uno y escribir sobre lasJTextArea 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 elcampo del archivo DICOM DDict.dPatientName.

Hecho esto, el dato estarıa en el objeto DicomImage pero no todavıa en elarchivo .dcm, para lo que se implementa estas otras lıneas 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 atraves de un FileOutputStream todos los datos de la instancia DicomImage enun archivo .dcm que, si no existe, crea uno.

Para ver lo insertado:



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 abrirel archivo DICOM y se podra observar que el nombre del paciente ha cambiadoo aparece cosa que antes no harıa. La figura ?? siguiente pretende ser un ejemplode lo descrito.

Como anadir campos nuevos al archivo DICOM

Existe la posibilidad de crear nosotrosmismos nuestros propios campos, para uti-lizar segun 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 muyimportante ser capaces de crear nuestros propios campos, como por ejemplo el numerode 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 capaceshacer este servicio.

Figura 6.33: Crear campos nuevos



Se tiene la posibilidad de crear campos donde se albergan datos de tipo Integer odatos de tipo String, es decir, campos para datos numericos y campos para datos detexto.

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 pasarlos parametros fijamos el numero de grupo, el numero de elemento, la descripcion delcampo 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 ainsertar nuestro nuevo campo por medio del metodo addEntry(DDictEntry a).

En este momento tenemos la posibilidad de poder meter en el objeto de la claseDicomObject (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 enJava. Ver tablas de conversion 5.1 y 5.2.

Para el caso de insertar un campo que alberge un dato de tipo String se haprocedido de la misma forma:

void jButton5 actionPerformed(ActionEvent e)

{

.......

DDictEntry entrarDDict2 = new DDictEntry(new Integer(

campoGrupoTexto.getText()) .intValue(), new Integer (



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 unico que cambia es el tipo de dato que vamos a insertar, por lo que eltercer 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 desar-rollado por el GVA. Este panel visualiza la imagen de origen a procesar y ejecuta el



algoritmo de procesamiento y cuando acaba este se visualiza en el panel de imagenprocesada (a la derecha).

Figura 6.35: Panel Procesamiento

Esta panel funciona si esta instalado previamente el MATLAB, el programa uti-lizado para el tratamiento de las imagenes.

Introduccion del algoritmo en la aplicacion

Pasos a seguir:

1. Lo primero que se debe hacer es poner en las variables de entorno los caminospara encontrar las librerıas necesarias:

C:/AWouter/bin/win32; C:/AWouter; C:/matlab6p5/bin/win32;

Esto significa que antes se ha debido copiar en estas carpetas los archivos solic-itados.

En la carpeta C:/AWouter se deben copiar los archivos applylut.dll y dataread.dll.



2. Despues se debe ejecutar el setup mglinstaller.exe que instala las librerıas nece-sarias 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 librerıas para soloeste algoritmo:

C:/matlab6p5/toolbox/images/images/private y se incluyen en esta bwlabel1.dlly bwlabel2.dll.

Si hubiera algun 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 implementacionpara que este algoritmo se pueda ejecutar desde nuestro GUI (graphical user inter-face). Para hacer esto se dan estos pasos:

En el panel de procesamiento se han creado dos JLabel donde poner las imagenesde origen y la de salida o procesada. Se ha incluido ademas un JTextArea para decir elcamino y el nombre de la imagen procesada y dos botones, uno para abrir la imagena 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 botonque 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);



Figura 6.36: Boton para anadir 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 caminode entrada y de salida en el fichero files.txt de donde despues con el botonque 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);

.....



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 deimagenes 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 VisorDicom”.

La parte nueva con respecto al panel de visualizacion de archivos DICOM es lazona de meter los datos de imagenes nuestras en formato jpeg dentro del nuevo archivoDICOM.

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

Insercion de una sola imagen

En esta parte vamos a ver la forma de como insertar los datos de una sola imagen.



Figura 6.39: Panel Crear DICOM

Lo primero que se hace es visualizar la imagen a insertar en el area destinadamediante el boton Abrir imagen y despues mediante los botones Monochrome o RGBmetemos la imagen segun 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");



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 escapaz de coger los datos de la imagen pixel a pixel, por lo que el resultado esun array de int donde se encuentran estos datos.

Las dos lıneas siguientes se colocan debido a que son datos que se deben en-contrar obligatoriamente en un archivo DICOM, ya que sin ellos no es posiblecrear el archivo.

Mas tarde, en nuestra instancia de la clase DicomImage (DicomImage dcm-Nueva = new DicomImage();) se insertan estos datos de imagen mediante elmetodo de esta clase imagePixelData(int filas, int columnas, int planarConf,int[] pixelData).

Una vez hecho esto se puede comprobar que los resultados son satisfactorios alir al panel VisorDicom y tratar de abrir el archivo creado, donde s3e puedenver los resultados. Figura 6.42



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 diferenciaes que se usa otra implemtentacion del metodo imagePixelData ya que es unmetodo sobrecargado y se utiliza debido al cambio de parametros que se pasana 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.

Compresion de archivos Dicom Monochrome

Se ha visto como crear un archivo DICOM de escala de grises, pero al hacer estose tiene un problema: el tamano de los archivos es muy grande debido a que no se ha



Figura 6.42: Comprobacion de la creacion de archivo Dicom en escala de grises

realizado ningun tipo de compresion a los datos de pıxel, por lo que el espacio queocupan es bastante grande.

Para ello se ha recurrido a la clase de la API de JDT llamada Compression, lacual proporcina metodos para realizar compresiones de estos datos.

Para realizar la compresion se actua 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 metodocompress, el cual necesita saber el tipo de compresion a usar. En este momento se



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

tiene que decir que el unico tipo de compresion que realiza este servicio es el senaladoarriba, TransferSyntax.JPEGLossless, mientras que con los otros tipos no se consiguelo buscado con la limitacion de que funciona solo con imagenes monochrome.

La diferencia de tamano de un archivo comprimido a uno sin comprimir es:

No comprimido: tamano = X

Comprimido: tamano = X / 2

Insercion de varias imagenes

Para este caso se ha introducido en un array de Image todas las imagenes que sequieren insertar en el archivo DICOM.

Una vez insertadas, se procede a sacar los datos de pıxel de estas instancias Image.En este caso se van a guardar estos datos en una matriz de bytes en vez de array int.



Teniendo la matriz de bytes (byte[][]), se continua uniendo todos estos bytes enun 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 funcionesvistas antes:

1. Boton No de imagenes: donde se senala el numero de imagenes que vamos ainsertar. En el codigo se da valor a una variable que es utilizada para saber elnumero 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 enel array las imagenes, hasta que se almacena la ultima, y es en este momentocuando aparece un nuevo cuadro que te pregunta por el lugar y el nombre dondeinsertar 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,



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 elarray, se pasa a sacar de cada objeto Image sus datos de pıxel y se reunen enuna matriz de bytes llamada arrayDeArrayDeBytes.

Una vez hecho esto, se unen esos array de bytes en uno solo mediante el metodounirBytesArray(byte[][] secuencia, int numeroDeImagenes), el cual es el dato ainsertar en nuestro archivo DICOM, donde se recogen todas nuestras imagenes.

Comprimir archivo DICOM de varias imagenes monochrome

Este archivo esta sin compresion. Se puede realizar una compresion como la indi-cada antes y la reduccion de tamano es de la relacion 2 a 1 aproximadamente, es decirel tamano del archivo comprimido es la segunda parte del archivo sin comprimir.

El unico sistema de compresion soportado sigue siendo JPEGLossless de estaslibrerıas y mas particularmente de la clase Compression.



Figura 6.44: Generacion de ejecutables

6.7.6. Distribucion e instalacion de la aplicacion

Generacion de ejecutables

Una vez creada la version Beta de nuestra aplicacion Cliente DICOM es importantepoder distribuirla para que sea ejecutada sobre cualquier sistema operativo, siendode esta manera una aplicacion multiplataforma.

Figura 6.45: Creador de ejecutables

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



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 sistemaoperativo en el que se vaya a utilizar.

7. Pulsar Finalizar

8. Una vez realizado esto, se generara en el panel de proyectos un archivo quese llama igual a como habıamos 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, paraLinux, 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 ejecutarcuando se quiera poner el funcionamiento el .class, ya que el servidor se debe ponersolo una vez en funcionamiento y no hace falta ningun tipo de administracion.

Para crear el .jar de una aplicion no basada en GUI se hace de la forma descritaen el apartado de Utilidades de SDK, utilizando la utilidad jar.



Instalacion

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 raız, es decir, parasistema Windows es C:\. En esta carpeta es donde llegaran los estudios DICOMque 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 ano 2002, si se utiliza la version de pruebaBeta.

Para poner el programa, tan solo hay que ejecutar el programa cliente, en nuestrocaso CuatroW.exe

Para la instalacion del servidor DICOM:

1. Instalacion del SDK entero.

2. Instalacion de librerıas JDT.

3. Creacion de carpeta que se llame “BaseDeDatos” en la raız, es decir, parasistema Windows es C:\. Esta carpeta es donde se deben encontrar los estudiosde la base de datos del servidor.

4. Retrasar el reloj del ordenador al ano 2002, si se utiliza la version de pruebaBeta.

5. Poner los .class que en este caso son Storagescp.class, Storagescu.class, Connec-tion.class y Encri.class en la raız que en Windows es C:\.

Para poner el servidor en funcionamiento, abrir un Shell de comandos, y ejecutaren C:\:

java Storagescp

De esta forma saldra un mensaje que pone “Puerto 104 a la escucha”.



6.8. Conclusiones

El programa realizado es una muestra clara de que el estandar DICOM es operativoy muy util a la hora de la administracion de estudios medicos desde diferentes puntosa grandes distancias.

Esta aplicacion es una version beta de un posible programa mucho mas avanzadoque de soporte a mas funciones del estandar DICOM. Ha sido desarrollado en Javapor lo cual hace que sea un sistema multiplataforma y mas eficiente.

Cierto es que utilizando las librerıas JDT se han detectado limitaciones no respectoa lo establecido en el estandar sino con la encriptacion de los datos de los pacientespor la red.

A pesar de ello, se trata de una tecnologıa que esta madurando con mucha rapidez,estabilidad y fiabilidad. Cabe esperar que en los proximos anos DICOM vaya a sercada vez mas utlilizado en el ambito de la medicina y la investigacion.

El unico inconveniente de esta aplicacion es que es una version beta, y por ella solano funciona, debe ser retrasado el reloj de la maquina sobre la que estemos trabajandoal ano 2002, para ası tener un ano de utilidad este programa. Si se quieren mas anostan solo habrıa que retrasar el reloj mas tiempo atras.


Apendice A

Administracion de sistemas

[GUNT] [LEBLA] [RUSSE97] [STIN]

En este apendice se recopilan los aspectos mas importantes en el amplio mundode Windows NT 4.0 y Windows 2000 para que cualquier persona con un mınimo deconocimientos en informatica sea capaz de manejar esta plataforma.

A.1. Introduccion a Windows NT y 2000

A.1.1. Presentacion del sistema operativo NT

Tanto el sistema operativo Windows NT 4.0 como el sistema operativo Windows2000, tienen semejanza en su forma interna, ya que el Kernel es muy semejante. Cadavez que se refiera a sistemas operativos NT, se incluyen Windows NT 4.0 y Windows2000.

El sistema operativo NT fue desarrollado por Microsoft para superar los obstaculosimpuestos por la vieja arquitectura de sus sistemas operativos MSDOS y Windows.NT es un sistema operativo completo, que puede ser instalado sobre un equipo nuevosin necesidad de software adicional, como le ocurre a Windows 3.x, y que ofrece nuevastecnologıas para el desarrollo y ejecucion de todo tipo de aplicaciones.

Algunas de sus caracterısticas mas importantes son:

Robustez. NT es un sistema operativo estable y robusto, que impide a lasaplicaciones mal escritas estropear al resto del sistema.

257

APENDICE A. ADMINISTRACION DE SISTEMASFernando Ballesteros Herranz

Seguridad. NT ha sido escrito para satisfacer criterios de seguridad tıpicosde organismos oficiales y empresas cuyos datos y aplicaciones deben quedar asalvo de accesos no autorizados. Practicamente cada objeto del sistema poseeun esquema de seguridad asociado que indica que usuarios pueden acceder alobjeto y con que privilegios pueden acceder.

Portabilidad. El diseno de NT permite que se pueda adaptar facilmente a otrasarquitecturas para las que no fue originalmente desarrollado. Actualmente so-porta las arquitecturas de Intel X86, MIPS, Alpha y PowerPC. Su diseno mod-ular y el estar escrito en lenguaje facilmente portable, como es el C, permiteesta rapida migracion.

Compatibilidad con las aplicaciones Windows. La capacidad de NT para eje-cutar aplicaciones MSDOS y Windows permite disponer de gran cantidad desoftware escrito que permite sacar rendimienteo al sistema sin tener que mi-grar las aplicaciones. Incluso las nuevas aplicaciones Win32 corren en modonativo en las diferentes plataformas de NT, simplemente recompilandolas paracada plataforma, o incluso a traves de los emuladores-compiladores JIT (JustIn Time) como son el X86, distribuido gratuitamente para las plataformas noIntel soportadas.

Velocidad. NT esta desarrollado para hacer frente a las aplicaciones que nece-sitan gran cantidad de recursos y altas velocidades de ejecucion, tıpicas de en-tornos cliente/servidor y de ingenierıa, como pueden ser servidores de recursosde red, de bases de datos y programas de calculo cientıfico y diseno grafico.

A.1.2. Sistemas de archivos

Hay varios tipos de gestores de archivos para los equipos, estos son utilizadosdependiendo del sistema operativo y la gestion realizada por el administrador de lared:

FAT: 16 bits, es compatible con Windows 95/98/NT/2000/XP y MS-DOS. Esel mas utilizado en la gestion de los archivos en los disquetes. Los cluster sonde 32 KB, esto quiere decir que los datos se guardan en paquetes de 32 KB. Unfichero que ocupe 33KB, ocupara 2 cluster, por lo que se desperdician 31 KBdel 2o cluster.

FAT 32: 32 bits, compatible con Windows 95/98/2000/XP. Mas eficiente quelas particiones FAT.

NTFS: Utilizado por los sistemas basados en Red, Windows NT/2000/XP. Loscluster son de menor tamano, son de 4 KB, de esta forma se aprovecha mejorel espacio en el disco.


Fernando Ballesteros Herranz A.1. INTRODUCCION A WINDOWS NT Y 2000

Ext 32: sistema de gestion de archivos utilizado por equipos Unix y sistemaoperativo Linux.

Hay mas tipos de gestores de archivos, solo se han senalado los que pueden serinteresantes en una administracion de equipos de una Red basada en Windows y a losumo 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. Porejemplo en las versiones 3.X de NT se utilizan el administrador de programas y demaselementos del Windows 3.X, mientras que en NT 4.0 se emplea el nuevo interfase deWindows 95/98. Esto permite reducir la curva de aprendizaje para el nuevo sistemaoperativo. NT saca un mejor provecho que los diferentes Windows a la ejecucion deaplicaciones en multitarea real, permitiendo ejecutar varias aplicaciones simultanea-mente, conmutando rapidamente entre ellas.

NT puede ejecutar varios tipos de aplicaciones:

Aplicaciones MSDOS. La mayor parte de las aplicaciones MSDOS corren sinproblemas.Solo aquellas que acceden directamente a recursos especıficos, comopueden ser el puerto serie o el paralelo, o que intentan capturar las interrup-ciones basicas de MSDOS, no funcionan. Tıpico ejemplo de estas aplicacionesson las que funcionan con llaves de proteccion del tipo “mochila” que no estanespecıficamente preparadas para NT.

Aplicaciones Windows de 16 bits. La mayor parte de las aplicaciones de 16 bitsfuncionan sin problemas bajo Windows NT. Algunas aplicaciones, que utilizanllamadas no documentadas a las APIs de Windows, o que hacen suposicionessobre los recursos de Windows que son solo validos en Windows 3.x fallan alejecutarse sobre NT.

Aplicaciones Win32. Son las nuevas aplicaciones desarrolladas para Windows 95y NT. Las aplicaciones Win32 eliminan gran parte de los problemas que tenıanlas aplicaciones Win16, que estan basadas en el modelo plano de memoria, quepermite a las aplicaciones disponer de hasta 2 gigabytes de datos. Las aplica-ciones Win32 se ejecutan siempre como multitarea real, en espacios de memoriaseparados que evitan que el mal funcionamiento de una de ellas repercuta en lasdemas. Ademas las aplicaciones Win32 hacen uso de las nuevas APIs Win32,mas potentes y flexibles, con capacidad de ejecucion de multiples hilos. Estopermite a las aplicaciones ejecutar tareas de fondo, como la revision ortografi-ca, recalculo, repaginacion e impresion tıpica de los procesadores de texto y de



las hojas de calculo. Esto evita al usuario largos tiempos de espera en su trabajohabitual.

Aplicaciones POSIX. Son aplicaciones basadas en el estandar comun POSIX,un subconjunto de las APIs de UNIX. El susbsistema POSIX emula el com-portamiento de las aplicaciones UNIX, incluyendo elementos como el uso deenlaces (links) para los ficheros. Para desarrollar aplicaciones POSIX para NTse puede utilizar el compilador que se distribuye en el kit de recursos, o unanueva distribucion del popular GCC de GNU (distribucion Cignus) que incluyeun soporte mucho mas avanzado tanto de aplicaciones Win32 como de aplica-ciones POSIX. Este compilador se puede encontrar en los espejos de GNU enla red.

Aplicaciones OS/2. Se pueden ejecutar aplicaciones OS/2 de modo texto. Lasaplicaciones basadas en Presentation Manager se pueden ejecutar utilizando unmodulo 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 fısica de la red. El funcionamiento basico de la red Microsoft, basadoen el protocolo Netbeui, supone que todos los miembros de la red estan inter-conectados entre sı. Esto implica que no hay barreras del tipo conmutadoreso encaminadores de red entre las diversas partes de la red. Cuando apareceeste 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 localdentro de una red mas compleja.

Para la parte logica de la red, el esquema de red de Microsoft permite trabajarde 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 redlocal del tipo de igual a igual. En este modo de funcionamiento, en principio todos losordenadores pueden ser clientes y servidores simultaneamente. Los grupos de trabajofueron introducidos por Microsoft cuando introdujo en el mercado Windows paraTrabajo en Grupo. Este esquema de funcionamiento es bastante sencillo, ya que noprecisa de la existencia de la figura del administrador del grupo.


Fernando Ballesteros Herranz A.2. LA RED MICROSOFT WINDOWS

Todos los ordenadores a priori se comportan de la misma forma, pudiendo accedertodos ellos a los demas ordenadores de la red. Esto no impide que dentro de un grupode trabajo se puedan introducir maquinas configuradas exclusivamente como clienteso como servidores.

A.2.2. Los dominios NT

El sistema de dominios en NT hereda la funcionalidad que permitıa obtener losdominios Lan Manager de Microsoft. El esquema de dominios aporta grandes ventajasen la seguridad de la red, aunque anade mayor carga administrativa. En un grupo detrabajo, al no existir la figura del administrador, deben ser los propios usuarios los quese encarguen de la configuracion de la seguridad. El sistema de dominios introduce lafigura 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 deldominio.

Un dominio esta compuesto por al menos un controlador primario del dominioy por estaciones de trabajo que actuan como clientes del dominio. El controladorprincipal del dominio va a ser el ordenador que va a almacenar la base de datosde usuarios y de ordenadores del dominio. Un dominio puede tener varios tipos declientes:

Clientes Windows para trabajo en Grupo, Windows 95/98, Windows NT/2000Workstation y Server.

Ordenadores con MSDOS o Windows 3.1, con el cliente de red Microsoft insta-lado.

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 sistemade grupos de trabajo cuando la red es pequena. El sistema de dominios necesita unamayor planificacion inicial frente al grupo de trabajo, ya que el administrador debedar de alta a los usuarios y equipos. Sin embargo, al ampliar la red esa mayor cargaadministrativa inicial se traduce en una mayor simplicidad de la administracion de unared corporativa. Cuando el numero de ordenadores y de usuarios de la red comienza a



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 unica, y esta cen-tralizada. A cada usuario se le asigna una cuenta que le identifica en el dominio. Enprincipio la autenticidad del usuario esta garantizada por el uso de su contrasena.Esto facilita al usuario el acceso a los recursos del dominio, ya que la mayor partede las veces no necesitara introducir su contrasena. El esquema de dominios permiteademas crear grupos de usuarios. Los grupos de usuarios facilitan la administracionde los dominios ya que permite asignar seguridad, aplicaciones y otros recursos deldominio a grupos de usuarios con caracterısticas comunes. El sistema de grupos deusuarios es muy flexible, permitiendo adaptar el dominio a la estructura corporativa.

Un usuario del dominio puede pertenecer a varios grupos, de manera que cada unode 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 detrabajo. A medida que se anaden estaciones y servidores al dominio, el administradorutiliza las herramientas administrativas para darlos de alta en el dominio. Cuandoun equipo es dado de alta en el dominio puede comunicarse de una manera seguracon los demas miembros del dominio. De esta manera puede reconocer a los demasusuarios y equipos del dominio. Esta tarea es realmente sencilla. Durante el procesode instalacion de una estacion de trabajo o servidor NT, aparece un cuadro de dialogoen el que se da la oportunidad de anadir el equipo al dominio. Para anadir el equipobasta escribir el nombre del dominio y nombre de usuario y contrasena con privilegiosde administrador valido en el dominio. El proceso de instalacion se pone en contactocon el controlador del dominio y da de alta al ordenador en el dominio. Una vez que seha dado de alta en el dominio, el programa de instalacion configura automaticamenteel sistema para que sea miembro del dominio. El proceso completo se desarrolla enpocos segundos y sin intervencion del usuario.

El sistema de dominios simplifica enormemente la gestion de grandes dominios, yaque los cambios introducidos en la configuracion del dominio se reflejan automatica-mente en todos los miembros del dominio. Si por ejemplo se anade un nuevo equipoal 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 tododominio puede haber:

Un controlador principal del dominio. Es obligatorio, ya que es el equipo quemantiene la base de datos del dominio. Este servidor debe ser obligatoriamente



un NT Server configurado como controlador principal del dominio.

Controladores de reserva del dominio. Puede haber varios en el dominio. Sulabor consiste en ayudar al controlador principal en caso de sobrecarga o malfuncionamiento de este. Es recomendable siempre tener al menos un contro-lador de reserva correctamente configurado, ya que de este modo se asegura quesiempre los usuarios podran iniciar sesion correctamente en el dominio.

Estaciones de trabajo. Son los clientes del dominio, y pueden ser de diferentestipos (Windows, Os/2, etc.)

Servidores NT. Se puede configurar NT Server en el modo servidor. En estemodo, el servidor no colabora en la validacion de los inicios de sesion por partede los usuarios, con lo que la carga del servidor es menor. Este modo se sueleutilizar para configurar servidores de ficheros y aplicaciones, como servidoresSQL y de Internet. Ademas, un NT Server configurado como servidor mantienesu propia base de datos, ademas de poder acceder a la del dominio. Esto permitetener cuentas separadas de las del dominio. El uso fundamental que se puededar 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 formapueden acceder al dominio NT, normalmente con sus propias herramientas deintegracion. Por ejemplo, desde que Microsoft hizo publico el protocolo SMB,hay sistemas que soportan parte de la funcionalidad de este protocolo, aunqueno 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 puedenser impresoras y unidades de red. En una red Microsoft el nombre de los recursossigue el siguiente convenio:

\\servidor\recurso

escrito en el formato UNC (Universal Name Convention). Servidor es el nombredel 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 puedeponer la ruta completa de directorios, y el nombre de un archivo cuando nos estamosrefiriendo 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



otro tipo de recursos, como unidades CD-ROM, modems, fax (con el software ade-cuado, no incluido en NT), y otros tipos de recursos especiales, como pueden ser lastuberıas 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 admin-istrador de archivos (Winfile.exe)

Para compartir impresoras se utiliza el administrador de impresion.

Para tipos especiales de recursos, normalmente hay herramientas especiales quelo hacen. Normalmente todos los recursos compartidos aparecen en los listadosde recursos de red de todos los clientes. Se puede modificar el nombre de recursopara que no aparezca en los listados de recursos. A este tipo de recursos se lesllama recursos compartidos en modo administrativo.

Para compartir un recurso en modo administrativo basta con anadir un signo $ alfinal del nombre de recurso:

Por ejemplo, siempre que se inicia NT, el sistema de red comparte automatica-mente en modo administrativo las unidades de disco. Ası por ejemplo tendremos:

\\servidor\c$

\\servidor\d$

compartidas automaticamente al arrancar el ordenador. Luego se pueden dejarde compartir, si fuese necesario. Ademas NT anade los permisos correspondientespara que solo tengan acceso los administradores. Para ver los recursos compartidosen 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 servidoro estacion de trabajo, ver los recursos compartidos.

Este mecanismo permite de una manera muy comoda acceder a los admin-istradores a los diferentes discos de todas las estaciones de trabajo del dominio,para realizar labores de copia de ficheros, instalacion de aplicaciones, y otrastareas. Para conectarse a un recurso compartido en modo administrativo, yaque su nombre no aparece en los listados de recursos, debemos seleccionarlomanualmente:



• Escribiendo su nombre directamente, en el cuadro de dialogo Conectarsea una unidad de red.

• Utilizando NET USE \\servidor\recurso$.

Otra forma de acceder los administradores a los discos de las estaciones de trabajodel 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 com-partido en modo administrador se llamara en nuestro ordenador. En “MiPC” aparecera este como si fuera una unidad mas de nuestro ordenador.

Otro es “Carpeta”, donde se debe escribir a que maquina queremos accedery 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 otrasmaquinas.



A.2.6. Inicio de sesion en un grupo de trabajo

Cuando un usuario va a acceder a una red, lo primero que debe realizar es un iniciode sesion. El inicio de sesion consiste en que el usuario debe introducir un nombre deusuario y una contrasena, 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 desesion, el inicio de sesion en Windows para trabajo en grupo es simple. El inicio desesion 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 puedeiniciar sesion con cualquier nombre dentro del grupo de trabajo. No existe ningunmecanismo que impida al usuario iniciar sesion de red.

Durante el inicio de sesion en un grupo de trabajo, al usuario se le pide su nom-bre de usuario y su contrasena. En Windows para Trabajo en Grupo el nombre deusuario se utiliza como identificador del usuario, aunque no hay ninguna garantıa dela verdadera identidad del usuario. La contrasena facilitada por el usuario se utilizapara dos tareas:

Cuando se acceden a los recursos de red protegidos por contrasena, Windowspara Trabajo en Grupo facilita esta contrasena en primer lugar. Si la contrasenano es valida, mediante un cuadro de dialogo se pedira al usuario la contrasenacorrecta para acceder al recurso.

La contrasena ademas se utiliza para encriptar el archivo de contrasenas, quenormalmente se llamara nombre.pwl, donde nombre es el nombre del usuario.En este archivo se guardan las contrasenas utilizadas por el usuario para accedera los recursos de red.

Si un usuario ha olvidado la contrasena, no podra desbloquear el archivo de con-trasenas. Normalmente puede iniciar sesion con otro nombre de usuario, y borrar elantiguo archivo de contrasenas, con lo que de nuevo podra iniciar sesion en el sistemacon su nombre de usuario habitual.

El esquema de contrasenas de los grupos de trabajo suele ser bastante engorroso,ya que cuando la contrasena de un recurso cambia obliga a difundir de nuevo lascontrasenas a los usuarios interesados. Ademas los archivos de contrasenas son muyfaciles de desbloquear, existiendo en Internet numerosas utilidades que lo hacen. Win-dows para trabajo en grupo es bastante difıcil de cerrar, para impedir el acceso alsistema y a la red de un usuario que no tiene permiso para ello.



A.2.7. Inicio de sesion en un dominio

Aparentemente el metodo de inicio de sesion en un dominio NT es similar alutilizado en un grupo de trabajo. El usuario tiene que realizar el proceso de inicio desesion o logon, suministrando un nombre de usuario y una contrasena valida para eldominio.

El proceso de inicio de sesion en un dominio es mas sofisticado:

El usuario proporciona el nombre de usuario y la contrasena en el cliente deldominio. Dependiendo del cliente, este procedimiento puede ser mas o menosseguro. Por ejemplo, en Windows para trabajo en grupo se siguen los mismospasos que para el inicio de sesion de red normal, aunque la contrasena para eldominio hay que proporcionarla en un cuadro de dialogo separado, para mayorseguridad. En Windows NT, el proceso de inicio de sesion automaticamenteregistra al usuario en el dominio, y requiere el uso de una combinacion especialde teclas: Ctrl+Alt+Suprimir.

El cliente solicita el inicio de sesion al servidor controlador del dominio. En estemomento el servidor envıa al cliente un conjunto de datos. Este esquema devalidacion es un esquema de tipo desafıo/respuesta.

El cliente encripta los datos enviados por el servidor con la contrasena que le hasuministrado el usuario. Este nuevo conjunto de datos es enviado al servidor.

El servidor encripta los datos originales, con la contrasena del usuario que guar-da 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 servidorvalida al usuario para acceder al dominio.

Durante el proceso de inicio de sesion, la contrasena del usuario no viaja por lared, ya que con el sistema de reto, lo que viajan son paquetes de datos codificados,pero no la contrasena que los codifica. Este sistema tiene un punto vulnerable, ya queen el servidor se almacenan las contrasenas de todos los usuarios en la base de datosde usuarios. Sin embargo, se han introducido mejoras en el sistema de gestion de labase de datos, que hace muy difıcil el acceso a las contrasenas incluso para los propiosadministradores de NT. Estas mejoras fueron introducidas con el Service Pack 3 paraNT Server.

El inicio de sesion en el dominio solo se produce una vez. Es decir, una vez queun usuario ha iniciado sesion en un dominio, no necesita suministrar de nuevo sucontrasena para acceder a los diferentes recursos del dominio. En todo momento, lavalidacion del usuario se va a realizar a traves de los controladores y servidores.



El sistema de seguridad de NT no solo permite gestionar el acceso de los usuariosa los recursos, sino que incluso se pueden crear grupos de usuarios a los que se lesasignan privilegios, por lo que la gestion de la seguridad se simplifica dentro deldominio.

A.2.8. Los controladores de dominio

Todo dominio tiene una base de datos de usuarios. La copia original de esta basede datos reside en el controlador principal del dominio. En esta base de datos quedanregistradas todas las caracterısticas de los usuarios, sus cuentas, y de los ordenadoresque forman parte del dominio.

Ademas del controlador principal del dominio, puede haber dentro de un dominiovarios controladores secundarios del dominio. En estos controladores se mantiene unacopia de la base de datos de usuarios del dominio. Si el controlador del dominioesta muy cargado o simplemente esta inactivo, cualquier controlador del dominiopuede validar el inicio de sesion en el dominio.

El proceso de inicio de sesion en los controladores del dominio comienza en elcliente por obtener la lista de controladores del dominio. Para ello el servicio Exami-nador de computadoras obtiene dicha lista, bien mediante una pregunta por difusion(broadcast), o bien preguntando a los servidores WINS del dominio. Una vez obtenidala lista, el cliente envıa una peticion de inicio de sesion a los diferentes controladoresdel dominio. El cliente elegira al primer controlador de dominio que le conteste paraintentar el proceso de inicio de sesion. Este metodo asegura que siempre el clientepueda iniciar sesion en el dominio.

El mantenimiento de la base de datos del dominio es automatico. Las herramien-tas administrativas de NT permiten modificar la base de datos, mediante el Admin-istrador de usuarios para dominios.

Los cambios se realizan siempre sobre el controlador principal del dominio, y sonenviados automaticamente a los demas controladores del dominio. Hay que tener encuenta que esto se realiza con una pequena demora temporal, que se puede reducirsincronizando 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: Workstationy Server.


Fernando Ballesteros Herranz A.3. EL ADMINISTRADOR DE USUARIOS

La version Workstation esta pensada para configurar puestos de trabajo, dondese ejecutaran las aplicaciones de usuarios. NT Workstation es una plataforma queincluye todos los elementos para trabajar con aplicaciones Windows y para trabajaren red. Incluye una pila completa TCP/IP.

NT Server esta preparado para configurar servidores. Aunque realmente los nucleosde NT Server y Workstation son muy parecidos, la version Server incluye una serie demejoras en el nucleo y en los diferentes modulos del sistema que lo hacen mas robustoen tareas de servidor de red. NT Server da mayor prioridad a los accesos mediantered frente a las aplicaciones de usuario que se ejecutan en el servidor. Ademas NTServer no tiene el lımite de 10 conexiones simultaneas de red que tiene NT Worksta-tion. NT Server ofrece mayor seguridad en el almacenamiento de datos, ya que poseecaracterısticas avanzadas de tolerancia a fallos que no han sido incluidas en la versionWorkstation.

A.3. El Administrador de usuarios

En NT hay dos tipos de usuarios, aquellos que pertenecen a una maquina quecorre NT WK o Server y aquellos que pertenecen a un dominio NT. Para cada uno deestos tipos de usuarios existe una herramienta de administracion: el administrador deusuarios incluido en NT Workstation y el administrador de usuarios para dominiosincluido 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



para dominios dispone de mas opciones. Por ello, se describira el administrador deusuarios para dominios.

Las tareas que se pueden realizar con el administrador de usuarios:

Anadir, modificar y eliminar usuarios del dominio.

Anadir, modificar y eliminar grupos locales y globales del dominio.

Fijar el plan de cuentas y contrasenas en el dominio.

Fijar la polıtica de derechos de usuario en el dominio.

Establecer el sistema de auditoria en el dominio.

Establecer relaciones de confianza entre dominios.

A.3.1. Creacion y modificacion de usuarios en el dominio

Crear un usuario nuevo

Para crear un usuario se pulsa Usuarios\Nuevo y se completa el cuadro dedialogo. (Ver figura A.3).

Figura A.3: Administrador de Usuarios; usuario nuevo

En este cuadro hay que rellenar una serie de campos:



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 unico en el dominio. Se lesuele conocer tambien como nombre de cuenta o login. Este identificador esel que se debe suministrar, junto con la contrasena, para iniciar sesion en undominio NT.

Nombre completo Es el nombre completo del usuario. Si este usuario es una per-sona se suele escribir el nombre y apellidos.

Descripcion Conviene anadir una descripcion de la labor, grupo de personas o de-partamento al que pertenecen el usuario, sobre todo si la base de datos deusuarios en el dominio es grande.

Contrasena Aquı se debe escribir la contrasena para el usuario. Puede incluir es-pacios, mayusculas y minusculas, e incluso caracteres especiales. NT admitehasta 14 caracteres. Cuando se va escribiendo aparecen asteriscos, y una vezcompletada en el cuadro aparece una lınea de asteriscos, siempre de la mismalongitud.

Repetir contrasena Hay que introducir de nuevo la contrasena, para comprobarque se ha escrito correctamente.

Tras estos campos aparecen una serie de botones activables:

El usuario debe cambiar su contrasena La primera vez que inicia sesion en NTse va a solicitar que introduzca una nueva contrasena. Habitualmente los admin-istradores crean los usuarios nuevos con contrasenas del tipo “cambiame”, queobligan al nuevo usuario a cambiar su contrasena al iniciar sesion por primeravez.

El usuario no puede cambiar su contrasena Se utiliza en tareas administrati-vas especiales, y bloquea el cambio de contrasena por parte del usuario.

La contrasena nunca caduca Desactiva la caducidad de contrasenas para estausuario. Se utiliza normalmente solo para algunos usuarios que lo necesitan.

Cuenta desactivada Permite bloquear la cuenta facilmente sin borrarla. Se sueleutilizar cuando el usuario no va a iniciar sesion durante un periodo de tiempoo cuando se va a cambiar la configuracion o entorno del usuario y se necesitaque no pueda acceder temporalmente al sistema.

Al final del cuadro de dialogo aparecen varios botones (ver figura A.3).



Figura A.4: Administrador de Usuarios; usuario nuevo; grupos

Grupos Permite establecer los grupos a los que pertenece un usuario (ver figuraA.4). En NT hay dos tipos de grupos:

Grupos globales Validos para dominios en los que se confıan. Aparecen mar-cados con el icono de grupo global.

Grupos locales Son grupos locales al servidor o estacion de trabajo.

Perfil Permite controlar las caracterısticas del entorno de un usuario (figura A.5).Se puede establecer:

Perfil Nombre del fichero que representa el perfil del usuario para NT. Hay queescribir un fichero en formato UNC (Univer name convention), es decir:

\\servidor\recurso\directorio\fichero.bat.

Figura A.5: Administrador de Usuarios; usuario nuevo; perfil



Archivo de inicio Asigna un archivo que se ejecutara al iniciar la sesion de reden el dominio. El archivo debe residir en el servidor que valida el inicio desesion. Este fichero se debe hallar en la carpeta NETLOGON del servidorque 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 ini-cia 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 dedialogo de guardar un fichero en una aplicacion Windows.

Horas En el boton Horas podemos acceder al cuadro de dialogo de Horas de iniciode sesion (ver figura A.6). En este cuadro de dialogo se pueden fijar las horasde inicio de sesion en los servidores del dominio, en intervalos de 1 hora, paracada dıa de la semana. En principio una vez iniciada la sesion el usuario puedeseguir trabajando en los servidores, aunque se puede modificar esto, para quelos servidores cierren la sesion del usuario al terminar las horas permitidas,mediante el cuadro de dialogo Plan de cuentas en el menu de Directivas delAdministrador de Usuarios.

Figura A.6: Administrador de Usuarios; usuario nuevo; horas

Iniciar desde Este cuadro de dialogo permite seleccionar los ordenadores desde loscuales un usuario puede iniciar sesion. Se pueden especificar hasta 8 ordenadoresque ejecuten NT, o permitir el inicio en todos los ordenadores del dominio. Verfigura A.7.



Figura A.7: Administrador de Usuarios; usuario nuevo; iniciar de sesion

Cuenta El cuadro de dialogo Informacion de cuenta permite especificar el tipo decuenta y su duracion. Se puede elegir que la cuenta caduque en una fecha de-terminada o que no tenga caducidad. Tambien se puede especificar si es unacuenta 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 demarcado para el usuario. Figura A.9.

Modificar un usuario

Utilizando el menu Usuario\Propiedades o haciendo doble clic sobre un usuarioo grupo se puede modificar el mismo.

Al modificar un usuario se acceden a los mismos cuadros de dialogo empleadosal crearlo salvo que ahora aparece una casilla para cuentas bloqueadas. Si el bloqueo



Figura A.9: Administrador de Usuarios; usuario nuevo; marcado

de cuentas esta activado en el dominio y el usuario ha fallado el numero de veceslimitado para ese dominio, esta casilla aparece activada. Al desactivarla, la cuentadel usuario es desbloqueada.

Nota importante: existe una ligera demora al cambiar las propiedades de unusuario o grupo del dominio, debido a que la base de datos de usuarios del dominiotarda unos minutos en actualizarse en los controladores secundarios. Se puede forzarla actualizacion inmediata mediante la sincronizacion manual de los servidores.

A.3.2. Creacion de grupos

Para un NT Workstation (o Server configurado como servidor) el administradorde usuarios permite crear grupos locales, que solo tienen validez en el propio orde-nador. 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 gruposglobales del dominio y los grupos globales de otros dominios en los que se confıa.

Los grupos globales tienen como miembros a los usuarios del dominio y se puedenutilizar tanto en los servidores del dominio como en las estaciones de trabajo deldominio. Tambien se pueden usar en otros dominios en los que se confıa.



Creacion de un grupo global nuevo

Para anadir un grupo global nuevo se selecciona el menu Usuario\Grupo Glob-al nuevo y se proporcionan en el cuadro de dialogo el nombre del grupo y unadescripcion opcional. Podemos ademas anadir usuarios al grupo.

Creacion de un grupo local nuevo

Para anadir un grupo local nuevo se selecciona el menu Usuario\Grupo Lo-cal nuevo y se proporcionan en el cuadro de dialogo el nombre del grupo y unadescripcion opcional. Podemos ademas anadir usuarios al grupo.

Usos de grupos locales y globales

Cuando se crea un dominio el programa de instalacion de NT crea una serie degrupos globales y locales del dominio. Tambien se crea la cuenta del administradordel dominio, y se anade al grupo administradores del dominio.

El grupo administradores que se ha creado permite administrar todos los servi-dores del dominio. NT anade al grupo local administradores el grupo administradoresdel dominio. De igual manera ocurre con el grupo de usuarios e invitados. Cuando unaestacion de trabajo es anadida al dominio, NT anade automaticamente los tres gruposglobales del dominio (administradores, usuario e invitados del dominio) a los gruposlocales correspondientes de la estacion de trabajo. Los grupos locales se utilizan paraasignar tareas especiales en las estaciones de trabajo o servidores del dominio. Porejemplo se pueden crear los grupos especiales para trabajar con el recurso como unaimpresora laser en color, cuyo acceso queremos restringir. Uno lo podemos llamar“Administradores de laser color” y otro “Usuarios de laser color”. Ahora basta darpermisos de impresion al grupo “Usuarios de laser color” y control total al grupo“Administradores de laser color”. Para anadir usuarios a estos grupos bastarıa anadiral grupo “Administradores de laser color” el grupo “Administradores del dominio” yal grupo “Usuarios de laser color” los miembros del dominio autorizados a imprimiren ella. Este ultimo paso lo podemos hacer de un medio mas eficiente si creamos ungrupo global “Usuarios de impresora laser color” y anadimos este grupo al grupo lo-cal “Usuarios de laser color”. Para dar permisos de impresion a los usuarios y gruposutilizaremos el Administrador de Impresion de dicha impresora, accesible desde elmenu de inicio Configuracion\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 encada servidor.


Fernando Ballesteros Herranz A.4. PERMISOS Y SEGURIDAD

A.4. Permisos y seguridad

En NT se pueden fijar una serie de directivas comunes para todo el dominio. Entreestas se puede fijar el plan de cuentas para el dominio, que fija propiedades de lascuentas tales como la polıtica de contrasenas, el plan de derechos de usuarios, quepermite asignar determinados permisos genericos usuarios o grupos del dominio, o elplan de auditoria, que permite activar los elementos del sistema de auditoria en eldominio.

A.4.1. Administracion del plan de cuentas

Desde el menu Directivas\Cuentas podemos acceder al cuadro de dialogo “Plande cuentas”.

En este cuadro podemos fijar las limitaciones de las contrasenas y el sistema debloque de cuentas. Cuando se ha seleccionado caducidad para la contrasena de unusuario, la contrasena utilizara las opciones elegidas en este cuadro de dialogo. Sepuede elegir:

Duracion maxima de la contrasena, en dıas.

Duracion mınima de la contrasena, para que el usuario cambie dos veces sucontrasena y vuelva a usar la contrasena antigua.

Longitud mınima de la contrasena. Las contrasenas con mas de 6 caracteres sondifıciles de saltar por metodos de asalto masivo (crackers), tambien llamados de“fuerza bruta”. Esto es util en redes conectadas a Internet.

Historia de la contrasena, que obliga al usuario a no repetir las ultimas con-trasenas.

Bloqueo de Cuentas El sistema de bloqueo de cuentas permite a los controladoresde 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 intentosespecificado la cuenta es bloqueada. Si el numero de intentos fallidos no alcanzaal especificado, el usuario puede esperar el tiempo fijado en “restablecer cuenta”para poder volver a intentarlo. Fijando por ejemplo estos parametros a 4 intentosy 10 minutos suele bastar para disuadir de accesos no autorizados. Una vezbloqueada la cuenta se puede elegir entre desbloqueo automatico o manual, conintervencion del administrador del dominio.



Tambien en este cuadro de dialogo se puede seleccionar si los usuarios remotosseran desconectados de los servidores al acabar su tiempo de conexion y si un usuariodebe iniciar sesion en una estacion de trabajo para poder cambiar su contrasena.

A.4.2. Administracion del plan de derechos de usuarios

Los derechos de usuarios son una serie de permisos que no se aplican sobre unobjeto concreto, como un fichero, impresora o directorio, sino que se aplican al sistemacompleto. Estos permisos tienen prioridad sobre los permisos asignados sobre losobjetos del sistema. Se pueden asignar a cada tipo de derecho de usuario los usuarioso grupos de usuarios a los que se necesite otorgar ese derecho.

Los derechos de usuarios pueden ser modificados desde el cuadro de dialogo “Plande derechos de usuarios” accesible desde el menu Directivas\Derechos de usuar-ios. 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 veralgunos derechos de usuarios mas especıficos. Normalmente los derechos de usuarioasignados por NT asignan derechos suficientes a los grupos de usuarios creados porNT. Cuando se instalan algunos servicios, como servidores de correo, de Web y simi-lares suele ser necesario cambiar algunos de estos derechos. Los mas frecuentes suelenser:

Iniciar sesion como servicio. Permite asignar un usuario a un servicio. Sueleser usuario en servidores de ficheros tipo FTP, Gopher y Web, ya que permiteasignar permisos a los ficheros para ese usuario, limitando el acceso a otrosficheros del sistema. Tambien lo usa el servicio de duplicacion de directorios.


Fernando Ballesteros Herranz A.5. PERMISOS Y SEGURIDAD EN NT

Iniciar sesion como proceso por lotes. Este derecho esta pensado para los ser-vicios que atienden las peticiones de usuarios en forma de transacciones, comopor ejemplo servidores POP3 y otros. Actualmente no esta implementado enel sistema operativo, pero algunos servicios verifican que el usuario posea estederecho 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 deNT. En NT todos los elementos del sistema, como pueden ser archivos, directorios,unidades de disco, impresoras,... se consideran “objetos”. Un objeto es un elementodel sistema operativo dotado de una serie de propiedades comunes a todos los objetosde su mismo tipo. En NT cada objeto del sistema tiene incorporada su seguridad demanera que el sistema puede determinar para cada objeto los permisos y modo deacceso permitidos a cada usuario.

En NT no existe una herramienta que centralice el sistema de seguridad, sinoque para cada tipo de objeto la herramienta que permite modificar sus propiedadestambien modifica su seguridad. Las principales herramientas administrativas que fijanla seguridad de los objetos son el administrador de usuarios, el administrador deimpresion 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 paracada usuario de Windows NT. En Windows 3.x estas opciones habitualmente se guard-aban en archivos .ini que eran archivos de texto normalmente compartidos por todoslos usuarios de la aplicacion. En NT todas las opciones y configuraciones del sistemay de las aplicaciones se guardan en el registro.

El registro es una base de datos jerarquizada donde se guarda toda la informacionde configuracion. En NT existe un registro completo para el sistema y uno para cadauno de los usuarios que han iniciado sesion en el sistema, que son los llamados perfilesde usuario.

Cuando un usuario inicia una sesion por primera vez en NT, el sistema crea unregistro personalizado para el usuario. Si no se ha definido previamente un perfil parael usuario, el sistema utilizara una copia del perfil de usuario por defecto. Tanto losperfiles de usuario como el perfil de usuario por defecto se puede editar para establecerde antemano las opciones del entorno de usuario.



A.5.2. Perfiles de usuario frente a perfiles obligatorios

Cuando un usuario inicia sesion en un NT el sistema busca su perfil. Este perfilexistira si el usuario ya ha iniciado anteriormente sesion en NT. En caso de que notenga perfil utiliza una copia del perfil de usuario por defecto. Las modificaciones querealice el usuario en su entorno se guardaran en esta copia del perfil.

Se puede modificar este mecanismo para asignar un perfil concreto al usuario. Estose 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 estefichero. Este proceso solo se realiza la primera vez que el usuario inicio sesionen la maquina.

perfil obligatorio. El sistema crea un perfil para el usuario basandose en estefichero cada vez que el usuario inicia sesion en el sistema, de manera que elusuario pierde la configuracion. Esto permite que el usuario parta de un entornoestandar cada vez que inicia sesion.

Se pueden eliminar perfiles antiguos de usuarios del sistema. Para ello, deberemosabrir el menu Opciones/Eliminar perfil del icono Instalacion de Windowsen 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 especıfico del ordenador en el que se ha creado. El usuario solopuede acceder al perfil local al iniciar sesion interactiva en el ordenador en elque reside el perfil.

Movil 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. Normalmenteson asignados a un usuario o grupos de usuario por el administrador.

En el perfil de NT 4.0 se guardan opciones como:


Fernando Ballesteros Herranz 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, endirectorios separados cuyo nombre se crea a partir del nombre del usuario. Este di-rectorio contiene ademas un perfil por defecto, en Default User, que se aplica a todousuario que inicia sesion interactiva por primera vez y no dispone de perfil, y un direc-torio llamado All Users que es accesible dentro del elemento programas del menu deinicio de todos los usuarios que inician sesion en el sistema. Esta carpeta guarda lascarpetas 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 ficherose 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 actu-aliza con los cambios introducidos en NTuser.dat.log. En el caso de que existanproblemas al actualizar el fichero NTuser.dat, los cambios se actualizaran en elsiguiente 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 sin-cronizada las preferencias y opciones del entorno de un usuario. Cuando un usuarioinicia 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 delperfil” 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 des-de el servidor hasta el directorio \Windir\profiles local. El usuario puede modificary usar su entorno. Al cerrar la sesion, el perfil central se actualiza con los cambiosintroducidos por el usuario.



A.5.5. Creacion de un perfil en NT 4.0

El metodo de creacion de perfiles se realiza mediante el icono de sistema del panelde 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 com-partido de tipo unidad de red en un servidor adecuado. No es necesario que seael controlador de dominio. Por ejemplo:

\\servidor\perfiles

Configuramos la seguridad del recurso para que los usuarios tengan acceso a superfil.

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 pestana Perfiles deusuario. · Se selecciona el perfil del usuario actual y se pulsa “Copiar a ”. Verfigura 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 quese les permite usar el perfil. Este boton se usa con perfiles asignados a gruposdel tipo obligatorio, ya que si un usuario no pertenece a un grupo que tengapermiso para usar el perfil, no podra cargarlo.


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 tratade un perfil movil.

Perfiles Obligatorios

Para asignar un perfil a un usuario de manera que el usuario no pueda actualizarel perfil con los cambios introducidos se utiliza el perfil obligatorio. Los perfiles obliga-torios ayudan al administrador a gestionar los perfiles, ya que aseguran que el usuariocada vez que inicia la sesion encuentre un entorno coherente. Esto suele ser necesariocuando los usuarios son inexpertos o por simples motivos de seguridad. Cuando el ad-ministrador debe mantener una gran cantidad de cuentas de usuarios, puede asignarperfiles obligatorios a un grupo. Por ejemplo, puede crear un perfil para los usuariosdel 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 ultimo paso impide en NT 4.0 que el usuario pueda iniciar sesion con el perfilcache si el perfil principal no esta disponible (el servidor de perfiles esta fuera deservicio).

A.6. El editor de directivas POLEDIT.EXE

Las directivas del sistema permiten a los administradores controlar la configu-racion y la capacidad de modificar el entorno por parte de los usuarios, o lo que eslo mismo imponer ciertas reestricciones a los mismo. Esto puede ser realizado de unaforma centralizada para todo el dominio sobre:



Ordenadores Se puede modificar la configuracion predeterminada de los servidoresy estaciones de trabajo.

Usuarios Se puede eliminar la capacidad de un usuario para acceder a partes deli-cadas de la configuracion del sistema, como es la configuracion de red o partesdel escritorio de NT.

Grupos Se pueden asignar configuraciones para grupos de usuarios, lo que simplificanotablemente la administracion del dominio.

A.6.1. Funcionamiento de las directivas

El modo de trabajo de las directivas del sistema consiste en modificar ciertas clavesdel 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 parapermitir o denegar el acceso del usuario para la modificacion de estas partes. Cuandose 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 anadenclaves al registro. El perfil del usuario normalmente almacena informacion deconfiguracion que no compromete la seguridad del sistema.

Las directivas del usuario se aplican anadiendo las claves despues de habercargado el perfil de usuario. Esto permite que independientemente de la config-uracion almacenada en el perfil del usuario, se puedan aplicar las restriccionesde seguridad necesarios para el usuario. Las directivas del sistema por tanto seaplican anadiendo o alterando las claves del registro tras la carga del perfil.

A.6.2. Creacion de las directivas del sistema para un dominio

La herramienta que permite modificar las directivas del sistema es el Editor deDirectivas del sistema POLEDIT.EXE (ver figura A.12). Las directivas del sistema sepueden aplicar sobre el sistema actual, aunque cuando realmente se saca provecho delas directivas del sistema es cuando se definen directivas para un dominio completo.

Crear y modificar directivas para un dominio completo es sencillo. Para ello sedeben seguir estos pasos:

Se crea una nueva directiva con el menu Archivo\nueva directiva del editorde directivas.


Fernando Ballesteros HerranzA.6. EL EDITOR DE DIRECTIVAS POLEDIT.EXE

Figura A.12: El editor de directivas del sistema

Se modifica convenientemente la directiva, anadiendo usuarios, grupos y com-putadoras.

La directiva se guarda en el fichero ntconfig.pol. Este fichero se debe guarda enel directorio de archivos de inicio de sesion (scripts) de todos los controladoresde dominio.

A.6.3. Modo de funcionamiento de las directivas

El editor de directivas trabaja modificando las claves del registro. Para ello al crearuna 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 comun 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 anadirlamanualmente un administrador desde el subdirectorio \Windir\inf.

El arbol de directivas muestra conjuntos de directivas que se pueden activar. Cadauna de las directivas puede tener un estado:

Activado (casilla marcada). El editor de directivas modificara conveniente-mente las claves del registro para aplicar la directiva.

Desactivado (casilla en blanco). El editor de directivas modificara convenien-temente las claves del registro para no aplicar la directiva.

Sin cambios (casilla en gris). Es editor de directivas no realizara ningunamodificacion en el registro.



El ejemplo mas sencillo es la directiva que indica el protector de pantallas quedebe usar un usuario. Por defecto el usuario utiliza el protector de pantallas que dictasu 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 activaresta directiva se puede modificar el comportamiento, obligando a un usuario a utilizarotro protector de pantalla (quizas el que tiene el logotipo corporativo y obliga a usarcontrasena). En este caso de no activarse la directiva se utilizarıa la del perfil. FiguraA.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 quela informacion almacenada en las directivas del dominio son asumidas por todoslos sistemas cuando se incorporan al dominio al arrancar.

Usuarios Es el modo mas sencillo de gestionar la seguridad de un usuario.

Grupos Cuando el numero de usuarios es grande se puede dividir la configuracionen grupos.


Fernando Ballesteros Herranz A.7. EL PROTOCOLO TCP/IP

Hay que tener en cuanta que las directivas se aplican de modo acumulativo. Si unusuario pertenece a varios grupos para los que se han fijado directivas, el orden deaplicacion se obtiene segun se halla fijado en el cuadro de dialogo “directivas degrupo”

A.7. El protocolo TCP/IP

A.7.1. Introduccion

El protocolo TCP/IP nacio de los trabajos del ARPA (Advanced Research ProjectAgency)del Departamento de Defensa de los EEUU, durante las decadas de los 60 y70. A traves de las universidades y centros de investigacion se trato de construir unared que fuese capaz de resistir las caıdas parciales de la misma (por ejemplo en casode guerra). Ası surgio ARPANET, la primera red de intercambio de paquetes.

En 1974 V. Cerf y R. Kahn propusieron un nuevo conjunto de protocolos basicosde red que solventaban gran parte de los problemas de los protocolos usados enARPANET. Ası se pusieron los cimientos de los protocolos IP (Internet Protocol) yTCP (Transmission Control Protocol). En 1980 se comenzo la migracion de los aprox-imadamente 100 servidores que formaban la red ARPANET a los nuevos protocolos.En 1983 el Departamento de Defensa estandarizo el protocolo TCP/IP como proto-colo basico de red. Rapidamente otras agencias del gobierno adoptaron el protocolo,lo que obligo a las empresas proveedoras de equipos a implementarlo en sus sistemasoperativos y equipos de comunicaciones. Ademas el Departamento de Defensa im-pulso el protocolo TCP/IP al recomendar a la Universidad de Berkeley la inclusiondel 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: NET-BEUI, usado en las redes de Microsoft e IBM principalmente, IPX/SPX, usado enlas redes Novell Netware y el TCP/IP, parte basica de las redes UNIX, y principalprotocolo de la Internet.

Cada uno de estos protocolos tiene sus propias ventajas e inconvenientes. De unmodo general se recomienda cada uno de estos protocolos:

Netbeui Para compartir ficheros e impresoras en redes sencillas. Para este tipo de



redes se muestra muy eficaz, dada su practicamente nula necesidad de configu-racion. No es encaminable.

IPX/SPX De aplicacion en redes en las que existan servidores Novell Netware. Tieneun 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 esel que presenta mayores herramientas para crear grandes redes de ordenadores.Es encaminable y es imprescindible en Internet. Microsoft ha implementadotodas las caracterısticas de Netbios dentro del protocolo TCP/IP. Es el queobliga al mayor esfuerzo administrativo.

A.7.3. Elementos del protocolo TCP/IP

Una red de ordenadores esta compuesta de dos partes: la red fısica en sı y el pro-tocolo que utilizan los ordenadores para comunicarse entre sı. La red fısica esta com-puesta normalmente de una serie de subredes, a las que se conectan los diferentesequipos (ordenadores, impresoras...).

Esta red puede tener una topologıa muy variada. Actualmente existen dos tiposde topologıas:

Ethernet, que es del tipo bus, Token Ring, que tiene topologıa de testigo y uti-liza topologıa de bus con paso de testigo. El protocolo TCP/IP fue desarrolladoinicialmente para Ethernet , pero admite sin problemas las otras dos tecnologıas.Actualmente se esta imponiendo la tecnologıa Ethernet en las redes pequenas, so-bre todo sobre cableado de par trenzado (10 Base T), y por su bajo coste y buenrendimiento.Normalmente una red tıpica estara compuesta por una serie de orde-nadores 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 otrasredes o al resto de la Internet a traves de puentes, encaminadores y otros tipos deenlaces.

El protocolo TCP/IP permite identificar cada elemento de la red y proporcionalos mecanismos para el intercambio de informacion entre estos elementos.

El protocolo TCP/IP esta formado por un protocolo generico de envıo y recepcionde 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 deellos, el protocolo TCP (Transmission Control Protocol), da nombre, junto con el IP,al protocolo TCP/IP. A su vez estos protocolos pueden incluir subprotocolos dentrode ellos. Esto se vera claramente en el protocolo TCP.



Cada paquete enviado a traves de la red tiene un formato especıfico. Si usamosel protocolo Ethernet de transmision, cada paquete esta compuesto de una cabeceraEthernet y de un campo de datos. La cabecera Ethernet origen y la de destino. Lasdirecciones Ethernet estan compuestos por un numero de 6 bytes. Este numero esasignado a cada tarjeta de manera unica. Cuando dos ordenadores de la red debenintercambiar 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 soloatienden a aquellos paquetes cuya direccion destino coincide con su direccion Ether-net. Existe un metodo para que una tarjeta envıe paquetes a todos los ordenadores.Este mecanismo es conocido como difusion de paquetes (Broadcast). Cuando la direc-cion destino son 6 bytes a 0 [cerciorarse si son a 0 o a 255], todas las tarjetas procesanel paquete. Este mecanismo es usado habitualmente por los protocolos de red paracomunicarse dentro de una red local, pero tiene el inconveniente de que sobrecarga lare, 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 campode datos contiene el paquete IP. Cada paquete IP esta compuesto de una cabecera yun campo de datos.

En el origen del protocolo TCP/IP, el TCP era el protocolo usado, pero luego seextendio el protocolo IP con nuevos protocolos como son el Protocolo de Control deMensajes de Internet (ICMP), los protocolos de resolucion de direcciones directo einverso (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, quees un numero de 4 octetos. En la red Internet no hay dos ordenadores con el mismonumero IP. En caso de necesidad se pueden asignar mas numeros IP a ese ordenador.Ademas cada direccion IP tiene un nombre asociado. Ese nombre esta formado por elnombre del servidor, que es unico dentro de una subred, y por el nombre del dominio,que identifica a la subred dentro del conjunto de las subredes de Internet. La formade asignar IP, nombres y nombres de dominio en Internet sigue una serie de criteriosque permiten el encaminamiento de los paquetes IP por la red y la traduccion denombres de ordenadores en numeros IP.

En Internet hay tres tipos de organizaciones de IP:

Organizaciones tipo A El primer octeto del IP es el mismo para toda la organi-zacion. 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. Laorganizacion dispone de direcciones para asignar. Este tipo de organizaciones



solo se asignan a paıses.

Organizacion tipo B Los dos primeros octetos del IP estan fijos. La organizaciondispone de 65536 direcciones IP para asignar. Suelen ser organizaciones detamano medio (universidades, grandes empresas).

Organizacion tipo C Se fijan los tres primeros octetos, dejando 256 posibles direc-ciones.Se utilizan en pequenos proveedores de servicios Internet (ISP).

Resolucion de nombres en el protocolo IP

Cuando dos ordenadores se quieren comunicar mediante el protocolo IP, debenconocer ambos sus respectivas direcciones IP. Por ejemplo, si se desea conectar desdeun ordenador a otro mediante un cliente del protocolo de transferencia de ficheros(FTP), debemos suministrar al cliente la direccion IP de destino. Dado que losnumeros IP son difıciles de recordar, en Internet se dispone de un mecanismo quepermite asociar nombres significativos a cada IP. Por ejemplo, el servidor de FTP deuna organizacion podrıa llamarse ftp.organizacion, donde “organizacion” es el nombredel dominio de dicha organizacion. Se puede emplear el archivo HOSTS de cada servi-dor para incluir en el una lista de direcciones IP con su nombre correspondiente. Deesta manera se puede proporcionar al cliente FTP el nombre ftp.organizacion comoIP de destino, y el protocolo IP se encarga de obtener el numero IP. A este mecanismose le llama resolucion de nombres.

Dado que mantener una lista de direcciones IP y nombres es complicado (habrıaque duplicar los archivos HOSTS por todos los servidores), en Internet se ha creado unmecanismo de resolucion de nombres automatico: el Servicio de Nombres de Dominio(DNS). En cada dominio hay al menos un servidor de nombres de dominio, quemantiene una lista de todas las direcciones IP del dominio y sus nombres asociados.Incluso podemos incluir varios nombres para una misma direccion IP (por ejemploen 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 denombres. Ademas en Internet, los servidores de nombres estan organizados de unaforma jerarquica, de manera que si el nombre buscado no pertenece al dominio delordenador, el servidor DNS puede buscar en otros servidores DNS de otros dominioshasta encontrar el servidor DNS del dominio destino, y de el recuperar la direccion IPde destino. Este mecanismo es generalmente muy rapido (menor que unos 2 segundosla busqueda con exito y unos 10 o 20 una busqueda con resultado negativo), ya quelos servidores DNS poseen mecanismos de cache.



A.7.5. El mecanismo de difusion (broadcast) en el protocoloIP

El protocolo IP al igual que el protocolo Ethernet tambien dispone de un mecanis-mo de difusion (broadcast), que permite enviar paquetes desde un ordenador a todoslos ordenadores de la red. Cada tipo de subred (A,B o C)tiene una mascara de subredasociada (255.0.0.0 para la A, 255.255.0.0 para la B y 255.255.255.0 para la C) quedetermina las direcciones IP que escuharan los paquetes de difusion. El protocolo dedifusion es ampliamente usado por Netbios sobre TCP/IP en la implementacion deMicrosoft, lo que permite emular al protocolo TCP/Ipde Windows el comportamientodel protocolo Netbeui.

El protocolo de difusion de paquetes tiene dos grandes desventajas: la primeraes que sobrecarga la red. Por ello en las redes basadas en Windows se introduce elprotocolo WINS, que intenta evitar en la medida de lo posible el envıo de paquetes dedifusion. La segunda desventaja es que los puentes y encaminadores que comunicanlas subredes, si entienden el protocolo IP, no permiten el paso de paquetes de difusion.

A.7.6. Implementacion del protocolo TCP/IP en NT

La implementacion del protocolo TCP/IP en NT persigue dos metas: imple-mentar 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 co-mo unico protocolo de la red, ya que los servicios de Netbios sobre TCP/IP permitenla comparticion de ficheros e impresoras en la red Windows.

La mayor parte de los clientes TCP/IP tienen version para NT. Se esta haciendoun gran esfuerzo a su vez para dotar a NT de todos los servidores tıpicos de Internet.Hay servidores de dominio publico de FTP, DNS, Gopher, TELNET, SMTP, POP3Y WEB, aparte de las propias incluidas en el NT Server. ademas existen versionescomerciales de dichos servidores, normalmente mas potentes y seguras.

A.7.7. Configuracion del protocolo TCP/IP en NT

Antes de proceder a la instalacion del protocolo TCP/IP en NT hay que averiguaruna 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 conocerningun parametro, ya que el protocolo se configurara automaticamente. Para anadir elprotocolo TCP/IP se pulsa el boton “Agregar software” dentro del cuadro de dialogo



“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 relaciona-dos. En estecuadro de dialogo nos aparecen las opciones que se pueden instalar. EnNt 4.0 se elige en Panel decontrol\Red\Protocolos\Agregar el Protocolo TCP/IP yelementos relacionados. Figura A.15.

En este cuadro se pueden senalar las opciones a instalar. Las mas comunes sonlas utilidades de conectividad (clientes ftp, telnet, finger, etc.), y son basicamente lasunicas necesarias. En este cuadro de dialogo tambien se puede seleccionar la config-uracion automatica vıa el protocolo DHCP. En NT 4.0 el cuadro de dialogo se hamodificado de manera que ahora la configuracion del protocolo TCP/IP esta organi-zada por bloques funcionales. En el caso de configuracion manual debemos conoceruna serie de parametros. El primero es la direccion IP del ordenador. En NT se puedeasignar una direccion IP a cada adaptador de red instalado, e incluso a un mismoadaptador se le pueden asignar varias direcciones IP. Esto ultimo se usa en Internetpara crear servidores “virtuales”. Luego se debe incluir una de las tres mascaras desubred posibles, para redes de tipo A, B o C. Si la red en la que se halla conectadoel ordenador esta conectada con otras redes vıa una pasarela (gateway), que puede



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 puertade enlace.

Si en la red hay servidores WINS, podemos incluir la direccion de un servidorWINS 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 deberıa coincidircon el que se le ha asignado en el servidor de nombres. En la lista “Orden de busquedadel servicio de nombres de dominio” debemos proporcionar una lista con las direc-ciones IP de los servidores de nombres que debe usar. Se pueden incluir servidoresde nuestra red y de otras, aunque suelen ser mas lentos. Debemos anadir a la casilla“nombre de dominio” el nombre de dominio de la subred local. Si no se proporcionaun dominio, el protocolo TCP/IP usa por defecto el dominio local.

Podemos anadir otros dominios para que se usen por defecto, anadiendo entradasa la lista “orden de busqueda del sufijo de dominio”.

Se pueden configurar varias opciones avanzadas para cada adaptador de red o pul-sando el boton avanzadas del cuadro de dialogo “Configuracion de TCP/IP”,en la seccion Direccion IP (ver figura A.16).

Tambien se puede activar el protocolo PPTP (Point to Point Tunneling Protocol)



Figura A.16: Protocolo TCP/IP, Direccion IP, Avanzado

que es el Protocolo de Tunel Punto a Punto. Este protocolo permite construir redesprivadas seguras dentro de redes de transmision publicas, siendo capaz de encapsularlos diferentes protocolos de red empleados en NT, como son NETBEUI, TCP/IP yIPX/SPX. Este protocolo utiliza cifrado de los paquetes, y algoritmos de clave publicaque hacen muy difıcil examinar los paquetes enviados a traves de una red como puedeser Internet. En este cuadro se pueden:

Asignar multiples direcciones IP a un mismo adaptador. Esto se usa cuandoun mismo adaptador de red debe poseer varias direcciones IP. En Internet esmuy comun el asignar multiples direcciones IP a un adaptador. El mejor usode este mecanismo consiste en reservar una direccion IP y un nombre de orde-nador para cada servicio Internet que se instale en el servidor. Si por ejemplose planea instalar un servidor FTP y un servidor WWW sobre el servidor, sedeben reservar dos direcciones separadas de la principal del servido, e instalarcada uno de los servicios en cada direccion. De esta manera es muy facil llevarse



todo es servicio a un nuevo servidor cuando por sobrecarga del servidor no sepuede hacer frente a las solicitudes efectuadas por los clientes de este servicio.

Anadir nuevas pasarelas o puertas de enlace para ese adaptador. Ver figuraA.17.

Figura A.17: Protocolo TCP/IP, Direccion IP, Avanzadas

Activar el agente de Proxy WINS, para lo cual la red debe disponer de servidorWINS. Un agente de proxy WINS es un equipo que permite que otros equiposque no estan configurados para acceder a un servidor WINS puedan acceder alos nombres contenidos en ese servidor WINS. Normalmente esta situacion se dacuando el servidor WINS esta en una red remota, por lo que los equipos de la redlocal que no tienen activado el cliente WINS no pueden acceder a los nombresregistrados en ese servidor. Al activar el proxy WINS las peticiones de busqueday registro de nombres Windows realizadas en modo local (vıa broadcast) sonatendidas y redirigidas sobre el servidor WINS por el servidor proxy WINS.

Configurar los parametros de red de Windows, que funcionan con el protocoloNetbios sobre TCP/IP. El archivo En NT 4.0 se ha introducido el agente Rele deDHCP. Normalmente el protocolo DHCP funciona sobre una red local, ya quese trabaja siempre en modo de difusion de paquetes (broadcast). En este modolos paquetes no pueden saltar los encaminadores, salvo que estos soporten elprotocolo de reenvıo de paquetes BOOTP. Si es necesario que en una red setenga 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 laconfiguracion dinamica en la red local. Se pueden anadir en el cuadro de dialogode Rele DHCP varios servidores DHCP, ası como configurar los parametros defuncionamiento del rele.



En el cuadro de dialogo de Enrutamiento (encaminamiento) se puede activarel encaminamiento IP, si se disponen de 2 o mas direcciones IP en el ordenador. Estasituacion es habitual cuando se disponen de dos tarjetas de red, cada una conectadaa una red fısica diferente. Ver figura A.18.

Figura A.18: Protocolo TCP/IP, Enrutamiento


Bibliografıa

[ANDRE] Andrews, Mark. Aprenda Visual C++ Ya. McGraw-Hill, 1999.

[BARBA] Barba Mir, C. A proposito del estandar DICOM 3.0. Hospital ClınicoUniversitario Lozano Blesa (Zaragoza).

http://www.hcu-lblesa.es/mane/noticia/didcom3.htm

[BATE] Bates, Jon. & Tompkins, Tim. Microsoft Visual C++ 6. 2000, PrenticeHall.

[BOBA00] Bobadilla, Jesus. & Sancho ,Adela. Comunicaciones y Bases dedatos con Java a traves de ejemplos. 2003, Ra-Ma

[BOBA01] Bobadilla, Jesus. Java a traves de ejemplos. 2003, Ra-Ma

[CASCA] Cascales, B. & Lucas, P. & Mira, JM. & Pallares, A. &Sanchez-Pedreno, S. LATEXuna imprenta en sus manos. 2000, ADI

[CEBAL99] Ceballos, F. Javier. Visual C++. Aplicaciones para Win32. RA-MA, 1999. ISBN: 84-7897-350-8

[CEBAL00] Ceballos, F. Javier. Visual C++. Programacion avanzada en Win32.RA-MA, 1999. ISBN: 84-7897-344-3

[DICOM] DICOM Standard . School of Psychology, University of Nottingham, Uni-versity 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. Guıa de integracion 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

http://www.hcu-lblesa.es/mane/noticia/didcom3.htm

http://www.psychology.nottingham.ac.uk/staff/cr1/dicom.html

http://www3.uji.es/~vcholvi/teaching/java/cap.12.1/Cap.12.1.html

http://www.dicomanalyser.co.uk/html/introduction.htm

BIBLIOGRAFIA Fernando Ballesteros Herranz

[JDK] API 1.4.1 .


[KRUG] Krugglinski, David J. & Shepher, G. & Wingo, S. Programacionavanzada 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. Administracion de sistemas Linux (La Biblia). 2000,Anaya

[LEMA] Lemay, Laura. & L. Perkins, Charles. Aprendiendo Java 1.1 en 21dıas. 1997, Prentice Hall

[NEMA] DICOM . NEMA, Suite 1847, 2003.

http://medical.nema.org/

[PAJ] Pajares, G. & de la Cruz, JM. & Molina, JM. & Cuadrado, J. &Lopez, A. Imagenes Digitales. Procesamiento practico con Java. 2003, Ra-Ma

[PASCU00] Pascual, J. & Charte, F. & J. Segarra, M. & De Antonio, A.& A. Clavijo, J. Programacion 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. Guıa completa de Microsoft WindowsNT 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 Imagingon the Internet. IEEE Communications Magazine, 1999.

http://www.comsoc.org/pubs/free/private/1999/jan/Tjandra.html



http://dicom.offis.de/index.php.en

http://medical.nema.org/

ftp://ftp-wjq.philips.com/medical/interoperability/out/DICOM_Information/CookBook.pdf

ftp://ftp-wjq.philips.com/medical/interoperability/out/DICOM_Information/CookBook.pdf

ftp://ftp.philips.com/pub/ms/dicom/DICOM_Information/CookBook.pdf

http://www.softlink.be/

http://www.tiani.com/JDicom/

http://www.comsoc.org/pubs/free/private/1999/jan/Tjandra.html

desarrollo de aplicaciones dicom para la gestión de ... · dedicado a mis padres juli y heliodoro,...

Documents