Lenguajes y plataformas formales

Para la descripción del modelo se emplean los lenguajes formales UML y OCL. El UML es un estándar gráfico para visualizar, especificar, construir y documentar un sistema de software. Es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad, se emplea para describir un modelo del sistema¹⁴. No obstante, el UML por sí mismo carece de formatos para especificar restricciones detalladas de las clases (componentes del sistema de información) y los tipos de datos. Para incrementar la expresividad de UML, se crea el OCL, una notación formal que permite describir restricciones adicionales acerca de los objetos en modelos UML y así expresar todos los aspectos relevantes de una especificación¹⁵. OCL es un lenguaje sin efectos colaterales que nunca altera los objetos del modelo, sino que completa los diferentes artefactos de la notación UML con requerimientos formalmente expresados. Existen otros lenguajes que incrementan la expresividad del UML, pero OCL es el único que está estandarizado¹⁶.

Es importante mencionar que el OCL ha sido utilizado para modelar problemas de diferente índole, por ejemplo, para validar las propiedades de seguridad del sistema de trenes del Metro de San Francisco¹⁷, para especificar la API de la tarjeta inteligente Java Card¹⁸, para la transformación de estándares para facilitar el intercambio electrónico de información clínica¹⁹, o para especificar reglas de negocio de mensajería financiera²⁰.

El EMF es un esquema de modelado estructurado para la construcción de aplicaciones basadas en definiciones de modelos, unificando tres tecnologías: Java, XML y UML, permitiendo la definición de modelos mediante una herramienta de modelado del UML, un esquema XML o especificando anotaciones en interfaces Java; todo ello para cerrar la brecha entre el modelado y la programación²¹. Dos subproyectos destacan: EcoreTools (ET), un entorno completo para crear, editar y generar automáticamente código fuente a partir de un modelo; y la EMF Client Platform (ECP), un marco para construir aplicaciones cliente basadas en EMF, tanto aplicaciones de escritorio, como web o móviles²². Además, EMF tiene la ventaja de ser software libre, es decir, no se quiere comprar licencias para su uso.

Extracción de datos

El diseño de menús se adapta a las necesidades nutricionales y geográficas, entre otras. Así, aunque el modelo propuesto puede adaptarse a otras regiones, los datos empleados en el software desarrollado fueron los utilizados por nutriólogas/os de la Universidad Juárez Autónoma de Tabasco (Tabasco, México), los valores nutricionales de los alimentos base (ingredientes) se tomaron de tablas empleadas en México^23-24, las fórmulas de gasto energético y factores de actividad física son descritos en el modelo más adelante.

Diseño de software a partir de un modelo

El diseño del software se realizó por expertos en computación en la Universidad Juárez Autónoma de Tabasco (Tabasco, México). Se utilizó la metodología RAD (Rapid Application Development) que acelera la construcción de un sistema al basarse en el desarrollo iterativo y la construcción de prototipos. Para conocer los requerimientos del software se revisaron las guías de alimentación y se acudió a clases presenciales en la institución mencionada, donde los nutriólogos describen el proceso de elaboración de menús y se procedió a entrevistar a los expertos para confirmar los pasos del proceso. Una vez definido el proceso, se propone un modelo¹², que se simplifica a continuación con fines ilustrativos para generación automática de código. Posteriormente, se emplea EMF para generar código automáticamente. Finalmente, se valida y verifica el modelo en colaboración con las/os nutriólogas/os que harán uso de éste.

Modelado del dominio de menús nutritivos

Para modelar las Leyes de la Alimentación es necesario, en primer lugar, definir el dominio del problema a considerar. Es decir, definir formalmente los conceptos empleados en la elaboración del menú: usuario, alimento base, menú, preparación, actividad física. Para ello, se diseñó el diagrama de clases mostrado en la Figura 1, representando el modelo de dominio. Se utilizó el Paradigma Orientado a Objetos por ser el estándar actual en el diseño de software, junto con la metodología de diseño bottom-down, en la que las partes individuales del sistema se diseñan con detalle y luego se enlazan para formar componentes más grandes, hasta formar el sistema completo.

Figura 1 Modelo de dominio. 

Las clases son representaciones abstractas de objetos existentes, son la forma de diseño e implementación más utilizada de manera computacional. Una clase contiene atributos y métodos. Los atributos son datos básicos, por ejemplo, en la clase Usuario tenemos los atributos de nombre, género, edad, estatura, peso, actividad física, con patologías y presupuesto; los métodos son operaciones sobre dichos datos, por ejemplo, en la clase Usuario tenemos el método CalcularPT(), cuyo fin es tomar el atributo de estatura y calcular un peso teórico ideal correspondiente al usuario. A su vez, estas clases pueden estar relacionadas entre sí. Otros elementos del diagrama de clases son las enumeraciones, las cuales son tipos de datos que consisten en un conjunto de valores con nombre que se comportan como constantes en el lenguaje de programación, un ejemplo es la enumeración ActividadFísica que considera 4 contantes designando los tipos de actividad física: reposo, ligera, moderada e intensa. A una variable que ha sido declarada de tipo enumerado sólo se le puede asignar como valor cualquiera de los miembros de esa enumeración.

La Figura 1 muestra el modelo de dominio propuesto, diseñado en el editor de diagramas visual del entorno EcoreTools versión 1.2 para generar el meta-modelo Ecore. Se le denomina meta-modelo ya que es posible crear modelos a partir de éste²⁵ (en el resto del documento se utilizará modelo y meta-modelo indistintamente). El diagrama resultante se almacena en formato XML Metadata Interchange (XMI), especificación estándar para el intercambio de diagramas UML entre diferentes herramientas de modelado. El modelo propuesto en este trabajo simplifica el modelo previo¹² para generar las interfaces gráficas necesarias en la validación de menús.

Este nuevo modelo se encuentra disponible en la plataforma en línea Open Science Framework²⁶. La información técnica, el código fuente y los ejemplos se encuentran disponibles con licencia libre (http://doi.org/10.17605/OSF.IO/25FQ7).

El modelo de la Figura 1 se puede interpretar como sigue: un menú consta de un conjunto de preparaciones y se prescribe a un usuario en particular, los macronutrientes y la energía que proporciona el menú se calculan a partir de las preparaciones; una preparación se compone de un conjunto de alimentos base, los macronutrientes y la energía que proporciona la preparación se calculan a partir de los alimentos base, la preparación puede ser una bebida o un platillo y se ingiere en un momento particular del día; un usuario tiene diversas características y requerimientos de nutrientes, y se relaciona con un conjunto de alimentos preferidos y un conjunto de alimentos que no tolera; un alimento base es una sustancia indivisible que contiene nutrientes específicos y que pertenece a cierto grupo alimenticio.

A continuación, se describen los elementos del modelo de dominio, es decir, las enumeraciones, clases y sus relaciones.

Enumeraciones

Las seis enumeraciones requeridas son:

Clases y sus relaciones

La clase Usuario representa a la persona con características particulares que requiere de un menú. Los requerimientos del usuario son implementados en los métodos de la clase y son calculados como sigue:

Para obtener el peso teórico (PT) del individuo se utiliza la Ecuación 1 ²⁸, modelada con el método calcularPT() en la especificación de la clase Usuario.

Para obtener el requerimiento energético del usuario en estado sedentario o de reposo, conocido como Gasto Energético Basal (GEB), se utiliza la ecuación de Harris-Benedict revisada por Mifflin & St Jeor²⁷, empleada para calcular el GEB en mujeres (Ecuación 2) y otra que permite calcular el GEB en hombres (Ecuación 3). Este par de ecuaciones se modelan con el método calcularGEB().

El Efecto Termógeno de los Alimentos (ETA) consiste en el gasto energético que se necesita para procesar los alimentos, 10% del GEB²⁹ (Ecuación 4). Esta ecuación se implementa en el método calcularETA().

El Gasto por Actividad Física (GAF) del usuario se obtiene a partir de la Tabla 1. El Factor de Actividad Física (FAF) es el porcentaje del GEB que se emplea dependiendo la actividad física del individuo²⁷ (Ecuación 5). La Ecuación 5 se modela con el método calcularGAF().

El Gasto Energético Total (GET) corresponde a la recomendación diaria de calorías para satisfacer los requerimientos del usuario²⁹, para ello al GEB se le suma el ETA y el GAF (Ecuación 6). La Ecuación 6 se modela mediante el método calcularGET().

La relación entre la clase Usuario y la clase AlimentoBase existe en dos formas, dado que un usuario puede tener un conjunto de alimentos que le agradan y un conjunto de alimentos intolerables. Estas relaciones se representan con las propiedades favoritos e intolerables dentro de la especificación de la clase Usuario.

La clase AlimentoBase representa a todas aquellas sustancias ingeribles que pertenecen a alguno de los grupos alimenticios (e.g. manzana, queso o miel). En las preparaciones, estos alimentos constituyen los ingredientes. En este caso, la clase carece de métodos.

La clase Preparacion representa tanto a bebidas como a platillos. Las bebidas corresponden a preparaciones líquidas que pueden ingerirse durante un momento del día (comida completa) (e.g. 8oz de jugo de naranja con betabel, 250mL de horchata de arroz, o 1 taza de café). Los platillos corresponden a preparaciones sólidas que pueden ingerirse durante una comida completa (e.g. platillo denominado “moros y cristianos” consistente de 40g de frijoles y 70g de arroz).

Para calcular la energía, carbohidratos, proteínas, lípidos y precio de la preparación, existe el método apropiado dentro de la clase Preparacion que calculan estos valores a partir de los ingredientes que contiene. La clase Preparacion contiene 1 o más alimentos base. Esta relación de composición entre la clase Preparacion y AlimentoBase se representa mediante la propiedad ingredientes.

La clase Menu modela el conjunto particular de preparaciones que debe ingerir el usuario durante el día para satisfacer sus requerimientos. La relación de composición se da entre la clase Menu y las clases Usuario y Preparacion, dado que un menú existe cuando se compone de 1 o más preparaciones y se asocia únicamente a 1 usuario.

La energía, carbohidratos, proteínas, lípidos y precio del menú se obtienen empleando métodos que calculan estos valores a partir de los atributos de las preparaciones del menú.

Modelado de las Leyes de la Correcta Alimentación

Para la especificación de las restricciones, se diseñó una invariante para cada una de las leyes. Una invariante es una regla bien formada que define una restricción sobre una clase en particular, en este caso, las restricciones enunciadas en las Leyes de la Alimentación son definidas sobre la clase Menu.

Por el momento, este modelo considera únicamente usuarios adultos, con un peso dentro de un rango del 10% alrededor de su peso teórico ideal, y sin patologías. Es decir, individuos de entre 18 y 60 años, sin sobrepeso ni bajo peso, con una talla o estatura estándar y sin enfermedades. El rango de porcentaje para considerar que un individuo posee un peso aceptable, es de 90-110% del peso teórico que se obtiene mediante la Ecuación 1. Es decir, si el peso real del usuario se encuentra dentro de este rango se considera que el individuo no posee bajo peso ni sobrepeso²⁷. Las unidades de medida del peso, estatura y edad son kg, cm y años, respectivamente.

La Ecuación 1 permite determinar el peso teórico a partir de la estatura de un individuo, sin embargo, se establece para la estatura estándar el límite inferior de 142cm y el límite superior de 191cm, restricción impuesta para que la Ecuación 1 provea pesos teóricos aceptables²⁷.

Estas restricciones se establecen en las invariantes de la clase Usuario, las cuales definen usuarios adultos sanos dentro del rango de peso aceptable y estatura acotada.

Ley de la Cantidad

“La cantidad de la alimentación debe ser suficiente para cubrir las exigencias calóricas del organismo y mantener el equilibrio de su balance”³⁰. Para determinar si la alimentación es suficiente se debe estimar el gasto calórico o energético del individuo, no existe una fórmula de estimación estándar, sin embargo, se consideran las necesidades basales relativas a la edad, género, peso, talla y estado fisiológico o patológico, a las que debe añadirse el costo térmico del proceso de los alimentos, y otros factores, tales como el gasto energético empleado en la realización de actividad física. Así, un balance calórico es adecuado cuando la cantidad de calorías que se ingieren durante el día se aproxima al gasto calórico del individuo. En este estudio se propone emplear la Fórmula 6 para estimar este gasto, sin embargo, el modelo es flexible y puede ser adaptado empleando otras fórmulas para la estimación de este gasto, incluso se puede adaptar a los datos calóricos calculados por dispositivos de monitoreo de actividad física y presión o relojes inteligentes.

Toda alimentación que cumpla con esta ley se considera suficiente. Si no cubre las exigencias calóricas para mantener el balance es insuficiente, y si el aporte es superior a las necesidades se considera excesiva³¹.

La invariante LeyDeLaCantidad establece que los alimentos ingeridos deben aportar las cantidades calóricas requeridas para satisfacer las exigencias energéticas del cuerpo (GET), con un margen de error del 10%.

Ley de la Calidad

“El régimen de alimentación debe ser completo en su composición para ofrecer al organismo, que es una unidad indivisible, todas las sustancias que lo integran”³⁰. Esta ley establece que los alimentos ingeridos contengan los nutrimentos de cada grupo de alimentos³, y puede cumplirse considerando los grupos de alimentos establecidos en las guías de alimentación. Algunas de las guías de alimentación más conocidas son: el ‘Plato ideal’⁴, ‘Plato del bien comer’³, o ‘MyPlate’⁵. Estas guías esquematizadas como “platos” dividen los alimentos en grupos, con base en su composición y en el aporte de nutrimentos.

Aquella alimentación que cumple con esta ley se considera completa. Aquella en la cual, un principio nutritivo falta o se halla considerablemente reducido se denomina carente³¹.

La invariante Ley De La Calidad menciona que los alimentos consumidos durante el día deben contener los nutrientes necesarios provenientes de los 5 grupos de alimentos propuestos por la SEEN⁴.

Ley de la Armonía

“Las cantidades de los diversos principios nutritivos que integran la alimentación deben guardar una relación de proporciones entre s픳⁰. Para mantener la relación armónica en las cantidades de los macronutrientes (carbohidratos, proteínas y lípidos), actualmente se establece que, del aporte calórico diario, los carbohidratos deben cubrir entre el 50-70%, las proteínas entre el 10-20% y los lípidos entre el 25-35%⁷, donde la suma de porcentajes de los tres nutrientes es el 100%. Los macronutrientes contienen calorías, donde cada gramo de carbohidratos aporta 4kcal, cada gramo de proteínas aporta 4kcal y cada gramo de grasas aporta 9kcal.

Toda alimentación que cumple con esta ley se considera armónica, equilibrada o como se le conoce coloquialmente, balanceada. Si los principios nutritivos no guardan esta proporción, el régimen es disarmónico o desequilibrado³¹.

La invariante LeyDeLaArmonia indica que los macronutrientes contenidos en los alimentos deben guardar la relación de proporción mencionada. Además, en conjunto con la invariante LeyDeLaCantidad se valida que la suma de la energía consumida a través de los macronutrientes no exceda el ±10% del GET del usuario (ver detalles en línea²⁶).

Ley de la Adecuación

“La finalidad de la alimentación está supeditada a su adecuación al organismo”³⁰. La Ley de la Adecuación señala que los nutrientes ingeridos deben ser acordes a la edad, actividad física y estado fisiológico del individuo, cultura, religión, entre otros factores. Las invariantes de usuario descritas en el modelo contemplan únicamente a individuos sanos mayores de edad. Sin embargo, esta última ley representa aspectos no considerados en las precedentes. Así, la alimentación se debe adaptar a gustos, hábitos, tendencias, y situación socioeconómica del usuario³⁰. Cuando no se cumple con esta ley, el régimen de alimentación se considera inadecuado o incorrecto³¹.

La invariante LeyDeLaAdecuacion propone la adecuación del menú considerando tanto la preferencia como la intolerancia a ciertos alimentos, y contemplando la situación económica del usuario.

En el modelo propuesto sólo se incluyen algunos aspectos de esta ley, sin embargo, los expertos en nutrición pueden detallar los parámetros que deben incluirse para complementar el modelado de esta ley, incluso el modelo puede extenderse e incluir lineamientos de guías alimentarias específicas.

Verificación y validación del modelo

La verificación del modelo responde a la pregunta “¿Es correcto el modelo?”, mientras que la validación del modelo responde a la pregunta “¿Es el modelo correcto?”³². Para responder a la primera pregunta, el OCLinEcore Editor verifica la correcta sintaxis y semántica de las restricciones con respecto al modelo de dominio. Esta funcionalidad es posible en tiempo de ejecución mientras se escribe el código, de tal manera que se garantiza que las invariantes se encuentran bien formuladas.

Para responder a la segunda pregunta, se generó una aplicación embebida en el Entorno Eclipse a partir del modelo de la Figura 1 bajo el patrón de diseño denominado Modelo-Vista-Controlador (MVC). Las aplicaciones desarrolladas bajo este patrón separan los datos y la lógica de negocio (el modelo), la gestión de eventos (el controlador) y la interfaz de usuario (la vista o UI por las siglas en inglés de User Interface) en tres componentes distintos pero relacionados entre sí¹⁵. El código fuente del modelo fue generado automáticamente vía EcoreTools, el controlador es gestionado por el Entorno Eclipse, y la vista se generó empleando la EMF Client Platform (ECP).

ECP contiene el componente EMF Forms, que facilita el desarrollo de UIs por medio de formularios, al permitir la descripción de UIs mediante un modelo Ecore en lugar de escribir el código manualmente. La ventaja principal, aparte de la creación automática de la vista, es que las UIs pueden actualizarse sin esfuerzo al modificar el modelo³³. Además, ECP permite renderizar la vista hacia web, aplicación de escritorio Swing, JavaFX, aplicación SWT, o aplicación embebida³⁴.

En la Figura 2 se muestra el formulario creado para la clase AlimentoBase. Mediante esta interfaz se pueden ingresar los datos de cada instancia de un alimento, esto es, los ingredientes de cualquier preparación. En el caso de que diferentes preparaciones requieran el mismo alimento, simplemente se crean distintas instancias de la clase AlimentoBase y se asocian a la preparación correspondiente.

Figura 2 UI de la aplicación para capturar alimentos base. 

Las instancias de cada entidad son almacenadas en un repositorio local en formato XML Metadata Interchange (XMI), especificación estándar para el intercambio de diagramas UML entre diferentes herramientas de modelado. Es posible visualizar, editar y eliminar instancias del repositorio, así como conectar la aplicación a una base de datos.

Para generar un menú nutritivo de acuerdo a este modelo, se utilizó la información de nutrientes contenida en las “Tablas de valor nutricional de los alimentos”²³, así como en las “Tablas de alimentos Equivalentes”²⁴ que emplean los nutriólogos en México para el diseño de menús; los precios de los productos se tomaron de un supermercado del sur de México. De esta manera se valida y verifica el modelo, al crear instancias válidas para cada clase y cada relación cumpliendo con las invariantes³².

Para validar menús, en primer lugar, se define el usuario del menú, un ejemplo de características se muestra en la Figura 3 (izquierda). En este caso se trata de una mujer cuya edad, estatura, peso y estado de salud son validadas por las invariantes definidas en la clase Usuario; y puede observarse que este usuario tiene un alimento ‘favorito’ y uno ‘intolerable’. En la Figura 3 (izquierda) se muestra el uso de la consola interactiva del OCL (Interactive OCL) al consultar los valores de la instancia. Un ejemplo de usuario no válido se muestra en la Figura 3 (derecha). En este caso se trata de una instancia vacía, en la cual no se cumplen las invariantes establecidas para un usuario válido.

Figura 3 Instancias de la clase Usuario y consulta OCL. 

Dado que los elementos básicos de un menú son los alimentos base, éstos son los primeros elementos en describirse. En la Figura 4 (arriba-izquierda) se muestra una instancia de un AlimentoBase, correspondiente a 1 taza de jugo de naranja.

Figura 4 Instancias de las clases AlimentoBase, Preparacion (una bebida y un platillo) y Menu. 

Una vez instanciados los alimentos base, éstos se utilizan para crear las preparaciones (platillos y bebidas). En la Figura 4 (arriba-derecha) se muestra una instancia de una bebida y en la Figura 4 (abajo-izquierda) se muestra una instancia de un platillo. Estos platillos y bebidas componen el menú final. En la Figura 4 (abajo-derecha) se muestra la instancia del menú válido detallado en la Tabla 2.

Cuando el menú se valida y cumple con las 4 Leyes de la Alimentación, se muestra un letrero con el resultado de validar la instancia del menú, como se muestra en la Figura 5 para el menú presentado. Esto indica que cada una de las diferentes instancias que componen el menú es válida.

Figura 5 Menú válido con respecto al modelo. 

Se validaron con el apoyo del software 7 menús, incluido el descrito, los cuales fueron generados por el experto en computación que modeló las leyes, posteriormente estos menús también fueron validados por las/os nutriólogas/os solicitantes del software. También el software se empleó para analizar un menú proporcionado en un gimnasio, descrito en Figura 3 (izquierda), donde se pudo observar que el menú era hipercalórico, hiperproteico e hiperlipídico, y se adaptó para satisfacer las restricciones.