KOC: Un Repositorio de Objetos de Conocimiento para la Enseñanza de la

Construcción Soportado por Herramientas para Composición y Autoría

David Francisco Cifuentes Cortés Departamento de Ingeniería de Sistemas y Computación

8 de Agosto de 2008

Tabla de Contenido 1  Introducción ................................................................................................................. 1-1 2  Objetivos ..................................................................................................................... 2-1 3  Estado del Arte ............................................................................................................ 3-1 3.1  Antecedentes en la Universidad de los Andes ....................................................... 3-2 3.2  Enseñanza del Área Técnica en Arquitectura ........................................................ 3-2 3.3  Administración del Conocimiento ........................................................................... 3-3 3.3.1  Administración del conocimiento en la industria de la construcción .................. 3-4 3.4  Ontologías y Web Semántica ................................................................................. 3-4 3.4.1  Sistemas para Construcción basados en Ontologías ........................................ 3-5 3.4.2  Taxonomías Para el Dominio de la Arquitectura y la Construcción ................... 3-6 3.5  E-Learning en KOC ................................................................................................. 3-6 3.5.1  E-Learning en Arquitectura y Construcción ........................................................ 3-7 3.5.2  E-learning basado en Ontologías ....................................................................... 3-7 3.6  Herramientas para Composición y Autoría ............................................................. 3-7 3.6.1  Herramientas de Autoría Basadas en Ontologías .............................................. 3-8 4  Solución Conceptual Propuesta ................................................................................. 4-1 4.1  Principios ................................................................................................................. 4-1 4.2  ArCo ........................................................................................................................ 4-2 4.2.1  El Qué. Objetos de Construcción ........................................................................ 4-4 4.2.2  El Para qué. Funcionalidades y Grados Desempeño ........................................ 4-5 4.2.3  WBS. Work Breakdown Structure ....................................................................... 4-5 4.2.4  El Dónde. Sistemas y Subsistemas en la WBS .................................................. 4-6 4.2.5  El Cuándo. Actividades en la WBS ..................................................................... 4-7 4.2.6  El Cómo. Materiales y Equipos ........................................................................... 4-7 4.3  Levantamiento de información de los proyectos arquitectónicos ........................ 4-10 4.4  KOC. Definición de conceptos .............................................................................. 4-11 4.4.1  Datos ................................................................................................................. 4-11 4.4.2  Metadatos .......................................................................................................... 4-12 4.4.3  Objetos de Conocimiento .................................................................................. 4-12 4.4.4  Anotaciones ....................................................................................................... 4-13 4.4.5  Proyectos ........................................................................................................... 4-14 4.4.5.1  Proyecto Teórico ............................................................................................ 4-15 4.5  Herramientas de autoría para KOC ...................................................................... 4-15 4.5.1  Compositor de Objetos Compuestos Basados en ArCo .................................. 4-16 4.5.1.1  Objetivo .......................................................................................................... 4-16 4.5.1.2  Usuarios ......................................................................................................... 4-16 4.5.1.3  Proceso .......................................................................................................... 4-17 4.5.1.4  Utilización de ArCo ........................................................................................ 4-17 4.5.1.5  Ejemplo .......................................................................................................... 4-18 4.5.2  Compositor Procesos Constructivos ................................................................. 4-18 4.5.2.1  Objetivo .......................................................................................................... 4-18 4.5.2.2  Usuarios ......................................................................................................... 4-19 4.5.2.3  Proceso .......................................................................................................... 4-19 4.5.2.4  Utilización de ArCo ........................................................................................ 4-19 4.5.2.5  Ejemplo .......................................................................................................... 4-20 4.5.3  Compositor Casos de Estudio ........................................................................... 4-20 4.5.3.1  Objetivo .......................................................................................................... 4-20 4.5.3.2  Usuarios ......................................................................................................... 4-21 

4.5.3.3  Proceso .......................................................................................................... 4-21 4.5.3.4  Utilización de ArCo ........................................................................................ 4-22 4.5.3.5  Ejemplo .......................................................................................................... 4-22 5  Análisis y Diseño de la Solución ................................................................................. 5-1 5.1  Descripción general y estrategia de implementación ............................................. 5-1 5.2  Actores .................................................................................................................... 5-1 5.2.1  Administrador General ........................................................................................ 5-2 5.2.1.1  Objetivo y Funciones ....................................................................................... 5-2 5.2.1.2  Permisos .......................................................................................................... 5-2 5.2.2  Administrador de la Ontología ............................................................................. 5-2 5.2.2.1  Objetivo ............................................................................................................ 5-2 5.2.2.2  Permisos .......................................................................................................... 5-3 5.2.3  Administrador de Datos ....................................................................................... 5-3 5.2.3.1  Objetivo y Funciones ....................................................................................... 5-3 5.2.3.2  Permisos .......................................................................................................... 5-3 5.2.4  Anotador .............................................................................................................. 5-3 5.2.4.1  Objetivo y Funciones ....................................................................................... 5-4 5.2.4.2  Permisos .......................................................................................................... 5-4 5.2.5  Recolector de Datos ............................................................................................ 5-4 5.2.5.1  Objetivos y Permisos ....................................................................................... 5-4 5.2.6  Profesor ............................................................................................................... 5-4 5.2.6.1  Objetivo ............................................................................................................ 5-4 5.2.6.2  Permisos .......................................................................................................... 5-5 5.2.7  Estudiante ............................................................................................................ 5-5 5.2.7.1  Objetivo ............................................................................................................ 5-5 5.2.7.2  Permisos .......................................................................................................... 5-5 5.2.8  Invitado ................................................................................................................ 5-5 5.2.8.1  Objetivo ............................................................................................................ 5-5 5.2.8.2  Permisos .......................................................................................................... 5-5 5.2.9  Anónimo ............................................................................................................... 5-5 5.2.9.1  Objetivo ............................................................................................................ 5-5 5.2.9.2  Permisos .......................................................................................................... 5-6 5.3  Casos de uso .......................................................................................................... 5-6 5.3.1  Diagramas de Casos de Uso .............................................................................. 5-6 5.3.2  Descripción de los casos de uso ........................................................................ 5-6 5.3.2.1  Administración de ArCo ................................................................................... 5-7 5.3.2.2  Administración de KOC ................................................................................... 5-7 5.4  Funcionalidades Complementarias ........................................................................ 5-7 5.4.1  Sistema de solicitudes y logs .............................................................................. 5-7 5.4.2  Personas y Empresas en la Industria de la Construcción .................................. 5-8 5.4.3  Derechos de autor y registro de fuentes ............................................................. 5-8 5.4.4  Georeferenciación de Proyectos ....................................................................... 5-10 5.4.5  Manejo Temporal de Proyectos y Datos ........................................................... 5-10 5.4.6  Feed de sindicación de noticias ........................................................................ 5-11 5.4.7  Búsqueda sintáctica .......................................................................................... 5-13 5.5  Requerimientos No Funcionales ........................................................................... 5-14 5.5.1  Manejo de archivos multimedia ........................................................................ 5-14 5.5.2  Seguridad y control de acceso .......................................................................... 5-15 5.5.2.1  Autenticación ................................................................................................. 5-15 5.5.2.2  Autorización ................................................................................................... 5-16 5.5.3  Internacionalización (i18n) ................................................................................ 5-17 

6  Arquitectura del Sistema ............................................................................................. 6-1 6.1  Arquitectura Multicapas........................................................................................... 6-1 6.1.1  Capa Web ............................................................................................................ 6-1 6.1.2  Capa de Servicios ............................................................................................... 6-1 6.1.3  Capa de Acceso a Datos .................................................................................... 6-2 6.2  Patrones de Diseño ................................................................................................. 6-2 6.2.1  Inyección de dependencia .................................................................................. 6-2 6.2.2  Patron Front Controller o Web MVC ................................................................... 6-2 6.2.3  DAO ..................................................................................................................... 6-2 6.3  Estructura de paquetes ........................................................................................... 6-3 6.4  Arquitectura de datos .............................................................................................. 6-4 6.4.1  Base de datos ...................................................................................................... 6-4 6.4.2  Ontología ............................................................................................................. 6-4 6.5  Arquitectura de componentes ................................................................................. 6-4 7  Implementación ........................................................................................................... 7-1 7.1  Especificaciones, Herramientas y Tecnologías ...................................................... 7-1 7.1.1  Java ..................................................................................................................... 7-1 7.1.2  Java EE ............................................................................................................... 7-1 7.1.2.1  JPA ................................................................................................................... 7-2 7.1.3  Eclipse ................................................................................................................. 7-2 7.1.4  Spring Framework ............................................................................................... 7-2 7.1.5  Hibernate ............................................................................................................. 7-3 7.1.6  OSGi .................................................................................................................... 7-3 7.1.7  MySQL ................................................................................................................. 7-3 7.1.8  Javascript ............................................................................................................. 7-3 7.1.9  Dojo Toolkit .......................................................................................................... 7-3 7.1.10  OWL ..................................................................................................................... 7-4 7.1.11  Protégé ................................................................................................................ 7-4 7.1.12  Jena ..................................................................................................................... 7-5 8  Estado actual y Resultados ........................................................................................ 8-1 9  Conclusiones ............................................................................................................... 9-1 10  Trabajo Futuro ........................................................................................................... 10-1 10.1  Difusión .................................................................................................................. 10-1 10.1.1  Convenios con otras universidades .................................................................. 10-1 10.1.2  KOC en la industria y en el país ....................................................................... 10-1 10.2  Desarrollo y Mantenimiento .................................................................................. 10-2 10.2.1  Mantenimiento y Extensión de ArCo ................................................................. 10-2 10.2.2  Estandarización ................................................................................................. 10-2 10.2.3  Herramientas de Tutoría ................................................................................... 10-3 10.2.3.1  Ordenador de Procesos Constructivos ......................................................... 10-3 10.2.3.2  Solucionador de casos de estudio ................................................................ 10-3 10.2.3.3  Generador de exámenes ............................................................................... 10-3 10.2.4  Otras Herramientas de Autoría ......................................................................... 10-3 10.2.4.1  Espacios de trabajo (KOC Workspaces). ..................................................... 10-3 10.3  Integración ............................................................................................................. 10-4 10.3.1  KOC Móvil.......................................................................................................... 10-4 10.3.2  KOC Social ........................................................................................................ 10-4 10.3.3  KOC Visual ........................................................................................................ 10-4 10.4  Otro Trabajo Futuro ............................................................................................... 10-5 11  Referencias ............................................................................................................... 11-1 12  Anexos ...................................................................................................................... 12-1 

12.1  Modelo Entidad Relación ...................................................................................... 12-1 12.1.1  Zona ArCo ......................................................................................................... 12-1 12.1.2  Zona Datos ........................................................................................................ 12-2 12.1.3  Zona Objetos de Conocimiento ........................................................................ 12-3 12.1.4  Zona Administración .......................................................................................... 12-3 12.1.5  Zona Anotaciones ............................................................................................. 12-4 12.1.6  Zonas de Herramientas de Autoría ................................................................... 12-4 12.1.7  Zona Workspaces ............................................................................................. 12-6 

1

1-1

1 Introducción La enseñanza de la construcción en cursos de arquitectura es un problema de alta complejidad y propone un gran reto para los educadores e investigadores. Partiendo de las observaciones realizadas por parte de un grupo de profesores en la Universidad de los Andes, dentro del desarrollo del programa de arquitectura (1) se han identificado una serie de situaciones que ratifican esta afirmación. En primera instancia existe una serie de restricciones inherentes a la actividad constructiva que impiden la visita de estudiantes a obras de construcción en tiempo real, como dificultad de acceso a la obra, inseguridad y riesgos físicos, diferencias en cuanto a cronogramas y tiempos de construcción contra tiempos asignados en un semestre académico, entre otros factores.

Como alternativa, algunos pocos profesores capturan material multimedia por sí mismos (fotografías, vídeos, entrevistas, etc.) o recuperan material de interventoría, siguiendo un proceso de recolección indocumentado, arbitrario e informal, para posteriormente presentarlo en clase. Algunos problemas resultantes de esta práctica radican en que: no hay criterios de calidad en cuanto al material recolectado, el uso del material está ligado a la interpretación propia del profesor, este material es de difícil acceso a los estudiantes y demás profesores resultando en una circulación limitada y restringida, puede desaparecer en cualquier momento, es decir, es altamente volátil, raramente es actualizado o mantenido, por lo general son datos dispersos localizados en varias máquinas diferentes y finalmente no existe un vocabulario unificado y comúnmente aceptado mediante el cual éstos sean descritos. En general es difícil enseñar de manera presencial y también lo es el simular de manera consistente las mejores prácticas y metodologías en la construcción de proyectos arquitectónicos.

Por otro lado y según el diagnóstico presentado por Villazón (2) es preocupante la gran cantidad de tiempo que invierte un profesor o un estudiante en el desarrollo de actividades rutinarias o mecánicas, que no aportan significativamente a su desarrollo profesional. Una de las claves para mejorar el desempeño, tanto de profesores como estudiantes, es garantizar que su tiempo se invierta en comprender y profundizar en los contenidos del curso, en lugar del desarrollo de estas actividades.

En las empresas de construcción, los problemas no son diferentes. Al requerir capacitar a un nuevo empleado o hacer sesiones generales de actualización y entrenamiento los empresarios se encuentra con: falta de registro de la memoria corporativa, no se aprende sistemática y efectivamente de los errores cometidos en proyectos anteriores, destinando a sus empleados a repetirlos. No hay material de calidad recolectado que muestre prácticas y metodologías propias de la empresa que pueden eventualmente acelerar la curva de aprendizaje de nuevos empleados, ni herramientas para que los mismos se entrenen.

En el día a día hay varias fuentes de información que constantemente están generando conocimiento, desde un proyecto de construcción y la actividad profesional del gremio industrial hasta la interacción de un grupo de profesores y alumnos en una facultad de arquitectura; sin embargo este conocimiento generado muchas veces se queda en un estado tácito o queda implícito en sólo aquellos que participaron directamente en su creación, perdiendo la capacidad de ser reutilizado o derivar aún más nuevo conocimiento.

1-2

Todos los factores expuestos anteriormente se reflejan de manera directa en los siguientes problemas:

• Según el diagnóstico presentado por Villazón (2) no existe un proceso formal de recolección de datos, los datos que son recolectados por profesores, por medio de su experiencia profesional o dados por contactos, no tienen ningún criterio de calidad y dependen drásticamente de la visión del profesor, la cual varía significativamente.

• No existe un lenguaje comúnmente aceptado, estructurado y no ambiguo para ser usado en la enseñanza de los conceptos de construcción en arquitectura, ya que cada profesor tiene diferentes antecedentes, origen y experiencia dentro del área técnica.

• Falta una fuente certificada, confiable y centralizada donde se puedan consultar información recolectada de proyectos de construcción, a la fecha no es posible consultar ningún catálogo o repositorio público y las empresas que registran sus obras de construcción por lo general tienen dicha información cerrada, privada y sin ninguna estructura.

El proyecto KOC (Knowledge Objects of Construction) (3) enfrenta este problema dividiéndolo en cinco grandes partes. La primera parte estructura los diferentes conceptos relevantes a la construcción en arquitectura y sus relaciones en una ontología, llamada ArCo (Arquitectural Concepts) (4). La segunda, define un proceso formal de seguimiento y recolección de datos de calidad a lo largo de todo el proceso de construcción de proyectos reales. La tercera, permite anotar los datos recolectados mediante la ontología ArCo e ingresarlos a un repositorio de objetos. La cuarta, provee facilidades de búsqueda y de consulta con alto contenido semántico sobre los objetos del repositorio. Por último la quinta, posibilita el uso de herramientas de autoría para generar objetos de conocimiento compuestos definiendo y manejando relaciones entre objetos de conocimiento "simples" existentes en el repositorio. El resultado obtenido es un repositorio de conocimiento con objetos arquitectónicos de alta calidad, claramente descritos, reutilizables y que además provee mecanismos de consulta de alto nivel, que responden a las necesidades de los arquitectos (profesionales, profesores y estudiantes).

Como prueba de concepto en la quinta parte de KOC, las herramientas de autoría, se diseñaron e implementaron tres prototipos. El objetivo de las herramientas de autoría que se desarrollaron es facilitar la labor de los autores expertos en el dominio de la construcción en arquitectura permitiéndoles construir objetos de conocimiento de mayor nivel conceptual e ingresarlos nuevamente al repositorio.

La primera herramienta, el compositor de objetos compuestos basados en ArCo, tiene como objetivo permitir a los autores relacionar objetos de conocimientos existentes a partir de búsquedas por componentes comunes de ArCo presentes en sus anotaciones. Como resultado se generan objetos de alto nivel que agrupan ejemplos de instancias específicas encontradas en el repositorio, estos ejemplos pretenden responder a preguntas de construcción en arquitectura. La segunda herramienta, el compositor de procesos constructivos, facilita el ingreso de múltiples actividades para la construcción de un elemento u operación registrando su proceso constructivo y recolecta información relevante a nivel de proceso. Por último, el compositor de casos de estudio, presenta a los profesores una manera de estructurar sus propios casos de estudio usando los contenidos del repositorio KOC como base, además permitiendo la edición colaborativa entre varios autores y la constante actualización de los casos.

El proyecto KOC es interdisciplinar y ha sido resultado del esfuerzo y colaboración de varias personas en varias áreas de conocimiento. Particularmente y dentro del marco de

1-3

esta tesis de maestría, dentro del programa de ingeniería de sistemas se presenta a lo largo de este documento mi participación en el proyecto resumido en las siguientes labores: Participación y retroalimentación en el diseño de la ontología ArCo. Participación en la definición de alcance, funcionalidades, casos de uso y requerimientos del sistema. Definición de la arquitectura, selección de tecnologías y herramientas a utilizar durante el ciclo de vida del proyecto en el que estuve involucrado. Análisis, diseño, implementación, pruebas y puesta en producción del sistema KOC. Propuesta, diseño e implementación de las tres herramientas de autoría junto con los cambios necesarios a la infraestructura de KOC para ser soportadas.

Este documento está estructurado de la siguiente manera: a continuación se presentan los objetivos del proyecto, luego se examina el estado del arte en cada una de las áreas de conocimiento que influyen en el proyecto. Más adelante se plantea la solución conceptual para introducir el análisis y diseño de la solución. Posteriormente se presenta la arquitectura del sistema seguida de detalles de implementación. Finalmente se muestra el estado actual y los resultados obtenidos hasta ahora y se finaliza con varias ideas acerca del rumbo que debe tomar el trabajo futuro.

2-1

2 Objetivos El objetivo principal de esta tesis de maestría es proveer a profesores del área técnica en arquitectura herramientas para generar material que pueda ser usado en ambientes educativos a partir de la composición de objetos de conocimiento existentes en una base de conocimiento recolectado a partir de proyectos de construcción reales y objetos teóricos. Para lograr esta gran meta es fundamental identificar algunos objetivos específicos, teniendo en cuenta la problemática planteada anteriormente en la introducción.

Como primer paso, se debe poner a la disposición de estudiantes y profesores un vocabulario unificado para la definición de los conceptos del área técnica en arquitectura. Este vocabulario debe hacerse administrable y actualizable por parte de expertos en el dominio; a partir de la definición de este vocabulario se facilita la comunicación en gran medida entre profesionales, profesores y estudiantes, al igual que el procesamiento de este tipo de información por agentes inteligentes de software.

Como segundo objetivo, se plantea administrar sistemáticamente la información resultante de la recolección de datos tomados de obras de construcción de edificios, además de hacer disponible esta información a estudiantes y profesores de las facultades de arquitectura. Esta sistematización se debe integrar con el proceso formal de recolección de datos presentado por Vela (5), teniendo en cuenta como principal componente la calidad de los datos y su relevancia en un entorno educativo.

El tercer objetivo, consiste en la centralización de grandes volúmenes de datos, relacionados con la construcción en arquitectura, en una fuente de información certificada y confiable, mediante la construcción de un repositorio de datos que evolucionan en objetos de conocimiento, el cual pueda ser consultado bajo diferentes enfoques por diversos actores.

El cuarto objetivo apunta a la gestión adecuada y sistematizada del conocimiento generado a partir de la actividad constructiva en las organizaciones involucradas en ella; universidades en primera instancia y luego en empresas dedicadas a la construcción. Por último, y como una de las claves para enriquecer pedagógicamente los datos existentes en el repositorio se tiene el objetivo de facilitar a los autores la elaboración de objetos de conocimiento compuestos de alto nivel que relacionen semánticamente conceptos y objetos de conocimiento simples, brindando así materiales propicios para el aprendizaje. El objetivo final a largo plazo de la visión global del proyecto es mejorar la enseñanza en cursos del área técnica en las facultades de arquitectura.

3-1

3 Estado del Arte El alcance del proyecto vincula varias disciplinas y áreas de conocimiento. El desarrollo del proyecto ha sido resultado de un esfuerzo interdisciplinar y colaborativo entre varias facultades universitarias por varios años; por otro lado el planteamiento del proyecto impacta tanto a la academia como a la industria. Como muestra de ello se han llevado a cabo varias investigaciones y proyectos en la Universidad de los Andes, que son tomadas como antecedentes directos del proyecto presentado en este documento. La primera sección de este capítulo consiste en la revisión algunos de estos proyectos.

Para continuar se introduce el estado del arte mediante la presentación de la Figura 3-1, en ésta se pueden observar las diferentes áreas de conocimiento que aportan o se ven beneficiadas con el proyecto. A partir de esta figura se divide el capítulo teniendo en cuenta que entre más grandes sean los cuadrados más generales son los temas y entre más pequeños más específicos, con el proyecto KOC como núcleo. Existen algunos proyectos que sirven de punto de comparación con KOC, éstos por lo general se ubican en las fronteras entre áreas de conocimiento ya que pretenden solucionar problemáticas conjuntas. Aunque en el proyecto existen muchos aportes de la ingeniería civil (como se muestra en la figura), el proyecto está enfocado a resolver la problemática vista desde el punto de vista de la arquitectura, por esta razón no se profundiza en el estado del arte en la ingeniería civil.

Se inicia con el marco teórico para la enseñanza del área técnica en arquitectura. Posteriormente se examina la temática de la administración del conocimiento y se presentan algunos de sus usos en la industria de la construcción. Luego se miran los conceptos detrás de la Web Semántica, como lo son las ontologías, e igualmente se evalúa su utilidad mediante la presentación de proyectos relacionados con el ámbito de la construcción. Posteriormente se introduce el tema de la educación a distancia o e-learning y su impacto en el dominio de la construcción, al igual que su aplicabilidad en la Web Semántica. Se finaliza con la presentación del marco teórico de las herramientas de autoría y algunos proyectos que explorar su concepción basados en ontologías.

Figura 3-1 Áreas de conocimiento involucradas en el proyecto

3-2

3.1 Antecedentes en la Universidad de los Andes Cabe anotar que KOC no es el primer intento de generación y estructuración del conocimiento en arquitectura e ingeniería civil dentro de la Universidad de los Andes. Existen otros proyectos que sirvieron de antecedentes y de los cuales se tomaron ideas, conceptos y experiencia para el diseño y la implementación de KOC, incluso desde sus primeras versiones.

Sarria (6) desarrolló una aplicación interactiva que combina diferentes medios visuales para exponer el tema de sistemas estructurales, visto desde el punto de vista de sus materiales, tipos de sistemas constructivos, cargas aplicadas, fallas y colapsos. Similar a este trabajo, Luquetta (7) hace énfasis en los subsistemas de instalaciones.

Existen varios proyectos enfocados a la gerencia de proyectos en construcción, como el propuesto por Alarcón (8) que presenta la utilidad que puede llegar a tener el uso de videos Time-Lapse para le medición y mejoramiento de la productividad de procesos constructivos, revisión de cadenas de calidad, identificación y manejo de riesgos, y capacitación. Arrieta (9) propone un trabajo más enfocado al almacenamiento del registro histórico de una empresa constructora. Se basa en las “lecciones aprendidas” como forma de continuidad de conocimiento. Para terminar con esta línea y muy relacionado con KOC como se muestra en la sección 4.2.3, Rodríguez (10) plantea una estructura de división del trabajo unificada, buscando poder ser implementada en la industria de la construcción, tratando de disminuir las dificultades que se puedan presentar en la interpretación y control de las actividades de los contratos de los diferentes proyectos. Rodríguez sugiere usar la metodología en un ámbito nacional para mejorar la comunicación entre las distintas obras dentro del país.

Por otro lado y más relacionado con la facultad de ingeniería, el Grupo de investigación LIDIE (11) realizó el AVA (Ambiente Virtual de Aprendizaje) denominado Taller Técnico I el cual tiene como principal objetivo “ofrecer un espacio de seguimiento y construcción del conocimiento tanto en las funciones estructurales como en los procesos constructivos a través de la disposición de ejercicios de análisis técnico y simulación de procesos de cimentación (constructivos)” (12). El ambiente virtual de aprendizaje permite publicar contenidos acompañados de material audiovisual como fotos y videos, e incluye un prototipo de aplicación en la que los estudiantes ordenan cronológicamente las actividades de un proceso constructivo.

Por último, la principal influencia de KOC está en la tesis de maestría de Villazón (2), quien es pionero, director y parte activa del proyecto. Él examina el estado el arte en investigaciones relacionadas con la enseñanza de la construcción, apoyados en tecnologías y nuevos medios. Adicionalmente, hace énfasis en la carencia de políticas para el registro de conocimiento proveniente de proyectos de construcción y presenta las problemáticas que impiden el acercamiento entre la academia y las obras de construcción. Su propuesta consiste en la elaboración de una aplicación que permite registrar, almacenar y recuperar información de los proyectos de construcción, con el fin de mitigar el impacto negativo que tiene el escaso acercamiento de los alumnos de arquitectura con la realidad en al área técnica de la construcción.

3.2 Enseñanza del Área Técnica en Arquitectura A lo largo de la evolución del programa de Arquitectura de la Universidad de los Andes durante casi sesenta años(13), se han identificado tres modelos educativos, que provienen de diferentes momentos del desarrollo de la enseñanza de la técnica en arquitectura: El primero, de carácter informativo brinda al estudiante los datos técnicos

3-3

sobre materiales y procesos constructivos (catálogos, visitas a obra, etc.), dentro de un número reducido de cursos, en los cuales el principal objetivo es el aporte de la mayor cantidad de información. Este modelo privilegia la cantidad de información, sobre la calidad de esta; adicionalmente no existe una estructura que ordene la información dada al estudiante.

El segundo, con enfoque politécnico, procede de las escuelas superiores europeas y norteamericanas, que a su vez tienen su origen en facultades de ingeniería, como se comentó anteriormente. Está basada en una altísima responsabilidad legal del arquitecto sobre el proyecto de construcción que lo obliga a tener las misma competencias de un ingeniero, lo que lleva a una forma de enseñanza de la técnica que busca abarcar todos los temas de estructuras, instalaciones, acondicionamiento y construcción por medio de un número elevado de cursos, apoyados en otros que tocan los contenidos específicos de las ciencias aplicadas a la arquitectura.

El tercero con un carácter claramente formativo, busca dar los criterios y conocimientos esenciales de la técnica, siempre referidos al proyecto, con énfasis permanente en la síntesis arquitectónica. Esto obliga a que el estudiante tenga contacto durante su formación con una estructura invariable de pensamiento que ha permitido construir la arquitectura.

3.3 Administración del Conocimiento La administración del conocimiento es el área que se preocupa por adquirir, hacer accesible y mantener el conocimiento al interior de una organización. En las últimas décadas se ha visto beneficiada por el uso de las tecnologías de información para este propósito y el cambio colectivo de concepción frente a los sistemas computacionales, pasando de ser únicamente procesadores de datos o calculadoras a ser herramientas de apoyo a la gestión integral del conocimiento (8). Como resultado de lo anterior el conocimiento interno de las organizaciones se ha valorizado tanto que se ha convertido en uno de los activos más importantes, éstos son denominados activos intelectuales. Una efectiva administración del conocimiento empieza a tener aun mayor relevancia en entornos globalizados y altamente competitivos. Dado el amplio alcance del término administración del conocimiento y de todo lo que implica, es conveniente tratar de clasificar y diferenciar entre diferentes tecnologías, enfoques y herramientas usadas para la administración del conocimiento.

Según Marwick (14) las tecnologías de administración del conocimiento se pueden clasificar dependiendo de los tipos de conversiones entre conocimiento tácito y explicito que pueden llevar a cabo. Para el caso específico de KOC existen varios puntos de vista de conversiones posibles que se pueden llevar a cabo siguiendo esta clasificación. La conversión de conocimiento tácito a explícito se realiza con las actividades de captura de conocimiento realizadas por los anotadores y los recolectores de información que transforman momentos de construcción en la obra a fotografías o videos y material multimedia a anotaciones estructuradas y persistentes respectivamente. La conversión de conocimiento explicito a otro conocimiento explicito se hace por medio de las herramientas de autoría cuyo objetivo es precisamente relacionar varios objetos simples y transformar el conocimiento, obteniendo como resultado otro objeto de conocimiento con un valor agregado; la búsqueda, ya que el hecho de encontrar produce nuevo conocimiento, y la generación de la ontología como taxonomía también entran en este espectro de conversión del conocimiento, ya que por medio de éstas el usuario puede manipular y encontrar el nuevo conocimiento. Por último existen varias funcionalidades de KOC que posibilitan la conversión de conocimiento explícito a tácito, entre las que se

3-4

cuentan las diferentes visualizaciones generadas o simplemente el hecho de utilizar el sistema con fines de enseñanza mediante la consulta de información.

3.3.1 Administración del conocimiento en la industria de la construcción Aunque los dominios de la arquitectura y la construcción se han caracterizado históricamente por la baja penetración de las nuevas tecnologías de información y el denominado e-work (15), se han llevado a cabo varios intentos investigativos en estructurar sistemáticamente los conceptos de la construcción y administrar este tipo de conocimiento.

Kamara, Augenbroe et al (16) llevan a cabo una investigación que resulta en la identificación de la problemática en la administración del conocimiento en las industrias de la construcción, ingeniería y arquitectura. En su artículo, ellos analizan y evalúan el alcance de las diferentes iniciativas y estrategias en la implementación de la administración del conocimiento en varias firmas. Como conclusión, muestran que para lograr una efectiva administración del conocimiento se debe tener una combinación entre los enfoques mecanicista y orgánico que incorpore tanto recursos tecnológicos como organizacionales y culturales. Este trabajo se complementa con la introducción de CLEVER (17) un framework o marco de trabajo para seleccionar a estrategia de administración de conocimiento adecuada dado el contexto organizacional y cultural de la organización, teniendo en cuenta que el hecho de administrar el conocimiento no es el fin sino el medio hacia la solución de los problemas del negocio.

A su vez Zhen, Heng et al (18) presentan un enfoque cuantitativo en la toma de decisiones para la administración de conocimiento en educación de las empresas de construcción. Este enfoque está basado en un modelo propuesto de toma de decisiones que integra estándares industriales con procesos analíticos, siguiendo la metodología de casos de estudio.

Desde el punto de vista de tecnologías y su impacto en la administración de conocimiento en la industria de la construcción, Christiannson (19), hace un recuento de herramientas existentes (algunas emergentes) para lograr este propósito. Él explica el potencial del uso de sistemas de información y discute como estas herramientas soportan e influencian el proceso de construcción de edificios. Concluye con la afirmación que no es suficiente con aprender a usar estas herramientas sino que también es necesario lograr que ellas sean parte integral de un microsistema para la administración de conocimiento en los proyectos de las compañías. También enfatiza en la importancia de la comunicación y colaboración entre la industria y la academia.

Por último, Schapke, Menzel y Scherer (20) discuten la necesidad de procesos de transformación del conocimiento en la industria de la construcción, una industria particularmente fragmentada y que presenta barreras inter e intra-organizacionales. Asignan a la administración del conocimiento el reto de superar estas barreras con soporte de las tecnologías de información y comunicación. Para ello proponen un framework que combina varios servicios de administración del conocimiento con el fin de implementar un sistema para la memoria corporativa. Se basan en gran parte en el manejo y control de documentos operacionales.

3.4 Ontologías y Web Semántica En vista de la importancia y el alcance de la administración del conocimiento, las comunidades de investigadores en las áreas de administración de información e ingeniería del conocimiento han convergido en uso de ontologías. Las ontologías son definidas como una descripción formal de un dominio específico en términos de un

3-5

lenguaje comúnmente aceptado, el vocabulario o los términos de conocimiento, teniendo en cuenta las interconexiones semánticas y algunas reglas de inferencia simples y restricciones (21).

El objetivo principal de las ontologías es modelar el conocimiento de dominios específicos de manera formal, no ambigua, consistente y libre de detalles propios de herramientas y tecnologías. En la práctica actual diversos dominios se benefician del uso de ontologías, en especial la medicina ha producido grandes y estandarizadas taxonomías.

Las ontologías han sido desarrolladas y usadas para compartir contenidos de manera semántica, tanto entre personas como entre agentes de software, aplicaciones y/o servicios. Existen otras ventajas que trae el uso de ontologías, como la separación entre el conocimiento del dominio y el conocimiento operacional, al hacer explicitas suposiciones del dominio y permitir la reutilización del conocimiento en escalas y escenarios diferentes (22).

A partir de lo anterior usar ontologías para apoyar la administración del conocimiento puede traer los siguientes beneficios: Organización del conocimiento en espacios conceptuales de acuerdo a su significado, es fundamental para las organizaciones tener claridad en la ubicación semántica de sus procesos núcleo y operaciones, identificar claramente a qué comunidades pertenece, en qué industrias se clasifica y cómo se integra interna y externamente. Mayor expresividad en consultas y mejores respuestas, con el uso de ontologías las consultas pueden ser mucho más expresivas ya que entienden conceptos y relaciones del dominio y como consecuencia las respuestas son mucho más concretas y específicas. Automatización de procesos mecánicos, como lo son por ejemplo procesos de mantenimiento, chequeo de consistencia y extracción de nuevo conocimiento (22).

La Web Semántica es un término acuñando por Sir Tim Berners-Lee para definir la visión de Internet como un medio para intercambiar, compartir e integrar información de diferentes fuentes bajo un mismo modelo; haciendo sus contenidos interpretables y procesables por agentes inteligentes (máquinas) que auto descubren, componen y ejecutan automáticamente (23). La Web Semántica necesita de las ontologías para describir las conceptualizaciones formales y compartidas en dominios específicos y de este modo, apoyándose en la semántica definida para el dominio, facilitar y potencializar labores de extracción, consulta, mantenimiento y descubrimiento de la información (24). KOC se puede beneficiar grandemente de la llegada de la Web Semántica ya que esto facilitaría la comunicación y coordinación para el intercambio, la consulta y la publicación de datos con otras organizaciones; con la posibilidad eventual futura de tener un solo vocabulario en todo el mundo para el área técnica de la arquitectura.

3.4.1 Sistemas para Construcción basados en Ontologías Existen proyectos que han tratado de estructurar la administración de conocimiento formalmente en ontologías ofreciendo acceso vía Internet a los datos, al igual que KOC. En especial Ei-Diraby y Zhang han realizado avances en el uso de ontologías para la administración del conocimiento en la industria de la construcción, específicamente enfocados en la administración de memoria corporativa en empresas de construcción (15) y en la documentación y seguimiento de las lecciones aprendidas y mejores prácticas (25). Por otro lado Wetherill, Rezgui et al han desarrollado una infraestructura (e-Cognos) (26) basada en una combinación de ontologías, sistemas de información y especificación de metodologías que incluyen servicios que permiten la creación, captura, indexamiento y diseminación del conocimiento relevante a la industria de la construcción (27). Las principales fortalezas que se identificaron del proyecto e-Cognos fueron: su arquitectura

3-6

modular y acertado uso del patrón Ontology Broker, énfasis a la temática de lecciones aprendidas y gestión de la memoria corporativa además del gran alcance e impacto que tuvo el proyecto en localizaciones de Europa y Canadá.

Aunque KOC tiene componentes similares a e-Cognos y parte de la problemática es la misma, existen ciertos puntos de vista divergentes y diferencias que se tuvieron en cuenta durante el proceso de diseño y la implementación del sistema KOC. En primer lugar el objetivo principal de KOC es mejorar la enseñanza de la construcción en arquitectura, es decir, KOC tiene un marcado énfasis en la educación y aunque su funcionalidad aplica para entornos corporativos, éste no es el núcleo del proyecto; a diferencia de e-Cognos. Como segundo punto de comparación se confrontaron las ontologías, dando como resultado un aumento en la complejidad, el tamaño y tipo de conceptos en e-Cognos, se notó e-Cognos deja a un lado el dominio constructivo para darle cabida a definición de actividades operativas, administrativas y de procesos. Por último y teniendo en cuenta los avances que han habido en el campo de la Web Semántica y la definición de nuevos lenguajes para ontologías, e-Cognos usa un lenguaje ya obsoleto (DAML) y se encuentra en gran parte desactualizada.

3.4.2 Taxonomías Para el Dominio de la Arquitectura y la Construcción Un poco más alejadas de la academia y más con el fin de llevar a cabo procesos de reglamentación, regulación y auditoría, las empresas de arquitectura e ingeniería civil dedicadas a la actividad constructiva han establecido acuerdos en la utilización de términos técnicos mediante vocabularios expresados en glosarios o taxonomías, como por ejemplo el BS6100 (28), MasterFormat (29) y UniClass (30). Estos acuerdos regularmente se dan por medio de organismos neutros de estandarización bien sea nacionales o internacionales, como el British Standard Institute (28), el Construction Specification Institute (29) o el Construction Project Information Committee (30) entre otros. Sin embargo estos vocabularios generalmente tienen algunas desventajas que dificultan su utilización en ambientes académicos: son anticuados e infrecuentemente actualizados, lo cual obstaculiza la utilización de nuevas prácticas, técnicas, recursos y empiezan a volverse obsoletos en la medida en que dejan de cumplir las necesidades de la industria. Son excesivamente extensos y a veces hasta sobre poblados, ya que intentan abarcar cada detalle de cada área de la construcción y su organización tiende a ser confuso en cuanto a las divisiones y categorías establecidas en algunos casos llevando a la inconsistencia (31).

3.5 E-Learning en KOC En el marco de este capítulo se entiende e-learning como "Educación justo a tiempo integrada con cadenas de valor de alta velocidad. Es la entrega de contenido para el aprendizaje individualizado, comprehensivo y dinámico en tiempo real que asiste el desarrollo de comunidades de conocimiento, encadenando estudiantes y practicantes con expertos" (32). A la fecha KOC no es considerado en su totalidad como una herramienta de e-learning, sin embargo según la visión planteada inicialmente se planea que así lo sea. El término e-learning puede llegar a ser bastante amplio e incluir a su vez varias sub áreas específicas del conocimiento que definen prácticas, metodologías y conceptos propios de la disciplina. Uno de estos conceptos es el de herramientas de autoría, el cual se clasifica el aporte de este documento y se constituye en el primer paso para hacer de KOC un ambiente educativo virtual. En éste capítulo se mira el estado del arte en cuanto a proyectos dentro del e-learning que están relacionados con la construcción en arquitectura y también proyectos que utilizan ontologías para formalizar conceptos propios del e-learning.

3-7

3.5.1 E-Learning en Arquitectura y Construcción Uno de los referentes más recientes en cuanto al uso de sistemas de e-learning en el dominio de la arquitectura es el sistema TDraw (33) presentado por la prestigiosa facultad de arquitectura de la universidad de Venecia. Esta herramienta pretende ser usada como un ambiente didáctico completamente virtual y como una herramienta de dialogo profesor-estudiante capaz de chequear diseños hechos por los estudiantes. TDraw promueve en gran medida, al igual que KOC, la relación y el encadenamiento de objetos que hacen parte del sistema. Una funcionalidad interesante de TDraw es la capacidad que tiene de auto aprendizaje y de sugerir soluciones a problemas que ya se han resuelto.

En el tema de procesos constructivos relacionados con el e-learning, Sampaio, Henriques y Ferreira (34) proponen una herramienta para el entrenamiento de la construcción visto de la perspectiva de la ingeniería civil. Esta herramienta utiliza modelaje geométrico y técnicas de realidad virtual para generar simulaciones de procesos de construcción permitiendo a los usuarios visualizar información propia del proceso. El valor agregado más importante de esta herramienta consiste en el detalle en que puede ser consultado la configuración de componentes de construcción.

3.5.2 E-learning basado en Ontologías Cada vez más las tendencias parecen confirmar la importancia en el papel del aprendizaje en las organizaciones, especialmente en el contexto del mercado donde se requieren métodos rápidos, eficientes y globalizados (35). Tecnologías de e-learning se han implementado para proponer una alternativa eficiente y distribuida al problema del aprendizaje. Sin embargo, con la propuesta de construcción incremental de la nueva Internet denominada Web Semántica, presentada anteriormente, se abren el potencial a los sistemas de e-learning para facilitar la navegación y el acceso a los recursos por parte de sus usuarios. A continuación se presentan algunos intentos de utilización de tecnologías de Web Semántica en contextos de educación a distancia.

Stojanovic, Staab y Studer (36) presentan la implementación de un sistema de e-learning usando descripciones de contexto, contenido y estructura de los materiales de aprendizaje basados en ontologías. Con ello logran el acceso flexible y personalizado a los materiales de aprendizaje cumpliendo los requerimientos planteados por un típico sistema de e-learning. Por otro lado, Marie-Hélène Abel, Ahcène Benayache, et al (37) presentan un sistema de memoria organizacional de documentos basado por ontologías que se adapta a escenarios de e-learning. El sistema cuenta con dos ontologías, una genérica para el dominio de entrenamiento y otra específica para el dominio de aplicación.

Ahmed, Shaik y Aouad (38) presentan el desarrollo de un ambiente e-learning para la construcción que incluye los conceptos claves tanto técnicos como pedagógicos, así mismo presentan una ontología del dominio de la construcción y su integración para definir contenido educativo tanto para profesores como para estudiantes. En la fecha que se consultó la ontología que presentan no es de acceso público, de tal manera no fue posible hacer la comparación contra ArCo e identificar alcances y diferencias.

3.6 Herramientas para Composición y Autoría Las herramientas de composición son instrumentos que permiten la creación de elementos de alto nivel a partir de elementos básicos, primitivos o ya existentes de un sistema. Constan de tres componentes fundamentales: la interfaz de usuario, el modelo de datos que las soportan y la integración con el sistema en el que se va a aplicar la autoría. La interfaz de usuario permite traducir, formalizar y visualizar el conocimiento (39) para personas sin ningún conocimiento técnico en cuanto al funcionamiento interno de la

3-8

herramienta, específicamente es deseable que estas personas sean expertos o conocedores del dominio. Por otro lado el modelo de datos que soporta la herramienta de autoría debe representar y persistir información adicional propia de la herramienta o datos adicionales relevantes que se derivan del impacto de la herramienta en el modelo.

El término acuñado como "herramientas de autoría" puede ser muy general y abarcar una gran cantidad de programas de software como editores y compositores altamente usados, por ejemplo Adobe Flash© o Microsoft Power Point®; sin embargo en las comunidades de la Inteligencia Artificial (AI) y de la educación adquieren el significado de instrumentos para la creación de contenido profesional, atractivo e interactivo para cursos de educación a distancia o e-learning (40).

La verdadera importancia y potencial de las herramientas de autoría yace en que proveen una manera sencilla, estructurada y consistente de mapear, transferir y persistir la mayor cantidad de conocimiento en personas expertas en el dominio al sistema, posteriormente esto da la capacidad de reutilizarlo y complementarlo de manera natural y progresiva extendiendo la base de conocimiento y capturando conocimiento adicional que de otras maneras puede ser muy dispendioso de recolectar.

3.6.1 Herramientas de Autoría Basadas en Ontologías En la actualidad se han propuesto varias aproximaciones al diseño y a la implementación de herramientas de autoría basadas en ontologías, especialmente desde las áreas de investigación del e-learning y la inteligencia artificial. La mayoría de herramientas propuestas, en principio, centran su atención en el ensamblaje, comunicación, presentación y definición de ontologías ortogonales al dominio propias de los procesos de la enseñanza y el aprendizaje cuyas preocupaciones generalmente son, por ejemplo: modelaje de estudiantes, secuenciación de curriculum, asuntos pedagógicos, calificaciones, entre otros, restando atención a la ontología del dominio específico tratando de abstraerla al máximo y tratando de ofrecer portabilidad y flexibilidad para cursos en diferentes dominios.

Castels y Macías (41) proponen herramientas de autoría para generación de páginas dinámicas que sirven como guías en un entorno educativo basado en la Web; mediante la construcción interactiva de ontologías e identificación de fragmentos de datos en páginas Web existentes. También presentan (42) un compositor gráfico que mediante una interfaz de usuario permite conectar diferentes bases de conocimiento basadas en ontologías con servicios web y adaptar el despliegue de información de acuerdo al dispositivo y al contexto del usuario. Murray (39) hace un análisis detallado de las herramientas de autoría en ITS (Intelligent Tutoring Systems), sistemas computarizados cuentan con modelos y estrategias que indican el cómo enseñar; muestra una clasificación según las capacidades que dichos sistemas tienen y los avances que ha presentado la investigación en esta área. Aroyo, Dicheva, et al (43) presentan un sistema basado en ontologías para soportar autoría en materiales educativos (courseware) por internet; con un enfoque multicapas, independiente del dominio y con miras a la elaboración colaborativas de cursos en línea. Por último y para dar una visión global, Devedzic (35) hace un análisis de la importancia de la Web Semántica en ambientes educativos y del impacto presente y futuro que podrían tener aplicaciones educativas basadas en la Web y prácticas actuales que se pueden implantar con miras a la adopción de tecnologías semánticas en entornos educativos.

Sin embargo la aproximación de KOC varía respecto al espectro de soluciones presentado anteriormente; ya que, pues las herramientas de autoría en KOC no pretenden ni fueron diseñadas para ser portables ni reutilizables en otros dominios.

3-9

Consecuentemente tampoco pretenden modelan recursos adicionales propios de la actividad pedagógica, siendo una de la las razones para ello es la falta de ontologías estándar en esta área. Las herramientas de autoría presentadas en este documento pretenden facilitar la captura del conocimiento en el dominio específico del área técnica en la arquitectura, construyendo un modelo de datos interno basado en la ontología, que a su vez permite asociar información adicional valiosa. Con este enfoque vemos el siguiente gran beneficio: No se sacrifica la semántica del dominio restringiendo la libertad del autor a un modelo interno ya establecido; por la misma razón se facilita la labor del autor quitándole responsabilidades y haciendo el proceso de autoría menos complejo.

El término herramientas de autoría y herramientas de composición se usan intercambiablemente a lo largo de este documento.

4-1

4 Solución Conceptual Propuesta La solución que se propone está basada en primera instancia en una serie de principios que se hacen parte de la estrategia general del proyecto. Luego se propone la especificación de una ontología, llamada ArCo, que permite estructurar y abstraer formalmente conceptos y relaciones del dominio del área técnica de la arquitectura. La segunda parte de la solución consiste en la formalización de un proceso para llevar a cabo el seguimiento y la recolección de datos en proyectos reales, siempre teniendo en cuenta la estructura planteada en ArCo. Posteriormente, complementando la función de ArCo y a partir de los datos recolectados en el proceso de seguimiento se propone la construcción de un repositorio de objetos de conocimiento, llamado KOC, en donde se anotan con base en la ontología los datos recolectados e ingresados al sistema. Por último se presenta una serie de herramientas de autoría que facilitan la labor a profesores de crear objetos pedagógicos de alto nivel compuestos de objetos de conocimiento simples.

4.1 Principios Desde los inicios del proyecto se han planteado una serie de principios que se tienen en cuenta al momento de tomar cualquier decisión de diseño o planificar nuevas funcionalidades, a lo largo de todos los niveles de la aplicación, desde la arquitectura hasta los requerimientos funcionales de alto nivel. Estos principios caracterizan a KOC como proyecto y muestran la visión que se tiene en cuanto a la utilización, estrategia y dirección futura del sistema. A continuación se menciona cada uno de ellos dando una pequeña descripción y sus principales características.

1. KOC sigue estándares. KOC se caracteriza por el cumplimiento con especificaciones y estándares tanto desde el punto de vista de la infraestructura tecnológica como desde los contenidos propios del dominio de la arquitectura. Algunos estándares que sigue KOC desde el punto de vista técnico hacen referencia a Java, JPA, SQL, OSGi, Java EE, OWL como se presenta en la sección 7.1. Desde el punto de vista de contenidos propios del dominio de la construcción en arquitectura se tomaron como referencia los mencionados en el capitulo anterior BS6100, MasterFormat, UniClass. Se planea soportar en el futuro el estándar SPARQL y otros nuevos estándares propuestos por organizaciones como la w3c para ser cada vez más compatible con tecnologías que lleven a la web semántica.

2. KOC es abierto. El desarrollo del proyecto ha sido completamente transparente y público, se han llevado a cabo varias presentaciones y publicaciones que así lo muestran, por otro lado se publican en la página oficial del sitio (44) las actas de las reuniones y el calendario de eventos. Inclusive desde la herramienta se proveen facilidades para participar de manera abierta en su crecimiento como el sistema de solicitudes, explicado en detalle en 5-7, y la página de contacto. Por otro lado, se planea con implementar el acceso programático a KOC mediante un API y de esta manera permitir a aplicaciones de terceros interactuar con los objetos de conocimiento presentes en KOC.

3. KOC es flexible. Dado que conocemos que es extremadamente difícil proveer todas las funcionalidades y datos que los usuarios del sistema puedan requerir en un determinado momento, desde su concepción KOC y ArCo están diseñados para ser extendidos. La arquitectura de KOC soporta este tipo de extensiones por medio de las herramientas de autoría que son componentes modulares que cuentan con funcionalidad específica y al mismo tiempo aprovechan el repositorio de objetos

4-2

existentes en KOC como insumo en la elaboración de objetos compuesto de mayor nivel conceptual.

4. KOC es intuitivo. La cantidad de esfuerzo puesto en el desarrollo de la interacción e interfaz de usuario es alto. Durante este proceso se ha buscado continuamente la manera más amigable para el usuario de interactuar con el sistema, esto ha llevado a varios rediseños que incluyen la actualización constante de paquetes gráficos, ver sección 7.1.9, nuevas maneras de visualizar la información, uso de técnicas avanzadas como Ajax para disminuir tiempos de interacción, entre otras.

5. Los contenidos de KOC son de calidad. Aunque este es uno de los principios más difíciles de cumplir y depende directamente de la utilización adecuada de cada usuario con el sistema; se han instaurado mecanismos que promueven la revisión colaborativa y le da facultades a usuarios administradores de intervenir en caso de encontrar elementos de baja calidad. Por otro lado con la definición formal del proceso de recolección de datos se fuerza a los recolectores de datos a cumplir con este principio.

6. KOC es seguro. La protección a la integridad de los datos es una preocupación clave de KOC, ya que de esto depende la confianza que depositen los usuarios en el sistema. Por otro lado para cumplir con este principio también es fundamental asignar responsabilidades y permisos a diferentes usuarios con roles específicos y garantizar que no se sabotee el sistema o dar la posibilidad de realizar cierta tarea a usuarios que no cuentan con esa competencia.

4.2 ArCo A lo largo de la evolución de la teoría de la arquitectura, han existido diversos intentos de estructurar su conocimiento a partir de diferentes sistemas, reflejados en la tratadística clásica. El común denominador de estos cuerpos de conocimiento es el plantear en primer lugar una aproximación compositiva a la compresión de su complejidad. Esto supone que el edificio, como totalidad, aparentemente indivisible, se puede descomponer en una serie de elementos, cuyo carácter puede ser constructivo, espacial o tipológico. Cuando se habla de elementos constructivos, se define una función técnica determinada dentro del edificio, como en el caso de una columna, una ventana, una viga, etc.; en el caso de los elementos espaciales supone una manera de ser ocupado o habitado el espacio según su función, como una oficina, un baño, un salón de clase, etc. En el caso tipológico el asunto se vuelve más complicado ya que se aborda la manera como están dispuestos y ordenados los espacios para que estos constituyan un “tipo” específico de edificio: por ejemplo como se disponen las habitaciones para que una casa o cualquier edificio se considere una tipología de patio. ArCo se enfoca pero no se restringe a la definición de conceptos relacionados a la construcción de edificios.

En primer lugar ArCo busca representar los conceptos arquitectónicos básicos expuestos en los tratados clásicos: Los elementos y los espacios. Esto obliga a definir las dos primeras relaciones importantes entre estos conceptos: Un espacio contiene elementos y es posible que a su vez contenga otros espacios siendo el edificio el espacio padre por excelencia.

El reto inicial, planteado por la problemática derivada de estos conceptos fundamentales, es determinar el conocimiento asociado que se quiere registrar y su estructura implícita, para la cual es necesario hacer un inventario mínimo de las aproximaciones al problema técnico en arquitectura, que han tenido diferentes autores. A partir de esta visión se debe armar una estructura finita de temas, que tenga la capacidad de representar la mayor cantidad de instancias, dentro del proceso de diseño y construcción de un edificio.

4-3

Se tomo la decisión de separar la producción de ArCo en dos fases, la primera consiste en la definición de los conceptos macro introducidos anteriormente, el resultado de esta fase consiste en una ontología de sólo clases llamada ArCo base. Al tener dentro de la ontología todas las instancias arquetípicas en ArCo base se habla de ArCo, a secas.

Figura 4-1 Representación visual de ArCo en Protégé

En conclusión, ArCo (Architectural Concepts) es una ontología que estructura la base de conocimiento en el área técnica de la arquitectura. Divide los conceptos en cuatro grupos, organizados alrededor de preguntas clave. El qué, hace referencia a los objetos de construcción que son el núcleo de la ontología y representan elementos y espacios arquitectónicos. El para qué, indica funcionalidades y grados de desempeño en tres categorías fundamentales: habitabilidad, estanqueidad y estabilidad. El dónde y el cuándo, por un lado ordenan cronológicamente las actividades dentro de la estructura de descomposición de trabajo (WBS) y por otro lado clasifica a los elementos por sistemas y subsistemas constructivos. El cómo, explica la escogencia de materiales, técnicas y equipos para la correcta construcción del elemento. En la Figura 4-1, se muestra la estructura jerárquica de sus conceptos y en la Figura 4-2, se muestra cada uno de los conceptos y sus relaciones de manera global.

4-4

Figura 4-2 Esquema conceptual de ArCo

4.2.1 El Qué. Objetos de Construcción La primera parte de la ontología busca definir la macro estructura del proyecto. Para esto se considera los objetos de construcción como el punto central a describir por medio de los otros conceptos de la ontología. Se definen los espacios y los elementos como los objetos de construcción básicos de la ontología. Es ideal que cualquier otra instancia de la ontología esté relacionada con mínimo un objeto de construcción, aunque se ha demostrado con algunos casos de uso que esta relación no es imperativa. Los objetos de construcción pueden tener unas dimensiones ideales de ancho, largo y alto que representan el volumen que ocupan. En términos de relaciones de pertenencia se modeló que los elementos pueden estar contenidos dentro de espacios y los espacios pueden estar contenidos dentro de otros espacios. Sin embargo a nivel de instancias ontológicas no es conveniente hacer esta asociación ya que la pertenencia de elementos en espacios y de espacios en otros espacios es dependiente del proyecto constructivo y sus características. En la Figura 4-3, se muestra el diagrama de clases UML respectivo a los objetos de construcción y sus relaciones.

Figura 4-3 Diagrama de clases para elementos y espacios

Los “Objetos Ideales” son un concepto que se maneja en KOC y que hace referencia a los objetos de construcción descritos en la ontología, se dice que son ideales o arquetípicos porque abstraen los componentes esenciales de todas sus instancias en proyectos reales

4-5

donde se utilizan, de esta manera al instanciar un objeto de construcción nuevo se toman las características descritas en el objeto ideal por defecto.

4.2.2 El Para qué. Funcionalidades y Grados Desempeño La segunda parte de la ontología busca representar, en primer lugar, las tres funciones básicas que debe cumplir un objeto de construcción, que no son otras diferentes a las que debe proveer cualquier edificio o espacio habitable (45).

Garantizar la estabilidad: Es una función derivada directamente de la existencia de la gravedad, los sismos, los vientos, los empujes de los fluidos y de los terrenos. Cualquier elemento, espacio o proyecto debe estar en capacidad de resistir estas variables impuestas por la naturaleza. Garantizar la estanqueidad: Esta función surge de la necesidad de controlar el ingreso del agua y las corrientes de viento dentro del edificio, para lo cual en necesario anteponer elementos y materiales que estén en capacidad de resistir y conducir el agua y el viento de forma inteligente a lo largo del edificio. Garantizar la habitabilidad: Es una función determinada por el hecho que los espacios son habitados por seres humanos, los cuales son sensibles a las variaciones de calor, del sonido, de la iluminación y de la humedad. Un elemento o un material deben aportar sus características para controlar las condiciones de habitabilidad del espacio interior y así garantizar que el ser humano pueda desarrollar sus actividades cotidianas.

A partir de estas tres posibilidades surge la primera cuestión alrededor de cada objeto de construcción: ¿Cuál es su grado de desempeño con respecto a cada función? Esto es más evidente revisando un ejemplo: claramente una columna estructural cumple un papel determinante en la estabilidad de un edificio, pero seguramente desde el punto de vista de la iluminación, su papel es claramente secundario. Por lo anterior, ArCo está en capacidad de indicar si el objeto de construcción tiene un papel central, complementario o indiferente con respecto a cada una de las funciones. Así, por ejemplo se definen para la función de estabilidad, los grados de desempeño no garantizar ningún tipo de estabilidad, garantizar exclusivamente su propia estabilidad, garantizar su propia estabilidad y hace parte de la estructura y como última opción ser un componente primario de la estructura.

En segundo lugar, dado que las tres funciones principales son demasiado generales para dar la verdadera dimensión del papel que cumple un elemento o espacio arquitectónico, ArCo propone una serie de funcionalidades específicas, que representan lo que se espera que el elemento “haga” para cumplir con la función establecida inicialmente. A partir de esta solución aparece una relación de causalidad clara: Si un elemento tiene un papel central, por ejemplo, en el sistema estructural, debe tener varias funcionalidades específicas, o sea, se espera que cumpla varios papeles desde el punto de vista estructural y ArCo tiene la capacidad de representar esta complejidad (15).

Igualmente, en este concepto en necesario diferenciar entre las funcionalidades específicas de los espacios y de los elementos. En el caso de los primeros, éstas dependen de la manera como el ser humano habita el espacio, o sea lo que espera el usuario que el espacio este en capacidad de proveer y en el caso de los elementos, éste aporta sus funcionalidades al espacio que está conformando. De lo anterior se deduce otra relación de causalidad: Si el usuario espera que un espacio tenga un buen aislamiento acústico, es deseable que los elementos que lo conforman tengan funcionalidades que aporten aislamiento acústico (15).

4.2.3 WBS. Work Breakdown Structure La WBS (Work Breakdown Structure) o estructura de descomposición del trabajo, es una estructura arborescente de capítulos, subcapítulos, operaciones y tareas que en primer

4-6

lugar clasifica los elementos constructivos por su función en el edificio y en segundo lugar ordena cronológica y secuencialmente las actividades que deben ser llevadas a cabo dentro del proceso constructivo del mismo elemento.

Para la definición de esta WBS se hizo un estudio general de otros sistemas clasificatorios de procesos constructivos existentes como BS6100 (28), Master Format (29) y UniClass (30). Se optó por completar la WBS unificada propuesta en el marco del Magíster en Ingeniería Civil de la Universidad de los Andes (10), pues responde claramente al orden y especificidad del medio local y garantiza la articulación con los sistemas presentados a continuación.

La organización de esta nueva WBS permitió integrar dentro de la misma estructura a los elementos arquitectónicos y los sistemas, Esta integración permite que al ubicar un elemento arquitectónico dentro de la WBS, se está definiendo de forma simultánea QUÉ elemento es, DÓNDE está ubicado (sistema y subsistema) y finalmente CUÁNDO ocurre en el tiempo de la siguiente manera.

El primer nivel de la WBS corresponde a los sistema generales del edificio; el segundo nivel corresponde a los subsistemas, los cuales definen grupos de actividades que cumplen una misma función (dentro del sistema estructural, hay subsistemas que representan la construcción de la cimentación, la superestructura, etc.). El nivel de elementos refleja el desglose real que demanda el desarrollo del trabajo en una obra (dentro del subsistema de construcción de la superestructura, aparece la operación de construcción de una columna, como elemento arquitectónico). Finalmente el nivel de tareas define los pasos para construir este elemento.

4.2.4 El Dónde. Sistemas y Subsistemas en la WBS En esta sección de la ontología se toma como referencia la teoría general de integración de sistemas (46), que propone ordenar el edificio a partir de cuatro sistemas principales y definir las relaciones de proximidad e interdependencia de estos. A la vez cada uno de los sistemas está dividido en subsistemas que apoyan las funciones del sistema principal, conformando una jerarquía, relativamente sencilla que se muestra a continuación en la Tabla 1 Inventario de sistemas:

Tabla 1 Inventario de sistemas

Sistema Objetivo Subsistemas

Sistema estructural Dar soporte general del edificio

Cimentación, Contención, Superestructura, Consolidación y Actualización sísmica

Sistema de Cerramiento Exterior

Manejar todo lo que implican los elementos naturales Fachadas, cubierta y espacio público

Sistema de Cerramiento Interior

Definir y caracterizar los espacios interiores del edificio

Particiones, cielos rasos, pisos falsos, puertas y muebles

Sistema Mecánico

Manejar todo lo que implican infraestructuras y servicios

Hidráulico de suministro, Hidráulico de incendios, Desagüe de aguas negras, Desagüe pluvial y freático, Suministro

4-7

eléctrico, Ventilación, Calefacción y refrigeración, Conducción de voz y datos, Seguridad y automatización, Evacuación de emergencia, Transporte vertical y horizontal y Evacuación de residuos sólidos

Los sistemas y subsistemas son los dos primeros niveles de clasificación de elementos y puntos de partida de una WBS respectivamente.

4.2.5 El Cuándo. Actividades en la WBS Define el momento en que debe llevarse a cabo la construcción de un elemento constructivo, dentro de una línea de tiempo general de actividades secuenciales que idealmente se llevan a cabo en el proceso constructivo estándar del elemento. En la Figura 4-4 se puede observar la estructura tipo árbol de la WBS expandido en el sistema estructural, subsistema de cimentación, el elemento constructivo Caisson y finalmente el listado de actividades necesarias para la construcción ideal de un Caisson.

Figura 4-4 Sección del árbol de la WBS

Esta WBS se completó y amplió con el fin de abarcar la totalidad del ciclo de vida del proyecto, incluyendo sus etapas iníciales, así como las etapas posteriores al proceso de diseño y construcción. De manera que las actividades cuentan con un atributo que indica el ciclo de vida en que deben ser llevadas a cabo (pre-factibilidad, factibilidad, diseño, construcción, operaciones y mantenimiento y deconstrucción).

4.2.6 El Cómo. Materiales y Equipos

4-8

En esta sección de la ontología se examina cómo se construye el objeto de construcción y se tiene en cuenta la escogencia adecuada de los materiales, las técnicas de construcción y los equipos con los que se construye. Se toma como referencia en primer lugar la clasificación de los materiales a partir de su composición física y en segundo lugar sus presentaciones a partir de la forma como llegan a la obra y entonces se define la técnicas que permite su transformación (47). El formato de presentación en la obra se clasifica en cuatro grandes grupos como lo muestra la Tabla 2 Formatos de presentación.

Tabla 2 Formatos de presentación

Formato de Presentación

en la Obra Descripción Ejemplo de

Presentaciones

Amorfo Materiales que carecen de forma específica arena, cemento, pinturas

Pequeños elementos

Materiales que ya sufrieron una primera transformación en su forma y su tamaño permite que sean cargados por un operario, y para construir un elemento es necesario unir varias unidades

ladrillos

Semiproductos Materiales que ya sufrieron varias transformaciones a nivel industrial y su aplicación en obra demanda modificaciones leves

rollos de alfombra, mantos de impermeabilización, mallas

Componentes Materiales totalmente prefabricados que no sufren ninguna transformación para ser utilizados en la obra

Inodoros, lavamanos, ventanas.

Las técnicas de construcción apropiadas para un elemento de construcción dependen directamente del tipo de material y de su formato de presentación. El moldeo y el tendido son las técnicas básicas para los materiales amorfos. La conformación es la técnica básica para los pequeños elementos. El corte y la fijación permiten transformar y fijar los semiproductos; y desde luego la fijación es la técnica básica para la instalación de componentes. ArCo establece las relaciones necesarias para asignar las técnicas apropiadas a cada tipo de material y formato de presentación.

Finalcon ontoldirec

• Siun

• Mcone

• Hse

Figura 4-6

lmente los elos materialogía. Paractamente co

imples: Equn balde, un

Mecánicos: Eompresoreseumático, e

erramientaserrucho, un

Figura 4-5

Visualización

equipos de ales, estána facilidad on su grado

uipos que cparal, una

Equipos ques, como el cetc.

s: Equipos d“bichiroque

Diagrama d

n del árbol d

construcció relacionadde uso se de complej

cumplen pacruceta, etc

e cumplen caso de un

de manipulae”, una pica

4-9

de materiales

de materiales

ón, como ados directae propone jidad:

apeles estátc.

funciones ana grúa, un

ación directa, una pala,

s, técnicas y p

s, presentacio

poyo directmente conclasificarlo

ticos en el

apoyadas pmolinete, u

ta por lo opetc.

presentacion

ones y el lista

to a las ope cada técns en tres

procesos, c

or principioun cargado

perarios, com

nes

tado de técni

eraciones renica a travétipos, relac

como es el

os físicos, mor frontal, un

mo es el ca

icas

ealizadas és de la cionados

caso de

motores o n taladro

aso de un

4-10

4.3 Levantamiento de información de los proyectos arquitectónicos

El levantamiento de información de los proyectos arquitectónicos consiste en el registro y la captura de los hechos a lo largo del ciclo de vida de construcción en una obra real, como resultado de esta captura se genera una serie de material que refleja el estado del proyecto en determinados momentos o muestra actividades y metodologías utilizadas que fueron llevadas a cabo.

Es una de las actividades más importante de todo el proyecto, ya que los materiales recolectados representan los datos base para ingresar en el repositorio KOC y en caso de no tenerlos se pierde el objetivo principal de construcción de conocimiento a partir de la información generada por la construcción de los edificios reales. Es una tarea bastante dispendiosa y debe llevarse a cabo con mucho cuidado, también es necesario implantar controles de calidad con el objetivo de satisfacer los requerimientos de los diversos usuarios de esta información.

El siguiente es el inventario inicial de actividades, desarrollado por Vela (5), para llevar a cabo en el proceso de levantamiento de información.

• Compra de equipos fotográficos de alta definición, con el fin de garantizar el registro de calidad de las diferentes actividades del proyecto.

• Conformación de un equipo de trabajo que incluye, por lo menos, un arquitecto senior como coordinador del proyecto, un arquitecto junior y un realizador de video profesional

• Definición del plan de recolección de material, a cargo del arquitecto senior. Determina cuáles son los procesos específicos de obra que quieren documentarse, cuándo y cómo debe ser su seguimiento: fotográfico, fílmico, time-lapse, etc.

• Coordinación de los turnos de visitas con las facultades de la Universidad de los Andes y otros visitantes, de acuerdo con el plan de generación de material.

• Seguimiento fotográfico de procesos específicos de la obra.

• Seguimiento fílmico de procesos específicos de la obra, incluyendo explicaciones de los encargados de la obra.

• Ubicación de los planos para la toma de videos time-lapse según instrucciones de la coordinación del proyecto.

• Generación de una bitácora del proyecto interactiva, donde se consigne la información relevante, a partir de la ontología ArCo.

• Generación de un archivo documental del proyecto, articulado con la bitácora interactiva, con miras a la consulta futura por parte de estudiantes y profesores, basado en ArCo.

• Realización de las visitas guiadas, incluyendo la presentación inicial y el acompañamiento de los grupos.

• Generación de los Objetos de Conocimiento en Construcción y su ingreso al repositorio de KOC, debidamente anotados según la ontología ArCo

Desde el año 2005 se han desarrollado varias experiencias de seguimiento de las actividades anteriormente descritas dentro del proyecto KOC, las cuales han sido determinantes para su evolución, aprovechando algunas oportunidades de seguimiento

4-11

de procesos constructivos, generadas directamente en la construcción del campus de la Universidad de los Andes.

Como se muestra en el estado actual del proyecto 8-1, este proceso formal de recolección se ha puesto a prueba en los proyectos de construcción del Edificio Mario Laserna durante años pasados y en los edificios Nuevo W y Centro Cultural y Deportivo de la Universidad de los Andes.

4.4 KOC. Definición de conceptos KOC es un repositorio de objetos de conocimiento en construcción para el área técnica en arquitectura. Sus funcionalidades más importantes consisten en permitir accesos de consulta, adición y edición colaborativa de datos, objetos de conocimiento y anotaciones para estudiantes, profesores y arquitectos profesionales manejando el control de acceso por medio de la asignación de roles para cada uno de sus usuarios.

KOC se compone de varias partes fundamentales: La implementación y administración de la ontología ArCo, el soporte al proceso de seguimiento y recolección de datos mediante su ingreso y anotación en términos explícitos de la ontología (en algunos casos también con información adicional), la administración de estos datos teniendo en cuenta propiedades auxiliares que facilitan la clasificación, búsqueda y regulación de la información, las consultas de alto nivel sobre el repositorio y un conjunto de herramientas de autoría que permiten a los expertos en el dominio generar objetos compuestos de alto nivel. Cada una de estas partes es de vital importancia y el funcionamiento simultáneo de todas ellas en conjunto se refleja proporcionalmente en la utilidad misma del sistema.

A continuación se presentan sus conceptos más importantes: datos, objetos de conocimiento, anotaciones y proyectos.

4.4.1 Datos Los datos son uno de los componentes principales de KOC ya que reflejan visualmente los objetos de conocimiento almacenados en el sistema. Los datos se constituyen de un archivo adjunto que se sube al repositorio más una serie de metadatos que serán explicados a continuación. Cabe resaltar que la pertenencia de un dato dentro de un proyecto de construcción (incluyendo el proyecto teórico) es obligatoria, ya que es muy importante tener en cuenta el contexto proveído por la información registrada del proyecto para entender los contenidos del dato y evitar que KOC se convierta en un sistema manejador de archivos aislados unos de otros.

Figura 4-7 Esquema de datos, metadatos y archivos

4-12

4.4.2 Metadatos Los metadatos en el marco de este proyecto se definen como información adicional asociada un dato que sirve para describirlo, identificarlo o monitorearlo. Como primer metadato importante se tiene el registro de la fecha y hora de ocurrencia del dato, en caso de contar con ellas; esta información de carácter temporal sirve para contextualizar el dato y compararlo con otros de acuerdo a su tiempo de ocurrencia, por ejemplo es fundamental en el módulo de procesos constructivos ya que influye en el orden en el que se realizaron las actividades, ver sección 4-18. Para mayor información sobre el uso del registro de fechas vea el capítulo 5.4.55-10.

También es importante especificar o inferir aspectos relevantes al archivo que acompaña al dato, estos aspectos se resumen en: el formato del archivo, el tamaño en bytes del archivo y el tipo de dato. Los dos primeros se pueden inferir de acuerdo a la extensión y al peso detectado durante la carga, son importantes porque dan una noción del posible tipo de contenido y su tamaño. En el caso del tipo de dato puede ser acotado por el formato identificado, de esta manera por ejemplo se puede decidir entre si un archivo JPEG representa una fotografía o un diagrama. El tipo de dato pretende ser utilizado en el futuro para determinar el LRT (Learning Resource Type) siguiendo la especificación LOM, ver sección 10.2.2 en el trabajo futuro.

Por último se tiene un espacio de texto libre para mostrar la descripción en términos de detalles adicionales o aspectos relevantes que no hayan sido recolectados por la herramienta o simplemente para dar explicaciones o mostrar el énfasis que se está dando al dato. En la Figura 4-8, se muestra la interfaz de usuario para ingresar un nuevo dato.

Figura 4-8 Formulario de dato

4.4.3 Objetos de Conocimiento Los objetos de conocimiento son entidades de alto nivel que extienden a los datos simples recolectados, indicando información adicional y anotaciones, que pueden ser vistas como valor agregado en términos de conocimiento. Los objetos de conocimiento se relacionan con uno o varios datos que actúan como componente de visualización (por ejemplo una fotografía o un video), se ubican dentro de una etapa del ciclo de vida constructivo (por ejemplo diseño, operaciones o construcción), tienen un nivel de anotación que indica la

4-13

granularidad o enfoque con la cual se está describiendo el dato (por ejemplo a nivel de subsistema, elemento, material), pueden tener asociada una calificación global cualitativa que indica qué tan bien o qué tan mal se está llevando a cabo la práctica en general que se muestra en el objeto de conocimiento. Finalmente y como componente esencial se tienen las anotaciones que lo describen.

4.4.4 Anotaciones Las anotaciones son relaciones entre los conceptos definidos en la ontología ArCo y los datos recolectados de proyectos reales. Las anotaciones son el puente que une las instancias arquetípicas o ideales definidas en ArCo y los objetos constructivos del mundo real almacenados en KOC. Las anotaciones van a mostrar por defecto las características que se especifique en el objeto ideal, asumiendo que el objeto del mundo real que se quiere anotar cumple con las especificaciones presentadas en la ontología. Las variaciones entre la definición arquetípica y el caso concreto en el mundo real se van a almacenar como fuente de posibles malas prácticas.

Además de contener las referencias de la entidad ontológica al dato tomado del mundo real, las anotaciones pueden contener información adicional que enriquezca al objeto de conocimiento, por ejemplo: al especificar las funcionalidades y grados de desempeño que presenta un elemento respecto a la habitabilidad, estanqueidad y estabilidad de un espacio, es posible asociar una calificación más precisa que indica qué tan bien o qué tan mal se están cumpliendo con los objetivos funcionales planteados en un principio; así mismo cuando se anota un objeto de construcción sus dimensiones alto, largo y ancho pueden ser muy relevantes. A continuación en la Figura 4-9, se presenta el diagrama de clases UML utilizado para la implementación del modelo de anotaciones.

Figura 4-9 Diagrama de clases de las anotaciones

La clase Anotación es el componente principal y sirve como abstracción a las demás clases (que a su vez la extienden) ella contiene la referencia al objeto de conocimiento. Existen varios tipos de anotaciones que mediante su relación con otras adquieren un significado más dependiente del contexto y prestan a un mayor potencial de análisis, como es el caso de los materiales que se relacionan con el elemento al que pertenecen, al igual que las funcionalidades y grados de desempeños con que cuenta el objetos de construcción y también los equipos que son utilizados en las actividades. También existe la posibilidad de vincular los elementos que están contenidos dentro de un espacio usando el mismo mecanismo.

4-14

En la interfaz de usuario se presenta al anotador una interfaz gráfica para lograr este propósito. La interfaz permite al usuario arrastrar y soltar (drag and drop) cada una de las anotaciones realizadas relacionándolas con las anotaciones contenedoras que apliquen. En la Figura 4-10 se muestra un ejemplo de anotación de un objeto de construcción, más específicamente se muestra la asignación de funcionalidades y grados de desempeño.

Figura 4-10 Interfaz de anotación de un objeto de construcción

4.4.5 Proyectos La unidad contenedora con mayor visibilidad en KOC es el proyecto. Dado que los datos son capturados durante la realización de un proyecto de construcción, esta se convierte en la fuente principal que agrupa los datos. KOC se limita a recolectar información básica del proyecto desde varios puntos de vista que se explican a continuación: Información temporal, mediante la especificación de una fecha de inicio y una fecha final en cuanto a la ejecución del proyecto, de allí se obtiene el tiempo de duración total. Información de localización, seleccionando la ciudad, el país donde se construye el proyecto y para mayor precisión las coordenadas, en el capítulo 5.4.4 se presenta mayor información relacionada con la georeferenciación de proyectos. Información de clasificación, se constituye en identificar el tipo de proyecto según su uso destinado (por ejemplo vivienda unifamiliar, edificio educativo, edificio gubernamental) y una ficha técnica bastante simplificada con medidas del área, el número de pisos y el sistema de unidades.

Figura 4-11 Formulario de proyecto, ejemplo nuevo edificio W

4-15

4.4.5.1 Proyecto Teórico Debido a la naturaleza de KOC en muchos casos es imposible asociar un dato a un proyecto, en especial datos no recolectados durante la construcción de un edificio. Datos netamente académicos como ensayos, artículos, libros sí tienen cabida en KOC y por ende pueden ser anotados como cualquier otro objeto de conocimiento, lo mismo sucede con materiales informales como entrevistas, diagramas, bocetos cuyos contenidos pueden representar un gran valor pedagógico. Por este motivo fue creado el proyecto teórico, proyecto en el cual no se tiene ninguna información asociada como proyecto Perse pero que agrupa todos los datos teóricos existentes en el sistema distinguiéndolos de datos recolectados o utilizados en proyectos reales.

Figura 4-12 Ejemplo de un dato perteneciente al proyecto teórico. Muestra un plano general de ejes

4.5 Herramientas de autoría para KOC La versión inicial de KOC únicamente permitía la anotación e ingreso de objetos de conocimiento en construcción únicamente de manera atómica. Es decir, cada objeto era completamente individual y no estaba relacionado con ningún otro. Una posible evolución de KOC pudo haber consistido en lograr definir y manejar relaciones entre estos objetos "simples" de conocimiento, construir así objetos de conocimiento de mayor nivel conceptual y por último ingresarlos al repositorio de conocimiento. Dependiendo de las relaciones que se quisieran adicionar, la generación de estos nuevos objetos complejos de conocimiento podría ser bastante difícil y dispendiosa para los generadores de conocimiento. Con el fin de facilitar este proceso, se propone la construcción de herramientas de autoría que, apoyadas en ArCo, permitan la creación e incorporación de contenido de alto nivel al repositorio de KOC de manera sencilla, clara y a la vez expresiva para los autores.

En este documento se presentan tres herramientas de autoría que pretenden facilitar la labor de los autores en el sistema KOC y como resultado mejorar la calidad de la enseñanza en las facultades de arquitectura: un compositor de objetos compuestos a partir de búsquedas estructuradas, basadas en las clases e instancias especificadas en la ontología ArCo, un compositor de procesos constructivos basado en las actividades a llevar a cabo para la elaboración de los elementos de construcción que a su vez son instancias del tercer nivel de la WBS, especificada en ArCo, y por último la herramienta de autoría más compleja y con mayor potencial en términos de expresividad y didáctica: un compositor de casos de estudio.

4-16

Cada una de las herramientas de autoría se presenta de la siguiente manera: se inicia con la descripción general y los objetivos, luego se definen quiénes son los usuarios y su nivel de interacción con la herramienta, más adelante se define cuál es el proceso de autoría y finalmente se examina cómo cada herramienta hace uso de la ontología ArCo seguida de un ejemplo concreto.

4.5.1 Compositor de Objetos Compuestos Basados en ArCo El compositor de objetos compuestos es una herramienta de autoría que, basándose en la estructura definida en la ontología ArCo mediante búsquedas estructuradas a las anotaciones presentes en el repositorio de datos KOC, vincula diferentes objetos de conocimiento existentes (simples) y los agrupa en un nuevo objeto de conocimiento compuesto, cuya generación es automática; pero puede ser editada posteriormente por el autor para describir más precisamente los contenidos del objetos compuesto.

Parte del proceso de autoría está en la selección cuidadosa de un subconjunto de los resultados arrojados por el sistema al momento de hacer la búsqueda estructurada, la otra parte fundamental del proceso consiste en proveer semántica generalizada que aplica al grupo de datos seleccionados y se almacena en el objeto compuesto.

La consecuencia inmediata del uso de esta herramienta consiste en el aumento de la reutilización de objetos existentes en el repositorio, generando redes de encadenamiento semántico entre ellos.

4.5.1.1 Objetivo El objetivo principal de esta herramienta es agrupar sistemáticamente objetos de conocimiento simples que comparten características similares (mediante la consulta de sus anotaciones) para formar un objeto de alto nivel con fines pedagógicos, que puede ser presentado en un salón de clase o consultado por internet según las indicaciones del profesor. Otro propósito de la herramienta puede ser responder a preguntas comunes que se hace el arquitecto profesional al momento de construir, desde el punto de vista del profesor, con ejemplos concretos presentes en el repositorio.

4.5.1.2 Usuarios El uso de esta herramienta de autoría está dirigido a los profesores. Ellos realizan búsquedas de acuerdo a los conceptos de la ontología para introducir una temática en clase o para mostrar ejemplos en el mundo real de un concepto ontológico. Los demás usuarios podrán consultar los objetos compuestos generados y utilizar el mecanismo de solicitudes, explicado en 5-7, para sugerir cambios, modificaciones o creación de nuevos objetos compuestos.

Los usuarios de esta herramienta deben ser conscientes de cuál es el aporte que se está generando al crear el objeto compuesto y deben saber que una mala utilización de ésta puede resultar en inconsistencias y restar significativamente el nivel de calidad en los datos.

4-17

4.5.1.3 Proceso

Figura 4-13 Proceso para el compositor de objetos compuestos

En la Figura 4-13, se muestra cada uno de los pasos del proceso de utilización de esta herramienta. Como primera instancia el usuario de la herramienta debe proveer al sistema los criterios de búsqueda basados en la estructura de ArCo: material, elemento, espacio, funcionalidad, grado desempeño por ahora. Luego es preciso indicar que tipo de restricción lógica existe entre los criterios, conjunción o disyunción (por ejemplo funcionalidad A y espacio B, elemento C o material D).

Dadas estas entradas es suficiente para realizar la búsqueda sobre los datos existentes a partir de la información almacenada en las tablas de anotaciones presentes en KOC, siempre y cuando cumplan con los criterios y restricciones. Se lleva a cabo el proceso de búsqueda y a partir de los resultados arrojados, el usuario elige cuáles de éstos se ajustan al objeto compuesto que quiere crear y cuáles no.

Posteriormente el autor debe complementar la creación del objeto compuesto con un título, una descripción y asociarle una etapa del ciclo de vida de forma general y que aplique a todo el conjunto de resultados elegidos; opcionalmente puede enriquecer el objeto compuesto con una calificación cualitativa.

Una vez se envían los datos, se procede con la creación del objeto de conocimiento compuesto anotado según los criterios anteriormente mencionados; adicionalmente se generan las relaciones entre él y los objetos de conocimiento simples, de los datos que habían sido seleccionados en los resultados de la búsqueda.

Por último, la herramienta genera automáticamente un archivo tipo presentación con su información de autoría, el cual es asociado al objeto de conocimiento compuesto. Dicha presentación compila toda la información de los resultados y del objeto compuesto en diapositivas, una por dato más la portada que lleva el título del objeto de conocimiento compuesto. Vale la pena mencionar que el objeto compuesto es persistente y puede ser actualizado o eliminado por el autor.

4.5.1.4 Utilización de ArCo Los criterios de búsqueda se traducen directamente en instancias de clases definidas en la ontología ArCo, en la versión actual se soportan búsquedas estructuradas por elementos, espacios, materiales, funcionalidades y grados de desempeño.

4-18

4.5.1.5 Ejemplo En la Figura 4-14, se presenta un esquema del uso de esta herramienta.

Figura 4-14 Esquema del Compositor de Objetos Compuestos

En este ejemplo se lleva a cabo una búsqueda del elemento Zapata Corrida en el espacio Edificio que debe cumplir con la funcionalidad de asumir cargas verticales. Como resultado de esta búsqueda se arrojan objetos de conocimiento de la construcción de la Zapata Corrida en el edificio Mario Laserna, los cuales son relacionados por medio del objeto de conocimiento compuesto que se visualiza en forma de presentación.

4.5.2 Compositor Procesos Constructivos Un proceso constructivo es una secuencia de actividades ordenadas cronológicamente, en las que, como resultado final de su ejecución, se tenga un objeto de construcción terminado. El compositor de procesos constructivos es una herramienta para la generación de objetos compuestos tipo proceso constructivo mediante la asistencia al autor en el ingreso de múltiples objetos simples que componen el proceso, cada una de sus actividades. Además la herramienta recoge información adicional propia del proceso como su duración, personal involucrado, calificación cualitativa y orden en el que se llevaron a cabo las actividades. Adicionalmente, la herramienta genera una presentación con fines pedagógicos para mostrar diapositiva a diapositiva cada una de las actividades que se llevaron a cabo durante el proceso.

Vale la pena anotar que el compositor de procesos constructivos restringe a una sólo nivel la anotación del objeto compuesto, proceso constructivo de un elemento. En la sección 10.2.4 del trabajo futuro se plantea la idea del desarrollo de una herramienta de autoría diferente para procesos constructivos de espacios.

4.5.2.1 Objetivo El objetivo de esta herramienta está en hacer más fácil y rápido el registro de procesos constructivos, reutilizando la mayor cantidad posible de información redundante o ya dada, con miras a ahorrar tiempo al autor. La motivación de esta herramienta parte de la manera en que se definió el proceso de recolección de datos, presentado en 4-10, y la definición misma de la WBS, en la que se agrupan las actividades por proceso constructivo de su elemento.

4-19

4.5.2.2 Usuarios El uso de esta herramienta está dirigida a los anotadores, ya que ellos son los encargados del ingreso de datos al sistema y se ven beneficiados directamente, al acelerar el proceso de subida de datos y asistir en varios pasos durante el proceso de anotación.

4.5.2.3 Proceso

Figura 4-15 Proceso de generación de procesos constructivos

La Figura 4-15, muestra el proceso de utilización del compositor de procesos constructivos. El primer paso consiste en indicar el elemento al que hace referencia el proceso constructivo. Luego se procede a la consulta en ArCo de las actividades "por defecto" registradas en la ontología para este proceso.

El autor puede eliminar actividades que no apliquen así como también puede cambiar el orden de las actividades realizadas según lo haya requerido su práctica real. Por cada actividad el autor crear un nuevo dato para la actividad y opcionalmente completa su anotación. Este ciclo de adición y anotación de actividades se repite una y otra vez hasta que toda la información se haya completado.

Posteriormente se ingresan los datos generales al proceso constructivo como: en qué proyecto se realizó, cuál es el ciclo de vida o a que etapa pertenece y una descripción global, también la información adicional a nivel de proceso explicada anteriormente, como el número total de personas y la calificación del proceso como valoración de las prácticas en él.

Una vez se envían los datos, se procede con la creación del objeto de conocimiento compuesto y la relación de éste con los objetos de conocimientos simples de cada una de las actividades. Finalmente la herramienta genera un archivo tipo presentación que es asociado al objeto de conocimiento compuesto. Los procesos son persistidos y pueden ser actualizados o eliminados por su autor.

4.5.2.4 Utilización de ArCo Para especificar el elemento y mostrar sus actividades es necesario consultar la estructura de la WBS, como se mostró anteriormente ésta corresponde a una clase ontológica. De la misma manera las anotaciones de las actividades se hacen con base a la estructura de la ontología.

4-20

4.5.2.5 Ejemplo En la Figura 4-16, se muestra un esquema que sirve de ejemplo para el uso de la herramienta.

Figura 4-16 Esquema del Compositor de Procesos Constructivos

El ejemplo consiste en el ingreso al repositorio del proceso constructivo de un Caisson durante la construcción del Edificio Mario Laserna. El Caisson es un elemento del sistema estructural que brinda el componente de cimentación a un edificio. El ejemplo muestra los tres primeros pasos de este proceso que consisten en la excavación, armado de refuerzos y colocación de formaletas. Estas actividades son relacionadas con el elemento Caisson y su anotación al igual que con objeto de conocimiento compuesto del proceso.

4.5.3 Compositor Casos de Estudio Un caso de estudio es "una descripción de una situación desde la perspectiva del protagonista" (48), que sirve como metáfora para enseñar al estudiante a resolver problemas de tipo general, que tienen el mismo núcleo (49). El compositor de casos de estudio es una herramienta informática que permite a los profesores, de los cursos del área técnica en arquitectura, estructurar sus casos de estudio mediante la composición del árbol de situaciones (nodos) y las transiciones (vértices), que conectan una situación a otra, obteniendo como resultado un grafo dirigido finito determinístico, no cíclico.

La herramienta como resultado de la composición del caso, genera un archivo PDF con la información general y el inventario de situaciones. Este archivo puede ser descargado o consultado por los usuarios de KOC.

Esta herramienta de autoría es mucho más compleja que las dos presentadas anteriormente, ya que internaliza la metodología pedagógica de los casos de estudio en su modelo de datos.

4.5.3.1 Objetivo El objetivo principal de la herramienta es ayudar a los profesores a estructurar sistemáticamente conocimiento en forma de casos de estudio, aprovechando los contenidos existentes en el repositorio KOC para ilustrar las situaciones planteadas. Los casos de estudio manejados por la herramienta pueden ser extendidos, complementados o vinculados con otros por diversos autores en un ambiente colaborativo.

4-21

Mediante el uso de la herramienta se utiliza el vocabulario propuesto en ArCo para capturar y persistir la mayor cantidad posible de conocimiento de los profesores en un formato pedagógico que puede ser reutilizado. Al seguir la metodología de casos de estudio se promueve la pedagogía Socrática (50), es decir, el aprender haciendo.

También busca reutilizar el conocimiento producido en escenarios de construcción reales y explotarlo al máximo en el salón de clase, usándolo como ejemplo y creando una red de relaciones entre materiales pedagógicos y conocimiento práctico.

4.5.3.2 Usuarios Esta herramienta está dirigida a profesores, ya que son ellos los autores de los casos de estudio, así mismo los encargados de la actualización y mantenimiento del mismo. Los estudiantes juegan un rol pasivo y no tienen ninguna interacción directa con la herramienta, aunque sean en última instancia los consumidores del caso de estudio.

4.5.3.3 Proceso

Figura 4-17 Proceso del Compositor de Casos de Estudio

En la Figura 4-17, se muestra el proceso de utilización de la herramienta compositor de casos de estudio. Como primer paso se debe proveer la información general al caso, ésta se compone de un titulo, el taller o curso donde se presenta el caso, el tipo de caso según Martínez (8), un resumen y un objetivo pedagógico, así como puede tener opcionalmente enunciados los objetivos generales y específicos que se buscan al resolver el caso.

El desarrollo del caso busca resolver una problemática para un concepto asociado a una instancia de la ontología ArCo, así que esta instancia se selecciona (actualmente sólo aplica para nodos de la WBS).

Aparte de la información general, un caso de estudio está compuesto por un conjunto de situaciones. El proceso de adición de cada situación consiste en: identificar y contextualizar la situación, mediante un título y asociando un objeto de conocimiento tomado del repositorio KOC (para ilustrar la situación en un escenario conocido), definir si

4-22

la situación corresponde a un estado inicial, intermedio o final, valorar la situación en una escala de calidad como mala, buena u óptima.

Al final de cada situación, el autor puede plantear una pregunta sobre cuál debe ser la transición a la siguiente situación. Como opciones para responder esta pregunta el autor define un conjunto de alternativas, que llevan consecuentemente a otras situaciones. De este modo se articulan y se conectan las situaciones controlando la navegabilidad del caso de estudio y finalmente dando origen a la estructura tipo grafo explicada anteriormente. El autor puede crear tantas situaciones como crea necesario, según la complejidad o tamaño del caso.

Una vez enviada la información general y el inventario de situaciones/alternativas se procede a crear el objeto compuesto del caso de estudio. Se generan además, las relaciones entre él y los objetos de conocimiento de los datos que se usaron como ilustraciones en cada situación. Posteriormente la herramienta genera automáticamente un archivo tipo documento PDF que es asociado al objeto de conocimiento compuesto. Este documento contiene la información general del caso más el inventario de situaciones. Los casos de estudio pueden ser actualizados o eliminados por su autor.

4.5.3.4 Utilización de ArCo La problemática presentada en el caso se refleja en un concepto de ArCo (por ahora un nodo del árbol de la WBS a cualquier nivel) y su objeto de conocimiento compuesto se anota como tal. Por otro lado cada una de las situaciones del caso hace referencia a un objeto ontológico dentro de ArCo (por ahora funcionalidades, materiales y equipos), ya sea en la contextualización de la situación o en la formulación de la pregunta.

4.5.3.5 Ejemplo

Figura 4-18 Árbol de decisión caso de estudio para elemento fachada

En la Figura 4-18, se presenta el esquema de uso de la herramienta de autoría compositor de casos de estudio para la estructuración del caso de estudio presentado por Villazón (51). El ejemplo muestra el proceso de toma de decisiones al momento de decidir cómo construir una fachada. Se organiza a partir de tres grupos de decisiones secuenciales, que tienen que ver directamente con tres temas generales que aborda la técnica en arquitectura: la forma y composición, ¿cómo se verá lo que se propone? Lo

4-23

técnico, ¿cómo se garantiza que la forma responda a las condiciones de la naturaleza? y por último la localización, ¿cómo el elemento se especializa según su ubicación?

Se puede observar el primer grupo de preguntas, que determina la forma que el estudiante espera obtener; así tendrá que decidir si la fachada se verá visualmente pesada o liviana, lo cual no necesariamente está relacionado con el peso físico de los materiales con los que se construye. La siguiente decisión tiene que ver con la continuidad del plano de fachada: hay perforaciones o se ve como una piel continua. En cualquiera de los dos casos, es necesario que el estudiante determine en un primer intento por proyectar lo que quiere que sea la fachada del edificio, las capas que arman la fachada, sea una o varias. Finalmente, se pide asumir un compromiso determinante para la forma: La relación que tendrá el plano de fachada con la estructura portante del edificio. Bajo este concepto, las opciones para el estudiante son:

• Que la forma de la fachada prime sobre la estructura, o sea que esta última debe modificar su forma para preservar la forma de la fachada a toda costa.

• Que la forma de la fachada y la estructura sean independientes.

• Que la forma de la estructura prime sobre la de la fachada.

Al final de este proceso sugerido al estudiante, ya hay un resultado formal que él y el profesor deben evaluar frente a la totalidad del proyecto ya que ningún elemento en un edificio es autónomo a la voluntad general que propone el arquitecto. El siguiente paso es que el estudiante ponga a prueba frente a los otros dos grupos de preguntas esta propuesta inicial, haciendo todas la iteraciones que sean necesarias para obtener un resultado que esté acorde a los lineamientos del proyecto general.

5-1

5 Análisis y Diseño de la Solución 5.1 Descripción general y estrategia de implementación Se identificaron varios puntos claves para el análisis y diseño de la solución así como la elaboración de una estrategia apropiada para la implementación. En primer lugar es fundamental tener identificados a los perfiles de los usuarios del sistema, ya que ellos van a ser los encargados de interactuar con el mismo, una vez hecho esto es necesario especificar que acciones puede realizar cada uno de ellos y que acciones no, dependiendo de su rol y sus intereses. Con base en esto se identifican posteriormente los casos de uso del sistema y se tiene en cuenta qué funcionalidad ofrecer a qué tipo de usuario. Por último se evalúan requerimientos no funcionales que tienen en cuenta dependiendo de restricciones del ambiente de ejecución, accesibilidad, seguridad, entre otros factores. Vale la pena anotar que hilo conductor del diseño y de la implementación son los principios enunciados en el capítulo 4.1.

5.2 Actores El primer punto en el análisis consiste en la identificación de los actores involucrados con el sistema y la descripción detallada de la interacción de cada uno de ellos con el mismo, esta interacción es dependiente de las acciones que pueda realizar (según los permisos asignados), de las funciones y del objetivo que tenga el usuario con respecto al sistema. En KOC existen varios tipos diferentes de actores identificados a continuación.

Figura 5-1 Actores y relaciones con KOC y sus componentes

En la figura Figura 5-1, se representan en un óvalo los componentes del sistema KOC, rodeados de los diferentes actores involucrados. Las flechas bidireccionales representan posibilidad de realizar accesos de lectura y escritura, mientras las fechas unidireccionales

5-2

representan únicamente uno de los dos tipos de acceso: punteado cuando es sólo lectura y segmentado cuando se refiere a sólo escritura. Existen nueve tipos de actores enumerados a continuación en orden descendente de potencial de acceso al sistema: 5.2.1 Administrador General El administrador general es la persona con el rol más flexible y con capacidad de llevar a cabo la mayor cantidad de acciones sobre el sistema, ya que cuenta con la posibilidad de realizar todas las acciones de los demás roles de manera agregada. Así mismo tiene también la mayor responsabilidad y es muy importante, que todo este poder asignado, esté en manos de personas confiables para evitar incoherencias o pérdidas de datos.

5.2.1.1 Objetivo y Funciones El principal objetivo del administrador general es observar globalmente el funcionamiento del sistema y actuar en caso de encontrar algún problema. El administrador general tiene las siguientes funciones:

• Monitorear el funcionamiento global del sistema y propender a que se desempeñe correctamente

• Tener la visión general de todos los componentes involucrados y su interacción

• Supervisar la administración de datos y de la ontología

• Realizar mediciones periódicas de utilización del sistema y actuar de acuerdo a ellas.

5.2.1.2 Permisos El administrador general tiene algunos permisos únicos dado su rol, como:

• Realizar la administración de usuarios y permisos

• Acceso completo de administración y uso de todas las herramienta de autoría

Otros que resultan de la consecuencia de tener agregados los permisos de los demás roles.

• Administrar los datos en su totalidad

• Administrar la ontología en su totalidad

• Aprobar o rechazar solicitudes

• Realizar anotaciones

• Realizar búsquedas

• Consultar información de cualquier dato o proyecto

5.2.2 Administrador de la Ontología El administrador de la ontología es un experto del dominio de la construcción en arquitectura y tiene las facultades y el conocimiento para hacer modificaciones en las instancias de las entidades ontológicas en ArCo.

Adicionalmente el administrador de la ontología recibe la retroalimentación dada por los demás usuarios con otros roles que realizan solicitudes de cambio a la ontología y evalúa la viabilidad del cambio y eventualmente lo lleva a cabo.

5.2.2.1 Objetivo

5-3

El principal objetivo del administrador de la ontología es garantizar a los usuarios de KOC una ontología consistente, actualizada y de alta calidad reflejada en ArCo. Las funciones principales son:

• Administrar los contenidos de las entidades ontológicas y las relaciones entre ellos

• Evaluar y revisar las solicitudes respectivas a cambios en la ontología hechas por los demás usuarios

• Realizar labores de mantenimiento y limpieza en la ontología

• En cada versión mayor del sistema revisar cambios a la estructura de la ontología, junto con los administradores generales, en términos de nuevas clases, propiedades y restricciones

5.2.2.2 Permisos • Acceder y modificar los contenidos de la ontología en su totalidad, esto incluye

adicionar, editar o eliminar instancias por medio de la interfaz de usuario

• Aprobar o rechazar solicitudes relevantes a la ontología

5.2.3 Administrador de Datos El administrador de datos es el encargado de asegurar la calidad de los datos y actuar en caso de haber alguna inconsistencia en ellos. También tiene labores administrativas respecto del funcionamiento armónico del sistema.

5.2.3.1 Objetivo y Funciones El principal objetivo del administrador de datos es velar por la calidad de los datos y gestionar los elementos auxiliares que intervienen en el registro de datos y proyectos. Sus principales funciones son:

• Administrar los datos en su totalidad

• Revisar la coherencia y aplicabilidad de las anotaciones en los datos

• Ingresar nuevos proyectos al repositorio y actualizar los existentes

• Asegurarse que los anotadores tengan las herramientas necesarias y suficientes para llevar a cabo las anotaciones de la mejor manera.

5.2.3.2 Permisos • Llevar a cabo labores ocasionales como la indexación de la base de datos o la

generación de imágenes en caso de un eventual problema con el servidor

• Acceder y modificar datos, proyectos y entidades auxiliares para el registro de éstos.

• Eliminar, activar o desactivar un dato de acuerdo a su relevancia y coherencia frente al contexto de la aplicación o frente a otros datos.

5.2.4 Anotador Los anotadores son los usuarios responsables de llevar a cabo el proceso de anotación de datos levantados de proyectos reales usando la estructura especificada en la ontología ArCo, es decir son personas que cuentan con competencias académicas y entienden los contenidos teóricos de la ontología pero al mismo tiempo han estado involucrados en procesos de construcción reales y saben relacionar ambos mundos.

5-4

5.2.4.1 Objetivo y Funciones Su principal objetivo es realizar anotaciones, plasmando explicita y estructuradamente conceptos de la ontología, en datos de proyectos reales. Sus funciones son:

• Anotar datos con las herramientas que el sistema ofrece para ello

• Realizar solicitudes a los administradores en caso de encontrar un elemento faltante o estar convencido del cambio de uno existente

• Realizar cambios en sus anotaciones

• Utilizar la herramienta de autoría de procesos constructivos para el ingreso de secuencias de actividades en la realización de un objeto de construcción

5.2.4.2 Permisos • Adicionar un nuevo dato. En algunas situaciones no se cuenta con un recolector de

datos que conozca del sistema y ellos son los encargados de asumir esta tarea.

• Realizar anotaciones sobre datos del repositorio

• Adicionar un nuevo proceso constructivo. En realidad tienen permiso de gestionar todos los aspectos del proceso constructivo creado.

• Adicionar nodos al árbol de la WBS, antes de empezar el registro del proceso constructivo. Este permiso fue dado de manera temporal y es resultado de la implicación práctica que lleva hacer el cambio en la ontología por un administrador, de este modo el anotador puede acelerar el proceso de registro. Eventualmente, cuando la ontología se encuentre lo suficientemente poblada se quitará este permiso.

5.2.5 Recolector de Datos Toma material de las obras en construcción y tiene la posibilidad de adicionar los datos recolectados al sistema. Juega un rol sumamente importante en las fases previas al ingreso de datos y tiene que estar en constante comunicación con el anotador para llegar a un acuerdo en las anotaciones que se van a realizar. El recolector de datos es responsable en gran medida de la calidad de los datos recolectados y posteriormente publicados en KOC.

5.2.5.1 Objetivos y Permisos Su objetivo es recolectar datos de alta calidad durante la construcción de un proyecto. Los datos que recolecte también deben ser pedagógicamente aplicables. El único permiso con el que cuenta es adicionar nuevos datos al repositorio.

5.2.6 Profesor El rol de usuario profesor está relevado fundamentalmente al uso de las herramientas de autoría para componer objetos de conocimientos compuestos y casos de estudio. Los profesores son los encargados de llevar a cabo todo el proceso pedagógico de elaboración del objeto compuesto de conocimiento y de composición de los casos de estudio, que va desde la definición del contexto hasta la creación de todas las situaciones y alternativas posibles.

5.2.6.1 Objetivo El objetivo principal de este usuario es administrar y mantener actualizados objetos de conocimiento compuestos y casos de estudio para la consulta de estudiantes, a partir de

5-5

los contenidos existentes en KOC y de contenidos propios a aportar al repositorio respectivamente, usando las herramientas de autoría para estos propósitos. Su función es componer objetos compuestos y casos de estudio, haciendo uso de los objetos de conocimiento en el repositorio y las herramientas de autoría.

5.2.6.2 Permisos • Adicionar un nuevo caso de estudio, actualizar o borrar uno existente

• Generar y mantener objetos de conocimiento compuestos

5.2.7 Estudiante Los estudiantes son los usuarios más beneficiados con los contenidos del repositorio de KOC, ya que desde su concepción todos los datos recolectados y las anotaciones hechas tienen fines pedagógicos que simplemente con navegar páginas de información es posible adquirir grandes cantidades de conocimiento. Los estudiantes además podrán ser participes de la construcción del repositorio, indirectamente, usando la herramienta de tutoría de casos de estudio y por medio de un flujo de eventos por definir publicar sus soluciones en KOC.

5.2.7.1 Objetivo Usualmente el objetivo que tiene un estudiante, que consulta KOC, es aprender conceptos teóricos y prácticas del área técnica en arquitectura por medio de los recursos educativos y material multimedia.

5.2.7.2 Permisos • Consulta de información de datos y proyectos. Estas consultas incluyen objetos de alto

nivel como casos de estudio y objetos compuestos generados por los profesores.

5.2.8 Invitado Los invitados son personas que están interesadas en el funcionamiento del sistema y evalúan la posibilidad ya sea de ser adicionados con algún otro rol o planean tener su propia versión de KOC. Pueden hacer pruebas de adición y edición sobre sus objetos, consultar toda la información pero no pueden alterar entidades administrativas o configuraciones del sistema.

5.2.8.1 Objetivo El objetivo de un usuario invitado es explorar las funcionalidades del sistema con el propósito de evaluar la viabilidad de implantación propia o ingreso al sistema.

5.2.8.2 Permisos • Consultar información

• Adicionar y anotar datos no publicables

• Descargar archivos con recursos originales almacenados en KOC

5.2.9 Anónimo El rol de usuario anónimo hace referencia a cualquier persona que visite el sitio web de la aplicación y no se autentique. Los usuarios anónimos están bastante limitados en términos de permisos y sus acciones son únicamente de lectura.

5.2.9.1 Objetivo

5-6

El objetivo principal de un usuario anónimo es informarse de los contenidos públicos del sistema.

5.2.9.2 Permisos • Realizar búsquedas

• Consultar páginas de información de datos y proyectos

5.3 Casos de uso 5.3.1 Diagramas de Casos de Uso

Figura 5-2 Diagrama de casos de uso KOC, núcleo

Figura 5-3 Casos de uso de herramientas de autoría

5.3.2 Descripción de los casos de uso Los casos de uso se dividen en dos grupos a partir de lo presentado en los diagramas

Figura 5-2 y Figura 5-3. Los casos de uso de las herramientas de autoría no son descritos en esta sección ya que se mencionó la descripción general y su proceso en el capítulo 4.5 Los casos de uso núcleo para KOC se describen a continuación:

5-7

5.3.2.1 Administración de ArCo La ontología ArCo dada su naturaleza y concepción es evolutiva y se construye dinámicamente en el tiempo, de modo que los administradores con permisos para modificar el contenido de la ontología ueden realizar este tipo de acciones por medio de la interfaz de usuario que ofrece KOC; los administradores general y administradores de la ontología son capaces de adicionar, editar y eliminar instancias arquetípicas, relaciones o en general cualquier otro contenido de la ontología, como la descripción de un concepto o el nombre. La interfaz de administración de la ontología se organiza en varios módulos que agrupan los diferentes conceptos núcleos de ArCo: WBS, espacios, materiales, funcionalidades y grados de desempeño, y por último, equipos. Cada uno de estos módulos provee una vista de los contenidos relevante a las clases agrupadas, presentadas ya sea en forma de listado o en forma jerárquica (árbol). Por otro lado cada módulo también provee formularios de ingreso o edición de nuevas instancias. La estructura de ArCo no se pretende que sea modificada regularmente, posiblemente al haber cambios mayores de versión de la aplicación, por este motivo los administradores no tienen la posibilidad de reestructurar las clases ni adicionar nuevas; para suplir esta necesidad se recomienda utilizar el sistema de solicitudes y al haber un cambio mayor de versión se revisa cada una de ella y se toma la decisión de aprobar la solicitud o no. Para mayor información en el sistema de solicitudes consulte el capítulo 5.4.1.

5.3.2.2 Administración de KOC La administración de entidades auxiliares para el registro de proyectos y datos, al igual que entidades netamente administrativas también pueden ser llevadas a cabo por medio del sistema KOC. La interfaz de usuario es muy similar a la administración de la ontología, de hecho se acceden con los íconos localizados en la barra superior. Los módulos disponibles al administrador general y al administrador de datos son: datos, proyectos, solicitudes, formatos, usuarios, fuentes y autores, tipos de datos y tipos de proyectos. Para cada uno de ellos se tiene un listado y formularios para el ingreso y edición de sus objetos.

5.4 Funcionalidades Complementarias Aunque no hacen parte de las funcionalidades núcleo de KOC, las siguientes funcionalidades complementarias responden a requerimientos auxiliares que se tuvieron en cuenta al momento de desarrollar el sistema, son funcionalidades que se encargan del seguimiento, del registro o simplemente presentan otras visualizaciones de los datos presentes en el repositorio.

Se introduce el sistema de solicitudes y logs como un mecanismo de control para los administradores, el registro de personas y empresas en la industria de la construcción como respuesta a la pregunta quién construyó qué, el registro de fuentes y derechos de autor como garantía del respeto a la propiedad intelectual y la georeferenciación de proyecto, manejo temporal de datos y feed de sindicación de noticias como tres visualizaciones contextualizadas de los datos presentes en KOC como mapas, líneas de tiempo y noticias respectivamente.

5.4.1 Sistema de solicitudes y logs Parte de las funciones de los administradores es velar por la calidad en los datos, para ello se han implementado mecanismos para hacer esta tarea más fácil. El primer mecanismo es el registro de cambios en los objetos de conocimiento, una utilidad que permite al administrador ver quién y cuándo se modificó un objeto de conocimiento y el cambio de estado respectivo. Por otro lado y a un más bajo nivel se ha utilizado en Logger

5-8

de Log4J por medio de la librería del grupo Apache Jakarta llamada Commons Logging (52), con este Logger es posible depurar la ejecución de la aplicación poniendo mensajes dentro del código a diferentes niveles de gravedad: DEBUG, para depurar la ejecución, INFO, para mensajes de información al usuario, WARN, para mensajes de advertencia, ERROR, para mensajes de error y FATAL para mensajes de errores fatales. La librería Log4J es completamente configurable por medio del archivo log4j.properties ubicado en el directorio conf. Por defecto la aplicación muestra los mensajes desde el nivel DEBUG en el archivo koc.log ubicado en WEB-INF. Inspeccionando este archivo el administrador podrá consultar mensajes relacionados con el funcionamiento de la aplicación y el cambio a todos los objetos existentes en el sistema.

Otro mecanismo que se implementó en KOC para ayuda de los administradores es el sistema de solicitudes; el principal objetivo de éste es ofrecer a usuarios sin privilegios suficientes la posibilidad de dar retroalimentación y solicitar cambios al sistema a los encargados directos o administradores. Para realizar una solicitud de cambio es necesario llenar el formulario de solicitud donde se preguntan varios datos: Nivel de la solicitud, es decir en qué se quiere solicitar, tipo de solicitud, puede ser adición, edición o remoción y por ultimo un comentario de texto libre donde el usuario puede explicar detalles del porqué de su solicitud. En la página de inicio de los administradores ellos pueden consultar el listado de solicitudes pendientes y aprobar o rechazarlas una vez se hayan evaluado.

5.4.2 Personas y Empresas en la Industria de la Construcción Dentro de un proyecto de construcción en arquitectura, varias personas naturales y jurídicas (empresas) están involucradas en cada una de las etapas del ciclo de vida del proyecto realizando diversas actividades como: labores de diseño, construcción, interventoría, planeación, gerencia de proyecto, entre otras. Como parte de la ficha técnica del proyecto, KOC permite especificar asociaciones de estas personas o empresas y el rol que desempeñan dentro de la construcción del proyecto. Al momento de ingresar o editar un proyecto es posible registrar las parejas persona/rol como participantes del equipo de diseño y construcción en el proyecto. Lo que se busca con esta funcionalidad es formar un directorio profesional en proyectos de construcción reales y de cierta manera dar crédito por el trabajo realizado a las personas y empresas involucradas en el proyecto. Los participantes luego de ser ingresados por primera vez al sistema quedan guardados dentro del directorio y pueden ser referenciados en proyectos posteriores. En la Figura 5-4 se presenta la interfaz de usuario para realizar el registro del equipo de diseño y construcción.

Figura 5-4 Equipo de Diseño y Construcción. Ejemplo edificio Mario Laserna

5.4.3 Derechos de autor y registro de fuentes

5-9

Desde la concepción de KOC se ha tomado muy en serio el respeto a la propiedad intelectual y el cumplimiento con los derechos de autor, ya que el éxito y la utilización masiva del sistema radican en la confianza que depositan en él sus usuarios generadores de contenido. Para satisfacer este requerimiento, en primera instancia KOC permite especificar a los usuarios que ingresan un nuevo dato cuál es su fuente o proveniencia y en las páginas de consulta dar el crédito respectivo. Actualmente es posible elegir entre tres tipos de fuente diferentes: autor, persona creadora/generadora del dato; bibliografía, texto escrito o publicación en forma de revista o libro; URL, dirección a un sitio Web donde fue tomado o permanece el dato. Al mismo tiempo de registrar cada una de las fuentes utilizadas dato por dato se va creando un directorio global de fuentes que puede ser consultado por los usuarios de KOC donde se listan y se referencian todas ellas. Las fuentes también se pueden reutilizar para el registro de nuevos datos ya estando dentro del directorio.

Cada dato siempre cuenta con la información del usuario responsable por su registro en KOC, tanto el creador del dato como cada una de las personas que realizaron modificaciones al objeto de conocimiento. Para la descripción técnicas de la implementación de roles y seguridad puede ir al capítulo 5.5.2.

En el diagrama de clases mostrado en la Figura 5-5 se presenta el modelo utilizado para estructurar las fuentes y los atributos asociados a cada uno de ellos. Existe la posibilidad de adicionar nuevas fuentes al sistema extendiendo la clase Fuente y sobrescribiendo los métodos getNombre y getDescripcion.

Figura 5-5 Diagrama de clases de las fuentes

Adicionalmente como otra medida de seguridad que potencialmente puede evitar el plagio o la copia de contenidos provenientes de KOC, las imágenes no se muestran en su tamaño real, es decir, son ligeramente redimensionadas y van acompañadas de una marca de agua con un mensaje de Copyright en la esquina inferior derecha tal como se puede ver en la Figura 5-6, sin embargo para personas con permisos de administrador es posible descargar el archivo original. Para la descripción técnica del proceso de manipulación de imágenes consulte el capítulo 5.5.1.

5-10

Figura 5-6 Marca de agua con mensaje de copyright resaltada en color rojo

5.4.4 Georeferenciación de Proyectos Como parte del registro de proyectos se tiene la especificación de su ubicación geográfica. La localización del proyecto es importante ya que puede determinar el uso de ciertos materiales o el cumplimiento de determinados grados de desempeño o funcionalidades. La georeferenciación del proyecto se hace usando geometría tipo punto con el par de coordenadas latitud y longitud y se guarda en la base de datos. Además de relacionar la ubicación del proyecto con sus propiedades ontológicas la georeferenciación sirve para ubicar en el mundo dónde están los proyectos registrados en KOC. Para su visualización se usa como el componente embebido de Google Maps (53) y mediante su API se adiciona cada punto como una cobertura (overlay en vocabulario de Google Maps); al hacer clic se muestra una ventana informativa con la imagen thumbnail y el nombre del proyecto tal como se puede apreciar en la Figura 5-7.

Figura 5-7 Vista de proyectos en un mapa

5.4.5 Manejo Temporal de Proyectos y Datos

5-11

Como se ha presentado anteriormente al momento de ingresar datos y proyectos se registran las fechas de inicio y finalización para el caso de los proyectos o la fecha de ocurrencia para el caso de los datos, se decidió que la mejor manera de visualizar esta información es en una línea de tiempo. Para lograr este propósito se utiliza un componente desarrollado por ingenieros del MIT dentro del proyecto SIMILE (54). El componente de línea de tiempo cuenta con un API donde se pueden adicionar eventos, configurar parámetros para la visualización, importar fuentes de datos en formato JSON y XML, entre otras muchas funcionalidades. Específicamente para KOC se utiliza este componente como vista alternativa dentro del listado de proyectos, donde cada proyecto se muestra como un intervalo de tiempo color azul, para el listado de datos, donde cada dato es un punto en la línea de tiempo, y para la página de información de cada proceso constructivo, donde el proceso es un intervalo y cada actividad se representa con un punto. Se usa en gran parte la configuración por defecto más una vista a menor escala en la parte inferior para avanzar y retroceder en el tiempo según lo desee el usuario a mayor velocidad. A continuación en la Figura 5-8 se muestra un ejemplo de utilización del componente en el listado de proyectos haciendo énfasis en la ventana de información del nuevo edificio W.

Figura 5-8 Vista de proyectos en la línea de tiempo

5.4.6 Feed de sindicación de noticias Los feed de sindicación de contenido permiten a los usuarios de KOC suscribirse a un canal de noticias que notifica cada vez que hay un nuevo dato o proyecto en la aplicación. Para lograr esta funcionalidad se hizo cumpliendo el estándar más utilizado para este propósito, RSS (Really Simple Syndication) basado en XML. Para suscribirse al canal de noticias de KOC en la parte inferior de la página de inicio se localiza el icono de RSS y al hacer clic en el (ver Figura 5-9) se es direccionado a una vista del archivo XML del canal RSS que puede ser dada a un servicio de suscripción o cliente RSS como Google Reader (ver Figura 5-10) o Mozilla Thunderbird (ver Figura 5-11), entre otros.

5-12

Figura 5-9 Vinculo de suscripción al canal RSS

Figura 5-10 Vista del feed de noticias en Google Reader

Figura 5-11 Vista del feed de noticias en Mozilla Thunderbird

5-13

Desde el punto de vista de implementación se utilizó el API de la librería ROME (55) desarrollada por ingenieros de Sun Microsystems en el lenguaje Java. El flujo de funcionamiento es el siguiente:

7. Se ingresa a la URL http://arqdis.uniandes.edu.co:8080/KOC/news.rss

8. El pedido es re direccionado a un controlador plano de Spring MVC con nombre NewsRssController

9. Este controlador contiene únicamente el método handle donde retorna como resultado la vista NewsRssView más la colección de datos (el modelo) a mostrar en el feed de noticias

10. Dentro de la vista se recorre cada dato como una entrada en el feed de noticias teniendo cuidado de poner el titulo, la fecha y el contenido.

11. Al terminar de armar la vista se hace render del feed usando la librería ROME y se despliega el XML generado listo para ser consumido

5.4.7 Búsqueda sintáctica El término búsqueda sintáctica en el marco del proyecto hace referencia al requerimiento de buscar con palabras clave como criterio único en los contenidos previamente indexados del sistema. Esta técnica también se conoce con el nombre de "Full Text Search" o búsqueda de texto completo. Como primera instancia se seleccionan los atributos en el modelo de objetos o las columnas en una base de datos relacional que aplican para realizar búsquedas y una vez hecho esto se crean índices que son mantenidos al haber modificaciones que reducen el tiempo de acceso y localización de los resultados de la búsqueda. Una de las decisiones de diseño fundamentales para el motor de búsqueda sintáctica consiste en definir cuál contenido es indexables y cuál no para el proceso de indexamiento. A priori, se eligieron como primer criterio los atributos de texto libre como las descripciones y los títulos de los objetos, principalmente visibles en datos y proyectos al igual que en otras entidades. Luego, se procedió con las clases de la ontología y con algunas otras que pudieran resultar interesantes al ser buscadas por el usuario.

La implementación del motor de búsqueda sintáctica se realizó haciendo uso del proyecto Compass (56) que provee toda infraestructura para hacer un sistema indexable y con capacidad de encontrar objetos dadas las palabras claves que deben contener en sus atributos. Compass incluye en su distribución una serie de conectores (subclases de CompassGPS y CompassGPSDevice) para integrar mecanismos de persistencia existentes o frameworks utilizados y hacer más fáciles los procesos de indexamiento y búsqueda. En particular para el caso de KOC se utilizaron los conectores para Spring Framework y JPA que por medio de interceptores son notificados de cambios en los atributos indexables al haber operaciones CRUD (Create Retrieve Update Delete) para posteriormente actualizar los índices respectivos en el sistema de archivos. La configuración de Compass se lleva a cabo en el XML del contexto de la aplicación en Spring y la definición de clases y atributos indexables se hace usando anotaciones de Java 5 bajo la práctica que ellos denominan OSEM (Object Search Engine Mapping).

Compass está construido sobre el proyecto Apache Lucene, que ha demostrado ser una librería muy robusta y de muy alto rendimiento, por este motivo maneja los mismos tipos de índices y tiempos de respuesta ofrecidos por Lucene; sin embargo al mismo tiempo encapsula mucha de la complejidad y ofrece interfaces de alto nivel que evitan malas utilizaciones de los índices y APIs de bajo nivel que maneja directamente Lucene.

5-14

5.5 Requerimientos No Funcionales 5.5.1 Manejo de archivos multimedia Existen varias funcionalidades del sistema KOC y de sus componentes que se apoyan en la manipulación y generación de contenido multimedia. Aunque uno de los propósitos es que el repositorio acepte y se nutra de cualquier tipo de archivos, existen algunos tipos de contenido multimedia especiales que se procesan y/o se presentan al usuario para enriquecer la experiencia o hacerla más interactiva. Estos tipos de contenido son básicamente imágenes, videos, documentos PDF y presentaciones.

Las imágenes son el tipo de dato más frecuentemente encontrado en el sistema, por ello se realizan varias operaciones que facilitan su manejo y operación. Al ingresar un dato cuyo archivo es una imagen la principal acción que se realiza es el redimensionamiento de la misma a dos tamaños thumbnail, para ser mostrada en listados y vista previa para ser mostrada en páginas de información. Este proceso de redimensionamiento es muy conveniente desde el punto de vista de diagramación de las páginas web ya que acota el área para desplegar la imagen a un ancho y alto máximos, también ayuda a que el tiempo de carga sea menor y le facilita al browser realizar procesos de caching, entre otras ventajas. En segundo lugar y dado el requerimiento de derechos de autor y manejo del copyright mencionado en el capítulo 5.4.3, todas las imágenes llevan en su versión redimensionada de vista previa un mensaje de copyright tipo marca de agua de color blanco y semitransparente. Para la manipulación de imágenes se utilizan principalmente las utilidades que la plataforma Java ofrece para ello por medio de las librerías incluidas en el paquete Java Image I/O.

El segundo tipo de dato que KOC tiene en su repositorio son videos. En la interfaz de usuario en KOC al subir un archivo identificado como video se abre una instancia del reproductor JW FLV Player (57) y se pone en marcha el video recién subido. Para hacer esto posible es necesario convertir de múltiples formatos de video a video tipo flash FLV, soportado por el reproductor. Dada la complejidad en soportar todos los codecs existentes y a la falta de herramientas en Java para procesamiento y manipulación de video se decidió hacer llamados a la librería nativa en C++ FFMPEG. Estos llamados se hacen por medio de la utilidad que Java ofrece para invocar la línea de comandos, de la siguiente manera process = runtime.exec(cmd) de modo que la aplicación debe estar instalada previamente y la variable de entorno PATH con el nombre del comando incluida además es la única parte de la aplicación que es dependiente al sistema operativo. Los formatos para video soportados por KOC son AVI, MPG, FLV, MP4. La aplicación FFMPEG aparte de la conversión de formatos es también utilizada para extraer un cuadro del video y utilizarlo como vista previa del dato e imagen thumbnail.

En cuanto a documentos se refiere KOC soporta el ingreso y la generación de archivos PDF (Portable Document Format) para Adobe Acrobat®. Al adicionar un dato cuyo archivo adjunto tiene formato PDF, KOC realiza una operación de captura de la primera página como imagen y genera a partir de ésta, al igual que en los casos anteriores, una imagen de vista previa y una imagen tipo thumbnail. Este proceso se logra utilizando el API de la librería jPedal (58). Por otro lado, en la herramienta de autoría de casos de estudio se generan programáticamente archivos PDF con la información de caso y el inventario de situaciones definido por el profesor. Para este propósito se utiliza el API de la librería iText (59) especializada en la generación de documentos PDF.

Por último KOC también soporta la generación programática de presentaciones en formato PPT visualizables en el programa Microsoft PowerPoint®. En las herramientas de autoría compositor de objetos compuestos y compositor de procesos constructivos el

5-15

objeto compuesto resultante se representa con un archivo PPT generado automáticamente; para crear este archivo se itera sobre cada objeto simple o actividad respectivamente creando una diapositiva que muestra su descripción general e imagen de vista previa. Este proceso se logra mediante el uso del API de la librería POI del grupo Jakarta de la fundación de Software Apache (52).

5.5.2 Seguridad y control de acceso La seguridad y el control de acceso es uno de los requerimientos más importantes en KOC ya que de ello depende la coherencia de los datos, la armonía en el funcionamiento y sirve para promover la colaboración de los usuarios dependiendo de su rol a desempeñar. En control de acceso consiste en restringir ciertas funcionalidad y otorgar privilegios a los usuarios dependiendo del rol que tengan asignado dentro del sistema, siempre y cuando demuestren serlo mediante unas credenciales.

Para manejar este requerimiento se hace uso del proyecto Acegi Security (60), que provee una amplia gama de componentes compatibles con Spring Framework que pueden ser utilizados para ofrecer altos niveles de seguridad en un sistema de manera no intrusiva y altamente configurable. Dos ejemplos de estos componentes son el "Remember Me" con la clase RememberMeProcessingFilter que mantiene una variable en forma de cookie recordando al usuario que se autenticó por un periodo determinado de tiempo y el procesador de usuarios anónimos con la clase AnonymousProcessingFilter, que permite consultar ciertas secciones del sistema a usuarios que no se han autenticado. Sin embargo para manejar otros aspectos de la seguridad y el control de acceso es necesario tomar decisiones de diseño e implementar componentes más complejos como se presenta en los dos capítulos a continuación. Básicamente se tienen dos grandes temas dentro del control de acceso, la autenticación y la autorización. El proceso de estos dos procesos se presenta en la Figura 5-12.

Figura 5-12 Proceso de autenticación

5.5.2.1 Autenticación Se entiende por el proceso de verificación de las credenciales de un usuario con el fin de identificar al usuario antes de que el acceso sea dado (61). A la fecha KOC soporta dos tipos de autenticación, basado en el directorio LDAP de la Universidad de los Andes y

5-16

basado en la base de datos de KOC, principalmente para usuarios de otras organizaciones o invitados. Dentro de la tabla de usuarios se cuenta con una columna que indica el tipo de autenticación a utilizar y dependiendo de ésta se procede con uno u otro tipo de autenticación, siguiendo el patrón delegado; esta lógica está implementada en la clase de KOC JdbcProviderManager. El verdadero proceso de autenticación lo realizan las clases de Acegi DaoAuthenticationProvider y LdapAuthenticationProvider. Cabe anotar que en caso de requerir otro tipo de autenticación el sistema es completamente extensible, sólo es necesario definir la clase proveedora de la autenticación y modificar la lógica respectiva en el delegador.

En caso de usar la base de datos para la autenticación, las contraseñas son cifradas usando el algoritmo MD5 y de este modo evitar que éstos sean visibles a quienes acceden la tabla directamente, específicamente se utiliza la clase de Acegi Md5PasswordEncoder que maneja el proceso de codificación de la contraseña. En cuanto a la autenticación con el directorio LDAP se hace uso de JNDI por medio de la clase de Acegi DefaultInitialDirContextFactory y FilterBasedLdapUserSearch con los atributos configurados acordemente con el directorio de la Universidad.

5.5.2.2 Autorización Se entiende por el proceso, inmediatamente posterior a la autenticación, en el que se autoriza el acceso a un usuario a ciertas partes del sistema o a realizar ciertas tareas dependiendo de sus privilegios o políticas establecidas en el sistema (61). La implementación de este requerimiento se logra manejando un par de tablas en la base de datos cuya responsabilidad es decir que usuarios están registrados y cual rol tiene cada cual. Se implementó en la clase JdbcLdapAuthoritiesPopulator la lógica de seleccionar el rol o perfil que tiene un usuario sin importar su tipo de autenticación. Desde el punto de vista de la implementación de los permisos se tienen dos etapas. La primera consiste en la asignación de permisos para cada rol de acceder a ciertas páginas, esto se logra configurando el atributo objectDefinitionSource de la clase FilterSecurityInterceptor. En la Figura 5-13 se puede ver la configuración en el contexto de la aplicación en Spring, note que se acepta el uso de expresiones regulares para las definiciones de las cadenas.

Figura 5-13 Definición de autorización a roles por URL de la página

Una vez los usuarios acceden a la página deseada, es posible que se quiera esconder o mostrar de manera personalizada los contenidos de la misma dependiendo del rol. Para ello se utilizó el taglib JSTL incluido en Acegi para este propósito, el taglib es una colección de etiquetas que extienden el lenguaje JSTL estándar para ofrecer

5-17

funcionalidades de alto nivel en un dominio específico. La etiqueta de Acegi se identifica con nombre authz:authorize y dependiendo del valor en los atributos ifAnyGranted, ifNotGranted, ifAllGranted muestra o esconde el contenido al interior de la etiqueta. En la Figura 5-14 se muestra un ejemplo de acciones que sólo el administrador general puede realizar en la página de inicio en la administración.

Figura 5-14 Uso del taglib de Acegi

Por último y aprovechando otro taglib que provee Acegi, authz:authentication, con el atributo operation con valor "username", es posible conocer el usuario en la sesión actual. Esto permite asignar responsabilidades a usuarios específicos sobre los datos ingresados y modificados en el sistema para tener un inventario de datos por usuario.

5.5.3 Internacionalización (i18n) La internacionalización de la interfaz gráfica de KOC es el primer paso en ubicar el proyecto a un nivel más global, haciéndolo accesible a personas que hablan diferentes idiomas. A la fecha se cuenta con las cadenas traducidas en inglés y español pero en el trabajo futuro se presentan otros idiomas a soportar.

La implementación de la internacionalización se hizo apoyándose en las utilidades que Spring MVC provee para este propósito, ubicadas en el paquete org.springframework.web.servlet.i18n existente en la distribución de Spring y la configuración necesaria definida en formato XML en el contexto de la aplicación. La clase que implementa el patrón front controller en Spring MVC, DispatcherServlet, permite resolver qué mensajes mostrar al usuario haciendo uso de los objetos de la clase LocaleResolver. Además del solucionador de localidad se hace uso de un interceptor que detecta el cambio de localidad basada en parámetros de la URL de la solicitud HTTP, es decir un objeto de LocaleChangeInterceptor. Las cadenas y traducciones están agrupadas por idioma en el directorio WEB-INF/ en archivos nombrados de la forma messages_<idioma>.properties donde <idioma> se reemplaza por el código ISO de dos letras que indica el idioma; los contenidos de este archivo son parejas de la forma <llave>=<cadena_traducida>. Todo esto se implementa configurando una instancia de ResourceBundleMessageSource en el contexto de la aplicación. En resumen, para adicionar un nuevo idioma al sistema KOC es necesario entonces crear un nuevo archivo messages_<idioma>.properties con cada una de las llaves traducidas en él. En las plantillas JSP se hace uso del taglib fmt:message con el nombre de la llave que se quiere utilizar en la interfaz de usuario y el framework se encarga de desplegar los mensajes en el idioma adecuado. En la Figura 5-15 se muestran dos fragmentos de archivos de traducción en diferentes idiomas.

5-18

Figura 5-15 Ejemplo de parejas llave=mensaje en español e inglés respectivamente

Desde el punto de vista de la experiencia de usuario se trata de hacer de la manera más transparente posible, detectando el idioma por defecto configurado por el navegador y mostrando las cadenas en este idioma. Sin embargo en el encabezado de cada página existe un Select de HTML que tiene el listado de idiomas disponibles en el sistema, al cambiar de idioma en este select automáticamente se cambia de localidad en todas las páginas que el usuario navegue posteriormente haciendo uso de la definición del LocaleChangeInterceptor anteriormente explicado. En el capítulo 10.4, se presenta como trabajo futuro el diseño e implementación de la internacionalización de contenidos.

6-1

6 Arquitectura del Sistema KOC tiene una arquitectura tipo aplicación web. Esto quiere decir que se tiene un servidor centralizado cuya función es responder pedidos hechos por clientes que se encuentran distribuidos. Los pedidos y las respuestas se llevan a cabo siguiendo el protocolo HTTP y la comunicación ocurre vía internet mediante el uso de un browser por parte del cliente que interpreta las respuestas del servidor en forma de documentos HTML, de esta manera no se requiere instalar software adicional y la aplicación se puede acceder virtualmente desde cualquier computador en el mundo que cuente con un browser y acceso a internet.

6.1 Arquitectura Multicapas Internamente, la aplicación está construida con un enfoque multicapas o n-capas, es decir, está compuesta por diferentes capas con roles específicos encargadas de funciones de acuerdo al nivel donde se ubican, teniendo la posibilidad de usar servicios provistos únicamente por la capa inmediatamente inferior. Este modelo de arquitectura facilita el mantenimiento para los desarrolladores y facilita la separación de responsabilidades. Al conjunto de capas, usualmente ubicadas dentro de un contenedor, se le conoce con el nombre de Middleware. Para el caso de KOC se definieron tres de estas capas, web, servicios y acceso a datos. En la Figura 6-1, se muestra un esquema global de la arquitectura de KOC.

Figura 6-1 Esquema de una arquitectura multicapas

6.1.1 Capa Web La capa web es la responsable de procesar las solicitudes hechas por los clientes y de construir la respuesta adecuada usando la capa de servicios.

6.1.2 Capa de Servicios La capa de servicios, como su nombre lo indica, ofrece servicios de alto nivel que involucran la operación de varios componentes del sistema, la lógica de esta operación está encapsulada en cada servicio y puede (suele) involucrar llamados a la capa de acceso a datos. Los servicios proveídos por esta capa son vistos como transacciones.

6-2

6.1.3 Capa de Acceso a Datos Se encarga de la interacción con el mecanismo de persistencia, para KOC la base de datos, y encapsula detalles específicos de cómo se hace este acceso.

En la Figura 6-2 se presenta un diagrama de despliegue UML, en donde se muestran los diferentes nodos y componentes del sistema.

Figura 6-2 Diagrama de componentes para KOC

6.2 Patrones de Diseño En el desarrollo de KOC se utilizaron varios patrones de diseño.

6.2.1 Inyección de dependencia DI por su sigla en inglés. Consiste en la definición de dependencias en términos de interfaces y su posterior resolución por clases específicas a utilizar mediante parámetros de configuración, seleccionadas por un contenedor de inversión de control (IoC) (62). Este patrón se usa consistentemente en la implementación de la aplicación por medio de Spring Framework (60) tal como se explica en el capítulo 7.1.4.

6.2.2 Patron Front Controller o Web MVC Modelo, vista, controlador. Separa en tres partes el proceso de interacción con el usuario. El modelo representa los datos y la conceptualización del dominio, la vista consiste en la presentación al usuario o visualización de este dominio y el controlador es el encargado de construir la vista con el modelo requerido según la solicitud del usuario (63). El uso de este patrón se hace a través del framework web Spring MVC, ver sección 7.1.4, que facilita este proceso y además provee otro conjunto de utilidades.

6.2.3 DAO Data Access Objects. Transfiere la responsabilidad de la persistencia de datos clave de los objetos del negocio a objetos cuya función específica es acceder a los datos. Estos objetos hacen transparente a los objetos de negocio de la fuente de datos que se está usando y de la configuración necesaria para comunicarse con esta. El uso de este patrón a su vez facilita el mantenimiento de la aplicación separando lógica propia del dominio de la lógica de persistencia de los datos (64).

6-3

6.3 Estructura de paquetes El código fuente de la aplicación se encuentra organizado en una estructura de paquetes de la siguiente manera. Todos los paquetes tienen el prefijo co.edu.uniandes.koc que identifica la pertenencia al proyecto más el namespace de la organización donde se desarrolló el proyecto, la Universidad de los Andes. El modelo del dominio se encuentra bajo el paquete model a su vez divivido en ocho partes: las clases de administración (admin), las clases de anotación (annotation), las clases referentes a la ontología ArCo (arco), las clases referentes a los datos (data) y las clases de objetos de conocimiento (ko), en este mismo paquete se tienen los paquetes del código fuente de las herramientas de autoría: procesos constructivos (process), casos de estudio (casestudy), compositor de objetos compuestos a partir de búsquedas (search). En lo que se refiere a la capa de acceso a datos se tienen dos paquetes, dao donde se encuentran las interfaces de acceso a datos y dao.jpa que contiene la implementación específica para el acceso a datos usando el estándar JPA mencionado en el capítulo 7.1.2.1. Igualmente la capa de servicios cuenta con dos paquetes similares, service que contiene las interfaces y service.impl que contiene la implementación. Para la capa web se tiene un paquete para cada tipo de clases que extienden a las de Spring MVC, controller agrupa los controladores multi-acción, controller.form los FormController, propertyeditor algunos editores de propiedades altamente usados, validator incluye clases para la validación de objetos usadas durante el proceso de encadenamiento, en el capítulo 7.1.4 se explica con un mayor nivel de detalle cada uno de estos componentes. Adicional a estos paquetes denominados “principales” se tienen los paquetes que proveen funcionalidad auxiliar, como es el caso de útil, o que se encargan de requerimientos no funcionales, como es el caso de security. En la Figura 6-3 se visualiza la estructura de paquetes vista desde Eclipse.

Figura 6-3 Estructura de paquetes

6-4

6.4 Arquitectura de datos Los datos son el principal activo de KOC ya que en ellos se encuentran reflejados todos los contenidos, propiedades y configuraciones del sistema. Dada su importancia KOC cuenta con una infraestructura que hace su mejor esfuerzo por garantizar la integridad de los datos en él, KOC utiliza un sistema manejador de base de datos relacional. Por otro lado y desde el punto de vista de la estructura y las relaciones semánticas de los datos se utilizan las ontologías para este propósito. A continuación se presenta cada una de estas tecnologías utilizadas en mayor detalle.

6.4.1 Base de datos Como se presentó anteriormente KOC cuenta con un sistema manejador de base de datos relacional y centralizado. El uso de esta clase de sistemas garantiza en gran parte los requerimientos no funcionales asociados a la aplicación, como transaccionalidad (o cumplimiento con las propiedades ACID), tolerancia a fallas, escalabilidad y algunos requerimientos de seguridad de los datos. Por otro lado se caracteriza por ser una tecnología con un muy alto impacto de adopción en la industria y se cuenta con gran variedad de productos existentes de alto desempeño y altamente optimizados. Finalmente una base de datos relacional permite el acceso de consulta de datos desde otras aplicaciones, permitiendo compartir y reutilizar. En la Figura 6-4 se muestra el modelo entidad relación utilizado, en total son alrededor de 70 entidades. Para una explicación más detallada sobre el modelo entidad relación puede consultar el anexo 12-1.

6.4.2 Ontología Las ontologías, tal como ha mencionado a lo largo de este documento, juegan un papel fundamental en KOC ya que estructuran formalmente los conceptos y relaciones del dominio del área técnica de arquitectura. Teniendo en cuenta que existen distintos tipos y usos de ontologías y siguiendo en marco teórico de la clasificación de Pollock (22), ArCo es una ontología de información, más específicamente es una ontología de industria o dominio específico. Desde otro punto de vista, puede ser utilizada como una ontología de interfaz si se pretende consumir por aplicaciones de terceros mediante el API proveído en el futuro por KOC.

Desde el punto de vista de diseño se ha identificado el uso de varios de los patrones enunciados por Pollock (22). El principal patrón de diseño y de arquitectura derivado de la manera como se implementó KOC es el patrón estructural Conceptual Identity que consiste en el uso de la ontología como base para modelar el sistema de software completo, es decir, la ontología es el núcleo e identidad de todo el sistema. Dentro de los patrones de comportamiento se resalta el uso del patrón Ontology Broker que consiste en la distribución de la ontología desde un sitio central para aplicaciones que la utilizan, esto se puede notar en la interacción vía OWL mencionada en 7-4, por otro lado se sigue el patrón Smart Query, también de comportamiento, utiliza la ontología como una interfaz de consulta altamente expresiva, lo cual se puede apreciar en la herramienta de autoría compositor de objetos compuestos presentada en el capítulo 4.5.1. Por último y en la arena de los patrones creaciones se utilizó el patrón Structure Reuse, ya que la primera versión de la ontología se baso en taxonomías estándar de la industria de la construcción y la misma elaboración de ArCo se hace extendiéndose a partir de sí misma.

6.5 Arquitectura de componentes El modelo de componentes de alto nivel que se tiene para la administración de las herramientas de autoría, es un modelo extensible, dinámico y altamente configurable. El

6-5

objetivo es permitir la adición al sistema de nuevos módulos (otras herramientas de autoría) que extiendan la funcionalidad núcleo de KOC, mientras este continúa en funcionamiento mediante un modelo de servicios dinámico.

A partir de esto se tienen en cuenta la existencia de varios componentes. El componente núcleo y principal, que va a ser KOC como repositorio de objetos e interfaz a la ontología y un componente modular (bundle) por cada herramienta de autoría.

Es posible, además necesario, que cada uno de los componentes de las herramientas de autoría consuma servicios proveídos por el componente núcleo de KOC. Estos servicios se resumen en tres operaciones: consultas a la ontología, consultas a los datos y por último ingreso de objetos de conocimiento al repositorio.

Los diferentes módulos, incluyendo el componente núcleo, tienen diferentes contextos de aplicación, pero tienen la capacidad de compartir recursos globales y utilizar la inyección de dependencias a través de distintos contextos.

6-6

Figura 6-4 Modelo Entidad Relación a la fecha

7-1

7 Implementación La implementación de KOC se apoya en el uso de varias tecnologías y proyectos de código abierto siguiendo algunas especificaciones y estándares. A continuación se presenta cada uno de estos componentes y se da una explicación general de su uso, alcance o aspectos que se utilizaron en el proyecto. En la Figura 7-1, muestra las principales tecnologías organizadas según los nodos donde se ejecutan.

Figura 7-1 Esquema de tecnologías utilizadas

7.1 Especificaciones, Herramientas y Tecnologías 7.1.1 Java La aplicación KOC se ha desarrollado en el lenguaje de programación Java. Se eligió este lenguaje de programación por la experiencia personal y por la estrategia en cuanto a su uso llevada a cabo en el departamento de ingeniería de sistemas de la Universidad de los Andes durante los últimos años. Otra ventaja en la utilización de Java consiste en que las aplicaciones pueden correr sobre cualquier sistema operativo que cuente con una JVM (máquina virtual Java).

7.1.2 Java EE Java Enterprise Edition consiste en la especificación para aplicaciones empresariales hecha por Sun Microsystems sobre Java, al ser una especificación para ambientes empresariales es bastante complejo y tiene muchos componentes que se pueden usar o no opcionalmente. Consiste básicamente en el funcionamiento de un contenedor en el que se despliegan las aplicaciones encargándose de requerimientos no funcionales y controlando el ciclo de vida de la aplicación. Por otro lado la especificación permite compartir recursos entre múltiples aplicaciones, como es el caso del pool de conexiones a la base de datos. La utilización de JEE en KOC se restringe al uso de los APIs de transacciones JTA (Java Transactions API), el uso de un contenedor de Servlets y JSP

7-2

(particularmente Apache Tomcat), el uso de recursos compartidos por medio de la interfaz de nombres JNDI como las fuentes de datos y el pool de conexiones y la especificación de persistencia que se explica a continuación.

7.1.2.1 JPA Java Persistence API. Es una parte de la especificación de JEE 5 que simplifica, hace más transparente y portable el acceso a datos. Según (65) "JPA se encarga de la manera en que los datos relacionales son traducidos a objetos persistentes en Java, de la manera en que los datos son persistidos para ser accedidos posteriormente y la existencia continuada de un estado de la entidad inclusive después de que la aplicación lo utilice. Además de la simplificación del modelo de persistencia, JPA estandariza el mapeo objeto-relacional". JPA posibilita intercambiar implementaciones específicas de proveedor siempre y cuando cumpla con este estándar.

7.1.3 Eclipse El ciento por ciento del desarrollo del código Java en KOC se llevo a cabo en Eclipse. Es una herramienta IDE, ambiente de desarrollo integrado, que facilita y acelera el desarrollo de aplicaciones por medio de su interfaz e infraestructura. Eclipse tiene arquitectura basada en los plugins que proveen extensibilidad y capacidad de integración con herramientas que proveen distintos tipos de funcionalidades. Se utilizaron tres plugins fundamentalmente: el plugin de integración con Apache Ant que permite la automatización de tareas como el despliegue, el armado y la compilación; el plugin Servers que permite levantar y bajar el servidor con la facilidad de tener todos los mensajes de la consola dentro del editor y el plugin de Spring IDE, que verifica que las clases y archivos de configuración de Spring Framework estén consistentes.

7.1.4 Spring Framework KOC está implementado utilizando Spring Framework (60), un contenedor que combina el uso del patrón de inyección de dependencia y la programación orientada por aspectos (AOP) y cuyo objetivo es proveer un modelo de programación unificado en el que el código está implementado en objetos simples o POJOs (Plain Old Java Objects) (63). El modelo de componentes utilizado por Spring Framework motiva al bajo acoplamiento ya que por medio de interfaces hace intercambiables las implementaciones específicas sin necesidad de alterar el código fuente sino simplemente un archivo de configuración, es decir, Spring se encarga de la instanciación, configuración, ensamblaje y decoración de los objetos. Una de las características más importantes de Spring es la facilidad de integración con librerías y módulos de terceras partes, así como su portabilidad entre diferentes contenedores JEE y servidores Web.

En la capa Web se utiliza un sub proyecto de Spring Framework llamado Spring MVC, que como su nombre lo indica implementa el patrón MVC explicado anteriormente. Spring MVC provee, entre muchas otras cosas, dos tipos de controladores claves; un controlador multi-acción, extendiendo la clase MultiActionController, que básicamente sirve para encadenar pedidos a métodos del controlador y cada uno de estos métodos retorna una vista con su modelo ya asociado. Este tipo de controlador se utiliza para realizar llamados a procedimientos puntuales, típicamente se utiliza para el caso de eliminar objetos. Otro tipo de controlador que provee Spring MVC es el SimpleFormController cuya función es realizar todo el proceso de encadenamiento de formularios (descritos típicamente en HTML) a objetos Java. Además de llevar a cabo este encadenamiento, Spring MVC permite hacer validaciones de los datos de entrada y permite manejar el ciclo de vida en cada etapa del encadenamiento. Adicional a estos dos tipos de controladores se

7-3

implementó el JsonFormController que permite reutilizar todas las ventajas del SimpleFormController anteriormente explicadas pero extrapolándolas para solicitudes en formato JSON (Javascript Object Notation) usualmente enviadas en llamados asincrónicos Ajax.

7.1.5 Hibernate Es una herramienta ORM (Object Relational Mapper) cuya función es traducir conceptos propios del modelo relacional (como tablas, filas, columnas, llaves) al modelo orientado por objetos (es decir, clases, objetos, referencias). Por medio de configuración, anotaciones en el caso de KOC, se hacen los mapeos entre conceptos del mundo OO y conceptos netamente relacionales.

Hibernate domina el mercado dentro de las herramientas de persistencia de código abierto y a lo largo de varios años ha demostrado solidez, confiabilidad y madurez, además de contar con una de las comunidades más activas en el mundo Java. Hibernate permite hacer portable el código fuente de la aplicación entre varios tipos de bases de datos. A su vez Hibernate está basado en JDBC.

7.1.6 OSGi Es la especificación de un framework (66) que provee modularidad, versionamiento y manejo del ciclo de vida de componentes en Java; además maneja un modelo de servicios basado en el uso de interfaces que incentiva al bajo acoplamiento en las aplicaciones que lo utilizan. Se ha probado su utilidad desde ambientes móviles hasta empresariales. Se utilizó la implementación específica realizada por el proyecto Apache Felix (67) en conjunto con el soporte ofrecido por Spring para OSGi mediante el sub proyecto Spring Dynamic Modules (68).

7.1.7 MySQL Se utilizó este sistema manejador de base de datos por su facilidad de instalación y estabilidad. La manipulación de las tablas se hizo principalmente mediante las operaciones de creación, poblamiento y eliminación, todas invocadas desde las tareas de Ant para este propósito.

7.1.8 Javascript Para la interacción con el usuario se utilizó este lenguaje de programación. Javascript tiene un API para acceder al DOM de las páginas web y dinámicamente hacer cambios de presentación, además tiene un conjunto de instrucciones que permiten implementar lógica de acuerdo a la complejidad de la interfaz gráfica. Debido al bajo nivel que maneja Javascript por sí solo y a la falta de componentes gráficos y un modelo unificado de programación se utiliza el proyecto Dojo Toolkit.

7.1.9 Dojo Toolkit Se compone de un conjunto de herramientas y utilidades para el desarrollo de aplicaciones web usando javascript como lenguaje de scripting. Dojo Toolkit se compone de tres grandes partes que soportan la infraestructura de toda la interfaz de usuario. Dojo, es el núcleo y provee funcionalidades básicas y comunes para toda la aplicación como: extensiones a Javascript, sistema de empaquetamiento y compresión, logger, internacionalización, etc. Dijit, es el modelo de componentes gráficos, también llamados Widgets, facilitan la interacción con el usuario, en él se tienen los campos de entrada para formularios, calendario para selección de fechas, contenedores de diagramación, entre muchos otros. Dojox, contiene funcionalidades en experimentación o cuyo API puede

7-4

cambiar con el tiempo. La comunicación entre el cliente y el servidor en muchos casos se hace usando el formato JSON (69) ya que la mayoría de Widgets lo "entienden" por defecto mediante las interfaces dojo.data. Adicional al Dojo Toolkit se utiliza en algunos casos el sub proyecto DWR, que permite la generación automática de proxies en Javascript a partir de clases Java, serializando todos sus contenidos como atributos y métodos.

7.1.10 OWL Ontology Web Language. Es un lenguaje basado en XML, que extiende RDF y RDFs para la definición de ontologías. Así mismo es un sucesor de los lenguajes DAML+OIL. OWL tiene tres representaciones dependiendo del grado de expresividad y del potencial de realizar inferencia: OWL-Lite que es la versión más liviana pero más restrictiva, OWL-DL que se basa en la lógica descriptiva para especificar restricciones lógicas y predicados y OWL-Full en la que hay completa libertad pero por ello no es posible matemáticamente realizar inferencia. La ontología ArCo se describió en OWL-DL.

7.1.11 Protégé Protégé es una herramienta desarrollada por la Universidad de Standford (70), sirve como un IDE (Ambiente de Desarrollo Integrado por su sigla en inglés) para la construcción de ontologías. Consta de una interfaz gráfica que permite modelar conocimiento de un dominio específico en términos de conceptos propios de las ontologías como clases, propiedades, restricciones e instancias permitiendo al autor visualizar gráficamente la estructura y cada uno de los componentes de la ontología. Una de las características de Protégé es que exporta el modelo creado a varios formatos estándares como RDF, OWL, entre otros. Además, en caso de estar modelando una ontología en formato OWL, por medio del plugin OWLViz desarrollado por Horridge (71) de la universidad de Manchester se puede visualizar la ontología gráficamente como un grafo.

Para el desarrollo de KOC se utilizó Protégé para modelar conceptos y relaciones de ArCo base en OWL. Tal como se puede apreciar en la Figura 7-2. Una visualización de la ontología ArCo base como un grafo generado a partir de OWLViz(71) se encuentra en la Figura 4-1.

7-5

Figura 7-2 Interfaz de usuario de Protégé. La figura muestra el modelaje de ArCo base

7.1.12 Jena Es una librería (72) que ofrece un API para acceder programáticamente a documentos estándar de ontologías como RDF y OWL. Adicional a esto Jena provee un motor de inferencia basado en reglas y un motor de búsqueda que soporta SPARQL. Jena es un proyecto de HP Labs.

La utilización de Jena en KOC es bastante básica y se divide en dos partes: la lectura del documento OWL de ArCo base generado por Protégé y en el armado de un nuevo documento OWL poblado con las instancias recuperadas de las tablas referentes a ArCo en la base de datos. Este documento puede ser visualizado nuevamente en Protégé por el usuario ingresando la URL respectiva que genera una solicitud a KOC.

8-1

8 Estado actual y Resultados El estado actual del proyecto KOC puede verse desde diferentes perspectivas: la definición conceptual, el desarrollo de la herramienta informática y la generación de contenido.

Desde el punto de vista conceptual, después de varias revisiones e iteraciones en el diseño de ArCo y la especificación de sus conceptos, se ha logrado una etapa de madurez que se refleja en la capacidad de expresión para definir objetos de construcción. ArCo parece responder a las necesidades básicas de los anotadores y su sistema de solicitudes combinado con la facilidad de administración hace su extensibilidad posible y controlada.

Mirando el desarrollo de la herramienta, también se han pasado por varias versiones y rediseños, en donde la retroalimentación de sus usuarios ha sido fundamental para mejorar los esquemas de interacción y usabilidad. En términos de infraestructura, KOC también ha mejorado y dada la experiencia que se ha obtenido a lo largo del desarrollo del proyecto se han solucionado problemas comunes haciendo la plataforma más estable y fácilmente escalable.

Teniendo en cuenta la generación de contenidos; ya hay una gran cantidad de material recolectado a partir de la construcción del edificio Mario Laserna de la Facultad de Ingeniería de la Universidad de los Andes, la cual está siendo ingresada incrementalmente a KOC. Por otro lado se encuentran los datos recolectados de los proyectos actualmente en proceso de construcción del Nuevo Edificio W para las facultades de matemáticas y física y el nuevo centro cultural y deportivo de la Universidad. Las métricas muestran un total de 154 datos, 72 anotaciones y 4 proyectos que existen actualmente en KOC.

Durante el segundo semestre del año 2008 se va a poner a prueba el proyecto KOC durante el desarrollo de un curso de pregrado en la facultad de arquitectura de la Universidad de los Andes, el objetivo de este curso es aplicar la metodología de casos de estudio al área técnica de la arquitectura. Este curso va a ser dictado por el arquitecto Rafael Villazón.

Por último, cabe anotar que el proyecto KOC ha sido presentado en varias ocasiones a expertos y docentes en el tema de construcción de edificios por medio de varias publicaciones y exposiciones. Entre ellas se destaca el artículo en la revista de Avances en Sistemas e Informática (3), la presentación en la Sociedad Colombiana de Ingeniería de Sistemas (73) y en el Congreso Colombiano de Computación (CCC) (74).

La propuesta del proyecto KOC resultó ganadora para el premio HP Technology for Teaching Grant Award en meses pasados, que financia al proyecto con recursos hardware, representados en varios dispositivos móviles y periféricos. En la sección 10.3.1 del trabajo futuro se explica en qué consistió la propuesta.

En general el proyecto ha tenido una buena acogida generando a su vez retroalimentación valiosa para el proyecto.

9-1

9 Conclusiones El proyecto KOC ya ha mostrado grandes beneficios con su aplicación en contextos académicos y su aporte no debe ser limitado por el esfuerzo que representa para los autores la elaboración y consulta de objetos de alto nivel. Las herramientas de autoría tratan de resolver este problema y su objetivo principal es romper la barrera con la que hasta ahora se han encontrado los autores, asistiéndoles y ayudándoles a componer objetos compuestos de alto nivel y alto contenido semántico, listos para ser explotados por agentes de software, actores principales de la Web Semántica.

KOC surge en un momento clave en el que los programas de pregrado en Arquitectura e Ingeniería Civil buscan aumentar al máximo el tiempo efectivo que sus estudiantes dedican al estudio de los temas centrales de la disciplina de la construcción y en general del problema técnico de los proyectos. El poco tiempo dedicado a la enseñanza de estos temas sumado a la inexistencia de una política en las instituciones de educación superior que propicie una dinámica de aprendizaje continuo, justifica la existencia de un sistema como KOC, que permite hacer más eficiente el tiempo de aprendizaje de estudiantes, profesores y profesionales de la construcción.

KOC permite que una universidad, que tiene su mayor capital concentrado en su equipo humano y el conocimiento generado a lo largo de muchos años de trabajo docente e investigativo, genere una política y estrategias eficientes para el registro y conservación del conocimiento. Esto es determinante, ya que los métodos tradicionales como las publicaciones, tanto impresas como virtuales, suponen unos tiempos de desarrollo relativamente extensos, que seguramente se pueden ver acortados mediante el manejo inteligente del conocimiento existente y el aprovechamiento de las tecnologías de información alrededor de temas disciplinares centrales, soportados directamente en KOC, ArCo y las herramientas de autoría.

Como resultado concreto de mi aporte al proyecto, la implantación de las herramientas de autoría y la infraestructura necesaria para soportarlas, se notó que la correcta reutilización y encadenamiento de conocimiento existente por parte de expertos en el dominio, resulta en la generación de nuevos objetos de conocimiento, cuya semántica muestra un valor agregado y enriquece los contenidos del sistema haciéndolos más accesibles y fáciles de generar mediante la implantación de las herramientas de autoría.

Desde el punto de vista práctico y con la experiencia de haber apoyado en el diseño y modelaje de la ontología ArCo, se ha demostrado la efectividad del uso de ontologías para la formalización y administración del conocimiento, para facilitar la comunicación entre profesores y estudiantes, para hacer explícita la semántica del dominio del área técnica en arquitectura. Sin embargo el potencial de las ontologías se puede explotar aún más al ser utilizadas como una tecnología de integración de datos, eventualmente entre varias instancias de KOC o con otros sistemas.

10-1

10 Trabajo Futuro El proyecto KOC dista de estar finalizado o completo en un ciento por ciento. Existen muchas áreas donde se puede extender, complementar y continuar, ya sea en términos de desarrollo de nuevas funcionalidades, integración con otros sistemas o utilización en otros contextos. En esta sección se presenta un espectro, que trata de ser comprehensivo, en cuanto al trabajo futuro por llevar a cabo en el proyecto. En algunos casos se presentan ejemplos, metodología, impacto esperado o simplemente ideas que podrían resultar interesantes en el futuro del desarrollo de KOC. El trabajo futuro se organiza en cuatro secciones: difusión del proyecto, desarrollo y mantenimiento,

10.1 Difusión 10.1.1 Convenios con otras universidades Como punto de partida en el trabajo futuro y para poner a prueba el proyecto en otros escenarios diferentes, es fundamental hacer convenios con otras universidades. Existen dos posibilidades para hacerlo; compartir acceso al mismo repositorio entre todas las universidades o replicar una instancia del repositorio por Universidad con que se tenga convenio. La ventaja de usar el primer enfoque es el enriquecimiento del repositorio con nuevos objetos de conocimiento con otros puntos de vista, prácticas, metodologías y usos, generando mayor volumen de debates y retroalimentación dado el alcance inter-universitario. Sin embargo, el segundo escenario se puede acoplar mejor a las necesidades de las facultades ya que restringe la anotación a sus propios datos, seleccionando datos y anotaciones según sus propios objetivos pedagógicos. El impacto de la utilización de KOC en otras universidades puede ser enorme y se puede aportar colaborativa y mutuamente entre varias universidades al mejoramiento de la enseñanza de la construcción en sus facultades de arquitectura.

10.1.2 KOC en la industria y en el país Desde el punto de vista de las empresas en la industria de la construcción, la propuesta de KOC también puede resultar muy atractiva. Existen dos casos de uso específicos dentro de las empresas que pueden ser direccionados con la implantación de KOC. El primero consiste en el entrenamiento y capacitación de su personal, haciendo posible mediante el uso del sistema enseñar a nuevos empleados prácticas y metodologías propias de la empresa, acelerando la curva de aprendizaje o para llevar a cabo sesiones de actualización a todo el personal en cuanto a temas específicos tomados de otra fuente. El segundo consiste en el uso de KOC como una herramienta de administración de conocimiento que contiene los registros de la memoria corporativa de la empresa y el inventario de datos recolectados en cada proyecto realizado, de esta manera es posible mediante la consulta de históricos y el seguimiento de procesos de calidad lograr mejoramiento continuo y al mismo tiempo aumentar cada vez más el valor de sus activos intelectuales.

En el contexto de una empresa la solución que mejor se podría ajustar consiste en la replicación de una instancia de KOC que funcione internamente para la empresa. Por cuestiones de seguridad en cuanto a datos confidenciales, ventajas competitivas, control de los datos, etc. está elección puede ser muy conveniente. Sin embargo, se daría el potencial para que las empresas donaran sus objetos de conocimiento a la academia y viceversa, así y de este modo compartir el máximo de conocimiento y promover la innovación.

10-2

Las perspectivas de desarrollo de KOC, visto dentro de un contexto más amplio tienen un gran potencial, ya que el sistema puede establecer las bases para la definición de una verdadera política tecnológica dentro del medio colombiano, al proponer una estrategia de documentación y manejo del conocimiento técnico generado en los proyectos de construcción, los cuales seguramente se podrán convertir en uno de los motores para mover la innovación tecnológica dentro de las diferentes comunidades académicas y profesionales o al menos para establecer las prácticas normales de construcción dentro del medio local, con el ánimo de establece sus estándares ideales.

10.2 Desarrollo y Mantenimiento 10.2.1 Mantenimiento y Extensión de ArCo Aunque se considera que la ontología ArCo está en una versión estable, está lejos de ser finalizada. En especial, ArCo carece de detalles en cuanto a la especificación de reglas, sinónimos y restricciones, lo cual dificulta la tarea de inferir lógicamente o automatizar procesos. Por otro lado existe una serie de relaciones que actualmente no se están teniendo en cuenta pero que se pueden hacer explícitas para refinar y mejorar ArCo, como por ejemplo la relación que tienen arquetípicamente los materiales y las funcionalidades. Otra opción que se puede contemplar en la evolución de ArCo es definir subclases restringiendo el uso de ciertas propiedades, como es el caso de una Oficina Aislada Acústicamente definida como subclase del espacio Oficina con la restricción de existencia de la funcionalidad Aislamiento Acústico. La implementación de esta característica podría aumentar significativamente el potencial de uso de herramientas, tales como los motores de inferencia, con el fin de poder detectar buenas y malas prácticas automática e inteligentemente a partir de la descripción de la ontología. Por otro lado se facilitaría el aprendizaje de la herramienta y con técnicas de inteligencia artificial (AI) tener la capacidad de ir prediciendo o sugiriendo anotaciones a partir de datos históricos y la estructura de la ontología.

Aún más interesante resulta el hecho de complementar ArCo con ontologías para otros dominios específicos. Potencialmente se podrían crear nuevas ontologías a partir de ArCo para temas como la gerencia de proyectos, manejo de formas y geometrías, gestión de presupuestos, control de calidad, entre otros, todo esto visto desde la perspectiva de la arquitectura.

La evolución de KOC planteada a corto plazo, consiste en la implementación de un conjunto de herramientas que aprovechen el modelo de datos de las herramientas de autoría para ofrecer funcionalidades pedagógicas y de esta manera empezar a dar forma a la estrategia de e-learning que se quiere proyectar en KOC. Estas herramientas se han denominado como herramientas de tutoría y se diseñaron algunas de ellas.

10.2.2 Estandarización Como se enunció en la sección 4.1 el seguimiento a estándares es un principio fundamental para el proyecto KOC y aunque se ha tratado de cumplir consistentemente todavía existen muchos otros estándares que valdría la pena soportar.

En cuanto a estándares que tienen que ver con ontologías y Web Semántica sería conveniente proveer una interfaz de consulta que cumpla con el protocolo e interprete el lenguaje SPARQL.

Desde el punto de vista del e-learning uno de los estándares más importantes es LOM (Learning Object Metadata) encaminado en KOC a complementar los objetos de

10-3

conocimiento, presentados en 4-12, con material pedagógico y convertirlos en objetos de aprendizaje.

10.2.3 Herramientas de Tutoría 10.2.3.1 Ordenador de Procesos Constructivos Se define como una herramienta donde los estudiantes ordenan las actividades de un proceso constructivo según su propio criterio, para posteriormente obtener retroalimentación en cuanto al orden real del proceso. Es similar, en cierta medida, a la aproximación presentada por el AVA Taller Técnico 1 (12), con la diferencia que se aprovecha el poder de expresividad de la ontología ArCo, además del uso de la herramienta de autoría compositor de procesos constructivos como fuente de datos.

10.2.3.2 Solucionador de casos de estudio Consiste en una herramienta que aprovecha al máximo el modelo de datos generado por el profesor al hacer uso de la herramienta de autoría compositor de casos de estudio, para guiar al estudiante en la navegación del caso mediante el despliegue del grafo de situaciones y alternativas; con esto se puede llegar poco a poco a una solución. Esta herramienta permite al estudiante subir al sistema y anotar su solución como soporte de la experiencia que tuvo ante la resolución del caso de estudio y de esta manera persistir en el repositorio, con previa autorización del profesor, para la consulta de otros estudiantes.

10.2.3.3 Generador de exámenes Es una herramienta que aprovecha todas las anotaciones y datos del repositorio para hacer preguntas a los estudiantes a manera de examen. La herramienta debe ser capaz de registrar los errores comunes de los estudiantes y debe ser configurable por el profesor para restringir las preguntas a un tema específico. Alternativamente, se puede aplicar el esquema que el profesor presente a los estudiantes el mismo dato, seleccionado del repositorio y permitirles anotarlo a cada uno independientemente.

10.2.4 Otras Herramientas de Autoría Las tres herramientas de autoría que se presentaron en este documento consisten netamente en tres pruebas de concepto o prototipos iníciales, pero existen otras herramientas de autoría que valdría la pena implementar sobre KOC. Específicamente una de las más relevantes consiste en un compositor de procesos constructivos de espacios a partir de los procesos definidos con la herramienta de autoría de procesos para elementos. Con los procesos de espacios se puede tener un panorama más global de la obra y de más alto nivel con información adicional aún más valiosa. Aparte de ésta, existen otras herramientas de autoría también interesadas en objetos de conocimiento compuestos de alto nivel, algunos ejemplos son: compositor de videos, compositor de artículos o analizadores y compositores automáticos de datos según la información de sus anotaciones.

10.2.4.1 Espacios de trabajo (KOC Workspaces). Se denomina como un espacio de trabajo al área donde los estudiantes pueden hacer experimentos o ejercicios sin la necesidad de alterar los datos reales del sistema. Los estudiantes pueden usar todo el poder de expresividad de ArCo y toda la infraestructura de KOC para hacer anotaciones e inclusive subir al sistema sus propios datos. En cada espacio de trabajo hay un profesor encargado de la calidad de los datos, quien tiene el criterio y la responsabilidad de aprobar o rechazar la publicación de datos ingresados por los estudiantes en el repositorio real en producción de KOC. Se puede tomar como

10-4

referencia el proyecto DIVERCITY (75) que trata la problemática de espacios de trabajo en la industria de la construcción, aunque se limite a revisiones de diseño.

10.3 Integración Desde el punto de vista de integración con aplicaciones de terceros se tiene un panorama prometedor y es un principio clave que se fijo desde un principio. La plataforma KOC incentiva la creatividad de otras aplicaciones y la promueve mediante la integración y la colaboración. Se tiene planeado realizar la implementación de un API, el cual va a ser llamado vía Web Services, la idea con este API es que otras aplicaciones puedan usar los contenidos de KOC para otros subdominios o para aportar nuevos datos y anotaciones a la plataforma. Un caso de uso interesante y de acuerdo a lo planteado en la sección 10.2.2 consiste en la implementación de una interfaz de consulta siguiendo el protocolo SPARQL.

Otra área de la integración que valdría la pena explorar es el desarrollo de módulos de integración con herramientas populares para los arquitectos, algunos ejemplos de ellas son AutoCAD, ArchiCAD, ScketckUp, entre otras. Se propone la gestión del ciclo de vida de los objetos de conocimiento desde una etapa de diseño y el seguimiento de los mismos durante todo el proyecto.

10.3.1 KOC Móvil Presentando como antecedente el recién otorgado HP Technology for Teaching Grant Award, el tema móvil ha despertado gran interés y es un área en la que se van a invertir recursos al corto plazo. La idea de KOC móvil es hacer una aplicación liviana que tenga todo el poder de hacer anotaciones in situ que posteriormente se van a sincronizar con el repositorio existente en el servidor vía una interfaz tipo web service. Un caso de uso de KOC móvil puede ser también el uso de dispositivos móviles livianos para llevar a cabo visitas guiadas donde se pueda consultar información de carácter constructivo en edificios ya finalizados en la etapa de operación. Se puede pensar en el desarrollo de una herramienta de autoría que permita al profesor planear las visitas guiadas y durante el recorrido de indicaciones claves a los estudiantes sobre el recorrido.

10.3.2 KOC Social Como se presentó en la sección 5.4.2 es muy importante preguntarnos QUIÉN participó en la construcción de un proyecto. Aunque se ha implementado la funcionalidad de registro de personas y empresas en la industria de la construcción existe un mayor potencial explorando el lado social de la ecuación. Se propone elaborar una red social de profesionales en la arquitectura y en la construcción que a través de la generación de contenidos auxiliares y un poco más informales a los objetos de conocimiento y a los proyectos, como comentarios, etiquetas y votaciones. Esta funcionalidad daría mayor difusión al proyecto y llevaría a la eventual globalización del conocimiento en el repositorio.

10.3.3 KOC Visual Aplicando técnicas de computación visual se podría enriquecer aun más la experiencia de aprendizaje en KOC. El objetivo consiste en la inmersión del estudiante en un ambiente virtual 3D en el que pueda navegar, experimentar y conocer de manera más directa cómo se construye un edificio. Para lograr este objetivo la primera fase consiste en georeferenciar de manera precisa los proyectos y cada uno de los objetos de construcción. El resultado podría ser un sistema de realidad aumentada que colaborativamente se construye a través de los datos y anotaciones existentes en KOC.

10-5

10.4 Otro Trabajo Futuro Existen otros puntos de extensión a KOC pendientes que no pertenecen a ninguna de las clasificaciones presentadas anteriormente. Entre estos se ubica la internacionalización de los contenidos de KOC y la ontología ArCo; apunta a la visión de un repositorio globalizado, haciendo accesible la totalidad del sistema a usuarios que hablan múltiples idiomas. Por otro lado se han pensado mecanismos que de control y seguimiento encaminados a la calidad de los objetos de conocimiento compuestos y evitar que pierdan la semántica de las conexiones que poseen por un mal uso de los autores. También se ha explorado la adición de nuevas políticas de seguridad y de rigor en cuanto a los datos compartidos, su visibilidad y privacidad permitiendo a los autores y anotadores tener varios niveles configurables de acceso. Está pendiente la "clonación" de objetos de conocimiento que apunta a la reutilización y generación de nuevo conocimiento a partir del existente. Por último se tiene pendiente estructurar y revisar el tema de las lecciones aprendidas, que apoyan directamente la generación de material pedagógico a partir de las buenas y malas prácticas que se encuentran en el repositorio.

11-1

11 Referencias 1. Villazón, R. Documento Base del Área Técnica. Universidad de los Andes, Departamento de Arquitectura. Bogotá : s.n., 2006.

2. —. Sistema de Información para el Apoyo a la Docencia y Gerencia del Conocimiento en Proyectos de Construcción. Tesis de Magíster en Ingeniería Civil. Bogotá : Universidad de los Andes, 2005.

3. KOC - Manejo Ontológico de Objetos de Conocimiento en la Construcción de Edificios. Villazón, R., Bravo G. 2, Medellín : s.n., 2007, Revista Avances en Sistemas e Informática, Vol. IV.

4. ArCo: An Ontology for Architectural Concepts in Construction. Villazón, R., Bravo G., Cifuentes D. Orlando : Knowledge Generation, Communication and Management: KGCM, 2008.

5. Vela, Maria. Documento de Seguimiento de Procesos Constructivos. Bogotá : Universidad de los Andes, 2007.

6. Sarria C., Fernando. Desarrollo e Implementación de una Aplicación de Multimedios en la Enseñanza de la Construcción. Bogotá : Universidad de los Andes, 1994.

7. Luquetta, R. Desarrollo de un aplicación Multimedia en la enseñanza de la construcción – Módulo construcción sistema hidráulico, sanitario y ventilación mecánica. Tesis Magíster Ingeniería Civil. Bogotá : Universidad de los Andes, 1997.

8. Alarcón, Liliana. Mejoramiento continuo de procesos constructivos mediante herramientas digitales. Tesis de Magíster en Ingeniería Civil. Bogotá : Universidad de los Andes, 1998.

9. Arrieta, Rocío. Aprovechamiento del potencial de la informática en el mejoramiento del registro histórico de proyectos de construcción. Bogotá : s.n., 2000.

10. Rodríguez, D. Estructura de división de trabajo unificada para la construcción en Bogotá. Tesis de Magíster en Ingeniería Civil. Bogotá : Universidad de los Andes, 1998.

11. LIDIE. Ambientes Virtuales de Aprendizaje. [Online] LIDIE. [Cited: Mayo 19, 2006.] http://tereque.uniandes.edu.co/ava/portalLidie/modules.php?name=Content&pa=showpage&pid=41.

12. —. Taller Técnico I. AVAteca. [Online] LIDIE. [Cited: Mayo 19, 2006.] http://ava.uniandes.edu.co/modules.php?name=AVALibrary&action=viewAva&avaId=4.

13. Villazón R., Cárdenas C. La Enseñanza de la Técnica en Escuelas de Arquitectura: El Modelo Formativo. Revista Arquitecturas. Bogota : s.n., 2001. 7.

14. Marwick, A. Knowledge Management Technology. [Online] http://www.research.ibm.com/journal/sj/404/marwick.html.

15. Ei-Diraby T., Zhang, J. A semantic framework to support corporate memory management in building construction. Automation in Construction. 2006. Vol. 4, 15.

16. Kamara, J., Augenbroe G., Anumba C., Carrillo P. Knowledge Management in the Architecture, Engineering and Construction Industry. Construction Innovation: Information, Process, Management. 2002.

17. John M. Kamara, Chimay J. Anumba and Patricia M. Carrillo. A CLEVER approach to selecting a knowledge management strategy.

11-2

18. Chen, Zhen, et al. An analytic knowledge network process for construction entrepreneurship education. The Journal of Management Development. 2006. Vol. 25, 1.

19. Christiansson, Per. NEXT GENERATION KNOWLEDGE MANAGEMENT SYSTEMS FOR THE CONSTRUCTION INDUSTRY. CIB W78 Proceedings Construction IT Bridging the Distance. Auckland : s.n., 2003.

20. Sven-Eric Schapke, Karsten Menzel, Raimar J. Scherer. Towards Organizational Memory Systems in the Construction Industry.

21. Ontology Languages for the Semantic Web. Gómez-Pérez, A and Corcho, O. s.l. : IEEE Intelligent Systems, 2002, Vol. I.

22. Pollock, J., Hodgson, R. Adaptive Information: Improving Business Through Semantic Interoperability, Grid Computing, and Enterprise Integration. s.l. : Wiley, 2004.

23. The Semantic Web. Berners-Lee, T., Hendler, J., & Lassila, O. s.l. : Scientific American, 2001.

24. Antoniou, G., van Harmelen, F. A Semantic Web Primer. s.l. : MIT Press, 2004.

25. Ei-Diraby T., Zhang, J. Semantic documentation of lessons learned in the building construction industry. 2004.

26. e-Cognos Project. [Online] http://e-cognos.cstb.fr/.

27. Wetherill, M., Rezgui, Y., Lima, C. & Zarli, A. Knowledge management for the construction industry: the e-Cognos project. Electronic Journal of Information Technology in Construction. 2002. Vol. 7.

28. British Standards Institute. BSI 6100-2.5+ Glossary of building and civil engineering terms. Londres : s.n., 1991.

29. Construction Specification Institute. CSI Master Format. 2004.

30. Construction Project Information Committee (CPIC). UniClass: Unified Classification for the Construction Industry. 1997.

31. Continuing Education Center. Unveiling The New MasterFormat 2004 Edition. [Online] 2005. [Cited: Agosto 18, 2007.] http://continuingeducation.construction.com/article.php?L=12&C=331&P=4.

32. Drucker, P. Need to Know: Integrating e-Learning with High Velocity Value Chains. [Online] 2000. [Cited: Julio 13, 2008.] http://www.delphigroup.com/pubs/whitepapers/20001213-e-learning-wp.pdf.

33. Vittorio Spigai, Massimiliano Condotta, Cristina Stefanelli. Collaborative E-Learning in Engineering and Architecture: Intellingent Systems for Knowledge Sharing in Online Desgin Laboratories. Joint International Conference on Computing and Decision Making in Civil and Building Engineering.

34. A.Z. Sampaio, P.G. Henriques, P.S. Ferreira. A Virtual Environment Tool Applied to Visualize Construction Processes. Proceedings of the Theory and Practice of Computer Graphics. 2004.

35. Education and the Semantic Web. Devedzic, V. 14, s.l. : International Journal of Artificial Intelligence in Education, 2004.

36. Ljiljana Stojanovic, Steffen Staab, Rudi Studer. eLearning based on the SemanticWeb.

11-3

37. Abel, M.-H., Benayache, A., Lenne, D., Moulin, C., Barry, C., & Chaput, B. Ontology-based Organizational Memory. Educational Technology & Society. 2004. Vol. 4, 7.

38. Vian Ahmed, Azmath Shaik and Ghassan Aouad. An Ontology of Construction Education for E-learning via the Semantic Web. Architectural Engineering and Design Management. 2006. Vol. 2.

39. Authoring Intelligent Tutoring Systems: An analysis of the state of the art. Murray, T. s.l. : International Journal of AI in Education, 1999.

40. Harris, J. An Introduction to Authoring Tools. [Online] Marzo 2002. [Cited: Mayo 16, 2008.] http://www.learningcircuits.org/2002/mar2002/harris.html.

41. An Adaptive Hypermedia Presentation Modeling System for Custom Knowledge Representations. Castells, José A. Macías and Pablo. Orlando : World Conference on the WWW and Internet, 2001.

42. An Authoring Tool for Building Adaptive Learning Guidance Systems on the Web. Castells, José A. Macías and Pablo. Madrid : E.T.S. Informática, 2001.

43. Ontological Support for Web Courseware Authoring. Aroyo, L. Dicheva, D. Cristea, A. Berlín : ITSí02, Intelligent Tutoring Systems, 2002.

44. Cifuentes, David. Página Oficial Proyecto KOC. [Online] Universidad de los Andes, 2008. http://sites.google.com/site/proyectokoc.

45. Heidegger, M. Construir, Habitar, Pensar. Traducción de Eustaquio Barjau en conferencias y artículos. Barcelona : Serval, 1994.

46. Rush, R. The Building systems integration handbook American Institute of Architects. 1986.

47. Paricio, I. La Construcción de la arquitectura. ITCC. 1995.

48. El Estudio de Casos como Técnica Didáctica. Las Estratégias y Técnicas Didácticas en el Rediseño. Monterrey : s.n.

49. Roberts, M.J. Developing a Teaching Case (Abridged). Harvard Business School. Boston : Harvard Business School Publishing, 2001.

50. A Comparative Evaluation of Socratic versus Didactic Tutoring. Penstein Ros, Carolyn, et al. Morriston : Association for Computational Linguistics, 2003.

51. Estudio de caso como instrumento didáctico para la enseñanza de la arquitectura: proyectar una fachada. Villazón, R. 01, Bogotá : Taller de Publicaciones Uniandes, 2007.

52. Apache Software Foundation. Apache Commons. [Online] [Cited: Julio 13, 2008.] http://commons.apache.org/.

53. Google Inc. Google Maps. [Online] http://code.google.com/apis/maps.

54. MIT Libraries. Simile Project. [Online] MITCSAIL. http://simile.mit.edu/.

55. Abdelnur, A., Chanezon, P., Chien, E. Project Rome. Java .net. [Online] https://rome.dev.java.net/.

56. Shay, B. Compass Project. [Online] Open Symphony. http://www.compass-project.org/.

11-4

57. Wijering, J. JW FLV Media Player. [Online] http://www.jeroenwijering.com/?item=JW_FLV_Player.

58. IDR Solutions. JPedal. [Online] http://www.jpedal.org/.

59. Bruno Lowagie, Adolf Baeyensstraat. iText. [Online] [Cited: Julio 13, 2008.] http://www.lowagie.com/iText/.

60. Spring Source. Spring Framework. [Online] http://springframework.org/.

61. Search Security. [Online] [Cited: Julio 13, 2008.] http://searchsecurity.techtarget.com/sDefinition/0,,sid14_gci514544,00.html.

62. Fowler, Martin. Inversion of Control Containers and the Dependency Injection Pattern. Martin Fowler Bliki. [Online] [Cited: Julio 13, 2008.] http://www.martinfowler.com/articles/injection.html.

63. Johnson, Rod. J2EE Development Frameworks. IT Systems Perspectives. 2005.

64. Danijel Matid, Dino Butorac and Hrvoje Kegalj. Data Access Architecture in Object Oriented Applications Using Design Patterns. IEEE MELECON 2004. 2004.

65. Biswas, Rahul and Ort, Ed. The Java Persistence API - A Simpler Programming Model for Entity Persistence. Sun Developer Network. [Online] Mayo 2006. [Cited: Julio 13, 2008.] http://java.sun.com/developer/technicalArticles/J2EE/jpa/.

66. OSGi Alliance. [Online] [Cited: Julio 13, 2008.] http://www.osgi.org/Main/HomePage.

67. Apache Software Foundation. Apache Felix. [Online] [Cited: Julio 13, 2008.] http://felix.apache.org/site/index.html.

68. Spring Source. Spring Dynamic Modules for OSGi. [Online] http://www.springframework.org/osgi.

69. JSON. Javascript Object Notation. [Online] [Cited: Julio 13, 2008.] http://json.org/.

70. Stanford University. The Protégé Ontology Editor and Knowledge Adquicition System. [Online] http://protege.stanford.edu/.

71. Horridge, Matthew. OWLViz. CO-ODE. [Online] University of Manchester. [Cited: Julio 13, 2008.] http://www.co-ode.org/downloads/owlviz/.

72. HP Labs. Jena Semantic Web Framework. [Online] [Cited: Julio 13, 2008.] http://jena.sourceforge.net/.

73. Asociación Colombiana de Ingenieros de Sistemas. ACIS. [Online] [Cited: Julio 13, 2008.] http://www.acis.org.co/index.php?id=1031.

74. Universidad Javeriana. Segundo Congreso Colombiano de Computación. Bogotá : s.n., 2007.

75. Per Christiansson, Laurent Da Dalto, Jens Ove Skjaerbaek, S. Soubra & M. Marache. Virtual Environments for the AEC sector. The Divercity experience.

76. El Estudio de Casos como Técnica Didáctica. Martínez Sánchez, Amparo. 9, Monterrey : Innovación educativa, 1999.

77. Semantic Web Services. 16, s.l. : IEEE Intelligent Systems, 2001, Vol. II.

78. Glenn E. Krasner, Stephen T. Pope. A cookbook for using the model-view controller user interface paradigm in Smalltalk-80. Journal of Object-Oriented Programming. 1988. Vol. 1, 3.

11-5

79. Moritz Stefaner, Elisa Dalla Vecchia, Massimiliano Condotta, Martin Wolpers, Marcus Specht, Stefan Apelt and Erik Duval. Creating New Learning Experiences on a Global Scale. Second European Conference on Technology Enhanced Learning. Creta : s.n., 2007. Vol. 4753.

80. Fuertes, Alba. De Jong, Tim. Specht, Marcus. Casals, Miquel. Mobile learning in a Real-World Construction Engineering Scenario.

81. Sun Microsystems. MySQL Server. [Online] http://www.mysql.com/.

82. W3C. World Wide Web Consortium. W3C. [Online] [Cited: 05 16, 2008.] http://www.w3.org.

83. —. RDF Data Access Working Group. [Online] http://www.w3.org/2001/sw/DataAccess/.

84. —. W3C Semantic Web Activity. [Online] http://www.w3.org/2001/sw/.

85. —. Web Ontology Language (OWL). [Online] http://www.w3.org/2004/OWL/.

86. JBoss. Hibernate. [Online] http://www.hibernate.org/.

87. Noy, N., McGuinness, D. Ontology Development 101: A Guide to Creating Your First Ontology. 2000.

88. Eisenhardt, K. Building Theories from Case Study Research. Academy of Management Review. 1989. 14.

89. McIlraith, S.A., Son, T.C., & Zeng, H. Semantic Web Services. IEEE Intelligent Systems. 2001. Vol. 2, 16.

90. Format, CSI Master. Construction Specification Institute. 2004.

91. González, J., Casals A. The Teaching Strategies of Architectural Construction. Informes de la Construcción. 2001. Vol. 53, 474.

92. Quaroni, L. Proyectar un edificio: Ocho Lecciones de arquitectura. Madrid : Xarait Ediciones, 1980.

12-1

12 Anexos 12.1 Modelo Entidad Relación El modelo entidad relación es uno de los artefactos más importantes durante las etapas de diseño en cada ciclos en el desarrollo de la aplicación. Este modelo muestra las entidades (tablas en la base de datos) con sus atributos tipados y las relaciones entre entidades (llaves foráneas). Para facilidad de entendimiento y organización se dividió el modelo en varias zonas. A continuación se explica cada una de ellas.

12.1.1 Zona ArCo

Fig. 1 Zona ArCo

Como se puede apreciar en la Fig. 1 Zona ArCo la zona ArCo es la que tiene mayor cantidad de entidades y relaciones. Esta zona modela relacionalmente la ontología ArCo.

12-2

Hay algunos detalles que vale la pena resaltar. Al no estar soportada la herencia múltiple en Java y dada la complejidad de traducción en el modelo relacional, ya que un Elemento es un Objeto de Construcción y al mismo tiempo un nodo de la WBS, se optó por replicar las instancias de la entidad, teniendo entradas en la tabla WBS y en la tabla Elemento; con una llave foránea a su registro en la WBS. Las relaciones entre Objeto de Construcción y Funcionalidad o Grado de desempeño son llamados funcionalidades arquetípicas ya que representan el comportamiento ideal y por defecto de todas las instancias reales. La relación entre Espacio y Elemento no es explícita en la ontología ya que es imposible determinar cuáles elementos componen un espacio idealmente siendo esto un resultado de las necesidades de proyectos específicos; esta relación está explícita en las anotaciones.

12.1.2 Zona Datos

Fig. 2 Zona Datos

Los datos, proyectos y entidades auxiliares están agrupados en esta zona. Más específicamente las entidades auxiliares de las que se está hablando se dividen en cuatro grupos: industria de la construcción, manejo de archivos, manejo de fuentes y información de localización. En el grupo de la industria de la construcción se encuentra los registros de Ejecutor o participante en el diseño y la construcción del proyecto, el rol de cada que juega en cada proyecto y la distinción entre personas (Ejecutor e Integrante) y empresas (únicamente Ejecutor), teniendo en cuenta la posibilidad que una persona puede trabajar en una empresa. Para el grupo de manejo de archivos se registra el formato con información adicional que puede ayudar a los usuarios y un filtro de formatos por tipo de dato (por ejemplo las presentaciones se restringen a formatos PPT y PPS). Las fuentes tienen la misma estructura explicada en 5-8. Por último para clasificar la localización se cuenta con tablas de País y Ciudad.

12-3

12.1.3 Zona Objetos de Conocimiento

Fig. 3 Zona Objetos de Conocimiento

Los objetos de conocimiento están representados en la tabla del mismo nombre, de ellos se persiste independientemente la fecha de anotación y la última fecha de actualización, además de los atributos explicados en 4-12. Existe una tabla que relaciona objetos de conocimiento unos con otros y sirve principalmente para definir la red de relación de los objetos compuestos.

12.1.4 Zona Administración La zona de administración contiene las tablas de registro de cambios y solicitudes, explicados en 5-7 además de usuarios y roles de usuario, explicado en 5-1.

Fig. 4 Zona administración

12-4

12.1.5 Zona Anotaciones Modela relacionalmente la estructura presentada en 4-13. Vale la pena anotar que los datos extra recolectados en las anotaciones persisten como atributos de estas tablas; como las calificaciones en Anotación Elemento, las dimensiones en Anotación de Objeto de Construcción, el orden, número de personas, duración en Anotación Paso.

Fig. 5 Zona anotaciones

12.1.6 Zonas de Herramientas de Autoría En las Fig. 6 Zona Búsqueda, Fig. 7 Zona procesos, Fig. 8 Zona Casos de Estudio, se muestran las zonas respectivas a las herramientas de autoría implementadas. Vale la pena anotar que las herramientas de tutoría propuestas en 10-2 fueron diseñadas en el modelo entidad relación mas no implementadas en KOC.

12-5

Fig. 6 Zona Búsqueda

Fig. 7 Zona procesos

12-6

Fig. 8 Zona Casos de Estudio

12.1.7 Zona Workspaces Para la herramienta de tutoría de Workspaces presentada en 10-3, también se hizo el diseño relacional. La estrategia a utilizar consiste en el manejo de datos del Workspace dentro de KOC igual que los datos comunes y corrientes con la diferencia de la visibilidad a los usuarios con la inclusión del atributo estado en la tabla Dato. Al aprobar los datos del Workspace se cambia el valor de éste atributo y los datos son visibles a todo el que los consulte.

Fig. 9 Zona workspaces