Software

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