CULCyT//Ciencias de la Información Desarrollo de una Interfaz de Usuario para una Máquina de Hemodiálisis Olmos, K.1, Gómez, M.2, Rascón, L.3 Instituto de Ingeniería y Tecnología Universidad Autónoma de Ciudad Juárez 1 [email protected], [email protected], [email protected] Introducción La máquina de hemodiálisis propuesta se Este trabajo muestra el desarrollo de un compone de una computadora personal, un software cuya funcionalidad principal es sistema de control y un sistema físico. La servir de interfaz de usuario de una metodología utilizada para desarrollar el máquina de hemodiálisis. Este proyecto software se basó en el proceso de surge de la idea de construir una máquina desarrollo presentado por Larman (2003). de Esta metodología es iterativa e incremental hemodiálisis que utilice una computadora como interfaz de usuario y y divide el que permita almacenar la información de desarrollo. En cada uno de éstos se realizan los y enfermeras las etapas de análisis, diseño, codificación involucrados en el proceso. Un trabajo y pruebas. En este trabajo, el análisis se similar desarrollado por (Bengtsoon & realizó bajo un enfoque integral, en el que Bosch, 1999) presenta las experiencias en se considera la máquina de hemodiálisis el diseño del software para una máquina de (hardware y software) como un todo. Para hemodiálisis y discute la metodología facilitar el mantenimiento y los cambios en aplicada; sin embargo, hace una separación un futuro, el diseño del software fue entre hardware y software y sólo muestra realizado bajo el paradigma de orientación el modelado del software. a objetos (Booch, Lovelle, & Cernuda, pacientes, médicos CULCyT//Septiembre-Octubre 2007 proyecto en ciclos Año 4, No. 22 de 1996), con una arquitectura basada en 1. Máquina de Hemodiálisis capas (Weitzenfeld, 2005) y utilizando los La función principal de una máquina de patrones GRASP, controlador, experto, hemodiálisis es eliminar las toxinas de la alta cohesión y bajo acoplamiento, para la sangre en personas con insuficiencia renal. asignación de responsabilidades (Larman, En una sesión de hemodiálisis se le extrae 2003). la sangre al paciente por medio de un Como resultado se obtuvo un software catéter para que circule a través de un cuya funcionalidad principal es actuar circuito externo en el que se filtra para como interfaz de usuario para la máquina eliminar toxinas y exceso de agua. Una vez de hemodiálisis propuesta. La verificación libre de toxinas la sangre es regresada al del software se llevó a cabo al sustituir el paciente. sistema de control por una computadora En la figura 1 (Graves, 2001) se muestran personal que ejecuta un software que los principios básicos del proceso de una emula las funcionalidades de este último. máquina de hemodiálisis la cual utiliza una Además, al haber sido diseñado bajo el bomba pulsátil para mantener el flujo paradigma de orientación a objetos y sanguíneo simulando el bombeo que hace tomando en cuenta los patrones de diseño y el corazón. Mientras la sangre circula fuera la arquitectura de tres capas, se considera del paciente es necesario inyectar heparina que el software cumple con los factores para evitar su coagulación. Para ello se externos de corrección, extensibilidad, incluye un mecanismo que presiona el reutilización y facilidad de uso, cualidades émbolo de una jeringa con un flujo que de acuerdo a Meyer (1999) determinan definido para toda la sesión. El proceso de la calidad de un sistema de software. eliminación de toxinas se realiza mediante CULCyT//Septiembre-Octubre 2007 Año 4, No. 22 Figura 1. Principios básicos del proceso de una maquina de hemodiálisis (Graves, 2001). un filtro al cual le llega la sangre y una detectar burbujas en la sangre antes de que solución salina. Las toxinas de sangre son ésta se regrese al paciente. En caso de que liberadas por diferencia de presiones. Para alguna variable esté fuera de su intervalo evitar que se altere la temperatura de la preestablecido se activa un oclusor que sangre que se le regresará al paciente es presiona la línea que regresa la sangre al importante que la solución salina se paciente. mantenga a una temperatura similar a la En la figura 2 se puede observar la corporal. máquina de hemodiálisis propuesta la cual Este proceso incluye un sistema de alarmas consta de una computadora personal, un para cuidar la seguridad del paciente. Es sistema de control y un sistema físico. La necesario monitorear el funcionamiento de computadora personal albergará un sistema la bomba de sangre y la bomba de heparina de software cuya función principal es así como monitorear presiones arterial y actuar como interfaz de usuario. La venosa, temperatura de la solución salina y CULCyT//Septiembre-Octubre 2007 Año 4, No. 22 MódulodeControl Tarjetas de control RS232 Tarjeta Maestra Tarjetas Esclavas Sistema Físico Figura 2. Esquema general de la máquina de hemodiálisis (Vazquez, Ortega, Ochoa, Gómez, Rascón, & Olmos, 2001). computadora a su vez se comunica con el reenviarlos sistema de control a través del puerto serie correspondiente. El monitoreo y control y este último sistema se conecta a los del sistema físico se divide en cuatro componentes físicos (Vazquez, Ortega, secciones: bomba de sangre, bomba de Ochoa, Gómez, Rascón, & Olmos, 2001). heparina, control de temperatura y alarmas. El sistema de software permite configurar Por cuestiones de seguridad se utiliza un las especificaciones de la sesión de esquema de control distribuido en el que se hemodiálisis y sirve como interfaz entre el asigna una tarjeta esclava a cada una de operador y el sistema físico para realizar la estas secciones. (Gómez & Ortega, 2002). sesión de diálisis. El sistema de control se 2. Metodología divide en dos secciones: una tarjeta El desarrollo del sistema de software de la maestra y cuatro tarjetas esclavas. La máquina tarjeta maestra realiza la comunicación siguiendo una metodología basada en el entre la computadora y las tarjetas proceso presentado por Larman (2003). esclavas. Esta comunicación se lleva a Esta metodología utiliza UML (Booch, cabo al recibir los códigos enviados por la Rumbaugh, & Jacobson, 2005) como computadora lenguaje de modelado, es iterativa e personal, analizarlos CULCyT//Septiembre-Octubre 2007 y a de la tarjeta hemodiálisis se esclava realizó Año 4, No. 22 incremental y divide el proyecto en ciclos tres capas, además de utilizar los patrones de desarrollo, en cada uno de los cuales se GRASP para asignar las responsabilidades realizan las etapas de análisis, diseño, de las clases que constituyen el sistema de codificación y pruebas. Los resultados del software (Larman, 2003). El diagrama de análisis y diseño del primer ciclo de clases se obtuvo a partir de los diagramas desarrollo fueron reportados en (Olmos, de secuencia. Gómez, Bravo, & Rascón, 2005). La funcionalidad del software se probó al El análisis se realizó bajo un enfoque remplazar el sistema de control por una integral en el que se considera la máquina computadora personal que ejecuta un de hemodiálisis (hardware y software) software que emula las funcionalidades de como un todo. Los artefactos que se este último. El software de emulación obtuvieron en esta etapa fueron el modelo permite de casos de uso, que consta del diagrama enviaría de casos de uso y de los flujos de eventos comunicarse con la interfaz de usuario. de cada uno de ellos, el modelo conceptual Así mismo, recibe y despliega los códigos y el diagrama de estados. que esta última le enviaría al sistema de En la etapa de diseño se elaboraron los control. diagramas de actividades y los diagramas 3. Análisis del sistema de secuencia para cada caso de uso, así El desarrollo del sistema de software de la como el diagrama de clases. Con el fin de máquina de hemodiálisis requirió, en que mantenible, primer lugar, entender el funcionamiento reutilizable, legible y flexible, el diseño se de la máquina como un todo. Por lo tanto, realizó con un enfoque de arquitectura de el el sistema fuera CULCyT//Septiembre-Octubre 2007 seleccionar el análisis sistema de los códigos de que control requerimientos al abarcó Año 4, No. 22 diferentes estrategias como 1) entrevistas a El modelo conceptual, reportado nefrólogos y a enfermeras especializadas, (Olmos, Ortega, Gómez, Fernández, & 2) asistencia a sesiones de hemodiálisis, 3) Rascón, 2002) se obtuvo a partir de los análisis de sesiones grabadas en video y 4) casos de uso. El modelo representa a la utilización de ingeniería inversa a una máquina propuesta en dos niveles de máquina de hemodiálisis. Los artefactos abstracción; en el primer nivel, la máquina generados en la etapa de análisis fueron el de hemodiálisis se divide en el sistema de modelo de casos de uso, el modelo software, el sistema de control y el sistema conceptual y el diagrama de estados, los físico, de acuerdo a la arquitectura cuales se explican a continuación. mostrada en la figura 2. En el segundo 3.1. Modelo de Casos de Uso nivel estos subsistemas se dividen en El modelo de casos de uso consta del componentes y se representan a un nivel de diagrama de casos de uso y el flujo de detalle suficiente. Lo que permite conocer eventos asociado a cada uno. Para la las interacciones entre los componentes y generación de los casos de uso se siguieron entre los sistemas. En este nivel se puede las recomendaciones proporcionadas en observar que el sistema de software será (Armour & Miller, 2001). Un total de responsable de la administración de los dieciocho casos de uso fueron encontrados, pacientes, de los usuarios y de las sesiones dentro de los más significativos se de diálisis. Además, este sistema tendrá un encuentran: inicializar sistema, normalizar módulo de comunicación que permitirá sistema y realizar sesión (Olmos, Ortega, intercambiar mensajes con el sistema de Gómez, Fernández, & Rascón, 2002). control. El modelo conceptual del sistema 3.2. Modelo Conceptual CULCyT//Septiembre-Octubre 2007 Año 4, No. 22 en de software se puede observar en la figura 3. Modelo del Sistema de Software Usuario inicia_una tiene_un Sesión de diálisis Registro de sesión tiene_un contenido_en actualiza Administrador tiene_un tiene_un Doctor Registro de usuario esta_contenido_en Archivo de usuarios Archivo de registros de sesión dializa_a_un Paciente tiene_un Registro de paciente actualiza_un descrito_en_un contenido_en Archivo de pacientes Módulo de comunicación Figura 3. Modelo conceptual del sistema de software (Olmos, Ortega, Gómez, Fernández, & Rascón, 2002). 3.3. Modelo de estados sistema hacia estos eventos (Booch, Las máquinas de estado son especialmente Rumbaugh, & Jacobson, 2005). útiles para comprender el comportamiento En la figura 4 se observa el diagrama de del sistema al modelar los aspectos estados del caso de uso de “Realizar sesión dinámicos de éste. Una máquina de estados de hemodiálisis”. El programa espera que especifica las secuencias de estados por las el usuario introduzca sus datos y después que pasa un objeto, un caso de uso o un de validarlos muestra el menú principal. Si sistema completo, a lo largo de su vida. el operador selecciona la opción Realizar Esta secuencia de determina de acuerdo a sesión de hemodiálisis, el programa envía los eventos recibidos y a la respuesta del un código de inicio al sistema de control y espera a que éste le regrese el código que CULCyT//Septiembre-Octubre 2007 Año 4, No. 22 representa el estado actual del sistema del sistema físico realiza físico. El estado se determina al encender diagnóstico de sus componentes. un auto el sistema de control cuando cada módulo Figura 4. Diagrama de estados de la sesión de hemodiálisis. Si el código que envía el sistema de control alarma durante el tratamiento el sistema de al sistema de software es válido el control manda un código al sistema de operador debe elegir la temperatura a la software, el cual indicará al operador el cual se mantendrá el líquido dializante y tipo de alarma a través de la interfaz de seleccionar la opción Normalizar. Cuando usuario. Es importante mencionar que la se alcanza la temperatura establecida, el acción ejecutada en respuesta a la alarma sistema de software le indica al operador se realiza automáticamente en el sistema que puede introducir las especificaciones físico o por el operador. Si el problema que requeridas e iniciar el tratamiento de causa la alarma se resuelve el sistema de diálisis. En caso de que se presente una software continúa con el tratamiento, si no, CULCyT//Septiembre-Octubre 2007 Año 4, No. 22 éste se interrumpe y el operador finaliza la sesión. Figura 5. Interfaz de usuario de la máquina de hemodiálisis. 4. Diseño personal. El diseño de la interfaz de 4.1 Diseño Interfaz de Usuario usuario se muestra en la figura 5. El diseño de la interfaz de usuario se 4.2. Diseño dinámico realizó tomando como base la máquina de El hemodiálisis Baxter 550, la cual dispone diagramas de actividades y los diagramas de indicadores analógicos y se opera de de colaboración de cada uno de los casos una forma manual mediante perillas y de uso. Para facilitar el mantenimiento y selectores. Sin embargo, fue necesario los cambios en un futuro, el diseño del agregar software fue realizado bajo el paradigma controles que estuvieran en diseño dinámico máquina de hemodiálisis propuesta y que arquitectura basada en capas y utilizando permitieran y facilitaran la operación de la los patrones GRASP de controlador, máquina experto, alta cohesión y bajo acoplamiento, computadora CULCyT//Septiembre-Octubre 2007 objetos, con los de la a de concordancia con la arquitectura de la mediante orientación consta una Año 4, No. 22 para la asignación de responsabilidades. clase por cada sección de la interfaz de Algunas de las clases se obtuvieron del usuario que agrupara a los indicadores y modelo se controles. Por ejemplo, en la figura 7 se que puede observar el diagrama de clases de la permitieran la funcionalidad esperada del sección bomba de heparina. La clase software. ControladorBombaHeparina agrupa a una 4.3. Diseño estático perilla, un indicador y los botones de El diagrama de clases representa el diseño Primer bolo y Enviar, que están en estático del sistema de software. Este correspondencia con esta sección en la diagrama se obtuvo al concentrar la interfaz de usuario. Así mismo, cada información de cada uno de los diagramas sección de la interfaz de usuario tendrá su de secuencia generados en el diseño clase dinámico. La figura 6 representa el funciones similares diagrama derivarán de conceptual, tuvieron que de sin agregar clases embargo clases del sistema de correspondiente. la Debido estas clase a sus clases se abstracta software. Como puede observarse el ControladorSecciones como se muestra en usuario y el sistema de control se la figura 8. consideran clase Para lograr una arquitectura basada en ControladorSesionDialisis se generó de capas, la estrategia a seguir fue separar las acuerdo al patrón controlador y es una de clases del dominio de las clases de interfaz, las clases más importantes ya que es como se menciona en (Weitzenfeld, 2005). responsable de la secuencia de eventos en Los eventos de la interfaz de usuario son una sesión de diálisis. Una de las capturados por una clase denominada GUI, estrategias que se siguió fue generar una la cual únicamente tiene la responsabilidad actores. La CULCyT//Septiembre-Octubre 2007 Año 4, No. 22 del manejo de eventos del operador. Esta relacionadas clase manda un mensaje con el evento aplicación. solicitado clase En el caso de que el sistema de control Ésta requiera comunicarse con la PC la clase determina las acciones a seguir: modificar comunicador recibirá el mensaje y lo los controles de la interfaz o comunicarse pasará a la clase AnalizadorDeCódigo, la con el sistema de control. En el primer cual es responsable de descifrar el código y caso la clase es responsable de determinar enviarlo al o a los qué secciones están involucradas en el sección para que estos a su vez manden evento solicitado por el usuario y enviar la mensajes a sus elementos y se visualice en información necesaria para que realicen su la pantalla los efectos del código enviado tarea. En el segundo caso se envía un por el sistema de control. Cabe mencionar mensaje a la clase Comunicador para que que según la arquitectura de la máquina, el ésta sea la responsable de mandar el sistema mensaje al sistema de control. La clase responsable de indicar al usuario los Comunicador es la que contiene toda la eventos que están sucediendo en la sesión información de diálisis. La creación de una clase a la ControladorSesionDialisis. relacionada con la de con el software de la controladores de únicamente responsable el sistema de control. El hecho de utilizar enviados por el sistema de control permite una clase especialmente diseñada para el delimitar las responsabilidades y que el manejo de estos eventos permitirá en un diseño se considere de bajo acoplamiento. futuro Esto permitiría en un futuro hacer cambios comunicación sin el esquema afectar CULCyT//Septiembre-Octubre 2007 las de analizar los es comunicación a través del puerto serie con modificar de dominio códigos clases Año 4, No. 22 en los códigos de envío, sin afectar las clases del dominio de la aplicación. Figura 6. Diagrama de clases del sistema de software. Figura 7. Diagrama de clases de la sección bomba de heparina. Figura 8. Clases abstracta ControladorSecciones y sus clases derivadas. 5. Resultados estático y dinámico. El programa se El código de la interfaz de usuario se desarrolló utilizando el entorno de Visual desarrolló tomando como base el diseño Studio CULCyT//Septiembre-Octubre 2007 2005 con el lenguaje Año 4, No. 22 de programación y utilizando los (hardware) es el responsable del sistema controles e indicadores proporcionados por físico y la funcionalidad del sistema de Measurement software es servir de interfaz de usuario. Instruments. C# Studio El punto de National la Dependiendo del tipo de alarma el usuario codificación fue la configuración del o el sistema de control deberán encargarse puerto serie, la cual fue resuelta en el de estabilizar el sistema. Por lo tanto, en el trabajo de Hernández y Herrera (2006). caso de las alarmas, el sistema de software Se considera que el uso de patrones únicamente GRASP y el diseño basado en la correspondientes en la interfaz pero no arquitectura de tres capas proporciona al realiza ninguna acción para reponerse de la sistema alarma. atributos de crítico en calidad como activa los controles mantenibilidad, reutilizabilidad, legibilidad 6. Conclusiones y flexibilidad. Una de las decisiones más relevantes de Como se mencionó al inicio del artículo, este proyecto fue iniciar con el análisis del para realizar el sistema de software y funcionamiento probarlo se sustituyó el sistema de control hemodiálisis de forma integral en lugar de por Las trabajar únicamente con el sistema de pruebas se llevaron a cabo utilizando los software. Esto permitió determinar los casos de uso como casos de prueba. requerimientos del sistema de software de Durante las pruebas el sistema se comportó una forma más precisa y contextualizada. de requerimientos Por otro lado, el seguir un proceso de establecidos. En el diseño de la máquina de desarrollo permitió que el sistema de hemodiálisis software se construyera de una manera una computadora acuerdo a el los personal. sistema CULCyT//Septiembre-Octubre 2007 de control de la máquina Año 4, No. 22 de sistemática y que se pudiera llevar un deben considerar todos los escenarios del control durante el desarrollo del mismo. La sistema además de que la documentación principal ventaja del proceso fue que se generaría conforme se avance en el permitió desarrollar un software que proyecto. cumpliera con los requerimientos de Con esta aplicación se da por terminado el funcionalidad. desarrollo del sistema de software, como El proceso implicó contar con una trabajo futuro se esperaría finalizar con el documentación en UML lo que facilitó la sistema de control y realizar las pruebas tarea de integración de nuevos miembros al del sistema en forma integral. proyecto. En particular los casos de uso Como aplicación adicional creemos que mostraron su efectividad al ser una este sistema de software puede servir como adecuada fuente de información para ayuda en la capacitación de médicos y entender el sistema, ya que enfermeras que requieran aprender el los nuevos miembros del equipo de desarrollo sólo funcionamiento requirieron del estudio de éstos para hemodiálisis. involucrarse en el dominio de de una máquina de la aplicación. Trabajos citados Por lo anterior, consideramos que esta Armour, F., & Miller, G. (2001). Advanced metodología sería de gran utilidad para los Use Case Modeling. Addison-Wesley. ingenieros de desarrollo de hardware Bengtsoon, P., & Bosch, J. (1999). Haemo principalmente en aplicaciones complejas Dialysis Arquitecture Design Experiences. basadas en microcontroladores. Lo anterior International Conference on Software debido a que desde el inicio del diseño se Enginiering, (págs. 516-526). CULCyT//Septiembre-Octubre 2007 Año 4, No. 22 Booch, G., Lovelle, C., & Cernuda, J. M. Larman, C. (2003). UML y Patrones. Una (1996). Análisis y Diseño Orientado a introducción al análisis y diseño orientado Objetos. Addison Wesley. a objetos y al proceso unificado. Madrid: Booch, G., Rumbaugh, J., & Jacobson, I. Pearson Education. (2005). Unified Modeling Language User Meyer, Guide (2 edition ed.). Addison-Wesley. software Orientado a Objetos. Madrid: Gómez, M., & Ortega, L. (2002). Diseño Prentice Hall. de un Sistema de Tarjetas Maestra-Esclava Olmos, K., Gómez, M., Bravo, G., & basada en la Vista de Casos de Uso para Rascón, L. (2005). Utilización de un una Máquina de Hemodiálisis. XXIV Proceso de Desarrollo de Software para la Congreso Internacional de Electrónica. Construcción 24. Hemodiálisis: Etapas de Análisis y Diseño. Chihuahua, México: Instituto B. (1999). de Construcción una Máquina de de Tecnológico de Chihuahua. CONIELECOMP. Puebla. Graves, G. (2001). Arterial and Venous Olmos, K., Ortega, L., Gómez, M., Pressure Monitoring During Hemodialysis. Fernández, L. F., & Rascón, L. (2002). Nephrology Nursing Journal , 28 (1), 23- Utilización de UML en el Modelado de 30. una Máquina de Hemodiálisis desde el Hernández, G., & Herrera, I. (2006). punto de vista de Casos de Uso. SOMI Desarrollo de un Sistema de Software para (Sociedad Mexicana de Instrumentación). la manipulación de una Máquina de Mérida. Hemodiálisis utilizando el Paradigma de Vazquez, R., Ortega, L., Ochoa, H., Orientación Gómez, M., Rascón, L., & Olmos, K. a Objetos. Tesis Licenciatura, IIT-UACJ, Juárez, México. CULCyT//Septiembre-Octubre 2007 de (2001). Diseño y Construcción de una Año 4, No. 22 Máquina que no Utiliza el Sistema de Weitzenfeld, A. (2005). Ingeniería de Preparación de Líquido Dializante. Foro Software orientada a objetos con UML, Estatal Java e Internet. México: Thompson. SIVILLA-CHIHUAHUA. Chihuahua. CULCyT//Septiembre-Octubre 2007 Año 4, No. 22