Las Ontologías en el mantenimiento del software Ontologies in Software Maintenance Edgar Serna Montoya



Descargar 103,16 Kb.
Fecha de conversión30.08.2017
Tamaño103,16 Kb.

Las Ontologías en el mantenimiento del software

Ontologies in Software Maintenance
Edgar Serna Montoya

Grupo de investigación SISCO. Fundación Universitaria Luis Amigó

Trv. 51A 67B-90. Medellín, Colombia.

edgar.sernamo@amigo.edu.co



RESUMEN

Muchos documentos describen diseños ontológicos, pero pocos explican cómo se puede diseñar una ontología; además, muy pocos se enfocan en la aplicación de técnicas de gestión del conocimiento para el mantenimiento del software. En este trabajo se hace un análisis de varias de las ontologías propuestas para responder a esta necesidad, con la finalidad de que algunas de sus ideas puedan ayudar a las organizaciones de desarrollo de software en trabajos similares, y se describe una metodología para estructurar una ontología que, además del área del mantenimiento del software, pueda aplicarse en otras áreas del conocimiento.


Palabras clave: Gestión del conocimiento, Mantenimiento de software, Ontología.
ABSTRACT

Many papers describe ontological designs but few explain how to design ontology. Moreover, very few focus on applying knowledge management techniques for software maintenance. This paper provides an analysis of several of the ontology’s proposed to address this need, in order that some of their ideas can help software development organizations in similar work, and describes a methodology for structuring an ontology that, besides the area of software maintenance, can be applied in other areas of knowledge.
Keywords: Knowledge management, Ontology, Software maintenance.
1. INTRODUCCIÓN

Para realizar trabajos eficientes en los modelos de Ingeniería de Software y aplicarlos en cada una de sus fases, el conocimiento requerido es variado, de grandes proporciones y en incremento constante. La investigación en Ingeniería de Software se orienta hacia la gestión del conocimiento, procurando tomar las mejores decisiones y proporcionando a las organizaciones la información que requieren para el desarrollo de estas fases [1].


La fase de mantenimiento del software es una actividad en la que el conocimiento juega un importante rol; el nivel de conocimiento de los encargados de realizarla es complejo, voluminoso e intensivo en áreas como: el dominio del programa, de la organización que lo utiliza, el pasado y presente de las prácticas de Ingeniería de Software, los diversos lenguajes de programación, la metodología de programación utilizada, las relaciones entre los diferentes módulos, las herramientas necesarias, entre otras [2]. Con frecuencia, la información necesaria para desarrollar este rol no se encuentra o es muy difícil de localizar y reconstruir; por ello, para realizar su labor, los encargados deben realizar consultas en la escasa documentación disponible o a través de compañeros de trabajo, lo que origina que parte del conocimiento existente en los grupos de mantenimiento se pierda o que no se utilice [3].
La gestión del conocimiento provee técnicas y métodos que ayudan a reducir la pérdida o el desaprovechamiento de conocimiento, y permite que los encargados del mantenimiento de software puedan compartirlo [4]; a las organizaciones de desarrollo y mantenimiento de software, les asegura beneficios como mejoras de la calidad de sus productos y procesos, y la reducción de costos y errores [5]. Sin embargo, antes de iniciar procesos de desarrollo de sistemas de gestión del conocimiento, es importante identificar el conocimiento que se va gestionar, el lugar en el que se almacena y lugar en que se requiere. Además, como generalmente la organización no sabe cómo localizar o cuál es la persona poseedora del conocimiento necesario para resolver el problema en cuestión, también se convierte en tarea por realizar [6].
Para ayudar en la gestión de ese conocimiento, los investigadores trabajan desde hace algún tiempo en la conceptualización de ontologías como modelos del dominio, que actualmente emergen como uno de los instrumentos de gestión del conocimiento más apropiados para soportar su representación, tratamiento, almacenamiento y recuperación, y que se comienza a extender a todas las fases de la Ingeniería de software. En relación con el mantenimiento, y considerando los tipos de conocimiento involucrados en las ontologías que lo apoyan, los desarrollos ontológicos se nutren de experiencias y aportes diversos, pero pocos llegan a modelar e implementar una ontología representativa de esta área.
En este artículo, un documento de revisión acerca de la temática, se analizan algunas de esas metodologías con el objetivo de servir como soporte a la toma de decisiones más adecuadas al problema de mantenimiento del software. Se parte de la definición de mantenimiento del software y del concepto de ontología, luego se describen y analizan algunas ontologías propuestas alrededor del mantenimiento del software, y posteriormente se describe una metodología para estructurar ontologías.
2. MANTENIMIENTO DEL SOFTWARE

El mantenimiento de software se define como “cualquier modificación de un producto de software, después de su entrega, para corregir errores, mejorar el rendimiento u otros atributos, o a la acción de adaptar el producto a un entorno que cambia” [7]; “los cambios en la gestión de productos de software para mantenerlos actualizados y en pleno funcionamiento” [8].


En el último decenio las técnicas de desarrollo de software avanzaron notoriamente y se propusieron y probaron nuevos procesos, nuevos lenguajes y nuevas herramientas; por el contrario, el mantenimiento de software al parecer se quedó a la zaga. Este tema, de mucha pertinencia e importancia en la Ingeniería de Software, recibe relativamente poca atención en la literatura técnica [9]. Sistematizar el mantenimiento es difícil, fundamentalmente porque es una actividad reactiva y por tanto muy caótica para desarrollar.
Mientras que los proyectos de desarrollo de software pueden durar unos meses o años, la fase de mantenimiento por lo general dura muchos años. La realización de estimaciones de recursos es un elemento clave de la planificación de mantenimiento, y estos recursos se deben incluir en el presupuesto de planificación de proyectos. La planificación de mantenimiento de software debe comenzar con la decisión de desarrollar un nuevo sistema, y debe considerar los objetivos de calidad que IEEE recomienda [10]. Esta fase del ciclo de vida del software es el resultado de la necesidad de adaptar los sistemas a un entorno siempre cambiante en el que, en la mayoría de los casos, no se pueden evitar los retrasos.
Las organizaciones deben mantenerse al ritmo de estos cambios, lo que a menudo significa que deben modificar el software sobre el que apoyan sus actividades. Una solución factible para romper este círculo vicioso, es el desarrollo de sistemas de gestión de conocimiento para el mantenimiento del software y evitar una práctica común a la mayoría de las organizaciones: intentar volver a documentar sus sistemas de software; esa es una operación costosa, en la que se alejan del beneficio de los programas instalados para centrarse en la documentación.
3. LAS ONTOLOGÍAS

Recientemente, el término “ontología” en el ámbito de las TIC suscita gran interés, especialmente luego que el World Wide Web Consortium -W3C- la considerara como la tecnología llamada a facilitar la infraestructura de conocimiento a la naciente Web Semántica o Web 3.0 [11], [12].


Para ser una tecnología, cuyo objetivo es clarificar, explicitar y consensuar el conocimiento relacionado con un dominio determinado, es paradójico que no alcance un consenso que ofrezca claridad acerca de lo que es o debería ser [13]. Lacy [14] manifiesta que el término ontología se sobrecarga, en tanto que su significado se refiere a diferentes cosas según quién lo defina. Axiomas más tradicionales permiten establecer una diferencia con el concepto filosófico, al determinar que “Ontología”, con mayúscula, es un campo que en filosofía estudia la naturaleza y organización de la realidad o la existencia, en relación directa con la epistemología; mientras que una de las definiciones más citada en el ámbito de la ingeniería del conocimiento la define como “una especificación explícita de una conceptualización” [15]. “Una ontología es la descripción conceptual y terminológica de un conocimiento compartido acerca de un dominio específico. Dejando de lado la formalización e interoperabilidad de aplicaciones, esto no es más que la principal competencia del término: hacer mejoras en la comunicación utilizando un mismo sistema en lo terminológico y conceptual” [16]. De estas concepciones es importante tener en cuenta que, contrario a la filosófica, la ontología debe considerarse no como una entidad natural que se descubre, sino como un recurso artificial que se crea con un objetivo determinado y para una aplicación concreta [17]. Aceptar esto es aceptar que la aplicación determina, en muchos casos, la categorización que se hace.
Las taxonomías se diseñan desde un punto de vista: el criterio explícito de una jerarquía resultante que se manifiesta en el resto de relaciones, las cuales definen y dotan de expresividad al conjunto. Debido a esto, diseñar una ontología implica hacer elecciones y seleccionar criterios; y ya que su objetivo es servir como referencia a personas, aplicaciones y organizaciones, esas elecciones y categorizaciones se deben consensuar y reconocer [18]. En el caso de los proyectos de mantenimiento de software es muy útil tener ontologías definidas acerca de la temática de gestión de los mismos, ya que se resuelven estos equívocos y evita las discusiones originadas en la comprensión del concepto mismo de “petición de mantenimiento” [19].
3.1 Ontologías y mantenimiento del software

Es importante que antes de estructurar un sistema de gestión del conocimiento para el mantenimiento del software, se piense en modelar, estructurar y generalizar la información que se genera y consulta en dicho proceso. Para lograr eficientemente esta actividad se utilizan las ontologías con las que, según Gruber [20], se hace la especificación explícita de una conceptualización. La tecnología de las ontologías se puede utilizar para que el conocimiento de la organización pueda compartirse, y para promover la característica de interoperabilidad entre sistemas [12].


Debido a que es una rama del conocimiento en permanente construcción y desarrollo, diferentes autores plantean sus ontologías en relación con el mantenimiento del software. A continuación se describen algunos de los trabajos más representativos.
3.1.1 La ontología informal para el mantenimiento del software [21]

Describe los aspectos más importantes que se deben tener en cuenta para realizar estudios empíricos del mantenimiento del software; aunque la propuesta tiene como objetivo particular identificar los factores de dominio que influyen en los resultados de estos estudios, propone otros que influyen en la fase esta y que sirven como para modelar una ontología de mantenimiento. La propuesta está estructurada en cuatro sub-ontologías: 1) De productos, en la que se definen los productos software que se van a mantener, así como su estructura interna, composición y versiones existentes; 2) De actividades, en la que se definen las actividades y recursos, dos tipos de elementos básicos en la gestión de un proyecto de mantenimiento –tipos de actividades: abstracción de “cómo se hace el trabajo”; tipos de recursos: lo más importante es el hardware y el software, pero también tiene en cuenta otros como locales y consumibles-; 3) De procesos de la organización, en la que se define cómo llevar a cabo las actividades y cómo organizar el proceso de mantenimiento como tal; y 4) De agentes, que abarca la jerarquía de tipos de agentes existentes en la gestión de los proyectos de mantenimiento.

Aunque es una propuesta que sirve como referencia para otras ontologías, algunas de las cuales se comentan en este trabajo, no llega a ser un modelo que direccione una aplicación de ontología de mantenimiento de software, ni tiene en cuenta el concepto de gestión del conocimiento en un contexto en el que sea posible aprovecharlo eficientemente por parte de los probadores.
3.1.2 El enfoque orientado al concepto [22]

Esta ontología parte de la definición abstracta de Gruber [20], en la que una ontología es una especificación explícita de una conceptualización, y refuerza la tesis de que representa un cierto punto de vista sobre una solicitud de dominio, en el que hay que definir los conceptos que viven en él de modo explícito y sin ambigüedades. Esta ontología complementa la definición de Gruber al tener en cuenta el papel que los conceptos de la especificación explícita desempeñan. Una ontología debe ser una obra de referencia, por lo que debe existir el cumplimiento de un estricto compromiso ontológico para que los usuarios puedan acceder a los significados de los conceptos.


El objetivo de la propuesta es considerar un enfoque ligero en el que es deseable, pero no necesario, alcanzar una serie de conceptos que se puedan usar como estándar para una comunidad más grande, y no la de crear ontologías formales y rigurosas para aplicar sobre dominios sometidos a consideración. Este objetivo se refuerza al definir que una de las principales actividades en el desarrollo de software es obtener conocimiento y entendimiento acerca del dominio de la aplicación.
Aunque esta propuesta apoya dicha actividad con una amplia gama de herramientas y técnicas, no tiene en cuenta el hecho de que mucho conocimiento continúa implícito en los objetos resultantes: los vínculos entre los diferentes objetos, el conocimiento que se pierde como resultado de las mejoras iterativas o el conocimiento que las partes implicadas consideran de sentido común. Además, al considerar ontologías que busquen facilitar los procesos del mantenimiento del software, es necesario intentar un acercamiento conceptual unificado para compilar una técnica común, lo que incrementa las posibilidades para nombrar y clasificar cada concepto. Es necesario trabajar en dos frentes: 1) en la posibilidad de especificar cuáles temas pueden ser similares al incluir la definición de relaciones entre temas de conocimiento, y 2) en la posibilidad de agrupar temas en varias categorías.
3.1.3 La ontología basada en el conocimiento [23]

El principio en el que se basa esta propuesta es que el desarrollo y el mantenimiento de software deben ser tareas de conocimiento intensivo, en las que se necesita conocer el dominio de la aplicación del software, el problema que soluciona el sistema, los requisitos del problema, la arquitectura del sistema, la forma como encajan las diferentes partes entre sí y cómo el sistema interactúa con el medio ambiente. Casi siempre este conocimiento no se documenta y reside en la memoria de los ingenieros de software, por lo que es inestable: una organización puede pagar varias veces a los profesionales para redescubrir el conocimiento previamente adquirido y posteriormente perdido.


Esta propuesta se estructura en cinco aspectos: toma los cuatro de Kitchenham [21] y le agrega un quinto aspecto, no considerado en la ontología informal: el conocimiento relacionado con el dominio de aplicación, en el que estructura una ontología orientada a determinar el conocimiento que necesitan los encargados de realizar mantenimiento del software.
Buena parte de la actividad y aplicación de esta ontología se desarrolla en posteriores trabajos de los mismos autores [24], [25], en los que refrendan el concepto de desarrollo y mantenimiento de software como la comprensión de las necesidades de los usuarios y su mundo -dominio de aplicación, reglas de negocio-, y un proceso en el que se convierte el código del funcionamiento en la aplicación de una serie de decisiones de diseño. Todo esto -dominio de aplicación, normas, decisiones de diseño-, representa el conocimiento que se incrusta en la aplicación resultante, muy a menudo de forma no registrada.
No es claro en esta propuesta cómo definir un mapa de conocimiento alrededor del mantenimiento del software, ya que el tiempo que requiere la captura y el análisis de la información se convierte en factor crítico que no se especifica claramente en ella. Por eso es que muchas empresas optan por acercarse a las fábricas de software para realizar este proceso, costos que muchas organizaciones no pueden cubrir o no tienen presupuestado en sus proyectos.
3.1.4 MANTIS: entorno para el mantenimiento integral del software [26]

Es un grupo de ontologías orientadas al uso descrito en la propuesta de Gruninger y Lee [27], aunque sólo se orienta a dos de los tres usos que éstos proponen: la comunicación -entre los integrantes de los grupos de mantenimiento y entre personas y sistemas-, y la reutilización y organización de conocimiento. La inferencia computacional, el tercer uso propuesto en aquella, no se incluye en la actual MANTIS, se propone como una de las líneas de trabajo futuras. Al mantener limitados los usos de las ontologías a los ya descritos, no es necesario que se formalicen completamente; en su lugar, la representación de la información se logra mediante los modelos y metamodelos.


La propuesta presentada en esta tesis no implica sólo aspectos de gestión, ya que también aboga por integrar, desde una perspectiva más amplia de proceso de negocio, la dimensión de gestión con la dimensión de ingeniería de software. Para ello se define un “entorno extendido para la gestión de proyectos de mantenimiento de software”, que integra y amplía dos conceptos básicos: metodología y entorno de ingeniería de software; define un marco de trabajo conceptual, considerado imprescindible para que las colecciones de herramientas metodológicas y técnicas formen un sistema de información automatizado integrado, y útil para la gestión de proyectos de mantenimiento. Este marco de trabajo da el soporte conceptual a todas las herramientas metodológicas y técnicas que describe y, por tanto, desempeña un papel central para cualquier propuesta en el tema.
MANTIS propone un entorno extendido que engloba tres tipos de herramientas: conceptuales, metodológicas y técnicas. Sus principales características son: integración por medio de herramientas, orientación a procesos, especialización en mantenimiento, escalabilidad y adaptabilidad. El componente ontológico de esta propuesta es uno de los más completos de los referenciados en esta investigación, ya que tiene en cuenta la fase de mantenimiento de software como un componente integral del proceso de la ingeniería de software y, porque mediante el uso de modelos y metamodelos, se acerca a conceptos como el orientado por objetos y la tendencia a los aspectos.
3.1.5 La ontología basada en la reutilización de la información [28]

Esta ontología parte de la premisa de que es conveniente, para toda organización, que la información y el conocimiento se procesen y almacenen de forma tal que se puedan reutilizar y, que para el mantenimiento, es importante realizar una buena gestión de los mismos, ya que proceden de distintas fuentes y etapas del ciclo de vida. Describe la manera de definir los conceptos involucrados en el mantenimiento del software y cómo representarlos en una ontología, potencializando el reuso de la información mediante el uso de técnicas de razonamiento basado en casos, de tal forma que los encargados del mantenimiento aprovechen las experiencias y lecciones aprendidas por otros.


Tiene su origen en la ontología de Kitchenham y su grupo [21], al identificar los factores que influyen en el mantenimiento, pero además, indica un conjunto de aspectos dinámicos del dominio descritos en términos de estados, eventos y procesos; es decir, esta ontología se extiende mediante la especificación de aspectos estáticos y dinámicos desglosados en tres ontologías y cuatro sub-ontologías. Su objetivo es definir una ontología con un nivel de abstracción más complejo y, aunque siempre se enfoca en la gestión de proyectos de mantenimiento de software con un punto de vista de procesos del negocio, pierde de vista el concepto dinámico del producto de la ingeniería de software: el sistema. No tiene en cuenta que los sistemas no son estáticos, que evolucionan de la misma forma que los hacen los procesos del negocio, lo que debilita el concepto al momento de realizar el mantenimiento como una actividad inmersa en alguno de esos procesos.
Aunque la idea general es que se puedan utilizar los conocimientos alcanzados en proyectos anteriores como ayuda para realizar los futuros, no se encuentra una clara y exhaustiva definición de cómo hacer que la reutilización del conocimiento sea útil en la realización del mantenimiento del software. Es un área cuyos aportes están cortos y se hace necesario comenzar trabajos de soporte que, a corto plazo, permitan la reutilización del conocimiento.
3.1.6 La ontología de conceptos de ingeniería de software [29]

Representa la idea de crear una ontología para separar los conocimientos de ingeniería de software del dominio, de los conocimientos sobre las operaciones, componentes de software y sistema de metadatos. Además, permite hacer supuestos explícitos sobre el dominio, con lo que es posible hallar lagunas en el conocimiento acerca de la forma como se estructuran algunos lenguajes de programación orientados por objetos [30].


Esta ontología describe la relación entre los componentes de un software orientado por objetos -programas que contienen los paquetes de clases, las clases abstractas y las interfaces con sus métodos-, y las pruebas de software, las métricas, los requisitos y sus relaciones, definidos como los distintos componentes de software. Las métricas y las pruebas se asocian con un componente de software y tienen momentos en que se calcula su valor varias veces. Los requisitos se asocian con múltiples componentes y pueden codificarse con una o más clases orientadas por objetos; un método se puede designar como el punto de entrada para la exigencia, y un punto de acceso proporciona una idea por dónde empezar a rastrear la aplicación en el código fuente.
El momento clave para utilizar esta ontología es al hacer la captura de información de los cambios, ya que se realiza mediante un objeto de propiedad que se puede utilizar en cualquier componente de software, en pruebas, métricas o requisitos, y denota cuándo se modificó por última vez. Además, el documento describe la aplicación del componente, que se refiere a los requisitos, para explicar las decisiones generales del diseño. Es de esperar que este tipo de ontologías, con la codificación de características comunes del dominio de la ingeniería de software, tenga un alto componente de reutilización.
3.1.7 La ontología basada en el conocimiento del sistema [31]

Se basa en la ontología orientada a la gestión de proyectos de mantenimiento de software [19], en la que se busca representar los aspectos estáticos y dinámicos del proceso de mantenimiento desde el punto de vista de los procesos de negocio. En esta propuesta se establece una relación entre la ontología y el conjunto de mejores prácticas contenidas en la integración de modelos de capacidad y madurez de CMMI, según la cual, especificar la transferencia de conocimientos, mediante las buenas prácticas que describen los modelos de madurez, es difícil; esto lo ratifica al explicar el proceso mediante el cual se forma a un asesor como nuevo integrante en un proceso para mejorar una actividad. Asimismo, es difícil referirse a la rapidez o al acceso a una práctica o subconjunto de prácticas, cuando se intenta responder a preguntas durante o después de una evaluación de la madurez.


Aunque esta propuesta describe el proyecto de modelado de un software de mantenimiento con base en la metodología de van Heijst [32], en la que se representa el conocimiento de sentido común como reutilizable a través de dominios, su ontología resultante la conforman: el modelo de tareas sobre el concepto de un formalismo de la ontología de dominio, la cartografía de la ontología en el papel del conocimiento de la tarea, y un modelo resultante al instanciar la aplicación del dominio específico del conocimiento.
Identificar las mejores prácticas en un modelo de madurez es una tarea difícil, debido al elevado número de conceptos y las múltiples respuestas adecuadas relacionadas con cada uno de ellos, por lo que es necesario pensar en una ontología que ayude a encontrar esas mejores prácticas para la fase de mantenimiento.
Esta ontología no tiene en cuenta muchos conceptos que participan en la solución, ya que comienza con un número limitado debido a que su propósito es mostrar la utilidad de una ontología en el mantenimiento del software de dominio. Los modelos de madurez suelen incluir detalles de las mejores prácticas que podrían ayudar en la solución de este tipo de problemas, pero la cuestión es que las mejores prácticas y sus interrelaciones permanecen ocultas en la arquitectura del modelo de madurez, especialmente en el proceso de dominio y planes de trabajo. Debido a esto es necesario encontrar una forma de vincular esta arquitectura con una ontología de los conceptos de mantenimiento, además de analizar las tareas necesarias para construir un sistema de gestión de conocimiento que, quienes realizan la actividad, puedan utilizar de apoyo en su búsqueda de soluciones [33].
4. PROPUESTA METODOLÓGICA PARA EL DISEÑO DE UNA ONTOLOGÍA

Una taxonomía se debe pensar como un criterio que determina una jerarquía resultante, que se refleja en el resto de relaciones que define y dota de expresividad al conjunto; por lo que crear una ontología implica realizar elecciones, seleccionar criterios, y dado que su objetivo es servir de referencia a personas y aplicaciones, se requiere que esas elecciones y categorizaciones estén consensuadas y reconocidas por éstas. Una ontología es la descripción conceptual y terminológica de un conocimiento compartido acerca de un dominio específico y, aparte de la formalización e interoperabilidad de aplicaciones, no es más que la principal competencia del término: hacer mejoras en la comunicación utilizando un mismo sistema en lo terminológico y conceptual [34].


La metodología que se propone en este documento se basa en la propuesta de Noy y McGuinness [30], quienes definen todos los conceptos relevantes acerca de por qué desarrollar una ontología, y presentan una metodología para su diseño basada en los sistemas de representación del conocimiento declarativo. La experiencia de los autores en la construcción y mantenimiento de ontologías en un variado número de ambientes, incluyendo Protege-2000, Ontolingua y Chimaera, se refleja en el contenido del texto. Y, aunque no existe una única forma ni metodología “correcta” para estructurar y desarrollar ontologías, a continuación se describen los puntos más generales que se deben considerar, además de los procedimientos posibles para diseñarlas. Es una forma iterativa de desarrollo que comienza por abordar el objetivo de forma frontal, para luego afinarlo y complementarlo con detalles y metas alcanzadas.
Este proceso metodológico se enmarca en algunas reglas que, aunque dogmáticas, son de gran ayuda para la toma de decisiones en el diseño ontológico:

  1. El proceso de modelar un dominio no tiene una única forma correcta de hacerlo, siempre existen otras alternativas; la selección siempre depende de la idea que se tiene para aplicarla y de las futuras extensiones que se visualicen.

  2. El proceso de diseñar y desarrollar una ontología es necesariamente iterativo.

  3. Cada concepto a incluir en la ontología debe considerarse desde la descripción de los objetos físicos o lógicos involucrados en ella, y desde las relaciones que tenga el domino seleccionado, es decir los sustantivos –objetos- o verbos –relaciones-, en las oraciones que lo describen.

  4. También se debe tener en cuenta que la ontología modela la realidad del mundo, por lo que los conceptos en ella deben reflejarla.

  5. Luego de tener los primeros acercamientos al diseño de la ontología, es necesario revaluarlo y discutirlo con especialista en el área; este proceso iterativo es necesario durante el transcurso del ciclo de vida de la ontología en construcción.

A continuación se detallan los pasos de la metodología propuesta.



4.1 Determinar el dominio y el alcance

El primer paso metodológico en esta propuesta es determinar el dominio, que se puede lograr al realizar preguntas como: ¿Qué dominio cubrirá la ontología? ¿Qué uso se le dará? La información en ella, ¿a qué tipo de preguntas deberá responder? ¿Quién se encargará de usarla y de mantenerla? Las respuestas a estas preguntas normalmente cambian en el proceso de estructuración de la ontología, pero la información que se recolecta cada vez sirve de ayuda para no exceder los límites y alcances del diseño.


Para determinar el alcance se utilizan preguntas de competencia que, como bosquejo, no requieren ser exhaustivas, además, la base de conocimientos de la ontología debería responderlas [35], y posteriormente se podrán utilizar para realizar las pruebas de control de calidad: ¿Contiene la ontología información suficiente para responder ese tipo de preguntas? ¿Qué nivel requieren las respuestas, detallado o representativo de un área en particular?
4.2 Considerar la reutilización de otras ontologías

Muchas veces vale la pena considerar otros trabajados acerca de la temática, para verificar si es posible utilizarlos para refinar y extender la ontología que se diseña [36]. El reuso de ontologías puede hacerse: cuando la que se estructura requiere interactuar con otras aplicaciones, ya que puede contar con dominios claros y específicos; cuando el nivel de formalismo en el que otras ontologías se expresan pasa a segundo plano, ya que la mayoría de sistemas de representación de conocimiento tiene la posibilidad de importarlas y exportarlas; además, la labor de “traducir” una ontología desde un formalismo particular a otro, no es una tarea complicada [37], [38].


En la Internet existen bibliotecas de ontologías que se pueden reutilizar, lo mismo que en la literatura:

  • Biblioteca de Ontolingua [39]

  • Guía de recursos sobre ontologías [40]

  • La biblioteca de ontologías DAML [41]

  • Biblioteca semántica WebQuest [42]

Igualmente, es posible adquirir un buen número de ontologías comerciales:



  • UNSPSC [43]

  • RosettaNet [44]

  • DMOZ [45]

En cualquier caso, sea porque se estructura desde cero o porque se reutiliza otra, la conceptualización y elaboración de una ontología se debe realizar para cada una de las ontologías parciales definidas en el alcance teniendo en cuenta [46]:



  1. Definir el glosario de conceptos a partir de las fuentes de conocimiento citadas.

  2. Definir las interrelaciones semánticas entre dichos conceptos representándolas mediante un diagrama de clases UML, y elaborar una tabla de clases de interrelaciones con las diversas clases identificadas.

  3. Analizar los conceptos relacionados para identificar las partes comunes a dos o más conceptos, y decidir si estas partes son a su vez conceptos y, en su caso, incluirlos en el glosario de conceptos.

  4. Identificar los atributos terminales -atributos normales- de todos los conceptos e incorporarlos a las tablas de atributos y al diagrama de clases UML.

  5. Completar las tablas de atributos de conceptos e incluir los atributos no terminales.

  6. Comprobar la completitud de todas las tablas de atributos e indicar si pertenece a la capa de descripción del artefacto, de su interfaz o contexto.


4.3 Enumerar términos importantes para la ontología

Para cualquier forma de trabajo ontológico es muy útil realizar una lista que contenga todos los términos con los que se van a hacer enunciados o para explicar al usuario, por lo que es necesario, como método inicial de trabajo, conocer cuáles con los términos que se tratarán en la ontología y qué propiedades tienen. Se debe estructurar una lista que integre estos términos, pero sin tener en cuenta los conceptos que representan, las relaciones entre ellos, las propiedades que puedan tener o si los conceptos son clases o slots, ya que, en esta metodología, se tienen en cuenta en las siguientes fases [47]. De lo que se trata es de crear las definiciones de los conceptos en la jerarquía para luego describir sus propiedades de forma sucesiva.


4.4 Definir las clases y la jerarquía de clases

Existen varios enfoques para desarrollar jerarquías de clases [48]:



  • El enfoque top-down, en el que primero se definen los conceptos más generales en el dominio y su respectiva especialización.

  • El enfoque bottom-up, que comienza con la definición de clases específicas, para luego generar las hojas de la jerarquía con su respectivo agrupamiento de clases en conceptos más generales.

  • El enfoque de desarrollo combinado, que resulta de combinar los enfoques anteriores, y que comienza por definir los conceptos más importantes para luego generalizarlos y especializarlos apropiadamente.

Ninguno de los tres enfoques puede considerarse mejor a los otros, por cuál de ellos decidirse depende en gran medida de la visión que se tiene del dominio: si se tiene una visión sistemática top-down del dominio, lo lógico es utilizar el enfoque top-down; pero el enfoque combinado es en muchas ocasiones el más fácil de aplicar, ya que los “conceptos del medio” generalmente son los conceptos más descriptivos en el dominio [49]; si la tendencia de la estructura es pensar primero en una clasificación más general, entonces podría funcionar mejor el enfoque top-down; si se prefiere comenzar con un listado de ejemplos específicos, el enfoque bottom-up podría ser el más apropiado.

Sea cual sea el enfoque que se elija, la primera tarea es definir las clases: de la lista de términos generada al Determinar el dominio y el alcance, se seleccionan los que describen objetos con existencia independiente, es decir sustantivos que no son sinónimos ni definen características de otros; estos términos se convierten en las clases de la ontología y son la base de la jerarquía de clases. También es posible ver las clases como preguntas que tienen un argumento -predicados unarios. Luego se organizan las clases en una taxonomía jerárquica, teniendo en cuenta que una instancia de una clase puede ser instancia de otra clase: si una clase X es una superclase de la clase Y, entonces cada instancia de Y lo es también de X. Es decir, que la clase B representa un concepto que es un “tipo de A [50].
4.5 Definir las propiedades de las clases

Para responder a las preguntas de competencia halladas al Determinar el dominio y el alcance, las clases aisladas no ofrecen la suficiente información, por lo que, luego de definir las clases, es necesario describir la estructura interna de conceptos: se seleccionan clases de la lista de términos estructurada al Enumerar los términos importantes para la ontología y, muy probablemente, los términos restantes son las propiedades de ellas, es decir que la describen; para cada propiedad en la lista se determina a qué clase describe, con lo que se convierten en los slots de la clase [20].


Existen varios tipos de propiedades que se pueden convertir en slots en una ontología:

  • Las intrínsecas: sabor, color, tamaño.

  • Las extrínsecas: nombre, área origen.

  • Partes: si el objeto es estructurado pueden ser partes físicas o abstractas: platos de una comida, vino que acompaña.

  • Relaciones con otros individuos: relaciones entre los miembros individuales de una clase y otros ítems: casa productora, que relaciona un producto con un fabricante y con la materia prima con la que se fabrica.

Además de las propiedades identificadas previamente, es necesario añadir los slots a la clase. Debe tener en cuenta que todas las subclases de una clase heredan los slots de la misma, y que un slot debe estar yuxtapuesto a la clase más general que puede tener esa propiedad [49].


4.6 Definir las facetas de los slots

Los slots tienen diferentes facetas para describir el tipo de valor [49]:



  • Cardinalidad. Define cuántos valores puede tener un slot. Existen sistemas que sólo aceptan cardinalidad simple –sólo un valor- o cardinalidad múltiple -cualquier cantidad de valores; otros admiten la especificación de cardinalidades mínimas y máximas para describir con mayor precisión la cantidad de valores del slot.

  • Tipo de valor. Describe qué tipos de valores puede contener el slot: String, el valor es una cadena de caracteres; Number, describe slots con valores numéricos; Boolean, son valores de banderas si/no, verdadero/falso; Enumerated, denotan una lista específica de valores admitidos para el slot, los define el desarrollador; Instance, admiten la definición de relaciones entre individuos; algunos sistemas especifican sólo el tipo de valor con la clase en lugar de un enunciado especial de slots de tipo instance.

  • Dominio y rango. Comúnmente las clases admitidas para los slots tipo Instance se nombran como rango de éste; las clases a las cuales un slot está yuxtapuesto o las clases de las que un slot describe sus propiedades, se nombran como dominio. Las reglas para determinar dominio y rango de un slot son: al definir un dominio o rango de un slot, se debe encontrar la o las clases más generales, que puedan ser el dominio o rango de los slots; no se debe definir un dominio o rango que sea muy general: todas las clases en el dominio deben ser descritas por el slot, y las instancias de las clases en el rango de un slot deben ser rellenos potenciales del slot [48].

4.7 Crear instancias y cardinalidades

El último paso de esta metodología es crear las instancias individuales de clases en la jerarquía, el proceso es el siguiente: 1) elegir la clase, 2) crear la instancia individual de la clase y 3) llenar los valores del slot [51], [52]. Debe tenerse en cuenta: 1) decidir si un concepto particular será una clase o una instancia individual en la ontología, depende de las aplicaciones que ésta tendrá [52], [54]; 2) para decidir dónde terminan las clases y comienzan las instancias, es necesario hallar primero el nivel más bajo de granularidad en la representación, y que también lo determina la aplicación potencial de la ontología [55]; 3) sólo las clases se pueden representar en una jerarquía, ya que los sistemas de representación de conocimiento no tienen la noción de sub-instancias, por lo que, si los términos tienen una jerarquía natural, se deben definir como clases aunque no tengan ninguna instancia propia [56], [57].


5. CONCLUSIONES

  • Debido a que la gestión del conocimiento es una técnica muy importante para facilitar el trabajo de los encargados del mantenimiento del software, es necesario contar con un método para detectar las fuentes existentes y su ubicación en la organización; una manera de hacerlo, rápida y eficientemente, es utilizar agentes inteligentes mediante ontologías para detectar la información que sea útil y acorde con las necesidades de la tarea de mantenimiento.

  • En este documento se presentó el análisis de la conceptualización alrededor de la gestión del conocimiento mediante ontologías para el mantenimiento del software, además, se describió una metodología para desarrollarla; sin embargo, luego de seguir y aplicar los pasos, reglas y recomendaciones, es muy importante recordar que no existe una sola ontología que se pueda considerar correcta para un dominio dado.

  • El diseño ontológico es un proceso que exige creatividad, por lo que las ontologías nunca serán iguales aunque se estructuren sobre el mismo dominio. La potencial aplicación de la ontología, así como la comprensión y aspecto del dominio por parte del diseñador, afectan las opciones del diseño mismo de la ontología.

  • No se sabe si algo es bueno hasta que se lo pone a prueba, se puede evaluar la calidad de la ontología solamente utilizándola en las aplicaciones para las cuales se diseñó.


6. REFERENCIAS

  1. I. Lindvallv. “Knowledge management in software engineering”. IEEE Software. Vol. 19. 2002. pp. 26-38.

  2. T. M. Pigoski. “Practical software maintenance: best practices for managing your software investment”. Ed. John Wiley & Sons. New York. 1996. pp. 400.

  3. D. B. Walz, J. J. Elam, B. Curtis. “Inside a software design team: knowledge acquisition, sharing, and integration”. Communications of the ACM. Vol. 36. 1993. pp. 63-77.

  4. O. M. Rodríguez, A. I. Martínez, J. Favela, A. Vizcaíno, M. Piattini. “Understanding and supporting knowledge flows in a community of software developers”. Lecture Notes in Computer Science. Vol. 3198. 2004. pp. 52-66.

  5. T. Dingsøyr, R. Conradi. “A survey of case studies of the use of knowledge management in software engineering”. International Journal of Software Engineering and Knowledge Engineering. Vol. 12. 2002. pp. 391-414.

  6. J. Nebus. “Framing the knowledge search problem: whom do we contact, and why do we contact them?” Academy of Management Best Papers Proceedings. 2001. pp. h1-h7.

  7. S. Mamone. “The IEEE standard for software maintenance”. ACM SIGSOFT Software Engineering Notes. Vol. 19. 1994. pp. 75-76.

  8. R. Singh. “ISO/IEC draft international standard 12207, software life-cycle processes”. IFIP Transactions. Vol. A-55. 1994. pp. 111-119.

  9. R. S. Pressmann. “Software engineering: a practitioner's approach”. Ed. McGraw-Hill. México. 2005. 912 p.

  10. Software Engineering Standards Committee of IEEE Computer Society. “IEEE Std. 1061-1998. IEEE Standard for a software quality metrics methodology”. Technical Report. 1998. pp 26.

  11. L. Lefort, K. Taylor, D. Ratcliffe. “Towards scalable ontology engineering patterns: lessons learned from an experiment based on W3C's part-whole guidelines”. Proceedings of the second Australasian workshop on Advances in ontologies. Vol. 72. 2006. pp. 31-40.

  12. I. Horrocks. “Ontologies and the semantic web”. Communications of the ACM. Vol. 51. 2008. pp. 58-67.

  13. J. A. Evans. “Electronic Publication and the narrowing of science and scholarship”. Science. Vol. 321. 2008. pp. 395-399.

  14. L. W. Lacy. “OWL: Representing information using the Web ontology language”. Ed. Trafford Publishing. USA. 2005.

  15. T. R. Gruber. “Towards principles for the design of ontologies used for knowledge sharing”. International Journal of Human-Computer Studies. Vol. 43. 1995. pp 907-928.

  16. M. Reuver and T. Haaker. “Designing viable business models for context-aware mobile services”. Telematics and Informatics. Vol. 26. 2009. pp. 240-248.

  17. K. Mahesh. “Ontology development for machine translation: ideology and methodology”. Computing Research Laboratory. Technical Report MCCS-96-292. New México State University. 1996.

  18. K. M. Oliveira, N. Anquetil, K. de Sousa, M. G. Batista. “Knowledge for software maintenance”. Fifteenth International Conference on Software Engineering and Knowledge Engineering. San Francisco. 2003. pp. 61-68.

  19. F. G. Ruiz, A. Vizcaíno, M. Piattini, F. García. “An Ontology for the management of software maintenance projects”. International Journal of Software Engineering and Knowledge Engineering. Vol. 14. 2004. pp. 323-349.

  20. T. R. Gruber. “A translation approach to portable ontology specifications”. Knowledge Acquisition. Vol. 5. 1993. pp. 192-220.

  21. B. A. Kitchenham, G. H. Travassos, A. von Mayrhauser, F. Niessink, N. F. Schneidewind, J. Singer, S. Takada, R. Vehvilainen, H. Yang. “Towards an Ontology of software maintenance”. Journal of Software Maintenance: Research and Practice. Vol. 11. 1999. pp. 365-389.

  22. D. Deridder. “Facilitating software maintenance and reuse activities with a concept-oriented approach”. Technical report. Programming Technology Lab. Vrije Universiteit Brussel. Belgium 2002.

  23. K. M. Oliveira, N. Anquetil, K. de Sousa, M. G. Batista. “Organizing the knowledge used in software maintenance”. Journal of Universal Computer Science. Vol. 9. 2003. pp. 641-658.

  24. K. M. Oliveira, N. Anquetil, K. de Sousa, M. G. Batista. “Legacy software evaluation model for outsourced maintainer”. Software Maintenance and Reengineering. Eighth European Conference on CSMR’04. 2004. pp. 65-72.

  25. K. M. Oliveira, N. Anquetil, K. de Sousa, M. G. Batista. “Software maintenance seen as a knowledge management issue”. Information and Software Technology. Vol. 49. 2007. pp. 515-529.

  26. F. G. Ruiz. “MANTIS: Entorno para el Mantenimiento Integral del Software”. Tesis doctoral. Director: Mario G. Piattini Velthuis. Universidad de Castilla-La Mancha. 2003.

  27. M. Gruninger, J. Lee. “Ontology applications and design”. Communications of the ACM. Vol. 45. 2002. pp. 39-41.

  28. A. Vizcaíno, J. P. Soto, F. García, F. Ruiz, M. Piattini. “Aplicando gestión del conocimiento en el proceso de mantenimiento del software”. Revista Iberoamericana de Inteligencia Artificial. Vol. 10. 2006. pp. 91-98.

  29. D. Hyland-Wood, D. Carrington, S. Kaplan. “Enhancing software maintenance by using semantic web techniques”. 5th International Semantic Web Conference. Athens, GA, USA. 2006.

  30. N. Noy, D. Mcguinness. “Ontology development 101: a guide to creating your first ontology”. Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880. Stanford Knowledge Systems Laboratory, Stanford University. 2001.

  31. A. April, J-M Desharnais, R. A. Dumke. “A formalism of ontology to support a software maintenance knowledge-based system”. Proceedings of the Eighteenth International Conference on Software Engineering & Knowledge Engineering Conference. San Francisco. 2006. pp. 331-336.

  32. G. van Heijst, A. Schreiber, B. Wielinga. “Using explicit ontologies in KBS development”. International Journal of Human-Computer Studies. Vol. 46. 1996. pp. 2-3.

B. Sarder, S. Ferreira. “Developing systems engineering ontologies”. System of Systems Engineering, SoSE '07. IEEE International Conference. San Antonio, TX, USA. 2007. pp. 1-6.

  1. J. M. Park, J. H. Nam, Q. P. Hu, H. W. Suh. “Product ontology construction from engineering documents”. International Conference on Smart Manufacturing Application, ICSMA’08. Goyang-si, South Korea. 2008. pp. 305-310.

  2. M. Gruninger, M. S. Fox. “Methodology for the design and evaluation of ontologies”. Proceedings of the Workshop on Basic Ontological Issues in Knowledge Sharing. Montreal. 1995.

  3. A. Gómez-Pérez. “Knowledge sharing and reuse”. The Handbook of Applied Expert Systems. 10-1 to 10-36. Jay Liebowitz. Ed. CRC Press. Germany. 1998.

  4. M. A. Musen. “Dimensions of knowledge sharing and reuse”. Computers and Biomedical.. Vol. 25. 1992. pp. 435-467.

  5. T. R. Rothenfluh, J. H. Gennari, H. Eriksson, A. R. Puerta, S. W. Tu, M. A. Musen. “Reusable ontologies, knowledge-acquisition tools, and performance systems: PROT´EG´E-II solutions to Sisyphus-2”. International Journal of Human-Computer Studies. Vol. 44. 1996. pp. 303-332.

  6. http://www.ksl.stanford.edu/software/ontolingua/

  7. http://es.geocities.com/ontologias_y_tesauros/guia_de_recursos_sobre_ontologias.htm

  8. http://www.daml.org/ontologies/.

  9. http://cfievalladolid2.net/webquest/common/index.php

  10. www.unspsc.org

  11. www.rosettanet.org

  12. www.dmoz.org

  13. C. Tautz, C. G. von Wangenheim. “REFSENO: A representation formalism for software engineering ontologies”. Technical Report IESE-Report No. 015.98/E. Fraunhofer Institute for Experimental Software Engineering. Germany. 1999. pp. 61-71.

  14. A. Borgida, R. J. Brachman, D. L. McGuinness, L. A. Resnick. “CLASSIC: a structural data model for objects”. Proceedings of the 1989 ACM SIGMOD International Conference on Management of Data. Portland. 1998. pp. 59-67.

  15. M. Uschold, M. Gruninger. “Ontologies: principles, methods and applications”. Knowledge Engineering Review. Vol. 11. 1996. pp. 93-155.

  16. E. Rosch. “Principles of categorization”. Concepts: core readings. pp. 189-206. Eric Margolis and Stephen Laurence. USA: MIT Press. 1999. 652 p.

  17. H. Ning, D. Shihan. “Structure-based ontology evaluation”. e-Business Engineering, ICEBE'06. IEEE International Conference. Shanghai. 2006. pp. 132-137.

  18. D. L. McGuinness, J. Wright. “An industrial strength description logic-based configurator platform”. IEEE Intelligent Systems. Vol. 13. 1998. pp. 69-77.

  19. K-S Choi. “IT ontology and semantic technology”. Natural Language Processing and Knowledge Engineering, NLP-KE’07. International Conference. Beijing. 2007. pp. 14-15.

  20. M. Fernández, A. Gómez-Pérez, N. Juristo. “Methontology: from ontological art towards ontological engineering”. AAAI Spring Symposium. University of Stanford. 2007. pp. 33-40.

  21. R. F. García, M. Piattini. “Calidad en el desarrollo y mantenimiento del software”. Ed. Ra-ma. Madrid. 2003.

  22. Software Engineering Standards Committee of IEEE Computer Society. “STD 1074-1997: IEEE Standard for developing software life cycle processes”. Technical Report. 1997. pp. 96.

  23. F. G. Ruiz, C. Calero, M. Piattini. “Ontologies for software engineering and software technology”. London: Ed. Springer. 2006.

  24. L. Zhang, S. Xia, Y. Zhou, A. Xia. “User defined ontology change and its optimization”. Chinese Control and Decision Conference. Yantai, Shandong. 2008. pp. 3586-3590.






La base de datos está protegida por derechos de autor ©absta.info 2016
enviar mensaje

    Página principal