universidad pontificia de comillas · el motor de inferencias funciona con un procedimiento de...

DIPAC Fernando-Román Ávila Vázquez

UNIVERSIDAD PONTIFICIA DE COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO INFORMÁTICO

PROYECTO FIN DE CARRERA

SISTEMA DE DETECCIÓN Y DIAGNÓSTICO DE PATOLOGÍAS EN LA CONSTRUCCIÓN

DIRECTORES: JOSE ANGEL OLIVAS VARELA

ARMANDO FUENTES GANZO

AUTOR: FERNANDO-ROMÁN ÁVILA VÁZQUEZ

1


Índice 0.- Resumen................................................................................................................... 3 1.- Introducción............................................................................................................... 6 1.1.- Descripción......................................................................................................... 7 1.2.- Motivación del proyecto...................................................................................... 9 1.3.- Objetivos .......................................................................................................... 11 2.- Descripción de técnicas de Ingeniería del Conocimiento a usar............................. 12 2.1.- Adquisición del conocimiento ........................................................................... 12 2.2.- Conceptualización del conocimiento ................................................................ 18 2.3.- Representación del conocimiento .................................................................... 25 2.4.- Razonamiento .................................................................................................. 42 2.5.- Tipos de Sistemas Basados en Conocimiento................................................. 53 3.- Descripción del problema a tratar ........................................................................... 55 4.- Estudio de viabilidad ............................................................................................... 63 5.- Adquisición y representación del conocimiento y razonamiento............................. 67 5.1.- Adquisición del conocimiento ........................................................................... 67 5.2.- Conceptualización del conocimiento ................................................................ 70 5.3.- Representación del conocimiento .................................................................... 78 5.4.- Razonamiento .................................................................................................. 80 6.- Implantación............................................................................................................ 88 7.- Evaluación y pruebas.............................................................................................. 94 8.- Conclusiones......................................................................................................... 105 8.1.- Grado de cumplimiento de los objetivos ........................................................ 108 8.2.- Una nueva idea para el papel del ingeniero del conocimiento....................... 110 9.- Bibliografía ............................................................................................................ 114 10.- Presupuesto ........................................................................................................ 115 11.1.- Anexo1-Entrevistas .......................................................................................... 116 11.2.- Anexo2-Base de reglas.................................................................................... 119 11.3.- Anexo3-Manual de usuario .............................................................................. 124 11.4.- Anexo4-DRPIE................................................................................................. 136 11.5.- Anexo5-Árbol de casos .................................................................................... 146 11.6.- Anexo6-Ontología ............................................................................................ 154 11.7.- Anexo7-Mapa de conocimiento........................................................................ 155

2


Capítulo 0.- Resumen La aplicación desarrollada es un Sistema Experto para la detección y diagnóstico de patologías en la construcción. Primeramente el usuario navegará por una serie de menús gráficos mediante los cuales aportará información al sistema. Esta información consistirá en:

- El tipo de edificio que se está tratando, los tipos de edificios se agrupan en cuatro categorías

- El síntoma principal que se observa - El elemento constructivo afectado por dicho síntoma - Características concretas del síntoma

Como cualquier otro sistema basado en conocimiento consta de una serie de fases relacionadas con el tratamiento del conocimiento que hay que ir cubriendo. Las fases en cuestión son:

- Adquisición del conocimiento - Conceptualización del conocimiento - Representación del conocimiento

Para la adquisición del conocimiento se han utilizado principalmente las técnicas de la entrevista y el seguimiento de experto. Esto último se realizó durante tres meses del verano pasado (2004). Se ha consultado a varios expertos, pero los colaboradores principales han sido dos arquitectos superiores entre los que se encuentran el codirector del proyecto Armando Fuentes Ganzo, y Román Ávila García, Arquitecto con más de treinta años de ejercicio profesional. Con este último experto se realizó la etapa de seguimiento. Además de la información aportada por los expertos, que ha sido la más valiosa y abundante, se ha utilizado diversa documentación con diferentes fines. La conceptualización del conocimiento supuso el punto de inflexión donde se debía profundizar lo suficiente en el conocimiento adquirido para poder formalizarlo y representarlo posteriormente. Para poder plasmar en detalle todo el proceso de inferencia, con las particularidades propias de cada caso se creó el “Diagrama de Representación del Proceso de Inferencia del Experto” o DRPIE. Con este diagrama, junto con el mapa de conocimiento, y otros diagramas de apoyo, se consiguió obtener una estructura del proceso y los datos suficientemente nítida para poder representarlo de una manera formal posteriormente.

3


Se utilizaron las reglas para la posterior representación del conocimiento, ya que sus características permiten una correcta formalización y gran facilidad a la hora de implantarlas y codificarlas en el sistema desarrollado. En total se han empleado más de 115 reglas, muchas de ellas con encadenamiento. El motor de inferencias funciona con un procedimiento de marcha hacia delante (Forward Chaining). El sistema compara la base de hechos aportados por el usuario –a lo largo de su navegación por los interfaces gráficos-, con la base de conocimiento resultado de la representación del conocimiento adquirido de los expertos. Tras la comparación, cuando llega a conclusiones parciales incluye dichos datos como hechos probados, aumentando de esta forma la base de hechos anteriormente mencionada. Al llegar a resultados finales, el sistema ha concluido la inferencia, pasando a mostrar los resultados de las patologías diagnosticadas, sus características, y sus posibles tratamientos en el caso de que los hubiere. Tanto la base de conocimientos como la base de hechos se encuentran de forma independiente entre sí y con el resto del programa. De esta forma se amplia la modularidad y escalabilidad del sistema. La aplicación se pone en contacto con la base de hechos a medida que avanza el proceso de aportación de información por parte del usuario. Posteriormente llamará al motor de inferencias, que contrastará dichos hechos con la base de conocimiento, por lo que tendrá que ponerse en contacto con ella para realizar el citado proceso. Debido a la gran cantidad de conocimiento heurístico recogido de los expertos, ha sido posible realizar lo que he denominado “Inferencias anticipadas”. En estos casos el usuario no debe completar el proceso de aportación de información al sistema, sino que en un punto intermedio de dicho proceso, con la información obtenida en ese punto, y contrastando con el conocimiento basado en la experiencia del experto, el sistema es capaz de inferir una posible patología que sufre el edificio analizado. Este es uno de los puntos donde la aplicación desarrollada pone de manifiesto toda su “parte inteligente”. La aplicación se desarrolló en Visual Basic 6.0, lo que ha facilitado una creación de interfaces gráficos muy sencilla y amigable. Este punto adquiere una gran importancia pues los usuarios potenciales del sistema en cuestión, no tienen por qué estar familiarizados con aplicaciones informáticas, y menos con sistemas expertos basados en conocimiento. De ahí la importancia de aislar lo más posible la verdadera naturaleza del sistema, intentando que se asimile en la mayor medida posible, a una herramienta general, fácilmente usable, que no plantee dudas, y con un gran apoyo gráfico. Para cubrir tales objetivos se han utilizado un total de 58 formularios de Visual Basic, además de dos módulos - .bas-, para implementar la base de conocimientos y la base de hechos.

4


La validación realizada una vez desarrollado el sistema, ha permitido comprobar la bondad de las inferencias realizadas por el sistema, siendo los resultados de estas pruebas más que satisfactorios. Al mismo tiempo se depuraron errores que no afectaban a la funcionalidad de la aplicación, tales como redundancias, etc... Entre las pruebas de validación más importantes cabe destacar las llevadas a cabo por los expertos colaboradores del sistema. Dichos expertos primeramente pusieron a prueba el programa con casos aleatorios que le planteaban al sistema a medida que iban navegando por sus interfaces. Posteriormente, realizaron ensayos con baterías de casos preparados de antemano, ante los cuales el sistema debería responder satisfactoriamente por su importancia y relevancia en el dominio del problema en el que nos estamos moviendo. Como conclusión se puede decir que el sistema desarrollado ha cubierto los principales objetivos planteados, y bastantes de los objetivos secundarios. La aplicación funciona correctamente, y además sus inferencias son correctas como se ha demostrado en el apartado de validación.

5


Capítulo 1.- Introducción La herramienta pretende cubrir la necesidad de detectar y diagnosticar patologías en edificios mediante la aplicación de los sistemas expertos basados en el conocimiento. La aplicación recogerá los datos desde distintas interfaces para poder inferir posteriormente, en base al conocimiento adquirido y formalizado, y a dichos datos aportados por el usuario, las conclusiones oportunas acerca de las posibles patologías que sufre un edificio. Para poder elaborar dicha aplicación lo primero que hay que realizar es la adquisición del conocimiento. Debido a que el conocimiento más importante para este tipo de casos es el basado en la experiencia, es el seguimiento y la entrevista al experto la mejor técnica de adquisición. Posteriormente, y previa a la fase de formalización del conocimiento en reglas, se necesita un paso de conceptualización para el correcto entendimiento del proceso de inferencia que llevará a cabo el sistema. Como ya se indicó anteriormente, el paso final para completar esta parte del programa consiste en formalizar el conocimiento adquirido y conceptualizado en forma de reglas, que es el sistema formal seleccionado para nuestro sistema. Con el conocimiento adquirido ya poseemos la base de conocimientos. Otra parte fundamental es la base de hechos, constituida en este caso por la información aportada por el usuario en lo que respecta al edificio analizado. Esto se conseguirá mediante la navegación por una serie de interfaces gráficos en los que el usuario aportará información que será recogida por el sistema. La base de hechos se verá incrementada en ocasiones con consecuentes que se deduzcan de la base de conocimientos. Por último tan solo falta un motor de inferencias que contraste la base de hechos con la base de conocimientos, para de esta forma llegar a conclusiones concretas. El encargado de realizar esta tarea de razonamiento se denomina “Motor de inferencias”. El paso final es una correcta validación y evaluación del sistema, probando que todo funcione correctamente y que además lo haga cumpliendo los requisitos de forma correcta. Para ello, a parte de las pruebas funcionales y de caja blanca que se desarrollarán principalmente en paralelo al desarrollo del programa, se usarán casos ejemplos suministrados por los expertos, así como casos reales, para poder comprobar la verdadera calidad de las inferencias realizadas por el sistema. La aplicación se desarrollará íntegramente en Visual Basic 6.0, con el apoyo de herramientas de tratamiento de imágenes para el desarrollo de los interfaces gráficos y de las fotos ejemplo que contendrá el programa.

6


Capítulo 1.1.- Descripción El sistema de detección y diagnóstico de patologías en edificios consiste en una aplicación, que apoyándose en los sistemas expertos, cubrirá una importante carencia en el mundo de la construcción. El usuario tan sólo tendrá que navegar por el amigable e intuitivo interfaz gráfico, aportando la información que el sistema le solicite en cada momento. De esta forma, tras obtener dinámicamente los datos necesarios para una correcta inferencia, el sistema aplicará el conocimiento aportado por expertos en la materia para poder llegar a conclusiones acerca de lo que puede ocurrirle al edificio que el usuario está analizando. El sistema estará al alcance de usuarios que no sean técnicos profesionales de la construcción, pero requiere de cierto vocabulario y conocimientos relativos al tema, especialmente en las últimas fases de la recogida de datos, así como para la interpretación de lo que se ha denominado “inferencias anticipadas” que se describirán más adelante. Se ayudará y apoyará al usuario a su toma de decisiones que desencadenarán una serie de datos de entrada mediante fotos y ejemplos, de esta forma el usuario podrá contrastar la veracidad de lo que él mismo está introduciendo, y así garantizar en mayor medida la calidad de las posibles patologías propuestas por el sistema. Adquisición del conocimiento El sistema de detección y diagnóstico de patologías en la construcción es un sistema basado en el conocimiento específico, que será aportado por diversos expertos, entre los que se encontrará el codirector Armando Fuentes Ganzo y Román Ávila García, así como con el fondo bibliográfico existente en el C.O.A.L.Z.A. (Colegio Oficial de Arquitectos de León, delegación de Zamora). Las técnicas empleadas para la adquisición del conocimiento serán tanto la entrevista como el seguimiento. Las entrevistas serán no estructuradas al principio y semi-estructuradas según se vaya avanzando. También se emplearán métodos como el de análisis de casos tipo (centrándonos en casos vividos por el experto), para recoger la mayor heurística posible, el método del “Role” inverso, y el método de la división del dominio. Se ha realizado, contando con la colaboración de los expertos, una doble clasificación de la casuística a implantar en el sistema, una atendiendo a la clasificación formal de las patologías, es decir, a su causa u origen, y otra atendiendo a los principales problemas que se suelen derivar de la existencia de la propia patología.

7


Representación del conocimiento El sistema está basado en reglas. Esta decisión fue tomada junto con los expertos, tras analizar los requisitos de la aplicación y su futura implantación. Se consideró que las reglas eran el mecanismo formal de representación del conocimiento más adecuado para este caso, descartando los marcos, que en un primer momento, también fueron considerados como una posible opción. La aplicación creada se corresponde con un sistema de producción, constando de una base de conocimientos, compuesta del conocimiento extraído representado en forma de reglas de producción. Una base de hechos, formada inicialmente por los síntomas introducidos por el usuario, y más adelante puede que por conclusiones parciales a las que se llega a partir de los primeros síntomas. Y por último el motor de inferencia, que será el encargado de realizar el ciclo de reconocimiento y actuación, contrastando la base de conocimientos con la base de hechos para intentar llegar a reconocer una patología concreta. Incertidumbre El método de representación de la incertidumbre consistirá en factores de certeza asociados a reglas de producción. Desarrollo El desarrollo se efectuará en el lenguaje de programación “Visual Basic”. Tanto el conocimiento como el motor de inferencias, estarán aislados entre sí y del resto de la aplicación de una forma lógica. Mediante listas desplegables el usuario introducirá los síntomas visibles, que el motor de inferencia, basándose en reglas, cotejará con el conocimiento almacenado para intentar encontrar la causa del problema, y poder mostrárselo al usuario.

8


Capítulo 1.2.- Motivación del proyecto. En numerosas ocasiones he sido testigo de los conflictos provocados entre las diferentes partes afectadas por patologías en la construcción. No es difícil percatarse del precario estado que este campo sufre en cuanto a su integración con las nuevas tecnologías, que indudablemente, podrían serle de gran apoyo. La detección y diagnóstico de forma eficaz de patologías constructivas requiere de una gran experiencia específica por parte del técnico encargado, pues en muchas de las ocasiones únicamente el conocimiento adquirido anteriormente, tras muchas horas de trabajo, es capaz de guiar al técnico hacia el verdadero origen de los problemas. Esto viene provocado tanto por la opacidad como por la escasez de síntomas que se manifiestan en el edificio, lo que provoca que daños con la misma apariencia puedan tener origen en causas completamente diferentes, pudiendo tener también soluciones que difieran entre sí de forma sustancial. Es común que la elección del técnico interviniente no se realice tanto en base a sus avanzados conocimientos sobre patologías constructivas, como en otros motivos ajenos a la especialidad en este campo, como por ejemplo: la existencia de relaciones extra-profesionales con dicho técnico, que se trate del técnico proyectista de la obra que sufre la patología, amistad, etc. En estos casos podría ser de gran ayuda un sistema informático que recoja toda la experiencia de otros expertos en la materia. Debo aclarar, que cuando la patología deriva en una demanda judicial, suelen coexistir varios peritos encargados de analizar y justificar la causa de la patología, para que el juez, tras estudiar sus informes, delimite las responsabilidades a que hubiere lugar y obrar en consecuencia. Cada parte afectada, demandantes y demandados, designan a su perito denominado “de parte”, ya que es contratado directamente por cada una de ellas. Existe además un perito judicial, cuyos servicios han sido contratados por el propio juzgado. Recientemente ha sido aprobada una ley que exige a los promotores de edificios que una oficina externa controle la ejecución de la obra, independientemente de los técnicos a los que se les haya encargado el proyecto y la dirección de dicha obra. La relación de este tipo de oficinas, conocidas como OCT (Oficinas de Control Técnico), con los autores y directores de las obras, suponen otro fundamento para la creación del sistema de detección y diagnóstico de patologías, pues son constantes los conflictos entre los diversos técnicos directores, responsables de la calidad y durabilidad de la construcción. No obstante, el apoyo recibido por parte de los expertos, y su ánimo transmitido para que desarrolle el sistema en cuestión, me han sido de gran ayuda a la hora de decidirme. A continuación remito un texto con las consideraciones transmitidas por uno de los principales colaboradores del proyecto, Román Ávila:

9


“Cada día resulta más penosa la actividad profesional de los técnicos en construcción, al menos si se observa desde un punto de vista puramente subjetivo. Tras más de treinta años de ejercicio profesional en el ámbito de la construcción de edificios, he podido apreciar en este mundo tan complejo innumerables situaciones de daños, derrumbes, defectos y en general lo que denominamos patologías. Resulta habitual observar actuaciones como perito a instancia de parte o por designación judicial, y apreciar a continuación la caída en la peor de las situaciones que pueden producirse tras un siniestro en la construcción: la derivada de un análisis erróneo, de un diagnóstico equivocado, del establecimiento de una causalidad incierta y de la proposición de conclusiones y soluciones inadecuadas cuando no contraproducentes. Es una frase conocida del profesor José-Luis de Miguel: - Lo peor que le puede ocurrir a un edificio dañado es que le hagan un mal informe de daños -. Dada mi tendencia natural, dentro del ejercicio profesional en la construcción, a observar las patologías que la afectan de forma casi habitual, nada me agradaría más que el colaborar con este intento de ordenar, clasificar, describir y diagnosticar la parte más conocida y admitida de esta especialidad. Resulta lamentable constatar en los juzgados cuando se tramitan procedimientos relacionados con estos temas, se observan informes conteniendo auténticos disparates legitimados por la firma de técnicos de diversa titulación relacionada, que hacen tambalear la lógica de los observadores y agentes judiciales, alcanzando a veces sentencias absolutamente inverosímiles. Como ejemplo: condenas a impermeabilizar la cara exterior de paramentos que sufren condensaciones por su cara interior. Si con un sistema como el que se propone conseguimos iniciar un proceso que culmine con el desarrollo de un sistema inteligente que ayude a resolver estas cuestiones nos daríamos por satisfechos.”

10


Capítulo 1.3.- Objetivos + Cubrir necesidades del mundo de la construcción

- Servir de ayuda a los peritos encargados de mediar en los habituales conflictos entre propietarios, empresas constructoras, compañías aseguradoras y técnicos que han proyectado y dirigido la edificación, ya que el sistema será capaz de reconocer el origen de la patología, contribuyendo a deslindar las responsabilidades que puedan corresponder a la intervención de cada agente en el proceso de construcción, o bien a los usuarios y propietarios por un uso incorrecto ó falta de mantenimiento del edificio.

- Apoyar en la elaboración de informes técnicos que se deriven de la inspección técnica de edificios, cuya exigencia e implantación, de forma cada vez más habitual, se viene adoptando por comunidades autónomas y ayuntamientos.

- Ayudar en la búsqueda de posibles alternativas y obras de reparación de las patologías detectadas, valorando la viabilidad de cada una de ellas.

+ Integración de la tecnología en otros campos ajenos a la informática

- Relacionar el mundo de la construcción con el de los sistemas inteligentes, para que de esta forma, las nuevas tecnologías presten todas sus ventajas a un campo tan tradicional y habitual como el de la construcción.

+ Contribuir al avance de la tecnología propia de otros dominios

- La elaboración de un sistema que pueda dar lugar a otros de la misma índole, para poder cubrir necesidades desamparadas actualmente de una forma eficaz, dada la escasa interacción existente entre estos dos campos a día de hoy.

+ Conocer otros sectores profesionales por parte del ingeniero informático

- Interactuar y analizar la forma de obrar y de pensar de otros profesionales de distinto ámbito que el de la informática, en este caso arquitectos, aparejadores, constructores, ingenieros, etc.

11


Capítulo 2.- Descripción de técnicas de Ingeniería del Conocimiento a usar En este capítulo se va a describir desde un punto de vista teórico las diferentes técnicas empleadas en la elaboración de sistemas basados en conocimiento. Cada una de las técnicas se puede agrupar en diferentes fases, pudiendo distinguir entre:

- Adquisición del conocimiento - Conceptualización del conocimiento - Representación del conocimiento - Razonamiento -

Capítulo 2.1.- Adquisición del conocimiento Se entiende como adquisición del conocimiento a la extracción o recogida del conocimiento desde una fuente experta del mismo, tales como libros, expertos, documentos especializados, etc... La lleva a cabo el Ingeniero del Conocimiento, con el fin de obtener la información con la que va a tratar un programa. Se trata de un proceso laborioso, de intensa interacción cuyo objetivo es lograr extraer el conocimiento heurístico o basado en la experiencia de allí donde se encuentre. Conocimiento perteneciente a la resolución de problemas del dominio que se quiere tratar. Este proceso largo y tedioso requiere de una habilidad especial para poder extraer el conocimiento realmente interesante del experto, que muchas veces no se centra en el principal problema que estamos tratando, aportando información irrelevante y alargando el proceso de adquisición de forma innecesaria. Debido a estas dificultades, se considera a esta fase de adquisición como uno de los principales cuellos de botella del proceso de elaboración de un Sistema Experto. El ingeniero del conocimiento desempeña un papel diferente al del experto, por lo que no suelen coincidir ambos papeles en una mima persona. Es recomendable que el ingeniero del conocimiento (de ahora en adelante IC) encargado de la adquisición tenga conocimientos previos del dominio en el que se enmarca el problema, para evitar las primeras fases, cuya única utilidad es ubicar al IC en el dominio del problema a tratar, iniciándolo en el argot, así como en otras cuestiones de “puesta a punto”, para que posteriormente pueda realizar la verdadera adquisición del conocimiento. No se debe olvidar que los expertos colaboradores con el proyecto son un agente externo al mismo, por lo que se tiene que tener en consideración su disponibilidad, paciencia, confidencialidad respecto a algunos asuntos, etc...

12


Etapas de la Adquisición del Conocimiento

- Identificación del dominio del conocimiento y definición del problema - Identificar los conceptos y relaciones del dominio del conocimiento - Formalización del conocimiento - Chequeo - Refinado y validación

Identificación del dominio del conocimiento y definición del problema Van íntimamente relacionados, pues al abordar uno de ellos se avanza en el otro. Al identificar el dominio se ve más claramente el problema que queremos resolver, y análogamente, al considerar el problema a resolver, se identifica con más nitidez el dominio que lo engloba. Posibles fuentes de conocimiento:

- Experto con gran experiencia en el sector - Libros, manuales, documentos específicos, etc... - Internet - Casos de ejemplo ya resueltos - Datos experimentales o de proceso

Identificar los conceptos y relaciones del dominio del conocimiento El IC debe ser capaz de de filtrar el conocimiento que el experto le pueda transmitir, eliminando anécdotas o casos particulares sin importancia. Su labor principal es encontrar y organizar los conceptos relevantes que el experto le pueda comunicar. Al final del proceso el conocimiento debe estar organizado, bien recogido, ser coherente, no dar lugar a dudas o ambigüedades, y no estar repetido implícita o explícitamente. Pueden surgir los siguientes problemas al tratar con el experto:

- Incapacidad de separar lo anecdótico de lo conceptual - Incapacidad de obtener conocimiento completo - Incapacidad de expresar claramente los conceptos

13


Formalización del conocimiento Lo resultante de esta etapa será el punto de partida para la fase posterior de representación, de ahí su importancia. Esta fase está relacionada de una manera considerable con la de representación, ya que la naturaleza de los conceptos y su estructura, condiciona de forma notable la elección del método de representación, pues éste deberá de ser lo más adecuado posible a las características del dominio y de los conceptos tratados. Si por el contrario el método de representación estuviese establecido con anterioridad, se deberá adecuar el conocimiento adquirido para posteriormente poder representarlo con el método establecido. A partir de los conceptos claramente identificados se tratará de relacionarlos entre ellos. Chequeo Comprobación intensiva de la calidad y bondad del conocimiento adquirido. Típicamente se realiza pasando baterías de ejemplos cuyo resultado conocemos, de esta forma se pueden detectar errores en el conocimiento antes de usarlo. Posibles errores:

- Poca representatividad - Conocimiento incompleto - Experto inadecuado - Falta de heurísticas importantes

Refinado y validación Trata de determinar el grado de madurez del sistema, comprobando si con el conocimiento adquirido el sistema sería capaz de inferir de forma análoga al experto.

14


Modelos de conocimiento El modelo de conocimiento a adquirir debe ser completo, coincidiendo con el modelo del dominio del experto. En muchas ocasiones esto no será posible, por eso es preferible completar un modelo de conocimiento parcial, antes que recoger todo el conocimiento posible del dominio completo, y dejarlo de esta forma incompleto, con lagunas y posibles ambigüedades. Tipos de modelos de conocimiento:

- Profundo - Heurístico: basado en la experiencia - Conocimiento del conocimiento - Mixto: combinación de los anteriores

Modos de adquisición de conocimiento Manual Basado en el diálogo entre el experto y el IC Semi Automático Requieren cierta interacción con el experto. Posteriormente se aplican procesos automáticos de adquisición Automático No requieren interacción con el experto o esta va a ser muy escasa.

15


Técnicas de adquisición del conocimiento Se pueden agrupar en familias:

- Entrevistas - Seguimiento - Técnicas conceptuales

Entrevistas Es el método más comúnmente utilizado. No es necesario tan sólo su realización, sino que deben registrarse, dejando constancia documental de su contenido. El IC debe preparar concienzudamente las entrevistas, planteando que objetivos quiere cubrir en esa entrevista y como cubrirlos. Se debe tratar de involucrar al experto entrevistado en el problema que estamos tratando, haciéndole sentir partícipe del proyecto, porque realmente lo es. La conducción de las entrevistas también debe ser estudiada, comenzando con temas generales y profundizando a medida que se avanza. Posteriormente se debe contrastar la información recogida en la entrevista, de ahí que sea recomendable contar con más de un experto, o bien poseer una buena fuente de conocimiento. Características del IC para la realización de entrevistas:

- Comprender el lenguaje que usa el experto y emplearlo en las entrevistas

- Identificación de la importancia de lo transmitido por el experto - Integrar gradualmente el conocimiento en el ya existente.

Tipos de entrevista: No Estructurada Se realizan de manera abierta y sin predeterminar los temas ni la secuencia en que estos se van a tratar. Son recomendables para las primeras sesiones a modo de toma de contacto con el dominio del problema. Son importantes para ir conociendo el lenguaje empleado por el experto, para una correcta interpretación en el futuro, y para facilitar la comunicación entre ambos. Estructurada En este tipo de entrevista existe un formato predeterminado de cómo se va a desarrollar la misma. El grado de estructuración puede ser variable.

16


Las entrevistas estructuradas facilitan la recogida de la información, al emplear un método más sistemático para ello, además de establecer un mayor control sobre la cobertura del dominio del conocimiento. La contrapartida es que exige más del IC, ya que requiere más tiempo de preparación además de algún conocimiento previo. Variantes de entrevista estructurada

- Discusión focalizada - Análisis de casos tipo - Simulación de escenarios hacia delante - Método de los incidentes o decisiones críticas - Método de los objetivos - Método de la división del dominio - Método del Role inverso - Método del Teachback - Método de las veinte preguntas - Método del escenario incompleto

Entrevista en grupo Consiste en adquirir conocimiento mediante una entrevista en la que se encuentran presentes varios expertos al mismo tiempo. Puede haber diferencias de opinión entre los expertos, provocando pérdidas de tiempo considerables en discusiones sin sentido que no aportan nada al proceso de adquisición de conocimiento, aunque también es cierto que entre ellos pueden llegar a estimularse y discutir de conceptos que de otra forma nunca saldrían a la luz. Variantes:

- Brainstorming - Toma de decisiones por consenso - Método Delphi - Técnica del grupo nominal

17


Capítulo 2.2.- Conceptualización del conocimiento Una vez finalizada la etapa de adquisición del conocimiento, es necesario un paso previo antes de la representación del mismo. Esta fase es la denominada conceptualización. En esta fase el objetivo es establecer cuales de los conceptos adquiridos son utilizados en cada caso, como son utilizados y cuando, para de estar forma poder obtener una descripción profunda del problema, lo suficientemente detallada para poder afrontarlo con garantías de que el conocimiento tratado realmente se corresponde con la realidad que debería. En este punto conviene distinguir entre modelos conceptuales y modelos formales. Los primeros indican que es lo que debe realizar el sistema, los segundos como construirlo y como ha de trabajar. Como ya se ha dicho, en esta fase se parte del conocimiento anteriormente adquirido. Este conocimiento se puede clasificar dependiendo de su función en:

- Estratégico o de control - Táctico - Factual o declarativo

Se podría resumir que la conceptualización es la descripción de los conceptos de un determinado ámbito y sus relaciones. Se pueden definir estas relaciones como un tipo de interacción entre conceptos en un universo de discurso. Estas relaciones también se pueden agrupar según sus características, agrupándose en:

- Taxonómicas - Causales - Estructurantes - Topológicas - Funcionales - De similitud - Cronológicas - Condicionales - De finalidad

18


Modelo conceptual Para poder realizar el modelo conceptual es necesario que plasmemos la realidad de alguna forma tangible e interpretable. Por eso su suelen utilizar todo tipo de diagramas, anotaciones, fórmulas, y demás herramientas que nos ayuden a expresar la función de los conocimientos. A estos instrumentos se les denomina Representaciones Externas Intermedias. Nos aportan bastante detalle y una buena descripción del problema, aunque no son formas directas de representar conocimiento. Existen muchos tipos de diagramas e instrumentos de este tipo, aunque dado su función, no es necesario ceñirse a los ya existentes, sino que el IC puede desarrollar sus propios instrumentos de conceptualización siempre y cuando sea positivo para el desarrollo de su proyecto y le ayude en el principal objetivo de esta fase: comprender mucho mejor los conceptos del dominio del problema, y las relaciones existentes entre ellos. Entre los diagramas más conocidos y utilizados se encuentran: Organigrama Ilustra el orden en el cual el SE debería ejecutar los pasos en su tarea y las condiciones bajo las cuales debería ejecutar esos pasos.

Figura 1: Ejemplo general de organigrama

19


Árbol de descomposición Ilustra cómo puede descomponerse la tarea del SE en pasos y sub-pasos modulares, y las metas y sub-metas.

Figura 2: Ejemplo árbol de descomposición Árbol de decisión Ilustra un proceso de toma de decisión complejo, cómo el SE debería conseguir una evidencia a partir de un caso.

Figura 3: Ejemplo de árbol de decisión

20


Definición de paso procedimental Describir en detalle la(s) entrada(s), razonamiento(s) y acción(es) de salida individuales que el SE deberá poner en un paso. Explicar por qué es necesario el paso, listar los prerrequisitos para ejecutar el paso. Árbol Describe jerarquías de tipo de conceptos usados para clasificar los atributos importantes para la tarea del SE. Define relaciones jerárquicas entre conceptos, en particular relaciones taxonómicas y de descomposición estructural de partes en subpartes.

Figura 4: Ejemplo general de árbol jerárquico

21


Grafo Ilustra cualquier relación entre conceptos, especialmente: topológica, causal, funcional, cronológica...

Figura 5: Ejemplo de grafo

Ontologías Según Gruber una ontología es una especificación explícita y formal sobre una conceptualización compartida. Es una forma muy utilizada de manejar los conceptos de un sistema. La interpretación de esta definición es que las ontologías definen conceptos y relaciones de algún dominio, de forma compartida y consensuada, y que esta conceptualización debe ser representada de una manera formal, legible y utilizable por los ordenadores. Una Ontología, por tanto, está especificando una forma de actuar, una forma de entender las cosas, en definitiva, una forma de entendimiento. Se trata de convertir información en conocimiento empleando metadatos con un esquema común consensuado sobre algún dominio, es decir, permite representar conocimiento de una forma legible por los ordenadores, consensuada y reciclable. Esto obliga a que tenga que existir un estándar para definir los metadatos que permitan interoperatividad. Los metadatos no sólo permiten especificar la estructura de los contenidos (datos) que debe aparecer en cada instancia, es decir, permiten describir las partes de un recurso, sino que además podrán tener información adicional de cómo hacer deducciones con ellos, es decir, axiomas que podrán aplicarse en el dominio.

22


Los datos sin una estructura y semántica asociada no tienen ningún interés, es necesario tener algún mecanismo que permita identificar los datos almacenados para poder recuperarlos de forma eficiente. Ventajas de las ontologías:

- Proporciona una forma de representar y compartir el conocimiento utilizando un vocabulario común.

- Permiten usar un formato de intercambio de entendimiento. - Proporciona un protocolo específico de comunicación. - Permite una reutilización de conocimiento

Ejemplo de ontología:

Figura 6: Ejemplo de ontología

23


Pasos para una correcta conceptualización A continuación se describen cuales son los pasos a dar para conseguir que la fase de conceptualización sea un éxito: Creación del diccionario de conceptos Se suele presentar como tablas objeto-atributo-valor. Realmente es el paso en el que menos detalle se consigue Definición del modelo dinámico de proceso y control Se llega a un acuerdo con el experto acerca de cual va a ser la jerarquía entre las tareas a realizar por el sistema. Creación del mapa de conocimiento Debe reflejar el proceso de razonamiento del experto, para que de esta forma, el sistema actúe de la forma más parecida posible. Realmente no hay un acuerdo acerca de cómo debe representarse el mapa de conocimiento, teniendo cada ingeniero del conocimiento sus propias ideas y conclusiones, que a cada uno le parecen más acertadas. Así y todo, la inmensa mayoría utiliza esquemas similares a los diagramas de flujo. A la hora de construir el mapa de conocimiento es importante tener en cuenta las siguientes cuestiones:

- Identificar claramente las decisiones realizadas por el Sistema Experto - Evitar duplicar inferencias - Examinar condiciones desconocidas y por defecto - Confrontar la imprecisión y la incertidumbre

24


Capítulo 2.3.- Representación del conocimiento Su objetivo es realizar una correspondencia entre el dominio del la aplicación que queremos desarrollar y un sistema de símbolos con el que tratará nuestro sistema. Por lo tanto hay dos puntos clave que hay que tratar para poder afrontar esta fase:

- Qué conocimientos hay que codificar - Como se puede codificar dicho conocimientos para usarlo

posteriormente Hay que tener en cuenta determinados factores para realizar una correcta representación del conocimiento, tales como que la representación sea adecuada para poder inferir más adelante, y que sea adecuada también al conocimiento adquirido, representando todos los tipos de conocimiento de nuestra aplicación. El conocimiento que debemos representar se suele corresponder con:

- Secuencias de suceso - Secuencias cronológicas - Categorías jerárquicas de clases de conceptos - Incertidumbre

De aquí surge la necesidad de emplear esquemas de representación de conocimiento. A lo largo del tiempo se han propuesto muchos esquemas de representación del conocimiento, aunque se pueden agrupar en cuatro categorías:

- Esquemas de representación lógica - Esquemas de representación procedural - Esquemas de representación en forma de red o malla - Esquemas de representación estructurada

25


Esquemas de representación Esquemas de representación lógica Es comúnmente aceptada por la comunidad científica, además de ser el esquema de representación más antiguo conocido. Sus puntos fuertes son:

- Clara - Transparente - No ambigua - Simple para representar hechos y sus relaciones

El cálculo de primer orden es el esquema de representación más ampliamente utilizado, aunque se pueden implementar más al margen de éste. Existen lenguajes que se adaptan de forma muy satisfactoria a este tipo de esquema, como puede ser el PROLOG. Esquemas de representación procedural Para representar el conocimiento se basan en un conjunto de instrucciones con las que se pueden resolver los problemas del dominio en cuestión. Es el tipo de representación más extendido, siendo los sistemas de producción un típico ejemplo de estos esquemas de representación procedural. Esquemas de representación en red o malla Utilizan formas de grafo para poder representar el conocimiento. Los objetos o conceptos del dominio del problema a tratar se representan mediante nodos, mientras que las relaciones existentes entre dichos objetos o conceptos se representan con arcos que unen los nodos.

26


Dentro de este tipo de esquemas de representación podemos encontrar:

- Redes semánticas. Ejemplos:

Figura 7: Ejemplo de red semántica

Relaciones en Redes Semánticas. Ejemplo:

Figura 8: Ejemplo de relaciones en redes semánticas

27


Redes de Petri. Ejemplo:

Figura 9: Ejemplo de red de Petri

- Grafos conceptuales. Ejemplo:

Figura 10: Ejemplo de grafo conceptual

28


Esquemas de representación estructurada Son una ampliación del esquema de representación de redes semánticas. Ahora cada nodo puede ser una estructura de datos compleja, que contienen una serie de atributos con sus correspondientes valores. Estos valores pueden ser de varios tipos, permitiéndose entre otros:

- Números - Símbolos - Punteros - Procedimientos

Los esquemas de representación típicos de este tipo son los marcos o frames y los scripts. Ejemplo de Marco o Frame:

Figura 11: Ejemplo de Marcos o Frames

29


Ejemplo de Marco o Frame:

Figura 12: Ejemplo II de Marcos o Frames

30


Esquemas de representación basados en reglas de producción Cada regla consta de dos partes:

- Condiciones o hipótesis - Acciones o conclusiones

Se componen de la siguiente forma: SI cond1 Y cond2 [...] Y condn ENTONCES conclus1 conclus2 [...] conclusn

Figura 13: Forma de componer las reglas Ejemplo: Si ha fallado la bombilla

y hay una de repuesto y está útil

Entonces cambiar la bombilla por la de repuesto y seguir trabajando

Sistemas de producción La utilización de los sistemas de producción en sistemas experto se remonta a los trabajos de Newell y Simon de la Universidad norteamericana Carnegie Mellon entre 1960 y 1970. Se percataron que los sistemas de producción podían utilizarse para modelar el conocimiento humano y hacer un posterior uso del mismo en el proceso de inferencia. En ellos tienen su origen las reglas de producción usadas en ingeniería del conocimiento. Los sistemas de producción son modelos de cálculo cuya eficiencia ha sido probada notoriamente en ingeniería del conocimiento, tanto en desarrollo de algoritmos de búsqueda como en el modelado de soluciones a problemas humanos.

31


Los sistemas de producción están compuestos por 3 elementos:

- Conjunto de reglas de producción - Memoria de trabajo o temporal - Ciclo de reconocimiento y actuación

Conjunto de reglas de producción Una producción es un par condición-acción que define una parcela o segmento del dominio de conocimiento. La producción o regla consta de dos partes:

- La parte de la acción define el paso asociado a la condición que resuelve el problema.

- La parte de condición (hipótesis) de la regla es un modelo que determina cuándo esta regla se puede aplicar.

Expresión: Si condición 1, ..., condición n

Entonces conclusión 1, ..., conclusión m

Memoria de trabajo Contiene una descripción del estado actual del mundo o entorno de la aplicación en cada paso del proceso de Razonamiento. Esta descripción es un modelo que servirá para asociar las partes condición de las reglas con las observaciones del mundo con objeto de seleccionar o producir las apropiadas acciones. En el momento en que se cumplen todas las condiciones de una regla se produce el “disparo” de la misma ejecutándose la acción. Esta operación alterará el contenido de la memoria de trabajo Ciclo de reconocimiento y actuación Es el procedimiento de control de un sistema de producción. Es un procedimiento de marcha hacia adelante. La memoria de trabajo se inicializa con la descripción del problema. El estado del proceso de resolución del problema se mantiene a través de un conjunto de modelos en la memoria de trabajo.

32


El control sigue los siguientes pasos:

- Los modelos guardados en la memoria de trabajo se tratan de superponer en las condiciones de las producciones.

- Se crea un conjunto “conflicto”. Este es un subconjunto de producciones cuyas condiciones se cumplen. Estas producciones se dice que son “permitidas”.

- Se escoge una producción y se “dispara” o se activa. Ejemplo: Clasificar una cadena de caracteres compuesta por las letras {a, b, c} en orden alfabético dado el siguiente conjunto de reglas: Si ba entonces ab Si ca entonces ac Si cb entonces bc Cadena: cbaca

Figura 14: Tabla que ordena la cadena “cbaca” en orden alfabético

33


Esquemas de representación basados en redes semánticas Los filósofos y los matemáticos pusieron especial interés en crear representaciones lógicas capaces de modelar los principios del razonamiento humano. Como consecuencia se desarrolló una representación formal del lenguaje y unas reglas completas de inferencia. Sin embargo los psicólogos y lingüistas propusieron una alternativa en la caracterización del razonamiento humano. No les preocupaba tanto establecer una forma científica del correcto razonamiento, pero si describir la forma por la que los humanos adquieren y usan el conocimiento. En 1969 se crearon los trabajos que fueron el soporte que permitió el desarrollo de las redes semánticas, dichos trabajos fueron desarrollados por Collins y Quillian, que estudiaron como las personas almacenaban y usaban la información. El experimento de Collins y Quillian constaba de tres preguntas a diferentes personas para medir el tiempo de respuesta. La idea que justificaba el experimento era una teoría asociacionista, que promulga que el significado de un objeto se tiene en términos de una red de asociaciones con otros objetos. Las redes semánticas permiten representar gráficamente el conocimiento utilizando nodos y arcos_

- Nodos: Representan los conceptos y se etiquetan con su nombre - Arcos: Representan las interrelaciones entre los conceptos

Ejemplo:

Figura 15: Relación entre complejidad y tiempos de respuesta

34


Explicación:

Figura 16: Justificación de la Figura 15 (anterior)

35


Casos ejemplo y conceptos Un concepto es la representación de un conjunto de ejemplos o individuos. Un caso ejemplo representa sin embargo una entidad o individuo particular del dominio. Se podría decir que un concepto se asimila a una clase en términos de orientación a objetos, mientras que un caso ejemplo es una instancia u objeto.

Figura 17: Ejemplo de conceptos y “casos ejemplo”

Un ejemplo positivo es un individuo que pertenece a un conjunto de ejemplos representados por un concepto. Un ejemplo negativo es un individuo que no pertenece a un conjunto de ejemplos representados por un concepto “Moto Honda CBR 600” es un ejemplo negativo del concepto “Coche”. Generalización Un concepto P es más general (o es una generalización) que otro concepto Q, sí y sólo sí el conjunto de ejemplos representados por P incluye el conjunto de ejemplos representados por Q. Ejemplo: “F1” representa todos los coches de fórmula 1 “Coche” representa todos los automóviles de 4 ruedas Relación de generalización: F1 es_un coche

36


La generalización permite jerarquizar conceptos:

Figura 18: Ejemplo de jerarquía de conceptos

37


Esquemas de representación basados en Frames o Marcos Son una ampliación del esquema de representación de redes semánticas. Ahora cada nodo puede ser una estructura de datos compleja, que contienen una serie de atributos con sus correspondientes valores. Estos valores pueden ser de varios tipos, permitiéndose entre otros:

- Números - Símbolos - Punteros - Procedimientos

Fueron creados por Minsky en el año 1975. Minsky definió a estas estructuras estáticas de la siguiente manera: “Cuando uno se encuentra ante una nueva situación, selecciona de su memoria una estructura de información que se puede denominar frame”. La representación que ofrecen los frames es parecida a la ofrecida por las redes semánticas, pero los frames ofrecen un vehículo más estructurado y compacto, haciendo que sea ideal para su utilización en programación orientada a objetos. Antes comparamos los diferentes componentes de la POO con los de las redes semánticas, ahora la analogía es similar, pero con mayor similitud, al poseer cada concepto y ejemplo una serie de atributos, al igual que las clases y objetos respectivamente. Estos atributos con sus respectivos valores se ubican en los “Slots” (campos) del frame. Ejemplo:

Figura 19: Ejemplo de Marcos o Frames

De esta forma, un frame es un bloque de conocimiento sobre un objeto o individuo, que describe al mismo con un nivel de detalle que variará según el problema a resolver y sus necesidades. Los frames suelen estar relacionados entre sí, y ordenados de forma jerárquica.

38


Por lo tanto podemos concluir que un frame posee la siguiente información:

- Identificación del frame - Relación del frame con otros frames - Descriptor del frame - Reglas de producción - Procedimientos a usar - Valores por defecto - Slots vacíos - Herencia de otros frames

Problemática No existe una teoría formal de frames lo que hace que los mecanismos de inferencia y consistencia no se puedan basar en una semántica bien definida.

39


Bases de conocimiento La estandarización en cuanto a arquitecturas que presentan las bases de datos no tiene paralelo en el ámbito de las bases de conocimiento. Cada implementación tiene su propia arquitectura. Lo que sí podemos aportar es alguna definición formal, siempre desde el punto de vista de la IA. La siguiente es una de las pocas que encontramos en la literatura (Hodgson 1991:49-50): Un Sistema de Representación de Conocimiento para un universo U consiste en:

Una colección E de etiquetas que pueden representar individuos en U;

estas etiquetas se dividen en constantes y variables. Una colección F de funciones. Una colección R de relaciones. Un lenguaje L consistente en reglas para combinar las funciones,

relaciones y etiquetas en expresiones bien formadas de L. Una semántica S que provee de significado a las etiquetas, funciones y

relaciones. Teniendo en cuenta la definición anterior, podemos deducir los problemas más importantes que la representación de conocimiento presenta: - La necesidad de un conocimiento profundo de nuestro propio conocimiento. Es evidente que no poseemos una comprensión lo suficientemente detallada de muchas materias. Cuanto más amplio sea nuestro conocimiento de éste, más fácil nos será recrear sus mecanismos artificialmente. En especial deberíamos conocer con exactitud tres puntos cruciales:

o ¿Cuáles son los individuos que constituyen el universo? o ¿Que propiedades poseen? o ¿Qué relaciones existen entre ellos?

- El desarrollo de una notación precisa. Aun suponiendo que poseamos un conocimiento lo suficientemente detallado de la materia que pretendemos representar, resulta crucial el disponer de una notación lo suficientemente precisa como para poder plasmar ese conocimiento de forma que pueda ser usado de forma inteligente por un cerebro electrónico. A esta notación se le da el nombre de esquema de representación. El primer paso para desarrollar tanto una base de datos como una base de conocimiento ha de ser la elección de un determinado modelo de datos en el caso del primero o de un esquema de representación en el caso del segundo. Esta elección repercutirá directamente en las características y posibilidades del sistema de información.

40


Al estudio de los sistemas desde un punto de vista más o menos abstracto se le denomina modelado conceptual. Por tanto, se entiende por modelado conceptual la descripción de un sistema de información (KBMS, DBMS, aplicaciones construidas con algún lenguaje de programación) en un nivel de abstracción por encima del nivel de arquitectura e implementación. En IA, el problema de diseñar un Sistema Experto se centra en construir una base de conocimiento que represente el conocimiento de una empresa determinada. También las metodologías de bases de datos han venido ofreciendo desde su etapa de madurez modelos semánticos de datos. Los modelos de datos clásicos ofrecen niveles de abstracción muy bajos, es decir la correspondencia entre el nivel conceptual y el nivel físico suele ser muy directa. Los modelos semánticos de datos intentan escalar en el nivel de abstracción para poder dar cuenta de estados y procesos complejos de una forma relativamente simple.

41


Capítulo 2.4.- Razonamiento A esta fase se la puede definir como el proceso como el proceso de obtención de inferencias o conclusiones a partir de unos hechos u observaciones reales o asumidos. Resumiendo se podría decir, que es el proceso por el cual, a partir de unos hechos conocidos, se obtienen conclusiones de otros hechos desconocidos. Evolución histórica En los años 50 ya se utilizaba el razonamiento automático en juegos. Posteriormente en 1963, apareció el sistema “General Problem Solver”, realizado por Newel y Simon, capaz de realizar inferencias lógicas. El sistema consistía en ir atravesando una serie de estados, de tal forma, que se generaba una secuencia de operaciones que iba reduciendo las diferencias entre el estado objetivo y el estado actual en cada momento. Cada diferencia indicaba una medida de la proximidad al objetivo y cuales eran los pasos a dar en la siguiente etapa. Más tarde aparece el razonamiento heurístico Proceso Se deben realizar los siguientes pasos:

- Identificación de los elementos del conocimiento importantes para la solución del problema

- Activación y control del conocimiento e interpretación de los resultados - Resolución de situaciones conflictivas

El encargado de llevar a la práctica el mecanismo de inferencia es el motor de inferencias. Tipos de razonamiento

- Forward Chaining o encadenamiento hacia adelante - Backward Chaining o encadenamiento hacia atrás - Forward/ Backward Chiang

42


Razonamientos basados en reglas de producción Tienen su origen en los sistemas de producción. Constan de:

- Conjunto de reglas de producción - Memoria de trabajo - Ciclo de reconocimiento y actuación

Ciclo de reconocimiento y actuación Es el procedimiento de control de un sistema de producción. Es un procedimiento de marcha hacia delante. La memoria de trabajo se inicializa con la descripción del problema. El estado del proceso de resolución del problema se mantiene a través de un conjunto de modelos en la memoria de trabajo. El control sigue los siguientes pasos:

- Los modelos guardados en la memoria de trabajo se tratan de superponer en las condiciones de las producciones. - Se crea un conjunto “conflicto”. Este es un subconjunto de producciones cuyas condiciones se cumplen. Estas producciones se dice que son “permitidas”. - Se escoge una producción y se “dispara” o se activa. (Resolución del conflicto). (Varias estrategias) - La acción de la regla es disparada cambiando el contenido de la memoria de trabajo. - Se repite todo el proceso descrito con la memoria de trabajo modificada. - El proceso continúa hasta que no hay condiciones en las reglas que cumplan el contenido de los modelos de la memoria de trabajo. (No hay mecanismos de ruptura de bucles infinitos)

43


Descripción gráfica:

Figura 20: Descripción gráfica del ciclo de reconocimiento y actuación

Figura 21: Descripción gráfica del ciclo de reconocimiento y actuación

44


En un sistema basado en reglas aparecen unos hechos. Los “hechos” son afirmaciones incondicionales que se asumen que son ciertas en el momento de ser usadas. Los hechos pueden proceder:

- De una base de datos - De la memoria del ordenador - De la información aportada por el usuario - De sensores - Derivados de la aplicación de reglas a otros hechos.

La interpretación y aplicación de las reglas de conocimiento de acuerdo a unos hechos, es la tarea del motor de inferencias, elemento ejecutor del razonamiento en un sistema basado en reglas. Pasos del motor de inferencias:

- Seleccionar las reglas a examinar: Reglas disponibles - Determinar cuáles de estas son aplicables y formar el conjunto conflicto - Seleccionar una regla para disparar

Razonamiento hacia delante. El ciclo del forward chaining 1. Parte de unas observaciones (hechos). 2. A partir de los hechos observados se seleccionan las reglas cuyas condiciones están relacionadas con ellos. 3. Las reglas seleccionadas son examinadas para ver si verifican todas sus condiciones. Aquéllas que las verifican constituyen el "conjunto conflicto". 4. De todas aquellas que forman el conjunto conflicto se selecciona una sola y se activa (se dispara). La selección de una regla del conjunto conflicto es la "resolución del conflicto”. 5. La activación de la regla provocará la aparición de otros hechos que se añaden a los observados y se actualiza la base de hechos. 6. Volver al paso 2 hasta analizar todos los hechos observados y deducidos.

45


Descripción gráfica:

Figura 22: Descripción gráfica del ciclo de forward chaining

Uso de variables en las reglas Se permite usar variables en la formulación de reglas de conocimiento. Las variables se usan para hacer las reglas más generales reduciendo el número de reglas necesarias para representar el conocimiento. El tipo de regla que se requiere a menudo es del estilo de: Para todo X, Si condición sobre X Entonces conclusión sobre X

46


Algoritmo RETE Una vez una regla ha sido seleccionada del conjunto conflicto y disparada, el conjunto conflicto se borra y se comienza de nuevo. Esto se justifica pensando que el disparo de una regla altera la base de hechos y pueden ser diferentes las reglas que pudieran estar en el conjunto conflicto. En la mayor parte de las veces, el disparo de una regla solamente introduce ligeros cambios en la base de hechos y de aquí que el conjunto conflicto no se altere demasiado. Un enfoque más eficiente sería examinar o tener en cuenta sólo aquellas reglas cuya condición haya sido afectada por cambios en la base de hechos en el ciclo anterior. El algoritmo de RETE es una posible solución a esta la ineficiencia del ciclo de forward chaining. Se basa en que en el momento de la lectura de la base de conocimientos durante la instalación de un Sistema Experto, todas las partes condición de todas las reglas se sitúan en una red RETE, donde cada nodo representa una condición atómica, (una sola condición). Hay dos tipos de nodos en una red RETE:

- Nodos alfa: Pueden ser satisfechos por un hecho simple - Nodos Beta: Pueden ser satisfechos sólo por un par de hechos

Ejemplo:

Si ?P es una tubería de calibre ?B y ?V es una válvula de calibre ?B Entonces ?P y ?V son compatibles

Esa regla estaría representada por la siguiente red RETE:

Figura 23: Ejemplo de red RETE

47


Estrategias para elegir una regla del conjunto conflicto para ser disparada

- Elegir la primera regla que encontremos que cumpla las condiciones (No se completa el conjunto conflicto). El orden de las reglas es decisivo.

- Seguir implemente el orden en que están escritas. - Asignar prioridades y empezar por las de más alta prioridad. - Reglas usadas más frecuentemente.

48


Razonamientos basados en redes semánticas Es un razonamiento hacia adelante basado en el simple seguimiento de los enlaces de la red. Existen varios procedimientos de inferencia:

- Activación por propagación - Asociación de estructuras

Activación por propagación Comienza con la activación de todos los nodos conectados a un par de nodos (iniciales) y continua con la activación de todos los nodos conectados a los nodos activados y así sucesivamente hasta que se encuentra un nodo que es activado por ambas partes del par de nodos inicial. Un concepto es conectado al par inicial de conceptos. (Razonamiento muy lento) Método de asociación de estructuras Es el más utilizado. Consiste en emparejar fragmentos de red que incluyen variables desconocidas con fragmentos de red contenidas en la base de conocimientos. Ejemplo con pegamentos: Red semántica

Figura 24: Red semántica inicial para asociar estructuras

49


¿Hay algún adhesivo que pegue papel?

Figura 25: Estructura a la cual se busca una solución

Solución:

Figura 26: Asociación de las estructuras que aporta la solución al problema

¿Qué estado tiene hiperglue?

Figura 27: Otro ejemplo de asociación de estructuras para otro caso particular

50


Razonamiento con esquemas de representación basados en lógica Se basa en el uso de reglas de transformación tanto del cálculo de enunciados como del cálculo de predicados de primer orden. Se pueden emplear diferentes métodos

- Deducción directa - Reducción al absurdo - Resolución

Cálculo de enunciados Una vez que se ha representado el conocimiento a base de enunciados y sus correspondientes conectivas, ahora es el momento para razonar apoyándonos en ese conocimiento representado previamente. Todo cálculo consta de reglas de transformación que son las leyes por las que a partir de expresiones bien formuladas se obtienen otras. Esto es similar al razonamiento, pues de unos enunciados podemos llegar a otros por inferencia. Nos interesa conocer cuales son esas reglas de inferencia válidas. Una de ellas son las tautologías. Una tautología es una forma de razonar válida en donde para cualquier razonamiento que podamos hacer con esa forma, si las premisas son verdaderas, lo será necesariamente también su conclusión. Por el contrario las contradicciones, al igual que las expresiones consistentes, no nos interesan. Por lo tanto sólo las expresiones tautológicas son de especial interés como reglas de transformación o reglas de razonamiento en el cálculo de enunciados. Cálculo de predicados de primer orden Todas las reglas que se utilizaban en la lógica de las proposiciones son de aplicación en el cálculo de predicados de primer orden. Además de las anteriores hay otras particulares del cálculo de predicados que se centran básicamente alrededor de los cuantificadores como son:

- Regla de eliminación del cuantificador universal - Regla de introducción del cuantificador universal - Regla de eliminación del cuantificador existencial - Regla de introducción del cuantificador existencial

51


Ejemplos de razonamiento basado en lógica Hacia delante:

Figura 28: Descripción gráfica del razonamiento hacia delante

Hacia atrás:

Figura 29: Descripción gráfica del razonamiento hacía atrás

52


Capítulo 2.5.- Tipos de Sistemas Basados en Conocimiento A continuación se va a describir brevemente cuales son los tipos de sistemas basados en conocimiento existente más comunes, así como sus características básicas y algunos ejemplos. Interpretación Se refiere a seleccionar una hipótesis en base a unos datos medidos y su información corolaria. En la interpretación, se infieren descripciones de situaciones a partir de datos observables. Ejemplos Vigilancia, Entendimiento de voces, análisis de imagen, elucidación de estructuras químicas, Interpretación de señales y muchos tipos de análisis de inteligencia. Diagnosis Aquí no solo se interpretan datos para determinar la dificultad, sino que se buscan datos adicionales para ayudar a verificar o rechazar la línea de razonamiento emprendida. Se infieren malfuncionamientos de sistemas a partir de datos observables. Dentro de este tipo se encuentra el Sistema Experto desarrollado. Ejemplos Diagnosis medica, electrónica, mecánica y de “software”, diagnóstico de averías, etc. Depuración, Tratamiento o Reparación: Con estas funciones se está uno refiriendo a tomar medidas o recomendar acciones que corrijan una situación adversa que ha sido diagnosticada. En este sentido, prescriben remedios para casos de malfuncionamiento. Confían en la capacidades de planificación, diseño y predicción para crear especificaciones o recomendaciones para corregir un problema de diagnostico o desarrollan y ejecutan planes para administrar un remedio para algún problema diagnosticado. Incorporan capacidades de depuración, planificación y ejecución.

53


Ejemplos: Tratamiento médico, solución/reparación de averías, etc. Predicción, pronóstico y prospección Se trata de pronosticar lo que sucederá en el futuro, sobre la base de la información actual; es decir, Se pretende inferir consecuencias verosímiles a partir de situaciones dadas. Esta previsión puede depender sólo de la experiencia, o puede implicar el uso de formulas y modelos. Este tipo de sistemas prevé el curso del futuro a partir de un modelo del pasado y del presente. Ejemplos Pronóstico del tiempo, predicciones demográficas, estimaciones de cosechas y previsiones militares, etc. Monitorización y control Monitorización: Se refiere a observar una situación en curso cuando se va desarrollando según lo previsto, e intentar reconducirla a su curso si se desviara de él. Si esto no pudiera hacerse, se alertaría al monitor cuando se produjeran diferencias de las observaciones de comportamiento de un sistema con las características que parecen cruciales para el éxito del plan resultante. Control: Es una combinación de “monitorización” de un sistema y de tomar las acciones necesarias para corregir los desvíos que lo alejan de alcanzar sus metas. En muchos casos, como sucede en la operación de vehículos o maquinas, el tiempo de respuesta tolerado sólo puede ser de milisegundos. Gobiernan adaptativamente el comportamiento global de un sistema. Para ello, deben interpretar repetidamente la situación actual, predecir el futuro, diagnosticar las causas de problemas venideros, formular un plan remedio y monitorizar su ejecución para asegurar el éxito. Ejemplos: Planta nucleares, procesos industriales, trafico aéreo, vuelos espaciales, enfermedades (UCI), etc...

54


Capítulo 3.- Descripción del problema a tratar En este capítulo se describirá la situación actual de la construcción y la arquitectura, ya que es el dominio donde se encuadra el problema que estamos tratando. Se analizarán tanto cuestiones específicas de las patologías en edificios, como temas más generales de construcción, pero que afectan directamente al problema que nos atañe. Origen de las patologías en la construcción Muchas y muy variadas pueden ser las causas de las patologías en los edificios. Las más comunes se debaten entre los efectos del paso del tiempo en todos aquellos edificios construidos hace ya bastantes años, errores en la ejecución, cálculo y diseño de determinados elementos constructivos, o simplemente la acción destructora de los agentes climatológicos que actúan, en unas zonas geográficas más que en otras, sobre los edificios, provocando daños y desperfectos. No se debe confundir la patología con el síntoma visible que la delata. Una grieta no es una patología, que las divisiones interiores no admitan las deformaciones que sufre la estructura si lo es, aunque el síntoma más claro y evidente sean unas grietas que aparecen en los tabiques con unas características concretas. Las agrupaciones de las patologías se han podido realizar en base a varios criterios, pero finalmente se ha decidido distribuirlas atendiendo a los síntomas que las caracterizan, como se puede comprobar en los diagramas de la parte de Conceptualización de este mismo proyecto. Otra clasificación se podría haber realizado en base a los elementos constructivos afectados por la patología, pero tras debatirlo con los expertos se decidió que el árbol resultante posterior del diagrama DRPIE, que se explicará más adelante, seria más complejo y ramificado para obtener exactamente el mismo resultado, ya que al clasificar por este criterio, el anidamiento posterior con los otros datos para modificar el flujo según muestra el mapa de conocimiento (ver apartado de Conceptualización), sería bastante más complejo. Según esta clasificación por síntomas las diferentes patologías aquí tratadas se pueden agrupar en:

- Grietas - Fisuras - Desconchones - Desplomes - Humedades

55


Cabe señalar que la casuística tratada se centra en obras con estructura de hormigón armado, así como en antiguas edificaciones de piedra, no siendo considerados los edificios construidos con estructura metálica, al ser ya la casuística expuesta más que suficiente a la par que significativa para realizar la aplicación. Por supuesto, aquellas patologías más difícilmente diagnosticables, y por ello más interesantes para el proyecto, son las relacionadas con las grietas y fisuras, debido a que estos síntomas son compartidos por muchas patologías completamente diferentes entre sí. Este es el principal reto de cara a la extracción del conocimiento al experto, su posterior Conceptualización y formalización. De nada serviría una aplicación en la que no existiese este tipo de ambigüedad, pues no se estaría tratando la verdadera complejidad que supone el diagnóstico de patologías en la construcción. Independientemente de su edad o estado, ningún edificio está exento de poder sufrir patologías, ya que incluso durante su construcción se producen, siendo muy frecuentes la aparición de grietas en los siete primeros años a partir de su finalización, casi siempre por la misma causa como hemos podido saber a manos de los expertos. Esta causa tiene su origen en la deformación y acomodamiento de la estructura al entrar en carga y redistribuir los esfuerzos, deformaciones estructurales, que aunque perfectamente admisibles, provocan la aparición de determinados desperfectos como grietas a 45º en tabiques y cerramientos interiores. La existencia de un exceso en las deformaciones estructurales, aún sin comprometer la estabilidad del conjunto, suele producir daños a los elementos soportados por la estructura. Incluso esto enlazaría con la aseveración de algún experto calculista de estructuras de edificación, en relación con la poca extendida teoría del “pilar crítico”, que llega a afirmar que en una estructura de edificación optimizada existe un porcentaje inferior al diez por ciento de pilares “críticos”, definiendo como tales aquellos cuya eliminación comprometería gravemente la estabilidad de la estructura. Es decir, si elimináramos un pilar de una estructura que no tuviera la condición de “crítico”, condición que predomina, no se produciría el derrumbamiento. Esta teoría es argumentada por el hecho de que una estructura es un elemento dinámico en cuanto a su capacidad para absorber y redistribuir las cargas que soporta. En el caso de que uno de los elementos de la estructura falle y no sea lo suficientemente indispensable para cumplir con su misión en relación con el conjunto, los elementos circundantes y relacionados actúan de forma solidaria, asumiendo la responsabilidad de este elemento. Esta es una de las aseveraciones en las que se basó el ilustre Ingeniero de caminos, diseñador y calculista de la cubierta del hipódromo de la Zarzuela de Madrid, Eduardo Torroja, para afirmar en alguna de sus aseveraciones que: para que una estructura se caiga es necesario que esté mal diseñada, mal dimensionada, mal calculada, mal ejecutada, y además, tener mala suerte.

56


Hoy en día esta afirmación se corrobora al estudiar los coeficientes de seguridad que establecen las normativas vigentes, tales como la EHE. Muchas de estas medidas preventivas son absolutamente desproporcionadas en opinión de algunos expertos, pues al final del proceso de cálculo, se han acumulado tantos coeficientes de seguridad, que incrementan la estructura de tal forma que el resultado es un edificio que realmente resiste varias veces más que el máximo de carga que le puede llegar a exigir su uso en determinados momentos puntuales y esporádicos.

57


Situación actual de la construcción Se puede decir que en los últimos años la arquitectura de élite se ha centrado mucho más en el proceso creativo y artístico del diseño del edificio, que en el avance de los procesos constructivos que mejoren la durabilidad y longevidad de lo construido, así como la optimización de la relación calidad/precio. Con esto ni mucho menos se pretende exponer que no se haya avanzado en los procesos constructivos tradicionales y más comúnmente empleados, pero si es cierto, que no se ha logrado ningún adelanto de un orden de magnitud importante, o que haya tenido gran relevancia. Haciendo una comparativa de la construcción con el software, se puede citar el artículo de F. P. Brooks “No silver Bullets” [BROOK]. Según va demostrando el tiempo con su devenir, en la construcción, al igual que en el software, no existen balas de plata que solucionen de una forma significativa todos esos escollos intrínsecos a su propia complejidad que ralentizan, encarecen y entorpecen su proceso de producción. Con la llegada del auge de los elementos prefabricados, tanto los estructurales como los que no lo son, realmente no se ha conseguido el gran avance esperado. Esto es debido a que, en primer lugar, no se abaratan costes de una forma sustancial, siendo incluso en ocasiones más caros que los elementos tradicionales construidos in situ. En cuanto al proceso constructivo, que en una primera instancia parecía favorable a los elementos prefabricados, finalmente no ha sido tan positivo para éstos, pues aunque la labor del operario se reduce a una “simple colocación” de los elementos prefabricados, dicha labor es algo nuevo y desconocido para él, lo que supone un proceso de adaptación y especialización, que conllevaría más retraso y aumento de costes que la construcción tradicional, sobre todo teniendo en cuenta que una vez finalizado este proceso de adaptación, el beneficio total no se vería altamente incrementado. Si merece especial mención la llegada, hace ya algunos años, de la informática al sector de la arquitectura. Actualmente la inmensa mayoría de los arquitectos e ingenieros relacionados con este campo utilizan herramientas informáticas en casi todos sus quehaceres profesionales diarios. Con la ayuda de esta tecnología han conseguido una mayor productividad, mejorando los aspectos cuantitativos de su vida profesional. Cierto es, que para la mayor parte de dichos técnicos, no ha supuesto un avance cualitativo, pues la automatización del proceso de diseño resta creatividad y merma la parte artística del mismo, dejando al profesional más atado a la máquina que al proceso de creación y diseño. Todo ello nos priva en ocasiones, de aquellas soluciones geniales por parte del técnico, que anteriormente eran conceptualmente viables, y que con la implantación de las nuevas herramientas se han reducido a cubrir el trámite sin pena ni gloria.

58


Dicho todo esto, cabe destacar a todos aquellos profesionales, que hoy día, aún se aferran a las técnicas clásicas específicas de su dominio, para imprimir a sus obras un carácter único, revalorizando su obra y dotándola de un valor que va más allá de lo estrictamente correcto. Es gracias a todos estos profesionales de la “vieja escuela”, que todavía se conserven elevados conocimientos de campos que han caído en el desuso, que no tienen la misma relevancia que en épocas anteriores debido a las circunstancias, o que simplemente, ya no interesan. Como es el caso que nos atañe, las patologías en la construcción. Analizando ya la situación física de la construcción hoy día, se puede dividir la labor profesional constructiva en varias tareas diferenciadas, pero ni mucho menos excluyentes entre sí. Por una parte está la construcción de obra nueva, por otra el mantenimiento de todos aquellos edificios en perfecto estado para su habitabilidad, pero que el paso del tiempo ha castigado, haciendo que sean necesaria determinadas reformas y adaptaciones para su correcto uso y funcionamiento. Finalmente queda por citar el campo de la rehabilitación y mantenimiento de edificios antiguos. Este último campo esta en un verdadero auge en los días que corren. La fiebre por mantener cualquier fachada o edificio arquitectónicamente intranscendente ha alcanzado valores extremos, siendo denominado este movimiento entre algunos profesionales del sector como: “fachadismo”. Los “eruditos del arte” y las comisiones de patrimonio, instan unos y obligan otros, a mantener y conservar, habitualmente, elementos parciales del edificio, que no hacen si no entorpecer y encarecer el proceso constructivo habitual, no obteniéndose en muchos casos ningún beneficio para la sociedad, pues lo conservado carece de todo valor, confundiendo lo antiguo con lo viejo. Mientras tanto, algunas verdaderas joyas del patrimonio arquitectónico que a todos pertenece, están totalmente abandonadas y sin ningún tipo de mantenimiento o conservación. El conocimiento de estas situaciones, unido a la certeza de que incluso los edificios en obra sufren patologías, nos llevan indudablemente a la necesidad de un sistema de las características del aquí descrito.

59


Patologías en la construcción Teniendo en cuenta lo anteriormente expuesto y viviendo la situación actual de la construcción en nuestro país, es fácil llegar a la conclusión de que hay muy pocos expertos de verdad en esta materia. El campo de las patologías en la construcción es un campo opaco y traicionero, donde la experiencia es mucho más importante que el conocimiento académico, donde sólo la heurística recogida durante muchos años de vida profesional, otorga el verdadero juicio para poder discernir entre un mal u otro. Al igual que en otras disciplinas, son los síntomas los agentes que nos indican la patología sufrida. Estos síntomas son los responsables de la dificultad de concluir con acierto lo que le sucede a un edificio, bien sea nuevo, se encuentre en su longevidad normal, o bien el paso implacable de los años hayan hecho mella en él. Un mismo síntoma puede estar provocado por innumerables patologías diferentes excluyentes incluso entre sí. Para discernir correctamente entre ellas es necesario analizar en profundidad las características del síntoma, siendo esto determinante en las ocasiones más favorables. En otros casos es necesario buscar y encontrar otros síntomas que apoyen y corroboren las hipótesis que el experto maneja en su mente. Como se puede comprobar en la aplicación creada, son muchas las patologías cuyo síntoma principal son las grietas y fisuras, de ahí lo difícil que es llegar a una conclusión acerca del verdadero mal que atañe al edificio. Por ejemplo, una simple grieta puede estar provocada por:

- Una deformación admisible de la estructura no admitida por la tabiquería interior.

- Asientos en la cimentación. - Corrosión de las armaduras. - Pandeo de las armaduras. - Una deformación provocada por una carga de uso excesiva o no

proyectada. - Una carga excesiva en el cerramiento exterior que apoya sobre

forjados en vuelo. - Humedades en revestimientos en climas fríos y con frecuentes

heladas. - La mala ejecución de la fábrica. - La mala ejecución del desmochado de las viguetas. - Dilataciones o efectos térmicos sobre la cerámica que compone

fábricas y soleras - Etc.

Vista la lista anterior es más fácil hacerse una idea de la complejidad que entraña el diagnóstico de patologías en la construcción, pues las causas de un mismo síntoma pueden ser muy diversas.

60


Gravedad de las patologías Es de vital importancia diagnosticar y evaluar la verdadera gravedad que supone cada patología, ya que en algunas ocasiones, puede entrañar peligro para la integridad física de personas, animales y bienes materiales, mientras que en otras el mal ocasionado no va más allá de un perjuicio estético o de desperfectos que no revisten importancia en cuanto a los daños potenciales y reales. Por ello, el diagnóstico del experto debe ser lo más acertado posible, no dejándose atrapar por la múltiple casuística que se presenta ante sus ojos como posibles patologías potenciales que sufre el edificio, ya que en muchas ocasiones, debido a un síntoma ambiguo, se puede restar importancia a un caso realmente grave, o otorgársela a un asunto nimio que no tiene repercusión real sobre asuntos trascendentes. Soluciones planteadas Debido a los problemas para el diagnóstico relatados en el punto anterior, se ha considerado que una parte esencial a tener en cuenta para el sistema es el proceso de razonamiento que sigue el experto dependiendo del caso que esté estudiando en cada momento, no siendo este proceso de inferencia idéntico para todas las patologías, aunque si bastante coincidentes sobre todo en las primeras fases de recogida de información relevante y esencial para un correcto diagnóstico. Es debido a la importancia de este proceso de inferencia por parte del experto, por lo que se decidió crear el “Diagrama de Representación del Proceso de Inferencia del Experto” (DRPIE) atendiendo a la casuística tratada. Este diagrama es una propuesta del autor para intentar plasmar gráficamente cuales son los pasos que sigue un verdadero experto a la hora de enfrentarse a un problema de este tipo. De esta forma se recoge toda la heurística propia del experto, que ya es clasificada y ordenada, para poder aplicarla en aquellos casos a los que les concierne dicho conocimiento. Esa heurística puede ser de varios tipos y aplicarse en momentos diferentes del proceso de inferencia. En ocasiones, el experto puede estar bastante seguro de la posible patología sufrida por el edificio con tan sólo conocer un par de datos. Este es el caso de las humedades por ejemplo, ya que la experiencia dictamina, que en su inmensa mayoría suelen ser problemas de condensación, bien por la presencia de un puente térmico, un mal aislamiento o una fuente de humedad intensa en el interior. En este tipo de casos la heurística del experto sirve para realizar inferencias anticipadas o prematuras. Estos casos han sido reflejados e implantados en la aplicación desarrollada.

61


En otras ocasiones la experiencia nos sirve para discernir entre dos posibles patologías, buscando evidencias concluyentes. De otra forma no sabríamos la existencia e importancia de estas evidencias o características a la hora de concluir lo que le pasa al edificio. En estos casos el experto está aplicando su conocimiento específico al final del proceso. Como se puede comprobar, no toda la experiencia del experto es igual, ni se aplica en el mismo momento, ni sobre los mismos datos, ni tiene la misma importancia. De ahí la importancia del DRPIE como paso previo a la formalización del conocimiento, para recoger toda la heurística en cada coso concreto y en el momento concreto. Considero que ha sido muy positivo el desarrollo de dicho diagrama para perder el menor conocimiento posible a la hora de pasar de adquirir el conocimiento a representarlo formalmente mediante reglas.

62


Capítulo 4.- Estudio de viabilidad

El estudio de viabilidad realizado para evaluar la factibilidad del sistema que queremos desarrollar es el Test de Slagel. Dicho test consta de tres etapas: Definición de las características En esta etapa se consideran cuatro dimensiones:

- Plausibilidad: Permite determinar si se cuenta con los medios necesarios para afrontar el problema desde el punto de vista de la ingeniería del conocimiento

- Justificación: Su labor es indicar si está justificado el desarrollo del sistema

- Adecuación: Se analiza si el problema es adecuado para ser resuelto con técnicas de Ingeniería del Conocimiento.

- Éxito: Se determinan las probabilidades a priori del éxito del sistema a desarrollar

A cada característica que se analiza se le asigna un peso, dependiendo de su importancia. Posteriormente se evalúa el grado de cumplimiento de la misma. Por este motivo se debe normalizar el resultado obtenido, pues al no tener todas las características el peso de 10, el resultado obtenido no está normalizado y es relativo a los pesos asignados y no al porcentaje puro.

63


Test de Slagel

PLAUSIBILIDAD CAT IDEN PESO VALOR DENOMINACIÓN CARACTERÍSTICA TIPO EX P1 10 9 Existen expertos. E EX P2 10 9 El experto asignado es genuino. E EX P3 8 10 El experto es cooperativo. D EX P4 7 8 El experto es capaz de articular sus métodos

pero no categoriza. D

TA P5 10 10 Existen suficientes casos de prueba; normales, típicos, ejemplares, correosos, etc.

E

TA P6 10 8 La tarea está bien estructurada y se entiende. D TA P7 10 10 Sólo requiere habilidad cognoscitiva. D TA P8 9 10 No precisan resultados verdaderamente

comprometidos con el proyecto. D

TA P9 9 10 La tarea no requiere sentido común. D DU P10 7 8 Los directivos están verdaderamente

comprometidos con el proyecto. D

Figura 30: Tabla de plausibilidad del test de Slagel

VC = 81,65 VC Normalizado = 91,57 Para nuestra aplicación contamos con numerosos expertos. Dichos expertos tienen una gran experiencia en el sector de las patologías en la construcción, además de que la disponibilidad en alguno de ellos es total. Por otra parte es muy común encontrarse con patologías en casi cualquier edificio, y existe gran documentación al respecto. El sistema sólo requiere de los conocimientos técnicos de los expertos, y los resultados inferidos no son críticos en ningún aspecto.

JUSTIFICACION CAT IDEN PESO VALOR DENOMINACIÓN CARACTERÍSTICA TIPO EX J1 10 7 El experto NO está disponible. E EX J2 10 7 Hay escasez de experiencia humana. D TA J3 8 8 Existe necesidad de experiencia simultánea

en muchos lugares. D

TA J4 10 7 Necesidad de experiencia en entornos hostiles, penosos y/o poco gratificantes.

E

TA J5 8 9 No existen soluciones alternativas admisibles. E DU J6 7 7 Se espera una alta tasa de recuperación de la

inversión. D

DU J7 8 9 Resuelve una tarea útil y necesaria. E

Figura 31: Tabla de justificación del test de Slagel

VC = 66,2 VC Normalizado = 76,65

64


Habitualmente hay pocos expertos propiamente dichos en este sector. Numerosos técnicos diagnostican patologías, pero se les encarga la tarea por motivos políticos, de cercanía o de comodidad, más que por su conocimiento al respecto.

ADECUACION CAT IDEN PESO VALOR DENOMINACIÓN CARACTERÍSTICA TIPO EX A1 5 7 La experiencia del experto está poco

organizada. D

TA A2 6 9 Tiene valor práctico. D TA A3 7 8 Es más táctica que estratégica. D TA A4 7 8 Sirve a necesidades a largo plazo. E TA A5 5 7 La tarea, que no es demasiado fácil, pero es

de conocimiento intensivo, tanto propio del dominio, como de manipulación de la información.

D

TA A6 6 8 Es de tamaño manejable, y/o es posible un enfoque gradual y/o, una descomposición en subtareas independientes.

D

EX A7 7 9 La transferencia de experiencia entre humanos es factible.

E

TA A8 6 6 Estaba identificada como un problema en el área y los efectos de la introducción de un SE pueden planificarse.

D

TA A9 9 10 No requiere respuestas en tiempo real "inmediato“.

E

TA A10 9 9 La tarea no requiere investigación básica y usa, si alguna, poca generación y entendimiento del lenguaje natural.

E

TA A11 5 9 El experto usa básicamente razonamiento simbólico que implica factores subjetivos.

D

TA A12 5 7 Es esencialmente de tipo heurístico. D

Figura 32: Tabla de Adecuación del test de Slagel VC = 50,25 VC Normalizado = 80,04

El sistema analizado es específico y prácticamente intemporal, pues las patologías en la construcción analizadas en dicho sistema permanecerán invariables mientras los sistemas constructivos no cambien radicalmente, cuestión más que improbable. Así y todo, muchas de estas patologías son causadas por efectos físicos inherentes a cualquier edificio independientemente del sistema constructivo empleado para su construcción. Este sistema no tiene la necesidad de inferir inmediatamente sus respuestas, puesto que estas no son críticas en ningún aspecto.

65


EXITO CAT IDEN PESO VALOR DENOMINACIÓN CARACTERÍSTICA TIPO EX E1 8 9 No se sienten amenazados por el proyecto,

son capaces de sentirse intelectualmente unidos al proyecto.

D

EX E2 6 9 Tienen un brillante historial en la realización de esta tarea.

D

EX E3 5 9 Hay acuerdos en lo que constituye una buena solución a la tarea.

D

EX E4 5 8 La única justificación para dar un paso en la solución es la calidad de la solución final.

D

EX E5 6 10 No hay un plazo de finalización estricto, ni ningún otro proyecto depende de esta tarea.

D

TA E6 7 10 No está influenciada por vaivenes políticos. E TA E7 8 5 Existen ya SS.EE. que resuelvan esa o

parecidas tareas. D

TA E8 8 8 Hay cambios mínimos en los procedimientos habituales.

D

TA E9 5 8 Las soluciones son explicables o interactivas. D TA E10 7 8 La tarea es de I+D de carácter práctico, pero

no ambas cosas simultáneamente. E

DU E11 6 7 Están mentalizados y tienen expectativas realistas tanto en el alcance como en las limitaciones.

D

DU E12 7 8 No rechazan de plano esta tecnología. E DU E13 6 9 El sistema interactúa inteligente y

amistosamente con el usuario. D

DU E14 9 6 El sistema es capaz de explicar al usuario su razonamiento.

D

DU E15 8 8 La inserción del sistema se efectúa sin traumas; es decir, apenas se interfiere en la rutina cotidiana de la empresa.

D

DU E16 6 7 Están comprometidos durante toda la duración del proyecto, incluso después de su implantación.

D

DU E17 8 8 Se efectúa una adecuada transferencia tecnológica.

E

Figura 33: Tabla de Éxito del test de Slagel

VC = 52,9 VC Normalizado = 79,50

El valor VC del sistema es = 81.94

66


5.- Adquisición y representación del conocimiento y razonamiento En este capítulo se abordarán las diferentes fases realizadas para el problema en cuestión de las patologías en edificios. Dichas fases ya fueron descritas con carácter general en el Capítulo 2. 5.1.- Adquisición del conocimiento A continuación se relatará como se ha realizado el proceso de adquisición del conocimiento para abordar la problemática de las patologías en la construcción. Técnicas empleadas Las diferentes técnicas empleadas para la realización de la adquisición del conocimiento se describen en este apartado, siendo las más importantes la técnica del seguimiento del experto y las entrevistas. Seguimiento del experto Si se tiene la oportunidad es la mejor de las técnicas, pues permite algo que no permite ninguna otra, observar como el experto realiza las tareas que la aplicación va a tener que intentar imitar lo más fidedignamente posible. No hay necesidad de hacer supuestos ni intentar comprender procesos que se desconocen. El experto actúa con naturalidad, como lo hace siempre en sus quehaceres diarios. Con suerte se consigue no sólo el conocimiento del proceso de razonamiento que sigue, sino también la aplicación de heurísticas, demostrando la importancia real de la experiencia en el dominio en el que él se mueve habitualmente, y que nosotros queremos formalizar. Se ha seguido al experto Román Ávila diariamente durante tres meses (Julio, Agosto y Septiembre de 2004) en todos sus quehaceres profesionales. Realmente aquí radica gran parte del éxito que ha cosechado la aplicación, al poder disponer de esta fuente de conocimiento tan importante, tanto a nivel cualitativo como cuantitativo. Es de ley señalar que este seguimiento ha sido posible gracias a la relación familiar existente entre el experto y mi persona, tal y como delatan nuestros apellidos. La constancia de este seguimiento se reduce a unas pocas fotos ejemplo, pero la aportación ha sido fundamental, debido a los casos tratados, al estudio del proceso de razonamiento realizado, y al apoyo que ha supuesto para poder realizar posteriormente una correcta conceptualización y representación.

67


Figura 34: Ejemplo de patología: Esquina Frágil

En la foto se puede observar un caso de “Esquina frágil” que se analizó y diagnosticó durante este proceso de seguimiento. Este es un caso típico pero y sencillo, pero cuyo conocimiento se reserva para unos cuantos profesionales curtidos con muchos años de ejercicio a sus espaldas. Entrevistas Han sido realizadas con varios expertos y profesionales de la construcción. Al principio de la fase de adquisición se realizaban de una forma informal para intentar ubicar el problema y entender los conceptos, de manera no estructurada. A medida que se avanzaba en el proyecto tanto cronológica como cualitativamente, las entrevistas se fueron centrando y focalizando, por lo que podemos hablar de entrevistas semi-estructuradas. No se realizaron entrevistas estructuradas propiamente dichas, pues siempre se dejaba un margen al experto, sin atar ni focalizar completamente el tema de discusión. A continuación se muestran algunos ejemplos de los informes realizados sobre algunas entrevistas:

68


Entrevista iniciales Fecha: Noviembre 2004 Duración: Tres horas Lugar: Estudio profesional Experto/os: Armando Fuentes (Arquitecto superior) Objetivos: • Estructurar casuística establecida previamente.

• Establecer funcionalidad del sistema. • Adquisición de documentación adicional. • Establecer criterios para desarrollo del interfaz gráfico

de usuario a implementar. Modo: No estructurada. Resultados: Todos los objetivos planteados fueron satisfechos,

obteniendo documentación adicional. Los casos a tratar por el sistema fueron estructurados atendiendo a varios criterios, y se establecieron las bases para la creación del interfaz gráfico de usuario, teniendo en cuenta las características propias de los futuros usuarios.

Comentarios: -

Figura 35: Ejemplo de las entrevistas realizadas Entrevista iniciales Fecha: Julio, Agosto, Septiembre 2004 Duración: - Lugar: Obras en construcción. Experto/os: José Luis Justo (Constructor) Objetivos: • Toma de contacto con el problema.

• Comprender el lenguaje usado en el gremio. • Establecimiento de la casuística principal que deberá

tratar el sistema. Modo: No estructurada, informal. Resultados: Todos los objetivos planteados fueron satisfechos a lo largo

de los tres meses que duró esta fase inicial. Se adquirió una visión real del problema y se pudo comprobar la utilidad que el sistema podría aportar en el futuro a este sector.

Comentarios: -

Figura 36: Ejemplo de las entrevistas realizadas Otras técnicas En las distintas reuniones mantenidas con los profesionales del sector de la construcción se han aplicado diferentes técnicas y mecanismos, bien para poder adquirir de esta forma nuevos conocimientos, bien para afianzar y contrastar conocimientos ya adquiridos. Dentro de estas técnicas empleadas cabe destacar la del “Role inverso”, que se llevó a cabo durante la fase final del seguimiento del experto, y la de “División del dominio”.

69


Capítulo 5.2.- Conceptualización del conocimiento Paso importantísimo para una correcta formalización del conocimiento adquirido. En cierta medida ha formado parte del propio proceso de adquisición del conocimiento, pues en muchos de estos diagramas es donde se ha plasmado el conocimiento adquirido de los expertos y otras fuentes de información. Estos diagramas han sido revisados por los expertos, formando parte activa en el desarrollo de los mismos. Se puede decir que es en este paso donde el ingeniero del conocimiento tiene que dar lo mejor de sí para poder integrar el conocimiento del problema a tratar con los mecanismos formales de representación que se utilizarán más adelante en el desarrollo de la aplicación. Justificación de lo realizado En este paso se conjugan dos tipos de conocimiento. Por una parte está el proceso que sigue el experto para poder desarrollar su tarea con éxito. Qué pasos da y en que orden lo hace. Por otra parte está la casuística en cuestión, que comúnmente también es aportada por el propio experto. Es fundamental para un correcto funcionamiento del programa que se pretende desarrollar conocer el vínculo y la relación existente entre la casuística y el proceso de razonamiento del experto. Como influye encontrarse en un caso concreto a la hora de modificar el flujo de actuaciones a llevar a cabo para una correcta inferencia. Este tipo de consideraciones son especialmente interesantes si queremos optimizar el sistema y hacerlo funcionar con la máxima eficiencia. Siempre se podría estandarizar el proceso de inferencia, siendo común para todas las situaciones en las que nos podamos encontrar, pero este razonamiento estático no haría sino entorpecer la inferencia, añadiendo pasos irrelevantes y gratuitos que solo conllevarían mayor coste de cálculo sin reportar ningún tipo de beneficio, al margen del ahorro de trabajo en la fase de adquisición, conceptualización y formalización. Independientemente de no aportar nada positivo, realmente nos alejaríamos del verdadero proceso que sigue el experto en sus quehaceres diarios, y no nos olvidemos, el sistema pretende ser lo más fidedigno posible con la realidad. Es por esto que no me ha importado perder pureza en mi sistema en cuanto a lo que la teoría de sistemas expertos promulga, apoyando un poco más al dominio del problema a tratar, que exigía un proceso de recogida de datos e inferencia un poco más “forzado” y rígido de lo que suele ser habitual en un SSEE, pero es cierto que lo he hecho para adaptar mejor el sistema a la realidad que los experto me han comunicado, optimizando en todo lo posible el proceso de inferencia para evitar conclusiones ilógicas, resultados contradictorios, y consumo de recursos inútiles que nada aportaban a la aplicación como ya he explicado anteriormente. De esta forma, puede que parezca que el sistema guía en exceso la labor del usuario, pero creo haberlo justificado de manera razonable.

70


Diagramas realizados A continuación se van a describir los diagramas realizados para la fase de conceptualización, así como su justificación y características. “Diagrama de Representación del Proceso de Inferencia del Experto” (DRPIE) Esta denominación ha sido creada por mí para referirme a la piedra angular que sostiene todo el conocimiento que trata la herramienta desarrollada. En el DRPIE se aúna la casuística tratada con el proceso de inferencia que realiza el experto en cada caso. Se podría decir que es un mapa de conocimiento expandido por casos, en el que se gana precisión y detalle, para perder carácter global y la visión de conjunto total que un mapa de conocimiento aporta. Ha sido el principal apoyo a la hora no sólo de formalizar el conocimiento, sino de desarrollar el motor de inferencias que actuaba sobre dicho conocimiento. El diagrama completo se muestra en la sección de anexos, adjuntando en esta parte tan sólo algunos ejemplos significativos por su contenido e importancia.

Figura 37: Leyenda de los símbolos utilizados en el DRPIE

71


Figura 38: Primer nivel del DRPIE

Figura 39: Segundo nivel del DRPIE correspondiente a grietas en este ejemplo

72


Figura 40: Tercer y cuarto nivel del DRPIE correspondientes

a grietas en elementos estructurales

73


Mapa de conocimiento Su creación e importancia ya se ha justificado en el diagrama DRPIE. El mapa de conocimiento aporta una visión global del funcionamiento de toda la aplicación, integrando datos con razonamiento. En el diagrama se puede observar como actúa a grandes rasgos la herramienta, sin entrar en detalles específicos para cada caso.

Figura 41: Mapa de conocimiento desarrollado para el sistema

Se observa como el flujo del programa va cambiando dinámicamente a medida que le van llegando datos por parte del usuario. Modificar el flujo del programa se refiere básicamente a descartar determinadas posibles patologías en función de la información ya confirmada. Del mismo modo se modifica la solicitud de datos. Por ejemplo, si un usuario nos indica que la obra está en construcción y que sufre fisuras, podemos descartar de antemano todos aquellos casos que no estén relacionados con las fisuras y los edificios en construcción. No tendría sentido realizar hipótesis sobre si las limas o las gárgolas están obstruidas, o casos similares. Igualmente se alteraría la información solicitada al usuario, pues sería totalmente absurdo preguntar cuestiones relativas a humedades cuando ya nos ha indicado que no es ese el principal síntoma observado.

74


Árbol de casos por síntomas Con este diagrama se pretende realizar una clasificación y organización de toda la casuística tratada atendiendo a los principales síntomas que caracterizan a cada patología. Una vez se han divido según el criterio expuesto anteriormente, se vuelve a hacer otra división dentro de cada subgrupo, esta vez en base al elemento constructivo afectado por el síntoma. De esta forma se consigue un árbol de clasificación congruente con los interfaces de la aplicación desarrollada. Ambos siguen los mismos criterios de clasificación para ir acotando y centrando el problema. Posteriormente a esta clasificación, el sistema sólo tendrá que discernir entre las posibles patologías diferentes que se concentran en cada nodo terminal, que comparten las características de síntoma principal y ubicación. Así y todo este diagrama es insuficiente para realizar por sí mismo una conceptualización profunda, sirviendo más como apoyo para la realización de otro tipo de diagramas que como fin en sí mismo.

Figura 42: Primer nivel de división del árbol de clasificación

de casos correspondiente a los síntomas

75


Figura 43: Segundo nivel del árbol de clasificación correspondiente a la ubicación

Figura 44: Tercer nivel del árbol de clasificación correspondiente a las características específicas

76


Ontologías Relacionan todos los conceptos del dominio del problema entre sí. Aporta una visión lógica del problema a tratar, siendo bastante útil para personas que desconozcan en gran parte el tema en cuestión. Es un buen introductor en el mundo cuyo conocimiento queremos formalizar, pero su relevancia en fases avanzadas es escasa, careciendo totalmente de la profundidad necesaria para poder apoyarnos en el a la hora de representar formalmente el conocimiento adquirido. En este caso no permite recoger heurística, pues sencillamente relaciona conceptos propios de la construcción, los edificios y sus patologías y síntomas. Al igual que el árbol de casos por síntomas, es más un apoyo en fases previas e iniciales, que un diagrama que aporte resultados tangibles, pero aporta una visión general del dominio muy interesante para centrarse y ubicarse dentro del sector del problema que queremos resolver. Como se puede observar, se relacionan conceptos de diferentes subdominios. Cada subdominio está representado por un color diferente, favoreciendo de esta forma la interpretación a simple vista. Las leyendas de las relaciones son fácilmente interpretables, y explican la forma en que los diferentes conceptos interactúan entre sí.

Figura 45: Ontología realizada para el sistema

77


Capítulo 5.3.- Representación del conocimiento El mecanismo formal utilizado para la representación del conocimiento adquirido son las Reglas de Producción. Se ha seleccionado este mecanismo por considerarlo el más adecuado para el tipo de conocimiento adquirido, pudiendo representar todos los tipos de conocimiento de la aplicación. Las reglas de producción son adecuadas para la inferencia que se realizará posteriormente, por lo que resulta un mecanismo de formalización del conocimiento excelente, facilitando las tareas posteriores que requieran de dichas reglas. Además, sus características posibilitan una implementación rápida y eficaz, evitando problemas accidentales que se pudiesen derivar de un sistema de representación de datos complejo y más rebuscado. También es necesario que el mecanismo empleado facilite posteriores modificaciones o ampliaciones, haciendo el sistema fácilmente escalable y adaptable. Las reglas de producción cumplen este requisito, además de representar el conocimiento de forma clara y específica, ayudando a su interpretación sin necesidad de grandes conocimientos para ello, lo cual contribuye positivamente a mejorar todos los procesos que se puedan realizar sobre este módulo del programa en el futuro, sobre todo si el encargado de afrontar dichas modificaciones no es el mismo que el desarrollador original. La base de conocimiento formada por reglas, se encuentra en un módulo independiente del resto del programa. De esta forma aislamos la base de conocimiento de la base de hechos, al mismo tiempo que del resto del código del sistema. Con esta diferenciación conseguimos una mayor facilidad para el acceso, lectura, comprensión y modificación de dicho conocimiento. Las reglas formalizadas a partir del conocimiento adquirido poseen encadenamiento, pues varios elementos que actúan como consecuentes en algunas reglas, en otras lo hacen como precedentes. En la base de reglas nos podemos encontrar con algunos ejemplos en los que el consecuente es el mismo para varios antecedentes posibles, es decir se puede llegar a las mismas conclusiones a partir de hechos diferentes. Así mismo, hay consecuentes que solo se diferencian entre sí en la probabilidad cualitativa asociada a dicho consecuente, desarrollando más, que muchos consecuentes poseen un análogo que solo difiere del original, en que este segundo tiene una mayor probabilidad debido a un aumento en los aspectos cuantitativos y/o cualitativos de los antecedentes. Esta situación es análoga a la que se presenta al formalizar con marcos, entre los atributos obligatorios y los opcionales.

78


Ejemplo de la base de reglas [...] (49) griet_otr_baran y no_bateaguas DILATACION SOLERAS C2 (50) griet_otr_baran y nivel_de_solado DILATACION SOLERAS C2 (51) griet_otr_baran y no_bateaguas y nivel_de_solado DILATACION SOLERAS C2 +PROBAB (52) DILATACION SOLERAS C2 (+PROBAB) y solera_dañada DILATACION SOLERAS C2 +PROBAB (53) griet_otr y pavimen y direc_perp_may_long ABOMBAMIENTO C4 (54) griet_otr y pavimen y superf_divid_areas_similares SOLERA CERAMICA POR RETRACCION C3 [...] (61) desc_vig y gran_canto y reves_inf_debil REVESTIMIENTO INFERIOR VIGA H4 (62) REVESTIMIENTO INFERIOR VIGA H4 y armad_visibl REVESTIMIENTO INFERIOR VIGA H4 +PROBAB (63) REVESTIMIENTO INFERIOR VIGA H4 y armad_densa REVESTIMIENTO INFERIOR VIGA H4 +PROBAB [...] (82) fisur_forj_sup y antig_obra y no_riego_fraguado RETRACCION HIDRAULICARUCTURA D.06 (83) fisur_forj_sup y sobrecarga_uso FLEXION D0.3 (84) FLEXION D0.3 y acumul_carg_cerram FLEXION D0.3 +PROBAB (85) FLEXION D0.3 y voladizo FLEXION D0.3 +PROBAB [...] (113) hum_carp y puente_termico CONDENSACION F3 (114) hum_carp y mal_aislamiento CONDENSACION F3 (115) hum_carp y fuente_humed_inter CONDENSACION F3 (116) CONDENSACION F3 y frio_exter CONDENSACION F3 +PROBAB (117) CONDENSACION F3 y uso_local_propicio CONDENSACION F3 +PROBAB (118) CONDENSACION F3 y no_calefacc CONDENSACION F3 +PROBAB

79


Capítulo 5.4.- Razonamiento Debido a que la representación del conocimiento se ha realizado mediante reglas de producción, el razonamiento debe estar adecuado a dichas reglas. Utilizaremos un ciclo de reconocimiento y actuación. Este es un procedimiento de marcha hacia delante (Forward Chaining). Utilizáremos las siguientes partes:

Conjunto de reglas Base de hechos Ciclo de reconocimiento y actuación

Reglas: La mayoría de las reglas que hemos empleado para representar el conocimiento relativo a las patologías tratadas por el sistema, son reglas de conocimiento profundo, pues son de carácter general y comunes a todas las patologías de ese tipo, y no específicas para elementos concretos del dominio. Base de hechos: La base de hechos o memoria de trabajo se inicializa con los datos obtenidos del usuario, es decir con la descripción de la patología que el usuario haya realizado. Las reglas que representan el conocimiento relativo al problema que estamos tratando poseen encadenamiento, por lo que, en bastantes ocasiones, los consecuentes inferidos en determinados momentos pueden ser necesarios para actuar como antecedentes en otras reglas en otros momentos. Por esto, el conocimiento que se infiere en cada paso se añade a la memoria de trabajo, pasando a formar parte de la base de hechos en ese momento. Ciclo de reconocimiento y actuación: Con los datos de la base de hechos se crea un conjunto conflicto, que son todas aquellas reglas que pueden ser disparadas con esos datos. De entre ese conjunto conflicto, se “dispara” una de las reglas, decimos que se “resuelve el conflicto”. Para seleccionar cual de las reglas se disparará de entre todas las del conjunto conflicto, se utiliza el criterio de la prioridad espacial, es decir, se disparará la primera regla que el motor de inferencias encuentre (el la base de reglas de la documentación se encuentran colocadas al revés, por lo que si nos guiamos por dichas reglas, será la última la que se dispare). Todas estas tareas son responsabilidad del motor de inferencias, que resumiendo, debe dar los siguientes pasos:

Selección de las reglas disponibles Crear el conjunto conflicto a partir de estas Seleccionar una regla para disparar

80


Una vez que la regla es utilizada se elimina del conjunto conflicto, por lo que no puede volver a ser disparada. Cuando el conjunto conflicto está vacío, se detiene el proceso de inferencia, y ya se debería haber llegado a unas conclusiones.

Figura 46: Descripción gráfica del ciclo de marcha hacia delante

81


Inferencias anticipadas Como consecuencia de la heurística aportada por el experto, en ocasiones no es necesario completar el proceso de recogida de información que debe realizar el usuario, sino que con menos datos que en procesos de inferencia normales, el sistema, debido a este conocimiento heurístico, puede realizar una diagnóstico anticipado de la posible patología que sufre el edificio analizado, aunque obviamente con una incertidumbre mayor a la habitual. Esta característica solo ha sido implementada en aquellos casos en los que se ha considerado que el conocimiento basado en la experiencia del experto es lo suficientemente fiable, y estadísticamente probado. En estos casos, con conocer tan sólo muy pocos datos descriptivos de la situación que el usuario observa, el sistema es capaz de inferir con bastante probabilidad lo que le está ocurriendo al edificio. En algunos casos tan sólo es necesario el síntoma principal para diagnosticar con bastante seguridad que es lo que está ocurriendo, en otros es necesaria más información, aunque no el proceso de recogida de datos completo. Por supuesto, siempre que el sistema realiza una inferencia anticipada, brinda al usuario la oportunidad de contrastar dicha inferencia, mediante la aportación de más datos por parte del usuario y un nuevo proceso de inferencia por parte de la aplicación. El interfaz gráfico donde se presentan las inferencias anticipadas dista ostensiblemente del mostrado cuando se realiza un proceso de inferencia completo. Se indica cual es el motivo de tan temprana resolución del problema, poniendo en antecedentes al usuario y previniéndole de la incertidumbre de la inferencia. A continuación se explica que puede completar el proceso de inferencia habitual, y como hacerlo. Si el usuario decide continuar para corroborar el diagnóstico anticipado, solamente tiene que completar el proceso habitual de aportación de datos, y el sistema realizará la inferencia con los resultados oportunos relativos a la información aportada. Si por el contrario, el usuario considera suficiente este diagnóstico, puede volver a realizar una nueva consulta o salir del programa directamente.

82


Ejemplo de inferencia anticipada A continuación se muestra un ejemplo de cual es el aspecto de la pantalla de inferencias anticipadas, en este caso una esquina frágil. Se puede observar un ejemplo de esta patología en la Figura 34 en la página 68.

Figura 47: Pantalla que muestra una patología inferida de forma anticipada

83


Características específicas del razonamiento para el sistema de patologías Debido a la naturaleza del conocimiento que nos incumbe, se hace necesaria la división del problema en varios conjuntos o dominios diferenciados. El criterio de esta división son los síntomas que la posible patología presenta y que son observables por el usuario, (se debe tener cuidado de no confundir los síntomas con las propias patologías). El desarrollo del programa se ha realizado implementando unos interfaces por los que el usuario puede navegar para ir introduciendo las características de la patología observables por el mismo. Estos interfaces son el resultado de aplicar el mapa de conocimiento, a la casuística concreta tratada por este sistema. De la conjunción de dichos elementos se obtiene lo que yo he denominado: Diagrama de representación del proceso de inferencia del experto atendiendo a la casuística tratada, (este diagrama se encuentra en esta misma documentación, en la parte de Conceptualización del Conocimiento). A partir de dicho diagrama se han elaborado los interfaces de recogida de datos del usuario. Algunos de estos interfaces, en vez de aludir a datos de carácter general, son específicos del dominio que el usuario ya ha acotado, recogiendo únicamente la información que en ese momento es relevante. Este diseño, se puede decir, que relaja el trabajo que posteriormente tendrá que realizar el motor de inferencias, al ir realizando durante la propia recogida de datos parte de la inferencia necesaria para concluir los datos finales. Mediante este tipo de interfaces, se reducen los posibles conjuntos conflicto iniciales, centrándose en reglas más profundas que recogen la heurística que tan importante es en el dominio que estamos tratando, para dirimir entre una u otra solución. Por todo ello, el diseño de interfaces resultantes, es la plasmación mediante programación del diagrama de representación del proceso de inferencia del experto. Por supuesto, el ciclo de Forward Chaining no se ve alterado por este diseño, siendo perfectamente compatibles. Para justificar e ilustrar estas apreciaciones, así como para demostrar que los resultados obtenidos son los mismos, se va a realizar el siguiente ejemplo:

84


Ciclo Forward Chaining teórico:

Iter. Memoria trabajo Conjunto conflicto

Regla disparada

0 Antig_3-7, grieta, tabiq, 45, pto_alt_baj, forjad_reticular (2) (2) 1 Antig_3-7, grieta, tabiq, 45, pto_alt_baj, forjad_reticular,

grieta_otr (16) (16)

2 Antig_3-7, grieta, tabiq, 45, pto_alt_baj, forjad_reticular, grieta_otr , griet_otr_tabiq

(17) (17)

3 Antig_3-7, grieta, tabiq, 45, pto_alt_baj, forjad_reticular, grieta_otr , griet_otr_tabiq , griet_otr_tabiq_inclin

(18) (18)

4 Antig_3-7, grieta, tabiq, 45, pto_alt_baj, forjad_reticular, grieta_otr , griet_otr_tabiq , griet_otr_tabiq_inclin, DEFORMACION ESTRUCTURAL

(19) (20) (21)

(21)

5 Antig_3-7, grieta, tabiq, 45, pto_alt_baj, forjad_reticular, grieta_otr , griet_otr_tabiq , griet_otr_tabiq_inclin, DEFORMACION ESTRUCTURAL, DEFORMACION ESTRUCTURAL C1 +PROBAB

DEFORMACION ESTRUCTURAL C1 +PROBAB

Figura 48: Tabla de iteraciones en el ciclo de reconocimiento y actuación Implementación realizada Mediante la siguiente secuenciación de interfaces se puede observar la forma de obtener los hechos que se ha implementado en el sistema.

Tipo de edificio

Figura 49: Pantalla de selección del tipo de edificio

85


Síntomas principales

Figura 50: Pantalla de selección de los síntomas principales

Elementos afectados

Figura 51: Pantalla de selección del elemento afectado

En este punto parte del ciclo ya se ha realizado. Nos encontraríamos en la iteración 2 de la tabla anterior del forward chaining. A partir de este punto se obtiene la información restante, que en muchos casos es fundamental para diferenciar una patología de otra.

86


Características diferenciadoras

Figura 52: Pantalla de introducción de las características específicas para las hipótesis realizadas por el sistema

En las pantallas anteriores se puede observar que existe una parte dedicada denominada “Navegación”, en la que el sistema muestra la traza en ese momento. Muchas reglas que no cumplen con esos hechos ya han sido descartadas antes de que el motor de inferencia tuviese que hacerlo.

87


Capítulo 6.- Implantación El sistema ha sido desarrollado en Microsoft Visual Basic 6. Para su realización se han necesitado más de 55 formularios. Mediante estos formularios se recoge la información que el usuario debe aportar, y se va informando a éste de la información ya aportada, así como de las posibles inferencias que realice el sistema en diferentes puntos. Además se ha utilizado dos módulos de Visual Basic con extensión .bas, con el fin de implementar en ellos tanto la base de hechos como la base de conocimientos, vista la independencia que requerían estos conceptos del resto del programa. Para la realización del motor de inferencias es necesaria la colaboración de los módulos .bas citados anteriormente además de los propios formularios donde el usuario ha introducido la información. Podemos dividir las tareas en:

- Recogida de información general de la patología y el edificio - Recogida de información concreta de la patología - Paso de la información a su módulo independiente - Llamada al motor de inferencias - Devolución de los resultados

88


Recogida de información general de la patología y del edificio La recogida por parte del sistema de este tipo de datos de carácter más general se realiza a través de unos interfaces gráficos diseñados para tal fin, que coinciden con las pantallas iniciales de la aplicación por las que el usuario debe pasar. Podemos ver un ejemplo de este tipo de recogida de información en el siguiente fragmento de código, donde, dependiendo de la elección del usuario, el sistema registra el tipo de edificio ante el que nos encontramos: [...] Private Sub img_3_Click() info_tipo = "3-7 años" sintom.Show Unload Me End Sub Private Sub img_7_Click() info_tipo = "+ 7 años" sintom.Show Unload Me End Sub Private Sub img_mon_Click() info_tipo = "Monumento" sintom.Show Unload Me End Sub Private Sub img_nuevo_Click() info_tipo = "Nuevo" sintom.Show Unload Me End Sub [...] Código 1: Recogida de información general

89


Recogida de información concreta de la patología Para realizar dicha recogida de información se diseñaron unos formularios donde el sistema muestra cada una de las hipótesis que maneja una vez que ha recibido la información general del edificio y la patología. En estos formularios se presenta una serie de aspectos concretos de carácter booleano en los cuales el usuario debe fijarse para marcarlos en el caso de que estén presentes en el edificio analizado. A continuación se muestra un pequeño ejemplo de cómo se recoge la información a través de los ya mencionados formularios de Visual Basic: [...] If paralelas.Value = 1 Or paralelas_2.Value = 1 Then paral = True Modulo1.info_gr_local = Modulo1.info_gr_local + "(paralel)" End If If oxido.Value = 1 Then oxid = True Modulo1.info_gr_local = Modulo1.info_gr_local + "(oxido)" End If If seccion.Value = 1 Then secc = True Modulo1.info_gr_local = Modulo1.info_gr_local + "(secc)" End If If clima.Value = 1 Then clim = True Modulo1.info_gr_local = Modulo1.info_gr_local + "(clima)" End If If revestimiento.Value = 1 Then reves = True Modulo1.info_gr_local = Modulo1.info_gr_local + "(revest)" End If [...] Código 2: Recogida de la información concreta de la patología

90


Paso de la información a su módulo independiente Como se puede ver en los ejemplos anteriores, la información aportada por el usuario se almacena en variables externas al código del formulario, en el denominado “Modulo1”. En este módulo se encuentran todas aquellas variables que el sistema utilizará en la inferencia, a la hora de intentar encontrar reglas para crear el conjunto conflicto. A continuación se muestra un ejemplo reducido de la declaración de algunas de las variables que contienen la información necesaria para realizar la inferencia: [...] 'desconchones piedra Global marim As Boolean Global exfol As Boolean 'desconchones pilar Global paral2 As Boolean Global visib As Boolean Global deform As Boolean 'desconchones viga Global cant As Boolean Global dens As Boolean Global lechad As Boolean Global saltadiz As Bolean [...] Código 3: Declaración de variables

91


Llamada al motor de inferencias El motor de inferencias se encarga, una vez recogida toda la información necesaria, de inferir cual es o cuales son las posibles patologías que afectan al edificio en cuestión. Debido a la separación existente entre el motor de inferencias y el resto del código, el pasarle el control al motor de inferencias desde el programa es tan sencillo como ejecutar la siguiente llamada: [...] Call Infer.Inferir [...] Código 4: Llamada al motor de inferencias De esta forma estamos invocando al método “Inferir” que se encuentra en el módulo “Infer.bas”. Este procedimiento “Inferir”, accederá a la información que ha sido depositada previamente en el “Módulo1.bas”, para, a partir de dicha información, buscar las posibles reglas que se pueden disparar, crear con ellas el conjunto conflicto, y a continuación irlas disparando. Hay que tener en cuenta que el criterio seguido por el sistema para disparar una u otra regla del conjunto conflicto se basa en disparar la primera regla que se encuentre, puesto que estas ya han sido implementadas de la forma adecuada para que se encuentren primero aquellas que más interesen, avanzando de lo más genérico a lo más particular, y de esta forma ayudar al encadenamiento existente entre las reglas. El sistema disparará las reglas que cumplan los antecedentes a medida que se encuentren, almacenando el resultado de las conclusiones en el citado “Modulo1.bas”. En el caso de que dichas conclusiones no sean definitivas sino resultados parciales, el motor de inferencias accederá igualmente a estos resultados parciales utilizándolos de antecedentes en las reglas si estas así lo requiriesen. Cuando el sistema ha reconocido una patología, al haber llegado a conclusiones finales, el propio motor de inferencias le asignará una probabilidad, que será dependiente de la regla mediante la cual se ha llegado a ese resultado final. Es obvio, por tanto, que no es la regla en sí quien impone la probabilidad, sino que es consecuencia de los antecedentes que forman dicha regla, que pertenecen a la base de hechos que se han observado en el edificio, siendo la probabilidad, única y directamente dependiente de los hechos observados.

92


Devolución de los resultados Una vez que el motor de inferencias ha concluido su trabajo, éste devuelve el control al programa principal en el punto posterior al de la llamada al procedimiento de Inferir. Cuando el motor de inferencias ha concluido, el programa principal no tiene más que comprobara cuales han sido los resultados obtenidos. Dichos resultados son las posibles patologías que ha diagnosticado el motor de inferencias, y en el caso de que haya diagnosticado alguna, la probabilidad con que esta se presenta. Estos resultados son depositados en el “Modulo1.bas”, por lo que el formulario tan solo debe comprobar si se han cumplido o no las patologías para las cuales se habían realizado unas hipótesis concretas, accediendo a dicho módulo. Al mismo tiempo, en el caso de que exista alguna patología, el sistema asigna la probabilidad que ha sido asignada a dicha patología. A continuación podemos observar como se realiza estas últimas tareas descritas: [...] If def_estr = True Then patol = "Deformacion estructural" If probab = "1" Then porcen = "80%" ElseIf probab = "2" Then porcen = "90%" ElseIf probab = "3" Then porcen = "93%" End If patolog.Show End If If jun = True Then patol = "Juntas" If probab = "2" Then porcen = "90%" ElseIf probab = "3" Then porcen = "97%" End If patolog_2.Show End If [...] Código 5: Recogida de resultados del motor de inferencias

93


Capítulo 7.- Evaluación y pruebas Después de la realización del sistema se debe comprobar su verdadera calidad, posibilitando de esta forma la subsanación de posibles errores encontrados. La evaluación del sistema se puede dividir en dos procesos diferenciados: la validación y la verificación, cuyos resultados para nuestro caso se describen a continuación. Verificación

Redundancias: En un primer momento existieron bastantes redundancias en cuanto a la denominación del conocimiento adquirido por el sistema. A día de hoy se ha eliminado este problema por completo, identificando el conocimiento de entrada sin ningún tipo de ambigüedad. Al mismo tiempo se han eliminado algunos elementos que no contenían conocimiento y por tanto eran intranscendentes para el sistema. En otros casos, elementos muy parecidos entre sí, se han agrupado de forma consciente, creando soluciones de programación para no perder el detalle diferenciador asociado a cada uno de ellos. No existen circularidades actualmente en el sistema.

Completitud:

El sistema realizado hasta la fecha de hoy no se ve carente de elementos ausentes, que impidan o no, una correcta ejecución de sus funciones de detección y diagnóstico. Se ha comprobado que todos los elementos del sistema son alcanzables, independientemente del camino seguido para tal fin. Por supuesto, algunos elementos son alcanzables directamente, mientras que otros son el fruto de inferencias intermedias o resultados parciales. Consistencia: Este puede que sea el aspecto al que más atención se ha prestado en el propio proceso de desarrollo del sistema. Teniendo en cuenta que se han usado reglas para formalizar el conocimiento, se ha intentado restringir al máximo la aparición de elementos contradictorios, aunque en ocasiones, se ha considerado que el responsable de este aspecto debe ser el usuario, por lo que el sistema, tras puede proponer varias hipótesis excluyentes entre sí. En estos casos no se limita la posibilidad de que el usuario aporte información contradictoria, siendo responsabilidad de éste. Es cierto que dicha información es entendida de forma fácil por cualquier usuario y claramente excluyente, por lo que un experto no debería “caer en ese tipo de trampas”, a no ser que esté intentando diagnosticar en paralelo dos o más patologías de forma intencionada.

94


Validación

Comparación frente a resultados conocidos: Ha sido realizada por el redactor del proyecto (el que suscribe). Para ello se han utilizado casos históricos cuya resolución era de antemano. En este apartado la evaluación ha resultado todo un éxito, coincidiendo las soluciones aportadas por el sistema con la realidad de la patología cuyas entradas se han aportado. Cierto es que estos resultados satisfactorios no son todo lo concluyentes que quisiéramos, pues están condicionados por los siguientes aspectos que maquillan la verdadera capacidad de inferencia del sistema:

La mayoría de estos casos históricos se han utilizado para la realización del sistema, usándolos en algunos casos incluso como punto de partida para la adquisición y conceptualización del conocimiento. Por ello, era bastante probable que el sistema infiriese de forma correcta, pues entre los fundamentos en los que se basa se encuentran dichas patologías, que por sen tan claras y esclarecedoras académicamente hablando, resultaron ideales para empezar a adquirir el conocimiento que el sistema usa, además de para ubicar y poner en contacto al ingeniero del conocimiento con un mundo ajeno al de su vida profesional. También es significativo el hecho de que sea el propio constructor del sistema el que ha aportado los datos de entrada, relativos a las patologías históricas que se querían evaluar. Este hecho, aunque no de manera premeditada, desvirtúa y altera el proceso de inferencia del sistema, pues el usuario está familiarizado con el sistema y su motor de inferencias, y de forma inconsciente, puede introducir los datos de tal forma que se favorezca la labor de diagnóstico. Es en este punto donde se ha llegado a la conclusión de que la evaluación del sistema debería realizarse por un experto ajeno a la elaboración del proyecto siempre que esto sea posible.

Comparación frente a un experto: juego aleatorio

Se ha realizado con dos expertos diferentes y de manera no simultanea. En la primera ocasión, el experto que más conocimiento ha aportado a este proyecto, Román Ávila, puso a prueba la capacidad de inferencia del sistema. El resultado fue bastante satisfactorio, no encontrando ninguna laguna en los casos que se analizaron aleatoriamente. Se pudo comprobar la capacidad de respuesta del sistema en caso de que la introducción de datos fuese insuficiente o incorrecta.

95


En la segunda entrevista, esta vez con el experto Armando Fuentes, se realizó una segunda comprobación del sistema con casos aleatorios. En esta ocasión se detectó una pequeña deficiencia en el momento de inferir las patologías relativas a los desplomes presentes en excavaciones con edificios colindantes. Tras haber analizado el caso concreto, se llegó a la conclusión de que la formalización del conocimiento no había sido todo lo satisfactoria que debiera para estos casos concretos, adoptando la resolución de modificar las reglas implicadas en la inferencia de este tipo de patologías. La modificación ya ha sido realizada, y se ha comprobado que el sistema responde a las entradas de una forma correcta, por lo que se considera subsanado el problema detectado por el experto, anteriormente descrito. Cabe señalar la importancia del experto en el proceso de validación, pues únicamente un ingeniero del conocimiento es absolutamente insuficiente para poder detectar este tipo de problemas en el sistema, ya que el dominio de los casos que trata dicho sistema, queda generalmente fuera de su conocimiento. Comparación frente a un experto: juego de ensayo Se ha realizado este tipo de validación con el primero de los expertos mencionados en el punto anterior. Dicho experto preparó unos casos específicos, que seleccionó por considerarlos interesantes y representativos. Es de señalar la importancia de la heurística adquirida por este experto a través de su dilatada y reconocida carrera profesional, sin la cual, el éxito de este sistema que ahora evaluamos, no habría sido el mismo. El sistema respondió de forma correcta al diagnostico de las patologías que atañían a los casos seleccionados, siendo el único punto de discrepancia la probabilidad de acierto que el sistema mostraba. Debido a lo delicado del asunto, y a la falta de objetividad presente a la hora de evaluar este apartado de las probabilidades, se determinó retocar mínimamente, pero no de una forma sustancial, pues obviamente es un hecho difícil recontrastar con datos. Comparación frente a un experto: casos reales Desafortunadamente todavía no se ha podido realizar un ensayo en paralelo. La falta de tiempo y la incompatibilidad geográfica por parte de ambas partes han impedido su evaluación.

96


Análisis de sensibilidad Como ya se ha comentado en otros apartados, se ha comprobado la capacidad de reacción del sistema frente a datos de entrada insuficientes o incorrectos. Así mismo se ha comprobado los efectos que en el proceso de inferencia provocan los cambios no sustanciales en las entradas. En este punto hay que distinguir que es un caso no sustancial y que no lo es. Para el sistema no todas las entradas tienen el mismo peso a la hora de inferir como es obvio. Por ello, en algunos casos, el cambio de una sola de las entradas es suficiente para que el diagnostico sea diferente e incluso para no inferir nada, debido a la falta de evidencias que ese cambio puede suponer para el sistema. Esos son los datos clave en lo que se basa el motor de inferencias, sin los cuales el sistema seria incapaz de diagnosticar ninguna patología. Otro tipo de datos de entrada, son aquellos, que por sí mismos son insuficientes para el diagnóstico, necesitan de los anteriores para que el sistema pueda funcionar. Estas entradas sirven para apoyar y corroborar las inferencias realizadas a partir del otro tipo de entradas. Lo realmente interesante, es que esta distinción entre las entradas introducidas por el usuario, es completamente transparente para éste, no siendo consciente en el proceso de “aportación de información” de la verdadera importancia y trascendencia del dato introducido. Esto provoca en ocasiones desconcierto en el usuario cuando éste no es un experto en la materia que estamos tratando, pues da la sensación de que el sistema es incapaz de inferir nada. Lo que ocurre realmente es que la introducción de datos por este usuario “novato”, se ha realizado al azar, y estadísticamente se demuestra que en este tipo de actuaciones no se suele aportar la suficiente información, ni cuantitativa ni cualitativa, para poder inferir algo coherente. La diferente importancia de la información aportada por el usuario experto, es una garantía de la calidad de la inferencia de nuestro sistema. Análisis de la usabilidad La usabilidad del sistema, así como la calidad de sus interfaces, ha sido puesta a prueba por varios usuarios ajenos al proyecto, y en muchas ocasiones ajenos al propio dominio que éste trata. Han sido necesarios tres procesos de modificación del sistema para poder adecuarlo con la mayor fidelidad posible a lo que los usuarios de las pruebas demandaban y consideraban más correcto.

97


Caso ejemplo Suponiendo que el usuario está observando unas grietas paralelas a las armaduras en una viga, con restos de emanaciones de óxido, el proceso de aportación de datos y de inferencia es el siguiente:

Figura 53: Pantalla de presentación


98


Figura 55: Pantalla de selección del síntoma principal


99


Figura 57: Pantalla de selección de las características específicas

de las hipótesis propuestas por el sistema

Figura 58: Pantalla de muestra de ejemplos de las hipótesis

100


Figura 59: Pantalla de patología detectada

101


Caso ejemplo con inferencia anticipada Supongamos que el usuario está viendo una grieta vertical de gran longitud a lo largo de una esquina de fábrica de ladrillo. Un ejemplo podría ser la siguiente foto:

Figura 60: Ejemplo de patología que se puede

inferir anticipadamente El usuario selecciona el tipo de edificio, en este caso “Nuevo/Obra”


102


Selecciona “Grietas” como síntoma principal que sufre el edificio

Figura 62: Pantalla de selección del síntoma principal

A continuación indica que se encuentra ubicado en una esquina


103


El sistema en base a la información aportada, ya es capaz de inferir una patología de forma anticipada, debido al elevado conocimiento basado en la experiencia que maneja.

Figura 64: Pantalla mostrando la patología diagnosticada

mediante inferencia anticipada

104


Capítulo 8.- Conclusiones La aplicación desarrollada es un Sistema Experto para la detección y diagnóstico de patologías en la construcción. Primeramente el usuario navegará por una serie de menús gráficos mediante los cuales aportará información al sistema. Esta información consistirá en:

- El tipo de edificio que se está tratando, los tipos de edificios se agrupan en cuatro categorías

- El síntoma principal que se observa - El elemento constructivo afectado por dicho síntoma - Características concretas del síntoma

Como cualquier otro sistema basado en conocimiento consta de una serie de fases relacionadas con el tratamiento del conocimiento que hay que ir cubriendo. Las fases en cuestión son:

- Adquisición del conocimiento - Conceptualización del conocimiento - Representación del conocimiento

Para la adquisición del conocimiento se han utilizado principalmente las técnicas de la entrevista y el seguimiento de experto. Esto último se realizó durante tres meses del verano pasado (2004). Se ha consultado a varios expertos, pero los colaboradores principales han sido dos arquitectos superiores entre los que se encuentran el codirector del proyecto Armando Fuentes Ganzo, y Román Ávila García, Arquitecto con más de treinta años de ejercicio profesional. Con este último experto se realizó la etapa de seguimiento. Además de la información aportada por los expertos, que ha sido la más valiosa y abundante, se ha utilizado diversa documentación con diferentes fines. La conceptualización del conocimiento supuso el punto de inflexión donde se debía profundizar lo suficiente en el conocimiento adquirido para poder formalizarlo y representarlo posteriormente. Para poder plasmar en detalle todo el proceso de inferencia, con las particularidades propias de cada caso se creó el “Diagrama de Representación del Proceso de Inferencia del Experto” o DRPIE. Con este diagrama, junto con el mapa de conocimiento, y otros diagramas de apoyo, se consiguió obtener una estructura del proceso y los datos suficientemente nítida para poder representarlo de una manera formal posteriormente.

105


Se utilizaron las reglas para la posterior representación del conocimiento, ya que sus características permiten una correcta formalización y gran facilidad a la hora de implantarlas y codificarlas en el sistema desarrollado. En total se han empleado más de 115 reglas, muchas de ellas con encadenamiento. El motor de inferencias funciona con un procedimiento de marcha hacia delante (Forward Chaining). El sistema compara la base de hechos aportados por el usuario –a lo largo de su navegación por los interfaces gráficos-, con la base de conocimiento resultado de la representación del conocimiento adquirido de los expertos. Tras la comparación, cuando llega a conclusiones parciales incluye dichos datos como hechos probados, aumentando de esta forma la base de hechos anteriormente mencionada. Al llegar a resultados finales, el sistema ha concluido la inferencia, pasando a mostrar los resultados de las patologías diagnosticadas, sus características, y sus posibles tratamientos en el caso de que los hubiere. Tanto la base de conocimientos como la base de hechos se encuentran de forma independiente entre sí y con el resto del programa. De esta forma se amplia la modularidad y escalabilidad del sistema. La aplicación se pone en contacto con la base de hechos a medida que avanza el proceso de aportación de información por parte del usuario. Posteriormente llamará al motor de inferencias, que contrastará dichos hechos con la base de conocimiento, por lo que tendrá que ponerse en contacto con ella para realizar el citado proceso. Debido a la gran cantidad de conocimiento heurístico recogido de los expertos, ha sido posible realizar lo que he denominado “Inferencias anticipadas”. En estos casos el usuario no debe completar el proceso de aportación de información al sistema, sino que en un punto intermedio de dicho proceso, con la información obtenida en ese punto, y contrastando con el conocimiento basado en la experiencia del experto, el sistema es capaz de inferir una posible patología que sufre el edificio analizado. Este es uno de los puntos donde la aplicación desarrollada pone de manifiesto toda su “parte inteligente”. La aplicación se desarrolló en Visual Basic 6.0, lo que ha facilitado una creación de interfaces gráficos muy sencilla y amigable. Este punto adquiere una gran importancia pues los usuarios potenciales del sistema en cuestión, no tienen por qué estar familiarizados con aplicaciones informáticas, y menos con sistemas expertos basados en conocimiento. De ahí la importancia de aislar lo más posible la verdadera naturaleza del sistema, intentando que se asimile en la mayor medida posible, a una herramienta general, fácilmente usable, que no plantee dudas, y con un gran apoyo gráfico. Para cubrir tales objetivos se han utilizado un total de 58 formularios de Visual Basic, además de dos módulos - .bas-, para implementar la base de conocimientos y la base de hechos.

106


La validación realizada una vez desarrollado el sistema, ha permitido comprobar la bondad de las inferencias realizadas por el sistema, siendo los resultados de estas pruebas más que satisfactorios. Al mismo tiempo se depuraron errores que no afectaban a la funcionalidad de la aplicación, tales como redundancias, etc... Entre las pruebas de validación más importantes cabe destacar las llevadas a cabo por los expertos colaboradores del sistema. Dichos expertos primeramente pusieron a prueba el programa con casos aleatorios que le planteaban al sistema a medida que iban navegando por sus interfaces. Posteriormente, realizaron ensayos con baterías de casos preparados de antemano, ante los cuales el sistema debería responder satisfactoriamente por su importancia y relevancia en el dominio del problema en el que nos estamos moviendo. Como conclusión se puede decir que el sistema desarrollado ha cubierto los principales objetivos planteados, y bastantes de los objetivos secundarios. La aplicación funciona correctamente, y además sus inferencias son correctas como se ha demostrado en el apartado de validación.

107


8.1.- Grado de cumplimiento de los objetivos Tras el desarrollo del sistema, y su posterior evaluación se ha podido comprobar el grado de cumplimiento de los objetivos marcados al comienzo del desarrollo del proyecto. A continuación se analizan los objetivos propuestos y su grado de cumplimiento: + Cubrir necesidades del mundo de la construcción

- Servir de ayuda a los peritos encargados de mediar en los habituales conflictos entre propietarios, empresas constructoras, compañías aseguradoras y técnicos que han proyectado y dirigido la edificación, ya que el sistema será capaz de reconocer el origen de la patología, contribuyendo a deslindar las responsabilidades que puedan corresponder a la intervención de cada agente en el proceso de construcción, o bien a los usuarios y propietarios por un uso incorrecto ó falta de mantenimiento del edificio. Debido a la calidad de inferencias mostrada en la fase de validación y pruebas, este objetivo ha sido cubierto en su totalidad, pues todas las personas anteriormente mencionadas pueden hacer uso de la herramienta con garantía, para el desarrollo de su vida profesional. - Apoyar en la elaboración de informes técnicos que se deriven de la inspección técnica de edificios, cuya exigencia e implantación, de forma cada vez más habitual, se viene adoptando por comunidades autónomas y ayuntamientos. Según lo expuesto por determinados colaboradores, el sistema puede ser de gran ayuda a la hora de realizar dichos informes. - Ayudar en la búsqueda de posibles alternativas y obras de reparación de las patologías detectadas, valorando la viabilidad de cada una de ellas. Este objetivo se cumple en la medida de lo posible, pues en ocasiones no es factible aportar una solución, debido a su complejidad, o a que cada caso requiere de un tratamiento específico.

108


+ Integración de la tecnología en otros campos ajenos a la informática

- Relacionar el mundo de la construcción con el de los sistemas inteligentes, para que de esta forma, las nuevas tecnologías presten todas sus ventajas a un campo tan tradicional y habitual como el de la construcción. La relación ha sido muy positiva, pudiendo calificarla de más que satisfactoria. Los expertos y demás colaboradores se han interesado en el proyecto, y han aportado todo aquello que estaba en sus manos. Tanto para los profesionales de la construcción como para el IC, ha sido una experiencia rica y gratificante, adquiriendo conocimientos nuevos e interesantes.

+ Contribuir al avance de la tecnología propia de otros dominios

- La elaboración de un sistema que pueda dar lugar a otros de la misma índole, para poder cubrir necesidades desamparadas actualmente de una forma eficaz, dada la escasa interacción existente entre estos dos campos a día de hoy. Para ver el cumplimiento de este objetivo habrá que esperar al futuro y ver como se desarrollan los acontecimientos, pero el primer paso ya está dado.

+ Conocer otros sectores profesionales por parte del ingeniero informático

- Interactuar y analizar la forma de obrar y de pensar de otros profesionales de distinto ámbito que el de la informática, en este caso arquitectos, aparejadores, constructores, ingenieros, etc. Como ya se ha argumentado en otros puntos, este es un objetivo cumplido. El proyecto, además de aportar su propio valor intrínseco, ha propiciado el enriquecimiento personal del autor, dotándole de nuevos conocimientos ajenos a su campo, y proporcionándole nuevas amistades y contactos que abren la puerta a potenciales proyectos.

109


8.2.- Una nueva idea para el papel del ingeniero del conocimiento Hoy en día en el diseño de sistemas autómatas de ayuda a la persona -ya sean programas, herramientas, máquinas u objetos mecánicos- una fase crítica es la adquisición de los conocimientos del experto en la materia que queremos tocar. En este proceso de adquisición del conocimiento hay que pasar por diferentes fases para poder transformar esas reglas cognoscentes del experto a reglas aplicables a la mecánica de funcionamiento de nuestro sistema.

o s s

s

o

.

Figura Este paso conlleva la pérdiday se acerca poco a lo que sepor ejemplo podemos ver gramédico que finalmente han odiagnóstico de una manera m Existen casos aislados dondmecánico de manera casi común, y es que el expertofuncionamiento. Por lo que reglas con la exactitud que se Como se puede deducir, estaque el problema que se planel cuello de botella de todoconocimiento al funcionamiesolucionar este estrago del dtan sólo de traspasar conocim Aquí es donde entra en conceptualización, el Ingenier Un paso importantísimo paadquirido es la conceptualizapaso donde el ingeniero delpoder integrar el conocimie

Conocimient

s

s

n

Funcionamiento

65: Proceso que lleva a cabo el IC

de mucho conocimiento que quiere plasmar en la mayorndes proyectos de sistemas eptado por aparcar dado que ás rápida que con el asistente

e el conocimiento ha sido trexacta. Estos casos suelen en el conocimiento es tames capaz de plasmar en el exige.

s personas no abundan en nutea necesita otra solución más este proceso es la correctanto, podríamos decir que liseño puede ser una etapa mientos a funcionamiento.

juego un nuevo personaje o del Conocimiento.

ra una correcta formalizacióción del mismo. Se puede d

conocimiento tiene que dar nto del problema a tratar co

110

Entrevista

Estudio

Análisi

Investigació

Regla

Metodología

Bipolarism

Etc..

se quiere transmitir, ía de los casos. Así xpertos de ayuda al el médico realiza el .

asladado al mundo tener un factor en bién experto en el funcionamiento las

estro planeta, por lo general. Dado que transformación del a llave que puede ás que se encargue

del mundo de la

n del conocimiento ecir que es en este lo mejor de sí para n los mecanismos


formales de representación que se utilizarán más adelante en el desarrollo de la aplicación. El papel del ingeniero del conocimiento encargado de esta tarea, es por tanto, fundamental. Si se consiguiese un mecanismo medianamente automatizado para realizar su labor supondría un avance cualitativo de gran magnitud, no solo para los sistemas expertos, sino para casi cualquier tipo aplicación informática, pues uno de los grandes problemas (por no decir el principal) del desarrollo software, se centra en la complejidad intrínseca del problema de negocio a tratar, y de su vínculo con las tecnologías de la información. De esta forma se conseguiría atacar de frente al principal cuello de botella y creador de conflictos de la ingeniería del software. Esta suposición corrobora la idea de que los problemas a la hora de crear el software no radican en el propio proceso de desarrollo como supone bastante gente, sino que estos no son más que problemas accidentales que no crean una repercusión grave en dicho proceso. Si somos capaces de tener un sistema intermedio que se encargue de analizar el conocimiento independientemente de su origen y sea capaz de transformarlo en funcionamiento, entonces podríamos estar ante un avance realmente importante en la Ingeniería del Software.

CONOCIMIENTO

FUNCIONAMIENTO

Conjunto de Herramientas de Abstracción y transformación

Expertos

Diseñadores

Figura 66: Proceso simplificado para crear un sistema basado en conocimiento

De esta manera y con estas herramientas estamos separando a los diseñadores del problema de tener que conocer la materia que están diseñando, dejándoles tan sólo la tarea de diseñar el sistema acorde con las reglas obtenidas de este paso de sistematización y abstracción de conocimientos. Los Diseñadores no tienen que aprender la materia del experto para poder diseñar.

111


La idea consiste en que el ingeniero del conocimiento pueda emplear herramientas y aplicaciones para realizar su tarea, de tal forma que sistematicen, automaticen y estandaricen el proceso de conversión del “ambiente” del conocimiento a emplear. Así, el ingeniero de conocimiento actuaría de forma eficaz a la hora de vincular el conocimiento puro en su dominio de negocio, con la representación de dicho conocimiento para poder ser tratado con la tecnología oportuna. Con esta idea se intenta crear un nexo eficaz, colaborando de forma sustanciosa en el proceso de diseño de casi cualquier aplicación. Hoy en día y a través de sistemas expertos que sean capaces de ir aprendiendo de su historia de sucesos, se podría desarrollar un conjunto de herramientas para el Ingeniero del Conocimiento que lo ayude a sistematizar conceptos y conocimientos que ya no tendría que aprenderse. Así por ejemplo si el I.C. se encuentra con un problema como: X + Y En primer lugar tendrá que estudiar cómo funcionan las reglas matemáticas para poder desarrollar un esquema de funcionamiento con el que resolver este problema: Regla: Añadimos el valor de X a Y Pero las próximas veces que el IC se encuentre con algo parecido, el Sistema Experto ya habrá aprendido esta lección, por lo que cuando el IC se encuentre con otro problema similar: X * 3 + Y Se lo dejará al IC como: Regla: Añadimos el valor de X * 3 a Y Y el IC se encargará de completar el sistema de reglas: Regla1: Sumamos el valor de X tres veces Regla2: Añadimos el resultado al valor de Y Y así sucesivamente hasta que el Sistema Experto sea capaz de discernir en la problemática que se trata de resolver. Así además se está separando a los diseñadores del conocimiento, por lo que tratarán de hacer un diseño lo más óptimo a estas reglas, que ya de por sí son un fiel reflejo del conocimiento, pero traducido para el diseñador.

112


El ingeniero del conocimiento dejaría de ser una figura tan específica para hacer honor a su propio nombre y abrirse camino en cualquier rama y/o sector de la sociedad de la información, pues desempeñando este nuevo papel, mucho más amplio, eficaz y universal, abandonaría su sector específico colaborando activa y positivamente en el diseño de aplicaciones informáticas de casi cualquier carácter.

113


Capítulo 9.- Bibliografía [MINV] Ruinas en construcciones antiguas. López Collado, Gabriel.

Ministerio de la vivienda. [CATMAD] Curso de patología. Comisión de asuntos tecnológicos (CAT).

Colegio oficial de arquitectos de Madrid. [CATGAL] Fichas para la prevención de patología en forjado unidireccional

de hormigón armado. CAT. Colegio oficial de arquitectos de Galicia.

[OCVCB] Fichas técnicas de construcción OCE. Colegio de arquitectos de

Cataluña y Baleares. [COAC] 25 Fichas de patología. Colegio oficial de arquitectos de Cataluña. [COAL] Fichas de patología. Colegio oficial de arquitectos de León. [ASEM] Publicaciones varias. Asociación de seguros mutuos de

arquitectos superiores (ASEMAS). [INFOR] Visual Basic 6 a fondo. Sergio Árboles y Luis Navarro. InforBook’s [BROOK] No Silver Bullets. Frederick P. Brooks

114


Capítulo 10.- Presupuesto Las tareas imputables son las siguientes:

- Horas del IC para adquirir el conocimiento - Horas del IC para conceptualizar y representar el conocimiento - Realización del motor de inferencias - Diseño del entorno gráfico - Programación de la herramienta

Se supone que las licencias y los equipos informáticos necesarios para desarrollar la aplicación ya se disponían con anterioridad, por lo que no se imputan en este presupuesto. Presupuesto:

Concepto Horas Precio/Hora (€) Total (€)Adquisición del conocimiento 100 20 2000Conceptualización y Representación 70 25 1750Realización del motor de inferencias 50 25 1250Diseño entorno gráfico 30 25 750Programación de la aplicación 80 20 1600Total 330 -- 7350

115


Capítulo 11.1.- Anexo1-Entrevistas Entrevista iniciales Fecha: Julio, Agosto, Septiembre 2004 Duración: - Lugar: Estudio profesional, obras en construcción, diversos

edificios ya terminados que sufren patologías. Experto/os: Román Ávila (Arquitecto superior) Objetivos: • Toma de contacto con el problema.

• Comprender el lenguaje usado en el gremio. • Establecer funcionalidad del sistema. • Convivir con el experto para conocer su modo de

operar. • Establecimiento de la casuística principal que deberá

tratar el sistema. • Adquisición de documentación complementaria. • Adquisición de permisos a través del experto para

acceder a fondos bibliográficos de instituciones oficiales.

Modo: No estructurada, informal. Resultados: Todos los objetivos planteados fueron satisfechos a lo largo

de los tres meses que duró esta fase inicial. La casuística fue establecida, se adquirió documentación relativa al problema en cuestión, y el Colegio Oficial de Arquitectos de Zamora (COALZA) concedió permiso para acceder a su biblioteca.

Comentarios: - Entrevista iniciales Fecha: Julio, Agosto, Septiembre 2004 Duración: - Lugar: Obras en construcción. Experto/os: José Luis Justo (Constructor) Objetivos: • Toma de contacto con el problema.

• Comprender el lenguaje usado en el gremio. • Establecimiento de la casuística principal que deberá

tratar el sistema. Modo: No estructurada, informal. Resultados: Todos los objetivos planteados fueron satisfechos a lo largo

de los tres meses que duró esta fase inicial. Se adquirió una visión real del problema y se pudo comprobar la utilidad que el sistema podría aportar en el futuro a este sector.

Comentarios: - Entrevista iniciales

116


Fecha: Noviembre 2004 Duración: Tres horas Lugar: Estudio profesional Experto/os: Armando Fuentes (Arquitecto superior) Objetivos: • Estructurar casuística establecida previamente.

• Establecer funcionalidad del sistema. • Adquisición de documentación adicional. • Establecer criterios para desarrollo del interfaz gráfico

de usuario a implementar. Modo: No estructurada. Resultados: Todos los objetivos planteados fueron satisfechos,

obteniendo documentación adicional. Los casos a tratar por el sistema fueron estructurados atendiendo a varios criterios, y se establecieron las bases para la creación del interfaz gráfico de usuario, teniendo en cuenta las características propias de los futuros usuarios.

Comentarios: - Entrevista Fecha: Noviembre 2004 Duración: - Lugar: - Experto/os: Román Ávila (Arquitecto superior) Objetivos: • Discutir acerca de las características propias de cada

patología. Modo: Estructurada. Tipo: Discusión focalizada. Resultados: Todas las patologías que forman parte de la casuística a

tratar por el sistema fueron descritas, identificando criterios diferenciadores clave para su correcto diagnóstico.

Comentarios: - Entrevista Fecha: Noviembre 2004 Duración: - Lugar: - Experto/os: Román Ávila (Arquitecto superior) Objetivos: • Analizar casos característicos y representativos Modo: Estructurada. Tipo: Análisis de casos tipo. Resultados: Todas las patologías que forman parte de la casuística a

tratar por el sistema fueron descritas, identificando criterios diferenciadores clave para su correcto diagnóstico.

Comentarios: - Entrevista

117


Fecha: Diciembre 2004 Duración: - Lugar: - Experto/os: Román Ávila (Arquitecto superior) Objetivos: • Conceptualización: Pasos a dar para diagnosticar una

patología Modo: Estructurada. Tipo: Simulación de escenarios hacia delante.

Método del “Role” inverso. Método del “Teachback”.

Resultados: Se obtuvo la información necesaria para poder elaborar el mapa de conocimiento de la aplicación.

Comentarios: - Entrevista Fecha: Noviembre 2004 Duración: - Lugar: - Experto/os: Armando Fuentes (Arquitecto superior) Objetivos: • Conceptualización: Pasos a dar para diagnosticar una

patología Modo: Estructurada. Tipo: Simulación de escenarios hacia delante.

Método del “Role” inverso. Método del “Teachback”.

Resultados: Se obtuvo la información necesaria para poder elaborar el mapa de conocimiento de la aplicación.

Comentarios: - No se han realizado entrevistas en grupo, ya que se considera que no es una buena técnica para extraer heurísticas, y éstas son la información más importante para el sistema que estamos tratando.

118


Capítulo 11.2.- Anexo2-Base de reglas (1) grietas y (viga o pilar o cartela o parte superior forjado o parte inferior forjado) grieta_estruc (2) grietas y (tabique o fachada o falso techo o barandilla o pavimentos o esquina) grieta_otr (3) grieta_estruc y paral_armad griet_estrc_paral (4) griet_estrc_paral y armad_oxid y reves_caida OXIDACION ARMADURAS H1 (5) griet_estrc_paral y armad_abomb PANDEO ARMADURA H5 (6) griet_estrc_paral y armad_abomb y reves_caida PANDEO ARMADURA H5 +PROBAB (7) griet_estruc y radiales y reves_caida PRESENCIA PIRITAS H2 (8) griet_estruc y 45º griet_estruc_inclin (9) griet_estruc_inclin y res_soporte DILATACION SOPORTES H6 (10) DILATACION SOPORTES H6 y altas_temper y forj_planos DILATACION SOPORTES H6 +PROBAB (11) DILATACION SOPORTES H6 y forj_planos DILATACION SOPORTES H6 +PROBAB (12) DILATACION SOPORTES H6 y altas_temper DILATACION SOPORTES H6 +PROBAB (13) griet_estruc_inclin y res_cartela ROTURA CARTELAS H3 (14) griet_estruc_inclin y res_forjado CORTANTE D.01 (15) CORTANTE D.01 y flanqueando_viga CORTANTE D.01 +PROBAB (16) grieta_otr y tabique griet_otr_tabiq (17) grieta_otr_tabiq y 45º griet_otr_tabiq_inclin (18) griet_otr_tabiq_inclin y pto_alt_baj DEFORMACION ESTRUCTURAL C1 (19) DEFORMACION ESTRUCTURAL C1 y antig_3-7 DEFORMACION ESTRUCTURAL C1 +PROBAB (20) DEFORMACION ESTRUCTURAL C1 y forjad_reticular DEFORMACION ESTRUCTURAL C1 +PROBAB (21) DEFORMACION ESTRUCTURAL C1 y forjad_reticular y antig_3-7 DEFORMACION ESTRUCTURAL C1 +PROBAB (22) griet_otr_tabiq y vertic y union_difer_elem JUNTAS (23) griet_otr_tabiq y otr_direc y no_junt_dilat EFECTOS TERMICOS D.05 (24) EFECTOS TERMICOS D.05 y forj_+_40o50_metros EFECTOS TERMICOS D.05 +PROBAB (25) EFECTOS TERMICOS D.05 y 1/4_o_1/5_luz_paño EFECTOS TERMICOS D.05 +PROBAB

119


(26) EFECTOS TERMICOS D.05 y forj_+_40o50_metros y 1/4_o_1/5_luz_paño EFECTOS TERMICOS D.05 +PROBAB (27) griet_otr_tabiq y otr_direc y antig_monum y nivel_freatic GRIETAS EN LLANO CON AGUA A4 (28) griet_otr_tabiq y otr_direc y antig_monum y ciment_sobre_yesos GRIETAS EN LLANO SOBRE YESOS A4 (29) grieta_otr y fachada griet_otr_fach (30) griet_otr_fach y paso_forjad PASOS FORJADO X1 (31) PASOS FORJADO X1 y mas_casos_misma_fachada PASOS FORJADO X1 +PROBAB (32) griet_otr_fach y reves_exter griet_otr_rev_ext (33) griet_otr_rev_ext y permeab_fach DETERIORO FACHADAS C5 (34) griet_otr_rev_ext y acumul_agua DETERIORO FACHADAS C5 (35) DETERIORO FACHADAS C5 y (ladrillo_hueco o bloque_hormig) DETERIORO FACHADAS C5 +PROBAB (36) griet_otr_fach y huecos griet_otr_huec_fach (37) griet_otr_huec_fach y deform_huec GEOLOGIA INESTABLE S2 (38) griet_otr_huec_fach y griet_traccion GEOLOGIA INESTABLE S2 (39) griet_otr_huec_fach y griet_cortante GEOLOGIA INESTABLE S2 (40) griet_otr_huec_fach y griet_traccion y griet_cortante GEOLOGIA INESTABLE S2 (42) GEOLOGIA INESTABLE S2 y (movilidad_suelo o asientos) GEOLOGIA INESTABLE S2 +PROBAB (43) griet_otr_fach y antig_monum y apertura_huecos APERTURA HUECOS A9 (44) griet_otr y falso_techo griet_otr_ft (45) griet_otr_ft y no_junt_dilat y long_excesiva EFECTOS TERMICOS D.05 (46) EFECTOS TERMICOS D.05 y pasillo EFECTOS TERMICOS D.05 +PROBAB (47) griet_otr_ft y GEOLOGIA INESTABLE S2 GEOLOGIA INESTABLE S2 +PROBAB (48) griet_otr y barand griet_otr_baran (49) griet_otr_baran y no_bateaguas DILATACION SOLERAS C2 (50) griet_otr_baran y nivel_de_solado DILATACION SOLERAS C2 (51) griet_otr_baran y no_bateaguas y nivel_de_solado DILATACION SOLERAS C2 +PROBAB (52) DILATACION SOLERAS C2 (+PROBAB) y solera_dañada DILATACION SOLERAS C2 +PROBAB

120


(53) griet_otr y pavimen y direc_perp_may_long ABOMBAMIENTO C4 (54) griet_otr y pavimen y superf_divid_areas_similares SOLERA CERAMICA POR RETRACCION C3 (55) griet_otr y esquina griet_otr_esq (56) griet_otr_esq y pilar y chapa_difer_grosor ESQUINA FRAGIL C2.5 (57) griet_otr_esq y PANDEO ARMADURA H5 PANDEO ARMADURA H5 +PROBAB (58) desc y horm_gener y griet_radiales y reves_caida PRESENCIA DE PIRITAS H2 (59) PRESENCIA DE PIRITAS H2 y exudaciones_osc_blan PRESENCIA DE PIRITAS H2 + PROBAB (60) desc y viga desc_vig (61) desc_vig y gran_canto y reves_inf_debil REVESTIMIENTO INFERIOR VIGA H4 (62) REVESTIMIENTO INFERIOR VIGA H4 y armad_visibl REVESTIMIENTO INFERIOR VIGA H4 +PROBAB (63) REVESTIMIENTO INFERIOR VIGA H4 y armad_densa REVESTIMIENTO INFERIOR VIGA H4 +PROBAB (64) desc_vig y reves_caida y armad_oxidad OXIDACION ARMADURAS H1 (65) OXIDACION ARMADURAS H1 y (humed o filtraciones o contaminacion) OXIDACION ARMADURAS H1 +PROBAB (66) desc_vig y PANDEO ARMADURA H5 PANDEO ARMADURA H5 +PROBAB (67) desc y pilar desc_pil (68) desc_pil y reves_caida y armad_oxidad OXIDACION ARMADURAS H1 (69) OXIDACION ARMADURAS H1 y (humed o filtraciones o contaminacion) OXIDACION ARMADURAS H1 +PROBAB (70) desc_pil y PANDEO ARMADURA H5 PANDEO ARMADURA H5 +PROBAB (71) desc y muros desc_mur (72) desc_mur y mur_contenc y terreno_relleno y empujes_terreno EMPUJES TERRENOS A2

121


(73) desc_mur y grietas y vegetación RAICES A11 (74) RAICES A11 y clima_humed RAICES A11 +PROBAB (75) desc y piedra_ext y clima_marin y oxid_metal y exfoliac_piedra EROSION AGUAS MARINAS A12 (76) desc y fachad desc_fachad (77) desc_fachad y paso_forjad PASOS FORJADO X1 (78) desc_fachad y acumul_agua DETERIORO FACHADAS C5 (79) fisur y forjad fisur_forj (80) fisur_forj y cara_super fisur_forj_sup (81) fisur_forj y cara_infer fisur_forj_inf (82) fisur_forj_sup y antig_obra y no_riego_fraguado RETRACCION HIDRAULICARUCTURA D.06 (83) fisur_forj_sup y sobrecarga_uso FLEXION D0.3 (84) FLEXION D0.3 y acumul_carg_cerram FLEXION D0.3 +PROBAB (85) FLEXION D0.3 y voladizo FLEXION D0.3 +PROBAB (86) fisur_forj_inf y paral_viguet y armad_oxid CORROSION VIGUETAS C.04 (87) CORROSION VIGUETAS C.04 y forj_expuesto CORROSION VIGUETAS C.04 +PROBAB (88) CORROSION VIGUETAS C.04 y zona_costera CORROSION VIGUETAS C.04 +PROBAB (89) CORROSION VIGUETAS C.04 y humedad CORROSION VIGUETAS C.04 +PROBAB (90) fisur_forj_inf y entor_soport PUNZONAMIENTO D0.4 (91) PUNZONAMIENTO D0.4 y (forj_retic o vigas_anchas_planas) PUNZONAMIENTO D0.4 +PROBAB (92) fisur y solera y superf_divid_areas_similares SOLERA CERAMICA POR RETRACCION C3 (93) fisur y fabrica fisur_fabr (94) fisur_fabr y dir_vert y machon APLASTAMIENTO MACHON FABRICA L1 (95) fisur_fabr y dir_horiz y entre_mort_y ceram FABRICA LADRILLO L2 (96) despl y fach y antig_monum y dir_ext y rotura_cubierta EDIFICIOS ANTIGUOS S3

122


(97) EDIFICIOS ANTIGUOS S3 y corrosion_acero EDIFICIOS ANTIGUOS S3 +PROBAB (98) EDIFICIOS ANTIGUOS S3 y putref_madera EDIFICIOS ANTIGUOS S3 +PROBAB (99) despl y batach y ancho_>_arco_desc EXCAVACIONES COLINDANTES D1 (100) humed y sot_y baj hum_sb (101) hum_sb y (nivel_freat o bolsas_agua) FILTRACIONES NATURALES F1 (102) hum_sb y rotura_saneam FILTRACIONES SANEAMIENTO F2 (103) FILTRACIONES SANEAMIENTO F2 y colorante FILTRACIONES SANEAMIENTO F2 +PROBAB (104) humed y cerram hum_cerr (105) hum_cerr y puente_termico CONDENSACION F3 (106) hum_cerr y mal_aislamiento CONDENSACION F3 (107) hum_cerr y fuente_humed_inter CONDENSACION F3 (108) CONDENSACION F3 y frio_exter CONDENSACION F3 +PROBAB (109) CONDENSACION F3 y uso_local_propicio CONDENSACION F3 +PROBAB (110) CONDENSACION F3 y no_calefacc CONDENSACION F3 +PROBAB (111) CONDENSACION F3 y detrás_cuadros_armarios CONDENSACION F3 +PROBAB (112) humed y carpint hum_carp (113) hum_carp y puente_termico CONDENSACION F3 (114) hum_carp y mal_aislamiento CONDENSACION F3 (115) hum_carp y fuente_humed_inter CONDENSACION F3 (116) CONDENSACION F3 y frio_exter CONDENSACION F3 +PROBAB (117) CONDENSACION F3 y uso_local_propicio CONDENSACION F3 +PROBAB (118) CONDENSACION F3 y no_calefacc CONDENSACION F3 +PROBAB

123


Capítulo 11.3.- Anexo3-Manual de usuario + Cómo realizar una consulta - Selección del tipo de edificio - Selección de los síntomas principales - Selección del elemento afectado - Corroborar las hipótesis propuestas por el sistema + Inferencias Anticipadas + Interpretación de las inferencias + Traza: Información aportada por el usuario + Fotos de ejemplo + Navegación entre pantallas + Acerca de:

124


Cómo realizar una consulta Para ello son necesarios los siguientes pasos, por los que el sistema guiará al usuario hasta obtener un resultado, que será o no satisfactorio dependiendo de los datos introducidos por éste. - Selección del tipo de edificio - Selección de los síntomas principales - Selección del elemento afectado - Corroborar las hipótesis propuestas por el sistema

Atrás

125


Selección del tipo de edificio Se realiza en la pantalla inmediatamente posterior a la de presentación. El sistema clasifica el edificio en cuatro categorías: - Nuevo/Obra: Para edificios en construcción o menores de 3 años - De 3 a 7 años - Más de 7 años - Monumental: Para edificios que hayan sobrepasado su longevidad habitual.

Atrás

126


Selección de los síntomas principales Posteriormente a elegir el tipo de edificio se debe seleccionar cual es el síntoma principal que sufre el edificio que queremos tratar. Lo s principales síntomas se agrupan en: - Grietas - Fisuras - Humedades - Desconchones - Desplomes

Atrás

127


Selección del elemento afectado En esta pantalla, una vez definidos el tipo de edificio y el síntoma principal, el usuario debe escoger cual es el elemento constructivo afectado por la patología que se pretende diagnosticar. Obviamente los elementos que el sistema muestra son dinámicamente dependientes del síntoma principal anteriormente seleccionado.

Atrás

128


Corroborar las hipótesis propuestas por el sistema Una vez definidas las características principales de nuestro edificio y sus síntomas, el sistema es capaz de realizar una o más hipótesis acerca de cual puede ser la patología que sufre. Para poder corroborar alguna de estas hipótesis, el usuario debe marcar como "presentes" todas aquellas cuestiones que se muestran en las hipótesis y en el edificio. De esta forma el sistema podrá ratificar una o más de sus hipótesis y mostrar las patologías inferidas con un porcentaje. En este tipo de pantallas es desde donde se podrá acceder a las fotos de ejemplo.

Atrás

129


Inferencias Anticipadas En determinadas ocasiones el sistema propondrá una posible patología antes de completar el proceso de recogida de datos. Esto se debe a que según el conocimiento recogido en la aplicación, para los datos introducidos hasta el momento, es muy probable que sufra la patología que se propone. Dicho conocimiento ha sido aportado por expertos que han tratado este tipo de problemas en innumerables ocasiones durante su vida profesional. Independientemente, el usuario puede proseguir el proceso de inferencia habitual pulsando sobre "Siguiente", tal y como se explica en la propia aplicación.

Atrás

130


Interpretación de las inferencias Una vez que el sistema ha realizado la inferencia, se muestra la pantalla de resultados. Éstos pueden ser una patología, varias o ninguna en el caso de que según los datos aportados, la inferencia no haya tenido éxito. A continuación se muestra la pantalla de resultados, tanto cuando la inferencia ha tenido éxito como cuando no lo ha obtenido:

131


Como se puede observar, se presentan varias secciones en la pantalla de resultados: - Traza - Patología: Nombre de la patología que probablemente sufre el edificio - Descripción: Descripción de la patología anteriormente citada - Tratamiento: Pasos a seguir para eliminar la patología y/o combatir sus síntomas Atrás

132


Traza: Información aportada por el usuario A lo largo de las pantallas de recogida de información, así como, de las pantallas de resultados, se puede conocer cual ha sido la información aportada por el usuario al sistema hasta el momento. En el caso de las pantallas de resultado, la información presentada es toda la recogida por el sistema para realizar la inferencia, y prácticamente se puede equiparar con la regla que ha disparado tal inferencia. Esta información se muestra en la parte superior de la pantalla, bajo la descripción de "Navegación", tal y como se puede ver en el siguiente ejemplo:

Atrás

133


Fotos de ejemplo En las pantallas finales de recogida de información, donde el usuario contrasta y corrobora las hipótesis propuestas por el sistema, se pueden consultar (no siempre) fotos de ejemplo para facilitar la tarea de contrastar la realidad con las preguntas efectuadas. Para ello hay que pinchar en el icono:

Una vez hecho esto se abrirá una ventana mostrando las fotos de ejemplo que ilustran las hipótesis.

Atrás

134


Navegación entre pantallas Para moverse entre las distintas pantallas hacia atrás tan solo es necesario pinchar sobre el texto "<<< Atrás" en cada una de las pantallas. De esta forma se volverá a la pantalla inmediatamente anterior a la actual. Desde la pantalla de resultados se puede volver al inicio de la aplicación para realizar una nueva consulta pinchando sobre "Inicio [::]". Atrás Acerca de: - Autor Fernando-Román Ávila Vázquez - Colaboradores José Ángel Olivas Varela Armando Fuentes Ganzo Román Ávila García Atrás

135


Capítulo 11.4.- Anexo4-DRPIE

136


137


138


139


140


141


142


143


144


145


Capítulo 11.5.- Anexo4-Árbol de casos

146


147


148


149


150


151


152


153


Capítulo 11.6.- Anexo4-Ontología

154


155

Capítulo 11.7.- Anexo4-Mapa de conocimiento

universidad pontificia de comillas · el motor de inferencias funciona con un procedimiento de...

Documents