Whitepaper

Proyecto Hormiga: problemas de ingeniería civil resueltos por ingenieros civiles

Norma Ércoli	Hugo J. Curti	Leonardo Román
Claudia Dietrich	Mariano Sanchez	Facundo Cabrera

RESUMEN

La resolución de problemas de Ingeniería Civil (diseño de estructuras, cálculo de dimensionado, etc.) tiene en su esencia una combinación de pasos completamente automatizados por un lado y pasos donde se deben tomar decisiones por el otro. Además, todo el proceso está regulado por reglamentos complejos, a veces cambiantes, y diferentes en función del país donde se aplique. Este artículo presenta el Proyecto Hormiga, un esfuerzo interdisciplinario realizado por Ingenieros Civiles e Ingenieros de Sistemas con el objeto de crear un sistema informático que dé soporte a la resolución de estos problemas. El Proyecto presenta un lenguaje de programación con componentes declarativas especialmente estudiado para adaptarse a las estructuras de pensamiento que utilizan los ingenieros civiles. La especificación de los problemas y sus soluciones son aportadas por los mismos usuarios, que colaboran constantemente en la extensión y actualización, sin necesidad de conocimientos avanzados de programación.

1. Introducción

El diseño y/o verificación de secciones de hormigón armado correspondientes a losas llenas, vigas y columnas, solicitadas por flexión, corte y compresión son solo algunos ejemplos de los diversos cálculos que se hacen en la disciplina de la Ingeniería Civil. Estos cálculos se caracterizan por tener algunos pasos que se siguen en forma automática, ya sea mediante fórmulas matemáticas o algoritmos definidos. Así mismo, estos cálculos también poseen otros pasos donde el Ingeniero debe tomar decisiones, hacer ajustes y repetir iterativamente varias pruebas hasta encontrar una solución óptima. Todos estos cálculos y procesos están regulados por un reglamento que es revisado periódicamente, y que además difiere según el país o región de aplicación.
En este contexto se plantea el desarrollo de un sistema informático que permita al Ingeniero Civil tomar las decisiones necesarias en cada paso del cálculo, y automatice el resto del proceso, facilitando de esta manera su tarea, acortando tiempos y reduciendo la probabilidad de cometer errores. Este sistema debe poder adaptarse fácilmente a los cambios reglamentarios y a diferentes países. Para el desarrollo de este proyecto se conforma un grupo interdisciplinario integrado por Ingenieros Civiles, Ingenieros de Sistemas y estudiantes. Se adopta para el sistema el paradigma de Software Libre y se propone una solución que permite a los Ingenieros Civiles especificar los pasos de cálculo, de forma tal que la misma comunidad de Ingenieros Civiles que utilizan el software contribuyan a su constante actualización y extensión. Para este fin se diseña un lenguaje de especificación que tiene componentes declarativas, componentes funcionales y componentes procedurales, con una semántica cercana a la estructura de pensamiento de los Ingenieros Civiles. Este lenguaje puede aprenderse y utilizarse con mínimos conocimientos de programación de computadoras.
En la sección 2 se describe brevemente la historia del proyecto. La sección 3 se describe el sistema y sus criterios de diseño. En la sección 4 se especifican los roles de los usuarios del sistema y su interacción con el mismo. La sección 5 presenta el lenguaje de especificación de cálculo y finalmente en la sección 6 se presentan las conclusiones del desarrollo.

2. Historia

En el año 1998 el Centro de Investigación Nacional de reglamentos para la Seguridad de las Obras Civiles, CIRSOC decidió modificar la base reglamentaria utilizada en Argentina (CIRSOC201). El comité ejecutivo de dicho centro envió un su momento una nota solicitando a la Facultad de Ingeniería de la Universidad Nacional del Centro de la Provincia de Buenos Aires colaboración para la elaboración y puesta en operación del nuevo reglamento. Desde la Facultad se generaron varias respuestas a este requerimiento, centradas en difusión de información y capacitación de egresados y profesionales. Como una de esas respuestas nació en el año 2006 el Proyecto Hormiga, por medio de un convenio entre la Facultad de Ingeniería y el Colegio de Ingenieros de la Provincia de Buenos Aires. El objetivo original era la implementación de una herramienta informática que ayudara a los usuarios a diseñar o verificar secciones de hormigón armado en diferentes estructuras. Luego de un estudio cuidadoso del contexto el objetivo evolucionó hacia desarrollar un soporte informático que permita a los mismos usuarios especificar los pasos de cálculo, crear una comunidad de usuarios y mantener la plataforma actualizada.

3. El Sistema

El sistema se desarrolló de acuerdo a los siguientes criterios de diseño:
a) Los procesos de cálculo deben poder ser especificados por Ingenieros Civiles, con mínima o nula intervención de Ingenieros Informáticos.
b) A los Ingenieros Civiles que especifiquen los procesos de cálculo no se les debe requerir conocimientos de Informática, en particular de programación. Si bien dichos conocimientos son deseables, deben reducirse a un mínimo.
c) El sistema debe adaptarse al esquema de pensamiento de los usuarios finales, ofreciendo un camino de solución similar al que utilizan naturalmente.
d) El sistema debe poder aceptar contribuciones de la comunidad de Ingenieros Civiles.
e) El sistema se desarrollará de acuerdo al paradigma de Software Libre (RS2007), al igual que todas las herramientas y librerías utilizadas como base para desarrollarlo.
f) La interfaz gráfica y el motor de cálculo deben mantenerse con un mínimo de acoplamiento.
El criterio a) busca desacoplar la interacción de Ingenieros Civiles e Informáticos, de manera tal de permitir a la herramienta evolucionar según las necesidades de los primeros.
El criterio b) tiene por objetivo minimizar la curva de aprendizaje de quienes deseen aportar especificaciones al sistema para extenderlo, adaptarlo o mejorarlo.
Aplicando el criterio c) quienes asuman el rol de usuarios finales tendrán acceso al sistema mediante una interfaz intuitiva, adaptada a los esquemas de pensamiento que habitualmente siguen para resolver los problemas, fundamentalmente, dividiendo el problema en pasos de cálculo.
El criterio d) busca que el sistema se adapte a las necesidades reales de los usuarios, admitiendo una evolución natural, análoga a la que haga la comunidad de usuarios. Aplicando este criterio el sistema debe poderse extender y actualizar en función de los cambios que se produzcan en la legislación, así como también adaptarse a las legislaciones de otros países o regiones.
El criterio e) tiene como objetivo asegurar que tanto el sistema en sí mismo, como las herramientas que se utilicen de base para desarrollarlo permanecerán accesibles a la comunidad. De esta forma se busca garantizar la libertad de uso de la herramienta: el sistema será accesible a todos en el presente y en el futuro sin necesidad del pago de contratos de licencia para utilizarlo, estudiarlo, modificarlo o redistribuirlo.
El criterio f) busca que el motor de la aplicación esté separado de la presentación de resultados y la toma de datos, de manera tal que se facilite la adaptación en el futuro a otras formas de uso, o la integración con sistemas mayores.



Como primera medida, y para satisfacer los criterios a) y b), se desarrolló un lenguaje de especificación de cálculos que permite describir los mismos en términos sintáctica y semánticamente cercanos al esquema de pensamiento que utilizan los Ingenieros Civiles en la resolución de problemas, reduciendo de esta forma la curva de aprendizaje del lenguaje y del sistema en general.
Para satisfacer los criterios c) y d) se definen dos tipos de usuarios: el denominado usuario desarrollador, y el denominado usuario final. El usuario desarrollador contribuye especificaciones de cálculo, mientras que el usuario final accede al sistema por medio de una interfaz gráfica diseñada de manera tal que le permite proponer y probar cada paso del cálculo, pudiendo corregir y verificar los resultados.
El sistema informático se divide en dos partes cuyo acoplamiento se busca minimizar, siguiendo el criterio f). Por un lado el intérprete toma una especificación, datos estáticos provistos junto con ella y los datos de entrada provistos por el usuario final, para procesar los cálculos y ofrecer como salida los resultados de los mismos. Por otro lado la interfaz de usuario interactúa con el intérprete y presenta al usuario final los resultados obtenidos, así como también le permite ingresar o modificar los datos de entrada, de una forma altamente interactiva e intuitiva.
La figura 1 muestra los componentes del sistema así como también la interacción entre los mismos y con los usuarios.

4. Los Usuarios

Siguiendo los criterios de diseño, se definen dos perfiles de usuario para el sistema, descriptos a continuación. La interacción entre los mismos y el sistema puede verse también en la figura 1.

4.1. Usuario Final

El usuario final utiliza el sistema desde su interfaz gráfica. El sistema le presenta los pasos de cálculo, tal como están especificados, ordenados en una vista de árbol a partir de sus dependencias. Cada paso tiene un estado, representado por un color. Un paso está deshabilitado (gris) cuando sus dependencias no están satisfechas, nunca ejecutado (negro) cuando las dependencias están satisfechas y el usuario nunca ejecutó el paso, ejecutado exitosamente (verde) cuando el paso fue ejecutado y las postcondiciones se cumplen y ejecutado en falla (rojo) cuando el paso fue ejecutado pero las postcondiciones no se cumplen.
El usuario final puede optar por ejecutar cualquier paso que no se encuentre en estado deshabilitado. Luego de la ejecución el sistema recalculará automáticamente el paso ejecutado y todos los pasos que dependan de él, actualizando sus estados.
Para cada paso ejecutado, se presentan al usuario las capturas, donde el usuario especificará los datos de entrada del paso. Luego de la ejecución, y si las postcondiciones se cumplen, el sistema mostrará al usuario la pantalla de resultados.
El usuario repetirá los pasos de cálculo todas las veces que sean necesarias hasta obtener una solución que considere óptima, en un proceso de aproximación iterativa.

4.2. Usuario Desarrollador

El usuario desarrollador provee una especificación, escrita en el lenguaje hormiga pensado para tal fin, y descripto en la siguiente sección. El usuario desarrollador debe dividir el cálculo en pasos, especificando para cada paso las dependencias (conjunto de datos que se necesitan a fin de que el paso pueda ejecutarse), las capturas (conjunto de datos que deben requerirse al usuario final), las precondiciones (condiciones que deben cumplir las capturas para ser consideradas datos de entrada válidos), el bloque de ejecución (calculo de los resultados a partir de las capturas y las dependencias), las postcondiciones (condiciones que deben cumplir los resultados luego de la ejecución a fin de considerarse que los resultados son válidos) y los reportes (datos a presentarse al usuario final). Junto con la especificación, el usuario puede proveer datos estáticos (tablas, gráficos, etc.) que ayuden al usuario final a elegir los valores de las capturas.
Todas las contribuciones hechas por los usuarios pueden publicarse en un repositorio donde quedan accesibles para usuarios finales y usuarios desarrolladores. De acuerdo con el paradigma de Software Libre, los usuarios pueden utilizar, revisar, corregir, mejorar o extender los trabajos realizados por otros usuarios, de manera tal que la comunidad de usuarios del sistema es la misma que lo mantiene actualizado para que satisfaga sus necesidades, y corrige errores que puedan cometerse.

5. El lenguaje

El lenguaje de especificación, denominado lenguaje hormiga, es un lenguaje multi paradigma con orientación declarativa (PL2007), especialmente diseñado para adaptarse al esquema de pensamiento que utilizan habitualmente los ingenieros civiles para resolver los problemas de cálculo.

5.1. El paso de cálculo

En el lenguaje se modela la solución de un problema de cálculo dividiendo el mismo en pasos. Cada paso debe ser declarado por el usuario desarrollador. La figura 2 muestra los componentes del paso de cálculo. Puede considerarse que el paso de cálculo es la unidad declarativa principal del lenguaje. Dentro del ámbito de un paso pueden declararse funciones, magnitudes, unidades, variables locales (solo serán visibles dentro del bloque de ejecución), variables exportadas (resultados provistos por el paso), reportes (resultados mostrados al usuario final), capturas (valores requeridos al usuario final), dependencias (variables exportadas de otros pasos que se requieren para calcular este paso), precondiciones (condiciones que deben cumplir las capturas para poder ejecutarse el paso) y postcondiciones (condiciones que deben cumplir los resultados para considerarse que el paso es válido).
El bloque de ejecución del paso se especifica de manera similar a una función. En este bloque son visibles todas las dependencias, y pueden modificarse los valores de las variables, tanto locales como exportadas.

5.2. Funciones

Una función en lenguaje hormiga coincide con una función matemática: no puede tener estado interno ni efectos colaterales. Las funciones permiten especificar mediante expresiones matemáticas, proceduralmente (o con una combinación de ambos métodos) la forma en que se obtiene un resultado a partir de uno o más parámetros. Dentro de una función se pueden declarar variables que solo tienen visibilidad local y pueden utilizarse para almacenar resultados intermedios. Respetando el paradigma funcional puro, todos los datos que se utilizan para calcular el resultado de una función deben ser estrictamente pasados como parámetro.

5.3. Magnitudes y unidades

Las magnitudes son los tipos de datos del lenguaje hormiga. Cada variable, captura o reporte debe corresponder a una magnitud. A su vez, cada magnitud debe tener una o más unidades. Cuando se asigna un valor a una variable puede indicarse una unidad, para que el sistema realice automáticamente la conversión a la unidad canónica. Las magnitudes serán controladas por el sistema durante el pasaje de parámetros a las funciones.

5.4. Variables

Las variables pueden declararse dentro de una función, o dentro del ámbito de un paso. Las variables declaradas dentro de una función solo son visibles dentro de la función, y solo tienen alcance dentro de la declaración de función. Las variables locales en el ámbito del paso de cálculo solamente son visibles dentro del bloque de ejecución. Las variable exportadas, también dentro del ámbito del paso de cálculo, tienen alcance global, y para ser visibles dentro de otro paso, deben ser declaradas como dependencia en el mismo.

5.5. Reportes

Los reportes son resultados que serán mostrados al usuario final. Además de una variable, también deben tener un tipo de reporte asociado, que indica la forma en que el resultado será presentado (numero, progreso, gráfico, imagen, etc.). Los reportes reflejarán siempre el valor de su variable asociada. El sistema construirá en forma automática la ventana de reporte para el paso de cálculo.

5.6. Capturas

Las capturas permiten requerir al usuario final un valor. Además de una variable, también deben tener un tipo de captura asociado (número, progreso, imagen, etc.). Cada captura puede tener una condición asociada, que restringe los valores que el usuario final puede ingresar en la misma. La variable asociada a una captura adquirirá automáticamente el valor indicado por el usuario final en la captura. El sistema construirá en forma automática la ventana de captura para el paso de cálculo.

5.7. Dependencias

Las dependencias indican las variables exportadas de pasos anteriores que deben tener valores válidos a fin de que el paso de cálculo pueda realizarse. También puede indicarse una dependencia hacia otro paso en forma explícita. Utilizando la información provista por las dependencias, el sistema construirá la vista de árbol y calculará en forma automática el estado de cada paso.

5.8. Precondiciones

Las precondiciones son condiciones que deben cumplir las capturas y las dependencias para considerar que el paso de cálculo puede ejecutarse. El sistema evaluará las precondiciones luego de que el usuario ingrese los valores de todas las capturas, y antes de ejecutar el paso. Si alguna precondición no se cumple el paso no se ejecutará y se mostrará un aviso de error al usuario final, quien tendrá entonces la oportunidad de corregir las capturas, o cancelar la ejecución.

5.9. Postcondiciones

Las postcondiciones son condiciones que deben cumplir los resultados de la evaluación de un paso de cálculo para considerarlos válidos. El sistema evaluará las postcondiciones luego de ejecutar el paso de cálculo. Si alguna postcondición no se cumple el paso se considerará ejecutado en falla, y se mostrará un aviso de error al usuario final.

5.10. Módulos

Un conjunto de magnitudes, unidades, pasos y/o funciones pueden agruparse semánticamente dentro de un módulo. Los módulos pueden ser luego importados en otras especificaciones. El agrupamiento en módulos permite construir librerías de magnitudes, funciones y/o pasos de cálculo que luego podrán ser utilizados en otros proyectos.

6. Conclusiones

Hormiga es un proyecto interdisciplinario que incluye profesionales de la informática, y de la Ingeniería Civil. Como tal presenta un modelo de desarrollo donde la informática se brinda como un servicio hacia otra disciplina (en este caso la Ingeniería Civil) dando como resultado un trabajo que combina sinérgicamente logros y formas de pensar.
El proyecto permite una independencia de los ingenieros civiles respecto de la informática. Ellos mismos pueden especificar las soluciones utilizando sus propios métodos y su propia forma de pensar, logrando naturalmente que la herramienta se adapte a sus necesidades y requerimientos.
El desarrollo basado en Software Libre garantiza la disponibilidad de la herramienta y sus componentes, reforzando el principio colaborativo sobre el que este proyecto se afirma, y no podría funcionar si no se creara una comunidad de usuarios finales y usuarios desarrolladores. Para que esta comunidad se sostenga en el tiempo todo el material disponible debe estar accesible.

Bibliografía

(CIRSOC201) CIRSOC, Reglamento Argentino de Estructuras de Hormigón, 2005
(RS2007) Richard Stallman, The GNU Manifesto, 2007
(PL2007) Pascual Julián Iranzo y María Alpuente Frasnedo, Programación lógica: teoría y práctica, 2007

---