UNIVERSIDAD DE CÓRDOBA

Tamaño: px
Comenzar la demostración a partir de la página:

Download "UNIVERSIDAD DE CÓRDOBA"

Transcripción

1 UNIVERSIDAD DE CÓRDOBA Departamento de Química Analítica Departamento de Informática y Análisis Numérico DESARROLLO DE UN LIMS Y UNA PLATAFORMA PARA LA AUTOMATIZACIÓN DE PROCESOS ANALÍTICOS CONTINUOS BASADOS EN LA TECNOLOGÍA ORIENTADA A OBJETOS. DESARROLLO Y USO DE MÉTODOS QUIMIOMÉTRICOS PARA EL TRATAMIENTO DE DATOS ESPECTROSCÓPICOS Manuel Urbano Cuadrado Córdoba, Febrero de 2005

2

3 DESARROLLO DE UN LIMS Y UNA PLATAFORMA PARA LA AUTOMATIZACIÓN DE PROCESOS ANALÍTICOS CONTINUOS BASADOS EN LA TECNOLOGÍA ORIENTADA A OBJETOS. DESARROLLO Y USO DE MÉTODOS QUIMIOMÉTRICOS PARA EL TRATAMIENTO DE DATOS ESPECTROSCÓPICOS Por Manuel Urbano Cuadrado Los Directores, Fdo. María Dolores Luque de Castro, Catedrática del Departamento de Química Analítica, Universidad de Córdoba Fdo. Miguel Ángel Gómez-Nieto, Catedrático del Departamento de Informática y Análisis Numérico, Universidad de Córdoba Fdo. Pedro Pérez Juan, Doctor en Ciencias, Sección Químicas Trabajo presentado para optar al grado de Doctor en Ciencias, Sección Químicas

4

5 María Dolores Luque de Castro, Catedrática del Departamento de Química Analítica de la Universidad de Córdoba, Miguel Ángel Gómez-Nieto, Catedrático del Departamento de Informática y Análisis Numérico, y Pedro Pérez Juan, Doctor en Ciencias, Sección Químicas, en calidad de Directores de la Tesis Doctoral presentada por el Licenciado en Ciencias Químicas, con el título Desarrollo de un LIMS y una plataforma para la automatización de procesos analíticos continuos. Desarrollo y uso de métodos quimiométricos para el tratamiento de datos espectroscópicos, CERTIFICAN: Que la citada Tesis Doctoral se ha realizado en los laboratorios del Departamento de Química Analítica y del Departamento de Informática y Análisis Numérico de la Universidad de Córdoba y que, a su juicio, reúne los requisitos necesarios exigidos en este tipo de trabajos. Y para que conste y surta los efectos pertinentes, expiden el presente certificado en Córdoba a 21 de Enero de Fdo. María Dolores Luque de Castro Fdo. Miguel Ángel Gómez-Nieto Fdo. Pedro Pérez Juan

6

7 Agradecimientos A María Dolores Luque de Castro, Miguel Ángel Gómez-Nieto y Pedro Manuel Pérez-Juan, directores de este trabajo, por su constante labor y por haber puesto a mi alcance su conocimiento y experiencia. Especialmente a María Dolores Luque de Castro por haberme ofrecido la oportunidad de realizar esta tesis doctoral. A los muchísimos amigos y compañeros del Departamento de Química Analítica y del Departamento de Informática y Análisis Numérico de la Universidad de Córdoba, que me brindaron siempre su más sincera ayuda y sin los cuales todo se habría retrasado mucho. A toda mi gente de Elche (Alicante) por el interés y cariño que siempre me han mostrado. A mis amigos Manolo y Antonio por haberme hecho llorar tantas veces de risa; sois especies en extinción, y gracias por soportar mis ausencias y excusas. A mis hermanos Rafa y Paqui, por estar ahí, por todo. A mi abuela Araceli, por todos sus cuidados. A mis padres por ser los responsables de que esté hoy donde estoy a través de su ejemplo y trabajo, por haber entregado siempre toda su vida por mí y mis hermanos. Estoy orgulloso de vosotros. A toda mi familia en general por tantas y tantas cosas. A Noelia, mi rocheta, por todo su amor.

8

9 Índice

10

11 Índice Objetivos 1 Introducción Introducción Ingeniería del Software. Modelado orientado a objetos: el significado de UML y el Proceso de Desarrollo Unificado El lenguaje de programación Java La información como recurso. Oracle. SGBD basados en el modelo de datos objeto-relacional Quimiometría: modelos clásicos para diseñar experimentos, clasificar productos y predecir parámetros Química computacional: índices de similitud y huellas digitales Referencias 85 Parte experimental 103 Parte I: Informatización del proceso analítico y de la gestión y análisis de los datos producidos mediante el uso del paradigma orientado a objetos 105 Capítulo 1. Use of object-oriented techniques for the design and development of standard software solutions in automation and data management in analytical chemistry 107 Capítulo 2. An open solution for computer control of flow injection analyses in wine production monitoring 131 Capítulo 3. Trigger-bassed concurrent control system for automating analytical processes 151 XI

12 Manuel Urbano Cuadrado Tesis Doctoral Capítulo 4. Fully automated flow injection analyser for the determination of volatile acidity in wines 185 Capítulo 5. A fully automated method for in real time determination of lacasse activity in wines 201 Capítulo 6. JWisWine: a Java web information system for quality control in wineries 217 Parte II: Desarrollo de métodos quimiométricos y algoritmos para el desarrollo de modelos cualitativos y cuantitativos en química analítica 237 Capítulo 7. Ultraviolet-visible spectroscopy and pattern recognition methods for differentiation and classification of wines 239 Capítulo 8. Study of spectral analytical data using fingerprints and scaled similarity measurements 265 Capítulo 9. Near infrared reflectance spectroscopy and multivariate analysis in enology: determination or screening of fifteen parameters in different types of wines 295 Capítulo 10. Comparison and joint use of near infrared spectroscopy and fourier transform mid infrared spectroscopy for the determination of wine parameters 315 Discusión de los resultados 333 Conclusiones 345 XII

13 Índice Anexo: comunicaciones a congresos 351 XIII

14

15 Objetivos

16

17 Objetivos Las últimas tendencias en metodología y tecnología informáticas poseen las características idóneas para la construcción de software que supere su tradicional dependencia de la variabilidad de la información que exhibe y requiere su entorno, de la diversidad de configuraciones hardware y sistemas operativos disponibles, y de la forma aleatoria de desarrollar productos software. Uno de los grupos de investigación (Ingeniería del Software, Conocimiento y Bases de Datos) en los que se ha desarrollado el trabajo recogido en esta Memoria ha empleado metodologías como la ingeniería de sistemas y los paradigmas evolutivo y orientado a objetos, junto con herramientas como Oracle, Java, XML, etc., para el desarrollo de soluciones software en diversas áreas. Este grupo de investigación también ha desarrollado en los últimos años algoritmos basados en cálculo de similitudes para el estudio de compuestos químicos y su recuperación de bases de datos. El otro grupo (Innovaciones en Sistemas Continuos y Discontinuos para la Automatización de Procesos Analíticos) donde se ha desarrollado parte de la investigación aquí presentada ha puesto a punto un gran número de métodos continuos de análisis. Estos métodos han supuesto la simplificación, reducción y automatización de las etapas previas a la medida en el conjunto del proceso analítico, aportando las ventajas de eliminación de errores, reducción del tiempo de análisis y del consumo de reactivos, etc. El grupo también ha usado los métodos quimiométricos clásicos para la determinación multiparamétrica y para la clasificación de muestras a partir de la información espectral. La Memoria de tesis aquí presentada ha tenido dos objetivos genéricos principales, a saber: (1) ensamblar parte de los logros alcanzados por ambos 3

18 Manuel Urbano Cuadrado Tesis Doctoral grupos de investigación para llevar a cabo la informatización del proceso analítico y la gestión de la información que proporciona utilizando las últimas tendencias computacionales y, (2) usar y comparar los métodos quimiométricos convencionales con otros basados en el cálculo de similitudes a partir de la información espectral. Estos objetivos genéricos se han concretado en los siguientes objetivos específicos: 1) Diseño y desarrollo de un sistema de automatización del proceso analítico dotado de las siguientes características: Abierto a cualquier tipo de análisis, con independencia de la instrumentación y método analítico utilizado. Orientado al usuario ( el químico ) que lo utilizará, de forma que la traducción del procedimiento analítico a órdenes computacionales no requiera un aprendizaje especial. Operativo en cualquier entorno hardware, de forma que pueda utilizarse con los diferentes recursos computacionales que existan en los laboratorios analíticos. Seguro en la adquisición de los datos relacionados con el proceso de análisis, de forma que esta información pueda comprobarse, validarse, analizarse y almacenarse para su posterior tratamiento. 2) Diseño y desarrollo de un sistema de información para la gestión y análisis de la información analítica generada en procesos de producción o elaboración. El sistema de gestión deberá considerar otros aspectos relevantes en el proceso analítico, tales como el instrumental con el que se realiza el análisis, las personas implicadas, la validación de los resultados, etc. Las características más destacables que deberá satisfacer el sistema son las siguientes: 4

19 Objetivos Escalable, de forma que esté abierto a la gestión y análisis de la información analítica de cualquier proceso de producción y a los cambios que pueda sufrir la información a monitorizar. Operativo en cualquier entorno hardware y sistema operativo disponibles en la empresa. Integrado con el sistema de automatización desarrollado, de forma que entienda la información suministrada por este sistema para su posterior tratamiento. Orientado al usuario no especializado que lo utilizará, de forma que la interacción con el sistema sea similar al proceso manual que se lleva a cabo en la empresa. Seguro y robusto en el manejo de la información, de forma que la información almacenada no esté sujeta a pérdidas, robos o manipulaciones malintencionadas. Rentable para la empresa, de forma que las utilidades integradas en el sistema aporten a los usuarios la reducción del tiempo invertido en las tareas diarias de gestión de la información analítica. Por otro lado, el sistema también debe poseer un conjunto de utilidades de análisis de la información almacenada para facilitar a los responsables el conocimiento suficiente para la correcta toma de decisiones. 3) Diseño de nuevos modelos y algoritmos orientados a encontrar nuevas soluciones quimiométricas que puedan utilizarse en el análisis de la información espectral. Estas soluciones se compararán con los métodos quimiométricos convencionales. La información espectral que se usará será la correspondiente a las zonas ultravioleta, visible, infrarrojo cercano e infrarrojo medio y se aplicará en el campo enológico. La validación de los métodos y algoritmos desarrollados será diferente si el objetivo es cuantitativo o cualitativo. Para métodos cuantitativos se emplearán parámetros tales como el coeficiente de determinación, el error en la 5

20 Manuel Urbano Cuadrado Tesis Doctoral calibración y en la validación, la correlación con el método de referencia usado, etc. Para métodos cualitativos, la bondad de los algoritmos será función del grado de agrupación de muestras y del porcentaje de clasificación en la validación. 6

21 Introducción

22

23 Introducción 1. Introducción Uno de los pilares básicos de la sociedad actual es la información. La dimensión que adquieren los avances económicos, sociales y culturales deriva, en gran parte, de las cualidades de la información y de su accesibilidad. El diccionario de la Real Academia Española de la lengua define información, entre otras acepciones, como comunicación o adquisición de conocimientos que permiten ampliar o precisar los que se poseen sobre una materia determinada. Desde un punto de vista práctico, la información puede ser considerada como el resultado de un proceso de gestión y análisis de datos. Los datos son registros de hechos, observaciones, valores, etc. y constituyen la entrada al proceso. La Fig. 1 visualiza el dinamismo implícito en el concepto de información. La importancia de la disponibilidad de una información de calidad es cada vez más explícita debido al reconocimiento de que la planificación y toma de decisiones en un ente dado está basada en la información a la que tiene acceso o la que ha sido capaz de elaborar. Gestión Análisis Datos Proceso Información Fig. 1. Proceso dinámico de síntesis de información. 9

24 Manuel Urbano Cuadrado Tesis Doctoral Diversos autores elevan a revolución el proceso experimentado por la sociedad como consecuencia del advenimiento de la era de la información. Así, se considera que esta revolución no sólo ha acelerado el flujo de información, sino que ha transformado la estructura profunda de la decisión de la que dependen nuestras acciones [1,2]. Cuando se habla de cualidad y calidad de la información se hace referencia a características muy genéricas y, normalmente, difíciles de cuantificar. Adjetivos como relevante, precisa, completa, y frases como destinada al receptor adecuado, disponible en un tiempo adecuado, detallada a un nivel entendible por el usuario, etc. [3,4], son algunos ejemplos del lenguaje impreciso en este ámbito. Cada área de conocimiento emplea una definición distinta de las cualidades de la información que, normalmente, consiste en un refinamiento de la genérica. Además, utiliza una serie de patrones de medida o evaluación para adaptar el concepto de información a su entorno y aplicación. La especialización de este concepto en la química analítica se expone a continuación. 1.1 Información y química analítica Obtener información analítica apropiada es de suma importancia para la caracterización de materiales, seguimiento de procesos de producción, detección de fraudes, etc. La química analítica es una disciplina que tiene como objetivo la síntesis de información (bio)química de interés mediante la aplicación de métodos de análisis a un objeto o sistema. Malissa definió la química analítica como la ciencia que hace evidente, asequible, verdadera y útil la información (bio)química latente, intrínseca de un objeto o sistema. Cuando la calidad de la información suministrada por el proceso analítico es mala, las decisiones tomadas pueden generar problemas económicos-sociales. Tölg estimó, en 1984, que las pérdidas económicas en Alemania derivadas de la mala calidad de la información analítica ascendían a 6000 millones de marcos. 10

25 Introducción La calidad de la información analítica puede considerarse desde diferentes puntos de vista. Teóricamente, la calidad es la conjunción de unas propiedades que permiten clasificar cierta información como peor, mejor o igual que otra. Al ser los datos los pilares que sustentan la información, la exactitud y representatividad de aquéllos son los dos indicadores más importantes en la caracterización teórica de la calidad analítica. Los indicadores se corresponden con las propiedades analíticas supremas (caracterizan un resultado analítico), que están a su vez soportadas en las propiedades básicas precisión, sensibilidad y selectividad (que caracterizan el proceso analítico). En el cálculo de la incertidumbre (la reducción de ésta) en química analítica, como en cualquier ciencia informativa, se usan los indicadores exactitud y precisión. Desde un punto de vista práctico, la calidad debe estar orientada a la satisfacción del usuario o cliente, adquiriendo importancia propiedades analíticas llamadas productivas, como la rapidez y los costes. De igual forma que el primer enfoque de la calidad analítica, la veracidad de la información sigue teniendo una importancia clave en la calidad, sólo que el grado requerido viene impuesto por el cliente. Así surgen los conceptos de calidad externa y calidad interna. El cliente y el laboratorio analítico participan de diferente forma en estos dos tipos de calidad. La calidad externa está asociada a la exigencia y a la percepción de las características de la información analítica por parte del cliente (así, se habla de calidad requerida y calidad percibida). Por otro lado, la calidad interna siempre es el producto que la política y la gestión de la calidad ofrecen a través del laboratorio o la organización de la que dependen. Se suele llamar calidad alcanzada. El resultado de un análisis es la consecuencia del proceso analítico, también llamado proceso de medida químico (PMQ), que se define como el conjunto de operaciones que separa el sistema en estudio (sin muestrear, sin medir y sin tratar) de los resultados generados y expresados según los requerimientos del problema analítico planteado. Esta definición, dada por 11

26 Manuel Urbano Cuadrado Tesis Doctoral Chalmers y Bailescu [5], es de carácter genérico y representa el proceso analítico como una caja negra. Si se analiza esta caja negra con mayor detalle se pueden distinguir diferentes etapas que componen el proceso analítico y el aumento del número de entradas a la caja, no siendo considerada la muestra como única entrada. Este análisis se plasma en la Fig. 2. Proceso Analítico Sistema en Estudio Operaciones previas Detección Adquisición y tratamiento de datos Resultado Instrumentación Información requerida Metodología de medida Herramientas Reactivos Normas y guías INFORMÁTICA Fig. 2. Esquema del proceso analítico. La primera etapa del proceso la componen las operaciones previas encaminadas a la preparación de la muestra para la medición. La etapa intermedia es la detección, en la que se ponen de manifiesto las características físico-químicas de los analitos. Por último, la adquisición y el tratamiento de datos para la generación del resultado analítico completan el proceso analítico. En cuanto a las diferentes entradas al proceso analítico, la información requerida, la metodología de medida y las herramientas también han de tenerse en cuenta, además del sistema a estudiar, que proporcionará la muestra, tal como aparece en la Fig. 2. Estas entradas actúan a modo de condicionantes del proceso analítico, afectando por tanto a sus propiedades analíticas. 12

27 Introducción La importancia de la información requerida ya ha sido comentada anteriormente al hablar de la calidad analítica. Viene impuesta por las personas u organizaciones que van a utilizarla con diversos fines. El papel de la metodología de medida también es de suma relevancia debido a que su desarrollo tiene como fin extraer del sistema en estudio la información con unas propiedades idóneas. Por último, los diferentes tipos de herramientas constituyen los pilares técnicos y materiales que sustentan el proceso, haciendo posible que se pueda llevar a cabo. Las herramientas son los aparatos e instrumentos empleados para la preparación de la muestra y para la medición de la señal de interés, respectivamente, además de los reactivos, las normas de calidad de los laboratorios analíticos, y las aplicaciones informáticas. Este último tipo de herramientas es el utilizado en esta Tesis, ya que la investigación desarrollada es un intento tanto de introducir la tecnología informática más reciente en las diferentes partes del proceso analítico, como de evaluar los efectos de estas últimas tendencias en la química analítica. 1.2 La informática y sus usos en química analítica La Real Academia Española de la Lengua define la informática como el conjunto de conocimientos científicos y técnicas que hacen posible el tratamiento automático de la información por medio de ordenadores. A pesar de que el hombre siempre ha buscado la forma de sustituir su participación en tareas de rutina (el desarrollo de las máquinas ha seguido un curso paralelo a la historia del ser humano), la implantación de sistemas eficientes para la automatización de la capacidad de razonar y tratar la información empezó a ver la luz a mediados del siglo pasado con el advenimiento de la primera generación de computadoras [6]. La carencia de la tecnología apropiada impidió hasta entonces materializar modelos formales de cálculo, que ya surgieron en la Grecia del siglo IV a. C. y que continuaron hasta 13

28 Manuel Urbano Cuadrado Tesis Doctoral la descripción de la máquina teórica por el matemático británico Alan Turing en 1936 [7]. A partir de la primera generación de ordenadores, su evolución ha seguido un ritmo vertiginoso hasta el punto de que se habla de hasta cuatro generaciones de ordenadores [8]. En estas cuatro etapas la caducidad y aparición de conceptos relacionados con la tecnología, estructura, sistema operativo, lenguaje de programación, base de datos, etc., ha sido una constante, de forma que términos como trabajos por lote, acceso secuencial a registros, tarjetas perforadas, etc., resultan ya lejanos en el desarrollo de la computación; mientras que conceptos como multiprogramación, base de datos relacional, clusters, Java, Internet, etc., tienen un diferente grado de cercanía a la informática de nuestros días. Los programas informáticos, formados por un conjunto de datos, instrucciones y operaciones aritméticas y lógicas, han encontrado un uso extenso en todas las áreas sociales. Así, no es posible el entendimiento del estado actual de muchas áreas de conocimiento sin el uso de estas herramientas, que, por otra parte, siguen un proceso constante de desarrollo e investigación de nuevas utilidades. La química analítica no se ha sustraído a la adopción de las ventajas que ofrece la computación. La aplicación de los métodos analíticos hace que la información química de los sistemas en estudio se ponga de manifiesto. Como se ha comentado anteriormente, el proceso analítico ofrece un resultado tras una serie de operaciones en la muestra empleando diversas herramientas, entre las que se encuentra la informática. Pero la química analítica moderna ha traspasado los límites del laboratorio para entrar en contacto con los problemas económicos-sociales que la rodean, requiriéndose un nuevo papel de la información analítica diferente a la concepción clásica de la entrega de resultados. Con este fin, el proceso analítico necesita una continuación a partir de la salida de resultados, resolviéndose con un enlace a un proceso de información, denominado Proceso de Información Automatizado, si en él intervienen los 14

29 Introducción ordenadores. La Fig. 3 muestra el nuevo proceso de información analítica (resultante de la unión del proceso de información automatizado al proceso analítico clásico) y la reubicación de las herramientas informáticas en este nuevo escenario. Muestra Control Operaciones previas Control Adquisición Detección Proceso analítico clásico Adquisición y tratamiento de datos INFORMÁTICA Resultado Introducción y manipulación Gestión de datos Consultas Estructuradas Extracción de datos Proceso de información automático Obtención de datos no estructurados Análisis de datos Información Fig. 3. La informática en el proceso de información analítica. 15

30 Manuel Urbano Cuadrado Tesis Doctoral La informática en el proceso analítico clásico La informática participa, aunque con un distinto grado de extensión, en todas las etapas del proceso analítico clásico. El manejo automático de los muestreadores y aparatos utilizados en las operaciones previas se realiza a través del software adecuado [9-17]. El flujo de información de estos programas es unidireccional desde el ordenador hasta los aparatos debido a que éstos no proporcionan información de interés para la resolución del problema analítico. Existe en la bibliografía un escaso número de estos programas a causa de que esta etapa es la más difícil de automatizar, siendo hoy en día uno de los frentes de investigación en química analítica. Su interés radica en el aumento de la calidad analítica que supone la eliminación de la participación humana en esta etapa, que es una de las que introducen mayor error en el resultado final. El uso del ordenador en la etapa de detección ya conlleva un flujo bidireccional de información. Por un lado, los programas permiten el control de instrumentos mediante la selección y ajuste de parámetros de medida, como pueden ser la longitud de onda en un espectrofotómetro, el voltaje en un equipo de electroforesis capilar o en un potenciostato, etc. Por otra parte, y a consecuencia de la diferencia entre aparatos e instrumentos, para la recogida de los datos proporcionados por el instrumento se hace uso, casi en todos los casos, de la informática. Aunque la adquisición de datos ya entraría dentro de la tercera etapa del proceso analítico clásico, desde el punto de vista informático existe una simbiosis con la de detección. Así pues, aunque a nivel conceptual constituyan distintas etapas, a nivel de funcionalidad pueden ser tratadas como una única solución software [18-28]. Incluso existen trabajos donde las etapas de tratamiento de muestra y las de detección y adquisición de datos se controlan por ordenador [29,30]. Para la tercera etapa, correspondiente al tratamiento de datos, se hace uso de la informática en toda la acepción de su definición, pues se usan unos datos 16

31 Introducción como entrada a una aplicación software para, a través de un algoritmo, generar un resultado [31-39]. Los programas encargados de la detección y de la adquisición de la señal en los instrumentos pueden llevar incorporados un módulo para el tratamiento de los datos [40]. Una aplicación software para el tratamiento de datos independiente de la adquisición sería otra modalidad [41,42]. Son de destacar algunas ventajas de la primera opción. La más importante de todas es la compatibilidad del formato para los datos entre la adquisición y el tratamiento, evitando el problema de tiempo que conlleva la conversión de un formato a otro, cuando no la imposibilidad de hacerlo. Otras ventajas pueden ser la compatibilidad con las propias configuraciones de hardware y sistema operativo que ofrece la opción continua, la parecida estructura de las interfaces gráficas de usuario, etc. Las aplicaciones de tratamiento de datos independientes de la adquisición de la señal ofrecen un mayor espectro de métodos de tratamiento, ya que los programas están construidos a partir de unos requerimientos generales sobre procesamiento de datos, a diferencia de la aplicabilidad de programas para el control, adquisición de la señal y tratamiento de datos de un determinado tipo de instrumento. El tratamiento de los datos puede dividirse en dos grupos atendiendo al fin perseguido por los diferentes métodos de procesamiento: filtrado y reducción del ruido de la señal analítica por un lado, y análisis de los datos para la obtención de un resultado por otro. En lo que respecta al primer grupo, un ejemplo representativo es el filtrado de la señal digital, para el que es imprescindible el uso del ordenador. Los filtros analógicos, que también juegan un papel importante en el tratamiento de la señal y suelen ser usados en combinación con los filtros digitales, no van a considerarse. Los filtros digitales son algoritmos desarrollados para la eliminación del ruido, que han encontrado aplicabilidad en la resolución de muchos y variados problemas analíticos. La señal analítica está compuesta por dos partes: una parte 17

32 Manuel Urbano Cuadrado Tesis Doctoral de interés que contiene la información química, y una parte aleatoria causada por deficiencias en la detección, que no sólo no tiene información de interés, sino que, además, enmascara la información analítica. La parte aleatoria se conoce como ruido. Se distinguen dos tipos de técnicas para eliminar el ruido: de dominio del tiempo y de dominio de la frecuencia. Las primeras aprovechan el carácter aleatorio del ruido y están soportadas en algoritmos que, de una manera u otra, realizan un promediado de puntos consecutivos o un ajuste por mínimos cuadrados [43-45]. Suele distinguirse entre filtros de ventana fija y filtros de ventana móvil. Las técnicas de dominio de la frecuencia están basadas en la diferencia que ésta exhibe para la señal de interés y el ruido. Las diferentes modalidades de la transformada de Fourier se encuadran en este tipo [46-49]. Las técnicas basadas en el filtrado de Kalman [50], normalmente usadas para la multideterminación de componentes mediante el empleo de técnicas cinéticas, también se han usado para la eliminación del ruido [51,52]. El otro gran grupo de tratamiento de datos engloba los procesamientos de alto nivel, y tienen la finalidad de producir un resultado analítico tras el procesamiento y análisis de datos. Las herramientas informáticas desarrolladas están soportadas en los numerosos métodos estadísticos usados por el químico analítico para cuantificar, clasificar, e incluso dilucidar aspectos estructurales de los analitos. Wold, en 1972, fue el primer investigador que denominó Quimiometría al uso de métodos estadísticos, matemáticos y otros de lógica formal para el diseño y selección de experimentos químicos y/o para la obtención de la máxima información química relevante a partir de datos químicos [53]. Hoy en día, muchos autores, no sólo en química analítica, sino en química farmacéutica, química de los alimentos, etc., la consideran como una ciencia esencial para soportar los métodos analíticos [54-56]. 18

33 Introducción La informática en el proceso analítico actual. El nuevo papel de la información analítica Como se ha comentado anteriormente, la labor de la química analítica hoy en día no se circunscribe a la entrega de resultados. En la Fig. 3 se puede observar que éstos son la entrada al sistema de procesamiento de la información, que es la segunda parte de lo que en la investigación realizada se ha denominado proceso de información analítica. Por lo tanto, los resultados de los análisis son la materia prima para la síntesis de información. Toda la aplicabilidad de los programas informáticos a las operaciones previas, a la detección de la señal, y a la adquisición y tratamiento de datos sigue estando vigente en la reubicación de la informática en el nuevo proceso de información analítica. En los últimos años ha surgido el concepto de LIMS (las iniciales de la expresión anglosajona Laboratory Information Management System ) que abarca los sistemas informáticos para la gestión y el análisis de datos analíticos. Su definición puede ser derivada de las muchas usadas para Sistema de Información. Andreu et al. [57] definieron Sistema de Información como: Un conjunto formal de procesos que, operando en una colección de datos estructurada según las necesidades de la empresa, recopilan, elaboran y distribuyen la información (o parte de ella) necesaria para las operaciones de dicha empresa y para las actividades de dirección y control correspondientes, es decir, las decisiones para desempeñar su actividad de acuerdo a su estrategia de negocio. Para definir LIMS, lo vamos a hacer añadiendo una serie de matices que particularicen la definición dada de un sistema de información a la de LIMS. Así, cuando se habla de empresa, ésta se corresponde con un laboratorio de análisis químico, y por tanto, la colección de datos estructurados será de resultados analíticos, equipos del laboratorio, analistas, etc. En segundo lugar, las 19

34 Manuel Urbano Cuadrado Tesis Doctoral operaciones de la empresa tienen que matizarse de diferente forma según que el laboratorio sea independiente o pertenezca a una organización de mayor dimensión, de la que el laboratorio es un departamento más. Incluso cuando el laboratorio es independiente, podría ser un laboratorio de referencia o control perteneciente al ente público o un laboratorio privado que ofrece un servicio de análisis, que generalmente suele cubrir las necesidades analíticas de un determinado campo, ya sea clínico, agrario, ambiental, etc. Así, las operaciones para las que será necesaria la información y el flujo de ésta son dependientes del tipo de laboratorio. Cuando un laboratorio es una parte de un ente de mayores dimensiones, la información generada sigue un camino vertical. Cuando es ascendente empieza en el laboratorio y termina en la dirección técnica del ente global, incluso llegando a la dirección general, pero con un nivel elevado de transformación y siempre con características indicativas para su uso táctico y estratégico. Por tanto, suele ser un paso desde los datos (con el calificativo producidos ) a la información (con el calificativo elaborada ). Por otro lado, cuando la información es descendente adquiere matices imperativos para la síntesis de nuevos datos requeridos por la organización de la empresa. Entonces, el proceso es el contrario y se pasa de la información (con el calificativo requerida ) a los datos (con el calificativo necesarios ). Es obvio que éste es el flujo de información entre el laboratorio y la dirección, habiendo otros, por ejemplo, entre la dirección y el departamento de producción, con una dirección descendente y con un contenido dependiente del ya explicado. Cuando el laboratorio es independiente y estatal o regional, el flujo suele ser también vertical, pero cambia el destino de la información, apareciendo la administración en el lugar de la dirección de la empresa. Por el contrario, cuando el laboratorio es independiente y privado el camino que sigue la información es horizontal entre el laboratorio y el cliente. Éste requiere una información que generalmente necesita un menor grado transformación después de la salida del proceso analítico clásico, es decir, después de la generación del resultado. 20

35 Introducción Cuando la información requerida es cualitativa (no implicando este término la respuesta binaria si/no, referida a la presencia de un compuesto ) se alcanza el mayor grado de elaboración necesaria. Esto es debido a que el cliente solicita respuestas sobre la pertenencia o no del material en estudio a una determinada clase (por ejemplo, material adulterado, con un estándar de calidad establecido por la ley, etc.) cuyo criterio se basa en la evaluación de una serie de parámetros analíticos. Aunque la definición que se ha dado de Sistema de Información no incluye ninguna referencia a los medios informáticos, es difícil no relacionarlos. Normalmente, se diferencia el Sistema de Información Total del Sistema de Información Automatizado porque, en el último, la informática sí está considerada como la herramienta principal Tipos de aplicaciones informáticas para el sistema de procesamiento Se van a distinguir dos tipos de aplicaciones: la conocida como MIS (de las siglas Management Information System) y los sistemas de ayuda a la decisión, conocidos como DSS (de las siglas Decission Support System). Estos sistemas representan diferentes niveles en la funcionalidad de los programas informáticos empleados (ver el proceso de información en la Fig. 3). También suele considerarse un nivel más bajo que el de los MISs, que abarca las aplicaciones software para la realización de tareas repetitivas, operativas y transaccionales con un número grande de datos. Los MISs en química analítica ayudan a los usuarios en la gestión de la información química, incluyendo introducción de resultados, codificación de muestras, control de equipos, inventario de reactivos, etc. [58-66]. Aunque tienen cierta hibridación con los sistemas de nivel más bajo (ya que muchas de estas tareas son repetitivas), son programas que ayudan a la toma de decisiones en tareas de gestión al proporcionar informes sobre la carga de trabajo del laboratorio, el uso de un instrumento, los análisis realizados por un determinado analista, etc. Se basan en consultas estructuradas a la base de datos. 21

36 Manuel Urbano Cuadrado Tesis Doctoral En cuanto a los DSSs, su uso en química analítica ayuda a la toma de decisiones que, estratégicamente, realiza la dirección de una empresa a raíz de la información química contenida en su base de datos. Esta ayuda a la decisión se basa en el análisis de los datos proporcionados por consultas que no siguen criterios preestablecidos [67-74]. Por ejemplo, conocer la semana, en un año cualquiera, en la que un determinado parámetro mostró los valores máximos, saber qué zona dentro de una denominación de origen de vinos es la que proporciona la uva con mayores concentraciones de ácido glucónico, etc. Estos sistemas son clave para el objetivo de la química analítica moderna de no limitarse sólo a la entrega de datos. 2. Ingeniería del software. Modelado orientado a objetos: el significado de UML y el Proceso de Desarrollo Unificado La participación de la informática en el proceso analítico se materializa en el uso de aplicaciones informáticas para la automatización (control de instrumentos y aparatos) y para el procesamiento y análisis de datos (adquisición y filtrado de la señal, tratamiento de datos, y gestión y análisis de la información analítica). Los programas informáticos, que anteriormente se han definido de una forma trivial como un conjunto de datos, instrucciones y operaciones aritméticas y lógicas, son productos que, en la mayoría de los casos, surgen después de una fase de desarrollo compleja. Existe una serie de condicionantes que diferencian de modo cualitativo y cuantitativo el producto software de otros derivados de un proceso de producción clásico o de un producto de servicios. Se van a comentar de manera breve algunos de ellos. En primer lugar, la variabilidad constante del entorno con el que interactúan los programas afecta considerablemente a la forma de construir aplicaciones informáticas. Los datos y la información a elaborar con éstos están influenciados, en un mayor o menor grado, por cambios en los requisitos funcionales. Por tanto, el desarrollo de un programa siempre tiene que estar 22

37 Introducción soportado en un diseño que haga a las estructuras de datos y a los procesos independientes (en la mayor dimensión posible) de la variabilidad intrínseca de los requisitos funcionales de la información. En segundo lugar, el soporte físico y tecnológico para las soluciones software está caracterizado, de igual forma que los requisitos funcionales, por una estructura dinámica. La compatibilidad entre el triángulo formado por el software, el hardware y el sistema operativo, indispensable para el uso de la computación, suele ser breve en el tiempo debido a la asimetría en el desarrollo y evolución de estos tres componentes. De nuevo el desarrollo de sistemas informáticos busca el concepto de independencia, esta vez relacionado con el triángulo anteriormente citado. Por último, la complejidad intrínseca en el mantenimiento de un programa informático también hace que su desarrollo sea especial. Los fallos del software no se pueden solucionar con un simple recambio de piezas, sino que son derivados del diseño del programa y se materializan en el código ejecutable, debiendo analizarse para su solución la estructura y el comportamiento del sistema, tanto a nivel de diseño como de implantación. Una aproximación para paliar este inconveniente es el diseño y desarrollo del sistema con un enfoque modular encaminado a construir componentes con una interfaz para la unión entre ellos. Además de la facilidad que este enfoque ofrece para la localización de los fallos, la reusabilidad del código aumenta debido a la consideración de diferentes componentes. Los condicionantes comentados hacen necesario que la forma de desarrollar programas no sea aleatoria, ni específica para una determinada aplicación. De esta necesidad surge el concepto de ingeniería del software que, como cualquier otra ingeniería, utiliza el conocimiento científico para la construcción de productos o servicios de interés para la sociedad. En el caso de la ingeniería del software, el conocimiento utilizado es sobre computación y hace hincapié en la forma disciplinada de desarrollar productos software que superen 23

38 Manuel Urbano Cuadrado Tesis Doctoral los inconvenientes citados, alcanzando el grado de provecho adecuado para el hombre. 2.1 Ingeniería del software. Proceso de desarrollo de productos software Muchas son las definiciones dadas del concepto de Ingeniería del Software. Se recoge la dada por Boehm en 1976 [75]: Es la aplicación práctica del conocimiento científico en el diseño y construcción de programas de computadora y la documentación asociada requerida para desarrollarlos, operarlos y mantenerlos. Se conoce también como desarrollo de software o producción de software. Analizando en detalle la definición se pueden observar dos conceptos diferentes: el producto y el proceso. Sobre el producto, la solución software, cabe destacar que los programas informáticos son muy recientes en la historia (se empezaron a desarrollar y a usar a partir de los años 50 del siglo pasado); de lo que deriva el hecho de que la ingeniería del software sea una disciplina que está por desarrollar en una gran parte [76]. Los siguientes pasos a dar en este desarrollo están encaminados a la reducción de las muchas diversificaciones que existen todavía en esta área, unificando los criterios sobre el proceso para llegar a conseguir un producto software de calidad. El proceso se refiere a la metodología usada para conseguir el producto. No se debe confundir proceso con ingeniería del software, pues ésta, además de la metodología, emplea la tecnología y herramientas automáticas disponibles. Por tanto, los métodos sustentan el desarrollo de software al definir técnicamente los pasos a seguir, que normalmente suelen ser: el análisis de requisitos, el diseño, la codificación, la implantación y pruebas y, por último, el mantenimiento. A la hora de estudiar el proceso suele hacerse desde dos puntos de vista comunes en muchos libros de ingeniería del software. Éstos son, en primer lugar, un acercamiento a los diferentes tipos de procesos (también llamados modelos o paradigmas), para continuar con una descripción de las fases comunes que 24

39 Introducción componen el proceso de desarrollo, independientemente de su tipo [77,78]. De forma no detallada se van a exponer tanto los modelos como las fases del proceso para, después, poder describir el modelado orientado a objetos y sus cualidades, que lo han hecho idóneo para la utilización en la investigación recogida en esta Memoria Tipos de procesos (paradigmas de ingeniería del software) El proceso de desarrollo puede verse de una forma simple como la separación entre una funcionalidad requerida y basada en el ordenador (en el caso de la química analítica versará sobre control de instrumentación, gestión y análisis de datos) y un producto aportado para cumplir esos requisitos funcionales. Existe cierta hibridación entre el proceso y el producto entregado debido a que la fase de mantenimiento se realiza en este último, tal como puede verse en la Fig. 1.4, donde se describe de forma gráfica el proceso de desarrollo de software y su entorno. En ella se observa cómo en el proceso participan la metodología, las herramientas y el conocimiento sobre informática. Existen diferentes tipos de procesos que exhiben una estructura interna particular, siendo los puntos inicial y final siempre los mismos: los requisitos y el producto. Se van a comentar a continuación los más importantes. Herramientas PROCESO DE DESARROLLO Conocimiento ordenadores Análisis del sistema Requisitos funcionales basados en ordenador Análisis de requisitos Diseño Codificación Implantación y pruebas Mantenimiento Producto software Metodología Fig. 4. El proceso de desarrollo de software. 25

40 Manuel Urbano Cuadrado Tesis Doctoral El primer tipo es el Modelo Lineal Secuencial [79], en el que se considera el proceso como una encadenación lineal de las diferentes fases del proceso: análisis del sistema donde se va encuadrar el producto, análisis y especificación de los requisitos, diseño, codificación, implantación y pruebas, y mantenimiento. Este modelo ha recibido muchas críticas que ponen en duda su eficacia debido a una serie de puntos débiles [80,81]. Entre ellos se pueden destacar la imposibilidad de una estricta especificación de requisitos en una fase temprana del desarrollo, la posible desconexión entre las tareas llevadas a cabo por diferentes miembros y la dificultad de seguir un camino lineal en el desarrollo del producto. El modelo conocido como Desarrollo Rápido de Aplicaciones (DRA) [82,83] es una variante del Modelo Lineal Secuencial que tiene el objetivo de recoger los procesos que, siguiendo un camino lineal, están orientados al desarrollo de un producto en condiciones extremas de tiempo. El DRA se basa en la construcción de software por medio de componentes. Además, se utilizan herramientas de cuarta generación que proporcionan automáticamente el código a partir de las especificaciones. El siguiente paradigma a considerar es el Modelo del Prototipo [84], basado en unas fases rápidas de análisis de requisitos (se identifican los más claros), y diseño (centrado en aspectos visibles para el usuario o cliente final). Estas dos etapas llevan a la construcción de un prototipo encaminado a poner de manifiesto nuevos requisitos funcionales que no estaban asequibles en un primer análisis general y que serán entendidos por el desarrollador de una forma más clara. Uno de los inconvenientes de este modelo es que el usuario quiere empezar a trabajar con el prototipo y no entiende la falta de eficiencia que éste suele exhibir. Además, el desarrollador puede emplear en la elaboración del prototipo herramientas (tecnología, estructuras de datos, etc.) que, aunque no eran las más idóneas, sí eran las que estaban más accesibles o permitían el desarrollo en un menor tiempo. El ingeniero del software debe usar el criterio riguroso para la selección de los recursos adecuados. 26

41 Introducción Un tercer paradigma de procesos es el denominado Modelo Incremental [85]. Éste, al igual que el modelo del prototipo y otros modelos evolutivos, cuenta con la ventaja de una implicación activa del cliente. Esto es debido a su estructura basada en iteraciones, las cuales se corresponden con subprocesos de desarrollo lineal que producen incrementos de software usados para el refinamiento de los requisitos. A diferencia del modelo del prototipo, el incremental entrega en cada iteración un producto que está preparado para ser operacional. Además de ser útil en la evaluación de riesgos, aporta una buena adaptación al hecho de no disponer del número adecuado de desarrolladores. El Modelo en Espiral [86] también es un proceso interactivo con el cliente. Está basado en incrementos que adquieren cada vez mayor dimensión, empezando incluso por un esquema en papel en la primera iteración, para llegar a sistemas de gran escala en las últimas versiones. Este modelo se divide en regiones de tareas (se distinguen entre 3 y 6 regiones de tareas), las cuales forman parte de cada versión. El modelo en espiral se aplica no sólo a la fase de desarrollo, sino que puede considerarse un procedimiento de trabajo que sustenta el ciclo de vida del software (es el tipo que da más importancia a la fase de mantenimiento). Además, usa la construcción de prototipos como un modo de evaluación de riesgos. Pero este paradigma también presenta inconvenientes, entre los que se citan la dificultad para convencer a los clientes de que se puede controlar el proceso y la habilidad requerida para la evaluación del riesgo Fases comunes en el proceso de desarrollo de software Existe una serie de etapas comunes en todos los modelos comentados anteriormente. Estas etapas son: análisis y especificación de requisitos, diseño del sistema, codificación e implantación de la solución construida, pruebas, y, por último, mantenimiento del producto software. Se van a comentar las más relevantes. El Análisis y Especificación de Requisitos permite conocer las necesidades a cumplir respecto a la funcionalidad del software, su rendimiento, 27

42 Manuel Urbano Cuadrado Tesis Doctoral las interfaces con el entorno, y sus restricciones [87]. Aunque se puede pensar que es una tarea que no reviste dificultad, es de importancia crítica en el proceso de desarrollo. Al hablar de la calidad de la información analítica se comentó que el cumplimiento de los requerimientos del cliente es el único camino para conseguirla. Un símil con este concepto se puede establecer con la calidad de un producto software, pues, aunque las demás fases del proceso se hayan hecho de una forma correcta, si el análisis de requisitos no recoge las necesidades del cliente la calidad del producto es mala [88,89]. Suelen distinguirse cinco actividades implicadas normalmente en el análisis de requisitos: reconocimiento del problema, evaluación y síntesis, modelado, especificación y, por último, revisión. La fase de modelado es de suma importancia, pues en ella se construye una serie de modelos para describir los requerimientos del cliente, establecer la base del diseño y, finalmente, definir un conjunto de requisitos que se puedan validar una vez que se ha construido el software. Dos tipos de modelado del análisis se han impuesto sobre otros en los últimos tiempos: el análisis estructurado [90,91] y el análisis orientado a objetos [92-94]. En este apartado se van a comentar las características más relevantes del primero, para más adelante introducir el análisis orientado a objetos. Son cuatro los principales elementos del análisis estructurado: el diccionario de datos, el diagrama entidad-interrelación, el diagrama de flujo de datos, y el diagrama de transición de estados. Los dos primeros elementos pertenecen al modelado de los datos, el tercero al modelado de la función, y el último al modelado del comportamiento del sistema. El diccionario de datos es un término introducido por DeMarco [90] y recoge las definiciones de las estructuras de datos de entrada al sistema, las que se van a generar o consumir en el procesamiento de la información, y las que forman la salida del programa. El modelado de los datos describe las agrupaciones de datos presentes en el dominio de información del sistema y la relación entre ellas. Los diagramas entidad-interrelación, propuestos por primera vez por Chen en el año 1977 [95], 28

43 Introducción son la principal herramienta en el modelado de datos. La intención de este autor era representar el nivel conceptual de una base de datos El flujo de información por el sistema se representa por el diagrama de flujo de datos. En él se describen, con un nivel de detalle dado, el camino de los datos, las entidades que operan con ellos, las transformaciones a que son sometidos y los lugares donde se almacenan. El refinamiento de los diagramas de flujo se utiliza para mostrar un mayor nivel de detalle. La creación de los diagramas de flujo de datos estuvo pensada para sistemas de procesamiento de la información discretos. Pero las demandas impuestas por los sistemas de tiempo real (en química analítica todos los sistemas de automatización y control de los instrumentos) hizo necesaria la extensión de los diagramas de flujo de datos [96,97]. Las nuevas aportaciones tienen en cuenta la recogida o producción de la información de una forma continua, el flujo de control necesario y el paralelismo de tareas. Para modelar uno de los requisitos más importantes de un sistema, su comportamiento, se introdujeron nuevas ampliaciones del análisis estructurado [96,97]. Este modelado se plasma en un diagrama de transición de estados que muestra los estados y las ocurrencias que hacen que un sistema cambie de un estado a otro. La siguiente fase del proceso es la fase de Diseño. En 1959, Taylor lo definió como el proceso de aplicar distintas técnicas y principios con el propósito de definir un dispositivo, un proceso o un sistema con suficiente detalle como para permitir su realización física [98]. El diseño constituye, junto con las fases de codificación y prueba, la fase técnica del proceso de desarrollo de software. Desde un punto de vista más práctico la fase de diseño puede visualizarse como el conjunto de actividades que transforman los modelos de análisis en modelos de diseño. Las tendencias del diseño están marcadas, por tanto, por las del análisis: un diseño estructurado [99-101] y un diseño orientado a objetos [102,103]. Se va a hacer un comentario sucinto del diseño estructural para 29

44 Manuel Urbano Cuadrado Tesis Doctoral después introducir, junto al análisis, el diseño orientado a objetos y sus aportaciones. El diseño se afronta con un enfoque sistemático, por lo que juegan una baza importantísima conceptos como abstracción, refinamiento, modularidad, partición estructural, etc. La modularidad se puede considerar como una actividad admitida en todas las ingenierías que hace más fácil la adaptación del sistema a los cambios y permite el desarrollo en paralelo. Está basada en la independencia respecto a otros módulos, siendo el subsiguiente acoplamiento de vital importancia para la estructura del programa. El diseño se divide en 4 partes: diseño de datos (su resultado son las estructuras de datos necesarias para implantar el software); diseño arquitectónico (se definen las partes estructurales del software); diseño de interfaz (se describe la comunicación de las diferentes partes estructurales entre sí, además del entorno) y diseño procedimental (los elementos estructurales del programa se describen de forma procedimental) [76]. Son numerosos los métodos de diseño descritos para cada actividad, estando fuera del alcance de esta introducción entrar en ellos, ni siquiera con un mínimo detalle. La fase de Codificación e Implantación supone la traducción física de los modelos de diseño al programa o prototipo, según el paradigma y el estado del proceso de desarrollo. Se pueden usar en estas etapas numerosos lenguajes de programación y, al igual que en las anteriores, se pueden distinguir lenguajes estructurados [104,105] y lenguajes orientados a objetos [106,107]. Las Pruebas del producto software, siguiendo con el paralelismo de los programas de calidad de las empresas, son las acciones correspondientes a la garantía de la calidad, es decir, el control de calidad y las subsiguientes acciones correctoras. Constituyen la evaluación final de las etapas de análisis, diseño, codificación e implantación. Numerosos autores han abordado la fase de pruebas del software [ ], tratando los principios de éstas, el diseño de los casos de prueba, etc. 30

45 Introducción 2.2 Modelado orientado a objetos El término orientado a objetos fue introducido a finales de los años sesenta y comienzos de los setenta, aunque hasta la primera mitad de la década de los noventa no se empezó a utilizar el paradigma orientado a objetos de forma considerable en ingeniería del software [103, ]. El concepto apareció con el uso de lenguajes orientados a objetos (el primer lenguaje fue Smalltalk [106]), dejando fuera la implicación del término en el proceso de desarrollo de aplicaciones Conceptos básicos del modelado y de los lenguajes de programación orientados a objetos El mundo real puede ser visto como un espacio lleno de objetos. Cualquier objeto tiene un conjunto de propiedades o atributos (atributo es el término más usado) que lo caracteriza y diferencia del resto. Apoyándonos en el área de automatización en química analítica, un instrumento es un objeto que tiene unas propiedades determinadas, como son: marca, modelo, puerto de comunicación, etc. Además, un instrumento se puede conectar y desconectar al ordenador, fijar una serie de parámetros para su funcionamiento, etc. Es decir, un objeto realiza una serie de operaciones (métodos es el término empleado). Una Clase es una abstracción de un conjunto de objetos que tienen la misma estructura (atributos) y el mismo comportamiento (métodos). Es decir, la clase Instrumento abarcaría objetos como un espectrofotómetro, un espectrofluorímetro, un medidor de ph, etc. También se suele emplear el término instancia (de la clase) en lugar de objeto. El hecho de que una clase pueda heredar los atributos y métodos de otra es conocido con el término Herencia, siendo ésta una de las características clave del paradigma de orientación a objetos. Se establece una jerarquía en la que la clase que hereda se denomina clase hija o subclase de la clase padre o superclase. Una clase, además de heredar las propiedades y el comportamiento de otra, puede 31

46 Manuel Urbano Cuadrado Tesis Doctoral añadir nuevos atributos y métodos, conociéndose esto como Especialización, lo que permite diferenciar las clases del mismo nivel en una determinada jerarquía. Así, una clase denominada InstrumentoOptico hereda los atributos y métodos de la clase Instrumento, pero para especializar su funcionalidad debe incorporar nuevas propiedades como el tipo de instrumento óptico (para saber si se corresponde con una técnica molecular o atómica, si es de absorción o emisión, etc.) y nuevos métodos, como, por ejemplo, el empleado para fijar la longitud de onda. Para obtener las propiedades de un determinado objeto que se requieren para la funcionalidad de otro, este último tiene que utilizar los mensajes como medio de comunicación con el primero. Los Mensajes estimulan el comportamiento del objeto receptor, necesitándose que en el mensaje se indiquen el método solicitado y los parámetros requeridos para que la operación se realice de forma correcta. De esta forma, un objeto oculta sus datos y sus métodos, y sólo los objetos que tengan permiso podrán llegar a la información que el objeto posee por medio de la comunicación anteriormente descrita. Esta característica es conocida como Encapsulamiento. El Polimorfismo es otra de las características del paradigma de orientación a objetos. Puede definirse como la diferente funcionalidad que exhiben los mismos métodos en diferentes objetos pertenecientes a la misma clase, o incluso en un mismo objeto (llamándose en este caso sobrecarga de métodos). La primera modalidad se puede llevar a cabo mediante el proceso de herencia. Así, una clase define unos determinados métodos, pero no los implanta ella, sino las clases hijas, adaptándolos a sus propias características. Estos métodos son conocidos en algunos lenguajes de programación como métodos abstractos (por ejemplo, el lenguaje Java [107]). La otra posibilidad, la sobrecarga de métodos, se lleva a cabo mediante la diferencia en los parámetros del mensaje al objeto receptor, ya sea por el tipo o números de datos. Éste utiliza el método apropiado para la finalidad requerida. 32

47 Introducción Ventajas inmediatas de los sistemas orientados a objetos Aunque el concepto de objeto fue utilizado primeramente en el mundo de los lenguajes de programación (Smalltalk), la filosofía y las características implícitas en el concepto hicieron conveniente su introducción en el proceso de desarrollo de software. Se van a comentar las características más destacadas. El modelado orientado a objetos se adapta de una forma más eficiente que el modelado estructurado a los paradigmas evolutivos, que son los que se están imponiendo en el desarrollo de productos software. Incluso hay autores que definen un nuevo paradigma de desarrollo llamado Modelo de Ensamblaje de Componentes [117], basado en el modelado orientado a objetos. En una primera iteración del proceso evolutivo, en el análisis y diseño orientados a objetos se buscan las clases necesarias en bibliotecas de clases, y, si no están, se construyen las nuevas. Una nueva iteración partiría ya de estos componentes, que se adaptan, como se verá a continuación, de una forma más eficiente a los cambios y ampliaciones necesarios en las nuevas iteraciones. Por tanto, el modelado orientado a objetos permite la reutilización de software, proporcionando los siguientes datos según Yourdon [118]: reducción del 70 % de tiempo en el ciclo de desarrollo del software, reducción del 84 % en el coste del proyecto, y un índice de productividad del 26.2, comparado con la norma de industria Las propiedades del diseño de un sistema software son las mismas para los métodos clásicos (estructurados) que para los orientados a objetos. Una de ellas es la eficiencia alcanzada en la modularidad de los programas. Se ha visto que el concepto de clase no sólo representa los objetos del mundo real, sino que encapsula los atributos y los métodos dentro de la clase. Se puede considerar que es una forma eficaz de abstracción de los datos y los métodos dentro del concepto de clase, que va a ocultar toda la estructura de datos y la implantación de los métodos. 33

48 Manuel Urbano Cuadrado Tesis Doctoral Una gran ventaja salta a la vista con este enfoque. Las clases proporcionan los datos necesarios para otros componentes (otras clases) a través de los métodos que tienen permiso (se habla de métodos privados y métodos públicos), actuando éstos a modo de interfaz. La posibilidad de efectos colaterales disminuye drásticamente. Los errores se localizan de forma rápida y están circunscritos a una determinada clase, por lo que una vez modificada la clase y eliminado el problema, la arquitectura del programa no se afecta. El acoplamiento, otra de las características buscadas, es máximo con un sistema de clases bien diseñado y construido. La cohesión también está asegurada si el número de datos a manejar por cada método es pequeño, que es la situación usual. La versatilidad de los sistemas orientados a objetos también es mayor que la conseguida por métodos convencionales. Este aspecto deriva del encapsulamiento de los métodos, que pueden considerarse como módulos en el sentido convencional, y que ofrecen una representación específica del comportamiento de un objeto, teniendo en otros métodos otros comportamientos para funciones distintas. La ventaja radica en que toda esta funcionalidad reside en una única y simple unidad llamada clase. La reusabilidad de los sistemas orientados a objetos se ha visto desde un punto de vista arquitectónico, con la utilización de clases ya diseñadas y construidas. Desde el punto de vista de la codificación, el concepto de herencia permite también aprovechar el concepto de reusabilidad, al no tener que reescribir el código de la implantación de los atributos y métodos heredados. Además, la introducción de modificaciones es una tarea más fácil debido a la propagación automática de las correcciones realizadas en las clases padre de la jerarquía. El polimorfismo facilita la expansión de los programas sin la modificación de las estructuras de control, lo que supone una ventaja considerable frente al modelado estructurado. Lo vamos a ver con un ejemplo. Supongamos una estructura de control utilizada en un programa de 34

49 Introducción automatización en química, en la que, si se cumple una premisa de tiempo (el tiempo en el cual el instrumento debe realizar una determinada operación), la clase Instrumento recibe un mensaje para llevar a cabo el método ejecutar de la clase Accion. La estructura es la siguiente: /* Se recorre la lista de instrumentos que forman un autoanalizador */ for (int i=0; i<lista_instrumentos.length; h++) { /* Para cada instrumento se recorre la lista de acciones a ejecutar */ for (int a=0; a<lista_instrumentos[i].acciones.length; a++) { /* Si el tiempo asociado a una acción es el mismo que el tiempo actual la acción se ejecuta*/ if (lista_instrumentos[i].acciones[a].gettime() == v_tiempoactual) { lista_intrumentos[i].acciones[a].ejecutar(); } } } La inclusión de una nueva clase representando un nuevo instrumento no supone ninguna modificación de la estructura de control mostrada arriba, ya que el polimorfismo del método ejecutar asegura una implantación acorde con el tipo de acción a desarrollar, que ya viene dada con el nuevo componente (la nueva clase). 2.3 UML. El lenguaje estándar del modelado orientado a objetos Antecedentes de UML El nacimiento de la tecnología orientada a objetos supuso la aparición de numerosos métodos de modelado para el análisis y diseño de aplicaciones. La diversidad de alternativas era muy grande, llegándose a alcanzar los 50 métodos 35

50 Manuel Urbano Cuadrado Tesis Doctoral en 1994, y conllevaba la falta de estandarización para el desarrollo de los programas. Además, estos métodos sólo cubrían áreas parciales, por lo que el ingeniero del software rara vez obtenía un método que le permitiese modelar todos los aspectos de una aplicación. Surgió entonces una serie de métodos con el objetivo de ensanchar el campo de aplicación de sus respectivos lenguajes de modelado, no restringiéndolo a necesidades específicas. De estos métodos destacaron el método OOSE (Object-Oriented Software Engineering) propuesto por Jacobson [103], el método OMT (Object Modeling Technique) propuesto por Rumbaugh [119], y el método de Booch [92]. Aunque eran considerados métodos completos, presentaban una serie de puntos fuertes y puntos débiles. La evolución de cada uno de los tres métodos de modelado principales fue el adoptar ideas y conceptos de los otros dos, por lo que cada vez fue más necesario el esfuerzo de sintetizar un lenguaje unificado. Además, la colaboración entre los creadores de los tres métodos dio como resultado una mejora global del modelado orientado a objetos. De esta forma, desde 1994 se desarrolló un trabajo en la compañía Rational Software que culminó en 1997 con la publicación de la versión 1.0 de UML [ ], que se ofreció para su estudio al grupo OMG (Object Management Group). En esta versión y en el estudio posterior los autores recibieron la colaboración de muchas organizaciones del área informática, entre las que se citan IBM, Hewlett-Packard, Microsoft, Oracle, etc Elementos del lenguaje UML Se consideran cuatro tipos de elementos UML: estructurales, de comportamiento, de agrupación y, por último, de anotación. El primer elemento estructural que se cita es la clase, que describe un conjunto de objetos que tienen los mismos atributos, operaciones y relaciones en el modelo a desarrollar. Otro elemento estructural es la interfaz, que describe un conjunto (total o parcial) de operaciones de una clase o componente desde el 36

51 Introducción punto de vista de la funcionalidad externa y no de la implantación de ésta. Una colaboración es un elemento estructural que define una interacción de elementos que participan de forma conjunta para conseguir un comportamiento no alcanzable por un elemento individual. Un caso de uso describe un conjunto de secuencias de acciones que el sistema ejecuta y que produce un resultado observable de interés para un actor particular. Se dice que un caso de uso se lleva a cabo por una colaboración. Otros tres elementos estructurales de UML son la clase activa, el componente, y el nodo. Son similares al concepto de clase, pero introducen particularidades que hacen necesario su empleo. Los elementos de comportamiento describen la parte dinámica de los modelos desarrollados con UML, por lo que son considerados los verbos de este lenguaje. Se distingue la interacción, que describe un conjunto de mensajes intercambiados entre un grupo de objetos para conseguir un objetivo específico, y la máquina de estados, que recoge la secuencia de estados por la que pasa un objeto o una interacción en respuesta a un evento. Los elementos de agrupación son las partes organizativas de los modelos. En UML sólo se utiliza el paquete, que puede ser considerado como un elemento que engloba elementos estructurales, de comportamiento, e incluso propios elementos de agrupación. Por último, los elementos de anotación son comentarios que se añaden al modelo para un mejor entendimiento de éste. La nota es el objeto de anotación básico para describir explicaciones y restricciones Relaciones en el lenguaje UML Para construir modelos se utilizan cuatro tipos de relaciones en UML, que tienen el objetivo de unir los elementos entre sí: la dependencia, la asociación, la generalización y la realización. La dependencia es una relación entre dos elementos, en la que un cambio a un elemento (denominado independiente) afecta a la semántica del otro (denominado dependiente). La asociación es una relación estructural que 37

52 Manuel Urbano Cuadrado Tesis Doctoral describe las conexiones entre objetos. La agregación es un tipo especial de asociación que representa la relación entre un todo y sus partes. La generalización (la forma de representar la herencia en UML) describe la relación de sustitución de un elemento general (padre) por un objeto especializado (hijo). Por último, la realización es una relación semántica donde un elemento especifica un contrato que otro elemento garantiza que cumplirá Diagramas en el lenguaje UML Un diagrama es la representación gráfica de un conjunto de elementos y relaciones que recogen una parte de la estructura, comportamiento y arquitectura del sistema. Los aspectos estructurales se recogen en el diagrama de clases y en el diagrama de objetos. El primero es una descripción de las clases, las interfaces, las colaboraciones y las relaciones entre los tres elementos anteriores. El segundo representa una vista instantánea de los elementos y relaciones encontrados en el diagrama de clases. El comportamiento del sistema se modela con la construcción de varios tipos de diagramas. El diagrama de casos de uso representa las relaciones entre las acciones del sistema y los actores implicados. El diagrama de secuencia y el diagrama de colaboración se emplean para el modelado de las interacciones entre un grupo de objetos que intercambian una serie de mensajes, por eso se les denominan también diagramas de interacción. Los de secuencia resaltan la ordenación temporal de los mensajes y los de colaboración señalan los aspectos estructurales de los objetos que envían y reciben mensajes. Otros diagramas se encargan de modelar la dinámica del sistema desde el punto de vista del flujo de control. Estos son el diagrama de estados y el diagrama de actividades. En ambos se muestran los estados por los que puede pasar un sistema, y, por otro lado, las actividades y eventos que provocan la transición de un estado a otro. La arquitectura del sistema se modela mediante el diagrama de componentes y el diagrama de despliegue. El primero se encarga de representar 38

53 Introducción la organización y dependencias entre un conjunto de componentes, y se relaciona con los diagramas de clases en que un componente incluye una o más clases, interfaces o colaboraciones. El diagrama de despliegue muestra la configuración de los nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. 3. El lenguaje de programación Java 3.1 Desarrollo del lenguaje de programación Java Java es un lenguaje de programación de alto nivel como lo son Pascal, Basic, C++, etc., o sus entornos gráficos de programación, Visual Basic, Delphi, Visual C++, etc. La primera versión de Java apareció en el verano de 1995 [123,124] en un intento de paliar los inconvenientes que presentaba la dependencia del código desarrollado respecto al microprocesador y sistema operativo del ordenador donde iba a utilizarse. El software de reducidas prestaciones que se empotra en dispositivos electrónicos de bajo precio, como electrodomésticos, calculadoras, sensores, etc., tenía que ser actualizado constantemente al modificar el microprocesador de estos dispositivos. Esto ocurre incluso con los lenguajes de alto nivel como C. La empresa Sun Microsystem [125] se marcó como objetivo, a principios de los años noventa, el desarrollo de un nuevo lenguaje de programación que se adecuara al entorno de ejecución sin la necesidad de realizar ningún cambio en el código. Es decir, el objetivo fue buscar la portabilidad total del lenguaje a construir. Éste fue el inicio de un proceso de desarrollo de un nuevo lenguaje que seguramente, y a pesar de importancia de la portabilidad del código hoy en día, no hubiese alcanzado las cotas de popularidad de las que goza si no hubiese nacido en la que ya se ha denominado era de la información. Así, fue determinante el encuentro entre el principal símbolo, herramienta, etc., de esta era, Internet, y el lenguaje Java. 39

54 Manuel Urbano Cuadrado Tesis Doctoral Gosling, al frente del equipo de Sun inmerso en la síntesis del nuevo lenguaje, vio la posibilidad de mostrar la total portabilidad del lenguaje ejecutando un programa dentro de una página Web, es decir, ejecutar un programa desde cualquier punto de la red. Para este fin necesitó un navegador que integrara la posibilidad de ejecutar Java en Internet, creando entonces el navegador HotJava. A partir de aquí surgieron las características que consagraron a Java como el lenguaje estándar de la red. 3.2 Características generales de Java Simplicidad Java, sin lugar a dudas, es un lenguaje simple. De lenguajes como C y C++ ha tomado las características de sintaxis, de diseño y de seguridad que han hecho que estos lenguajes sean de los más utilizados en la programación actual. Java ha avanzado respecto a estos lenguajes al eliminar las características que implican para el programador un mayor grado de dificultad, reduciendo considerablemente el número de errores. Así, los tipos de estructuras (struct), y su definición (typedef), no están presentes en el lenguaje Java. Como punto más importante, Java ha eliminado el concepto de puntero presente en el lenguaje C y C++ y, por tanto, la aritmética de punteros, uno de los aspectos más engorrosos de estos lenguajes. Java posee una gestión automática de la memoria que permite liberarla a través del denominado recolector de basura (garbage collector) [126, 127] Robustez Java incorpora una serie de medidas y comprobaciones que evitan errores inesperados, por lo que se considera un lenguaje robusto (de hecho, se pensó llamarlo Oak, roble en inglés, haciendo alusión a su robustez). Tanto en tiempo 40

55 Introducción de compilación como de ejecución se realizan chequeos para encontrar posibles problemas. También se realiza una comprobación de los bytecodes, que son el código resultante tras la compilación de un programa Java, es decir, no se trata de un código máquina directamente entendible por el hardware. Los bytecodes son la entrada a la Máquina Virtual de Java (JVM), que se tratará más adelante. El control automático de la memoria, eliminando los errores por desbordamiento (overflow), también aporta robustez al lenguaje Portabilidad e independencia Características como la portabilidad y la independencia de Java y su arquitectura derivan del hecho de que este lenguaje es compilado e interpretado, es decir, están presentes las dos formas de traducción de un código fuente (lenguaje de alto nivel a código máquina). Tras el proceso de compilación del programa Java, se obtiene el código objeto formado por bytecodes, que contiene el 80% de las instrucciones del programa en código máquina. Este código es genérico y, para adaptarlo a una determinada plataforma (el concepto de plataforma se refiere a la combinación de un procesador y un sistema operativo), se interpreta por la JVM para añadir el 20% de las instrucciones del programa. La JVM, que es la encargada de interpretar los bytecodes al lenguaje máquina, hace que la ejecución de una determinada aplicación se adapte al hardware de la plataforma dada. Por lo tanto, la JVM es dependiente de la plataforma, siendo el único elemento específico que se necesita para ejecutar un programa Java, independientemente de que éste haya sido compilado en cualquier otra máquina con diferente sistema operativo o distinto microprocesador [128]. La JVM está disponible en la arquitectura Java (Java 2 Platform Standard) para Solaris 2.x, SunOS 4.1.x, Microsoft Windows (95, 98, 2000, NT, Server y XP), Linux, Iris, Aix, Aple, etc. Además, ha sido incorporada a los 41

56 Manuel Urbano Cuadrado Tesis Doctoral distintos navegadores (Microsoft la incorpora en la versión 5.0 de Internet Explorer), a los sistemas de gestión de bases de datos, servidores virtuales, etc Lenguaje distribuido y capacidad para la programación multihilo Java está concebido para el desarrollo de aplicaciones ejecutables en distintas máquinas en red. Por eso posee una serie de librerías para facilitar la interconexión vía protocolo TCP/IP. Por lo tanto, se pueden desarrollar aplicaciones para acceder a la información en la red de igual forma que se accede a la memoria secundaria de una máquina local [129]. Una aplicación construida en Java puede ejecutar varias actividades de forma simultánea dentro de una aplicación. Esta propiedad aporta un mejor rendimiento interactivo y facilita el desarrollo de aplicaciones para control de dispositivos en tiempo real [130] Lenguaje orientado a objetos y gratuito En primer lugar, es un lenguaje orientado a objetos, tanto a nivel arquitectónico, al aportar las propiedades más importantes de los sistemas de objetos (herencia, encapsulación y polimorfismo), como a nivel funcional, al ser los datos tratados como objetos en todo momento. Por otro lado, las diferentes herramientas para el desarrollo de aplicaciones Java son gratuitas. Todas las plataformas están disponibles en 3.3 Aplicaciones Java Las diferentes plataformas e interfaces para la programación de aplicaciones (denominadas APIs del inglés Application Programming Interfaces) de Java proporcionan un amplio abanico de posibilidades en la construcción de programas de distinto tipo. Así, se pueden desarrollar soluciones standalone, que son aplicaciones sin características especiales (no acceden a un servidor, no utilizan recursos en máquinas remotas, etc.) para ejecutar en un único ordenador. 42

57 Introducción Para su desarrollo son suficientes las librerías y utilidades incluidas en la plataforma estándar de Java (Java 2 Platform, Standard Edition, J2SE). Aplicaciones más complejas son las que están basadas en una arquitectura multicapa. Por ejemplo, los sistemas de información de tres capas, denominados en inglés three tiered Enterprise Information Systems y desarrollados con tecnología Java usan la plataforma Java 2 Entreprise Edition (J2EE). Por este motivo, también se denominan aplicaciones J2EE [131,132]. La primera capa se denomina capa cliente, formada por diferentes componentes que se ejecutan en las máquinas que acceden de forma remota a un servidor Web. Un componente J2EE es una unidad software con una determinada funcionalidad y que se acopla a los demás componentes de la aplicación J2EE a través de sus respectivas clases. Los diferentes componentes de la capa cliente se pueden agrupar en tres bloques: los clientes Web, los applets y las aplicaciones cliente. Los clientes Web están formados por las páginas Web dinámicas, escritas con los lenguajes de marcas HTML o XML (extensible Markup Language), y los navegadores Web, que permiten la búsqueda y visualización de la información. Por su parte, los applets son pequeñas aplicaciones cliente escritas en Java y que ejecutan la JVM perteneciente al navegador. Por último, las aplicaciones cliente son interfaces normalmente realizadas con los paquetes Swing o Awt de Java para aportar una mayor riqueza gráfica. La segunda capa es el servidor Web, que está formada por Servlets y las páginas JSP (Java Server Page). Los servlets son clases Java que, de forma dinámica, procesan las peticiones al servidor y construyen las respuestas a los clientes. Las páginas JSP presentan la misma funcionalidad que los servlets, diferenciándose de éstos en la estructura basada en página Web que poseen. La arquitectura de tres capas es considerada por algunos autores, que desde una óptica del dominio de la información a tratar por la aplicación J2EE, establecen cuatro capas, y argumentan que la arquitectura de tres capas sólo hace referencia a la localización de los componentes. Por tanto, en la nueva estructura 43

58 Manuel Urbano Cuadrado Tesis Doctoral propuesta para las aplicaciones J2EE, la capa servidor se divide en la capa Web y la capa de negocio. La capa Web está formada por los componentes que formaban la antigua capa servidor, es decir, los servlets y las páginas JSP. Por otro lado, la capa de negocio está formada por los Enterprise Java Beans (EJB), que son la interfaz entre la capa Web (peticiones y respuestas entre el cliente y el servidor) y la última capa, denominada capa del sistema de información. Se distinguen tres tipos de EJB: los de sesión, los de entidad y, por último, los de mensaje. La capa del sistema de información incluye todas las estructuras que facilitan el almacenamiento de la información de la empresa. Por tanto, su núcleo es la base de datos. Los componentes J2EE de esta capa son aquéllos que permiten la conexión entre la capa Web y la de negocio, y la base de datos. Para terminar, se van a citar otras plataformas que ofrece la arquitectura Java para el desarrollo de aplicaciones informáticas en otros campos. J2ME (Java 2 Platform Micro Edition) proporciona las utilidades necesarias para el desarrollo de software para dispositivos electrónicos como móviles, calculadoras, etc. También están disponibles diferentes APIs para el desarrollo de servicios Web, que son aplicaciones para el uso de datos con Java y XML. Para el ensamblaje de componentes Java y componentes XML son útiles las interfaces JAXB, SAX y JDOM [133,134]. 4. La información como recurso. Oracle. SGBD basados en el modelo de datos objeto relacional Los correctos procesos de almacenamiento, mantenimiento y consulta de la información analítica hacen uso de las bases de datos. La gestión automática de los datos siempre se ha apoyado en las características de la memoria secundaria (memoria no volátil) y en una tecnología que ha avanzado desde los sistemas de ficheros hasta los sistemas de gestión de bases datos, basados estos últimos en modelos avanzados de representación de la información. En este apartado se van 44

59 Introducción a considerar las ventajas aportadas por el sistema de gestión de bases de datos Oracle, que es la herramienta de gestión de la información utilizada en el desarrollo y uso del sistema de información que se ha diseñado y construido y que se recoge en esta Memoria. 4.1 De los sistemas de ficheros planos a los de bases de datos Evolución Las demandas funcionales requeridas para las aplicaciones de procesamiento de la información han marcado el camino a seguir en la tecnología de acceso a los datos. Así, los primeros sistemas tenían el objetivo de cumplir unos requisitos normalmente relacionados con las tareas repetitivas de administración, buscando una reducción del tiempo y el espacio que requerían la gestión en papel de los datos. Cuando las empresas llegaron a considerar que la información es el recurso más importante para la vista de negocio, la tecnología evolucionó hacia el desarrollo de las bases de datos. Hoy en día, las bases de datos son el pilar de los sistemas de información. Los sistemas de almacenamiento basados en ficheros mantienen la información por medio de archivos que contienen una colección de registros con diversos campos de datos. La principal limitación de estos sistemas para sintetizar información es la imposibilidad de relacionar diferentes registros sin aplicaciones externas complejas. Además, como se verá más adelante, presentan también una serie de inconvenientes que hacen inapropiado su uso en el entorno computacional de la sociedad actual. Los sistemas clásicos de almacenamiento, como se conocen a las estructuras de ficheros, también experimentaron una evolución interna. El hito más importante que la marcó fue el cambio del acceso secuencial al acceso directo de los datos. Así, para consultar o proporcionar los datos de un determinado registro en un fichero ya no fue necesario leer ni ordenar los archivos de uno en uno, llevando este hecho a un ahorro de tiempo significativo. 45

60 Manuel Urbano Cuadrado Tesis Doctoral El acceso aleatorio de los datos estaba asegurado con ficheros con estructura indexada, soportados en el método ISAM (de las siglas en inglés de Indexed Sequential Access Method) [135]. En la primera generación de ordenadores (años cincuenta y comienzos de los sesenta) se utilizaron ampliamente los sistemas de almacenamiento clásicos. Estos sistemas sólo proporcionaron una solución parcial (por los motivos anteriormente comentados y los inconvenientes que se citarán en el siguiente apartado) por lo que a mediados de los sesenta apareció el concepto de bases de datos [136]. Se cita una definición del concepto de bases de datos de las muchas que aparecen en la literatura: Colección de archivos relacionados que almacenan tanto una representación abstracta del dominio de un problema del mundo real cuyo manejo resulta de interés para una organización, como los datos correspondientes a la información acerca del mismo. Tanto la representación como los datos están sujetos a una serie de restricciones, las cuales forman parte del dominio del problema y cuya descripción está también almacenada es esos ficheros [137]. La tecnología de las bases de datos también ha seguido una evolución, esta vez marcada por los diferentes modelos que representan la estructura de la base de datos a diferentes niveles, desde un nivel físico hasta el externo, pasando por los niveles conceptual y lógico [138]. Así, aparecen las bases de datos jerárquicas, en red, relacionales, objeto-relacional, orientadas a objetos y las bases de datos soportadas en el conocimiento. Los dos primeros modelos, apoyados en el concepto de puntero, tenían una alta dependencia de los niveles físicos, lo que seguía siendo un inconveniente y provocó la búsqueda de nuevos modelos y la evolución de la tecnología Ventajas e inconvenientes de los sistemas de bases de datos frente a los sistemas basados en ficheros Como ya se ha comentado anteriormente, la dificultad de representar la relación entre los datos es el inconveniente más destacado de los ficheros clásicos. Las 46

61 Introducción bases de datos surgen del concepto de Sistema Orientado a los Datos, dejando atrás los Sistemas Orientados a los Procesos. El primero busca la relación de los datos en la definición de la estructura y en el comportamiento, y no en las aplicaciones externas de manejo de datos. La independencia entre los datos y los tratamientos es de vital importancia para que el dinamismo implícito del entorno que los rodea no les afecte. Las bases de datos aseguran que la inclusión de nueva información no modifica los tratamientos de la información y, en dirección contraria, que los cambios de los procesamientos no influyen en el diseño de los datos. Aunque esta independencia no es absoluta, las bases de datos se acercan a este objetivo. La integridad de la información, básica para su uso, se consigue mediante las bases de datos, que permiten que se almacene una única copia de la información que representa un determinado dato. Esta propiedad se sustenta en otra característica de los sistemas de bases de datos, la mínima redundancia que presenta, siendo ésta a nivel físico la totalidad de las veces. En el mantenimiento de los sistemas clásicos, la introducción o modificación de un dato obligaba al acceso a varios ficheros, lo que conllevaba la posible inconsistencia de la información almacenada. La disponibilidad de la información es más apropiada debido a que ningún fichero de datos es para el uso exclusivo de un tratamiento, sino que los datos pueden consultarse por todas las aplicaciones. El espacio de almacenamiento, debido al menor número de redundancias existentes, se reduce en los sistemas de bases de datos. Este menor espacio de memoria secundaria utilizada se pone de manifiesto en los sistemas de gran volumen de datos. Esto es debido a que un sistema de bases de datos utiliza un diccionario de datos, punteros, índices, etc., que, generalmente, ocupan un espacio considerable. Las bases de datos presentan un alto desempeño en la interacción hombre-máquina porque los datos se recogen y se consultan una sola vez. Por lo 47

62 Manuel Urbano Cuadrado Tesis Doctoral tanto, el rendimiento de la consulta y la actualización en una base de datos va a ser siempre mayor que en los sistemas de ficheros planos. Los sistemas de gestión de bases de datos (que se verán más adelante) garantizan la seguridad y la privacidad de la información. Una de las características más importantes de Oracle (uno de los más conocidos sistemas de gestión de bases de datos) es la extrema protección que su arquitectura proporciona [139]. A pesar de esta serie de ventajas, existen algunos inconvenientes en los sistemas de bases de datos, normalmente potenciados por el desconocimiento por parte de las empresas de las características de los sistemas de gestión de bases de datos. Uno de estos inconvenientes es la implantación larga y costosa, y como consecuencia, una rentabilidad no visible a corto plazo. Otros problemas están relacionados con la falta de estandarización (aunque ya se dispone de herramientas estándares, sobre todo para las bases de datos relacionales), y el desfase entre una teoría adelantada y una práctica a la zaga. 4.2 El Sistema de Gestión de Bases de Datos (SGBD) El SGBD es el sistema computacional que facilita la gestión de las bases de datos. Por tanto, el SGBD engloba el conjunto de programas, procedimientos, lenguajes, interfaces, etc., que suministra a los usuarios de la base de datos las utilidades necesarias para describir y manejar los datos almacenados. Además, garantiza la seguridad y privacidad de la información contenida en la base de datos. Por lo tanto, se puede considerar que es la interfaz entre la base de datos y los diferentes usuarios y aplicaciones del sistema de información. Cuando se habla de usuarios de las bases de datos, se refiere a dos niveles o dos grupos, que a su vez se pueden subdividir. El primer grupo lo componen los usuarios que crean y mantienen la base de datos, además de desarrollar los programas que acceden a los datos. El segundo grupo de usuarios son aquellos que emplean los datos para sus actividades dentro de la empresa. 48

63 Introducción Funciones y lenguajes de los SGBD Suelen distinguirse tres funciones principales de los SGBD: la función de definición, la de manipulación y la de control de los datos. La función de definición permite especificar los elementos de datos, su relación y las restricciones impuestas tanto por el dominio de la información, como por las estructuras físicas de almacenamiento. El lenguaje encargado de esta función es el Lenguaje de Descripción de Datos (Data Definition Language, DDL), que es dependiente del SGBD. Este lenguaje suele encargarse también de indicar el espacio reservado para la extensión de los campos, las estructuras de datos y sus relaciones, y las restricciones. Ésta es la definición física y, en algunos SGBD, su especificación se hace separadamente con otro lenguaje denominado Lenguaje de Definición del Almacenamiento de los Datos (Data Storage Definition Language, DSDL). La función de manipulación se lleva a cabo con el Lenguaje de Manipulación de Datos (Data Manipulation Language, DML), que permite la definición externa de los datos, su consulta y la actualización de éstos, es decir, su inserción, modificación y borrado. EL DML es un lenguaje dependiente del modelo que emplea el SGBD, y puede ser una serie de mandatos dentro de un lenguaje de programación, llamado huésped o, por el contrario, un lenguaje que no necesita apoyarse en ningún otro. Por último, la función de control se lleva a cabo por medio de una serie de interfaces que proporcionan el correcto acceso de los usuarios a la base de datos. Esta función reside en el Lenguaje de Control de Datos (Data Control Language, DCL) Otros componentes del SGBD Se ha comentado anteriormente que el SGBD está formado no sólo por los lenguajes citados, sino que también cuenta con una serie de programas, estructuras de datos, etc., que permiten la correcta gestión de los datos. El 49

64 Manuel Urbano Cuadrado Tesis Doctoral Diccionario de Datos es un conjunto de archivos que contienen la información de los datos que pueden ser almacenados (es una Metabase de Datos). En este diccionario se almacenan los esquemas lógico y físico de la base de datos, al igual que los subesquemas de ésta. Más adelante se verá que hay 3 niveles o modelos de abstracción en los que se representa una base de datos: físico, lógico y externo. Por lo tanto, el diccionario de datos recoge la definición de estos tres niveles. Los procedimientos de acceso necesitarán en algún momento de cómputo vincular las tres definiciones, basándose en lo que se conoce como Mapa de Reglas, también almacenadas en el diccionario de datos. Otro componente a destacar del SGBD es el Gestor de la Base de Datos, que es un componente software que actúa de interfaz entre los datos almacenados y las aplicaciones que acceden a ellos. Garantiza el correcto, seguro y eficiente almacenamiento y consulta de los datos Estandarización en los SGBD La estandarización y normalización de las bases de datos y de sus sistemas de gestión han sido tratadas por distintos organismos desde los años sesenta, pero su avance ha sido y es lento debido tanto a motivos técnicos, como burocráticos. Los objetivos de la estandarización están encaminados a que el cambio de un producto comercial SGBD a otro no implique la modificación del diseño de la base de datos en uso y de las aplicaciones que usan los datos. Es decir, el concepto de Sistema Abierto es el centro de los objetivos. Dos organismos como son la ISO (International Organisation for Standarisation) e IEC (International Electrochemical Commission) han establecido un comité conjunto denominado JTCI (Joint Technical Committee) para la estandarización en las tecnologías de la información. Uno de los muchos grupos de este comité, el denominado WG3, está dedicado a la búsqueda de sistemas abiertos de bases de datos. Actualmente trabajan en cuatro proyectos: 50

65 Introducción lenguajes de bases de datos, modelos de referencia, acceso remoto a datos y sistemas de diccionarios de recursos de información [138]. Codasyl (Conference on Data System Languages) es un grupo que investigó la normalización en los modelos de datos y sus diferentes lenguajes y propuso un modelo de datos en red, llamado también Codasyl, con sus lenguajes de descripción y manipulación. El grupo ANSI/X3/SPARC es el grupo de estudio de la organización Standard Planning and Requirements Committee (SPARC), perteneciente al American National Standards Institute (ANSI). El comité X3 es el que trata los temas informáticos. En el año de 1972 estos grupos empezaron a aunar esfuerzos encaminados a una potencial normalización de los SGBD. Como en anteriores intentos por parte de otros grupos, el principal inconveniente era el temor a hacer una estandarización en un momento no apropiado que frenase los avances del área. Por este motivo, sus primeras actividades fueron estudios sobre los componentes o aspectos de los SGBD que requerían un mayor grado de normalización. En el año 1977 se elaboró un informe en el que se analizó la arquitectura de un SGBD y las 42 interfaces identificadas. Los trabajos continuaron durante años, creándose grupos dentro del ANSI/SPARC específicos del área de las bases de datos, para, en 1986, proponer un Modelo de Referencia para la estandarización de los SGBD [140]. Tanto el informe final como los intermedios introducen una diferencia en la arquitectura de los SGBD respecto a los trabajos de otros organismos, que sólo distinguían entre la estructura o nivel lógico y la estructura o nivel físico. La arquitectura ANSI/X3/SPARC introduce un tercer nivel entre las estructuras física y lógica. Es el llamado nivel conceptual. Aunque empleando terminología distinta, otros grupos (el grupo GUIDE/SHARE de usuarios de IBM, el Club de Banco de Datos del INRIA, etc.) han introducido arquitecturas similares de tres niveles. 51

66 Manuel Urbano Cuadrado Tesis Doctoral La arquitectura ANSI/X3/SPARC La arquitectura ANSI/X3/SPARC propone tres niveles de abstracción de datos. En ella el nivel clave es el denominado esquema conceptual, del cual derivan una serie de esquemas externos que son la imagen de los datos que tienen los usuarios y aplicaciones que hacen uso de ellos. Del esquema conceptual también deriva el interno, que describe los datos desde un punto de vista físico. La conversión de un nivel a otro se efectúa por medio de funciones de correspondencia. La arquitectura, propuesta en el informe de 1978, está dividida en dos partes: una para la definición de los datos y otra para su manipulación. Se distingue una serie de funciones tanto humanas como de programas, un conjunto de interfaces lógicas o físicas, y un diccionario de datos, también denominado metadatos, clave en esta arquitectura. Los requisitos de independencia y escalabilidad entre los tres niveles se cumplen por la arquitectura ANSI/SPARC, por lo que los cambios en los esquemas interno, conceptual y externo no se afectan recíprocamente. El impacto de la estructura de tres niveles en los SGBD actuales es elevado, pero el informe que la propuso fue criticado debido al número tan elevado de interfaces y la vaguedad del concepto del diccionario de datos. Como se ha comentado anteriormente, los trabajos prosiguieron hasta el Modelo de Referencia (MR), publicado en 1986 [140]. El MR está basado en la arquitectura ANSI, pero supera los inconvenientes del elevado número de interfaces y del concepto del diccionario de datos (se contesta a las numerosas preguntas sobre su concepto que surgieron en el primer informe). Su objetivo es explicar la relación entre los diferentes componentes y niveles del SGBD, lo que supone un intento de marcar las bases para futuras estandarizaciones. 52

67 Introducción 4.3 Modelos de datos Un modelo es una representación de un sistema a un nivel de detalle dado para considerar sus aspectos más importantes. Desde el punto de vista de las bases de datos, el concepto a tener en cuenta es Modelo de Datos, que puede definirse como el conjunto de elementos semánticos que permiten la descripción de la base de datos a diferentes niveles de abstracción. Teniendo en cuenta la arquitectura ANSI, existen modelos internos, conceptuales y externos. Por tanto, se pueden considerar los modelos como herramientas que ayudan a la implantación, comprensión y uso de las bases de datos. En este apartado se va a hacer hincapié en los modelos conceptuales, pues los modelos externos suelen estar basados en los conceptuales y, por otra parte, los modelos internos no están estandarizados y son dependientes del fabricante. Los modelos conceptuales se dividen en modelos conceptuales propiamente dichos y modelos lógicos. Los primeros se centran en la descripción del conjunto de la información a tratar por cada aplicación desde un enfoque totalmente independiente de la máquina. Los modelos lógicos, a diferencia de los conceptuales, describen el dominio de la información, pero desde un punto de vista dependiente del SGBD, utilizando elementos que se soportan en éste y que limitan la representación semántica del problema. Un modelo de datos debe estar compuesto por dos submodelos: el estructural y el dinámico. El submodelo estructural describe la parte estática de los datos (entidades u objetos, sus atributos, sus asociaciones, y sus restricciones), mientras que el dinámico describe las operaciones que hacen que la base de datos varíe de un estado a otro Modelos conceptuales. Análisis semántico de la base de datos Los modelos conceptuales permiten capturar la semántica del problema a tratar sin las restricciones impuestas por el SGBD. Por lo tanto, son modelos más flexibles y proporcionan un mayor grado de abstracción. La interacción que este 53

68 Manuel Urbano Cuadrado Tesis Doctoral tipo de modelos permite es la que tiene lugar entre la información del mundo real a representar y el diseñador de la base de datos. Son varios los modelos conceptuales recogidos en la bibliografía, entre los que se citan los modelos Entidad/Interrelación (E/R), Infológico, Modelo Semántico de Datos (SDM), etc., [141,142]. Por su versatilidad, el primero es el que más se usa hoy en día en el diseño de las bases de datos. No suele estar implantado en los SGBD, aunque algunos de éstos pueden llevar una herramienta CASE incorporada para realizar el diseño conceptual y luego la traducción automática a un modelo lógico. Se suele elegir entre un modelo conceptual u otro, al igual que entre diferentes modelos lógicos, pero no entre un modelo conceptual y un modelo lógico, ya que tienen diferentes ámbitos de funcionalidad. La metodología a seguir en el diseño de las bases de datos es utilizar primero un modelo conceptual para recoger la mayor dimensión semántica del problema y, luego, diseñar la base de datos con el modelo lógico que soporta el SGBD. Además, suelen existir reglas para pasar de un modelo conceptual a un modelo lógico de forma sistemática garantizando la menor pérdida de información posible. El modelo E/R fue propuesto por Chen en los años 1976 y 1977 [ ], y son varios los investigadores que han contribuido a su expansión [ ]. El concepto clave en torno al que giran los demás elementos semánticos es Entidad, que es cualquier objeto de interés para el dominio del problema. Las entidades tienen unos atributos con sus respectivos dominios y se asocian a otras a través de lo que se denominan Interrelaciones, que también pueden presentar atributos. Aunque una descripción del modelo E/R queda fuera del alcance de esta introducción, se van a citar los términos más importantes de este modelo, como son: entidades o interrelaciones débiles o fuertes, cardinalidad de las interrelaciones, debilidad por existencia o por identificación, interrelaciones jerárquicas, etc. El modelo E/R, tal como lo propuso su creador, es únicamente un modelo estructural de la información. Ampliaciones aportadas por Poonen [149] 54

69 Introducción y Shoshani [150] incorporan lenguajes para la recuperación y actualización de los datos almacenados en sus estructuras. Muchos investigadores dudan de la aplicabilidad de la parte dinámica añadida al modelo debido al uso que se le da, pues se emplea el diseño de la base de datos desde la óptica conceptual y no desde la visión lógica del SGBD, que opera sobre los datos Modelos lógicos. Diseño de la base de datos en función del SGBD Un modelo lógico permite un diseño de la base de datos que cubre una información parcial del problema, debido a que la estructura y el comportamiento de los datos en el SGBD imponen unas restricciones al dominio de información a tratar. Muchos son los modelos de este tipo propuestos en la literatura de bases de datos, aunque el más extendido actualmente es el Modelo Relacional debido a que la mayoría de los SGBD comerciales están basados en él. Otros modelos lógicos que han sido usados en gran medida son el modelo en red o Modelo Codasyl, y el Modelo Jerárquico. La sencillez que el usuario encuentra en la parte estática (relaciones o tablas) y en la parte dinámica (lenguajes de consulta y modificación) del modelo relacional es una de las causas que hace que sea el más usado. Además, este modelo no presenta dependencia respecto al nivel físico, que sí la tienen los modelos jerárquico y en red, que utilizan el concepto de puntero (con la implicación física del término) para representar la relación entre objetos. Por otra parte, el modelo relacional ha recibido críticas referentes a la debilidad semántica que posee respecto a los modelos jerárquicos y Codasyl al no permitir, principalmente, la distinción entre los objetos y las asociaciones, ambos representados mediante tablas. Otras críticas se le hicieron cuando los primeros prototipos que implantaban el modelo relacional salieron al mercado y dieron problemas relacionados con la eficiencia de los sistemas. Ya se ha comentado en esta introducción que la teoría y la práctica de las bases de datos ha presentado siempre un desfase a favor de la primera, y éste no fue menos para los sistemas 55

70 Manuel Urbano Cuadrado Tesis Doctoral relacionales. Hoy en día, uno de los más conocidos SGBD, Oracle, soporta el modelo relacional (desde 1980). En los años 90, con el auge del paradigma orientado a objetos en las áreas de ingeniería del software y programación, se desarrolló un nuevo modelo de datos, el Modelo Orientado a Objetos, aunque no se prevé ni a medio ni a corto plazo que sustituya la base relacional de los SGBD actuales. A continuación se exponen brevemente los aspectos clave del modelo relacional y su expansión para soportar la programación orientada a objetos Estática y dinámica del modelo relacional Codd es el creador del modelo relacional, que introdujo a través de una serie de publicaciones donde presentó tanto sus aspectos estructurales como dinámicos [151,152]. El modelo relacional está basado en la teoría matemática de la relaciones, siendo la tabla o relación la estructura básica de almacenamiento, compuesta por filas o tuplas cuyo número varía con el tiempo. La relación, desde el punto de vista de las bases de datos y no matemático, se define como una tabla, identificada normalmente por un nombre que suele ser único en el modelo. Esta tabla posee un conjunto de filas donde la primera se denomina intención de la relación, que está formada por los m pares atributo-dominio. El resto de filas (denominándose al conjunto extensión de la relación) están formadas por los m pares atributo-valor, siendo el orden de estos m pares igual al de los m pares de la intención. La intención es invariable con el tiempo (estática), al contrario de la extensión, que es variable (dinámica). Una base de datos relacional es simplemente un conjunto de relaciones cuya extensión varía con el tiempo. Una fila o tupla no puede repetirse en una relación en un instante t, por lo que debe haber un atributo o un conjunto de ellos que identifiquen únicamente a una determinada tupla. La normalización de las relaciones fue propuesta por Codd [153] con el objetivo de eliminar las inconsistencias y redundancias de un sistema relacional. 56

71 Introducción Para ello se emplea un conjunto de operaciones encaminadas a eliminar una serie de dependencias entre los atributos de una relación. Además, es posible la construcción de las relaciones en una base de datos relacional a través de una serie de reglas de traducción de modelos E/R a modelos relacionales [137]. La dinámica del modelo relacional es el conjunto de operaciones que transforman el estado de una relación, y por lo tanto de una base de datos. Las operaciones son las siguientes: inserción de tuplas, borrado, modificación y consultas. La dinámica del modelo se expresa mediante lenguajes de manipulación relacionales, siendo éstos de dos tipos: algebráicos y predicativos [154,155]. Los primeros dan lugar a lo que se conoce como Álgebra Relacional, que se caracteriza porque modifica el estado de la base de datos mediante operaciones donde los operandos y el resultado son relaciones. Los lenguajes predicativos constituyen el Cálculo Relacional, donde los cambios de estado se especifican por predicados que definen el estado final de la relación sin indicar las operaciones. Se dividen en dos tipos: los que están orientados a tuplas y los que están orientados a dominios. El lenguaje de manipulación que se ha impuesto con diferencia en los SGBD relacionales es el lenguaje estándar SQL (Structured Query Language), que es del tipo algebráico El modelo de datos orientado a objetos El modelo de datos orientado a objetos tiende a eliminar la separación entre los datos y los procesos, que siempre ha existido en la tecnología de bases de datos. Los SGBD Orientados a Objetos (SGBDO) gestionan entidades donde se encuentran encapsulados tanto los datos como las operaciones a realizar con ellos. Así, parte del código que se encontraba en el lado de las aplicaciones en los sistemas convencionales con este modelo se almacena en la base de datos. El modelo de objetos también elimina la frontera entre el nivel conceptual y el nivel lógico, ya que la captura semántica del problema se hace a través del modelo que va a ser implantado por el SGBD. El SGBDO emplea y 57

72 Manuel Urbano Cuadrado Tesis Doctoral aprovecha las características del paradigma de orientación a objetos. Por ejemplo, el encapsulamiento y el ocultamiento de la información, que aportan la ventaja de que el usuario no ve los aspectos de implantación. Además, la modificación de un objeto no afecta a los objetos que interaccionan con él. Las interacciones entre los objetos pueden ser de dos tipos: estáticas y dinámicas. Las primeras se basan en la herencia de objetos (en la tecnología de bases de datos denominada generalización) y en la agregación de objetos para crear objetos complejos. Por otro lado, las interacciones dinámicas tienen lugar a través de los mensajes que solicitan servicios y proporcionan resultados. Los SGBDO poseen una serie de características que son propias del paradigma de orientación a objetos, y otras que han tenido que incorporar de los SGBD. Entre las primeras se encuentran la extensibilidad y la disponibilidad de bibliotecas. Entre las generales de los SGBD están la persistencia, el cumplimiento de la arquitectura ANSI, la seguridad, etc. Hay dos tendencias a la hora de aplicar la metodología de objetos a las bases de datos (se denomina tercera generación de bases de datos) que se diferencian en la distancia que establecen con el modelo relacional. Así, se distingue entre SGBDO puros (rompen por completo con el modelo relacional) y SGBD relacionales extendidos (aprovechan el modelo relacional y la tecnología basada en éste). La comunidad científica está dividida en dos corrientes, una a favor del enfoque evolutivo [ ] y otra que defiende el enfoque revolucionario [159]. Pero el debate también se está dando en el ámbito económico, decantándose la mayoría de las empresas de SGBD por el enfoque evolutivo para no desaprovechar la base tecnológica en la que se asientan las bases de datos relacionales. 58

73 Introducción 4.4 Oracle Evolución reciente del sistema de gestión de bases de datos Oracle Oracle Data Server, comercializado por la compañía Oracle Corporation, y más comúnmente conocido como Oracle, es el líder en el mercado de los SGBD [139]. A partir de la versión Oracle7 se incorporaron las características que hicieron que este producto fuese útil para muchos tipos de aplicaciones: sistemas de almacenamiento de datos, sistemas de ayuda a la decisión, sistemas para el procesamiento de datos operacionales y transaccionales, etc. A partir de la versión Oracle8 soporta tanto el modelo relacional, como el orientado a objetos (enfoque evolutivo) [160]. El lanzamiento de la versión Oracle8 [161,162], verano de 1997, supuso la inclusión de una serie de nuevas características para adaptar el producto a las exigencias de los nuevos entornos computacionales. Así, se incluyeron la partición de datos, los tipos de objetos y sus métodos, los tipos de objetos grandes (LOB, large object), la adjudicación de contraseñas, etc. En 1999, se inició la distribución de Oracle8i, que aportó una serie de mejoras para las aplicaciones de almacenamiento masivo de datos y para las aplicaciones Web. Respecto al primer tipo, Oracle8i incluye características para el incremento del rendimiento del procesamiento de peticiones complejas, como son las vistas materializadas, reescritura de peticiones automáticas e índices basados en funciones. Respecto a las aplicaciones Web, la nueva versión incluye la máquina virtual de Java, comentada anteriormente, lo que permite construir tanto aplicaciones de acceso a los datos, como componentes del SGBD usando el nuevo lenguaje de programación. También se ha incluido el Sistema de Archivos de Internet (conocido por sus siglas iniciales, IFS del Internet File System) Arquitecturas de procesamiento de Oracle Oracle distingue entre la base de datos y la instancia de la base de datos. La definición del primer término ya se ha dado anteriormente. La instancia de la 59

74 Manuel Urbano Cuadrado Tesis Doctoral base de datos es el conjunto de los procesos de sistema operativo y de memoria que el SGBD usa para administrar el acceso a la base de datos. Es decir, para poder acceder a la base de datos es necesario que la instancia de base de datos esté en ejecución [162]. Una instancia de Oracle usa un conjunto independiente de hilos o procesos para soportar las conexiones de usuario (a través del SGBD o de una aplicación externa). Oracle soporta un número de sesiones conectadas a la instancia en varios tipos de entorno computacional. Las aplicaciones cliente/servidor, también denominadas de procesamiento distribuido, realizan varias tareas a través de dos o más componentes. Por ejemplo los tres componentes de los sistemas cliente/servidor: el cliente, el servidor y la red. Para soportar las conexiones distribuidas, Oracle emplea varias arquitecturas: la de servidor dedicado y la de servidor multihilo. En el primer tipo de servidor se crea lo que se denomina un servidor de segundo plano para cada cliente que se conecta al sistema. En el segundo tipo se crea un conjunto de hilos de servidor que de manera eficaz soportan la conexión de gran cantidad de usuarios Java y el acceso a bases de datos Oracle: JDBC y SQLJ La relevancia que tiene actualmente el lenguaje de programación Java ha hecho que Oracle desarrolle una serie de características para la adecuación de las aplicaciones construidas con este lenguaje. En primer lugar, Oracle incorpora la máquina virtual de Java necesaria para la interpretación de los programas. En segundo lugar, Oracle permite usar los estándares industriales JDBC (del inglés Java DataBase Connectivity) y SQLJ (hace referencia al lenguaje de consulta SQL y al lenguaje Java). Por último, las clases Java se pueden almacenar en la base de datos, es decir, no sólo se pueden almacenar los datos, sino también la funcionalidad 60

75 Introducción requerida mediante módulos Java. Además, ya se ha comentado la inclusión del modelo de bases de datos objeto-relacionales en Oracle. 5. Quimiometría: modelos clásicos para diseñar experimentos, clasificar productos y predecir parámetros El empleo de la estadística y las matemáticas en química analítica, conocido este uso con el nombre de Quimiometría, tiene dos objetivos básicos. El primero de ellos es usar la parte deductiva del método científico (a partir del conocimiento se llega a los datos) para el diseño de experimentos [ ]; el segundo objetivo es extraer la máxima información (bio)química, a priori oculta, de los sistemas en estudio. Esta información puede ser cuantitativa (sistemas de regresión multivariante [ ]) o cualitativa (diferenciación y desarrollo de modelos de clasificación de objetos [ ]). Este segundo objetivo usa la parte inductiva del método científico (desde los datos se llega al conocimiento). El diseño de experimentos está encaminado, por una parte, a la selección del conjunto de ensayos necesarios para desarrollar un determinado modelo. Por otro lado, el diseño de experimentos está dedicado al estudio de las variables que influyen en un proceso analítico o en la síntesis de un producto. Los procesos analíticos están afectados por una serie de variables como pueden ser el ph, la temperatura, el caudal en un sistema dinámico, etc. La puesta a punto de un nuevo método analítico debe implicar la mejora de las características analíticas de los métodos oficiales, de referencia o convencionales. Una de estas características es la sensibilidad, con el fin de llegar a discernir entre concentraciones de analito lo más pequeñas posible. Por lo tanto, hay que optimizar el método para ver qué variables afectan a la señal analítica y la dimensión o peso de esta influencia. Además, algunas de las variables a optimizar pueden estar relacionadas con la propiedades analíticas productivas (rapidez, coste, etc.) y afectar 61

76 Manuel Urbano Cuadrado Tesis Doctoral negativamente a la señal, por lo que el cálculo de cómo influyen es de vital importancia para el desarrollo del método. Las técnicas de análisis actuales se caracterizan por proporcionar mucha información. Por ejemplo, los equipos espectroscópicos multicanal permiten la obtención de datos correspondientes a cientos e incluso miles de variables en unos minutos. Esta información no sería útil sin el uso de los diferentes métodos multivariantes propuestos en la bibliografía. Así, observar las posibles tendencias de los datos o utilizarlos para determinar un parámetro dado requiere el uso de las herramientas multivariantes para clasificar o para cuantificar, respectivamente. 5.1 Diseño experimental para la optimización de procesos analíticos Factores experimentales y respuesta Las variables o condiciones experimentales que afectan a un determinado proceso o producto reciben el nombre de factores en la terminología del diseño de experimentos. Los factores se clasifican en cualitativos (por ejemplo, el uso de un determinado reactivo) y cuantitativos (por ejemplo, la presión en un proceso de extracción con un fluido supercrítico). Los diferentes valores que pueden tomar los factores se denominan niveles. Las características del producto o proceso que queremos optimizar se llaman respuestas. Generalmente, cada respuesta se modela separadamente, aunque muchas veces los valores óptimos para las respuestas están en conflicto. Existen métodos de múltiple criterio para resolver estos conflictos [ ] Diseño de experimentos y análisis multivariante En el diseño de experimentos se utiliza el análisis multivariante debido a que una aproximación univariante puede conducir a errores. Se va a suponer un proceso analítico en el que influyen dos factores, x 1 y x 2. Con un enfoque univariante se dejaría un factor fijo, por ejemplo, x 2, y se irían variando los valores para x 1 hasta encontrar el óptimo de este factor. Se estudiaría después el factor x 2 dejando fijo 62

77 Introducción x 1 en el valor óptimo. Cuando se obtuviera el valor óptimo para x 2 la optimización habría finalizado. Este método sólo es correcto cuando los factores no interaccionan entre sí. Además, si el número de factores es muy elevado, el proceso es largo y engorroso. Por tanto, el procedimiento más correcto es recurrir a métodos secuenciales o simultáneos, que se comentan más adelante Estrategias en el diseño de experimentos Los primeros pasos a seguir en el diseño de experimentos son la selección de los factores y las respuestas. Aunque se pueden conocer de antemano los factores que influyen en la respuesta, no es una información con la que se cuente normalmente como punto de partida. Por lo tanto, hay que tener en cuenta todos los posibles factores y hacer un screening con el objetivo de descartar los factores no influyentes. Antes del screening se define el dominio experimental, en el que se establecen los valores extremos para cada factor. Normalmente se emplea el diseño de dos niveles, aunque existen otras aproximaciones; por ejemplo, el diseño de Doehlert [180]. Tras el screening, y una vez elegidos los factores, las respuestas y los niveles, el siguiente paso es la selección de la metodología de diseño a utilizar entre dos grandes grupos: el secuencial o el simultáneo Método secuencial Simplex El diseño secuencial está basado en la realización de pocos experimentos que se usan para determinar las condiciones del próximo experimento. El diseño más empleado de este tipo es el método Simplex [181,182]. Para explicar brevemente en qué consiste, se suponen de nuevo dos factores, x 1 y x 2. Se empieza con la realización de tres experimentos situados en un triángulo en el plano formado por x 1 y x 2. El experimento que dé peor respuesta indica que la dirección tiene que ser la contraria a la que lleva a este vértice del triángulo. Por tanto, se construye un 63

78 Manuel Urbano Cuadrado Tesis Doctoral nuevo triángulo formado por los dos vértices anteriores que dieron las mejores respuestas y el vértice opuesto al que proporcionó el peor resultado. El proceso se continúa hasta que la inclusión de un nuevo experimento no mejora los resultados obtenidos. El principal inconveniente de este método radica en la dependencia de la calidad del diseño (superficie de respuesta) de la ruta escogida para alcanzar el máximo, por lo que presenta connotaciones azarosas Métodos simultáneos Entre los diseños simultáneos, también llamados diseños factoriales, se pueden distinguir dos tipos con distinta filosofía de trabajo: a) Diseños en los que los objetivos son establecer/conocer qué factores influyen y en qué magnitud lo hacen. El diseño más usado dentro de este tipo es el denominado diseño factorial completo de dos niveles, en el que para cada factor se consideran dos niveles. Este método permite calcular el efecto de los factores y sus interacciones. El número de experimentos a llevar a cabo es 2 n, donde n es el número de factores. Una modalidad de este tipo de diseños son los denominados diseños factoriales fraccionarios, en los que sólo se lleva a cabo una fracción de los experimentos (1/2, 1/4, 1/8, etc.). Aunque la información obtenida es menor, su uso es práctico cuando el número de factores es muy alto. En los casos en los que las interacciones entre factores no influyen y sólo se quiere conocer qué factores son relevantes, se emplean los diseños factoriales fraccionarios saturados [183] o los de Plackett-Burman [184]. Son útiles para procesos de screening de factores. También se han empleado en el estudio de la robustez de métodos analíticos [185]. b) Diseños en los que la importancia radica en la obtención de la función de respuesta en el punto óptimo. Las funciones de respuesta para dos factores y una única respuesta vienen dadas por las siguientes expresiones: 64

79 Introducción y = b 0 + b 1 x 1 + b 2 x 2 + b 12 x 1 x 2 (1) y = b 0 + b 1 x 1 + b 2 x 2 + b 11 x b 22 x b 12 x 1 x 2 (2) En estas ecuaciones se pueden observar: Un término independiente b 0, que será igual al valor de y cuando x 1 y x 2 son cero. La mayoría de las veces se suele trabajar con valores codificados donde se le dan los valores -1 y +1 a los extremos elegidos para cada factor, por lo que 0 corresponde al valor intermedio del rango entre -1 y +1. En estos casos, b 0 es el valor de y en el centroide. Términos de primer orden en la ecuación (1) y (2), y de segundo orden en la ecuación (2) para x 1 y x 2. Los términos de la interacción ente x 1 y x 2 (último sumando de las ecuaciones (1) y (2)). Cuando se usa la ecuación (2) se consideran tres niveles para cada factor con el fin de tener en cuenta los términos cuadráticos de esta ecuación. El modelo más empleado de este tipo es el diseño central compuesto, que tiene en cuenta dos niveles y varias réplicas de los puntos centrales. 5.2 La quimiometría en el tratamiento de la información espectroscópica La necesidad del análisis multivariante en espectroscopía Las técnicas espectroscópicas han experimentado un gran avance en los últimos años que ha dado lugar a nuevos métodos analíticos. Una de las zonas espectrales más utilizadas ha sido la del infrarrojo, surgiendo la tecnología NIRS (de las siglas en inglés Near InfraRed Spectroscopy), que ha sido incorporada en el control de calidad en muchos campos, especialmente en las áreas agroalimentaria, farmacéutica, química, petroquímica y ambiental [ ]. Otra técnica también muy extendida por las mismas razones es la relacionada con 65

80 Manuel Urbano Cuadrado Tesis Doctoral otras zonas del espectro IR, además de técnicas como la Resonancia Magnética Nuclear, la Espectroscopía Raman, la Espectrometría de Masas, etc. En una parte de la investigación recogida en esta Memoria se han utilizado los datos correspondientes a la absorción en las zonas ultravioleta, visible, infrarrojo cercano e infrarrojo medio. Puesto que la muestra se analiza apenas sin tratar, los espectros recogidos son muy poco característicos y las bandas corresponden a la absorción de un variado número de componentes. La aplicación de la ley de Lambert-Beer a estos espectros es imposible debido a la gran cantidad de datos, la colinealidad de éstos y, por tanto, su redundancia. Una aproximación univariante carece de sentido en este tipo de espectros [189,190]. Además, los datos espectroscópicos están afectados por diversos tipos de error, entre los que destacan el ruido intrínseco del instrumento y los relacionados con la heterogeneidad, textura, estabilidad, etc., de las muestras a analizar. Por todo lo expuesto se hace necesario el uso de diversas herramientas quimiométricas basadas todas ellas en el Análisis Multivariante, que abarca los diferentes métodos estadísticos, matemáticos, o gráficos para el análisis de datos que usan de forma simultánea varias variables [191,192]. En el caso de las técnicas espectroscópicas, el análisis multivariante tiene dos objetivos: 1) la determinación de una o varias propiedades físico-químicas a partir de múltiples variables espectrales (valores de absorbancia a diferentes longitudes de onda); 2) la diferenciación o la clasificación de grupos de muestras con características comunes a partir de la información espectral Preprocesamiento de los datos espectrales Uno de los aspectos que más interfiere en la información espectral es la dispersión de la radiación incidente (conocida en la bibliografía espectroscópica como Efecto Scatter) [ ]. Es un fenómeno físico provocado por la interacción no relacionada con fenómenos de absorción entre la radiación y la muestra, sino con la dispersión causada por el tamaño y la geometría de las 66

81 Introducción partículas que existen en la muestra. También intervienen en su origen los cambios en el índice de refracción. Con el fin de minimizar el efecto de dispersión scatter se ha desarrollado una serie de soluciones para el preprocesamiento de los datos espectroscópicos. Entre ellas se encuentran los tratamientos MSC (de las siglas en inglés de Multiplicative Scatter Correction), SNV (Standard Normal Variate), DTR (Detrending) y OSC (Orthogonal Signal Correction) [197,193]. Otro tipo de transformación de los datos espectroscópicos es el tratamiento de derivadas, que tiene el objetivo de disminuir tanto la superposición de picos, como la variación de la línea de base del espectro (esto último aumenta la relación señal/ruido). También son numerosos los métodos de derivadas, entre los que se destacan el de Savitzky-Golay y el de las diferencias finitas, y las transformadas de Fourier [198,199,190]. La normalización y escalado de los datos también son métodos de preprocesamiento empleados en espectroscopía con el objetivo de igualar la influencia de todas las variables que componen el espectro. 5.3 Análisis cualitativo En análisis cualitativo los datos espectroscópicos, sometidos o no a un preprocesamiento, se utilizan con el fin de calcular una variable categórica, por ejemplo, origen, variedad, tipo de proceso, etc. Es decir, la información espectral se emplea para la clasificación de muestras en diferentes grupos atendiendo a la similitud de sus espectros respecto a otros de muestras conocidas. Estos métodos son conocidos con el nombre de Métodos de Reconocimiento de Pautas o Patrones [54]. Suelen distinguirse dos grupos de estos métodos: supervisados y no supervisados, en función de la información del agrupamiento de datos de que se dispone a priori. En los métodos no supervisados no se dispone de información de las muestras analizadas o, si se dispone, es escasa. El objetivo, por tanto, es 67

82 Manuel Urbano Cuadrado Tesis Doctoral poner de manifiesto tendencias que están ocultas en la matriz de datos formada por los espectros de las muestras. Son métodos que se aplican en las primeras etapas de la investigación de la clasificación de muestras y, según la discriminación alcanzada por éstos, la posterior fase de clasificación conducirá a mejores o peores resultados. Los métodos más frecuentes en la bibliografía son el Análisis de Cluster y el Análisis de Componentes Principales. Por el contrario, los métodos supervisados sí cuentan con las categorías existentes en el colectivo de muestras, y el objetivo es la síntesis de reglas, empleando la información de partida de los tipos de muestras para la clasificación de muestras desconocidas. En los métodos supervisados se distingue entre métodos discriminantes y métodos de modelado. El objetivo de los primeros es discriminar entre las categorías existentes de forma que una determinada muestra se clasifica dentro de alguno de los tipos existentes. Los métodos discriminantes que más se han empleado son el Análisis Discriminante Lineal (ADL) y su derivado Análisis Discriminante Cuadrático (ADC). También son importantes el método de los vecinos más cercanos, más conocido como KNN (de las siglas en inglés de k- nearest neighbour), los métodos de densidad y los basados en el análisis discriminante mediante regresión. Este último se basa en una calibración donde las variables de salida son discretas y toman el valor de la clase a la que corresponden. En los métodos de modelado, a diferencia de los anteriores, se define un volumen de espacio para cada una de las clases, de tal forma que puede haber muestras que no pertenezcan a ninguna clase. La filosofía de este tipo de métodos es clasificar según la similitud dentro de una misma clase, y no por discriminación entre clases. La clasificación de las muestras desconocidas se basa en los valores de distancia a una referencia distinta según el modelo usado. Se emplean diferentes tipos de medida de distancia, entre las que se encuentran la distancia euclidea y la de Mahalanobis [200,201]. El método de modelado más empleado para la clasificación de muestras según datos espectroscópicos es el 68

83 Introducción método SIMCA (de las siglas en inglés de Soft Independent Modelling of Class Analogies). En análisis cualitativo existen diferentes métodos basados en la técnica de redes neuronales. Estos métodos pueden ser tanto no supervisados (por ejemplo, las Redes Kohonen), como supervisados (por ejemplo, la máquina de aprendizaje lineal, más conocida por sus siglas en inglés, LLM, de Linear Learning Machine). Este último se considera uno de los primeros de clasificación supervisados. A continuación se exponen con mayor detalle los métodos que se han utilizado en la investigación presentada en esta Memoria Análisis de clusters En este grupo se encuentra una serie de métodos que permiten, a partir del cálculo de distancias entre objetos o muestras, agruparlos según la similitud o diferencia entre ellos. La salida más frecuente de estos métodos suele ser un dendograma que muestra los agrupamientos de los objetos o muestras. El espacio multidimensional en el que se calculan las distancias es el formado por las m longitudes de onda, es decir, no se lleva a cabo ninguna reducción de variables [202, 173] Análisis de componentes principales (ACP) El ACP se define en la norma ASTM (1990) [203] como el procedimiento matemático que se emplea para transformar un conjunto de datos en nuevas variables ortogonales, denominadas componentes principales (CPs), siendo estas últimas una combinación lineal de las variables de partida (cada longitud de onda en el caso de las técnicas espectroscópicas). Es decir, en el ACP se realiza una síntesis de nuevas variables, intentando explicar cada una de estas nuevas variables la máxima variación de los datos. El número de variables finales es menor que el número de variables de partida, por lo que, junto con algunos métodos discriminantes, se les denomina métodos de reducción de variables. 69

84 Manuel Urbano Cuadrado Tesis Doctoral Existen variados criterios para seleccionar el número de CP a partir del cual el modelo no aporta más información, es decir, la varianza explicada por dos componentes consecutivas es prácticamente la misma. Tres causas justifican el uso del ACP en el tratamiento de la información espectroscópica. La primera es el alto grado de colinealidad presente en el espacio original de los datos, hecho éste que se elimina con una de las características de las nuevas variables construidas: son ortogonales, y por lo tanto, linealmente independientes. En segundo lugar, cabe destacar el reducido número final de variables, siendo más fácil la visualización de tendencias de los datos en este espacio que en el de partida. En tercer lugar, y relacionado con la anterior característica, la reducción de variables es clave para el uso de las CP en la construcción de modelos, tanto cuantitativos como cualitativos, usando métodos basados en el ACP. De nuevo, el número grande de variables iniciales supone prácticamente la imposibilidad de llevar a cabo la etapa de calibración o aprendizaje (en términos cuantitativos o cualitativos, respectivamente) por el número de muestras que se necesitarían. Se ha comentado que una CP es una combinación lineal de las m longitudes de onda iniciales, como se observa en la siguiente expresión: CP i = a i1 * λ 1 + a i2 * λ a im * λ m (3) La primera CP es el resultado de la combinación lineal de las longitudes de onda de forma que ésta explique la máxima variación presente en los datos. La segunda CP se elige para que explique de nuevo la máxima variabilidad de los datos, una vez restada la variabilidad explicada por la primera, y con la condición de ser ortogonal con la primera. Así se procede hasta que no hay diferencia entre la varianza explicada por dos componentes consecutivas. Los coeficientes de las longitudes de onda para cada componente principal se denominan loadings o pesos. Son interesantes los gráficos donde se representan los pesos frente a las longitudes de onda, ya que se puede deducir a 70

85 Introducción partir de ellos las zonas espectrales que más interesan por su elevado peso en una determinada CP. Los scores o autovalores son las coordenadas de las muestras en los nuevos ejes formados por las CP. Cuando los objetos o muestras se sitúan en el nuevo espacio, denominado gráfico de scores, existe la posibilidad de distinguir agrupamientos en los objetos, lo que resulta imposible en el anterior espacio Análisis discriminante lineal (ADL) y análisis discriminante cuadrático (ADC) En este grupo, las categorías o clases existentes en el colectivo de aprendizaje se separan a partir de una combinación lineal de variables que minimiza la variabilidad dentro de las muestras de una misma clase y la maximiza cuando se trata de grupos diferentes [204,205]. A partir de estas combinaciones lineales se genera un número de funciones lineales una unidad menor que el número de clases. Por lo tanto, y junto con el ACP, también es un método en el que se lleva a cabo una reducción de variables. Las nuevas funciones, también denominadas variables latentes, se seleccionan teniendo en cuenta las direcciones con las que se consigue la máxima separación entre las clases. Ésta es la principal diferencia del análisis discriminante respecto al ACP, pues en este último la obtención de las CP está basada en la búsqueda de direcciones que expliquen la mayor variabilidad de los datos, lo que resulta del hecho de que un método es supervisado y el otro no. Se asume una distribución normal de las variables empleadas y la igualdad entre las matrices de covarianza, empleando como criterio de clasificación la distancia de Mahalanobis. El hecho de asumir la igualdad de las matrices de covarianza puede conducir a errores, ya que no siempre se alcanza la igualdad, surgiendo una variante del ADL. En este tipo de métodos se generan funciones cuadráticas, de ahí el nombre de análisis discriminante cuadrático. 71

86 Manuel Urbano Cuadrado Tesis Doctoral SIMCA (Soft Independent Modelling of Class Analogies) SIMCA es un método de modelado [206,207] en el que se realiza un ACP para cada una de las clases que se pretende modelar. Existen tres posibilidades a la hora de clasificar una muestra usando un modelo SIMCA: la muestra no pertenece a ninguna de las clases que componen el sistema de modelado, pertenece a una de ellas o, puede pertenecer a dos o más clases. La última opción se dará siempre que solapen dos clases y la muestra a clasificar se ubique en la zona de solapamiento. Hay dos criterios para ubicar una muestra en una determinada clase: la distancia de la muestra al centro del modelo y la distancia de la muestra al modelo. En el primer caso, la distancia informa sobre la varianza que queda explicada por el modelo de una determinada clase cuando la muestra se proyecta sobre el espacio de componentes principales de esta clase. En la segunda opción, informa sobre la varianza que no ha podido explicarse por el modelo, denominándose ésta residual. 5.4 Análisis cuantitativo En esta vertiente del análisis multivariante el espectro correspondiente a una muestra se utiliza para la determinación de sus propiedades físico-químicas. Es decir, pone de manifiesto la información que contiene el espectro sobre composición química de la muestra. Para la determinación de un analito es necesario un proceso de calibración (la construcción de una función que relacione el espectro con la concentración del compuesto o propiedad a determinar). El hecho de emplear las técnicas multivariantes conlleva el cambio del concepto de calibración. Así, el proceso de calibración univariante a través del cual se determina un analito empleando una recta de calibrado que se construye cada cierto tiempo es diferente al proceso empleado en los métodos multivariantes. 72

87 Introducción La diferencia más importante es la derivada de la definición de calibración multivariante, es decir, el desarrollo de un modelo cuantitativo para la determinación de un conjunto de propiedades (y 1, y 2,, y q ) a partir de un número de variables predictoras (x 1, x 2,, x p ). Desde un punto de vista práctico, esta diferencia adquiere connotaciones triviales. Así, la principal diferencia pasa a ser que el objetivo de la calibración en tecnologías como NIRS, RMN, espectroscopía Raman, etc., es la construcción de ecuaciones globales y robustas. El primero de estos términos hace referencia a la aplicabilidad de las ecuaciones a la práctica totalidad de las muestras, mientras que el segundo indica el mantenimiento de la exactitud y precisión a lo largo del tiempo [208,209] Métodos de regresión multivariante lineales Estos métodos se emplean cuando existe una relación lineal entre los datos espectrales (o su transformación a otro espacio de coordenadas, normalmente reducido) y la concentración de los analitos en las muestras. Los métodos lineales más empleados son la regresión lineal múltiple, la regresión por componentes principales y la regresión mediante mínimos cuadrados parciales, más conocidos por sus iniciales del inglés MLR, PCR y PLSR, respectivamente [54]. En la MLR el espectro se considera una función de la composición química de la muestra. Esta consideración hace que la MLR presente una serie de inconvenientes que limitan su aplicabilidad al uso de los datos espectroscópicos. Destacan la dificultad de su aplicación a sistemas complejos como son las muestras reales (el modelo debe recoger también los interferentes o los analitos que no son de interés) y la limitación impuesta por el número de muestras necesarias para la construcción del modelo, que debe ser como mínimo igual al de variables. Por lo arriba expuesto la MLR se lleva a cabo empleando un número reducido de longitudes de onda seleccionadas mediante un test F, de forma que sólo se tienen en cuenta aquellas longitudes de onda que presentan una alta correlación entre el dato de absorbancia y el analito a determinar. Por estos 73

88 Manuel Urbano Cuadrado Tesis Doctoral inconvenientes, además de la utilidad que supone el uso de un método de reducción de variables para la eliminación de la colinealidad de los datos espectroscópicos, se recurre a los métodos PCR y PLSR. Los dos métodos son parecidos en cuanto a que ambos construyen un nuevo espacio de variables reducido respecto al espacio inicial formado por todas las longitudes de onda que conforman el espectro. La diferencia radica en la forma de construcción de las nuevas variables: en la PCR, basada en el ACP, se construyen de forma que explique la mayor variabilidad de los datos espectroscópicos; en la PLSR, junto a la variabilidad de los datos espectroscópicos, se tiene en cuenta también la variación de los datos químicos de las muestras usadas para la construcción del modelo. Tanto PCR como PLSR consideran la composición función del espectro, lo que elimina la limitación de que el número de muestras tiene que ser mayor que el número de variables, aunque ya se haya reducido drásticamente el número de estas últimas Métodos de regresión multivariante no lineales Son numerosas las aplicaciones recogidas en la bibliografía analítica que versan sobre la determinación cuantitativa mediante el uso de redes neuronales. Su interés es capital para los sistemas en los que los datos del espectro no tienen una relación lineal con los datos químicos y, por tanto, los métodos expuestos anteriormente no son adecuados [210]. Son varios los tipos de redes empleados, aunque en número de aplicaciones destaca el tipo MLF, del inglés Multilayer Feed Forward [211,212]. Últimamente está muy extendido también el uso de las redes RBF, del inglés Radial Basis Function [213,214]. Son múltiples las posibilidades de desarrollo de modelos de determinación basados en redes según el tipo empleado, el algoritmo de aprendizaje usado, etc. 74

89 Introducción 5.5 Metodología general en el desarrollo de métodos de determinación Son dos las etapas generales a considerar en el desarrollo de un método de determinación, ya sea cualitativo o cuantitativo: la etapa de calibración o aprendizaje (el primer término se usa en análisis cuantitativo y el segundo en cualitativo) y la etapa de validación [54,208,209]. En la primera se construyen las ecuaciones o modelos (nuevamente la diferente denominación distingue el tipo de análisis) y en la segunda se procede a la verificación de las propiedades requeridas para estas ecuaciones o modelos. La forma de llevar a cabo las dos etapas es diferente, aunque tienen puntos comunes, según el análisis sea cuantitativo o cualitativo Selección de los grupos de aprendizaje o calibración y de validación En el análisis cuantitativo tiene una importancia clave la selección del grupo de calibración, ya que el que se cumpla o no el objetivo de construir ecuaciones globales depende de la representatividad (una de las dos propiedades analíticas supremas) de las muestras empleadas. El número de muestras en la calibración tiene que ser elevado para aumentar la capacidad de determinación de las ecuaciones. La obtención de los datos químicos de referencia conlleva la mayoría de las veces métodos lentos y costosos (de ahí el interés de su sustitución por métodos rápidos basados en la espectroscopía y en el análisis multivariante). Este hecho limita el número de las muestras empleadas en la fase de calibración. Más importante incluso que un número elevado de muestras es la representatividad de éstas. Así, es necesario recoger la variabilidad química existente en las muestras y todas las fuentes de variación en el análisis de muestras futuras (variaciones en la forma y ciclos de producción, procedencia de las muestras, etc.) [ ]. Son numerosos los métodos propuestos para seleccionar el conjunto de calibración, estando la mayoría basados en un análisis 75

90 Manuel Urbano Cuadrado Tesis Doctoral de componentes principales seguido del cálculo, generalmente, de la distancia de Mahalanobis. En el análisis cualitativo los criterios de selección del conjunto de aprendizaje varían ligeramente, siendo la representatividad de las muestras de nuevo la clave para la fiabilidad de los modelos a construir. Como existe una serie de categorías, las muestras de cada tipo deben de estar en una proporción homogénea, cubriendo la máxima variabilidad dentro de una misma clase Detección de anómalos espectrales y anómalos químicos En el desarrollo de los modelos se suele observar la existencia de una serie de muestras que se diferencian del resto debido a anomalías de la información tanto espectral como química. Estas anomalías reducen la capacidad de los modelos, por lo que se procede a una etapa de estudio de los denominados outliers [218,219,189,191,192,198]. Las anomalías espectrales se pueden dar a una determinada longitud de onda, a varias, o en todo el espectro. Para su detección existe, por un lado, una serie de métodos basados en el cálculo de distancias en espacios n-dimensionales, como pueden ser la de Mahalanobis o el estadístico leverage. Por otra parte existen métodos que se basan en el cálculo de residuales en los datos espectroscópicos, es decir, espectros que presentan una variabilidad significativa que no explica el modelo propuesto. El espacio n-dimensional usado suele ser el derivado del ACP. Las anomalías químicas se dan cuando algunas muestras exhiben diferencias significativas en los datos de composición respecto al resto del conjunto de calibración. El dato diferente puede ser el aportado por el método de referencia o bien por la ecuación de calibración. Por tanto, es un tipo de anómalos que se da sólo en el análisis cuantitativo. La detección de los anómalos químicos se lleva a cabo, principalmente, mediante el cálculo de residuales en los datos de composición. El test T, que está basado en la diferencia entre el valor de 76

91 Introducción referencia y el valor estimado, además de la dispersión de los datos, es el más empleado para la detección de los outliers químicos. Una vez detectados los anómalos se procede a un estudio de las causas de la desviación que presentan, intentando repetir el análisis de referencia o el espectral siempre que sea posible La etapa de calibración o aprendizaje Una vez eliminada la influencia de los outliers en el colectivo de calibración o aprendizaje se realiza la etapa correspondiente (calibración o aprendizaje). Si el análisis es cuantitativo la calibración puede evaluarse internamente mediante el coeficiente de determinación y el error estándar obtenido en la calibración. Otros parámetros de la correlación entre el método de referencia y el método espectroscópico son la pendiente y la ordenada en el origen, pero se aplican más en la etapa posterior de validación. En análisis cualitativo se establecen las reglas de clasificación, no obteniéndose en esta etapa estadísticos que indiquen la fiabilidad de las reglas. La etapa posterior de validación sí proporcionará los parámetros apropiados para la evaluación de las reglas. De todas formas, el realizar un análisis exploratorio (ACP y análisis de clusters) antes de la construcción de las reglas da una idea general sobre las características de los futuros modelos La etapa de validación en análisis cuantitativo En la etapa de validación se mide la capacidad de predicción de los modelos construidos mediante diferentes criterios estadísticos basados en la diferencia entre los valores de referencia y los valores estimados por los métodos espectroscópicos. Para ello se emplea un conjunto de muestras que, con la excepción de la validación cruzada, está formado por muestras que no han intervenido en la anterior etapa de calibración, denominándose a éste, conjunto de validación. 77

92 Manuel Urbano Cuadrado Tesis Doctoral La modalidad de validación cruzada fue descrita por Stone en 1974 [220], y es de gran utilidad en los casos en que el número de muestras de las que se posee información química es reducido. Para paliar este inconveniente se forma un conjunto de calibrado del que se extrae un pequeño subconjunto de muestras que no van a intervenir en la calibración y sí en la validación del modelo. Este proceso se repite hasta que todas las muestras que forman el conjunto global de calibración se han utilizado una vez para la validación. El modelo final es la media de los submodelos formados en cada iteración. Las propiedades analíticas exactitud y precisión son los indicadores empleados para la evaluación del error y la capacidad de determinación del nuevo método. En métodos cuantitativos, el coeficiente y el error de la determinación, y la pendiente y la ordenada en el origen de la correlación entre el método de referencia y el método espectroscópico son los parámetros estadísticos usados en el estudio de la exactitud y precisión del método. El Error Típico de la Calibración (ETC) es un estimador usado en la propia calibración, por lo que suele ser sobrestimado respecto al Error Típico de la Predicción (ETP), ya que éste tiene en cuenta muestras no usadas en la etapa de calibración, por lo que es mucho más útil que el ETC. Si se trabaja con validación cruzada, el parámetro se denomina Error Típico de la Validación Cruzada (ETVC) [189,192,209,219]. El ETP puede dividirse en dos partes: el error aleatorio o no explicado, y el error sistemático o sesgo [221,54]; lo que puede observarse en la conocida fórmula de partición de la varianza del error: ETP 2 = sesgo 2 + ETP(C) 2 (4) Donde el ETP(C) informa sobre los errores aleatorios. Algunos autores afirman que el ETP representa la exactitud de una ecuación, mientras que el ETP(C) evalúa la precisión [189]. En la literatura sobre calibración multivariante no hay un uso constante de la denominación de estos estadísticos, denominando algunos 78

93 Introducción autores y algunos programas informáticos (por ejemplo el Unscrambler) ETP(C) al ETP. Otros autores centran el interés del ETP en la influencia de la calidad del dato de referencia [222]. Así, el ETP se expresa de la siguiente forma: ETP 2 = ETL 2 + ET Esp 2 + ET Modelo 2 (5) Donde el ETL es el error típico del método de referencia, ET Esp es el error típico debido a la medida espectral, y ET Modelo es el error introducido por el método quimiométrico. De los tres, y gracias a las mejoras alcanzadas en las técnicas espectrales y en los métodos quimiométricos, es el error asociado al método analítico de referencia el que tiene un mayor peso en la fórmula anterior. Se proponen diferentes formas de evaluar y comparar el coeficiente de determinación y el ETP en el desarrollo de una aplicación cuantitativa basada en datos espectroscópicos, la mayoría de las veces datos NIR. La pendiente y la ordenada en el origen de la recta de correlación entre el método espectroscópico y el método de referencia también son dos parámetros importantes para la visualización de errores sistemáticos. La pendiente tiene que ser igual a uno y la ordenada tiene que ser igual a cero para una perfecta correlación entre los métodos. Obviamente éste es un caso ideal, siendo necesaria la realización de un test de hipótesis para ver si son estadísticamente igual a uno y a cero. Algunas organizaciones han redactado un protocolo para la validación de nuevos métodos de análisis frente a los de referencia u oficiales. Estos protocolos suelen recoger la realización del test T para diferentes intervalos de confianza y grados de libertad. En la investigación recogida en esta Memoria se ha utilizado el protocolo propuesto por la Oficina Internacional de la Viña y del Vino (OIV) [223], ya que los métodos desarrollados corresponden al campo enológico. 79

94 Manuel Urbano Cuadrado Tesis Doctoral La etapa de validación en el análisis cualitativo En la validación de una aplicación cualitativa el error es el principal indicador de la fiabilidad [224]. El error en este caso se calcula de una forma mucho más simple, ya que se atribuye al porcentaje de muestras clasificadas de forma incorrecta. El proceso de validación puede ser externo (con muestras que no han participado en el establecimiento de las reglas de clasificación) o llevarse a cabo mediante validación cruzada. Cuando se trata de un método de modelado en el que las muestras no tienen forzosamente por qué pertenecer a una clase, este estadístico tiene que ser modificado para adaptarlo al nuevo modelo. Surgen los conceptos de falsos positivos y falsos negativos. Los primeros corresponden a aquellas muestras que se clasifican dentro de una clase sin pertenecer a ella, mientras que los falsos negativos son las muestras que no se clasifican en sus respectivas clases. Varios autores proponen estrategias para el desarrollo y evaluación de modelos cualitativos [189,207]. 6. Química computacional: índices de similitud y huellas digitales La química computacional engloba una serie de métodos matemáticos y estadísticos, implantados en el ordenador mediante algoritmos, que se emplean en diversas áreas de la química, la mayoría de carácter teórico. Entre estas áreas destacan la mecánica cuántica, la determinación estructural, y el estudio de reacciones químicas [225,226]. El campo de aplicación se extendió ya desde su creación, abarcando áreas de índole más práctica como pueden ser la espectroscopía, la química analítica (métodos de regresión y de reconocimiento de patrones), y la química farmacéutica (QSAR, de las siglas Quantitative Structure-Activity Relationships, y química combinatoria) [ ]. 80

95 Introducción Los métodos y herramientas utilizados en la química computacional son de muy variada naturaleza. Por un lado se emplean las herramientas y métodos propiamente informáticos, como son las bases de datos, la lógica difusa, la teoría de la información, el hardware, etc.; por otro lado es necesario el desarrollo de utilidades algorítmicas que implantan una serie de métodos matemáticos y estadísticos con varios fines. De éstos destacan el cálculo de descriptores moleculares, los métodos de regresión (esta parte es quimiométrica pues se suelen usar regresiones PLS), el cálculo de similitudes, etc. 6.1 Aplicaciones de la química computacional Especial relevancia está adquiriendo hoy en día el diseño de fármacos por ordenador, que ha convertido la química computacional en una de las herramientas clave en la industria farmacéutica [ ]. Los métodos computacionales han elevado el papel de la informática en este sector, dejando de lado el concepto de almacenamiento de los compuestos moleculares que poseían las bases de datos y beneficiándose de las técnicas de minería de datos (data mining). Estas últimas permiten obtener compuestos de una base de datos mediante consultas cuyo criterio se centra en la actividad biológica de un determinado tipo de fármacos. Así, se pueden obtener los compuestos y sus propiedades sin el costoso proceso de su síntesis y purificación. Gran parte de los avances de la química computacional en farmacia son debidos al desarrollo de las bibliotecas de química combinatoria, que es una de las modalidades de construcción de bases de datos en química computacional. Se basa en el almacenamiento de pequeños fragmentos o subestructuras que se utilizan para hacer una síntesis de un compuesto de manera automática siguiendo una serie de reglas [237,238,232]. La teoría de la información basada en el cálculo de probabilidades, incertidumbre y entropía, también se ha usado con diversos fines en química. Así, se ha utilizado en la identificación de sustancias en cromatografía de capa 81

96 Manuel Urbano Cuadrado Tesis Doctoral fina, en la obtención de la máxima información de procedimientos que combinan diversos métodos analíticos, elección de fases móviles en cromatografía de gases, análisis de datos, etc. [ ]. Los conjuntos difusos, más conocidos por su acepción inglesa fuzzy sets, permiten modelar situaciones analíticas imprecisas. La definición de los conjuntos difusos y las operaciones a las que se someten fueron propuestas por Zadeh en 1965 [246]. Su utilidad radica en la resolución de problemas en los que un elemento no se puede asignar a un determinado conjunto de forma discreta y clara. Han encontrado aplicaciones tanto en quimiometría (en la identificación de patrones y en los métodos de regresión) [247,248], como en el desarrollo de sistemas expertos [249]. El cálculo de similitud estructural y espectral es una de las últimas tendencias en química computacional [ ]. Se va a tratar en mayor extensión al ser una de las herramientas usadas por el doctorando. 6.2 Índices de similitud y huellas digitales Cálculo de similitud estructural El cálculo de similitudes se ha utilizado en aspectos estructurales mayoritariamente, aunque últimamente también se ha aplicado en cálculos de similitud espectral. Se han propuesto numerosos parámetros para medir la similitud entre dos objetos, destacando en química computacional los denominados índices de similitud [257]. El más utilizado es el Índice de Tanimoto (IT), que calcula la similitud entre dos cadenas de bits de igual tamaño, A y B, mediante la siguiente expresión: T A B c, = (6) a + b c donde: a es el número de bits igual a 1 en la cadena A. 82

97 Introducción b es el número de bits iguales a 1en la cadena B. c es el número de bits iguales a 1 comunes en las cadenas A y B, es decir, que están en la misma posición. El IT varía entre cero y uno, de forma que cuanto mayor sea el valor, más similitud exhiben las cadenas. La forma de construir las cadenas de bits es diferente según el área donde se aplica el método de Tanimoto. En el cálculo de la similitud estructural entre dos compuestos, las cadenas de bits son representativas de un determinado compuesto, recibiendo el nombre de huellas digitales o, más comúnmente, el de su traducción inglesa, fingerprints. Se construyen a partir de la tabla de conexión (teoría de grafos), que a su vez deriva de la estructura en dos dimensiones del compuesto químico. Posibilita la transformación de las complejas estructuras moleculares a cadenas de bits, que se pueden tratar fácilmente por ordenador. La principal aplicación radica en la búsqueda de compuestos químicos en las bases de datos. Se reduce el tiempo de consulta gracias a que la comparación se lleva a cabo sólo entre la estructura problema y los compuestos que presentan un índice de similitud igual o mayor que un valor límite que introduce el usuario Calculo de similitud espectral El cálculo de la similitud espectral se ha utilizado la mayoría de las veces con el fin de identificar compuestos a través de la interpretación del espectro o la comparación del espectro problema con los almacenados en una base de datos de espectros. En la bibliografía aparecen descritos varios parámetros para medir la similitud espectral en la espectroscopía de infrarrojo y en la de masas [258]. En otras aplicaciones se ha usado el cálculo de la similitud espectral junto con otras técnicas computacionales y quimiométricas para la siempre difícil tarea de interpretar el espectro [ ] con el fin de elucidar una estructura molecular no almacenada en la base de datos. Con este objetivo, algunos autores han utilizado los dos tipos de cálculo de similitud (el estructural y el espectral) 83

98 Manuel Urbano Cuadrado Tesis Doctoral [255,256]. Sin embargo, no se ha encontrado una buena relación entre ambos tipos de similitudes Cálculo de similitud en química analítica El cálculo de similitudes es interesante en análisis cualitativo en química analítica al proporcionar un valor de semejanza entre dos muestras. El cálculo de distancias (en diferentes espacios multidimensionales), como se vio en el apartado de quimiometría, es el usado en la casi totalidad de los casos. Aparte de las redes, no son usuales los métodos de cálculo de similitud basados en parámetros distintos a la distancia. Sólo una aplicación [262] aparece en la bibliografía del uso del índice de Tanimoto para la clasificación de muestras a partir de los datos obtenidos por cromatografía de gases. Por tanto, es interesante el estudio de las formas de construcción de huellas digitales a partir de espectros para la clasificación de muestras, siendo éste un campo a desarrollar en los próximos años, además de la búsqueda de nuevos índices o parámetros de similitud. 84

99 Referencias 7. Referencias [1] A. Toffler, La Tercera Ola, Plaza & Janes S.A., Barcelona, [2] J. Naisbitt, Megatrends, Ten New Directions Transforming Our Lives, Warners Books, Nueva York, [3] S. Green, Information Systems Design, Thomson Computer Press, Londres, [4] I. Luque Ruiz, M.A. Gómez-Nieto, Ingeniería del Software: Fundamentos para el Desarrollo de Sistemas Informáticos, Servicio de Publicaciones de la Universidad de Córdoba, Córdoba, [5] G.E. Bailescu, R.A. Chalmers, Education and Training in Analytical Chemistry, Ellis Horwood, Chichester, [6] A. Prieto Espinosa, A. Lloris Ruiz, J.C. Torres Cantero, Introducción a la Informática, Tercera Edición, McGraw-Hill, Madrid, [7] J. Agar, Turing and the Universal Machine: the Making of the Modern Computer, Icon Books, Cambridge, [8] J.G. Brookshear, Computer Science: an Overview, Sixth Edition, Addison- Wesley, [9] F. Vogt, M. Karlowatz, M. Jakusch, B. Mizaikoff, Analyst 128(4) (2003) 397. [10] D.L. Pfeil, A. Reed, Int. Lab. 32(2) (2002) 23. [11] J.Y.K. Hsieh, L. Lin, W. Fang, B.K. Matuszewski, J. Liq. Chromatogr. Relat. Technol. 26 (2003) 895. [12] L. Wendler, J. Miller, Am. Lab. (Shelton, Conn) 33(16) (2001) 18, 20, 22, 24. [13] J.Y. Neira, N. Reyes, J.A. Nóbrega, Lab. Rob. Autom. 12(5) (2000) 246. [14] A. MacDonald, Am. Lab. (Shelton, Conn) 28(8) (1996) 29. [15] R. Raso, H.W. Fehlhaber, Rapid Commun. Mass Spectrom. 9 (1995) [16] K. Dettmer, L. Stieglitz, Chemosphere 29 (1994)

100 Manuel Urbano Cuadrado Tesis Doctoral [17] R.C. Luders, L.A. Brunner, J. Chromatogr. Sci. 25(5) (1987) 192. [18] A.M. Tabert, J. Griep-Raming, A.J. Guymon, R.G. Cooks, Anal. Chem. 75 (2003) [19] Y.Q. Xia, J.D. Miller, R. Bakhtiar, R.B. Franklin, D.Q. Liu, Rapid Commun. Mass Spectrom. 17 (2003) [20] Z. Karpas, W. Chaim, R. Gdalevsky, B. Tilman, A. Lorber, Anal. Chim. Acta 474(1) (2002) 115. [21] T.L. Buxton, P. de B. Harrington, Appl. Spectrosc. 57(2) (2003) 223. [22] J.R. Johnson, F.Y. Meng, A.J. Forbes, B.J. Cargile, N.L. Kelleher, Electrophoresis 23 (2002) [23] C.E. Lenehan, N.W. Barnett, S.W. Lewis, J. Autom. Methods Manage. Chem. 24(4) (2002) 99. [24] T.R. McJunkin, P.L. Tremblay, J.R. Scott, J. Assoc. Lab. Automat. 7(3) (2002) 76. [25] H.T. Chueh, J.V. Hatfield, Sens. Actuators, B 83B(1-3) (2002) 262. [26] O.O. Soyemi, M.A. Busch, K.W. Busch, J. Chem. Inf. Comput. Sci. 40 (2000) [27] E. Maire, E. Lelievre, D. Brau, A. Lyons, M. Woodward, V. Fafeur, Anal. Biochem. 280(1) (2000) 118. [28] A. Krauss, U. Weimar, W. Goepel, Trends Anal. Chem. 18 (1999) 312. [29] M.M. Gónzalez-García, F. Sánchez-Rojas, C. Bosch-Ojeda, A. García de Torres, J.M. Cano Pavón, Anal. Bioanal. Chem. 375 (2003) [30] E. Becerra, A. Cladera, V. Cerdá, Lab. Rob. Autom. 11(3) (1999) 131. [31] G.K. Taylor, Y.B. Kim, A.J. Forbes, F.Y. Meng, R. McCarthy, N.L. Kelleher, Anal. Chem. 75 (2003) [32] D. Chelius, T. Zhang, G.H. Wang, R.F. Shen, Anal. Chem. 75 (2003) [33] J. Gallardo, S. Alegret, R. Muñoz, M. de Román, L. Leija, P.R. Hernández, M. del Valle, Anal. Bioanal. Chem. 377(2) (2003)

101 Referencias [34] F. Dieterle, B. Kieser, G. Gauglitz, Chemom. Intell. Lab. Syst. 65(1) (2003) 67. [35] P.S. Williams, M.C. Giddings, J.C. Giddings, Anal. Chem. 73 (2001) [36] P. Courcoux, M.F. Devaux, B. Bouchet, Chemom. Intell. Lab. Syst. 62(2) (2002) 103. [37] K.P. Hinz, M. Greweling, F. Drews, B. Spengler, J. Am. Soc. Mass Spectrom. 10 (1999) 648. [38] H. Masui, M. Yoshida, J. Chem. Inf. Comput. Sci. 36(2) (1996) 294. [39] J. Moore, P. Solanki, R.D. McDowall, Chemom. Intell. Lab. Syst. 31(1) (1995) 43. [40] WinISI software, Infrasoft International, Port Matilda, PA, EE.UU. [41] The Unscrambler, Camo Process AS, Oslo, Noruega. [42] Matlab: the Language of Thecnical Computing, The MathWorks, [43] A. Savitzky, M.J.E. Golay, Anal. Chem. 36 (1964) [44] C.G. Enke, T.A. Nieman, Anal. Chem. 48 (1976) 705-A. [45] J. Wang, S. Bollo, J.L.L. Paz, E. Sahlin, B. Mukherjee, Anal. Chem. 71 (1999) [46] R.N. Bracewell, The Fourier Transform and its Applications, McGraw- Hill, Nueva York, [47] G. Quintas, A. Morales Noe, S. Armenta, S. Garrigues, M. de la Guardia, Anal. Chim. Acta 502(2) (2004) 213. [48] W.D. Cao, X.Y. Chen, X.R. Yang, E.K. Wang, Electrophoresis 24 (2003) [49] J.A. McReynolds, P. Edirisinghe, S.A. Shippy, Anal. Chem. 74 (2002) [50] D. Graupe, Identification of Systems, Krieger, Nueva York, [51] R. Ergon, K.H. Esbensen, J. Chemom. 16 (2002) 401. [52] T.L. Cecil, R.B. Poe, S.C. Rutan, Anal. Chim. Acta 250(1) (1991)

102 Manuel Urbano Cuadrado Tesis Doctoral [53] S. Wold, Kemisk Tidskr. 3 (1972) 34. [54] D.L. Massart, B.G.M. Vandeginsten, S. Buydens, S. De Jong, P.J. Lewi, J. Smeyers-Verbeke, Handbook of Chemometrics and Qualimetrics: Parts A and B, Elsevier, Amsterdam, [55] K.H. Esbensen, Multivariate Data Analysis - in Practice, Camo Process AS, Oslo, [56] J.N Miller, J.C. Miller, Estadística y Quimiometría para Química Analítica, Prentice Hall, Madrid, [57] R. Andreu, J.E. Ricart, J. Valor, Estrategias y Sistemas de Información, McGraw-Hill, Madrid, [58] M. Bitton, Spectra Anal. 31(229) (2002) 37. [59] T. Wessa, C. Wegner, Spectra Anal. 31(229) (2002) 34. [60] V. Kershner, Am. Lab. (Shelton, Conn) 34(17) (2002) 22. [61] J.A. Schibler, Am. Lab. (Shelton, Conn). 32(6) (2000) 52, [62] H.M.J. Goldschmidt, M.J.T. Cox, R.J.E. Grouls, W.A.J.H. van de Laar, G.G. van Merode, Lab. Autom. Inf. Manage. 34(1) (1999) 1. [63] R. Pavlis, Int. Labmate. 22(4) (1997) 24. [64] M. Hinton, P.R. Hinton, S. Williams, Am. Lab. (Shelton, Conn) 28(2) (1996) 51. [65] M. Pradella, R. Dorizzi, A. Burlina, Chemom. Intell. Lab. Syst. 17(2) (1992) 187. [66] R. Megargle, Anal. Chem. 61 (1989) 612A-614A, 616A-618A, 620A. [67] T. Staab, T. Shiina, D. Miller, J. Assoc. Lab. Autom. 8(6) (2003) 107. [68] S. Cross, S. Ahmed, Lab. Update. Dec (2000) 16. [69] B.K. Alsberg, R. Goodacre, J.J. Rowland, D.B. Kell, Anal. Chim. Acta 348(1-3) (1997) 389. [70] P. Vankeerberghen, J. Smeyers-Verbeke, D.L. Massart, J. Anal. At. Spectrom. 11(2) (1996) 149. [71] M. Ivandic, W. Hofmann, W.G. Guder, Clin. Chem. (Washington, DC) 42 (1996)

103 Referencias [72] P. Hubert, P. Chiap, M. Moors, B. Bourguignon, D.L. Massart, J. Crommen, J. Chromatogr. A 665 (1994) 87. [73] R. Wehrens, P. Van-Hoof, L. Buydens, G. Kateman, M. Vossen, W.H. Mulder, T. Bakker, Anal. Chim. Acta 271(1) (1993) 11. [74] J. Klaessens, B. Vandeginste, G. Kateman, Anal. Chim. Acta 223(1) (1989) 205. [75] B.W. Boehm, IEEE Trans. Comput. C-25 (1976) [76] R.S. Pressman, Software Engineering: a Practitioner s Approach, McGraw-Hill, Nueva York, [77] D.C. Ince, Ingeniería del Software, Addison-Wesley Iberoamericana, Buenos Aires, [78] I. Sommerville, Software Engineering, Addison-Wesley, Wokingham, [79] W.W. Royce, Managing the Development of Large Software Systems: Concepts and Techniques, Proc. WESCON, [80] M. Hanna, Software Magazine, Mayo (1995) 38. [81] M. Bradac, D. Perry, L. Votta, IEEE Trans. Softw. Engineer. 20 (1994) 774. [82] J. Kerr, R. Hunter, Inside RAD, McGraw-Hill, Nueva York, [83] J. Martin, Rapid Application Development, Macmillan International Editions, Nueva York, [84] F. Brooks, The Mythical Man-Month, Addison-Wesley, Reading, [85] J. McDermid, P, Rook, Software Development Process Models, Software Engineer s Reference Book, 15/26-15/28, CRC Press, [86] B. Boehm, Computer 21(5) (1988) 61. [87] A. Davis, Software Requirements: Objects, Functions and States, Prentice Hall, Englewood Cliffs, [88] R. Zultner, Am. Programmer, Febrero (1992)

104 Manuel Urbano Cuadrado Tesis Doctoral [89] Y. Asao (ed.) Quality Finction Deployment: Integrating Customer Requirements in Product Design, Productivity Press, Cambridge, [90] T. DeMarco, Structured Analysis and System Specification, Prentice Hall, Englewood Cliffs, [91] M. Page-Jones, The Practical Guide to Structured Systems Design, Yourdon Press, Nueva York, [92] G. Booch, Object Oriented Analysis and Design with Applications, Benjamin Cummings, Redwood City, [93] P. Coad, E. Yourdon, Object Oriented Analysis, Prentice Hall, Englewood Cliffs, [94] K.S. Rubin, A. Goldberg, Communic. ACM 35(9) (1992) 48. [95] P. Chen, The Entity-Relationship Approach to Logical Database Design, QED Information Sciences, Wellesley, [96] D.J. Hatley, I.A. Pirbhai, Strategies for Real-Time System Specification, Dorset House, Nueva York, [97] P.T. Ward, S.J. Mellor, Structured Development for Real-Time Systems, Yourdon Press, Nueva York, [98] E.S. Taylor, An Interim Report on Engineering Design, Massachusetts Institute of Technology, Cambridge, [99] J. Warnier, Logical Construction of Programs, Van Nostrand Reinhold, Nueva York, [100] W. Stevens, G. Myers, L. Constantine, IBM Systems J. 13(2) (1974) 15. [101] O. Dahl, E. Dijkstra, C. Hoare, Structured Programming, Academic Press, Nueva York, [102] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns, Addison-Wesley, Reading, [103] I. Jacobson, Object-Oriented Software Engineering, Addison-Wesley, Reading, [104] C.H. Koebel, D.B. Loveman, R.S. Schreiber, G.L.S. Jr, M.E. Zosel, The High Performance Fortran Handbook, The Mit Press, Cambridge,

105 Referencias [105] S.C. Herbert, C: The Complete Reference Fourth Edition. McGraw- Hill, Nueva York, [106] A. Goldberg, D. Robson, Smalltalk-80: the Language, Addison Wesley, Reading, [107] M. Campione, The Java Tutorial Third Edition. McGraw-Hill, Nueva York, [108] IP.G. Frankl, S. Weiss, IEEE Trans. Softw. Engineer. 19 (1993) 770. [109] S.C. Ntafos, IEEE Trans. Softw. Engineer. 16 (1988) 868. [110] P.G. Frankl, E.J. Weyuker, IEEE Trans. Softw. Engineer. 14 (1988) [111] G. Myers, The Art of Software Testing, Wiley, Nueva York, [112] T. McCabe, IEEE Trans. Softw. Engineer. 2 (1976) 308. [113] E.V. Berard, Essays on Object-Oriented Software Engineering, Addison-Wesley, Reading, [114] D. A. Taylor, Object-Oriented Technology: A Manager s Guide, Addison-Wesley, Reading, [115] M. Cashman, CM Softw. Engineer. Notes 14(6) (1989) 67. [116] G. Booch, IEEE Trans. Softw. Engineer. SE-12 (1986) 211. [117] O. Nierstrasz, S. Gibbs, D. Tsichritzis, Communic. ACM, 20(1) (1992) 160. [118] E. Yourdon, Applic. Develop. Strateg. VI(12) (1994) 1. [119] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, Object- Oriented Modeling and Design, Prentice-Hall, Englewood Cliffs, NJ, [120] J. Rumbaugh, I. Jacobson, G. Booch, The Unified Modeling Language. Reference Manual, Addison-Wesley, Reading, [121] G. Booch, J. Rumbaugh, I. Jacobson, The Unified Modeling Language. User Manual, Addison-Wesley, Reading, [122] I. Jacobson, G. Booch, J. Rumbaugh, The Unified Software Development Process, Addison-Wesley, Reading,

106 Manuel Urbano Cuadrado Tesis Doctoral [123] H. Schildt, P. Naughton, Java. Manual de Referencia, McGraw-Hill, Madrid, [124] J. Zukowski, Java 2. J2SE 1.4, Anaya-Multimedia, Madrid, [125] [126] B. Eckel, Thinking in Java Third Edition, Prentice Hall, Englewood Cliffs, [127] F.J. Ceballos Sierra, El Lenguaje de Programación Java, Ra-ma, Madrid, [128] P. Naughton, The Java Handbook, McGraw-Hill Osborne Media, [129] Java Network Programming, Second Edition, O Reilly, Sebastopol, [130] P.J. Perrone, S.R. Chaganti, T. Schwenk, J2EE Developer s Handbook, Sams Publishing, [131] P. Wainwright, A. Ahmad, M. Link, P. Sarang, Professional Apache 2.0. Wrox, (http://www.apache.org). [132] G. Reese, Database Programming with JDBC and Java, O Reilly, Sebastopol, [133] Jasnokwski, M. Java, XML, and Web Services Bible. Hungry Minds, Wiley, Nueva York, [134] M. Akif, S. Bordead, A. Cioroianu, J. Hart, E. Jung, D. Writz, Java y XML, Anaya, Madrid, [135] G.H. Gonnet, R. Baeza-Yates, Handbook of Algorithms and Data Structures, Addison-Wesley, Reading, [136] C.J. Date, An Introduction to Database Systems, Sexta edición, Addison-Wesley, Reading, [137] I. Luque Ruiz, M.A. Gómez-Nieto, E. López Espinosa, G. Cerruela García, Bases de Datos: Desde Chen hasta Codd con Oracle, Ra-Ma, Madrid,

107 Referencias [138] A. de Miguel, M. Piattini, Fundamentos y Modelos de Bases de Datos, Ra-Ma, Madrid, [139] G. Koch, K. Loney, Oracle8i: The Complete Reference, 10th edition, Oracles Press, Osborne-McGraw-Hill, [140] Informe del grupo de estudio de bases de datos del ANSI/X3/SPARC, Reference Model for DBMS Standarisation, Sigmo Record 15(1) (1986). [141] G.W. Hansen, J.V. Hansen, Database Management and Design, 2nd edition, Prentice-Hall, [142] C. Batini, S. Ceri, S. Navathe, Diseño Conceptual de Bases de Datos, Addison-Wesley Iberoamericana, Buenos Aires, [143] P.P. Chen, Assoc. Computing Machin. Transac. Database Syst. (ACM TODS) 1(1) (1976). [144] P.P. Chen, The Entity/Relationship Model: a Basis for the Enterprise View of Data, Am. Fed. Inf. Process. Soc. Conf. Proc. Vol. 46, [145] P.P. chen (Ed.), Entity Relationship Approach to System Analysis and Design, North Holland, Amsterdam, [146] R. Elsmari, S. Navathe, Fundamentals of Database Systems, 2nd edition, Benjamin Cummings, Nueva York, [147] T.J. Teorey, Database Modelling and Design. The Entity Relationship Approach, Morgan Kaufmann Publishers, San Francisco, [148] S. Ferg, Modelling the Time Dimension in an Entity-Relationship Diagram, Proc. 4th Int. Conf. Entity/Relationship App., EE.UU., [149] G. Poonen, CLEAR: a Conceptual Language for Entities and Relationships, Proc. Int. Conf. Managem. Data, Italia, [150] A. Shoshani, CABLE: a Language Based on Entity-Relationship Model, Conf. Database Managem., Israel, [151] E.F. Codd, Recent Investigations into Relational Data Base Systems, Proc. Int. Fed. Inf. Process., Suecia, [152] E.F. Codd, Communic. Assoc. Computing Machin. (CACM) 13(6) (1970). 93

108 Manuel Urbano Cuadrado Tesis Doctoral [153] E.F. Codd, Further Normalisation of the Database Relational Model, en Database Systems, Courant Computer Science Symposia Series 6, Prentice-Hall, Englewood Cliffs, [154] E.F. codd, Relational Completeness of Data Base Sublanguages en Database Systems, Courant Computer Science Symposia Series 6, Prentice- Hall, Englewood Cliffs, [155] E.F. Codd, A Data Base Sublanguage Founded on the Relational Calculus, Proc. ACM SIGFIDET Workshop on Data Description, Access and Control, EE.UU., [156] M. Stonebraker, R. Agrawal, U. Dayal, E.J. Neuhold, A. Reuter, DBMS Research at a Crossroads: the Vienna Update, Proc. 19th Int. Conf. Very Large Data Bases, Irlanda, [157] E.F. Codd, The Relational Model for Database Management, Versión 2, Addison Wesley, Reading, [158] H. Darwen, C.J. Date, Sigmod Record 24(1) (1995) 39. [159] Atkinson et al. The Object-Oriented Database System Manifiesto, en Deductive and Object-Oriented Databases, Elsevier, Amsterdam, [160] P. Dorsey, J.R. Hudicka, Oracle8. Design Using UML Object Modeling, Oracles Press, Osborne-McGraw-Hill, [161] S. Bobrowski, Oracle8i para Windows NT, Oracles Press, Osborne- McGraw-Hill, [162] S. Urman, Oracle8. Programación PL/SQL Oracles Press, Osborne- McGraw-Hill, [163] G.E.P. box, W.G. Hunter, J.S. Hunter, Statistics for Experimenters, An Introduction to Design, Data Analysis and Model Building, Wiley, Nueva York, [164] S.N. Deming, S.L. Morgan. Experimental Design: a Chemometric Approach, 2nd edition, Elsevier, Amsterdam, [165] J. Salafranca, C. Domeno, C. Fernández, C. Nerín, Anal. Chim. Acta 477(2) (2003)

109 Referencias [166] A. Cerrato, D. de Santis, M. Moresi, J. Sci. Food Agric. 82 (2002) [167] P.A. Martoglio-Smith, Vib. Spectrosc. 24(1) (2000) 47. [168] S. Van Huffel, J. Vandewalle, The Total Least Squares Problem: Computational Aspects and Analysis, SIAM, Philadelphia, [169] T. Næs, E. Risvik (Ed.), Multivariate Analysis of Data in Sensory Science, Data Handling in Science and Technology Series, Elsevier, Amsterdam, [170] M. Felipe Sotelo, J.M. Andrade, A. Carlosena, D. Prada, Anal. Chem. 75 (2003) [171] H.W. Tan, S.D. Brown, Anal. Chim. Acta 490(1-2) (2003) 291. [172] H.L. Yu, J.F. MacGregor, Chemom. Intell. Lab. Syst. 67 (2003) 125. [173] L. Kaufman, P.J. Rousseeuw, Finding Groups in Data: an Introduction to Cluster Analysis, Wiley, Nueva York, [174] R.G. Brereton (Ed.), Multivariate Pattern Recognition in Chemometrics, Elsevier, Amsterdam, [175] J.M. Andrade, M.P. Gómez-Carracedo, E. Fernández, A. Elbergali, M. Kubista, D. Prada, Analyst 128 (2003) [176] D. Coomans, I. Broeckaert, M. Jonckheer, D.L. Massart, Meth. Inform. Med. 22 (1983) 93. [177] R.J. Laub, J.H. Purnell, J. Chromatogr. 112 (1975) 71. [178] G.K. Bolhuis, C.A.A. Duineveld, J.H. de Boer, P.M.J. Coenegracht, Simultaneous Optimization of Multiple Criteria in Tablet Formulation: Part I Pharmaceutical Technology EUROPE, Junio (1995), [179] A.K. Smilde, A. Knevelman, P.M.J. Coenegracht, J. Chromatogr. 369 (1986) 1. [180] D.H. Doehlert, Appl. Statist. 19 (1970) 231. [181] D.E. Long, Anal. Chim. Acta 46 (1969) 193. [182] K.W.C. Burton, G. Nickless, Chemom. Intell. Lab. Syst. 1 (1987) 135. [183] D.K. Lin, Technometrics 37 (1995) 213. [184] R.L. Plackett, J.P. Burman, Biometrika 33 (1946)

110 Manuel Urbano Cuadrado Tesis Doctoral [185] M.M.W.B. Hendriks, J.H. De Boer, A.K. Smilde, Robustness of Analytical Chemical Methods and Pharmaceutical Technological Products, Elsevier, Amsterdam, [186] A.M.C. Davies, R. Giangiacomo (Eds.), Near Infrared Spectroscopy: Procedings of the 9th International Conference, NIR Publications, Chichester, [187] A.M.C. Davies, R.K. Cho, Near Infrared Technology in the Agricultural and Food Industries, NIR Publications, Chichester, [188] A.M.C. Davies, R.K. Cho (Eds.), Near Infrared Spectroscopy: Procedings of the 10th International Conference, NIR Publications, Chichester, [189] T. Næs, T. Isakson, T. Davies, A User-Friendly Guide to Multivariate Calibration and Classification, NIR Publications, Chichester, [190] D.A. Burns, E.W. Ciurczak, Handbook of Near Infrared Analysis, Marcel Dekker, Nueva York, [191] H. Martens, M. Martens, Multivariate Analysis of Quality: an Introduction, Wiley, Nueva York, [192] H. Martens, T. Næs, Multivariate Calibration, Wiley, Nueva York, [193] D. Bertrand, E. Dufour, La Spectroscopie Infrarouge et ses Applications Analytiques, Editions TEC & DOC, París, [194] B.G. Osborne, T. Fearn, Practical NIR Spectroscopy with Applications in Food and Beverage Analysis, Longman Scientific and Technical, Londres, [195] V. Fernández-Cabanás, A. Garrido-Varo, Química Analítica 18 (1999) 113. [196] M.S. Dhanoa, S.J. Lister, R. Sanderson, R.J. Barnes, J. Near Infrared Spectrosc. 2 (1994)

111 Referencias [197] D. Bertrand, Data Pre-treatment and Original Analysis in Spectroscopy, en Advanced Comet Chemometrics School, Libramont, Bélgica, [198] J.S. Shenk, M.O. Westerhaus, Analysis of Agricultural and Foods Products by Near Infrared Reflectance Spectroscopy, Monograph, NIRSystems Inc., Silver Spring, [199] P.C. Williams, K. Norris (Eds.), Near Infrared Technology in the Agricultural and Food Industries, American Association of Cereal Chemists Inc., St. Paul, [200] P.C. Mahalanobis, On the Generalised Distance in Statistics, Proc. National Institue of Science of India, 12:49-55, [201] R. De Maesschalck, D. Jouan-Rimbaud, D.L. Massart, Chem. Intell. Lab. Syst. 50 (2000) 1. [202] D.L. Massart, L. Kaufman, The Intepretation of Analytical Chemistry Data by the Use of Cluster Analysis, Wiley, Chichester, [203] ASTM, Standard Definitions of Terms and Symbols Relating to Molecular Spectroscopy, American Society for Testing and Materials, vol , Standard E131-90, West Conshohcken, [204] Y. Mallet, D. Coomans, O. de Vel, Chemom. Intell. Lab. Syst. 35 (1996) 157. [205] G. McLachlan, Discriminant Analysis and Statistical Pattern Recognition, Wiley, Nueva York, [206] S. Wold, Pattern Recogn. 8 (1976) 127. [207] D.L. Massart, B.G.M. Vandeginste, S.N. Deming, Y. Michotte, L. Kaufman, Chemometrics: a Textbook, Elsevier, Amsterdam, [208] J.S. Shenk, M.O. Westerhaus, Calibration the ISI Way, en Near Infrared Spectroscopy: the Future Waves, A.M.C. Davis, P.C. Williams (Eds.) NIR Publications, Chichester,

112 Manuel Urbano Cuadrado Tesis Doctoral [209] J.S. Shenk, M.O. Westerhaus, Routine Operation, Calibration, Development and Network System Management Manual, NIRSystems Inc., Silver Spring, [210] F. Despagne, D.L. Massart, Analyst 123 (1998) 157R. [211] B. Wythoff, Chemom. Intell. Lab. Syst. 18 (1993) 115. [212] J. Zupan, J. Gasteiger, Neural Networks for Chemists. An Introduction, VCH, Weinheim, [213] J. Park, I.W. Sandberg, Neural Computat. 3 (1991) 246. [214] B. Walczack, D.L. Massart, Anal. Chim. Acta 331 (1996) 187. [215] J.S. Shenk, M.O. Westerhaus, Crop Sci. 31 (1991) 469. [216] T. Isaksson, T. Næs, Appl. Spectrosc. 44 (1990) [217] T. Næs, T. Isaksson, Appl. Spectrosc. 43 (1989) 328. [218] V. Barnett, T. Lewis, Outliers in Statistical Data, Wiley, Nueva York, [219] H. Mark, Y. Workman, Statistics in Spectroscopy, Academic Press Inc., Nueva York, [220] M. Stone, J. R. Statist. Soc. B 39 (1974) 111. [221] W.R. Windham, P.C. Flinn, Comparison of MLR and PLS Regression in NIR Analysis of Quality Components in Diverse Feedstuff Populations, en Near Infrared Spectroscopy. Bridging the Gap between Data Analysis and NIR Applications, K.I. Hildrum, T. Isaksson, T. Næs, A. Tandberg (Eds.), Ellis Horwood, Chichester, [222] T. Fearn, Anal. Proc. 23 (1986) 123. [223] Resolution OENO 6/99. Validation Protocol for a Typical Analytical Method Compared to the OIV Reference Method. Office International de la Vigne te du Vin. [224] E. Trullols, I. Ruisánchez, F.X. Rius, Trends Anal. Chem. 23 (2004) 137. [225] C.J. Cramer, Essentials of Computational Chemistry: Theories and Models, Second Edition, Wiley,

113 Referencias [226] T. Clark, A Handbook of Computational Chemistry: a Practical Guide to Chemical Structure and Energy Calculations, Wiley, Nueva York, [227] J.W. Robinson (Ed.), CRC Handbook of Specrtoscopy, Vols. I-III, CRC Press, Ohio, [228] M.A. Sharaf, D.L. Illman, B.R. Kowalski, Chemometrics, Wiley, Nueva York, [229] P.C. Jurs, Chemometrics and Multivariate Analysis in Analytical Chemistry, en Reviews in Computational Chemistry, Vol. 1, Willey, Nueva York, [230] H. van de Waterbeemd (Ed.), QSAR: Chemometric Methods in Molecular Design, VCH, Weinheim, [231] H. Kubinyi, QSAR: Hansch Analysis and Related Approaches, VCH, Weinheim, [232] J.M. Bamard, G.M. Downs, Persp. Drug Discov. Des. 7-8 (1997) 13. [233] A. Hillisch, R. Hilgenfeld, Modern Methods of Drug Discovery, Springer-Verlag, Nueva York, [234] T. Lenganer, R. Mannhold, H. Kubinyi, H. Timmerman, Bioinformatics from Genomes to Drugs, Wiley, Nueva York, USA, [235] J. Zupan, J. Gasteiger, Neural Networks in Chemistry and Drug Design: an Introduction, Second Edition, Wiley, Nueva York, [236] M.A. Miller, Nature Rev. Drug Discov. 1 (2002) 220. [237] W.A. Warr, J. Chem. Inf. Comput. Sci. 37 (1997) 134. [238] B.A. Leland, J. Chem. Inf. Comput. Sci. 37 (1997) 62. [239] K. Eckschlager, K. Danzer, Information Theory in Analytical Chemistry, Wiley, Nueva York, [240] D.L. Massart, J. Chromatogr. 79 (1973) 157. [241] F. Dupuis, A. Dijkstra, Anal. Chem. 47 (1975) 379. [242] P.J. Slonecker, X. Li, T.H. Ridgway, J.G. Dorsey, Anal. Chem. 68 (1996)

114 Manuel Urbano Cuadrado Tesis Doctoral [243] P.J. Tandler, J.A. Butcher, H. Tao, P. De B. Harrington, Anal. Chim. Acta 312 (1995) 231. [244] D.R. Scott, A. Levitski, S.E. Stein, Anal. Chim. Acta 278 (1993) 13. [245] L.A. Clark, D. Pregibon, Tree-Based Models, en Statistical Models, J.M. Chambers, T.J. Hastie (Eds.), S. Chapman and Hall, Nueva York, [246] L.A. Zadeh, Inform. Control 8 (1965) 338. [247] M.Otto, H. Bandemer, Chemom. Intell. Lab. Syst. 1 (1986) 71. [248] T. Blaffert, Anal. Chim. Acta 161 (1984) 135. [249] B. Walczak, E. Bauer-Wolf, W. Wegscheider, Microchim. Acta 113 (1994) 153. [250] D.H. Rouvray, A.T. Balaban, Chemical Applications of Graph Theory. Applications of Graph Theory, R.J. Wilson, L.W. Beineke (Eds.), Academic Press, Nueva York, [251] G.M. Downs, P. Willet, Similarity Searching in Databases of Chemical Structures en Reviews in Computational Chemistry, Vol. 7, Wiley, Nueva York, [252] H. Scsibrany, M. Karlovits, W. Demuth, F. Mueller, K. Varmuza, Chemom. Intell. Lab. Syst. 67 (2003) 95. [253] R. Hefferlin, M.T. Matus, J. Chem. Inf. Sci. 41 (2001) 484. [254] R.P. Sheridan, M.D. Miller, D.J. Underwood, S.K. Kearsley, J. Chem. Inf. Sci. 36 (1996) 128. [255] K. Varmuza, M. Karlovits, W. Demuth, Anal. Chim. Acta 490 (2003) 313. [256] W. Demuth, M. Karlovits, K. Varmuza, Anal. Chim. Acta 516 (2004) 75. [257] P. Willet, J.M. Barnard, G. Downs, J. Chem. Inf. Comput. Sci. 38 (1998) 983. [258] K. Varmuza, P.N. Penchev, H. Scsibrany, J. Chem. Inform. Comput. Sci. 38 (1998) 420. [259] V. Schoonjans, F. Questier, Q. Guo, Y. Van der Heyden, D.L. Massart, J. Pharm. Biomed. Anal. 24 (2001)

115 Referencias [260] F. Ehrentreich, Anal. Chim. Acta 393 (1999) 193. [261] W. Werther, K. Varmuza, Fresenius J. Anal. Chem. 344 (1992) 223. [262] P.J. Dunlop, C.M. Bignell, J.F. Jackson, D. Brynn Hibbert, Chemom. Intell. Lab. Syst. 30 (1995)

116

117 Parte experimental

118

119 Parte I: Informatización del proceso analítico y de la gestión y análisis de los datos producidos mediante el uso del paradigma orientado a objetos

120

121 Capítulo 1 USE OF OBJECT-ORIENTED TECHNIQUES FOR THE DESIGN AND DEVELOPMENT OF STANDARD SOFTWARE SOLUTIONS IN AUTOMATION AND DATA MANAGEMENT IN ANALYTICAL CHEMISTRY El contenido de este capítulo ha sido enviado para su publicación a la revista Trends in Analytical Chemistry.

122

123 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 USE OF OBJECT-ORIENTED TECHNIQUES FOR THE DESIGN AND DEVELOPMENT OF STANDARD SOFTWARE SOLUTIONS IN AUTOMATION AND DATA MANAGEMENT IN ANALYTICAL CHEMISTRY Manuel Urbano Cuadrado, M. D. Luque de Castro, Miguel Ángel Gómez-Nieto Abstract An object-oriented design of software structures for both automating analytical processes and managing the data generated from these processes is proposed. Two models, for automation and data management, are developed for building the programs used in these two areas. The advantages arisen from these object-oriented models regarding the classical design are exposed. Thus, the standardisation, scalability, independence, etc., of the programs are assured by the object-oriented modelling. Characteristics like inheritance, polymorphism, encapsulation, etc., are used for achieving the pursued goals, in addition to having a new way for representing the analytical concepts in automation and data management. Keywords: Object-oriented paradigm, Automation, Data management. 109

124 Manuel Urbano Cuadrado Tesis Doctoral 1. Introduction The development of two main subareas in analytical chemistry as automation and laboratory information management systems (LIMS) can not be conceived without the fast advances on informatics. Firstly, computing has allowed automation of the different steps of the analytical process sample preparation [1,2], detection [3,4] and data collection and processing [5-7] thus avoiding human participation in analysis development and errors owing to manual operations. Regarding information management, different approaches have been developed with different complexity and scope, namely: systems for handling daily data from laboratories Management Information Systems (MIS) [8,9], systems for supporting decisions making in laboratories Decision Support Systems (DSS) [10,11], and, at the highest level, systems for entirely substitution of human skills and expertise Knowledge Based Systems (KBS) [12,13]. In addition, analytical disciplines such as chemometrics, hyphenated techniques, molecular design, QSOR /QSAR, etc., have also taken advantages from informatics. Thus, computers and modern analytical chemistry are closely interrelated subjects. Computer programs are built following engineering processes Software Engineering [14,15] consisting of a series of steps, namely: specification of requirements (also known as system analysis), system design, codification, implementation and testing. Most efforts, experience and time are devoted to programs analysis and design these two steps constitute the modelling of a system. The quality of the remaining process, and, in turn, of the software developed, depends on the modelling stage. The analytical problems (that is, the number and properties of the target analytes, characteristics of the samples, etc.), and their resolution (the time for obtaining results, the level of accuracy required, etc.) are in continuous change. Re-updating computational resources to the new 110

125 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 scenarios raised from these changes is often an expensive and long period, which frequently makes necessary to improve the software and hardware involved. This is a consequence of shortcomings of the classical model ling in software engineering. Other problems in analytical laboratories related to deficient modelling are the specificity of software for a given equipment and hardware, disconnection between software for automation and software for data management, etc. New efforts in modelling software systems have been addressed at the development of programs with a high degree of scalability property referred to the capacity for enlarging the program functionality with minimum efforts, independence of both the hardware used and the required information, re-usability, etc. With this aim, computational researchers developed the Object-Oriented Paradigm (OOP) for engineering software [16,17] at the beginnings of the 90s despite the object-oriented programming was introduced by Smalltalk in the 70s, the modelling based on objects was not used for analysis and design of software solutions, based on the key and intuitive object concept: an abstraction unit of a real entity. In this way, a program is composed by a number of objects related between them and endowed with a series of properties and actions. The object-oriented modelling has been hardly used in analytical chemistry [18,19] owing to reasons such as: 1) the shortcomings owing products standardisation for commercial brands; 2) the relatively recent development of the paradigm, and in turn, 3) the non-availability of both a standardised modelling language and tools appropriate for implementation. Nevertheless, the development of both Unified Modelling Language (UML) [20] and objectoriented programming languages C++ and, particularly, Java [21] increases the use of OOP. In this paper, two objects models for automation and data management are described with the aim of showing the advantages of these models in analytical chemistry. 111

126 Manuel Urbano Cuadrado Tesis Doctoral The development of these models is an attempt to create a useful programming structure, in addition to a new meta-language based on the objects definition in analytical chemistry. 2. Object model for automation Many approaches have been developed in analytical chemistry regarding automation, but few of them [22,23] deal in some extension with software design. The description of the model here presented deals with structural modelling the abstraction of the analytical equipment. Therefore, only the dynamic aspects related to actions carried out by analytical hardware are considered. The automation processes in which this model can be used have been described previously. [24]. 2.1 The analytical hardware: devices, apparatus, instruments and autoanalysers A given instrumental set-up aimed at providing either a signal, such as a peak height or area, slope, etc., or, directly, the value of the parameter under study is necessary in order to carry out analyses in an automatic or automated way. The use of the word automatic or automated implies computer control of some of the steps of the analytical process al least data collection and processing. Computer control requires two parts. Firstly, the software that, in addition to data processing for information output, commands the hardware, which constitutes the second part involved. For the development of the model, the concept of hardware is divided into two types, namely: the physical part of computers and the analytical equipment analytical hardware is the name here proposed. The IUPAC distinguishes between devices, apparatus, instruments and analysers. Devices are considered as the minimum part of analytical equipment (either apparatus or instruments) able of realising a unitary physical or electronic operation (e.g. electronic interface, mechanical rotor, etc.). Thus, apparatus are defined as a set of devices assembled to carry out physical, 112

127 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 dynamic or chemical operations involving samples and reagents (e.g. an ultrasound digester, a selection valve, etc.). Nevertheless, apparatus cannot provide any information about the samples in contrast to instruments (e.g. a spectrophotometer, a potentiometer, a chromatograph, etc.). At the highest level, the combination of apparatus and instruments for setting up an analytical method is known as analyser (e.g. an autoanalyser for pesticides in soils). The objects model to be developed must take into account these IUPAC definitions in order to assure the standardisation level pursued. 2.2 Classes involved in automation: static view of the analytical hardware The concept of class means a generalisation of a group of objects endowed with common both properties and behaviour from the OOP point of view attributes are properties that characterise the structure of a given object and methods are operations to be carried out by the objects. Therefore, an object is a case of a given class which represents a recognisable world real entity. The object-oriented modelling uses a Classes Diagram for designing the structural aspects of a system [20]. Fig. 1 shows the classes diagram developed here for automation in analytical chemistry. As can be seen in the figure, the class Analytical Hardware is considered as the parent class. The remaining classes are descending from AnalyticalHardware and, thus, they inherit its properties and methods inheritance and specialisation are concepts below commented. The attributes of the class AnalyticalHardware are identifier, brand, model and communication_port. These attributes show different value for each object of the AnalyticalHardware class. Any hardware involved in an analytical process is identified by an item, is from a given brand, corresponds to a specific model, and, finally, needs a channel for communication with computers. On the other hand, the methods of the class hardware are 113

128 Manuel Urbano Cuadrado Tesis Doctoral ANALYTICALHARDWARE -identifier : String -brand : String -model : String -communication_port : String -setidentifier() : void -setbrand() : void -setmodel() : void -setcommunicationport() : void -getidentifier() : String -getbrand() : String -getmodel() : String -getcommunicationport() : String -abstract setremotecontrol() : void -abstract exitremotecontrol() : void APPARATUS INSTRUMENT -abstract setremotecontrol() : void -abstract exitremotecontrol() : void -abstract setremotecontrol() : void -abstract exitremotecontrol() : void -abstract monitoring() : void Branch detailed in Fig. 2 Branch detailed in Fig. 3 Fig. 1. Classes diagram for automation in analytical chemistry (I). Specialisation of the class AnalyticalHardware into classes Apparatus and Instrument. those in charge of managing the attributes above cited and also two abstract methods responsible for setting and exiting the remote control necessary for automation. The term abstract is a method modifier that means that the latter is implemented in the lower classes. Any class with abstract methods is considered as an abstract class, and therefore, the specialisation of the parent class is mandatory in order to implement these methods. The inheritance capacity is one of the key object-oriented modelling s characteristics that yields advantages related to reusability of the code and programming time. Yourdon provided the following data [25]: reduction of 70 and 84 % in time 114

129 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 and costs, respectively, required for the development of a software product. Moreover, the inheritance property helps to support a conceptual view of the problem. Thus, the classes descending from a given class inherit the structure and behaviour of its parent, but taking into account to add new functionality (new attributes or methods). This fact is known as specialisation and permits to differentiate classes of the same level. Thus, classes Apparatus and Instrument are descending from class Analytical- Hardware. This justly corresponds to IUPAC hierarchy, and because the difference between apparatus and instruments is the analytical information provided by the latter, class Instrument has a new method named monitoring, also defined as abstract. This method, which is implemented by classes derived from class Instrument, collects data from instruments in a continuous way. The use of specialisation appears continuously in the proposed model. Thus, Figs. 2 and 3 summarise the classes sub-diagrams for apparatus and instruments, respectively. The Apparatus class is specialised into classes HydrodynamicApparatus and SampleTreatmentApparatus. The former corresponds to apparatus for propelling samples and reagents through the analyser (e.g., auto samplers, peristaltic pumps, selection valves, etc.) and the latter represents apparatus for samples and reagents treatment (e.g., thermostats, ultra sound digesters, microwave digesters, high pressure chambers, etc.). Thus, classes as MicrowaveDigester, Auto sampler, SelectionValve, etc., are in Fig. 2, where the most outstanding attributes and methods of each class are shown. The branch of the classes diagram for automation in Fig. 3 is devoted to instruments. Class Instrument is firstly specialised into OpticalInstrument and ElectroanalyticalInstrument. Thus, classes as Spectrophotometer, Spectrofluorimeter, DiodeArraySpectrometer, PotentiometricInstrument, AmperometricInstrument, etc., are shown in Fig

130 Manuel Urbano Cuadrado Tesis Doctoral Fig. 2. Classes diagram for automation in analytical chemistry (II). Specialisation of the class Apparatus into different classes that represent the apparatus involved in analytical chemistry. 116

131 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 Fig. 3. Classes diagram for automation in analytical chemistry (III). Specialisation of the class Instrument into different classes that represent the instruments involved in analytical chemistry. 117

132 Manuel Urbano Cuadrado Tesis Doctoral 2.3 Separation between logical structure and physical implementation: degree of independence The structural modelling based on the object-oriented paradigm takes into account only a logical point of view of the analytical equipment involved in automation by classes. These classes are endowed with a series of properties and operations that are close to the analytical chemist. The implementation of the abstract methods of the corresponding classes is carried out by leaf classes, which are the manufacturers classes. This is the linkage between standard application for monitoring analytical processes and the analytical hardware of an autoanalyser. The hardware is controlled by commands used by the classes in order to implement the functionality required for a given instrument or apparatus. The set of commands is the physical part not treated by the logical model and often associated to devices above commented. The join of the physical part to the logical model is carried out by object-oriented programming languages endowed with an interface for implementing methods written in other languages. The physical part is often composed by functions written in languages such as C, Fortran, etc. responsible for commanding devices that compose instruments and apparatus. The programming language Java is endowed with Java Interface Native (JNI) [21] in order to develop methods able of using code written in other language. There are two ways for introducing the manufacturers classes into the model. One of them involves delivering by the manufacturer the classes corresponding to the hardware he/she fabricates. These classes must be endowed with the requisites (namely, inheritance and implementtation of abstract methods) necessary for being included in the model, and therefore, in a standardised system for automation. It is clear that this way can be considered only from an optimistic point of view as standard tools are not of interest for most companies. This way is based on the 118

133 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 development of a classes library used for the choice of the classes required in order to compose a given autoanalyser. On the other hand, classes can be developed taking into account the list of commands necessary to build the physical part used by the model the list is often provided by the manufacturers, even sometimes the entire physical part. The authors of this article have developed some manufacturers classes, in addition to the rest of the classes of the model, in Java language (e.g. classes Crison- Sampler, Rheodyne7010, Unicam8625 Spectrophotometer, etc.). These classes are at the disposal of researchers interested in them. 2.4 The automation model in the analytical process The system for automating analytical processes proposed by the authors [24] is prepared for the classes diagram described above. This system involves a series of interfaces for the design and control of processes and it is based on the execution of hardware actions and functions if a series of time and state premises are fulfilled. The aggregation of hardware classes and the relationship between the AnalyticalHardware and Hardware Action classes the former has a list of HardwareAction objects as attribute yields a specific auto analyser. Thus, the model allows different autoanalysers to be controlled by a standard software. Polymorphism is other important object-oriented modelling s characteristic, which permits that any reference to a parent class can be converted into a reference to a descending class. This is of importance for the scalability of the program since the introduction of a new class in the model does not affect the control code because of the use of references to the parent Analytical Hardware class. Hybridisation between the programming language Java and the markup language XML assures the coupling of the model to a standard automation system. The definition of an analytical method (consisting of the specification of both the hardware involved and the time and state 119

134 Manuel Urbano Cuadrado Tesis Doctoral actions to be carried) is stored in an xml file. Then, objects of the class AnalyticalHardware with their lists of objects ActionHardware are built in execution time from the XML data for autoanalyser control by the computer. 3. Objects model for data management Any laboratory for process control carries out a series of analyses aimed at knowing the value of several parameters of interest for monitoring a given process. The number of analyses to be carried out depends on the complexity of the process. Thus, the more the complexity of the process, the higher the number of parameters to be monitored. Other factor that influences the amount of information is the workload in the laboratory with respect to the number of samples to be analysed. This aspect depends on the monitoring frequency for each process. Moreover, independently of these factors, the amount of information to manage is large independence of the amount and way of carrying out the measurements, separation between daily data even if the number of samples and parameters is low as long as a historical management is necessary in order to extract information from data corresponding to long past periods. Specificity to a given laboratory or process is an undesirable aspect for LIMS use because the low degree of scalability the design of the programs enables in this case. The dynamics of analytical information makes necessary systems that require null or minimum reprogramming when conditions as sample identification and classification, new analytical parameters to monitor, computer resources, etc., change. Therefore, open characteristics are mandatory for avoiding or minimising economical and time efforts when reprogramming is necessary. The object-oriented model here proposed permits to build data management applications with the above commented requirements (namely: applicability to any process monitoring or reference laboratory, handling and historical data analysis modules, etc.). 120

135 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 SELECTED PARAMETER * MEASUREMENT CALCULATED MEASUREMENT DATUM MEASUREMENT 0..* 0..1 USER PARAMETER < Uses > * 0..1 Some measurements may not be associated to a calibration curve CALCULUS FORMULAE CALIBRATION CURVE 1..* 1..1 ANALYSER MAGNITUDE FORMULAE CONVERSION FORMULAE Fig. 4. Classes diagram for data management in analytical chemistry (I). Classes for representing the samples, parameters and their relationships, unities and users of the analytical information. 3.1 Classes involved in the management of samples and analytical parameters The class Sample represents the samples in which several properties or parameters have to be determined. Samples identification is the key in the management of the laboratory information. The criterion for identification is different for each laboratory. Thus, modelling with a view on identification independent of the laboratory is the first step for constructing the classes diagram shown in Fig. 4. Class Code represents the possible codes used for identification, with name and data_type attributes. The latter is important for correct functioning of the programs since data consistence is necessary and it indicates the numerical, text, date or binary code used. An analytical parameter is 121

136 Manuel Urbano Cuadrado Tesis Doctoral considered a property of the material under study that is of interest for its characterisation. The definition of parameter is encapsulated in Para meter class. This is specialised into two classes (see Fig. 4), namely: classes DatumParameter and CalculatedParameter. The former represents parameters that are determined directly in samples; and the latter those determined by the relationship between one or several parameters of the first type and a mathematical expression, as shown in Fig. 4. A result is expressed by a value and the unit in which this is measured. Class Unit is necessary for representing the different units in which the analytical parameters can be expressed. The association between the classes Parameter and Unit yields the new class Magnitude, which represents a given parameter expressed in a specific unit. This class is endowed, among others, with two key attributes to trigger off alerts for users warning, namely, minimum _value and maximum_value, which define the normal range of a given magnitude. Class SelectedParameter arises from the association between the classes Sample and Parameter and represents a given parameter to be determined in a sample. This class manages all the measurements of the parameter in the target sample by the list of objects of the class Measurement described below. 3.2 Relationship between measurement and calibration in analytical chemistry Fig. 5 shows classes that represent the analytical measurements and the information they provide. The most important class is Measurement, which is specialised into classes DatumMeasurement and Calculated Measurement in a way similar to that commented for the class Parameter. These classes represent the measurements carried out in the laboratory, either in a direct or indirect way, and therefore, they are related with class Magnitude in order to know the parameter and unit to which the attribute value belongs. The relationship between the classes Magnitude and Formulae is 122

137 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 SELECTED PARAMETER * MEASUREMENT CALCULATED MEASUREMENT DATUM MEASUREMENT 0..* 0..1 USER PARAMETER < Uses > * 0..1 Some measurements may not be associated to a calibration curve CALCULUS FORMULAE CALIBRATION CURVE 1..* 1..1 ANALYSER MAGNITUDE FORMULAE CONVERSION FORMULAE Fig. 5. Classes diagram for data management in analytical chemistry (II). Classes for representing both the measurement processes and analytical calibration. shown in Fig. 5. The class Formulae is an abstraction of the formulas in charge of calculating the value of a given magnitude from one or several values of other magnitudes. The class Formulae is specialised into the classes CalculusFormula and ConversionFormula. These two classes have in common a Magnitude attribute named output_magnitude as any of them provides one output value. The difference between these formulas is the number of input values. Thus, ConversionFormula class has a Magnitude attribute, named input _magnitude that represents the single value accepted by this formula. On the other hand, CalculusFormula class has a list of Magnitude class as attribute because a calculated measurement comes from one or several data. Conversion formulas require to be specialised. The conversion of an instrumental unit (e.g. an absorbance change with time) into a 123

138 Manuel Urbano Cuadrado Tesis Doctoral chemical unit (e.g. g l -1 ) is much more complex than a conversion in which only two chemical units (e.g. mol l -1 and ppm) are involved. This is a consequence of the necessity of characterising the instrumental response. Thus, class FormulaConversion is specialised into class CalibrationCurve. The new structure involves an attribute named calibration, which is of Calibration class type. This class represents the calibration process and manages information of the date when this step was carried out, the type of calibration used, the instrument employed, patterns, etc. The new classes CalibrationType, LinearCalibration, LogaritmicCalibration, Measurement- Calibration and Measurer are thus required. The class Analyser (see Fig. 5) represents analytical equipment from the point of view of data management. The association between classes Magnitude and Analyser (not shown in Fig. 5) gives place to a new class named Measurer that represents the feasibility of measuring an analytical parameter in a specific unit with a given instrument. Class Measurer is an attribute of the Calibration class, as well as, date, and both permit to search for the proper calibration in the database. To now, it has been supposed that the type of calibration is univariate, which fulfil the major part of the analyses carried out in any laboratory the signal from the instrument is often a value of absorbance or potential, a height or peak area, slope, etc.. Nevertheless, multivariate methods have been developed in the last years with the aim of obtaining the value of one or several parameters from a large number of variables, which is, most times, a spectrum. For the case in which multichannel spectrophotometers are not provided with chemometric software for multivariate calibration, a block of chemometrics has been modelled for supplying this possibility. 3.3 Classes diagram for multivariate calibration Multivariate calibration requires a large amount of standards which, in 124

139 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 turn, provide a huge amount of data. Two steps can be distinguished in the development of a multivariate model, namely: training and validation after which validated equations are obtained. Multivariate calibration is a continuous process, where the calibration set is continuously enlarged in order to build universal equations with a wider application field. A complete description of the chemometric modelling would require a long discussion that is out the scope of the research here presented. Only the description in Fig. 6, a brief classes diagram, is given. Class MultivariateEquation, which represents an equation in multivariate calibration, is associated to Magnitude class. The latter class is endowed with an attribute named equation, that is, a reference to an object of the class Multivariate Equation. This attribute becomes null if the parameter associated to the object of the class Magnitude does not require multivariate calibration for its determination. Classes Spectral Measurement, Spectrum, and Spectral Datum, and their relationships must be taken into account for predicting the value of the given parameter. Class SpectralMeasurement is a specialisation of the DatumMeasurement class, and therefore, it is associated to both a given sample and a specific parameter. This class provides, as specific attribute, an object of type class Spectrum which represents a spectrum endowed with class Spectral Datum list named list_of_points. The process of calibration is represented by the different associations between the classes Multi variateequation, MultivariateCalibration, MultivariateCalibration Type, PLSR, PCR, MLR and MCalibrationMeasurement. Thus, an instance of the class Multivariate Calibration is endowed with a list of MCalibrationMeasurement objects that provide the spectrum corresponding to a pattern. In addition to the list of MCalibration Measurement objects, the class MultivariateCalibration is also provided with a Multivariate CalibrationType object specialised in PLSR, PCR, and MLR whose attributes and methods are the key for developing an instance of the class 125

140 Manuel Urbano Cuadrado Tesis Doctoral MAGNITUDE MULTIVARIATE EQUATION 1..* 1..1 MULTIVARIATE CALIBRATION 1..1 < Uses > PLSR 1..1 SPECTRAL MEASUREMENT 1..1 MULTIVARIATE CALIBRATION TYPE PCR < Uses > 1..1 MLR SPECTRUM 1..1 *..* SPECTRAL DATUM Fig. 6. Classes diagram for data management in analytical chemistry (III). Classes for representing multivariate calibration. MultivariateEquation. 3.4 Information from historical data: a tool for supporting decisions A module for permanent storage of data of interest is mandatory for efficient handling and analysis of the information. After analysing all the specified parameters for a given sample, the corresponding data sample are stored into a historical repository and deleted from the module for daily management. The modelling of the historical repository is shown in Fig. 6. This class diagram is similar to that of the management of daily data. Class Query is used in order to extract information from historical data. This represents a real-time query against the database aimed at obtaining tabular or graphical information. Thus, this class has a series of attributes and methods in charge of providing a list of data for building either a table or a plot. This class is specialised into classes EvolutionQuery and HistogramQuery for 126

141 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 fulfilling the characteristics of the searching criteria. An object of the EvolutionQuery is aimed at obtaining the evolution of one or several parameters with the value of either a numerical or date code. The association between classes EvolutionQuery, Statistics and DataList provides statistical parameters of the data. For example: mean, increment, maximum, minimum, standard deviation, etc. On the other hand, Histogram Query class is in charge of obtaining the data necessary for building a frequency histogram. Here, the main searching criterion is a set of intervals for a numerical or date code, or a set of values for a text code. 3.5 Management of users and analytical equipment The user of an LIMS can be of 3 types. Firstly, technicians are users in charge of performing daily tasks in the laboratory, namely: inclusion and codification of new samples and specification of the parameters to be analysed, control of the workload, generation of reports, development of the analyses carried out manually, validation of results, etc. These users interact with the computers system at an operational level. Secondly, managers are users in charge of extracting information from the data by a tabular or graphical output after a real-time query against a historical repository using different criteria. This interaction is of the highest level since the system behaves as a tool for supporting decisions. In addition to this functionality, managers use the system with the aim of evaluating the workload, controlling the use of the equipment, etc. The last type of users is the administrators of the system, responsible for the security, integrity and privacy of the analytical information. The hierarchical order of the class User is shown in Fig. 4. Class Analyser has identifier, brand, model, list_of_magnitudes, acquisition_date, among other attributes. The association with class Magnitude yields the class Measurer, commented in a previous section. Also, the association between classes Measurement, Analyser, and Technician provides a new class named 127

142 Manuel Urbano Cuadrado Tesis Doctoral AnalyserUse that represents the use of an analyser by a technician in order to determine a given parameter. This class permits to control the management and use of the analytical equipment. 4. Conclusions The advantages arisen from two object-oriented models, for automation and data management, have been discussed in this work. The automation model is a new way for representing the analytical equipment. This model takes into account the hierarchy and concepts corresponding to IUPAC definitions, and, on the other hand, classifications proposed in the analytical literature. Thus, the encapsulation of attributes and methods in a given class, and the inheritance, specialisation and aggregation pro cesses provide the mechanisms for specifying the structure of any autoanalyser and the operations it can carry out. The structure of this model makes possible its coupling with a standard interface for automating analytical processes, taking advantages from both polymorphism and classes libraries in order to enlarge the functionality of the programs without changing the control flow in the code. Both the implementation of the abstract methods by the manufacturers classes and the use of Java for translating the model into a physical system guarantee the independence of the software regarding analytical equipment and hardware, respectively. The model for data management also takes into account the above commented characteristics of the object-oriented modelling. In this case, the proposed model assures the development of an LIMS with a high degree of scalability regarding production process to be monitored, information to be stored, different users that interact with the system, etc. Acknowledgements The Comisión Interministerial de Ciencia y Tecnología (CICyT) is thanked for financial support (Project AGL P4-03). 128

143 Trends Anal. Chem., enviado para su publicación Parte I, cap. 1 References [1] R.P.R. Rocha, B.F. Reis, E.A.G. Zagatto, J.L.F.C. Lima, R.A.S. Lapa, J.L.M Santos, Anal. Chim. Acta 468 (2002) 119. [2] E.P. Borges, P.B. Martelli, B.F. Reis, Mikrochim. Acta 135 (2000) 179. [3] K.A. Howell, E.P Achterberg, C.B. Braungardt, A.D. Tappin, P.J. Worsfold, D.R. Turner, Trends Anal. Chem. 22 (2003) 828. [4] B.F. Ni, P.S. Wang, H.L. Nie, S.Y. Li, X.F. Liu, W.Z. Tian, J. Radioanal. Nucl. Chem. 244 (2000) 665. [5] A. Calmon, L. Dusserre-Bresson, V. Bellon-Maurel, P. Feuilloley, F. Silvestre, Chemosphere 41 (2000) 645. [6] X.J. Li, H. Zhang, J.A. Ranish, R. Aebersold, Anal. Chem. 75 (2003) [7] R. Perez de Alejo, E.M. Rodriguez, I. Rodriguez, D. Uribazo, E.D. Alvarez, Meas. Sci. Technol.13 (2002) 95. [8] M. Bitton, Spectra Anal. 31 (2002) 37. [9] M. Pradella, R. Dorizzi, A. Burlina, Chemom. Intell. Lab. Syst. 17 (1992) 187. [10] Y. Vander-Heyden, P. Van keerberghen, M. Novic, J. Zupan, D.L. Massart, Talanta 51 (2000) 455. [11] P. Vankeerberghen, J. Smeyers-Verbeke, D.L. Massart, J. Anal. At. Spectrom. 11 (1996) 149. [12] M. Praisler, I. Dirinck, J. Van Bocxlaer, A.de Leenheer, D.L. Massart, Talanta 53 (2000); 155. [13] M. Peris, Crit. Rev. Anal. Chem. 26 (1996) 219. [14] R.S. Pressman, Software Engineering: a Practitioner s Approach, McGraw-Hill, New York, [15] I. Sommerville, Software Engineering, Addison-Wesley Longman Inc, [16] R.G. Fichman, C.F. Kemerer, Computers 25(10) (1992) 22. [17] G. Booch, IEEE Trans. Software Engineer. SE-12(2) (1986) 129

144 Manuel Urbano Cuadrado Tesis Doctoral 211. [18] K. Smith, J. Duckworth, K. Harrington, J. Bebel, Am. Lab. (Shelton, Conn). 32 (2000) 28. [19] R.E. Majoras, W.M. Richardson, R.S. Seymour, J. Radioanal. Nucl. Chem. 193 (1995) 207. [20] I. Jacobson, G. Booch, J. Rum baugh, The Unified Software Development Process, Addison- Wesley Longman Inc, [21] M. Campione, The Java Tutorial Third Edition. McGraw- Hill, 2002, (http://java.sun.com). [22] F. Zenie, Int. Lab. 32(1) (2002) 22. [23] M. Urbano, M.D. Luque de Castro, M.A. Gómez-Nieto, Automation of Flow Injection Methods in the Winery Industry through a Computer Program based on a Multilayer Model. Proceedings of 9th IEEE International Conference on Emerging Technologies and Factory Automation. Lisbon, Portugal, September, [24] M. Urbano, M.D. Luque de Castro, M.A. Gómez-Nieto, Trends Anal. Chem. 23 (2004) 270. [25] E. Yourdon, Development Strategies 6(12) (1994)

145 Capítulo 2 AN OPEN SOLUTION FOR COMPUTER CONTROL OF FLOW INJECTION ANALYSES IN WINE PRODUCTION MONITORING El contenido de este capítulo ha sido enviado para su publicación a la revista Computers and Electronics in Agriculture y ha sido presentado como comunicación oral en la 9th International Conference on Emerging Technologies and Factory Automation, celebrada en Lisboa (Portugal) entre los días 16 y 19 de Septiembre de 2003.

146

147 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 AN OPEN SOLUTION FOR COMPUTER CONTROL OF FLOW INJECTION ANALYSES IN WINE PRODUCTION MONITORING M. Urbano Cuadrado, M.D. Luque de Castro, M.A. Gómez-Nieto Abstract A computer program for the design and control of automated methods for wine analysis based on the Flow Injection (FI) technique is proposed. It has been provided with different layers, encompassing a physical oriented layer to user and analysis design layers. The user layer permits control the equipment, and the design layer allows selection of both the analytical instruments and the actions to be performed by these instruments. Thus, the analyses are carried out in an automated manner when they are based on FI. The use of Java and XML languages endows the proposed system with versatility to be installed in any platform. Keywords: Automation, Flow injection, Java, XML, Object-oriented system. 133

148 Manuel Urbano Cuadrado Tesis Doctoral 1. Introduction The monitoring of wine production is supported by a number of chemical analyses in both must and wine samples. Wineries use official and routine methods to determine most of the enological parameters. These methods have shortcomings in relation to both long analysis times and little mostly nil degree of automation. In recent years, new methods have been implemented in the enological laboratories with the aim of overcoming these limitations. These methods have often been based on Flow Injection (FI) technique (Mataix and Luque de Castro, 1998, Mataix and Luque de Castro, 2000, González et al., 2001, González et al., 2002). Since the beginning of its invention (Stewart et al., 1974, Ruzicka and Hansen, 1975) FI has been considered an easy to automate technique. Despite this general acceptance, few FI methods are automated methods in the strict sense of the word automated ; that is, without human intervention and with the capacity for making decisions through a feed-back system. The degree of automation involved in a given FI method varies from potential automation expressed as The system described can easily be automated and controlled from a personal computer (Collins et al., 2001), or The proposed method is suitable for automatic and continuous analysis (Li et al., 2001) to a real automatic approach (Danet et al., 2001). There are intermediate states such as the use of the label automated based on the single fact of their continuous functioning (Delgado et al., 2001, Okamura et al., 2001, Nitao et al., 2001, Solich et al., 2001); data are collected by a computer (Zhang and Beck., 2001, Shen et al., 2001) or any of the FI units works unattended (López et al., 2002). On the other hand, the use of computer programs for the control of the analytical equipment is not very frequent in wineries due to the fact that each analysis is carried out by a given hardware manifold. Thus, specific software must be used for each method. 134

149 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 The work here presented was aimed at the development of a computer system to control the enological analyses based on FI in a configurable and open way that surpasses the limitations above reviewed. 2. Materials and methods 2.1 Apparatus and instruments used in the development and testing of the program Apparatus and instruments from different suppliers have been used, namely: a Gilson Minipuls3 peristaltic pump (Villiers le Bel, France); a Rheodyne 7010 automatic injection valve (Elkay, Galway, Ireland) and a Rheodyne 5012 automatic selection valve (Elkay, Galway, Ireland) connected to a Gilson Valvemate111 valvemate (Villiers le Bel, France); a Unicam 8625 UV-Vis spectrophotometer (Cambridge, England); a Kontron SFM 25 spectrofluorimeter (Zurich, Switzerland). Several lists of commands have been used to control the above apparatus and instruments by a computer (Gilson, Minipuls 3 Peristaltic Pump, User s Guide; Gilson ValvemateTM Valve Actuator, User s Guide; Unicam Limited, 8625 Series UV/Visible Spectrometer, User s Guide; Kontron Instruments, SFM 25, User s Guide). On the other hand, Gilson uses a specific communication protocol, a serial GSIOC port (Gilson Serial input/output channel) which works under the RS485 protocol. This port hinders the establishment of communication directly through RS232C ports. A 506C interface (Gilson, 506C System Interface, User s Guide) from Gilson is necessary. This interface makes possible the control of Gilson hardware (until 64 by only an RS232C port). 2.2 Semi-automated methods used The following methods have been used in the construction and testing of the system: Semiautomatic Flow- Injection Method for the Determination of Volatile Acidity in Wines (González et al., 2001); Determination of Total and Free Sulphur Dioxide in Wine by Pervaporation-Flow Injec- 135

150 Manuel Urbano Cuadrado Tesis Doctoral tion (Mataix et al., 1998); Simultaneous Determination of Ethanol and Glycerol in Wines by a Flow Injection-Pervaporation Approach with Parallel Photometric and Fluorimetric Detection (Mataix et al., 2000); Method for the Simultaneous Determination of Total Polyphenol and Anthocyan Indexes in Red Wines Using a Flow Injection Approach (González et al., 2002). 2.3 Technology used For the construction of the system, both the object-oriented and the evolutionary incremental software engineering paradigms have been used. Unified Modelling Language (UML) (Booch et al., 1999, Rumbaugh et al., 1999, Jacobson et al., 1999) has been used for the modelling of the program; C (Herbert, 2000) and Java (Anderson and Stone, 1999, Campione, 2002, Eckel, 2003) languages have been used in the development step. On the other hand, extensible Markup Language (XML) (Morrison et al., 2000, Goldfarb and Prescod, 2001) has been used as storage structure. Technologies for joining Java and XML JDOM, JAXB and SAX (Jasnokwski, 2002) have also been used. 2.4 Software architecture for the development of flow injection analysis For the development of the system, a physical and logical control on the hardware components is necessary, in such as way that the situation of each component can be known and modified, if necessary before, during, and after a given analytical test. A layered architecture model capable of providing independence for working with the different FI manifolds and modus operandi has been used for software construction. As shown in Fig. 1, the system is based on a multi-layer model, which takes into account the functionality of the system at different abstraction levels, from the physical or hardware aspects to the analyst, who defines the analytical method through which the analysis is carried out. The layers or software components in the proposed model are as follows: 136

151 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 Configuration of FI analyses depending on requirements of the equipment Input/output of information in the software system Design Layer :Java and XML components Operator Layer :IU: Interface Java Each Java class represents a hardware element, assuring the logical structure of the analysis Logical Layer :Java Classes Communication between the logical structure and the hardware drivers Communication Layer :C Procedures Drivers Layer Primary functionality for instrument control :Drivers Hardware Fig. 1. Layer model of the approach for the design and control of flow injection analysis. (a) The drivers layer: hardware level This layer comprises commands or functions both to make the hardware operative (e.g. to change the position of an injection valve) and to collect the primary and physical information (e.g. to check the functioning of a 137

152 Manuel Urbano Cuadrado Tesis Doctoral peristaltic pump). It is a supplierdependent layer as each supplier does a given physical communication protocol for the hardware he/she fabricates. The driver layer can be constructed in any language which usually is a low or medium level language as, for example, C and it is supplied as a compiled function library. The information of how to deploy and to use this library was provided by the hardware supplier. Appendix 1 shows the basic functions present in this file for the control, not only of the peristaltic pump, but also of any hardware from Gilson. Two functions are used to send two types of commands to the hardware units: type I or Immediate commands, which use the ICmd function and ask for information about the hardware state; and type B or Buffered commands, which use the BCmd function and send operative instructions to the hardware units. An example of commands defined for the control of Minipuls3 [17] are: K> (B type), which makes the pump work clock-wise, and K (I type), which retrieves the direction and velocity of the pumped fluid. (b) Base layer: communication with the drivers This communicates the drivers layer with the logical level. It implements all the functionality the hardware is able to develop and ensures that the logical structure of the system recognises the hardware elements. This layer has been constructed using C language to achieve optimum exploitation of the computation resources and easy integration of its programs into other computer languages. This last characteristic makes it possible to link this level layer with the upper (Logical layer), constructed with Java technology. The modules developed with Java invoke methods written in C through the JNI. The software procedures which constitute the Base layer are used from native Java methods through a dynamic library (.dll) where the object procedures developed in C language are located. Appendix 2 shows an example of this layer through a C 138

153 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 Appendix 1 INTERFACE int (WINAPI DYNAMIC ICmd)( int unit, char const* cmd, char* rsp, int maxrsp ); // returns 0=OK, 1=channel error, 4=undefined command, // 6=bad ID, 8=response buffer overflow INTERFACE int (WINAPI DYNAMIC BCmd)( int unit, char const* cmd, char* rsp, int maxrsp); // returns 0=OK, 1=channel error, 2=unit busy, 3=unit // buffer overflow, 6=bad unit Appendix 2 #include "gsioc32.h" #include "GilsonMinipuls3.h"... JNIEXPORT jint JNICALL Java_instrumental_bomba_GilsonMinipuls3_setVelocity (JNIEnv *env, object jobj, jstring velocity, jint device) { int result; int slave = (int) device; char answer; const char *command = (*env)->getstringutfchars(env, speed, 0); // Drivers function. result = BCmd(slave,command,&answer,5); (*env)->releasestringutfchars(env, speed, command); return (jint)result; } function which has as objective to fix the velocity of the peristaltic pump Minipuls-3. The function interface and body of the function can be observed in this Appendix 2. The way for using the function BCmd of the Driver layer can be seen in the function body. (c) Logical layer: control level The logical layer comprises a group of Java classes in correspondence with 139

154 Manuel Urbano Cuadrado Tesis Doctoral each of the different hardware elements. These classes include in their definition a group of methods which make possible the control of the analysis carried out by FI. The technology used in this layer provides the system with a parallel availability for executing several tasks simultaneously and with a very precise time control. In addition, and given the logical character of this level concerning the chemical problem under study the development of a multiplatform system for ensuring its open configuration is convenient. Under these requirements, the logical layer has been developed using the Java language, which provides the Logic layer structure which exactly corresponds to the conceptual representation of an FI system. The usefulness of this Java characteristic is used in the construction of the java.instrumental.valve package, which includes the classes representative of the apparatus responsible for injecting and selecting samples and reagent in the analyser. Another characteristic of Java is its capacity to support multithread or concurrent programs, which enable the simultaneous development of several synchronised tasks. An example of this level is the class Unicam8625.java, which represents the detector UV-Visible Unicam One of the methods defined is that in charge of changing the wavelength, then adjusting the baseline. This method invokes Thread.sleep, which stops the program execution for an interval specified in the input argument. This delay time is necessary because after changing the wavelength, the spectrophotometer requires time to locate the monochromator in the new selected position and then for adjusting the baseline. Appendix 3 shows the Java code for this method. (d) Operator layer: user interface This level controls the execution of the different wine analyses carried out from the point of view of interaction with the user. From this level, the system starts to be tangible to the analyst, as it allows the input and output of information in the software. 140

155 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 Appendix 3 public void changewavelength(string port, String wavelength, Integer timesleep) { try{ setwavelength(port, wavelength); try{ Thread.Sleep(timesleep); }catch(interruptedexception e){system.out.println ("error in Thread.Sleep()");} setzeroabs(port); }catch(exception e){} This level has been built using java.awt and java.swing packages, giving rise to the powerful windows based interface. In this layer the user can stop, cancel and re-start the execution of a given analysis. (e) Experiment layer: design of flow injection methods This level enables the design of an analysis. FI analyses consist of a series of actions to be developed by the instruments involved. In this layer the information referred to number and type of instruments involved and actions to be carried out by these instruments is defined. This level was developed using Java and XML. The first allows the building of a user interface for the design, and the second provides the information storage structure. Thus,.xml files are used in order to store the definitions of the different analysis. On the other hand, the joint use of Java and XML (thanks to the JAXB, SAX and JDOM programming interfaces) makes it possible to build both the Java classes corresponding to the equipment and the procedure through which the analysis is carried out, taking into account data stored in the configuration file. 141

156 Manuel Urbano Cuadrado Tesis Doctoral Fig. 2. Example of the interface for FI analyses design. 2.5 Software developed The product is a computer application for the control of enological analyses based on the FI technique and it is being used in a winery of the appellation d origine Montilla-Moriles. It is formed by two tools: the first is in charge of either defining or modifying the procedure of the analysis and the second is in charge of executing a given analysis. The design tool is a graphical interface through which the user defines both the instruments and actions to be developed. Figure 2 shows this interface, in which, the hierarchical menu representing the analysis is on the left. The rest of the window is devoted to a framework 142

157 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 where sub-frames for data introduction and modification are launched if the user clicks the new element button or the corresponding left element, respectively. The execution tool is a graphical interface created dynamically taking into account the data referred to the given analysis that are stored in the.xml file. Figure 3 shows the control interface for the determination of volatile acidity, which requires a pump, two injection valves and a photometric detector. The control application charges a subgroup interface a frame for each type of hardware. In this case, the interface will be composed by a peristaltic pump frame, a valve frame and a detector frame. The interface differentiates each hardware element when the number of elements is higher than 1; that is, in the above example, in the valves frame two subframes are charged. As can be seen in Figure 3, there are interface elements devoted to output information inherent to the given analysis. This information involves several aspects, namely analysis time elapsed, activities in which the instruments is involved at present (sample injection, detector monitoring, activated rinsing stream, etc.), results in a graphical and numerical format, anomalous instrument behaviour, etc. 3. Results and discussion 3.1 Users participation (a) Users in the development of the software The participation of different users analysts and technicians in the development of the system has been made possible by the use of the evolutionary incremental paradigm. Thus, the requirements for interface designs, instruments control, functionality of the system, etc., have been established by the users in various meetings. A prototype has been installed in the laboratory for a first checking step. (b) Users in the analytical control under the system The program makes it possible to develop different wine analyses 143

158 Manuel Urbano Cuadrado Tesis Doctoral Fig. 3. Example of the control interface. without users intervention. The user defines the analysis and then, the definition can be modified if the experimental conditions change. Figure 4 shows the functionality referred to definition and modification of analyses. Ethanol_Glycerol.xml for the simultaneous determination of ethanol and glycerol, VolatileAciditiy.xml for the determination of volatile acidity, Total_Free_SulphurDioxide.xml for the determination of total and free sulphur dioxide and TotalPolyphenol_Anthocyan.xml for the simultaneous determination of total polyphenol index and total anthocyan index have been defined for testing the systems. For the execution of the 144

159 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 Analysis Definition include include Selection of type and number of hardware Selection of tasks for each hardware element include Save the definition for the new analysis and ready for run Chemist include Retrieval of analysis by name Update of Analysis include include Modification of neccesary data Save modifications and ready for run Fig. 4. Functionality of the design layer. analyses the users load the corresponding.xml files and the sample codes, before clicking the execute analysis button. 3.2 Improvements and limitations i. Diverse chemical parameters are determined under a unique program control. Thus, the user, after a learning period, controls most of the wine analyses carried out. The following improvements have been achieved using this automation approach: ii. The program can be modified functionally with few changes in the architecture due to the 145

160 Manuel Urbano Cuadrado Tesis Doctoral open and scalable structure of the system from the logical level. iii. The program can be installed in any platform (Windows, Linux, etc.). The main limitation of the program is the dependence of the drivers and communication layers on both the instruments and the platform used. In this way, the components of many instruments or apparatus in the laboratory for these levels have been built under Windows and Linux. Nevertheless, the introduction of a new device in the manifold of any analytical method makes necessary to develop the drivers usually provided by suppliers and communication components for this instrument. 4. Conclusions The aim of this work was to introduce an open and configurable tool for automation of wine production monitoring, intended to overcome the limitations of previous contributions, which have been restricted to a given method. The development of this program has been supported on a multi-layer model that endows the control level close to the analytical chemist with maximum independence of the physical tasks requirements to communicate with instruments. The main limitation of this model is in the programming of the low level layers components for each new type of instrument. On the other hand, the multi-layer model assures a program with open and configurable characteristics. This contribution surpasses the role of the word semi-automated in many FI methods described in enological analysis. Thus, a key tool to improve both the quality control and analysis times is presented. New research lines are open, such as remote control (through a web application) of the configuration and process monitoring, system of aid for reagents selection, etc. Acknowledgements The Comisión Interministerial de Ciencia y Tecnología (CICyT) is 146

161 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 thanked for financial support (Project AGL P4-03). Users of the built system are thanked for their help in the development of the system. References Anderson, C.J., Stone, L.B., Manual de Oracle Jdeveloper (Oracle Jdeveloper Handbook). McGraw-Hill/Oracle Press, Madrid. Booch, G., Rumbaugh, J., Jacobson, I., The Unified Modelling Language. User Manual. Addison-Wesley Longman Inc, USA. Campione, M., The Java Tutorial Third Edition. Mc Graw-Hill. Collins, A., Nandakumar, M.P., Csoeregi, E., Mattiasson, B., Monitoring of alphaketoglutarate in a fermentation process using expanded bed enzyme reactors. Biosens. Bioelectron. 16(9-12), Danet, A.F., Cheregi, M., Martinez, J., García, J.V., Aboul, H.Y., Flow-injection methods of analytes for waters. I. Inorganic species. Crit. Rev. Anal. Chem. 31 (3), Delgado, F., Fernández-Romero, J.M., Luque de Castro, M.D., Semi-automated spectrometric method for the determination of pectinesterase activity in natural and processed juices. Ana. Lett., 34 (13), Eckel, B Thinking in Java (Third Edition). Prentice Hall. Gilson S.A. LT801121K, Minipuls 3 Peristaltic Pump, User s Guide. Gilson S.A. LT3331, ValvemateTM Valve Actuator. User s Guide. Gilson S.A. LT3635, C System Interface, User s Guide. Goldfarb, C., Prescod, P., XML Handbook (Fourth Edition). Prentice Hall. González, J., Pérez-Juan, P., Luque de Castro, M.D., Semiautomatic flow-injection method for the determination of volatile acidity in wines. J. AOAC Int., 84 (6), González, J., Pérez-Juan, P., Luque de 147

162 Manuel Urbano Cuadrado Tesis Doctoral Castro, M.D., Method for the simultaneous determination of total polyphenol and anthocyan indexes in red wines using a flow injection approach. Talanta, 56, Herbert, S., C: The Complete Reference (Fourth Edition). McGraw-Hill. Jacobson, I., Booch, G., Rumbaugh, J., The Unified Software Development Process. Addison- Wesley Longman Inc. Jasnokwski, M., Java, XML, and Web Services Bible. Hungry Minds. Kontron Instruments, Spectrofluorimeter SFM 25, User s Guide, Zurich, Switzerland. Li, B.X., Zhang, Z.J., Liu, W., Flow-injection chemiluminescence determination of chlortetracycline using on-line electrogenerated [Cu(HIO6)2]5 as the oxidant. Talanta, 55(6), Lopez, I., Merino, B., Campillo, N., Hernandez, M., On-line filtration system for deter mining total chromium and chromium in the soluble fraction of industrial effluents by flow injection flame atomic. Anal. Bioanal. Chem., 373(1-2), Mataix, E., Luque de Castro, M.D., Determination of total and free sulphur dioxide in wine by pervaporation-flow injection. Analyst, 123, Mataix, E., Luque de Castro, M.D., Simultaneous determination of ethanol and glycerol in wines by a flow injectionpervaporation approach with parallel photometric and fluorimetric detection. Talanta, 51, 489. Morrison, M., XML Unleashed. Prentice Hall. Nitao, J.K., Birr, B.A., Nair, M.G., Herms, D.A., Mattson, M.J., Rapid quantification of proanthocyanidins (condensed tannins) with a continuous flow analyser. J. Agric. Food. Chem., 49(5), Okamura, K., Sugiyama, M., Obata, H., Maruo, M., Nakayama, E., Karatani, H., Automated 148

163 Comput. Electron. Agric., enviado para su publicación Parte I, cap. 2 determination of vanadium(iv) and (V) in natural waters based on chelating resin separation and catalytic detection with bindschedler s green leuco base. Anal. Chim. Acta., 443(1), Rumbaugh, J., Jacobson, I., Booch, G., The Unified Modelling Language. Reference Manual. Addison-Wesley Long man Inc. Ruzicka, J., Hansen, E.H., Anal. Chim. Acta 78, 145. Shen, H.L., Grung, B., Kvalheim, O.M., Eide, I., Automated curve resolution applied to data from multi-detection instruments. Anal. Chim. Acta., 446(1), Solich, F., Ogrocka, E., Schaefer, U., Aplication of automated flow-injection analysis to drug liberation studies with the Franz diffusion cell. Pharmazie, 56(10), Stewart, K.K., Beecher, G.R., Hare, P.E., Fed. Proc. Fed. Am. Soc. Biochem. 33, Unicam Limited (Division of Analytical Technology Inc.) , Unicam 8625 Series UV/Visible Spectrometer, UK. Zhang, B., Beck, H.P., A rapid and sensitive method for the fluorimetric determination of phosphate by flow-injection. Anal. Lett. 34(15),

164

165 Capítulo 3 TRIGGER-BASED CONCURRENT CONTROL SYSTEM FOR AUTOMATING ANALYTICAL PROCESSES El contenido de este capítulo ha sido publicado en la revista Trends in Analytical Chemistry, 23 (2004)

166

167 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 TRIGGER-BASED CONCURRENT CONTROL SYSTEM FOR AUTOMATING ANALYTICAL PROCESSES Manuel Urbano Cuadrado, M. D. Luque de Castro, Miguel Ángel Gómez-Nieto Abstract A system for the design and automation of analytical processes based on concurrent actions developed by the equipment involved is here presented. The system thus developed enables the control of any hardware that acts during a given process. The control of the process is based on time and state parameters; thus the continuous monitoring of these parameters is necessary in order to achieve the pursued aim. To take decisions without human intervention is possible due to a subsystem in charge of an intelligent control of the analytical process. The overall design of the analytical process is divided into two steps: the design of the time-based process and the design of the state-based control (triggers). The latter also manages the exceptions and alerts activated during each experiment. Automation is carried out by a procedure constructed from the data design. Computer technologies like UML, Java, XML, etc. have been used for program construction. Keywords: Experiment automation, Instrumental control, Concurrent processing, Trigger-based control. 153

168 Manuel Urbano Cuadrado Tesis Doctoral 1. Introduction Automation of chemical or analytical processes is aimed at the same objectives as in other areas, namely: shortening the time required for developing a given process, avoiding human intervention and human errors, and increasing the quality of process control [1-3]. The International Union Pure and Applied Chemistry (IUPAC) distinguishes between automatic and automated systems [4]. The formers develop programmed actions, but they can not take decisions by themselves without human intervention; decisions that can be taken by the latter. The distinction does not appear clear in chemical nor analytical publications. Thus, the word automation is referred to computer control of some step of the process; usually data collection and treatment [5-9]. With the exceptions of the wrong use of the word, the computer control has been widely implemented in the chemical field. Concerning analytical processes, where the ultimate objective is the measurement of one or several components in a sample, the process is usually divided into three steps: sample treatment which involves physical and chemical operations focussed on optimum monitoring ; the measurement step which produces bio-chemical information from the sample ; data collection and handling for obtaining proper information on the system under study. Most times, the main shortcoming of computer programs in the literature is the necessity for a specialised user for taking decisions. There are in the literature few systems which are able to substitute human decisions for avoiding user involvement in the process [10-14]. Although these approaches reach the objective of avoiding human decisions, they have a series of limitations regarding to scalability, open characteristics and so on [13]. Some of these proposals are closed systems, where the production rules, variables and other constructions to define the flow control of the process must be defined a priori and future variations in the instrumental used, analytical problems to be solved, etc., affect the system. 154

169 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 Thus, it is necessary to reprogram a large part of the system due to its low scalability. Regarding the purpose of the works described in the literature, the majority of them use control code construction or production rules but as simple logical construction (the inference engine, the knowledge propagation, etc. are not defined). If these concepts are not defined, the systems are simply based on triggers in order to avoid overall human intervention. To take decisions involves knowing the situation of the system from the values of state or time variables and either acting or not on the system depending on these values [15-17]. The research here presented is a program, the functionality of which is on the control of analytical, determination processes. The control structures used are based on time and state system domains; thus triggers are used for taking decisions through both aspects: time and state. Other, more innovative aspect of the functionality of the program is that the user can design the control structures based on both the state of the system and time parameters. Thus, the user can define the flow of the process control based on a series of state variables, functions and processes. The scalability, portability, versatility and free distribution of the developed system make it applicable to analyses of different nature, in addition to the present application to the analysis of a number of wine components. A description of the open software developed for the design and automation of analytical processes is described on: first, a classification of the processes as a function of the type of control based on time and state of the system is the subject of section 2. Section 3 describes the model proposed for representing the time-governed processes; meanwhile, section 4 describes the model and system of a state-governed control of the system. Finally, the part of the system which translates the information the user introduces in the design of the analytical process to control instructions is described in section 5. A discussion of the results obtained and the applications developed with the proposed system 155

170 Manuel Urbano Cuadrado Tesis Doctoral constitutes the last part of the article. 2. System for automation of analytical processes by a time and state-based model A process can be defined as a sequence of related actions carried out along an interval with the objective of producing a change in a given system. From the point of view of process automation and control it can be divided into two types: Type I: Processes dependent on the system state The actions which constitute an overall process are developed along the time as a function of the intermediate state reached by the system due to each previous action. Automation of these processes involves continuous control of the system by inspection and analysis of the variables or parameters which establish its characteristics. So, the actions are adopted after checking the value or state of the given variables. Traditionally, process automation has been carried out by systems based on events (actions). A series of rules are defined in these systems taking into account the values of state variables. With this aim, it is mandatory to construct a monitoring subsystem for checking the fulfilment of the established rules; if yes, the program executes the actions associated to the given rule. Type II. Processes dependent on the time within which the actions are developed In this group, the actions are developed independently of the present situation of the system. This kind of processes are characterised by actions developed in a sequential or concurrent manner along the time: they only depend on the time elapsed since the starting point of the process and are independent of the situation of the system. So, a module for control and measurement of the elapsed time is mandatory. Evidently, a given process can belong to types I and II; these processes are based on events determined by both the state of the 156

171 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 system and the time elapsed from the start of the process. State-based and time-based variables will be present in the rules, in this case. Automation of Type I pro cesses is more complex than those of Type II, and the control of the given process requires higher computer costs, due among others to the following aspects: The number of rules for action execution is, usually, higher. Continuous monitoring of the variables or parameters which determine the situation of the process is mandatory in order to use the information thus obtained for ordering the corresponding action. The module which analyses the state of the system is more complex. It requires more computer resources because a higher number of variables are involved, and a higher possibility of errors, inconsistencies and redundancies exists. In addition, it is mandatory to establish a relationship between the defined rules when more than one must be fulfilled in order to determine either the action to be executed first or the concurrent execution. Nevertheless, it is always possible to convert a type I process to a type II process. For this, it is only necessary to know the foreseeable states through which the system evolutes with time; delete this information from the rules in order to consider only time-related information, and monitor the state of the process only at its end. Most processes belong to this group (timebased processes -TBP-); that is, the user knows the initial state of the system and he/she wants to know the final state through measurement of signals provided by one or several detectors: the intermediate state is not interesting or it is known. If the intermediate state is of interest, only it is necessary to consider it as a final state of the process. Based on the above premises, a general model for the design of 157

172 Manuel Urbano Cuadrado Tesis Doctoral Hardware a 0 (t=0) a*(t=0) a*(t=t 1 ) a*(t=t 2 ) a*(t=t F ) a F (t=t F ) S 0 S 1 S 2 S F t=t 0 t=t 1 t=t 2 t=t F Start End Fig. 1. General model to design analytical processes. analytical processes can be proposed based on the structure shown in Fig.1. The initial state of the system, S 0, is known. Then, the system is subject to a series of actions to be executed in either a sequential or concurrent manner along an interval to reach a final state S F, in which the characteristics of the system are monitored again. Automation of this process involves development of the necessary actions without human intervention. For this, specific equipment or hardware is in charge of the development of these time-based actions a*. The initial action, a 0, can be executed by the user, time-based or determined by either the characteristics of the process or its state, S 0. When the process reaches its final state (t=t F ) a new series of actions are executed by the hardware, and a special action will determine the end of the process (a F ). Under this model, time is the parameter determinant for the actions to be carried out by the hardware. Despite these actions are executed at a given time, their effect can be applied along the time of the process, and several actions can be executed simultaneously; thus allowing concurrent hardware control. In addition, action a F can determine the start of the process (see Fig.1) by considering a new initial state of the process. In this way, it is possible to represent, under a time- 158

173 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 based model, processes which require evolution monitoring. In this case, it is necessary to consider as final state that corresponding to a given evolution point, to apply the final action (a F ) and, then, re-start the process control. From either an intermediate state S X or a final state S F, total automation of the process requires knowing the value of the process variables in order to use this information to take decisions affecting the process. The decisions will be executed if the analysis of the variables dictates the necessity of control actions in order to act on the process environment (user alarm); halt the process (by stopping the main execution process) or to conditioning the system for a more accurate and error-free result (by eliminating potential interferences). 3. Process design system The design and construction of a software system for automation and control of chemical analytical processes has been developed under the above-proposed process model. The main aim has been to supply analytical chemists non-experienced on informatics with a tool to design the actions to be carried out by both the hardware and analytical equipment during a given process. The system thus developed is based on a layer architecture proposed by the authors [18], which enables control of any hardware and analytical equipment. Figure 2 shows by a component diagram [19] the architecture used. The hardware participating in a process is physically controlled by drivers supplied by the manufacturers. Usually, these drivers are functions or compiled libraries developed by a procedural language (e.g. C, Basic, etc.). From these libraries, functions in C language in charge of managing the functionality provided by the hardware are constructed. These functions, which constitute the Communication level, allow modulating the hardware func tionality, thus making independent each of the physical actions to be developed by the hardware. A library with the group of defined functions is constructed for each specific 159

174 Manuel Urbano Cuadrado Tesis Doctoral This layer is often developed by manufactures Drivers Libraries built with language C Communication Classes and packages built with Java Logical Package Hardware Drivers f1 f2 Library Class properties methods m1() m2()... mk() Hardware Drivers f1 f2 Library Class properties methods m1() m2()... mk() Fig. 2. Layer architecture for the design and control of analytical experiments. hardware; thus allowing each type of hardware to be considered as an object to be managed in each process where the given hardware is used. Each of these static libraries is represented by an object class by definition of the corresponding class at the Logical level (see Fig. 2). In these object classes: The attributes represent each 160

175 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 parameter which takes part in functions defined at the Communication level (so they are defined at the interfaces of the drivers provided by the hardware manufacturers). The methods correspond to each of the functions defined at the Communication level and they are present in the static libraries developed for each type of hardware. The classes constructed at this Logical level can be compiled as packages for a better portability of the proposed system. The construction of these classes requires a specific knowledge of C and Java languages [20-22]. The latter has been used due to the availability of Java-based software for both object orientation and portability. The authors have developed a number of open-code packages for managing different type of hardware (namely, peristaltic pumps, injection and selection valves, photometric detectors, etc.) [22-24], which can be used by other researchers for the control of either other hardware or analytical equipment. The analysis and development of the proposed system for process design have been carried out under the object orientation paradigm, which allows to consider any 'logical' or 'physical' element forming part of the problem domain as an object class. Under this point of view, the developed system considers an object series (object class) as actors in the development of an automated process The analytical equipment and hardware The analytical equipment also includes the hardware in charge of preparing the analytical system for monitoring and performing. Despite IUPAC nomenclature differentiates an instrument (as that providing chemical information, as a detector) from an apparatus (as that used for performing steps which do not provide chemical information), most analytical equipment integrates both types of devices. As commented before, the Driver, Communication and Logical 161

176 Manuel Urbano Cuadrado Tesis Doctoral levels enable control at a low, medium and high abstraction level, respectively. Control of a given hardware or equipment can involve from a mechanical operation (e.g. to impel a liquid to a given module for the development of a given step) to set the values of instrumental parameters (e.g. working potential or wavelength) Constants and variables Constants in the proposed system are parameters defined by the designer, which represent properties of both the control system and the process unchangeable along the process. They can be numerical and logical, and used for taking decisions during the process development. On the contrary to constants, variables are parameters that change along the process. They can also be logical and numerical. Any number of constant and variables necessary to control can be defined during the process design. The developed system has defined by default a number of constants and variables in order to facilitate the process design. Examples of these variables are as follows: Logical constants False and True, which represent these logical values. Numerical constants, c_processtime and c_process- Number, which represent the process time and the number of times the process is repeated, respectively. The variables v_processtime and v_processnumber, which have a zero value at the start of the process, and are modified along the process and represent the elapsed time of the process and the number of processes developed. Both constants and variables are used in structures to control the process, as described below Functions Action sequences are repeated along the development of a given process. These sequences can be encapsulated as a function, thus simplifying the 162

177 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 Chart 1 /* Function to adjust the spectral parameters in a spectrofluorimeter */ void setspectralparameters(string id_port, String wavelength_exc, String wavelength_em) { /* Adjust the excitation wavelength */ setexcitationwavelength(id_port,wavelength_exc); /* Wait a given time to enable the monochromator reaches the position */ try{ Thread.sleep(5000); }catch(interruptedexception e){} /* Adjust the emission wavelength */ setemisionwavelength(id_port,wavelength_em); } /* Function for enabling the probe sampler to go to the vial which the system under study is in */ void govial(string id_port, String position) { /* Go up the probe sampler */ upvial(serial_port); /* Wait a given time to enable the probe sampler goes up */ try{ Thread.sleep(5000); }catch(interruptedexception e){} /* The probe sampler goes to the specified vial */ vial(id_port,position); /* Wait a given time to enable the probe sampler goes to the vial */ try{ Thread.sleep(5000); }catch(interruptedexception e){} /* Go down the probe sampler */ downvial(id_port); /* Wait a given time to enable the probe sampler goes down */ try{ Thread.sleep(5000); }catch(interruptedexception e){} } 163

178 Manuel Urbano Cuadrado Tesis Doctoral overall control. These functions or actions sequences can be of two types; namely: a) Those formed as a single action or actions sequence developed by one or several hardware involved in the process; thus a control structure similar to the structure corresponding to the analytical process is obtained. For example, those functions for establishing a preset velocity of the peristaltic pump, fixing the temperature in a thermostat, sampling data from a detector, etc. Chart 1 shows examples of this type of functions. b) Those formed by logical or mathematical operations on the variables and/or constants (parameters involved in the process). For example, start a repetitive sequence, determine if the sequence has been developed at the preset times, etc. Chart 2 is an example of this type of functions The structure of the process control The flow or actions sequence to be developed along a process only controlled by the time (Type II) can be described by the structure represented in Chart 3. Where do and while are reserved words. They inform on the start and end of the process for execution of the actions defined in Process-body until the function isendprocess() returns true. This will happen when the elapsed time is longer than the duration of the process. This function is defined in Chart 4. As can be seen, some of the functions defined in Chart 2 are used in Chart 4. The structure of the process body is represented in Chart 5. Under a control model governed by time, once the process has started, the control on the analytical equipment is performed and the time from the start of the process at which the given actions must be executed by each hardware element involved are indicated. For each time value the following can be specified: 1. The action to be developed by 164

179 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 Chart 2 /* Function for reset to zero the process time. It is called if the process has to be repeated when final action is executed */ void resetprocesstime() { v_processtime = 0; } /* Function to know if the system is in a time node in which the presence or absence of actions to be executed has been analysed. Thus, to call the same function in the same second is avoided */ boolean isanalysednode() { if (analysed_node = false) return true; else return false; } /* Function to acquire the present time from the object which manages the time (This object is a java thread) */ int getelapsedtime() { long time_elapsed; time_elapsed = chrono.gettime(); time_elapsed = time_elapsed/1000; return (int)time_elapsed; } Chart 3 /* Structure corresponding to a single process governed by the time*/ do{ Process-body }while ( isendprocess()!= True) the hardware. The methods defined by the classes (Logical level) corresponding to the analytical equipment used will be used. For example, the class representing the model Minipuls3 of peristaltic pumps [23] is endowed with a method 165

180 Manuel Urbano Cuadrado Tesis Doctoral Chart 4 /* Function to know if the end of the process has been reached */ boolean isendprocess() { v_processtime = getelapsedtime(); if(v_processtime <= c_processtime) return false; else return true; } Chart 5 /* Structure of the process-body */ Process-body /* Running the list of the hardware used in the process */ for (int h=0; h<hardware_list.length; h++) { /* Running the actions to be exexuted by each hardware */ for (int a=0; a<hardware_list[h].actions.length; a++) { /* If the time to be executed each actions is that the process is, the action is executed */ if (hardware_list[h].actions[a].gettime == v_processtime) { hardware_list[h].actions[a].execute(); } } } for establishing a preset velocity, as can be seen in Chart 6. This method must call the corresponding function in the hardware library (Communication level), which represents this class through the Java native interface (JNI) [21,22]. From this, the modifier native appears in the code. 2. A (b) type function in charge of realising a mathematical calculus, variables updating, etc. For example, if the detector starts monitoring at any process time, it will be necessary to 166

181 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 Chart 6 /* This class represents the peristaltic pump Minipuls3*/ class Minipuls3Pump { /* Classes code body */ native void setspeed(string id_port, String speed); /* Classes code body */ } Chart 7 /* Function incharged of setting true the variable is_monitoring which represents if the detector is monitoring */ void setmonitoring() { is_monitoring = true; } execute an action that communicates the appropriate command to the hardware for this purpose. This action is composed by two functions: the (a) type function setting the detector monitoring and the (b) type function shown in Chart 7. As can be seen, this function updates the value of the variable that represents the detector state (on/off) and it is useful when the process ends or it is interrupted. If the detector is monitoring, the program will stop monitoring before turning off the hardware remote control. As an example, the use of the constants, variables, functions and the control structures is described by an experiment carried out by a peristaltic pump that propels the chemical system under study to the detector. A valve inserts a reagent that endows the chemical system with the features to be monitored by the detector. The signal intensity is proportional to the concentration of the target component. Time data and hardware activities are shown in Table I. The control flow for this analysis begins when the setinitialactions() function 167

182 Manuel Urbano Cuadrado Tesis Doctoral Table I. Activities to be carried out by the hardware and their execution times. TIME (S) HARDWARE ACTIVITY Peristaltic pump Injection valve Electroanalytical detector Injection valve Electrochemical detector Peristaltic pump Injection valve Peristaltic pump Turn at preset speed. No injection Set potential Injection Start monitoring Stop No injection Stop Monitoring is invoked. This function orders to each hardware involved in this process to execute its initial action and also calls to the startchrono(), which initiates the part of the program in charge of time monitoring. Each second, the v_processtime is updated and the instrumental list is read out in order to verify if there are some actions to be executed. As can be seen in Table I, there are actions to execute in seconds 20 and 40. After the last actions and as the function isendprocess() returns true because the value of the variable v_processtime is higher than the value of the constant c_process- Time the endprocess() function is invoked. This function calls to other functions: namely startagain() and exitremotecontrol(), in charge of verifying if the process is executed again and, if not, it turns off the hardware remote control Designing analytical processes In this section, a time-based control of the analytical process is described. In the next section the analytical process design based on system state control structures will be described. In all instances, the configuration of the process is divided into two steps: definition of hardware; and, specifications of hardware actions. Because these actions can use 168

183 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 Fig. 3. Interface to design time-based processes. Configuration of the hardware involved in the process. constants, variables and functions to control the process, these control elements must be defined. Figure 3 shows a program interface that belongs to the subsystem in charge of defining the analytical process. As can be seen, the interface is divided into three areas: (a) an upper area where the menu bar is placed and which has all the functionality related to the process design, (b) a left-side area that shows all the components and elements involved in the process through a hierarchical menu, (c) a central framework area in charge of data input/output concerning the different elements and components. For example, if a new element (a detector) is added to the process definition, a window corresponding to this hardware component will be placed in the central framework. As can be seen in Figure 3, the users can introduce the hardware data: identifier, brand and model, hardware 169

184 Manuel Urbano Cuadrado Tesis Doctoral Fig. 4. Interface to design time-based processes. Specification of the actions to be developed by the hardware. type, communication port, and initial action. When the data introduction is finished and validated by the users and the program, respectively, the node is charged in the configuration tree (hierarchical menu). After the hardware involved in the analytical process is defined, the hardware actions can be specified. With this aim, the icon corresponding to the loading of a group of actions per time unit must be selected from the tool bar. A window, through which the user introduces hardware actions at a preset time, is charged in the framework as can be seen in Figure 4. The user introduces the time elapsed between the beginning of the process and the actions to be executed by the configured hardware after this interval. In the hierarchical menu that shows the process structure as a function of time, the corresponding to this time node is created or updated. 170

185 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 In time-based actions, the user can add other control elements like functions, constants, variables and triggers, which are also defined by the user as shown later on. Both the hierarchical menu and a window in the central framework manage information about the time-dependent actions of the hardware, as can be seen in Figure 4. Once the process is defined, its definition is stored in a file.xml, the structure of which is described in the next section. 4. Control based on the system state: triggers In automating analytical processes, a model based on the time during which the hardware executes its actions is sometimes not enough. The state of the system must also be known at each time in order to take decisions depending on the given state. These decisions both vary the control flow of the process and control the exceptions produced. For this reason, the developed software has a state-based control consisting of a triggers sub-system. A trigger is a logical rule that has the general structure shown in Chart 8. Depending on the moment at which the premises are evaluated, there are two types of triggers: 1. Triggers evaluated at the end of the process: their premises are evaluated when the process governed by the time is executing its final action (a F ). It is the simplest type because the trigger does not alter the control flow of the process. (see Chart 5). 2. Triggers evaluated in a way concurrent to the process: their premises are evaluated in parallel to the process and they have the capacity to stop or modify the control flow of the process. Their development and implementation has a high degree of difficulty because it is necessary both to synchronise the access to the status variables and their modification and create a parallel thread of execution. Problems related with concurrent access to a resource either a variable or a method, possible redundancy and high computation necessities characterise these triggers. 171

186 Manuel Urbano Cuadrado Tesis Doctoral Chart 8 /* Trigger identifier or name */ NameTrigger /* General structure of the triggers */ IF /* Logical expression or premise that has the form: (variable constant) operator (variable constant) */ premise THEN /* Action executed by the program if the premise is true. A trigger action can be a function or a new process that has the structure shown in Chart 3 */ action; Figure 5 shows the classes diagram [19] that represents the structure of the triggers sub-system. The TriggersManagement class manages all the triggers defined by the user to control the process through both manageconcurrenttriggers and managenoconcurrenttriggers methods. The Trigger class has a method in charge of evaluating the defined premises, and only if all the premises are fulfilled (this is equivalent to carry out the logical operation <and> on the group of premises), Triggers Management triggers off the process corresponding to the target trigger. The Premise class is evaluated from its structure (see Figure 5), as formed by two measurable nodes which collect the value of a constant or variable state, and an operator node in charge of a logical operation on the previous nodes. This structure, also shown in Chart 8, represents the system properties and the process control through the constants and variables and the actions corresponding to the trigger, respectively. Variables involved in the premises are consulted and modified in the triggers analysis and the actions of the main process (governed by time), respectively. For this reason, consulting and updating must be subject to a concurrent control. Constants such as c_upper- _Value and c_rinsing constants are defined by the user who designs the analytical process. They represent the 172

187 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 TriggerManagement Trigger[] triggers void : manageconcurrenttriggers( ) void : managenoconcurrenttrigges( ) 1..1 LeftNode Object variable abstract Object: evaluate( ) void : resetvalue( ) Trigger 1..n 1..1 String id_trigger int trigger_type Premise[] premise TriggerProcess process TriggerProcess Action[] actions Function[] functions void: executeprocess( ) boolean: evaluate( ) n 1..1 Premise int premise_type LeftNode left_side RigthNode rigth_node OperatorNode operator 1..1 boolean: evaluate( ) OperatorNode RigthNode int operator Object value int: getoperator( ) abstract Object: evaluate( ) void: resetvalue( ) BooleanLeftNode DoubleLeftNode BooleanRightNode DoubleRightNode boolean variable double variable boolean variable double variable Object: evaluate( ) void : resetvalue( ) Object: evaluate( ) void : resetvalue( ) Object: evaluate( ) void : resetvalue( ) Object: evaluate( ) void : resetvalue( ) Fig. 5. Class diagram with the structure of the trigger subsystem. upper limit of the measured property and the logical value for the necessity of a rinsing process, respectively. Variables v_upper_value and v_rinsing variables, updated during the process, represent the value, at time t, of the measured parameter and whether or not a rinsing process is necessary after the process governed by the time, respectively. Actions associated to a trigger can be of two types: A process governed by time as that described in section 3 (see Chart 3), so that an analytical process is designed as a group of steps that execute a list of actions in either a series or parallel way. Functions endowed with the same considerations as those described in section 3. These functions must be previously defined in order to encapsulate the hardware actions and/or update or calculate operations. Two groups of functions can be emphasized: Functions that encapsulate a sequence of actions to be 173

188 Manuel Urbano Cuadrado Tesis Doctoral Chart 9 /* Function that stops the main process */ void stopprocess() { for (h=0; h<hardware_list.length; h++) { hardware_list[h].stopaction(); } exitremotecontrol(); } Chart 10 /* Function that shows an interface warning that the detector monitored a value higher than the upper limit allowed */ void alerthighvalue() { MainInterface.alertDialog.setInfo( The value is higher than the limit ); MainInterface.alertDialog.setModal(true); MainInterface.alertDialog.pack(); MainInterface.alertDialog.show(); } executed by the hardware. A process associated to a trigger can stop the execution of the activities that form the process governed by the time. The function that stops the process and turns off the remote control of the hardware is shown in Chart 9. Alert functions. These functions act on the system environment to warn users in a graphical and/or sound format that the system is in the state that triggers off the corresponding interface or sound. Chart 10 shows the function that warns the user by an alert interface- about the monitoring of a data higher than the upper limit allowed Triggers design Although the developed software allows to define a trigger at any time, 174

189 Trends Anal. Chem., 23 (2004) 370 Parte I, cap. 3 Fig. 6. Interface to design triggers. Premises and the trigger process.. the logical sequence in the design of an analytical process is that the user defines constants, variables, functions and the control flow of the process under a view governed firstly by the time (as described in section 3). Then, the user defines the trigger subsystem, which uses the elements defined previously. The general steps sequence to define a trigger is as follows: The first step consists of identifying the trigger with a name and specifying if the trigger is concurrent or not. Figure 6 shows the definition of a trigger named ValueControlTrigger characterised as a concurrent trigger. In the following step, the user defines one by one all the premises that constitute the trigger. For that, state constants or variables are chosen from the defined group of constants and variables in a previous step. Users can select both a constant and 175

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L

I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L I GE IERÍA DEL SOFTWARE. Mª Dolores Carballar Falcón 28935146L REFERE CIA AL SISTEMA EDUCATIVO ACTUAL. Los contenidos de este tema, están enfocados a introducir al alumno en el concepto de Ingeniería del

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1

Sistemas de Información II. Introducción al Proceso Unificado de Desarrollo de Software. Autor: Ing. Silverio Bonilla 1 Introducción al Proceso Unificado de Desarrollo de Software Autor: Ing. Silverio Bonilla 1 James Rumbaugh et al. Concepto de Método Una metodología de ingeniería del software es un proceso para producir

Más detalles

Fundamentos del diseño 3ª edición (2002)

Fundamentos del diseño 3ª edición (2002) Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software

Más detalles

Tema 2. Ingeniería del Software I feliu.trias@urjc.es

Tema 2. Ingeniería del Software I feliu.trias@urjc.es Tema 2 Ciclo de vida del software Ingeniería del Software I feliu.trias@urjc.es Índice Qué es el ciclo de vida del Software? El Estándar 12207 Modelos de proceso Qué es el Ciclo de Vida del SW? Definición

Más detalles

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA

DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA DESARROLLO DE SOFTWARE CON CALIDAD PARA UNA EMPRESA Resumen AUTORIA CARLOS CABALLERO GONZÁLEZ TEMATICA INFORMÁTICA ETAPA ESO-BACHILLERATO-CFGM(ESI,ASI,DSI) Se describe la revolución que supuso la incursión

Más detalles

Interacción Persona - Ordenador

Interacción Persona - Ordenador Interacción Persona - Ordenador Diseño de la interfaz en la Ingeniería del Software Dr. Pedro Latorre Dra. Sandra Baldassarri Dra. Eva Cerezo Ingeniería del Software Ingeniería del Software: Definición

Más detalles

Modelos de desarrollo de software. septiembre de 2007 1

Modelos de desarrollo de software. septiembre de 2007 1 Modelos de desarrollo de software septiembre de 2007 1 Referencias básicas Ingeniería de software. Un enfoque práctico. Pressman, R. Quinta edición. Mc. Graw Hill 2002 Ingeniería de software. Sommerville,

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

Modelos de Proceso Tradicionales

Modelos de Proceso Tradicionales Modelos de Proceso Tradicionales Capitulo 2,QJHQLHUtDGHO6RIWZDUH (VSHFLDOL]DFLyQHQ*HUHQFLDGH6LVWHPDVGH,QIRUPDFLyQ 8QLYHUVLGDG6DQWLDJRGH&DOL Profesor: MSc. MIGUEL ANGEL NIÑO ZAMBRANO Programación: Tiempo

Más detalles

3. Principios de medición de la calidad del aire

3. Principios de medición de la calidad del aire 3. Principios de medición de la calidad del aire 3.1. Medición. Medir es contar, comparar una unidad con otra, dar una valoración numérica, asignar un valor, asignar números a los objetos. Todo lo que

Más detalles

Etapas del desarrollo

Etapas del desarrollo Capítulo 4 Etapas del desarrollo Este capítulo documenta la aplicación del modelo presentado anteriormente, para el caso de la detección y clasificación de eventos sísmicos sobre señales digitales. El

Más detalles

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular.

Un modelo de proceso es una representación abstracta de un proceso. Presenta una descripción de un proceso desde una perspectiva particular. El proceso software Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software Especificación: Definir la funcionalidad y las restricciones en

Más detalles

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.

cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred. cilred.com CICLO DE VIDA DEL SOFTWARE & METODOLOGIAS DE DESARROLLO DE SOFTWARE ING. EDUARDO CRUZ ROMERO eduar14_cr@hotmail.com cilred.com CICLO DE VIDA DEL SOFTWARE Para apreciar un poco más el problema

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Denominación de la materia. N créditos ECTS = 36 carácter = OBLIGATORIO SISTEMAS DE SOFTWARE. Ubicación dentro del plan de estudios y duración

Denominación de la materia. N créditos ECTS = 36 carácter = OBLIGATORIO SISTEMAS DE SOFTWARE. Ubicación dentro del plan de estudios y duración Denominación de la materia SISTEMAS DE SOFTWARE N créditos ECTS = 36 carácter = OBLIGATORIO Ubicación dentro del plan de estudios y duración La materia Sistemas de Software está formada por 6 asignaturas

Más detalles

Ciclo de vida del Software

Ciclo de vida del Software Tema 2: Ciclo de vida del Software Marcos López Sanz Índice Qué es el ciclo de vida del Software? La norma 12207-2008 Modelos de desarrollo Qué es el Ciclo de Vida del SW? Es una sucesión de etapas por

Más detalles

Cristian Blanco www.cristianblanco.es

Cristian Blanco www.cristianblanco.es 3.1.- INTRODUCCIÓN Para realizar el desarrollo de cualquier proyecto de software es necesario llevar una sistemática de trabajo, que nos asegure el éxito del mismo. Lo que tenemos que evitar, en el desarrollo

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título

3. OBJETIVOS. 3.1. Objetivos. Objetivos generales del título. Objetivos específicos del título 3. OBJETIVOS 3.1. Objetivos Objetivos generales del título De acuerdo con lo establecido en el Libro Blanco y el acuerdo del plenario de la Conferencia de Directores y Decanos de Informática (Zaragoza,

Más detalles

Ingeniería de Software I

Ingeniería de Software I Ingeniería de Software I Agenda Objetivo. Unidades de aprendizaje. Formas de evaluación. Bibliografía. 2 Datos del profesor Correo electrónico: egonzalez@upemor.edu.mx Asesorías Jueves de 11:00 a 13:00

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE. Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3 er Curso.

TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE. Dr. José Ignacio Peláez Sánchez E.T.S.I. Informática de Sistemas. 3 er Curso. TEMA 1 INTRODUCCIÓN A LA INGENIERÍA DEL SOFTWARE Dr. E.T.S.I. Informática de Sistemas. 3 er Curso. Año 2004/2005 Visión General Importancia de la Ingeniería del Software. Retraso en la llegada de la Ingeniería

Más detalles

INTRODUCCION A LA INGENIERIA DE SOFTWARE

INTRODUCCION A LA INGENIERIA DE SOFTWARE UNIDAD I INTRODUCCION A LA INGENIERIA DE SOFTWARE Contenido: 1.1 Definiciones 1.2 Evolucion del Software 1.3 Importancia del Software 1.4 Problemas del Software 1.5 Caracteristicas del Software 1.6 Conceptos

Más detalles

INGENIERÍA DEL SOFTWARE

INGENIERÍA DEL SOFTWARE INGENIERÍA DEL SOFTWARE Sesión No. 2 Nombre: Procesos de ingeniería del software INGENIERÍA DEL SOFTWARE 1 Contextualización La ingeniería de software actualmente es muy importante, pues con los avances

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

P1 Elaboración de un plan de proyecto utilizando MS Project G3

P1 Elaboración de un plan de proyecto utilizando MS Project G3 UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA P1 Elaboración de un plan de proyecto utilizando MS Project G3 José Luís Espinosa Aranda Noelia Vállez Enano Manuel Ramón Guerrero Álvarez

Más detalles

Competencias generales vinculadas a los distintos módulos Módulo de Formación Básica

Competencias generales vinculadas a los distintos módulos Módulo de Formación Básica Competencias generales vinculadas a los distintos módulos Módulo de Formación Básica C1. Capacidad para la resolución de los problemas matemáticos que puedan plantearse en la ingeniería. Aptitud para aplicar

Más detalles

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R

Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos. Unidad didáctica 1: Fase de análisis de requisitos Modelo E/R índice Módulo A Unidad didáctica 1: Introducción a las Bases de Datos Unidad didáctica 2: Metodologías de desarrollo de Bases de Datos 3 19 Módulo B Unidad didáctica 1: Fase de análisis de requisitos Modelo

Más detalles

Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296)

Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296) Programa de la asignatura Curso: 2009 / 2010 ANÁLISIS E INGENIERÍA DEL SOFTWARE (1296) PROFESORADO Profesor/es: MARIA BELEN VAQUERIZO GARCIA - correo-e: belvagar@ubu.es FICHA TÉCNICA Titulación: INGENIERÍA

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Grado en Ingeniería Informática

Grado en Ingeniería Informática Grado en Ingeniería Informática Competencias Generales y trasversales De acuerdo con la resolución del Consejo de Universidades de fecha 3 de marzo de 2009, para obtener este título de grado en ingeniería

Más detalles

Denominación de la materia. N créditos ECTS = 36 carácter = MIXTA INGENIERIA DE COMPUTADORAS

Denominación de la materia. N créditos ECTS = 36 carácter = MIXTA INGENIERIA DE COMPUTADORAS Denominación de la materia INGENIERIA DE COMPUTADORAS N créditos ECTS = 36 carácter = MIXTA Ubicación dentro del plan de estudios y duración La materia Ingeniería de Computadoras está formada por 6 asignaturas

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

rg.o El l c i c c i l c o l o de d vi v d i a d a cm a l@ rza e de d u n u n si s s i t s e t ma m a de d in i f n or o ma m c a i c ó i n ó b

rg.o El l c i c c i l c o l o de d vi v d i a d a cm a l@ rza e de d u n u n si s s i t s e t ma m a de d in i f n or o ma m c a i c ó i n ó b El ciclo de vida de un sistema de información El ciclo de vida de un sistema de información El proceso de desarrollo de software Modelos de ciclo de vida El ciclo de vida de una base de datos El proceso

Más detalles

SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES. Manufactura Integrada por Computadora (CIM) Qué es es CIM?

SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES. Manufactura Integrada por Computadora (CIM) Qué es es CIM? SISTEMAS DE INFORMACIÓN PARA ADMINISTRACIÓN DE OPERACIONES 2003 Manufactura Integrada por Computadora (CIM) Qué es es CIM? Bajo el nombre de CIM se engloba a un conjunto de aplicaciones informáticas cuyo

Más detalles

Taxonomía de los Sistemas de Gestión

Taxonomía de los Sistemas de Gestión Taxonomía de los Sistemas de Gestión Carlos Rivera Orozco, Rosario Rodríguez Báez Bufete de Ingenieros Industriales, S. C. Pimentel 4104 B, Las Granjas, 31160, Chihuahua, México. carlos@bii.com.mx RESUMEN

Más detalles

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos

Tema 13. Metodologías en el desarrollo de Sistemas de Software. Prof. Oscar Adolfo Vallejos Tema 13 Metodologías en el desarrollo de Sistemas de Software Prof. Oscar Adolfo Vallejos Desarrollo de Sistemas de Software Objetivo Conceptos en el contexto más amplio de Software e Ingeniería de Software

Más detalles

TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO

TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO TRABAJO FINAL ESPECIALIDAD EN CONTROL Y GESTION DE SOFTWARE GESTIÓN DE CONFIGURACIÓN DE PRODUCTOS SOFTWARE EN ETAPA DE DESARROLLO Autor: Lic. Claudio Jorge Rancán Directora: M.Ing. Paola Britos Julio 2003

Más detalles

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN

PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN PLANEACIÓN DE SISTEMAS INFORMÁTICOS ING. KARINA RAMÍREZ DURÁN Principios y criterios para la evaluación del ciclo de vida de desarrollo de sistemas Se pueden enunciar algunos principios para desarrollar

Más detalles

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software

Instruir al alumno con los conceptos, modelos, teorías y principios básicos estudiados en la Ingeniería de Software Universidad de Colima Dirección General de Educación Superior Facultad de Ingeniería Mecánica y Eléctrica Licenciatura en Ingeniería en Sistemas Computacionales I. DATOS GENERALES P R O G R A M A A N A

Más detalles

En verde están algunas propuestas que entendemos que faltan y que ayudarían a mejorar las fichas sustancialmente.

En verde están algunas propuestas que entendemos que faltan y que ayudarían a mejorar las fichas sustancialmente. NOTAS ACLARATORIAS: Esta ficha de grado es la resultante de las dos reuniones celebradas (9 enero 2009 y 23 de febrero de 2009) por la subcomisión creada desde el MICIIN para debatir las fichas de Grado

Más detalles

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO.

PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. PRINCIPIOS DE PRUEBAS. ENFOQUE ESTRATEGICO. 0. Consideraciones iniciales. Las pruebas son un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemáticamente. Por esta razón,

Más detalles

UN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR

UN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR UN ENTORNO A MEDIDA PARA EL DISEÑO Y LA SIMULACIÓN DE MAQUINARIA POR COMPUTADOR Manuel González y Javier Cuadrado Departamento de Ingeniería Industrial II, Campus de Esteiro, 15403 Ferrol Universidad de

Más detalles

1. Fundamentos de la interacción persona-computadora

1. Fundamentos de la interacción persona-computadora Interacción persona-computadora 1. Fundamentos de la interacción persona-computadora Luis Rodríguez Baena Facultad de Informática Introducción La interacción hombre-máquina es una disciplina que se ocupa

Más detalles

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software

Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Aplicación de una Metodología basada en Mediciones para la Gestión de Calidad de Software Jorge Bozo jbozo@inf.ucv.cl Escuela de Ingeniería Informática Universidad Católica de Valparaíso Valparaíso, Chile

Más detalles

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software

Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Preguntas y respuestas (rebatibles) sobre metodologías de desarrollo de software Introducción Este documento recopila las preguntas, opiniones y respuestas que se produjeron en un pequeño curso sobre las

Más detalles

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas

CAPITULO 1. Introducción a los Conceptos Generales de Bases de Datos Distribuidas CAPITULO 1 Introducción a los Conceptos Generales de 1.1 Preliminares Las empresas necesitan almacenar información. La información puede ser de todo tipo. Cada elemento informativo es lo que se conoce

Más detalles

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE

Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE Departamento de Informática Universidad de Valladolid Campus de Segovia TEMA 2: EL CICLO DE VIDA DEL SOFTWARE 1 DEFINICIÓN DE CICLO DE VIDA DEL SOFTWARE ISO/IEC 12207-1 Marco de referencia que contiene

Más detalles

POSIBLE APLICACIÓN DE LA MINERÍA DE TEXTOS A LOS TRABAJOS DE LA COMISIÓN MINISTERIAL DE INFORMÁTICA

POSIBLE APLICACIÓN DE LA MINERÍA DE TEXTOS A LOS TRABAJOS DE LA COMISIÓN MINISTERIAL DE INFORMÁTICA POSIBLE APLICACIÓN DE LA MINERÍA DE TEXTOS A LOS TRABAJOS DE LA COMISIÓN MINISTERIAL DE INFORMÁTICA M.ª del Pilar Cantero Blanco Jefa de Servicio de Sistemas Informáticos. Subdirección General de Planificación

Más detalles

BASES DE DATOS. 1.1 Funciones de un DBMS

BASES DE DATOS. 1.1 Funciones de un DBMS BASES DE DATOS Un DBMS, son programas denominados Sistemas Gestores de Base de Datos, abreviado SGBD, en inglés Data Base Management System (DBMS) que permiten almacenar y posteriormente acceder a los

Más detalles

La selectividad en análisis químico

La selectividad en análisis químico La selectividad en análisis químico Ricard Boqué Grupo de Quimiometría y Cualimetría Universidad Rovira i Virgili (Tarragona) El concepto de selectividad en análisis químico ha sido objeto de una redefinición

Más detalles

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas

Contenido de la sesión. Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Contenido de la sesión Diseño de Software Principios del Diseño Arquitectura de Software Especificación de Arquitecturas Diseño de Software Es una descripción de la estructura del software que se va a

Más detalles

Programa de Estudio: Ingeniería en Sistemas Computacionales.

Programa de Estudio: Ingeniería en Sistemas Computacionales. Ingeniería en Sistemas Computacionales 1. DEFINICIÓN DEL PROGRAMA EDUCATIVO. La ingeniería en sistemas computacionales es una disciplina que estudia los fenómenos reales con el propósito de analizar, modelar

Más detalles

Planificación y Control de Proyectos de Software mediante MS Project

Planificación y Control de Proyectos de Software mediante MS Project Práctica 2 Planificación y Control de Proyectos de Software mediante MS Project E n esta práctica vamos a introducirnos en la Planificación y Control de Proyectos de Software mediante herramientas informáticas

Más detalles

MASTER OFICIAL DE PLANIFICACIÓN Y GESTIÓN DE PROCESOS EMPRESARIALES

MASTER OFICIAL DE PLANIFICACIÓN Y GESTIÓN DE PROCESOS EMPRESARIALES UNIVERSITAT DE VALÈNCIA MASTER OFICIAL DE PLANIFICACIÓN Y GESTIÓN DE PROCESOS EMPRESARIALES ORGANISMO RESPONSABLE Departamento de Estadística e Investigación Operativa Facultad de Matemáticas Universidad

Más detalles

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION

ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION UNIDAD V ANALISIS DE REQUERIMIENTOS DE LA PROGRAMACION Contenido: 5.1 Introducción 5.2 Principios del Análisis 5.3 Construcción de Prototipos del Software 5.4 Métodos de Análisis de Requisitos 5.5 La Especificación

Más detalles

Symantec Data Center Transformation

Symantec Data Center Transformation Symantec Data Center Transformation Un marco integral para la evolución de TI A medida que las empresas se hacen cada vez más dependientes de la tecnología de la información, la complejidad, los costos

Más detalles

Antes de imprimir este documento piense en el medio ambiente!

Antes de imprimir este documento piense en el medio ambiente! Versión 1.0 Página 1 de 14 1. OBJETIVO: Suministrar la metodología que se aplicará para la estimación de esfuerzo para los desarrollos nuevos en el ICBF, para lo cual se detallan los aspectos a tener en

Más detalles

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8

Documento de Competencias. Facultad de Informática, UPV/EHU. 1 Estructura general del Grado TE1 TE2 TE3 TE4 TE5 TE6 TE7 TE8 Documento de Competencias Grado en INGENIERÍA INFORMÁTICA Facultad de Informática, UPV/EHU 1 Estructura general del Grado 1.1 Fundamentos de Tecnología de los Principios de Diseño de Sistemas Digitales

Más detalles

Tecnología VoIP integrada en Sistemas de Emergencia Policiales

Tecnología VoIP integrada en Sistemas de Emergencia Policiales Tecnología VoIP integrada en Sistemas de Emergencia Policiales Mariela E. Rodriguez 1, José Farfan 2, & José V. Zapana 3 Cátedra de Modelos de Desarrollo de Programas y Programación Concurrente / Facultad

Más detalles

Fundamentos del diseño de software

Fundamentos del diseño de software Fundamentos del diseño de software El diseño es el primer paso de la fase de desarrollo de cualquier producto o sistema de ingeniería. Definición de diseño según Taylor Proceso de aplicar distintas técnicas

Más detalles

Desarrollo de Aplicaciones con Tecnologías Web

Desarrollo de Aplicaciones con Tecnologías Web Desarrollo de Aplicaciones con Tecnologías Web Código: Modalidad: Distancia Duración: 100 Horas. Objetivos: La presente formación se ajusta al itinerario formativo del Certificado de Profesionalidad IFCD0210

Más detalles

Software de Simulación aplicado a entornos de e-learning

Software de Simulación aplicado a entornos de e-learning Software de Simulación aplicado a entornos de e-learning 2009 Laboratorio de Investigación de Software Universidad Tecnológica Nacional Facultad Regional Córdoba Titulo del Proyecto Software de Simulación

Más detalles

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño.

Introducción. Conceptos y principios. Introducción. Introducción. Elementos del modelo de análisis. Elementos del modelo de diseño. Definición de diseño Proceso para la definición detallada de un sistema con el fin de su realización física. Ingeniería del Software 1 Ingeniería del Software 2 Modelo de diseño vs. Paradigma de IS 3 actividades

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software

Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002. Introducción al Diseño de Software Principio de Diseño Resumen obtenido de: Roger S. Pressman, Ingeniería de Software. Un enfoque práctico, quinta edición, 2002 Introducción al Diseño de Software Qué es el diseño? Representación ingenieril

Más detalles

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación

Trabajo Final de Graduación para optar por el título. Bachiller en Ingeniería en Computación Trabajo Final de Graduación para optar por el título Bachiller en Ingeniería en Computación Migración del Módulo de Inventario del Sistema Business Advance Víctor Guzmán Alfaro Carrera Ingeniería en Computación

Más detalles

El monitoreo de una variable física requiere supervisión permanente de señales que

El monitoreo de una variable física requiere supervisión permanente de señales que Capítulo 1 Marco Contextual 1.1. Formulación del problema 1.1.1. Definición del problema El monitoreo de una variable física requiere supervisión permanente de señales que varían con el tiempo. Tal información,

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Tabla de Contenidos PARTE I INTRODUCCIÓN Capítulo 1: Evolución Los hitos en la evolución histórica del Desarrollo de Software Problemas y soluciones... Fallas, malas estimaciones

Más detalles

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software

Contenidos. Parte I - Introducción Capítulo 1 - Evolución. Capítulo 2 Condiciones de trabajo en el Desarrollo de Software IX Contenidos Prólogo... XIX Prefacio... XXI Guía de lectura...xxiii Parte I - Introducción Capítulo 1 - Evolución 1.1 Introducción... 2 1.2 Los hitos en la evolución histórica del desarrollo de software...

Más detalles

Por qué puede ser necesario el modelado CAD 3D paramétrico y directo

Por qué puede ser necesario el modelado CAD 3D paramétrico y directo Por qué puede ser necesario el modelado CAD 3D paramétrico y directo Cinco áreas en las que el modelado paramétrico complementa el modelado directo Introducción Durante demasiado tiempo, los equipos de

Más detalles

- Capacidad para dirigir las actividades objeto de los proyectos del ámbito de la informática de acuerdo con los conocimientos adquiridos.

- Capacidad para dirigir las actividades objeto de los proyectos del ámbito de la informática de acuerdo con los conocimientos adquiridos. Competencias generales - Capacidad para concebir, redactar, organizar, planificar, desarrollar y firmar proyectos en el ámbito de la ingeniería en informática que tengan por objeto, de acuerdo con los

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Evolución histórica 60 -. Metodologías

Evolución histórica 60 -. Metodologías TEMA 1 INTRODUCCIÓN Historia Evolución de las técnicas de programación Qué es orientado a objetos? Factores cruciales que miden la calidad del software Externos Internos La familia Orientada a objetos

Más detalles

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL

Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL Departamento de Informática y Automática INGENIERÍA DEL SOFTWARE PARTE I: TEST EXAMEN FINAL DNI Apellidos y nombre 1. Cuál de las siguientes afirmaciones no es una causa de los problemas del software?

Más detalles

PERFIL DEL INGENIERO DE SISTEMAS FUSM

PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS FUSM PERFIL DEL INGENIERO DE SISTEMAS DE LA FUSM El perfil del Ingeniero de Sistemas presencial de la Fundación Universitaria San Martín, Bogotá, está en capacidad de modelar

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES

Denominación de la materia. créditos ECTS = 36 carácter = OBLIGATORIA SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES Denominación de la materia SISTEMAS OPERATIVOS, SISTEMAS DISTRIBUIDOS Y REDES créditos ECTS = 36 carácter = OBLIGATORIA Ubicación dentro del plan de estudios y duración La materia está formada por 6 asignaturas

Más detalles

Propuesta de Métricas para Proyectos de Explotación de Información

Propuesta de Métricas para Proyectos de Explotación de Información Propuesta de Métricas para Proyectos de Explotación de Información Diego Martín Basso 1. Maestría en Ingeniería de Sistemas de Información. Universidad Tecnológica Nacional, FRBA Buenos Aires, Argentina

Más detalles

DATOS DE LA ASIGNATURA

DATOS DE LA ASIGNATURA DATOS DE LA ASIGNATURA Titulación: Licenciatura en Ciencia Ambientales Plan: 1998 Asignatura: Métodos Automáticos de Análisis Código: 24033 Créditos Totales LRU: 6.0 Teóricos: 4.5 Prácticos: 1.5 Descriptores

Más detalles

Escuela Politécnica Superior. Proyectos de Desarrollo Software. Capítulo 5. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS

Escuela Politécnica Superior. Proyectos de Desarrollo Software. Capítulo 5. daniel.tapias@uam.es. Dr. Daniel Tapias Curso 2014/ 15 PROYECTOS Escuela Politécnica Superior Proyectos de Desarrollo Software Capítulo 5 Dr. Daniel Tapias Curso 2014/ 15 daniel.tapias@uam.es PROYECTOS PROGRAMA DE LA ASIGNATURA Capítulo 1: Introducción. Capítulo 2:

Más detalles

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION)

PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) PRESENTACIÓN CMMI: (CAPABILITY MATURITY MODEL INTEGRATION) INDICE 1. Introducción 2. Estructura CMMI 3. Nivel 2 4. Nivel 3 5. Nivel 4 6. Nivel 5 7. Bibliografía INTRODUCCIÓN Qué es y por qué usar CMMI?

Más detalles

Entorno basado en tecnologías Web para el manejo de la información técnica en Centrales Térmicas

Entorno basado en tecnologías Web para el manejo de la información técnica en Centrales Térmicas Entorno basado en tecnologías Web para el manejo de la información técnica en Centrales Térmicas S. Fraga *, D. Castro *, J. Presedo *, A. Bugarín *, M. Mucientes *, S. Barro *, F. Seoane +, T. Lucas ++

Más detalles

I.3 APLICACIÓN DE UN RECONOCEDOR DE LENGUAJE NATURAL RESTRINGIDO A LA RECUPERACIÓN DE DATOS Gabriel Cordero Sánchez*

I.3 APLICACIÓN DE UN RECONOCEDOR DE LENGUAJE NATURAL RESTRINGIDO A LA RECUPERACIÓN DE DATOS Gabriel Cordero Sánchez* I.3 APLICACIÓN DE UN RECONOCEDOR DE LENGUAJE NATURAL RESTRINGIDO A LA RECUPERACIÓN DE DATOS Gabriel Cordero Sánchez* Resumen En este documento se muestra la estructura funcional de un reconocedor de lenguaje

Más detalles

Resumen. 1. Introducción. 2. Objetivos

Resumen. 1. Introducción. 2. Objetivos Propuesta para la Asignatura Sistemas Industriales en las Titulaciones de Informática F.A. Pujol, F.J. Ferrández, J.L. Sánchez, J. M. García Chamizo Dept. de Tecnología Informática y Computación Universidad

Más detalles

2. Las funciones de control interno y auditoría informáticos.

2. Las funciones de control interno y auditoría informáticos. TEMA 9 AUDITORIA DE PROYECTO 1. Auditoría: Procedimiento reglado para analizar cualitativamente y cuantitativamente la eficiencia de un proceso, una tarea o un sistema. Las auditorias pueden ser internas

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 17 CUALIFICACIÓN PROGRAMACIÓN DE SISTEMAS INFORMÁTICOS PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC303_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s

rg.o cm a Espec e i c fica c ci c ó i n ó n d e e r e r q e uer e i r mi m en e tos o l@ rza e b Di D s i e s ño d e b as a e s s s d e d at a o t s Especificación de requerimientos Diseño de bases de datos Documento de especificación del sistema 1. Definición del problema 2. Descripción funcional 2. 3. Restricciones 4. Diagramas de flujo de datos

Más detalles

HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN

HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN HERRAMIENTAS Y ENTORNOS DE PROGRAMACIÓN Tema 2. Tecnologías CASE Escuela Superior de Informática 1 Tema 2. Tecnologías CASE. Tecnologías CASE (~ 4 horas) Introducción. Conceptos, Objetivos, Herramientas

Más detalles

Migración de datos automática a partir de la información de los esquemas conceptuales 1

Migración de datos automática a partir de la información de los esquemas conceptuales 1 Migración de datos automática a partir de la información de los esquemas conceptuales 1 J.Pérez 1, J.A.Carsí 1, I.Ramos 1, V.Anaya 1, J.Silva 1, Departamento de Sistemas Informáticos y Computación Universidad

Más detalles

BASES DE DATOS MIS 308

BASES DE DATOS MIS 308 2. MODELOS DE DATOS Introducción 2.1 Entidad relación 2.2 Jerárquico 2.3 De red 2.4 Relacional Introducción Hoy en día las empresas manejan una gran cantidad de datos. Cualquier empresa que se precie debe

Más detalles

Aplicaciones Web a tu medida!

Aplicaciones Web a tu medida! Nota aclaratoria: El presente documento se realizó tomando como base el documento titulado Ingeniería de Requisitos en Aplicaciones para la Web Un estudio comparativo escrito por María José Escalona (Universidad

Más detalles

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES TEMA: La Programación Extrema aplicada al desarrollo del Sistema Informático

Más detalles