ingeniería del software en la década del 2000lbd.udc.es/repository/publications/drafts/10.pdf ·...

CYTED

Nieves R. Brisaboa (Ed.)

Ingeniería del Software en la Década del 2000

RIT

OS2

Cartagena de indias, Colombia Agosto 2003

Nieves R. Brisaboa (Eds.)

Ingeniería del Software en la Década del 2000

IX Jornadas Iberoamericanas de Informática Cartagena de Indias, Colombia 11-15 Agosto, 2003

A todas las personas que con su apoyo y esfuerzo entusiasta, contribuyen a que RITOS2 sea un lugar de encuentro y esperanza Iberoamericana..... y a Isidro Ramos por habernos inspirado

PRESENTACIÓN

Es evidente que contar con herramientas informáticas que utilicen tecnología avanzada proporciona una ventaja competitiva a cualquier organización, y especialmente a la pequeña y mediana empresa, independientemente de que su área de actividad sea la industria, el comercio, los servicios públicos o privados. En todo caso, la eficiencia de su gestión depende de lo avanzado de su tecnología informática.

Este volumen se presenta en el marco de las IX Jornadas de Informática de la

AECI en las que diferentes especialistas de la Red Iberoamericana de Tecnologías del Software para la Década del 2000 (RITOS2) han aportado sus conocimientos y experiencia, como queda reflejado a lo largo de los diferentes capítulos de este libro.

Los capítulos han sido seleccionados de modo que ofrezcan una visión global de

las diferentes tecnologías que se combinan en la actualidad para atender los requerimientos de software que en esta década del 2000 las organizaciones están demandando.

Desde nuestro punto de vista, dichas tecnologías se encuadran en 4 grandes áreas

que coinciden con las 4 áreas de trabajo de los especialistas de RITOS2:

• Ingeniería del Software: La investigación en Ingeniería del Software se caracteriza por la necesidad de proponer, experimentar y validar nuevas teorías y técnicas para el desarrollo y evolución de sistemas software. Gran parte de las aplicaciones software desarrolladas actualmente, y que se perfilan como la tendencia de la década, utilizan Internet como soporte. Esto presenta nuevos desafíos que no son adecuadamente abordados por las técnicas utilizadas en la década anterior. Temas tales como la calidad en el proceso y en el producto de software, técnicas, métodos y medios aplicados a las etapas de la construcción de software, o los nuevos enfoques para modelado y desarrollo de componentes o la orientación a aspectos, resultan de trascendental importancia en este contexto, lo que hace su estudio imprescindible para abordar con garantías de éxito el desarrollo de este tipo de aplicaciones.

• Bases de Datos: Las aplicaciones actuales y futuras trabajan sobre Internet y

utilizan nuevos modelos de bases de datos (desde BD objeto-relacionales, hasta sistemas GIS, BD documentales, multimedia, etc.) puesto que el clásico modelo relacional es insuficiente para dar satisfacción a las nuevas necesidades de la sociedad de la información. De ahí el interés de la investigación en Bases de Datos que sirvan como fuentes de datos a las aplicaciones Web. Las técnicas de Modelado y Diseño de Bases de Datos, Minería y Almacenes de Datos, Federación de Bases de Datos, BD Distribuidas, Espaciales, etc. , técnicas de Recuperación de la Información en la Web, y por supuesto tecnologías de Bibliotecas digitales o la utilización de Ontologías para guiar el acceso a Bases de Datos vía Internet, así

I

como todo lo relacionado con lenguajes de marcado (XML) o con lenguajes de lógica descriptiva para la Web Semántica ( OWL) son, en este contexto, temas cruciales.

• Sistemas Distribuidos: Internet permite acceder directamente a información

geográficamente dispersa, pero sin garantizar el manejo integral y eficiente de recursos distribuidos que trabajen cooperativamente. El desarrollo de tecnologías que proporcionen plataformas cooperativas de bajo costo en Internet, para explotar eficientemente y de forma integrada recursos dispersos, permitirá dar soporte al tipo de aplicaciones Web. Por tanto son temas de trabajo de gran interés en esta área el manejo eficiente de recursos en Internet, accesibilidad y coordinación de componentes de Sistemas Distribuidos, evaluación de rendimiento, fiabilidad y tolerancia a fallos, planificación, seguridad etc.

• Procesamiento del Lenguaje Natural: La presencia del español y portugués en

Internet (actualmente dominada por el inglés) está condicionada al desarrollo de las técnicas y herramientas de procesamiento del lenguaje natural para permitir la recuperación de textos por contenido. Además dicha tecnología es indispensable para explotar el patrimonio cultural de los países del marco CYTED (bases de documentos textuales, bibliotecas digitales y la propia Internet). Por otro lado es cada vez más prioritario el desarrollo de interfaces de usuario “amigables” para las nuevas aplicaciones y en este sentido las interfaces en Lenguaje Natural son la solución más adecuada. Estas 4 áreas son cruciales hoy en día para el desarrollo de la tecnología necesaria

para la implementación de aplicaciones útiles a las organizaciones tanto públicas como privadas, tanto se dediquen a la gestión y explotación de recursos naturales (de la minería al sector agropecuario), o a la industria (desde la textil a la turística) al comercio, o a los servicios (educación, sanidad, patrimonio cultural, etc.). En la década del 2000, de acuerdo a la prospectiva tecnológica, cualquiera de estas organizaciones demanda y seguirá demandando aplicaciones que, deberán aplicar los principios de calidad desde el punto de vista de la Ingeniería del Software, tendiendo a la optimización de los recursos. Además dichas aplicaciones serán distribuidas, se podrán ejecutar desde Internet, utilizarán grandes bases de datos y tendrán interfaces de usuario “amigables” utilizando técnicas próximas al lenguaje natural.

El contar con grupos de investigación en estas 4 áreas, permite que en el seno de

RITOS2 se promueva el intercambio de conocimientos (conceptos, métodos, técnicas y herramientas) necesarios para afrontar los grandes retos que las necesidades de la nueva economía y la cultura digital han planteado y que marcarán el desarrollo tecnológico de esta década. Por otro lado, la colaboración multidisciplinar entre grupos de diferentes áreas es crucial para pensar en soluciones software avanzadas a las cada vez mas complejas demandas de las organizaciones, así como para generar sinergias enriquecedoras e innovadoras en la forma de afrontar dichos problemas.

RITOS2 es una red de 30 grupos de investigación de 14 países financiada por el

Programa Iberoamericano Ciencia Y Tecnología para El Desarrollo (CYTED).

II

Cyted financia redes y proyectos de investigación que favorezcan el desarrollo tecnológico de Iberoamérica propiciando los contactos y el surgimiento de sinergias potenciadoras. RITOS2 nació en el año 2000 como continuación de la red RITOS, que dirigida por el Dr. Isidro Ramos, tuvo un impacto enorme en el desarrollo de la investigación en Informática en la región y en la formación de profesionales.

La vocación claramente aplicada de la investigación que realizan todos los grupos

de RITOS2 y su compromiso con la formación de investigadores y profesionales en informática, permite establecer tres Objetivos Fundamentales para RITOS2:

1. Objetivo Tecnológico: Facilitar el Desarrollo de tecnologías del Software y

potenciar su transferencia a los sectores industriales y de servicios, así como a las administraciones públicas, de modo que se doten de mejores herramientas informáticas.

2. Objetivo de Formación de Recursos Humanos: Potenciar la formación y

capacitación de investigadores y de profesionales. 3. Objetivo Estratégico: Ser foro de intercambio de experiencias y conocimientos,

así como de informaciones, bibliografía, documentación etc. Evidentemente la organización de las IX Jornadas Iberoamericanas de Informática

encaja perfectamente con estos objetivos. Los primeros capítulos ofrecen dos de las perspectivas más interesantes y actuales

en Ingeniería del Software, la Orientación a Aspectos y el Desarrollo de Software Basado en Componentes, en ambos casos se trata de estudios introductorios a dichos temas. A continuación se presentan algunos capítulos relacionados con Bases de Datos. Se comienza por el modelado conceptual presentando una propuesta enriquecedora del modelado conceptual tradicional mediante la utilización de lógica difusa. Se introducen después los Sistemas de Información Geográfica como aplicación de las Bases de Datos Espaciales y se presenta después un trabajo que implica problemas de gestión espacio-temporal para optimizar el establecimiento de rutas para vehículos.

Dentro de la tecnología de Bases de Datos, se pasa a continuación a lo que

constituye quizá el campo de mayor desarrollo en Bases de Datos, las Bases de Datos Documentales o Bibliotecas Digitales. Sobre este tema se incluyen varios trabajos que presentan diferentes aproximaciones y problemas relacionados con diferentes tópicos relevantes dentro del mismo incluyendo la problemática de la indexación, compresión de textos y minería textual en la Web. Entroncando directamente con la problemática de manejo de los textos en Bases de Datos Documentales, los siguientes dos capítulos introducen la problemática del procesamiento del Lenguaje Natural.

Por último se presenta algo que no podría faltar en una revisión de las tecnologías

actuales para el desarrollo del software, el diseño de interfaces, Así el capítulo 14 hace una revisión general de las propuestas de Modelado de Interfaces Web y el 15

III

presenta un ejemplo de utilización de Ontologías y técnicas de Lenguaje Natural para Interfaces de Usuario. Finalmente y a modo de resumen final de lo que es hoy la industria del software se presenta un modelo de procesos para dicha industria.

En resumen, este libro presenta un material actual y riguroso sobre diferentes

desarrollos tecnológicos que se están produciendo en el campo del software. Creemos que a lo largo de los diferentes capítulos, considerando especialmente aquellos en los que se introducen temas nuevos o estados del arte de ciertos tópicos, los asistentes a las IX Jornadas Iberoamericanas de Informática podrán encontrar ideas, propuestas y retos que guíen su trabajo de investigación o su desarrollo profesional en los próximos años.

Agosto 2003 Nieves R. Brisaboa

IV

ÍNDICE

Aspectual Requirements: a Model for Advanced Separation of Concerns . . . . . 1 Ana Moreira Desarrollo Basado en Componentes utilizando UML . . . . . . . . . . . . . . . . . . . 23 Raquel Anaya. Propuesta de un Modelo Conceptual Difuso . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Angélica Urrutia, José Galindo y Mario Piattini Sistemas de Información Geográfica: Revisión de su Estado Actual . . . . . . . . . 77 Nieves R. Brisaboa, José A. Cotelo Lema, Antonio Fariña, Miguel R. Luaces y José R.R.Viqueira

Comparación de un Sistema de Colonias de Hormigas y una Estrategia Evolutiva para el Problema del Ruteo de Vehículos

con Ventanas de Tiempo en un Contexto Multiobjetivo . . . . . . . . . . . . . . . . . . 95 Benjamín Barán y Augusto Hermosilla A System for the Integrated Access to Digital Libraries . . . . . . . . . . . . . . . . . . 109 Nieves R. Brisaboa, Miguel R. Penabad, Ángeles S. Places y Francisco J. Rodríguez

Búsquedas en Bases de Datos Textuales Distribuidas en una Red de Procesadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 M. Printista, V. Gil Costa y M. Marín Index structures for distributed text databases . . . . . . . . . . . . . . . . . . . . . . . . . . 131 Mauricio Marín Minería de Datos en la Web usando Computación Evolutiva . . . . . . . . . . . . . 153 José Aguilar, Junior Altamiranda Compresión de textos en Bases de Datos Digitales . . . . . . . . . . . . . . . . . . . . . . 169 Nieves R. Brisaboa, Antonio Fariña, Gonzalo Navarro, Eva L. Iglesias, José R. Paramá y María F. Esteller

Obtención automática de información sintáctica para un diccionario de patrones de manejo para el lenguaje español . . . . . . . . . . . . . . . . . . . . . . . . . . 181 Sofía N. Galicia-Haro, Alexander F. Gelbukh e Igor A. Bolshakov Procesamiento del Lenguaje Natural: presente y perspectivas futuras . . . . . . . . 191 Maximiliano Saiz Noeda

Modelando Interfaces para Aplicaciones Web . . . . . . . . . . . . . . . . . . . . . . . . . . 227 Luis A. Guerrero Las Ontologías Como un Medio de Hacer Portable una Interfaz en Lenguaje Natural a Bases de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 J. Antonio Zárate M., Rodolfo A. Pazos R. y Alexander Gelbukh MoProSoft: Modelo de Procesos para la Industria de Software . . . . . . . . . . . . . 251 Hanna Oktaba y Claudia Alquicira Esquivel

Aspectual Requirements: a Model for Advanced Separation of Concerns

Ana Moreira

Departamento de Informática, Faculdade de Ciências e Tecnologia, Universidade Nova de Lisboa, Quinta da Torre, 2829-516 Caparica, Portugal

{amm}@di.fct.unl.pt

Abstract. Separation of concerns is one of the foundational rules of software engineering. Concerns are the primary motivation for organizing and decom-posing software into manageable and comprehensible parts. Software engineer-ing development methods have been created with this principle in mind. How-ever, they do not handle well the crosscutting nature of some concerns, such as security, fault tolerance and usability. These concerns may cut across many other concerns and therefore are difficult to keep separated in different mod-ules. They are responsible for producing tangled representations that are diffi-cult to understand, maintain and evolve. An effective requirements engineering approach should reconcile the need to handle crosscutting concerns with the need to integrate existing technologies.

In this paper we propose an approach to modularise and compose such cross-cutting, aspectual requirements. The approach is based on separating the speci-fication of aspectual requirements, non-aspectual requirements and composition rules in modules representing coherent abstractions and following well-defined templates. The composition rules employ informal, and often concern-specific, actions and operators to specify how an aspectual requirement influences or constrains the behaviour of a set of non-aspectual requirements. A realisation of the proposed approach, based on viewpoints and the eXtensible Markup Lan-guage (XML), supported by a tool called ARCaDe and a case study of a toll collection system is presented.

1 Introduction

Separation of concerns is a foundational rule of software engineering that aims at identifying and modularizing those parts of software that are relevant to a particular concept, goal or purpose. This allows us to deal with different issues of a problem individually so that we concentrate on each one independently. The main advantages of applying this rule are: (i) to decrease the complexity of the software development by concentrating on different issues separately; (ii) to support division of efforts and separation of responsibilities and (iii) to improve the modularity of software systems artefacts.

Traditional approaches to software development, such as object-oriented methods, have been created with that rule in mind. However, they do not handle well the cross-cutting nature of some concerns. Examples of such concerns are the well known non-functional requirements, such as security, fault tolerance and usability. Non-

functional requirements are constraints that affect several components of a system and are usually associated with quality of service. Advanced separation of concerns has its main focus on those concerns that cut across other concerns. These crosscut-ting concerns are responsible for producing tangled representations that are invasive to implement, difficult to understand and tough to evolve.

Existing requirements engineering (RE) approaches achieve separation of concerns through the separation of functional and non-functional requirements. The NFR framework [11] handles well non-functional requirements. It does not explicitly deal with functional concerns, but establishes a link to them. Nevertheless, it ignores the crosscutting nature of those requirements. There are approaches that integrate func-tional and non-functional concerns [10, 29], but, again, the crosscutting nature of those concerns is not addressed.

An effective RE approach should reconcile the need to integrate functional and non-functional requirements with the need to modularize those that are crosscutting. Aspect-oriented software development [13] techniques aim at providing means for the systematic identification, modularisation and composition of crosscutting con-cerns throughout the software life cycle. Crosscutting concerns are encapsulated in separate modules, known as aspects, so that localisation can be promoted. A number of aspect-oriented programming approaches have been proposed. These range from language mechanisms [1] to filter-based techniques [5] through to traversal-oriented [20] and multi-dimensional approaches [23, 28].

In the last years, the Software Engineering community has been interested in propagating the aspect-oriented concepts to the early stages of the software life cycle to facilitate the modeling of aspects in the design and implementation phases by means of: (i) the determination of the mapping of crosscutting requirements on arti-facts at later development stages and (ii) the understanding about how a crosscutting concern affects others requirements.

Work has been carried out to incorporate aspects, and hence separation of crosscutting concerns, at the design level mainly through extensions to the UML meta-model e.g. [8, 9, 27]. Research on the use of aspects at the requirements engineering stage is still immature and there is no consensus about what an aspect is at this early stage of software development and how it maps to artefacts at later development stages.

The focus of this paper is on identification, modularisation and composition of re-quirements level concerns that cut across other requirements. These crosscutting concerns cannot be encapsulated by a single viewpoint [14] or use case [17], for example, and are typically spread across several of them. There is, therefore, a need to include aspects as fundamental modelling primitives at the requirements engineer-ing level. The motivations for this are two-fold: 1. Providing improved support for separation of crosscutting functional and non-

functional properties during requirements engineering hence offering a better means to identify and manage conflicts arising due to tangled representations;

2. Identifying the mapping and influence of requirements level aspects on artifacts at later development stages hence establishing critical trade-offs before the architec-ture is derived.

2 RITOS2

This paper proposes an approach aimed as a stepping-stone towards the above goals. Section 2 provides some background on existing approaches to manage cross-cutting concerns at the requirements level. Section 3 presents a general model that supports effective identification and specification of aspectual requirements and their mapping and influence on later development stages. Section 4 instantiates the general model with a concrete set of techniques, namely viewpoints and XML. Section 5 introduces some related work, and finally, section 6 concludes the paper by discuss-ing key outstanding issues and directions for future work.

2 Background

In RE, viewpoints [14], use cases [17] and goals [19] have been advocated as a means of partitioning requirements as a set of partial specifications that aid traceability and consistency management. However, ensuring the consistency of these partial specifi-cations with global requirements and constraints is largely unsupported.

An aspect-oriented requirements engineering approach targeted to component based software development has been proposed in [16]. There is a characterisation of diverse aspects of a system that each component provides to end users or other com-ponents. However, the identification of aspects for each component is not clearly defined.

The XBel framework [4] offers a logic-based approach, supported by a model checker, for merging and reasoning about multiple, inconsistent viewpoints. Although the framework can be used to support requirements negotiation, the focus is on rea-soning about the properties of the specification in the presence of inconsistent view-points and not on providing means for explicit modularisation and composition of crosscutting requirements. Nor is there any support for identifying the mapping and influence of crosscutting requirements on later development stages.

Separation of crosscutting properties has also been considered in [26] which pro-poses a viewpoint-oriented requirements engineering method called PREView. A PREView viewpoint encapsulates partial information about the system. Requirements are organised in terms of several viewpoints, and analysis is conducted against a set of concerns intended to correspond broadly to the overall system goals. Due to this broad scope concerns crosscut the requirements emerging from viewpoints. In appli-cations of the method, the concerns that are identified are typically high-level non-functional requirements.

3 A Model for Aspectual Requirements

Modern systems have to run in highly volatile environments where the business rules change rapidly. Therefore, systems must be easy to adapt and evolve. If not handled properly, crosscutting concerns inhibit adaptability. It is therefore essential to think about crosscutting concerns as early as possible. The model we envisage to deal with crosscutting concerns at the requirements level is illustrated in Figure 1. It is com-posed of five main tasks: identify and specify concerns, both functional and non-

Ingeniería del Software 3

functional; identify crosscutting concerns; compose candidate aspects; handle con-flicts between candidate aspects; specify aspect dimensions. INPUT

CATALOGUES

Revise requirements specification

2.1: Identify coarse grained relations

Task 3: Compose candidate aspects

3.1: Define composition rules

OUTCOME

Task 5: Specify aspect dimensions

1.1: Identify concerns

1.2: Specify concerns

Task 1: Identify & specify concerns

Task 2: Identify crosscutting concerns

2.1: Identify candidate aspects

3.1: Compose aspects with other concerns

Task 4: Handle conflicts

4.1: Build contribution table

4.2: Attribute weights

4.3: Resolve conflicts

XML templates

XML rules

Visual diagrams

Figure 1: A model for advanced concerns at RE

This model should be guided by an iterative and incremental process.

Task 1: Identify and specify concerns. This task is responsible for identifying con-cerns in general and for specifying them. These concerns can be functional or non-functional1.

Task 1.1: Identify concerns. We start by an exhaustive inspection of the existing documents and to query the stakeholders to understand their goals and needs towards to the future system. (Stakeholders are all the people that have a direct or indirect influence in the project. They may be users, clients, managers, developers, etc.) The identified concerns can be classified into functional and non-functional. Functional concerns represent functions or operations that the system must accomplish. They define the fundamental process or transformation that the system’s components must perform on inputs to produce outputs. Non-functional concerns are those that usually reflect abstract quality goals that the stakeholders expect from the system. Examples are software design distribution, performance and accuracy. They are very difficult to test and therefore are usually evaluated subjectively.

We may also use any of the existing techniques to help eliciting the requirements. While some techniques emphasize the main functions that the future system should implement (e.g. use cases [17]), others emphasize constraints and certain properties that affect the whole system (e.g. the NFR framework [11]). Traditional techniques

1 While functional concerns are known as “functional requirements”, non-functional concerns

are known as “non-functional requirements”, or only NFR.

4 RITOS2

concentrate on the functional behavior of a system and they are part of the common knowledge of any software engineer. However, experts in NFRs, for example, are a lot harder to find. This is also true for techniques integrating both types of concerns, such as [19]. To alleviate the onus of the identification of the broadly scoped re-quirements we propose the use of existing catalogues, such as [11].

Task 1.2: Specify concerns. This is accomplished by using any of the existing tech-niques for requirements specification. In certain cases a choice may have already been done during Task 1, especially if particular techniques have been used to help in the elicitation process. If so, we may find useful to complement our documentation with (some of) the models produced by those techniques.

Task 2: Identify crosscutting concerns. This is composed of two subtasks: identify coarse-grained relationships and identify candidate aspects. (Notice that a crosscut-ting concern may be functional or non-functional. Here we will only concentrate on non-functional ones.)

Task 2.1: Identify coarse-grained relationships. It is useful to relate non-functional concerns (denoted by NFC) with functional ones, through a matrix, as the former may constrain the latter (see Table 1).

Table 1. Relating functional with non-functional concerns Functional Concern

NFC Functional Concern1

Functional Concern 2 …

Functional Concern n

NFC1 NFC 2 … NFC n

Task 2.2: Identify crosscutting concerns. A NFC is crosscutting if it affects more than one other concern. This means that latter must satisfy the former and therefore the NFC needs to be applied (or composed) in some point of another functional con-cern’s implementation. Looking at the matrix (cf. table 1) we can see which NFCs crosscut the modules encapsulating stakeholders’ functional requirements and qualify as candidate aspects (we explain the rationale behind the notion of candidate aspects later in this section2).

Task 3: Compose candidate aspects. The goal of this task is to compose all the concerns to form the whole system. Here we will focus our attention on the composi-tion of those concerns that are crosscutting (candidate aspects), as the non-crosscutting ones bring no new problems. To guide the composition, we propose two subtasks: define composition rules and compose candidate aspects with stakeholders’ functional requirements.

Task 3.1: Define composition rules. The composition rules operate at the granularity of individual requirements (of a given concern) and not just the modules encapsulat-

2 For simplicity we will sometimes use the term aspect instead of candidate aspect. However,

at the level of abstraction we are working on, we are always dealing with candidate aspects.


ing them. Consequently, it is possible to specify how an aspectual requirement influ-ences or constrains the behaviour of a set of non-aspectual requirements in various modules. At the same time, if desired, aspectual trade-offs can be observed at a finer granularity. This alleviates the need for unnecessary negotiations among stakeholders for cases where there might be an apparent trade-off between two (or more) aspects but in fact they are influencing different isolated requirements. It also facilitates iden-tification of individual, conflicting aspectual requirements with respect to which ne-gotiations must be carried out and trade-offs established.

Task 3.2: Compose candidate aspects with stakeholders’ requirements. A com-position rule defines the way in which the crosscutting concerns will be composed with stakeholders’ functional requirements.

Task 4: Handle conflicts. After composing the candidate aspects and stakeholders’ requirements using the composition rules, identification and resolution of conflicts among the candidate aspects is carried out. This is accomplished by: building a con-tribution matrix; attributing weights to those aspects that contribute negatively to each other; solving the conflicts with the stakeholders.

Task 4.1: Build contribution matrix. A contribution relationship between two can-didate aspects defines the way in which one aspect affects the other. This contribution can be collaborative (or positive) and is represented by “+”, or damage (or negative) and is represented by “-“ (see Table 2). (Empty cells represent “don’t care” contribu-tions.)

Table 2. Contributions between candidate aspects Aspects Aspects Aspect1 Aspect2 … Aspectn Aspect1 Aspect2 − … Aspectn

Task 4.2: Attribute weights. Attribute weights to those aspects that contribute nega-tively to each other in relation to a set of stakeholders’ requirements. These weights should reflect the degree of importance of each aspect in the system. Each weight is a real number in the interval [0 .. 1] and represents the priority of an aspect in relation to a set of stakeholders’ requirements. This is done with the stakeholders’ help.

Task 4.3: Resolve conflicts. This should be accomplished by using the weights at-tributed above. Conflict resolution might lead to a revision of the requirements speci-fication (stakeholders’ requirements, aspectual requirements or composition rules). If this happens, then the requirements are recomposed and any further conflicts arising are resolved. The cycle is repeated until all conflicts have been resolved through effective negotiations.

Task 5: Specify aspect dimensions. The last activity in the model is identification of the dimensions of an aspect. We have observed that aspects at this early stage can have an impact that can be described in terms of two dimensions [24]:

6 RITOS2

− Mapping: an aspect might map onto a system feature/function (e.g. a simple method, object or component), decision (e.g. a decision for architecture choice) and design (and hence implementation) aspect (e.g. response time). This is the reason we have chosen to call aspects at the RE stage candidate aspects as, de-spite their crosscutting nature at this stage, they might not directly map onto an aspect at later stages.

− Influence: an aspect might influence different points in a development cycle, e.g. availability influences the system architecture while response time influences both architecture and detailed design

4 A concrete model with viewpoints and XML

The concrete techniques we have chosen are viewpoints [14] for identifying the stakeholder requirements, and XML as the definition language to specify these re-quirements, the candidate aspects identified and the composition rules to relate view-points with aspects. Tool support is provided by the Aspectual Requirements Compo-sition and Decision support tool, ARCaDe. The tool makes it possible to define the viewpoint requirements, aspectual requirements and composition rules using pre-defined templates. These templates can, optionally, be enforced using XML schemas. The modules encapsulating the various requirements and composition rules are stored in eXist, a native XML database system [3]. A combination of DOM (Document Object Model) and SAX (Simple API for XML) is employed to: − validate the composition rules i.e. to ensure that they refer to viewpoints, aspects

and requirements that exist in the database; − compose the aspects and viewpoints and identify resulting conflicts in order to

establish trade-offs. Our choice of viewpoints as a mechanism to specify stakeholders’ requirements is

driven by our previous experience in handling global requirements in viewpoint-oriented requirements engineering [24]. Instead of viewpoints we could have used other requirements approaches such as: goal-oriented requirements which cover func-tional and non-functional requirements [19]; use cases or scenario-based approaches, by specifying which use cases/scenarios are crosscut by a non-functional concern [25]. XML has been chosen because, as demonstrated by the following case study, there is a need for concern-specific actions and composition operators when defining the composition rules. The extensible model offered by XML coupled with the rich specification model of the XML schema language makes it an ideal choice as it is virtually impossible to anticipate the various types of composition operators and ac-tions that might be required. Since the XML schema language is extensible – it is based on XML itself – it is possible to enforce constraints on the specification of composition rules when new operators and/or actions are introduced. Furthermore, the ability to define semantically meaningful tags and informal operators ensures that the readability of the requirements specification is not compromised as the specifica-tion resides in the stakeholders’ domain and must be readable by them.


The following case study illustrates this concrete realisation of the generic aspec-tual requirements model.

4.1 Case study

The case study we have chosen is a simplified version of the real system implemented in the Portuguese motorways network [6]:

“In a road traffic pricing system, drivers of authorised vehicles are charged at toll gates automatically. The gates are placed at special lanes called green lanes. A driver has to install a device (a gizmo) in his/her vehicle. The registration of authorised vehicles includes the owner’s personal data, bank account number and vehicle details. The gizmo is sent to the client to be activated using an ATM that informs the system upon gizmo activation.

A gizmo is read by the toll gate sensors. The information read is stored by the sys-tem and used to debit the respective account.

When an authorised vehicle passes through a green lane, a green light is turned on, and the amount being debited is displayed. If an unauthorised vehicle passes through it, a yellow light is turned on and a camera takes a photo of the plate (used to fine the owner of the vehicle). There are three types of toll gates: single toll, where the same type of vehicles pay a fixed amount, entry toll to enter a motorway and exit toll to leave it. The amount paid on motorways depends on the type of the vehicle and the distance travelled.”

4.2 Applying the model

Task 1: Identify and specify concerns

Identify and specify stakeholders’ requirements3. Each functional concern will be described by means of a viewpoint. The following viewpoints can be identified. Note that some of the viewpoints have sub-viewpoints: − ATM: allows customers to enter their own transactions using cards. The ATM

sends the transaction information for validation and processing. − Vehicle: enters and leaves toll gates. There is a sub-viewpoint Unauthorised Ve-

hicle whose plate number is photographed. − Gizmo: is read by the system and is glued on the windscreen of the car it belongs

to.

3 For simplicity reasons here we will start by identifying and specifying functional concerns

and then do the same with non-functional concerns, changing the order in which we first pre-sented the model in Section 3.

8 RITOS2

− Police: receives information about the unauthorised vehicles and their infrac-tions.

− Debiting System: interacts with the bank to allow the system to debit client ac-counts.

− Toll Gate: through which the vehicles pass when entering or leaving the toll collection system. There are two sub-viewpoints: Entry Toll and Paying Toll. En-try Toll detects gizmos. The Paying Toll viewpoint is further refined into two sub-viewpoints: Single Toll turns the light green and displays the amount to be paid for authorised vehicles and turns the light yellow, sounds an alarm and pho-tographs the plate numbers for unauthorised vehicles; Exit Toll behaves similarly to single toll, except that it must take into account the valid (or invalid) entrance of the vehicle.

− Vehicle Owner: who has three sub-viewpoints: Registration of vehicles, cancella-tion of registration and modification of registration details; Billing in the form of regular invoices and Activation of the gizmo using ATMs.

− System administrator: introduces new information and modifies existing information in the system.

Throughout the paper we will use the viewpoints ATM, Vehicle, Gizmo and Toll Gate to illustrate our approach. Figures 2 through 5 show these viewpoints in XML. The structure is self-explanatory. A Viewpoint tag denotes the start of a viewpoint while a Requirement tag denotes the start of a requirement. Refinements such as sub-viewpoints and sub-requirements are represented via the nesting of the tags. Each requirement has an id which is unique within its defining scope i.e. the viewpoint. Viewpoint names are unique within each case study in ARCaDe. However, XML namespaces can be used for the purpose as well. <?xml version="1.0" ?> - <Viewpoint name="ATM">

- <Requirement id="1"> The ATM sends the customer's card number, account number and gizmo identifier to the sys-tem for activation and reactivation. - <Requirement id="1.1"> The ATM is notified if the activation or reactivation was successful or not. <Requirement id="1.1.1">In case of unsuccessful activation or reactivation the ATM is notified of the

reasons for failure.</Requirement> </Requirement>

</Requirement> </Viewpoint>

Figure 2: The ATM viewpoint in XML <?xml version="1.0" ?> - <Viewpoint name="Vehicle">

<Requirement id="1">The vehicle enters the system when it is within ten meters of the toll gate.</Requirement> <Requirement id="2">The vehicle enters the toll gate.</Requirement> <Requirement id="3">The vehicle leaves the toll gate.</Requirement> <Requirement id="4">The vehicle leaves the system when it is twenty meters away from the toll gate.</Requirement> - <Viewpoint name="UnauthorisedVehicle">

<Requirement id="1">The vehicle number plate will be photographed.</Requirement> </Viewpoint>

</Viewpoint>

Figure 3: The Vehicle viewpoint in XML


<?xml version="1.0" ?> - <Viewpoint name="Gizmo">

- <Requirement id="1"> The gizmo identifier is read by the system. <Requirement id="1.1">The gizmo identifier is validated by the system.</Requirement> <Requirement id="1.2">The gizmo is checked by the system for being active or not.</Requirement>

</Requirement> </Viewpoint>

Figure 4: The Gizmo viewpoint in XML <?xml version="1.0" ?> - <Viewpoint name="TollGate">

- <Viewpoint name="PayingToll"> <Requirement id="1">A green light is turned on if the gizmo is valid.</Requirement>

<Requirement id="2">A yellow light is turned on if the gizmo is not present or invalid.</Requirement> <Requirement id="3">An alarm is sounded if the gizmo is not present or invalid.</Requirement>

- <Requirement id="4"> The amount being debited is displayed if the gizmo is valid. <Requirement id="4.1">The amount being debited depends on the class of the vehicle.</Requirement>

</Requirement> - <Viewpoint name="SingleToll"> <Requirement id="1">The amount being displayed is fixed.</Requirement>

</Viewpoint> - <Viewpoint name="ExitToll"> <Requirement id="1">A yellow light is shown if the vehicle did not enter using a green

lane.</Requirement> <Requirement id="2">The amount being debited depends upon the entry point.</Requirement>

</Viewpoint> </Viewpoint>

- <Viewpoint name="EntryToll"> <Requirement id="1">No signals are shown on passing an entry point.</Requirement>

</Viewpoint> </Viewpoint>

Figure 5: The Toll Gate viewpoint in XML

Identify and specify non-functional concerns. NFCs are identified by analysing the initial requirements. For example, since the owner of a vehicle has to indicate his/her bank details during registration, Security is an issue that the system needs to address. Other NFCs in our case study, identified in a similar way, are: Response Time, Multi-Access System, Compatibility, Legal Issues, Correctness and Availability. For simpli-fication we choose to provide the specification of only three NFCs here: Compatibil-ity, Response Time and Correctness (figures 6 through 8). The choice is aimed at demonstrating a range of dimensions, between Compatibility and Response Time, and conflicts between Response Time and Correctness. The Requirement tag has the same semantics and scoping rules as for the viewpoints. The only difference is that the defining scope is now the non-functional concern. Like viewpoints, NFCs can be nested as well and NFCs names are unique with the scope of a case study in AR-CaDe. <?xml version="1.0" ?> - <NFC name="Compatibility">

- <Requirement id="1"> The system must be compatible with systems used to: <Requirement id="1.1">activate and reactivate gizmos;</Requirement> <Requirement id="1.2">deal with infraction incidents;</Requirement> <Requirement id="1.3">charge for usage.</Requirement>

</Requirement> </NFC>

Figure 6: The Compatibility non-functional concern in XML

10 RITOS2

<?xml version="1.0" ?> - <NFC name="ResponseTime">

- <Requirement id="1"> The system needs to react in-time in order to: <Requirement id="1.1">read the gizmo identifier;</Requirement> <Requirement id="1.2">turn on the light (to green or yellow);</Requirement> <Requirement id="1.3">display the amount to be paid;</Requirement> <Requirement id="1.4">photograph the plate number from the rear;</Requirement> <Requirement id="1.5">sound the alarm;</Requirement> <Requirement id="1.6">respond to gizmo activation and reactivation.</Requirement>

</Requirement> </NFC>

Figure 7: The Response Time non-functional concern in XML

<?xml version="1.0" ?> - <NFC name="Correctness">

- <Requirement id="1"> The system must ensure correctness of the data: <Requirement id="1.1">calculated within the system;</Requirement>

<Requirement id="1.2">exchanged with the environment.</Requirement> </Requirement>

</NFC> Figure 8: The Correctness non-functional concern in XML

During this task, if catalogues were used to identify some NFCs, we may build any complementary documentation suggested by the catalogue. Supposing that we have used the NFR framework to identify a non-functional concern, we can use a Softgoal Interdependency Graphs (SIG) to complement its description. The nodes of a SIG are NFCs, and are represented by clouds, and the lines represent decompositions (of a given NFC into its sub-concerns). When all sub-concerns of a given non-functional concern are needed to achieve that concern, an AND relationship is defined with an arc connecting the lines (see Figure 9). If, on the contrary, not all the sub-concerns are necessary to achieve the concern, an OR relationship is defined with two arcs linking the decomposition lines.

C on fiden tia lity[V eh icle O w n er D ata ]

Secur ityR egister V eh icle

In tegr ity[V eh icle O w n er D a ta ]

Figure 9: Security specification for Register Vehicle

In this case Integrity and Confidentiality are both needed to achieve Security, so an AND relationship is required. Notice that a subject matter is added under the concern name. A subject matter is the topic addressed by the non-functional concern. In Fig-ure 9 Security influences Register Vehicle while Integrity and Confidentiality influ-ence Owner Data.


Task 2: Identify crosscutting concerns

Identify Coarse-grained NFC/viewpoint relationships. As we identify and describe viewpoints and NFCs we can relate them, by building the matrix in table 3.

Table 3. Matrix relating non-functional concerns with viewpoints (P: Police; Gz: Gizmo; DS: Debiting System; TG: Toll Gate; PT: Paying Toll; ST: Single Toll; ExT:

Exit Toll; ET: Entry Toll; Vh: Vehicle; UV: Unauthorized Vehicle; VO: Vehicle Owner) VP NFC

P

Gz

DS

ATM

TG PT ST

ExT

ET

Vh

...

VO

Response Time Availability

Security Legal Issues Compatibility Correctness Multi Access

Identify candidate aspects. The matrix in table 3 shows which NFCs cut across specific viewpoints. For example, we can observe that the requirements in the Re-sponse Time NFC influence and constrain the requirements in the viewpoints: Gizmo, ATM, Toll Gate and Vehicle. Similarly, Compatibility requirements crosscut the requirements specified by the Police, Debiting System and ATM viewpoints. In fact in our case study all the NFCs are crosscutting. Consequently all the NFCs identified form candidate aspects as they cut across multiple viewpoints. However, in another system a NFC might constrain a single viewpoint and, hence, will not qualify as a candidate aspect (note that it will still be modularised as a concern).

Once a candidate aspect has been identified, the XML specification of the corre-sponding NFC is transformed to reflect this fact. The transformation is a simple op-eration (using a simple transformation in XSLT – eXtensible Style Sheet Language for Transformations) which replaces the NFC tag with an Aspect tag. While this might seem a trivial transformation, it ensures that the specification reflects the aspec-tual nature of a concern.

Task 3: Compose candidate aspects

Define composition rules. Composition rules define the relationships between aspec-tual requirements and viewpoint requirements at a fine granularity (unlike the rela-tionship matrix in table 3 which is aimed at identifying candidate aspects). Composi-tion rule definitions can be governed by an XML schema in ARCaDe. However, for simplification we describe the structure of composition rules with reference to some examples and not the XML schema definition. As shown in figures 10 and 11, a co-herent set of composition rules is encapsulated in a Composition tag. Figure 10 en-capsulates all compositions for the Compatibility requirements while figure 11 does so for Response Time requirements. The semantics of the Requirement tag here differ

12 RITOS2

from the tags in the viewpoint and aspect definitions. Each Requirement tag has at least two attributes: the aspect or viewpoint it is defined in and an id which uniquely identifies it within its defining scope. If a viewpoint requirement has any sub-requirements these must be explicitly excluded or included in the Constraint imposed by an aspectual requirement. This is done by providing an include or exclude value to the optional children attribute. A value of all for a viewpoint or id value implies that all the viewpoints or requirements within the specified viewpoint are to be con-strained.

The Constraint tag defines an, often concern-specific, action and operator defining how the viewpoint requirements are to be constrained by the specific aspectual re-quirement. Although the actions and operators are informal they must have clearly defined meaning and semantics to ensure valid composition of aspects and view-points. The Outcome tag defines the result of constraining the viewpoint requirements with an aspectual requirement. The action value describes whether another viewpoint requirement or a set of viewpoint requirements must be satisfied or merely the con-straint specified has to be fulfilled (see table 6). <?xml version="1.0" ?> - <Composition>

- <Requirement aspect="Compatibility" id="1.1"> - <Constraint action="ensure" operator="with">

<Requirement viewpoint="ATM" id="all" /> </Constraint> <Outcome action="fullfilled" />

</Requirement> - <Requirement aspect="Compatibility" id="1.2">

- <Constraint action="ensure" operator="with"> <Requirement viewpoint="Police" id="all" />

</Constraint> <Outcome action="fullfilled" />

</Requirement> - <Requirement aspect="Compatibility" id="1.3">

- <Constraint action="ensure" operator="with"> <Requirement viewpoint="DebitingSystem" id="all" />


</Requirement> </Composition>

Figure 10: The composition rules for Compatibility requirements <?xml version="1.0" ?> - <Composition>

- <Requirement aspect="ResponseTime" id="1.1"> - <Constraint action="enforce" operator="between">

<Requirement viewpoint="Vehicle" id="1" /> <Requirement viewpoint="Vehicle" id="2" />

</Constraint> - <Outcome action="satisfied">

<Requirement viewpoint="Gizmo" id="1" children="include" /> </Outcome>

</Requirement> - <Requirement aspect="ResponseTime" id="1.2">

- <Constraint action="enforce" operator="between"> <Requirement viewpoint="Gizmo" id="1" children="include" /> <Requirement viewpoint="Vehicle" id="3" />

</Constraint> - <Outcome action="satisfied" operator="XOR">

<Requirement viewpoint="PayingToll" id="1" /> <Requirement viewpoint="PayingToll" id="2" />

</Outcome> </Requirement>


- <Requirement aspect="ResponseTime" id="1.3"> - <Constraint action="enforce" operator="between">

<Requirement viewpoint="PayingToll" id="1" /> <Requirement viewpoint="Vehicle" id="3" />


<Requirement viewpoint="PayingToll" id="4" children="include" /> </Outcome>


- <Constraint action="enforce" operator="between"> <Requirement viewpoint="PayingToll" id="2" /> <Requirement viewpoint="Vehicle" id="4" />


<Requirement viewpoint="UnauthorisedVehicle" id="1" /> </Outcome>


- <Constraint action="enforce" operator="between"> <Requirement viewpoint="PayingToll" id="2" /> <Requirement viewpoint="Vehicle" id="4" />


<Requirement viewpoint="PayingToll" id="3" /> </Outcome>


- <Constraint action="enforce" operator="on"> <Requirement viewpoint="ATM" id="1" children="include" />


</Requirement> </Composition>

Figure 11: The composition rules for Response Time requirements

The informality of the actions and operators ensures that the composition specifi-cation is still readable by the stakeholders, an important consideration during re-quirements engineering. For example, if we look at the first composition rule in figure 11 and focus on the values in bold we get the following: “Response Time require-ment 1.1 must be enforced between requirements Vehicle 1 and Vehicle 2 with the outcome that Gizmo requirement 1 including its children is satisfied”.

Tables 4, 5 and 6 describe the semantics of the actions and operators, which we have defined so far, for Constraint and Outcome. They also list the aspects that an operator or action might be specific to. The interesting point to note here is that not all operators are aspect-specific, e.g. XOR is a generic operator (reflected by a value ANY in the aspect column in table 4). Also, the actions for the Outcome are generic and not specific to a particular aspect. It is, however, not possible to say whether Outcome actions are always generic, as more case studies need to be carried out be-fore arriving at such a conclusion. It is also worth noting (from table 5) that although the same operator might apply to different aspectual requirements, not all operator-action combinations are valid in the Constraint specification for a particular aspect. The combinations in table 5 apply to the case study in this paper only. More case studies need to be carried out to determine the complete set of valid operator-action combinations.

14 RITOS2

Table 4: Description of Constraint actions Constraint Action

Type Description

Aspects applicable to

enforce Used to impose an additional condition over a set of viewpoint requirements.

Response Time

ensure Used to assert that a condition that should exist for a set of viewpoint requirements actually exists.

Availability, Compati-bility, Correctness

provide Used to specify additional features to be incorporated for a set of viewpoint requirements.

Security, Multiple Access

applied Used to describe rules that apply to a set of viewpoint requirements and might alter their outcome.

Legal Issues

exclude Used to exclude some viewpoints or requirements if the value all is specified.

ANY

Table 5: Description of Constraint operators Constraint Operator

Type Description

Action Valid aspect: action-operator combinations

during Describes the temporal interval during which a set of requirements is being satisfied.

ensure Availability: ensure-during

be-tween

Describes the temporal interval falling between the satisfaction of two requirements. The interval starts when the first requirement is satisfied and ends when the second one is to start being satisfied.

enforce Response Time: enforce-between

on Describes the temporal point after a set of require-ments has been satisfied.

enforce Response-Time: enforce-on

for Describes that additional features will complement the viewpoint requirements.

ap-plied, provide

Legal Issues: applied-for Security: provide-for MultipleAccess: provide-for

with Describes that a condition will hold for two sets of requirements with respect to each other.

ensure Compatibility: ensure-with

in Describes that a condition will hold for a set of requirements that has been satisfied.

ensure Correctness: ensure-in

XOR Exclusive-OR (when either requirement is satisfied but not both)

ANY ANY

Table 6: Description of Outcome actions Outcome Action

Type Description

Aspects applicable to

satisfied Used to assert that a set of viewpoint requirements will be satisfied after the constraints of an aspectual requirement have been applied.

ANY

fulfilled Used to assert that the constraints of an aspectual requirement have been successfully imposed.

ANY

Compose aspects and viewpoints. The candidate aspects and viewpoints are com-posed using the composition rules. This leads to identification of conflicts among aspects whose requirements constrain the same or overlapping sets of viewpoint re-quirements. In case of ARCaDe this process is optimised as any potential interaction or conflict can be deduced from the composition rules. Consequently, one does not need to compose the aspects and viewpoints until the conflicts have been resolved. In


another instantiation of our generic model this might not be possible and composition might be required to identify conflicts.

Task 4: Handle conflicts

Build the contribution table. The contribution table shows in which way (negatively or positively) an aspect contributes to the others. The matrix represented in table 7 is symmetric, i.e. we only need to consider the diagonally upper triangle (or the lower one).

In this case, Response Time contributes negatively to Security, Correctness and Multiple Access and positively to Availability, for example. Whenever there is a nega-tive contribution between aspects we are faced with conflict if these aspects apply to the same or overlapping sets of requirements in the viewpoints.

Table 7. Contribution matrix

Aspects Aspects

Response Time Availability Security

Legal Issues Compatibility Correctness

Multi-Access

Response Time − − − Availability Security Legal Issues Compatibility Correctness Multi-Access

Attribute weights to conflicting aspects. We can help resolve aspectual conflicts by attributing weights to the cells of the aspect/viewpoint matrix (derived as the con-cern/viewpoint matrix in section 4.1.3) where the conflicting aspects apply to the same viewpoints. Weighting allows us to describe the extent to which an aspect may constrain a viewpoint (c.f. table 8).

Table 8. Matrix with weights to conflicting aspects

(P: Police; Gz: Gizmo; DS: Debiting System; TG: Toll Gate; PT: Paying Toll; ST: Single Toll; ExT: Exit Toll; ET: Entry Toll; Vh: Vehicle; UV: Unauthorized Vehicle; VO: Vehicle Owner)

VP Aspects

P

Gz

DS

ATM

TG

PT

ST

ExT

ET

Vh

...

VO

Response Time 1,0 0,3 1,0 1,0 1,0 1,0 1,0 1,0 …

Availability Security 1,0 Legal Issues Compatibility

Correctness 0,8 1,0 1,0 1,0 1,0 1,0 Multi Access 0,3 0,3 0,3 0,3 0,3 0,3 0,3 0,3 …

The values are given according to the importance each aspect has for each view-

point. The scales we are using are based on ideas from fuzzy logic and have the fol-lowing meaning:

16 RITOS2

− Very important takes values in the interval ] 0,8 .. 1,0] − Important takes values in the interval ] 0,5 .. 0,8] − Average takes values in the interval ] 0,3 .. 0,5] − Not so important takes values in the interval ] 0,1 .. 0,3] − Do not care much takes values in the interval [0 .. 0,1]

Using fuzzy values (very important, important, not so important, etc) facilitates the stakeholders’ task of attributing priorities to conflicting aspects. Therefore, for viewpoint Gizmo, for example, Response Time has higher priority than Correctness and Multiple Access, and Correctness has higher priority than Multiple Access.

Resolve conflicts. The conflict mentioned above should not be too difficult to re-solve, as the weights express priorities. However, Toll Gate and its sub-viewpoints: Paying Toll (with sub-viewpoints: Single Toll, Exit Toll) and Entry Toll still show a conflicting situation between Response Time and Correctness. These two aspects contribute negatively to each other and have the same weight allocated to them (see the cells highlighted in table 8).

Using ARCaDe we can determine that the conflict is in fact with reference to re-quirements 4 and 4.1 in Paying Toll. On one hand, the toll gate needs to react in time, on the other hand, it needs to display the correct amount. To resolve these kinds of conflicts negotiation is needed among the stakeholders. One suitable solution will be to lower the weight allocated to Response Time to 0.8 for the affected viewpoints. This is because Correctness is more important than Response Time. It is essential that the correct amount is displayed (and subsequently billed) even though the driver may not see it (if s/he is driving too fast).

Once all the conflicts have been resolved the specification is revised and recom-position carried out to identify any further conflicts.

Task 5: Specify aspect dimensions

Specification of a candidate aspect’s dimensions makes it possible to determine its influence on later development stages and identify its mapping onto a function, deci-sion or aspect. Consider our Compatibility candidate aspect. The requirements de-rived from this aspect will influence parts of the system specification, architecture and design pertaining to requirements derived from viewpoints constrained by it. They will also influence system evolution as change of the user’s ATM cards must be anticipated. The Compatibility aspect will, however, map on to a function allowing activation and reactivation of the gizmo. The Response Time aspect, on the other hand, will influence the type of architecture chosen and the design of the classes realising the requirements constrained by Response Time. It will map to an aspect at the design and implementation level because response time properties cannot be en-capsulated in a single class and will be otherwise spread across a number of classes. The various candidate aspects in our case study and their mappings and influences are shown in table 9.


Table 9: Aspect dimension specification

Candidate aspect Influence Mapping

Compatibility Specification, archi-tecture, design, evolution

Function

Response time Specification, architecture, design Aspect

Legal issues Specification Function

Correctness Specification, design Function

Security Specification, architecture, design Aspect

Availability Architecture Decision

Multi-user system Architecture, design Aspect

4 Related Work

Recently there has been growing interest in propagating the aspect paradigm to the earlier activities of the software development lifecycle. A number of approaches to aspect-oriented design have been proposed e.g. [8, 7, 27]. At the last two conferences on Aspect-Oriented Software Development, a workshop was devoted to aspect-oriented requirements and architecture design [2a, 2b].

Suzuki and Yamamoto propose an extension to UML to support aspects, where an aspect is described as a classifier in the meta-model [27]. The focus is on extending UML with aspects to support the design activity. An XML-based aspect description language is employed to interchange aspect models between development tools such as CASE tools and aspect weavers. The XML-based specifications supported by ARCaDe can also be used as an interchange mechanism.

Composition patterns [8, 9] is another approach to handle crosscutting concerns at the design level. This model, based on subject-oriented design [7] and UML, pro-motes reusability and traceability to the following activities of the software develop-ment. In our approach the traceability of aspectual requirements is supported from the earlier stage of requirements engineering. This makes it possible to identify the map-ping and influence of a requirements level aspect on the architecture and design in addition to the implementation.

A UML compliant approach to handle quality attributes (i.e. non-functional re-quirements) at the early stages of the development process is proposed in [21]. Unlike the approach in this paper, separation of composition rules is not supported. Also, it is only possible to detect that a quality attribute affects a (set of) UML model(s). It is not possible to identify relationships at a more detailed level, such as between quality attributes and parts of the functionality represented in a UML model. The mapping and influence of a quality attribute on artefacts at later development stages is not discussed. Furthermore, the model in [21] does not provide explicit support for con-flict resolution.

18 RITOS2

Dingwall-Smith and Finkelstein [12] present the building of a system for runtime monitoring of system goals. This system is specified using the KAOS approach [10] and currently it supports its achieve pattern. The major similarity with our work is in the way composition rules are separated. However, in their approach Hyper/J and its concepts are used as the definition language while we define a more abstract set of actions and operators that are independent of any aspect-oriented programming lan-guage. Also, while Dingwall-Smith and Finkelstein’s approach is specific to the con-struction of a system for runtime monitoring, we discuss modularisation and composi-tion of aspects and stakeholders’ requirements at a general level, independently of any particular application or crosscutting concern.

In the Architecture Trade-off Analysis Method – ATAM [18] various competing quality attributes and their interactions are characterised. This is achieved by building and maintaining both quantitative and qualitative models of these attributes. The models are used as a basis to evaluate and evolve the architecture. The main focus of ATAM is on identifying the trade-off points at the architecture level. The work de-scribed in this paper focuses on identifying conflicting concerns and establishing critical trade-offs before the architecture is derived. Consequently, it is closer to the Twin Peaks model [22] which focuses on developing requirements and architectures in parallel in order to develop an early understanding of the system’s technical feasibility, discover further requirements and constraints and evaluate alternative design solutions.

The aspect-specific actions and operators employed by the composition rules bear a relationship with [23] which proposes employing the most suitable aspect-oriented programming technique to implement a particular concern. In our composition rules the most suitable action or operator is employed to deal with a particular requirements level aspect. This is also in close relation with the work on domain specific aspect modelling. One such environment and language is proposed by Gray et al. [15]. The focus of their work is on the design level while the composition rules, actions and operators discussed in this paper are aimed at the requirements level. The Embedded Constraint Language (ECL), based on OCL, employed by [15] is a design-level speci-fication language that is not appropriate for requirements.

5 Conclusions and future work

In the beginning we stated that the generic aspect-oriented requirements engineering model and its concrete realisation with viewpoints and XML is aimed as a stepping-stone towards two goals: 1. Providing improved support for separation of crosscutting functional and non-

functional properties during requirements engineering hence offering a better means to identify and manage conflicts arising due to tangled representations;

2. Identifying the mapping and influence of requirements level aspects on artifacts at later development stages hence establishing critical trade-offs before the architec-ture is derived.


The separation of composition information from the aspects and viewpoints makes them highly independent of each other hence providing an improved separation of concerns. This also improves the reusability of the aspects in some instances. For example, the Correctness aspect in figure 8 is not specific to the toll collection system and may be reused to specify correctness requirements in another system. The Avail-ability aspect (not shown in the paper) exhibits a similar degree of reusability. Since the composition rules operate at the granularity of individual requirements, it is pos-sible to identify and manage conflicts at a fine granularity. This optimises the task of the requirements engineer identifying negotiation points for the stakeholders. Not only can the requirements engineer identify individual viewpoint and aspectual requirements for negotiation, s/he can also capture situations where there might be an apparent conflict with reference to the viewpoints, but no conflict at the level of indi-vidual requirements. The use of abstract, concern-specific operators coupled with the extensible model of XML ensures that the approach remains adaptable to other appli-cations and extensible to incorporate new aspects as the requirements for the toll collection system change. The operators also help maintain the informality of the requirements specification while providing well-defined composition semantics.

The identification of the mapping and influence of a requirement level aspect pro-motes traceability of broadly scoped requirements and constraints throughout system development, maintenance and evolution. The improved modularisation and traceability obtained through early separation of crosscutting concerns can play a central role in building systems resilient to unanticipated changes hence meeting the adaptability needs of volatile domains such as banking, telecommunications and e-commerce.

With increasing support for aspects at the design and implementation level, the in-clusion of aspects as fundamental modelling primitives at the requirements level and identification of their mappings also helps to ensure homogeneity in an aspect-oriented software development process.

Our future work will focus on developing concrete realisations of the generic AORE model with use cases, scenarios and problem frames. We anticipate the exten-sible model of XML to play a fundamental role in this context (as has been the case for viewpoints). We intend to support these concrete models within ARCaDe. We also aim to develop support for validation of requirement level aspects. The case study in this paper contained only non-functional aspects. Another future direction will, therefore, be to conduct case studies involving both functional and non-functional aspects. We are also interested in exploring the use of fuzzy logic for trade-off analysis based on the weights we may give to aspects and viewpoints. This could help us identify a process to rank viewpoints and aspects by degree of impor-tance in a system and use the result as a basis for incremental development.

Acknowledgements

This work has been developed in collaboration with. Awais Rashid, João Araújo and Isabel Brito. It has been partly supported by CITI and ICCTI/British Council grants.

20 RITOS2

References

[1] "AspectJ Home Page", Xerox PARC, USA, http://aspectj.org/, 2002. [2a] "Early Aspects: Aspect-Oriented Requirements Engineering and Architecture

Design", Workshop at AOSD 2002, http://trese.cs.utwente.nl/AOSD-EarlyAspectsWS/.

[2b] "Early Aspects 2003: Aspect-Oriented Requirements Engineering and Architec-ture Design", Workshop at AOSD 2003, http://www.cs.bilkent.edu.tr/AOSD-EarlyAspects/

[3] "eXist XML Database Management System", W. Meier, http://exist.sourceforge.net/, 2002.

[4] "XBel Framework - Reasoning with Inconsistency", A. Cheng, http://www.cs.toronto.edu/~annie/FMGroup/xbel.html, 2002.

[5] L. Bergmans and M. Aksit, "Composing Crosscutting Concerns using Composi-tion Filters", CACM, 44(10), 2001.

[6] R. Clark and A. Moreira, "Constructing Formal Specifications from Informal Requirements", Software Technology and Engineering Practice, 1997, IEEE Computer Society Press, pp. 68-75.

[7] S. Clarke, W. Harrison, H. Ossher, and P. L. Tarr, "Subject-Oriented Design: Towards Improved Alignment of Requirements, Design, and Code", OOPSLA, 1999, ACM, pp. 325-339.

[8] S. Clarke and R. J. Walker, "Composition Patterns: An Approach to Designing Reusable Aspects", ICSE, 2001.

[9] S. Clarke and R. J. Walker, "Towards a standard design language for AOSD", AOSD, 2002, ACM, pp. 113 - 119.

[10] A. Dardenne, A. Lamsweerde, and S. Fickas, "Goal-directed Requirements Ac-quisition", Science of Computer Programming, Vol. 20, pp. 3-50, 1993.

[11] L. Chung, B. Nixon, E. Yu, J. Mylopoulos: Non-Functional Requirements in Software Engineering, Kluwer Academic Publishers, 2000

[12] A. Dingwall-Smith and A. Finkelstein, "From Requirements to Monitors by way of Aspects", AOSD 2002 Workshop on Early Aspects, 2002.

[13] T. Elrad, R. Filman, and A. Bader (eds.), "Theme Section on Aspect-Oriented Programming", CACM, 44(10), 2001.

[14] A. Finkelstein and I. Sommerville, "The Viewpoints FAQ." BCS/IEE Software Engineering Journal, 11(1), 1996.

[15] J. Gray, T. Bapty, S. Neema, and J. Tuck, "Handling Crosscutting Constraints in Domain-Specific Modeling", CACM, 44(10), pp. 87-93, 2001.

[16] J. Grundy, "Aspect-Oriented Requirements Engineering for Component-based Software Systems", 4th IEEE Int'l Symp. on RE, 1999, IEEE CS Press, pp. 84-91.

[17] I. Jacobson, Object-Oriented Software Engineering - a Use Case Driven Ap-proach: Addison-Wesley, 1992.

[18] R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson, and J. Carriere, "The Architecture Tradeoff Analysis Method", ICECCS, 1998, IEEE CS Press, pp. 68-78.


[19] A. Lamsweerde, "Goal-Oriented Requirements Engineering: A Guided Tour", 5th Int'l Symp. on RE, 2001, IEEE CS Press, pp. 249-261.

[20] K. J. Lieberherr, D. Orleans, and J. Ovlinger, "Aspect-Oriented Programming with Adaptive Methods", CACM, 44(10), pp. 39-41, 2001.

[21] A. Moreira, J. Araújo, and I. Brito, "Crosscutting Quality Attributes for Re-quirements Engineering", SEKE, 2002, ACM, pp. 167-174.

[22] B. Nuseibeh, "Weaving Together Requirements and Architectures", IEEE Com-puter, 34(3), pp. 115-117, 2001.

[23] A. Rashid, "A Hybrid Approach to Separation of Concerns: The Story of SADES", Reflection conf., 2001, Springer-Verlag, LNCS 2192, pp. 231-249.

[24] A. Rashid, P. Sawyer, A. Moreira, and J. Araujo, "Early Aspects: A Model for Aspect-Oriented Requirements Engineering", IEEE Joint Int'l Conf. on RE, 2002, IEEE CS Press, pp. 199-202.

[25] G. Schneider and J. Winters, Applying Use Cases - A Practical Guide: Addison-Wesley, 1998.

[26] I. Sommerville and P. Sawyer, Requirements Engineering - A Good Practice Guide: John Wiley and Sons, 1997.

[27] J. Suzuki and Y. Yamamoto, "Extending UML with Aspects: Aspect Support in the Design Phase", ECOOP Workshop on Aspect-Oriented Programming, 1999.

[28] P. L. Tarr, H. Ossher, W. H. Harrison, and S. M. Sutton, "N Degrees of Separa-tion: Multi-Dimensional Separation of Concerns", ICSE, 1999, ACM, pp. 107-119.

[29] Yu, E.: "Modelling Strategic Relationships for Process Reengineering": PhD Thesis, University of Toronto, 1995.

22 RITOS2

Desarrollo Basado en Componentes Utilizando UML

Raquel Anaya

Universidad EAFIT. Medellín, Colombia [email protected]

Abstract. El enfoque de desarrollo basado en componentes busca la adopción sistémica de la reutilización en el proceso de desarrollo de software. Este proceso parte de la definición de los requisitos, para luego especificar la arquitectura de componentes en tres pasos iterativos: identificación del componente, análisis de interacciones y especificación del componente. Tres principios básicos diferencian esta aproximación del ADOO tradicional.: componentes de especificación antes que componentes de implementación, tipos antes que clases y diseño basado en interfaces antes que diseño basado en clases. El lenguaje UML se extiende a través de estereotipos, para representar tres constructores básicos: interfaces, componentes y tipos. Se utiliza la arquitectura por capas para definir los principios de interacción de los componentes : los componentes actividad que representan la capa de lógica de la aplicación y los componentes de negocio que representa la lógica de negocio.

1. Introducción

Integrar formalmente la reutilización en el proceso de desarrollo de software, es uno de los retos que enfrenta la comunidad informática. Tal como lo afirma Mili, la madurez del proceso de desarrollo de software como una disciplina de ingeniería será posible en la medida en que se cuente con metodologías y tecnologías para el desarrollo de productos a partir de artefactos que son reutilizados de forma rutinaria y a escala industrial [1] [3]. Aunque el concepto de construir software tomando partes ya desarrolladas no es nuevo, el desarrollo de la tecnología ha incrementado significativamente la posibilidad de construír sistema a partir de componentes reusables, generando expectativas entre clientes y proveedores que no siempre han sido satisfechas [2]. En la Ingeniería de Software Basada en componentes (Component Based Software Engineering – CBSE) el desarrollo de una solución software se percibe como un trabajo de adaptación y composición a partir de componentes, los cuales pueden tener

diversos orígenes: ya desarrollados para uso genérico, comprados, o desarrollados a la medida.

CBSE ha sido reconocida como una nueva subdisclina de la Ingeniería de Software con tres objetivos importantes: (1) Desarrollar sistemas a partir de componentes ya construidos, (2) Desarrollar componentes como entidades reusables (3) Mantener y evolucionar el sistema a partir de la customización y reemplazo de sus componentes. Aunque la motivación inicial de este enfoque estaba directamente relacionado con el rápido avance de la infraestructura tecnológica de componentes, la experiencia ha demostrado que la adopción exitosa de este enfoque requiere una aproximación sistémica en la que se integran aspectos tecnológico, metodológicos, organizacionales y legales [2] . Últimamente este enfoque de desarrollo ha despertado un gran interés, tanto en la academia como en la industria [5][6][7][8]. Se han propuesto aproximaciones metodológicas que han sido aplicadas a escala industrial como [5][6] y se han realizado esfuerzos por ofrecer propuestas académicas intensivas en el uso de UML [9][10], que disminuyen en algún grado la complejidad que hay detrás de estos enfoques. Todas las propuestas coinciden en identificar el componente como un elemento clave que se mueve a lo largo de todo el proceso de desarrollo; el componente nace como un artefacto software cuya estructura y comportamiento es especificado utilizando un lenguaje visual independiente del entorno en el que será implementado, para luego convertirse en una unidad binaria de distribución en un modelo de arquitectura determinado

El objetivo de este trabajo es presentar una guía metodológica para el desarrollo basado en componentes utilizando UML, que retoma buena parte de los planteamientos dados en [9] y [11]. La sección 2 define los conceptos básicos en los que se fundamenta el desarrollo basado en componentes, la sección 3 presenta las características generales del proceso y detalla la guía metodológica de los flujos de requisitos y especificación, la sección 4 presenta un ejemplo que ilustra algunas actividades del proceso y sus diferencias con un análisis y diseño OO tradicional, la sección 5 introduce un análisis comparativo de aproximaciones de desarrollo y finalmente se presentan las conclusiones y trabajos futuros.

2. Fundamentación Conceptual

2.1 Objeto

Un objeto es una unidad de instanciación con una identidad única, un estado y un conjunto de operaciones. El estado esta representado por el conjunto de valores que

24 RITOS2

toman las propiedades en un instante de tiempo, el cual varía dinámicamente como resultado de la ejecución de sus operaciones. El objeto puede trascender el proceso que lo crea utilizando un almacenamiento estable (archivo, base de datos, etc.): en este caso se entiende que su estado es persistente. La clase es la plantilla genérica que define el espacio de estados posibles del objeto y a partir de la cual se pueden instanciar los objetos. Es importante distinguir la diferencia entre clase y tipo. Mientras que la clase hace referencia a una unidad de especificación o implementación (espacio de la solución), el tipo hace referencia a una unidad de conceptualización que permite identificar entidades o conceptos relevantes en el dominio (espacio del problema) [11]. Esta diferencia entre clase y tipo, dará lugar a diagramas de clase con diferente propósito, alcance y nivel de detalle que facilitará un acercamiento progresivo a la solución.

2.2 Componente vs. Objeto

Un componente es una unidad de utilización independiente que puede ser reemplazable y provee una funcionalidad útil que ha sido reunida para satisfacer una necesidad. En palabras de Szyperski, el componente se define como “ una unidad de composición con interfaces especificadas mediante contratos y con dependencias de contexto explícitas. Puede ser entregado de manera independiente y es sujeto a composición por terceras partes”. [12]. A diferencia de los objetos, el componente no tiene estado persistente por lo tanto no puede ser distinguido de otras copias del mismo. El concepto de componente se apoya fuertemente en los principios básicos de encapsulación y polimorfismo de modelo de objetos. Es por lo tanto común, que un componente este conformado por un conjunto de clases cuyos objetos se instancian para implementar la funcionalidad del componente en un lenguaje de programación orientado a objetos. Sin embargo, es también posible que el componente este internamente estructurado en módulos escritos en cualquier tipo de lenguaje de programación.

2.3 Interfaces

Los componentes ofrecen servicios a través de su interface, lo que garantiza que exista una clara separación entre la especificación del componente y su implementación. La funcionalidad total que el componente se compromete a implementar puede estar dividida en varias interfaces. Esto permite que las relaciones de dependencia entre componentes estén restringidas a interfaces individuales, dando una mayor flexibilidad en el momento de reemplazar o modificar el componente. Las interfaces pueden estar asociadas a los componentes con dos propósitos: para establecer los servicios ofrecidos por el componente, desde su perspectiva servidora,


denominadas interfaces provistas y para definir los servicios que necesita de otros para poder trabajar, desde su perspectiva cliente, denominadas interfaces requeridas [4] Un componente puede directamente proveer una interface, cuando se trata de interfaces procedurales de librerías tradicionales, o puede implementar objetos, que de manera indirecta provean la interface requerida. Aunque desde el punto de vista académico es deseable que el componente establezca una clara separación entre su especificación (interface) y su implementación, desde el punto de vista práctico es común observar componentes como parte de un sistema que no definen de manera explícita las interfaces y no obedecen a reglas establecidas por algún modelo de componentes. Tal es el caso de las aplicaciones legado que representan una funcionalidad clave del negocio y que fueron construidas sin tener en cuenta la tecnología de componentes.

2.4 Estados y Contratos del Componente

En su estado final el componente representa una unidad de ejecución o utilización que opera en un modelo de componentes (CORBA, .NET, J2EE, etc.), que hace las veces de contenedor, el cual define las reglas de interacción entre ellos. No obstante, es importante analizar diferentes etapas por las que evoluciona el componente antes de convertirse en un unidad de ejecución.

Especificación del Componente. Esta fase especifica el componente de manera independiente a la plataforma en la que va a ser construido. La especificación del componente se alcanza a través de la especificación de las interfaces que lo conforman. Se establece una clara separación entre la especificación de la interface y la especificación del componente. La especificación del componente establece el contrato con el implementador, el ensamblador y el probador y delimita la unidad de implementación y los límites de encapsulamiento. Es decir, la especificación del componente determina la granularidad de las piezas reemplazables de un sistema. La especificación de la interface, por su parte, representa la unidad de trabajo del diseñador del componente y sirve para definir la signatura de operaciones que la conforman.

Implementación del Componente. En esta fase se realiza o traduce la especificación ya definida a un entorno de implementación concreto, utilizando un lenguaje de programación determinando y respetando los reglas que establece un modelo de componentes. La implementación del componente se realiza diseñando la estructura interna del componente y construyendo el código para todas y cada una de las interfaces que el componente especifica. Si se trata de reutilizar componentes que ya existen, es probable que se requiera construir algún código intermedio (glue code) que permita adecuar las interfaces suministradas por el componente existente a las interfaces requeridas por el sistema.

26 RITOS2

Instalación del componente. Ejecuta las acciones necesarias para dar disponibilidad del componente en la plataforma específica, para ser utilizado por las diferentes aplicaciones.

Objeto Componente. Instancia de un componente ya instalado en el momento cuando este va a ser invocado para su utilización.

Las diferentes etapas del componente ya presentadas, dan lugar a definiciones del componente a diferente nivel de abstracción. Cada rol involucrado en el proyecto (diseñador, implementador, probador, ensamblador, instalador, etc.) tiene diferente percepción del componente. El componente debe entonces, establecer un contrato que sea respetado por las partes que interactuan. Se distinguen dos tipos de contrato: El contrato de uso que establece un acuerdo entre la interface del objeto componente y sus clientes y el contrato de realización que establece un acuerdo entre la especificación del componente y sus implementaciones. Mientras que el contrato de realización se establece en la fase de diseño, el contrato de uso se asegura en tiempo de ejecución.

2.5 Arquitectura

Los temas de arquitectura software (SA) y componentes están estrechamente relacionados [4]. Todo diseño de software comienza con definir la estructura el sistema en términos de partes más pequeñas tan independientes como sea posible. En una primera fase de esta estructuración, el diseño de la arquitectura obedece a aspectos de funcionalidad que posteriormente va siendo refinada para considerar diversos requisitos de calidad. Una vez definida la arquitectura, se desarrollan o seleccionan los componentes que la harán ejecutable [2].

2.5.1 La Arquitectura y los Requisitos del Sistema

La manera como se establece la arquitectura de un sistema, depende en buena medida del alcance de reuso que se propone la organización. Dados los requerimientos de un sistema, se pueden tener componentes de propósito especial desarrollados específicamente para el sistema, componentes ya existentes desarrollados internamente para múltiples uso o componentes comerciales construidos por terceras partes, llamados componentes COTS (Comercial Off The Shelf) [12]. Cuando se trata de componentes de propósito especial desarrollados para el sistema, es natural que la arquitectura se establezca de manera descendente (top down): en este caso el componente que va a ser construido respetará los acuerdos de alto nivel establecidos en la arquitectura.


Cuando se trata de componentes desarrollados internamente para múltiples usos, es muy probable que algunos aspectos de la arquitectura estén establecidos previamente, (antes de los requisitos del sistema). Si, además, el componente construido representa una funcionalidad relevante del negocio (componentes de granularidad gruesa), es muy probable que éste haya sido construido como parte de un framework de negocio; en este caso, el proceso de elicitación de requisitos es guiado por la arquitectura misma estableciendo los puntos de variación del sistema especifico con respecto a las características ya establecidas en la arquitectura. La especificación se concentra entonces en diseñar las extensiones a los componentes ya construidos utilizando los puntos de extensión definidos por el framework [13]. En el caso de componentes COTS, es importante establecer una adecuada coordinación entre los procesos de elicitación y negociación de requisitos y los procesos de búsqueda y selección de los componentes; una definición de requisitos sin considerar las características de los componentes candidatos a comprar, puede derivar en que luego no se encuentren componentes que satisfagan los requerimientos establecidos; por el contrario, una selección temprana de los componentes puede derivar en que no se obtuvieron todos los requerimientos de los clientes. Es por lo tanto necesario que el proceso de establecimiento de la arquitectura en el desarrollo basado en COTS, se defina de manera iterativa en los dos sentidos: desde los requerimientos hasta la arquitectura y desde los componentes hasta la arquitectura [2].

2.5.2 Caracterizando la Arquitectura

Puesto que la arquitectura es el elemento central de diseño en este tipo de aproximaciones, es importante definir características adicionales de la arquitectura.

Niveles de la arquitectura. Representa el grado de detalle de la arquitectura en diferentes etapas del proceso. En un primer acercamiento, cuando la arquitectura representa aspectos conceptuales de especificación, recibe el nombre de arquitectura de especificación o arquitectura conceptual. En una siguiente etapa la arquitectura representa aspectos concretos en el espacio de la solución y recibe el nombre de arquitectura de implementación. En su etapa final la arquitectura describe la manera como se distribuye en la plataforma de Hardware / Software y recibe el nombre de arquitectura de despliegue [2].

Estos diferentes niveles de la arquitectura representan una jerarquía de modelos por niveles en donde los modelos del siguiente nivel de detalle deben respetar el contrato establecido en los modelos del nivel anterior. Las propuestas metodológicas CBSE con mayor alcance de reuso como Catalysis [11] y Kobra [5], colocan especial énfasis en establecer los principios y patrones que garantizan una derivación consistente de un nivel de arquitectura a otro.

Vistas de la arquitectura. Una vista de la arquitectura permite analizar un aspecto o dimensión de la misma en un nivel específico; cada dimensión de la arquitectura

28 RITOS2

representa un conjunto de elementos del sistema relevantes desde una perspectivas del usuario. Uno de los modelos de arquitectura mas conocidos es el 4+1 View Model definido por Kruchtem [14]. Este modelo describe la arquitectura software utilizando 5 vistas concurrentes, cada una de las cuales esta orientada a un aspecto específico.

La vista lógica soporta los requerimientos funcionales; en esta vista el diseñador descompone el sistema en un conjunto de abstracciones claves derivadas principalmente del dominio del problema. La vista del proceso toma en cuenta requerimientos no funcionales como rendimiento, disponibilidad, distribución, integridad y tolerancia a fallas; esta vista se considera relevante para definir aspectos de calidad de la arquitectura. La vista física describe el mapeo del sistema a la infraestructura de hardware y software mostrando los aspectos de distribución del sistema y considerando requerimientos no funcionales como disponibilidad, tolerancia a fallas, rendimiento y escalabilidad. La vista de implementación describe la estructura de módulos del sistema por capas y su partición en subsistemas que pueden ser implementados por uno o más desarrolladores. La vista de escenarios es una vista integradora que muestra instancias relevantes de requerimientos funcionales estructurados como escenarios.

Estilo de la arquitectura. Una decisión importante al diseñar la arquitectura es definir el (los) estilo (s) adecuados que se va(n) a utilizar. Un estilo de arquitectura permite precisar la semántica asociada a las descripción gráfica o textual de una arquitectura, utilizando un conjunto de elementos arquitecturales y los patrones y reglas necesarias para su utilización; el estilo de arquitectura más utilizado en este tipo de aproximaciones es el estilo por capas (layer) [15] [3]. Este estilo es una metáfora que visualiza el software como una agrupación de componentes distribuidos por niveles, en donde cada nivel representa un mayor o menor alcance de la funcionalidad de los objetos que lo conforman. Es importante entender los principios y reglas asociadas a una arquitectura por capas con el propósito de caracterizar adecuadamente los componentes que serán ubicados en las diversas capas.

2.5.3 Niveles de una Arquitectura por Capas

La calidad del diseño en términos de reusabilidad y portabilidad, se logra en la medida en que se distribuyan de manera adecuada los componentes en las diferentes capas. Aunque las diferentes propuesta CBSE estudiadas varían tanto en número de capas como en el nombre que se le da a cada capa, éstas poseen una semántica similar. Aquí adoptamos la propuesta de capas definida por Ratio [15], la cual se ilustra en la figura 1.

La capa de presentación agrupa los componentes que son responsables de manejar las interacciones entre el mundo externo y las capas inferiores. Típicamente, esta conformada por componentes que ofrecen servicios de interface GUI que sirve de punto de interacción con actores humanos (GUIDebit) o componentes que prestan servicios a sistemas externos (IntercambioDctos). Obsérvese que los servicios de


presentación que ofrece la plataforma de base, conceptualmente corresponden a la capa de plataforma, de la cual hereda el componente gráfico de la aplicación.

La capa de aplicación agrupa los componentes que ofrecen soluciones específicas a una aplicación. En esta capa se implementan los procesos y reglas de negocio asociadas a una aplicación. Esta conformada por componentes que implementan las interfaces de aplicación, cuyo objetivo principal es coordinar la interacción de los objetos de la capa del dominio para satisfacer la funcionalidad que representa un caso de uso. En el ejemplo se observa que el componente ControlDedito puede ser invocado tanto por los servicios gráficos como no gráficos. Este componente, a su vez, establece una relación de uso con el componente de la capa más interna Cuenta. El otro componente que se encuentra en esta capa (AppReglasDébito) surge como una implementación de la interface (o de la clase abstracta) ReglasDebito de la capa interna, con el propósito de customizar las reglas del crédito de acuerdo a las necesidades de la aplicación. La capa del dominio agrupa los componentes de negocio que ofrecen servicios que son utilizados por mas de un componente de la capa de aplicación e incluso, puede ser utilizado por una familia de aplicaciones relacionadas., tal es el caso de los componentes Cliente y Cuenta del ejemplo. Esta capa contiene los componentes que se derivan de los conceptos relevantes del negocio y reciben el nombre de Componentes de Negocio. En el ejemplo se observa además el componente ReglasDebito que establece una lógica general que será extendida por las aplicaciones.

Fig. 1. Ejemplo de una arquitectura por capas. Los componentes de cada capa tienen una estructura de clases con relaciones de uso o de especialización con las clases de las capas

internas.

30 RITOS2

La capa de infraestructura agrupa los componentes de base que ofrecen servicios potencialmente reutilizables en más de un dominio; implementa servicios de tipo técnico como infraestructura de persistencia, infraestructura general de programación, etc. En el ejemplo se observa que el componente de la capa de aplicación hereda los servicios de manejo de transacciones que le ofrece esta capa y que el componentes de la capa de dominio hereda los servicios de persistencia.

La capa de plataforma de software representa la plataforma que ofreces los servicios de base propios del sistema operativo, infraestructura de distribución (CORBA, COM, J2EE, etc.).

2.6 El Papel de UML en el Modelado de Componentes

Aunque se han reconocido algunas limitaciones de UML a la hora de representar de manera precisa los diversos aspectos de una arquitectura, la amplia difusión que ha tenido este lenguaje ha sido capitalizada por las aproximaciones estudiadas para adoptarlo como lenguaje para el modelado de componentes. Se aprovechas tres características importantes de UML: los diferentes permiten soportar el proceso de especificación desde diferentes dimensiones; la flexibilidad de la representación de los diversos elementos permite definir modelos cercanos al espacio del problema o modelos detallados en el espacio de la solución; es fácilmente extensible. A continuación se enfatizan las características relevantes del lenguaje que serán utilizadas en la propuesta metodológica. Referencia completa del lenguaje puede encontrase en [16] y un acercamiento práctico de su uso en [17] [18].

2.6.1 Extendiendo UML

Aunque UML provee varios mecanismo de extensión (estereotipos, valores etiquetados, restricciones), indudablemente el mecanismo más utilizado para extender el lenguaje es por medio de estereotipos. Un estereotipo es una clasificación precisa dada a un elemento de UML (que de manera general se denomina clasificador) con el propósito de asociarle una semántica de interés para un tipo especial de problema. El lenguaje permite además asociarle a un estereotipo un conjunto de restricciones que deben satisfacerse en todos los elementos marcados con dicho estereotipo. Aunque UML distingue entre clase, interface y componente, el significado que se da a estos elementos es un tanto restrictivo para los propósitos que persigue el enfoque CBSE, es por eso necesario precisar dentro de este contexto la semántica de estos conceptos.


Table 1. Conceptos CBSE y sus estereotipos en UML

Concepto CBSE Clasificador UML

Estereotipo Observaciones

Componente de especificación

Clase <<comp spec>>

Forma parte de la vista conceptual de la arquitectura

Tipo de interface

Clase <<interface type>>

Siempre se encuentra asociado a un componente de especificación. Un componente de especificación <<offers>> servicios de un tipo de interface

Interface Clase <<interface>>

Siempre se encuentra asociada un componente (de implementación). Un componente <<realize>> una interface

Tipo Clase <<type>>

Describe los conceptos relevantes del negocio en el “Modelo de tipos del sistema”.

Tipo central Clase <<core>>

Determina los conceptos ó tipos centrales alrededor de los cuales se hará la partición de componentes de negocio

Tipo de dato Tipo de dato <<data type>>

Describr estructuras de datos que caracterizan propiedades de un tipo o representan información de las vistas del usuario.

El componente en UML es definido como “una pieza física de un sistema” [16], lo cual restringe el concepto de componente al nivel de implementación y despliegue. Como ya fue mencionado, el enfoque CBSE concibe el componente como un constructor de primera clase que surge en la fase de especificación para representar un elemento conceptual de vital importancia. Se utilizará entonces la notación de clase de UML para representar el concepto de componente de especificación, con un estereotipos particular que lo diferencia de componente de implementación. La clase, por su parte, representa en UML “un conjunto de objetos con una estructura y comportamiento”; este constructor es generalmente asociado a un módulo o programa en un lenguaje OO. Puesto que el enfoque CBSE destaca la importancia de establecer tipos (como elementos de caracterización de conceptos relevantes de

32 RITOS2

negocio) antes que clases (como módulo de implementación), se utilizará entonces la notación de clase con un estereotipo particular para identificar el concepto de tipo. La interface es otro de los constructores básicos en el enfoque CBSE el cual identifica “un conjunto de operaciones con nombre que caracterizan un comportamiento”; para UML, la interface esta directamente asociada a la declaración de contratos en la vista de implementación del sistema; es por ello, que se establecerá diferencia entre interface y tipo de interface. La primera hará referencia a la declaración de un contrato asociado a un componentes de implementación y la segunda hará referencia a un contrato del componente de especificación. Se utilizará la notación de clase para describir con un estereotipo específico tanto la interface como el tipo interface. La tabla 2.1 resume la manera como se utilizaran los esterotipos para definir los conceptos CBSE de acuerdo a la propuesta de Cheesman [9]. La utilización de los diferentes conceptos se ilustran en el ejemplo que aparece en la sección 4.

3. El Proceso de Desarrollo Basado en Componentes

3.1 Características Generales del Proceso CBSE

Fig. 2. Visión general de los flujos del proceso CBSE


Aunque CBSE se asimila en buena parte a un proceso de Ingeniería de Software clásico, la diversidad de consideraciones que integra (tecnológicas, legales, de gestión, metodológicas) le generan complejidades particulares en el momento de adoptarlo a escala industrial [25]. Esta propuesta se apoya en la visión del proceso dada por RUP (Rational Unified Process) [19] que visualiza el desarrollo de software como un proceso iterativo e incremental centrado en la arquitectura en dos dimensiones: En la dimensión dinámica guía el desarrollo del proyecto en 4 fases a través de iteraciones sucesivas y en la dimensión estática establece los elementos básicos de gestión del proyecto de desarrollo organizados en dos categorías: los flujos básicos que describen las tareas propias de ingeniería y los flujos de apoyo que gestionan el proceso y aseguran su calidad. En la propuesta de CBSE planteada se conservan los flujos de trabajo Modelado del negocio, Requisitos, Pruebas y Despliegue y se definen nuevos flujos de Especificación, Aprovisionamiento, Ensamblado los cuales reemplazan los flujos de Análisis, Diseño e Implementación.

La figura 2 presenta una vista integrada de los flujos de trabajo: El flujo de Requisitos concreta las necesidades del usuario. El flujo de Especificación establece la arquitectura del sistema. El flujo de Aprovisionamiento garantiza que los componentes queden disponibles ya sea por compra, construcción a la medida o adaptación de componentes ya existentes. El flujo de Ensamblaje toma los componentes y los integra para formar los aplicativos. El flujo de Pruebas realiza la verificación de calidad del producto y el Flujo de Disposición realiza el proceso de instalación en la plataforma operativa.

3.3 Flujos de Requisitos y Especificación

Esta sección describe de manera detallada los flujos de requisitos y especificación, los cuales serán ilustrados con un ejemplo en la siguiente sección. Para cada flujo se describen sus actividades, sus artefactos y consideraciones a tener en cuenta en el desarrollo de las actividades

3. 2.1 Flujo de Requisitos Nombre del flujo: Requisitos Objetivo: Entender el problema enmarcado dentro de un dominio y definir las

necesidades del usuario Actividad: R1. Comprender el contexto del sistema Objetivo: Entender el proceso de negocio que se desea soportar analizando la

manera como el sistema software contribuirá a su mejoramiento. Artefacto: Modelo del negocio (diagrama de actividades / nivel requisitos) Consideraciones: El análisis del proceso del negocio y la mejora de los mismos,

forma parte de una tarea compleja denominada Ingeniería de Negocio en la que se

34 RITOS2

requiere la participación activa de los analistas del negocio. Si se trata de un proceso de negocio ya establecido dentro de la compañía puede ser conveniente levantar dos modelos independientes: el modelo del proceso actual y el modelo del proceso mejorado teniendo en cuenta el nuevo sistema. En el modelo del proceso mejorado puede ser conveniente identificar las tareas que son completa responsabilidad del sistema software, agregando un carril que representa el sistema.

Actividad: R2. Definir vocabulario del dominio. Objetivo: Lograr un acuerdo de lenguaje común para el dominio Artefacto: Modelo del dominio (diagrama de clases / nivel negocio Consideraciones: Encontrar conceptos básicos que caracterizan el negocio y

conceptos subordinados sobre los cuales se establecen restricciones relevantes del negocio. Encontrar asociaciones semánticas entre tipos. Producir glosario de términos. Este vocabulario establece un acuerdo en un vocabulario común del dominio que es utilizado por los expertos del dominio. Según Cheesman, en un modelo del dominio se puede incluír loa actores del negocio y sus relaciones de generalización (utilizando el estereotipo <<actor>>)

Actividad: R3. Definir los requisitos del sistema. Objetivo: Determinar las necesidades del usuario Artefacto: Documento de Requisitos del Sistema (DRS) Consideraciones: Realiza las tareas de recolectar y clasificar requisitos, resolver

conflictos, priorizar requisitos y verificar su validez. Esta actividad se realiza de manera cíclica. Las diferentes iteraciones pueden dar lugar a versiones diferentes del documento de requisitos del sistema.

Actividad: R4. Estructurar los requisitos funcionales. Objetivo: Definir el alcance del sistema en términos de casos de uso Artefacto: Modelo de contexto del sistema (diagrama de casos de uso / nivel

requisitos) Consideraciones: Se realizan las tareas de: (1) Encontrar y documentar los

actores y casos de uso (documentación de alto nivel). (2) Priorizar los casos de uso de acuerdo a su relevancia en la arquitectura del sistema. (3) definir contrato del caso de uso. Un caso de uso será relevante a la arquitectura cuando describe un funcionalidad importante (desde el punto de vista del usuario o del arquitecto), o que implique algún requisito importante que debe desarrollarse pronto dentro del ciclo de vida (por ejemplo requisitos con uso intensivo de tecnología que aun no se ha probado). El contrato de los casos de uso (precondiciones, poscondiciones, invariantes se realiza utilizando lenguaje natural. Este contrato será precisado en el flujo de especificación utilizando el vocabulario del tipos de sistema.

Actividad: R5. Analizar requisitos funcionales. Objetivo: Detallar los casos de uso de uso y definir el prototipo de la interface de

usuario asociada Artefacto: Plantilla de definición extendida de casos de uso Consideraciones: Realiza las tareas de describir los flujos de eventos asociados a


los casos de uso (flujos básicos, flujos de excepción, flujos alternos). Estructurar el modelo de casos de uso: Caso de uso base y sus relaciones con otros casos de uso que incluye (<<used>>) o que lo extienden (<<extend>>).. Construir prototipo de la interface de usuario

Nota: Se separan las actividades de definición y refinamiento de casos de uso siguiendo la idea dada en Catalysis: las interacciones representan un “zoom – in” del caso de uso que pueden ser extendidas en el tiempo. Catalysis enfatiza la importancia de describir el contrato del caso de uso de manera independiente a los escenarios que éste represente.

Actividad: R6. Definir requisitos no funcionales. Objetivo: Definir los requisitos no funcionales que deben ser considerados en el

sistema Artefacto: DRS con requisitos nos funcionales Plantilla de definición extendida de casos de uso con requisitos no funcionales Consideraciones: Precisar los requisitos no funcionales en las fases tempranas

permitirá insumos importantes para la especificación de la arquitectura.

3. 2.2 Flujo de Especificación Nombre del flujo: Especificación Objetivo: Encontrar progresivamente la propuesta de solución del sistema en

términos de componentes y relaciones. Subflujo E1: Identificación de componentes. Objetivo: Producir una versión inicial

de la arquitectura Subflujo E2: Interacción de componentes. Objetivo: Asigna responsabilidades a la

interface Subflujo E3: Especificación del componente. Objetivo: Documenta la arquitectura. Nombre del subflujo: E1. Identificación de componentes Objetivo : Crear un conjunto inicial de especificaciones de interface y de

componentes como un primer acercamiento a la arquitectura. Actividad: E1.1. Definir el modelo de tipos del sistema Objetivo: Especificar la información de negocio relevante al sistema Artefacto: Modelo de Tipos del Sistema - MTS (diagrama de clases / nivel

requisitos) Consideraciones: Extraer del modelo del dominio los conceptos que van a ser

utilizados en el sistema, definir las reglas de negocio asociadas a tipos, definir los tipos que representan los conceptos núcleo del negocio (<<core>>). Los atributos deben tener su definición de tipo; las estructuras de datos especiales se definen como <<datatype>>. Los atributos representan piezas de información y las asociaciones representan relaciones entre ellas. Se pueden definir atributos parametrizados.. Los roles de asociación representan consultas sobre colecciones que pueden ser aplicadas

36 RITOS2

al tipo. No visibilidad, no asociaciones cualificadas, no uso de agregación

Actividad: E1.2. Definir interfaces del negocio Objetivo: Particionar los tipos del sistema en unidades manejables Artefacto: MTS con declaración de interfaces de negocio Consideraciones: Definir las interfaces de negocio para los tipos centrales,

representar las interfaces de negocio en el modelo de tipos. Por regla general se crea una interface de negocio por cada tipo central. Cada interface de negocio administra la información representada por el tipo central y los tipos de detalle asociados. Estas interfaces ofrecerán los servicios de administración para un conjunto de instancias del tipo central, por lo tanto se recomienda asociarle el nombre IAdmXXXX. Los tipos centrales aparecen como elementos agregados a la respectiva interface en el modelo de tipos del sistema. Los tipos de detalle se agregan a la interface con la que se encuentre más altamente acoplado. Las asociaciones entre tipos que pertenecen a diferentes interfaces, generan asociaciones Inter. -interface en las cuales se debe decidir cuál de ella será la encargada de manejar la información y quién se encargará de mantener la integridad referencial. Generalmente estas relaciones inter – interface definen relaciones de navegación en un solo sentido.

Actividad: E1.3. Definir interfaces y operaciones del sistema Objetivo: Definir las interfaces que representan la lógica de la aplicación Artefacto: Modelo de operaciones de interfaces del sistema Consideraciones: Definir una interface del sistema por cada caso de uso,

identificar dentro del flujo de eventos las operaciones del sistema, asociar cada operación del caso de uso a la misma interface. Las operaciones de mostrar y seleccionar información serán manejadas por la lógica del diálogo del usuario. La interface toma su nombre del caso de uso antecedido por una I. Si se trata de una caso de uso complejo, con relaciones de inclusión o extensión a casos de uso comunes, es conveniente definir una interface independiente por cada caso de uso común.

Actividad: E1.4. Identificar interfaces y sistemas existentes Objetivo: Encontrar componentes / interfaces externos con los cuales interactúa el

sistema Artefacto: Modelo de interfaces Consideraciones: Se define una interface por cada sistema con el cual se va a

interactuar. Se identifican interfaces de componentes ya construidos con los cuales el sistema debe interactuar. Se identifican interfaces que forman parte de una arquitectura mayor con las cuales se requiere una interface.

Actividad: E1.5. Crear arquitectura inicial de components Objetivo: Proponer una primera distribución de componentes que representan el

sistema Artefacto: Modelo de arquitectura / vista de especificación


Consideraciones: La clave de esta actividad es realizar una distribución adecuada de las interfaces que formarán parte de un componente. Para las interfaces de negocio es conveniente identificar un componente por cada interface. Caso en los que un componente tiene mas de una interface: cuando los conceptos representados por las diferentes interfaces tienen el mismo tiempo de vida o cuando las interacciones entre las interfaces son complicadas, frecuentes e involucran grandes cantidades de datos.

Nombre del subflujo: E2. Interacción de componentes Objetivo : Definir la interacción requerida entre los componentes para satisfacer la

funcionalidad deseada

Actividad: E2.1. Definir las operaciones de negocio Objetivo: Establecer los servicios de las interfaces de negocio requeridas para

satisfacer las operaciones del sistema Artefacto: Modelo de arquitectura. Vista Especificación

Modelo de colaboraciones de interfaces Consideraciones: Para cada operación de las interfaces del sistema se realiza un

diagrama de interacción que definirá los servicios que deben proveer las interfaces de negocio. Se definen tipos de datos estructurados para especificar estructuras de entrada o salida. Se detalla la signatura de la operación del sistema. Se hace una primera declaración de las precondiciones y poscondiciones de la operación. El análisis de interacciones permitirá definir las responsabilidades de cada interface y componente y las dependencias entre ellas. Se deben respetar las reglas de interacción establecidas el estilo de arquitectura.

Actividad: E2.2. Analizar integridad referencial entre interfaces Objetivo: Asegurar que las interfaces correspondientes especifican la

responsabilidad para el manejo de la integridad referencial entre los objetos componentes que las agrupan.

Artefacto: Modelo objetos components Consideraciones: Se debe analizar la manera de asignar responsabilidades a los

objetos componentes con dos propósitos importantes: (1) para garantizar que el objeto componente de negocio utilizado por el objeto componente de aplicación es el mismo (en este caso se utiliza la restricción {congelado}. (2) para asegurar la integridad de referencias entre componentes.

Actividad: E2.3. Refinar interfaces y operaciones Objetivo: Revisar la interacciones definidas y aplicar estrategias que optimicen

dichas interacciones. Artefacto: Modelo de colaboraciones de interfaces refinado. Especificación de la interface con declaración de operaciones Consideraciones: Este refinamiento se realiza teniendo en cuenta los principios

generales de acoplamiento y cohesión entre módulos. Se analiza que el número de invocaciones sea mínimo, que no existan dependencias cíclicas entre componentes y que se apliquen patrones de diseño que permitan optimizar la estructura. Es posible

38 RITOS2

también que las interfaces definidas se particionen para identificar comportamientos más específicos, proceso conocido como factorizar interfaces. Este caso puede presentarse en las interfaces de negocio que ofrecen funcionalidad a diversas aplicaciones. factoricen algunas interfaces.

Actividad: E2.4. Refinar arquitectura Objetivo: Producir un modelo de componentes e interacciones refinado Artefacto: Modelo de la arquitectura refinado / nivel especificación Consideraciones: A partir del refinamiento de las interfaces se producen cambios

en la arquitectura de componentes y sus relaciones de uso y dependencia.

Nombre del subflujo: E3. Especificación de componentes Objetivo : Producir la información que el implementador y el ensamblador de

componentes deben conocer Actividad: E3.1. Definir interfaces ofrecidas y requeridas Objetivo: Generar especificación independiente y autocontenida para cada

componente. Artefacto: Plantilla de especificación de componente Consideraciones: La lista de las interfase que provee y requiere un componente

son obtenidas del modelo de arquitectura refinado. La especificación también puede indicar en número de instancias de objetos componente será utilizados. La plantilla debe ir acompañada del diagrama de interacciones que define la manera como debe ser implementada una operación, esto se convierte en las restricciones de interacción del componente

Actividad: E3.2. Definir el modelo de información de la interface Objetivo: Agrupar a nivel de interface los tipos que utiliza. Artefacto: Modelo de interface con tipos asociados Consideraciones: Este modelo se obtiene como vista consolidada de los tipos que

fueron agregados a una interface. Actividad: E3.3. Definir el contrato de la interface Objetivo: Formalizar el alcance de las operaciones. Artefacto: Plantilla de especificación de componente Consideraciones: Se declaran formalmente las invariantes, precondiciones y

poscondiciones de cada operación asociada a una interface. Actividad: E3.4. Ubicar las reglas del negocio Objetivo: Ubicar las reglas en la respectiva interface de manera formen parte del

software entregable Artefacto: Especificación de la interface con reglas de negocio Consideraciones: Las reglas de negocio pueden ser ubicadas (a) solamente en las

interfaces del sistema, (b) solamente en la interfaces de negocio o (c) en ambas. Si la regla debe ser respetada por todos los sistemas, debe ubicarse en las interfaces de negocio, por el contrario, si la regla es específica par aun uso particular de la


interface de negocio, se ubicará en la interface del sistema. Actividad: E3.3. Factorizar interfaces Objetivo: Generalizar interfaces con modelos de información común Artefacto: Plantilla de especificación de componente Consideraciones: Introducir interfaces abstractas como supertipo de otras

manteniendo los elementos comunes del modelo de información de interfaces.

4. Del desarrollo OO al Desarrollo Basado en Componentes: Un Ejemplo de Aplicación.

El objetivo de esta sección es ilustrar, con apartes del ejemplo sobre reservas en una cadena de hoteles presentado en [9], la aproximación metodológica detallada en la sección anterior. Mas que un seguimiento detallado de cada paso, el ejemplo tratará de ilustrar, cuestionar y reflexionar sobre aquellos puntos donde la propuesta CBSE establece diferencias importantes con el análisis y diseño orientado a objetos tradicional (ADOO). Se asume que el lector esta familiarizado con el proceso análisis y diseño OO tradicional y con los diagramas UML que lo acompañan.

4.1 Definir Modelo de Tipos del Sistema (E1.1)

THotelnombre : String

<<type>>THabitacion

numero : int

<<type>>

*1..1

TClientenombre : Stringz onaP osta l : Direcc ionemail : Str ing

<<type>>

TReservanroRes : intperiodo : RangoFecha

<<type>>1..*

1..1

TTipoHabitacionnombre : intprecio : Moneda

<<type>>

1..1

*

1..1*

1..*

1..1 1..1*

1..1

*

*1..1

Fig. 3. Modelo de tipos del sistema obtenido como un subconjunto del modelo de conceptos del negocio

40 RITOS2

Este es el modelo conceptual que representa el vocabulario relevante del dominio para el sistema. Tiene dos características importantes: abstracción y precision [11]. Aunque no se recomienda describir de manera detallada todas las propiedades del tipo, las propiedades establecidas ya tienen definido su tipo correspondiente. Algunos tipos, como RangoFecha, son estructuras de datos que habrá que seguir refinando. Figura 4.2.

4.2 Definir Interfaces de Negocio (E1.2)

Esta tarea de definir interfaces de negocio, es uno de los pasos fundamentales del enfoque de desarrollo basado en componentes que rompe con el ADOO tradicional: Cada interface de negocio identificada como <<core>> define el núcleo de un módulo independiente que se convertirá en un componente en la capa de lógica de negocio. Para el ejemplo, se han definido las interfaces IClienteAdm que agrupa el tipo cliente e IHotelAdm, que agrupa los tipos restantes. Cada interface representa el núcleo de dos componentes de negocio claramente identificados: Cliente y Hotel. Al particionar los tipos en interfaces independientes, se debe entrar a analizar la manera como se resuelve la relación entre tipos que quedaron agrupados en interfaces independientes; tal es el caso de la relación entre TCliente y TReserva. Resolver la relación significa establecer restricción de navegabilidad que indique cuál de los tipos tendrá conocimiento del otro por medio de su referencia; en este caso, se decide que el tipo TReserva conoce al tipo TCliente.

THabitac ionnumero : int

<<type>>

TReserva

nroRes : intperiodo : RangoFecha

<<type>>TTipoHabitacion

nombre : intprecio : Moneda

<<type>>

*

*

1..11..1

*

1..11..1*

THotelnombre : St ring

<<type>>

*1..1 *1..1

IH ote lAdm<<interface type>>

TCliente

nombre : StringzonaPostal : Direccionemail : String

<<type>>

1..*

1..1

1..*

1..1

IClienteAdm<<interface type>>

Fig. 4. Modelo de tipos con interfaces de negocio


4.3. Definir Interfaces y Operaciones del Sistema.(E1.3)

Bajo la estrategia de “interfaces antes que clases” de la aproximación CBSE, el interés principal en este punto es definir las interfaces del sistema, siguiendo una regla similar del enfoque ADOO: una interface del sistema por cada caso de uso. La interface del sistema tendrá asociada operaciones del sistema que se deducen a partir de los flujos de eventos definidos en el caso de uso, aplicando los mismos criterios que en un desarrollo ADOO tradicional [18]. La única diferencia se presenta en el momento de definir el elemento responsable del sistema que, en este caso, será directamente una interface del sistema responsable de las operaciones del caso de uso. La figura 5 presenta las interfaces correspondientes a dos de los casos de uso del hotel.

4.4 Identificar Interfaces Existentes

Se debe precisar en este momento cuáles de las interfaces existentes va a utilizar el sistema. Para el ejemplo en estudio, se identifica un componentes que representa el sistema de facturación Los casos mas frecuentes que se presentan a la hora de identificar interfaces existentes son: Componentes existentes: Es posible que ya existan componentes que ofrecen lógica de negocio: en este caso, el análisis de interfaces de negocio (Actividad E1.2) debe utilizar las interfaces que ya existen ó debe definir nuevas interfaces para el componente; la alternativa de modificar interfaces existentes es la menos recomendable por el impacto del cambio que esto conlleva. Se debe considerar también el uso o la factorización de interfaces que ofrecen servicios genéricos a ciertas estructuras de datos identificadas (por ejemplo, fechas, monedas, etc). Sistemas externos: Se requiere interactuar con un sistema externo, en este caso la precisión de la interface que será utilizada depende de las características del sistema externo; se recomienda definir una interface en la capa presentación que será la responsable de implementar la conexión al sistema externo, utilizando estrategias como el patrón Proxy. Frameworks existentes. Si el sistema necesita utilizar interfaces que forman parte de una arquitectura mayor, la decisión de qué interfaces implementar, extender o heredar no es trivial: se requiere un análisis detallado de la arquitectura existente (frameworks) que abre una nueva y compleja vertiente metodológica: desarrollo basado en frameworks [13].

42 RITOS2

IH ac e rReserva

obtenerDeta l lesHo te l()obtener In foHa ib tac ion()hace rRes e rva ()

< < interfac e t y p e > >

ITo m a rReserva

obtener In fo R e s e rva ()tom arRe s erva()

< < inte rfac e t y p e > >

Fig. 5. Interfaces del sistema para los casos de uso HacerReserva y TomarReserva

4.5 Crear Arquitectura Inicial de Componentes (E1.5)

Esta actividad hace una primera exploración de la estructura de componentes y su relaciones de dependencia que serán validadas y refinadas en el siguiente subflujo. Nótese (figura 6) que el modelo de arquitectura (establece relaciones preliminares de dependencia entre algunos componentes de lógica del negocio que tiene estructuras comunes. Cuando se trata de sistemas complejos, es posible que esta primera visión de la arquitectura se visualice en términos de paquetes que representan sistemas de componentes y sus relaciones.

4.6 Definir las Operaciones de Negocio (E2.1)

Se utilizan los diagramas de interacción de UML (secuencia o colaboración) para definir de que manera las interfaces del negocio participan para implementar las operaciones declaradas en las interfaces del sistema. La lógica de asignación de responsabilidades a las interfaces, sigue siendo muy similar al utilizado en el proceso ADOO [18] , sólo que en este caso los participantes de la interacción no son objetos instancias de clase sino instancias que representan un interface.

4.7 Analizar Integridad Referencial entre Interfaces (E2.2)

Recordemos que entre los objetos componente que representan la lógica del negocio, existen referencias a estructuras comunes, que por principio de empaquetamiento de los componentes, sólo aparece en uno de ellos. Al definir las interacciones se debe precisar cuál de los objeto componentes será el responsable de preservar la integridad. En el ejemplo que venimos trabajando tenemos que IHotelAdm conoce una referencia de la estructura cliente que pertenece IClienteAdm.

4.8 Refinar Interfaces y Operaciones (E2.3)

En esta actividad se puede resaltar la flexibilidad que posee esta aproximación para factorizar interfaces (reubicar, factorizar o distribuír), en los diversos componentes,


característica que no se posee en el enfoque de ADOO. La interface como una unidad lógica que especifica de manera coherente un conjunto de objetos y el componente como la unidad de empaquetamiento y distribución que agrupa dichos tipos con el propósito de administrarlos.

Fig. 6. Modelo de arquitectura Nivel Especificación

4.9 Refinar la Arquitectura (E2.3)

Se produce una vista refinada del modelo de arquitectura, nivel especificación. Esta es la actividad que cierra el subflujo de Interacción de Componentes; las siguientes actividades producen una especificación de los componentes como unidades relevantes desde el punto de vista del implementador e integrador.

4.10 Especificación de Componentes

Este subflujo es un proceso de consolidación y formalización que permite definir el componente como un elemento software indivisible, que establece un contrato de una granularidad adecuada para actividades posteriores como implementación, instalación y composición. El modelo de información de la interface agrupa los tipos asociados a la interfaz y sobre los cuales se establecerá el contrato definitivamente. Se formaliza el contrato de las operaciones y se especifican las restricciones para las interfaces. La figura 7 presenta un ejemplo del modelo de información para la interface HacerReserva.

44 RITOS2

Fig. 7. Modelo de Información para HacerReserva

5. Revisión de Propuestas Metodológicas

Analizaremos brevemente las características básicas de algunos enfoques para el desarrollo basado en componentes basados en UML [11][6][5] [7] [10][9]. Catalysis es la propuesta pionera en la que se inspiran estas aproximaciones; la mayoría de estos trabajos Kobra [5], Ratio[6], Magma[7], y Castek [8], muestran una trayectoria importante de aplicación a escala industrial. Describiremos a continuación los aspectos que consideramos relevantes.

Niveles y vistas de la arquitectura: Esta propiedad representa una medida cualitativa del alcance de reutilización que persigue la aproximación. Se establece aquí una diferencia entre nivel de la arquitectura y vista de la arquitectura. Mientras que el primero hace referencia al nivel de abstracción que se intenta cubrir, el segundo hace referencia a un aspecto en particular, dentro de un nivel, de relevancia para un usuario (stakeholder) de la arquitectura. Catalysis define una vista de dominio, Magma establece una clara diferencia entre modelos del dominio y modelos del sistema. Kobra elabora más el aspecto de niveles para definir el concepto de arquitecturas estratificas en las cuales el sistema software se percibe como un número de niveles (o estratos) dentro de los cuales los elementos del siguiente nivel refinan los elementos del nivel anterior.


Estilo de arquitectura. Todas las propuestas coinciden en adoptar el estilo por capas como el patrón arquitectural de referencia obligada para establecer principios de claros de interacción entre los componentes. Desde las actividades iniciales, la propuesta de Cheesman establece una clara diferencia entre las interfaces de negocio y las interfaces de la aplicación que darán lugar a los componentes en los diferentes niveles de la arquitectura: Los componentes actividad que agrupa las interfaces del sistema en la capa de lógica de la aplicación y los componentes de negocio que representan la lógica de los objetos de negocio (tipos) en la capa de lógica del negocio.

Alcance de la reutilización. Esta propiedad esta estrechamente relacionada con los niveles de la arquitectura. Como consecuencia natural, las tres aproximaciones mencionadas anteriormente, son las más adecuadas para enfrentar una reutilización de mayor alcance: Mientras que Catalysis da cuenta, en un mismo marco metodológico, de conceptos tan generales como frameworks y paquetes de plantillas, Kobra orienta su enfoque al desarrollo de líneas de productos (Software Product Line) [22] y Magma diferencia las actividades de ingeniería en tres procesos principales: procesos de ingeniería de dominios, procesos de ingeniería de componentes y procesos de ingeniería de aplicación La manera como un enfoque CBSE impacta los diversos flujos de trabajo, depende en buena medida del alcance de la reutilización que se persiga. En propuestas como la de Cheesman [9], por ejemplo, se observa que el flujo de requisitos es muy similar al de un desarrollo tradicional. Propuestas de mayor alcance como la de Kobra[5] pueden impactar notablemente los flujos de requisitos e incluso los de modelado del negocio. Refinamiento y trazabilidad de modelos: Estas propiedades nos permiten visualizar el desarrollo basado en componentes como un proceso iterativo que permite, de manera consistente y ordenada, llevar modelos de un nivel de abstracción a otro con aproximaciones tanto ascendentes (generalizar) como descendentes (refinar). Catalysis en una de las propuesta pioneras que caracteriza las operaciones de refinamiento de los modelos tanto del punto de vista estructural (abstracción de modelos y abstracción de objetos), como desde el punto de vista de comportamiento (abstracción de operaciones y abstracción de acciones). Kobra acompaña el proceso de ingeniería con procesos paralelos de actividades de inspección sistemática que garantizan la calidad de los modelos. Magma apoya el proceso de refinamiento por pasos en modelos de calidad de arquitecturas como SAM y ATAM. Uso de UML. Como ya fue mencionado, todas las propuestas analizadas utilizan UML como lenguaje de partida para especificar los diferentes modelos, el cual extienden haciendo uso de estereotipos. Quizás la propuesta que mas se aparta de la definición básica del lenguaje es Catalysis. El enfoque propuesto por Cheesman es el que presenta con mayores niveles de detalle el uso de UML para acompañar el proceso de desarrollo. Apoyo en lenguajes formales: De las propuestas estudiadas, las que hacen mayor uso de un enfoque formal son Catalysis y Kobra. Catalysis define su propia semántica que

46 RITOS2

guarda equivalencia con el lenguaje OCL; Kobra se apoya en los enfoques de Cleanroom para apoyar su proceso de desarrollo. El esfuerzo de investigación en lenguajes formales que apoyen el desarrollo basado en componentes es alto; prueba de ello es que actualmente se distinguen tres categorías diferentes de lenguajes: Lenguajes de definición de arquitecturas (ADL), que formalizan el aspecto de diseño de alto nivel (23) y lenguajes para definición de interfaces que formalizan la semántica de las interacciones [24]. Sin embargo, desafortunadamente, los esfuerzos de integración de estos lenguajes con lenguajes visuales como UML no avanza con la misma rapidez.

6. Conclusiones y Trabajos Futuros

Se ha presentado una propuesta metodológica para la definición de requisitos y especificación para el desarrollo basado en componentes, utilizando UML. Las características principales de esta aproximación son: Un diseño orientado a interfaces. Las interfase (tipo interface) serán el elemento básico que permitirá capturar los contratos de servicio en las diferentes capas de la arquitectura. En la capa de presentación aparecen las interfaces que ofrecen los servicios de despliegue y captura de datos (<<datatype>>) involucrados en la interacción; en la capa de lógica del sistema se ubican las interfaces que representan el comportamiento visible del caso de uso; en la capa de lógica del negocio se ubican las interfaces que ofrecen los servicios de los objetos del negocio. La propuesta metodológica establece una clara diferencia entre las interfaces del negocio y las interfaces del sistema. Mientras que las primeras se derivan de los servicios genéricos ofrecidos por un objetos de negocio (modelado como tipo central <<core>>), las interfaces del sistema surgen a partir de las operaciones requeridas para un caso de uso. Un diseño basado en contratos: Un contrato permite establecer de manera precisa un acuerdo formal de las afirmaciones y responsabilidades de cada módulo, generando entre ellos relaciones de confianza [21]. La propuesta de Cheesman ubica la definición del contrato en el ultimo flujo de la especificación. Consideramos importante que este concepto se encuentre a lo largo de todo el proceso: desde la definición de los casos de uso se establece utilizando el lenguaje del usuario, en la especificación de interacciones se precisa en términos de instancias creadas, relaciones establecidas, etc. y, finalmente, en la especificación del componente se concreta en el lenguaje IDL seleccionado. Los principios generales de gestión y administración, que acompaña el enfoque tradicional de ADOO, se mantienen en el enfoque basado en componentes que fue presentado. Aunque las técnicas utilizadas son las mismas, las diferencias fundamentales se concentran en los principios de ingeniería que retoman: A través de


ejemplo ilustrado en la sección 4, se presentaron los puntos en los que se diferencian estos dos enfoques, desde el punto de vista de ingeniería. Se percibe que los enfoques de desarrollo se van moviendo desde dos dimensiones: aquellas que parten de los principios concretos y tecnológicos de los componentes, para buscar lenguajes que permiten un mayor nivel de abstracción, que podríamos llamar aproximaciones ascendentes y aquellos que parten de enfoques generales de reutilización sistémica como la ingeniería de dominios y desarrollo de líneas de productos, que ven en la tecnología de componentes el mecanismo ideal para hacer ejecutables sus modelos. Una de las preguntas importantes en este punto es: Cuál de estos dos enfoques es el mas apropiado para adoptar en mi organización? Y la respuesta es igualmente compleja [25]: Las consideraciones incluyen aspectos que van desde el nivel de conocimiento de las tecnologías de componentes existentes, el grado de competencia del equipo de desarrollo, el perfil como industria de software ya sea como proveedor de componentes o como desarrollador de soluciones genéricas o soluciones a la medida y la madurez del proceso de desarrollo que se tenga en la compañía, entre otros. La propuesta metodológica que se presenta en este trabajo es un punto de referencia importante para avanzar en el propósito de proponer enfoques metodológicos de desarrollo basado en componentes de mayor alcance y que también se inspiran en la propuesta pionera de Catalysis. Algunos aspectos que están siendo integrados en la nueva propuesta son: Uso de las colaboraciones como mecanismo para mantener la coherencia entre los modelos que describen la especificación de un componente; estudio de las reglas de refinamiento que justifican el paso de los modelos de un nivel a otro, y de manera especial desde el nivel de especificación en que queda esta propuesta, hasta el nivel de especificación de un modelo de componentes específico, como J2EE; propuesta de un modelo de biblioteca de artefactos que permita integrar los diferentes modelos por niveles y vistas.

7. Bibliografía

1. Mili, Hafedh; Mili, Fatma; Mili, Ali. Reusing Software : Issues and Research Directions. IEEE Transactions on Software Engineering. Junio 1.995

2. Crnkovic. Ivica. Component-base Software Engineering – New Challenges in Software Developmemnt. FocurReviwe, Winner 2001. Disponible en: http://www.idt.mdh.se/kurser/cd5490/2002/. Fecha de acceso: 2003-07-23

3. Jacobson, Ivar; Griss, Martin; Jonsson, Patrik. Software Reuse. Arquitecture, process and Organization for Business Success. Addison Wesley, 1997.

48 RITOS2

4. Bass, Less et.al. Software Architecture in Practice. Addison Wesley. 1998 5. Atkinson Colin, Bayer Joachim, Laitenberger Oliver, Zettel Jorg. Component

Based Software Engineering: The KobrA Approach. Disponible en www.sei.cmu.edu/cbs/cbse2000/papers/index.html. Fecha de acceso: 2003-07-23

6. Matthews, Hubert;, Collins-Cope, Mark. Components in Financial Systems; en www.sei.cmu.edu/cbs/cbse2000/papers/index.html. Fecha de acceso: 2003-07-23

7. Hallsteinsen, Svein, et.al. A Component Oriented Domain Architecture for Fish Farming. Disponible en http://www.sei.cmu.edu/cbs/cbse2000/papers/index.html Fecha de acceso: 2003-07-23

8. Burg, William, et.al. Exploring a Comprehensive CBD Meted: Use of CBD in Practice. Disponible en: http://www.sei.cmu.edu/cbs/cbse2000/papers/03/03.html. Fecha de acceso: 2003-07-23

9. Cheesman John, Daniels John. UML Components. Addison Wesley, 2001. 10.Brown, Alan. Large Scale Component Base Development. Prentice Hall, 2000 11. D’Souza, D., Cameron, A.; Objects, Components and Framework with UML. The

Catalysis Approach. Addison Wesley, 1.998. 12.Szyperski C., Component Software – Beyond Object Oriented Programming.

Addison Wesley, 1998 13. Fayad, Mohamed; Schmidt, Douglas; Ralph E. Johson. Bulding Application

Frameworks. Wiley Computer Publishing, 2000 14.Kruchtem, P. The 4+1 View Model of Architecture. IEE Software. Novembre

1995 (Vol 12, No. 6) 15.Collins-Cope Mark. A Reference Architecture for Component Based

Development. Disponible en: www.ratio.co.uk. Fecha de acceso: 2003-07-23 16.OMG UML. http//www.omg.org/technology/uml. Fecha acceso 2003-07-23 17.Fowler, Martin. UML Gota a Gota. Addison Wesley, 1999 18.Craig, Larman. UML y Patrones. Prentice Hall, 1999 19.Jacobson, Ivar; Booch, Grady; Rumbaugh, James;. El Proceso Unificado de

Desarrollo de Software. Addison Wesley, 1999 20.Heineman, G; Council, W. Component Base Software Engineering. Putting the

Pieces Together. Addisson Wesley. 2001 21.Meyer, Betrand. Construcción de Software Orientado a Objetos. Prentice Hall,

segunda edición, 1999. 22.Weiss, D. et. Al. Software Product Line Engineering: A Family-Based Software

Development Process. Addison Wesley, 1999 23.Nenad Medvidovic, Richard N. Taylor: A Classification and Comparison

Framework for Software Architecture Description Languages. TSE 26(1): 70-93 (2000)

24.C. Canal, L. Fuentes, E. Pimentel, J.M. Troya, A. Vallecillo. Adding Roles to CORBA Objects. IEEE Transactions on Software Engineering 29(3):242-260, Mar. 2003.

25.Sparling Michael. Lessons Learned through six years of Component-base Development. Comunications of the ACM. October 2000, Volume 43, Number 10.


Propuesta de un Modelo Conceptual Difuso*

Angélica Urrutia1 José Galindo2 Mario Piattini3

1Dpto. de Computación e Informática, Universidad Católica del Maule, Chile, [email protected] 2Dpto. Lenguajes y Ciencias de la Computación, Universidad de Málaga, España, [email protected]

3 Escuela Superior de Informática, Universidad de Castilla la Mancha, [email protected]

RESUMEN

En este artículo presentamos algunos resultados de la tesis doctoral “Definición de un modelo conceptual para bases de datos difusas”. En ella se propone una extensión de un modelo EER a un modelo FuzzyEER. En este artículo sólo se presentan algunas de los principales componentes del modelo: atributos imprecisos, grados en diferentes tipos de atributos, entidades difusas, agregación difusa y especialización definidas por grados difusos.

Palabras claves: Bases de datos difusas, modelo conceptual difuso, atributos difusos o imprecisos, grados difusos en entidades y atributos..

1 Introducción

Dentro de la problemática del diseño de bases de datos, los modelos de datos cumplen un importante rol, pues son las herramientas de abstracción que permiten representar la realidad, captando la semántica y restricciones de un sistema de información. Existen en la actualidad modelos conceptuales de datos que definen una semántica y notación, que puede adoptar varios formatos que incluyen texto y gráficos (Batini et al. 1994; De Miguel et al., 1999). Los modelos conceptuales deben ser fáciles de usar para propósitos determinados de un sistema de información que se desea especificar. Rumbaugh et al. (1999) dicen que un propósito fundamental de los modelos es que permiten “captar y enumerar exhaustivamente los requisitos y el dominio de conocimiento, de forma que todos los implicados puedan entenderlos y estar de acuerdo con ellos”. Por otro lado, Elmasri y Navathe (2000) afirman que “un esquema conceptual es una descripción concisa de los requisitos de información de los usuarios, y que contienen descripción detallada de los tipos de entidades, vínculos (interrelaciones) y restricciones; éstas se expresan mediante los conceptos del modelo de datos de alto nivel”. Este trabajo se centra en la representación de requisitos de dominios imprecisos que actualmente no son representados por los modelos existentes. Algunas investigaciones al respecto se encuentran en: Chaudhry

* Este trabajo se enmarca en los proyectos RITOS2 y TIC2002-00480 del “Ministerio de

Ciencia y Tecnología”' (MCYT) español.

et al., 1994; Yazici y Merdan, 1996; Chen G., 1998; Ma et al., 2001, las que discutiremos a continuación.

En Chaudhry et al. (1994) los autores proponen un método para diseñar bases de datos difusas siguiendo el modelo EER. A su propuesta la llaman FRDBS (Fuzzy Relational Data Base System). En dicha metodología, se encuentra un conjunto de pasos para representar imprecisión siguiendo el modelo EER como una extensión, prestando especial interés en convertir bases de datos clásicas (crisp) en difusas. La forma de hacerlo es definiendo n etiquetas lingüísticas para n conjuntos difusos, después cada instancia de una entidad crisp es transformada en un conjunto de instancias difusas, que contienen los grados correspondientes a cada etiqueta asociada al valor crisp. Los autores han trabajado un caso específico, y sobre éste la extensión su modelo, sólo enfocaron aquellos atributos asociado a más de un valor de un atributo difuso en una entidad (atributo multivaluado) y han dejado de lado otros tipos de datos inciertos o imprecisos, las entidades difusas y las interrelaciones.

En Yazici y Merdan, (1996) los autores proponen una extensión del modelo IFO, al tratamiento de datos imprecisos, de forma especia aquellos datos que presenten similitud en una etiqueta. A esta extensión la llaman ExIFO, y exponen mediante ejemplos la implementación y validación de la representación de un esquema conceptual difuso considerando una representación de atributos inciertos. En el modelo agregan tres nuevos constructores, y usando estos constructores es posible representar explícitamente atributos que posean valores inciertos.

Chen, (1998) define que una variable lingüística X está formada por la tupla (T,U,G,M) donde: T es el conjunto de términos lingüísticos de X, U el universo del discurso, G el conjunto de reglas sintácticas que genera el elemento T, y M es el conjunto de reglas semánticas traducidas desde T que corresponden al subconjunto difuso de U. Todo esto para definir un modelo conceptual y su respectiva representación matemática. Por ejemplo, sea X = Edad, T es generado vía G por el conjunto {muy viejo, viejo, edad media, joven, muy joven}, cada término de T es particularmente manejado vía M por conjuntos difusos entre 0 y 1. También establece un tipo de correspondencia entre una entidad y entidad difusa, además del conjunto de valores que obtiene un grado de pertenencia a un conjunto difuso: 1:1, 1:N, N:M, incorporando la difusidad al modelo ER.

Ma et al., (2001) trabajan con los tres niveles de Zvieli y Chen, (1986), introduciendo al modelo entidad interrelación extendido difuso (FEER. Fuzzy Extended Entity-Relationship), una forma de manejar objetos complejos en el mundo real a nivel conceptual, asociando un grado de importancia a un esquema a cada una de las componentes (atributos, entidades, etc.). Además presentan una transformación del esquema FEER (modelo Entidad Interrelación Extendido Fuzzy) a un esquema FOODB (Base de Datos Orientada a Objeto Fuzzy).

En los siguientes apartados se introducen conceptos de lógica difusa y teoría de conjuntos difusos en, atributos difusos y distintos tipos de grados difusos, para luego formular un modelo de datos difusos, al que hemos llamado FuzzyEER (Urrutia, 2003). Dentro de esta extensión, los componentes de modelado de datos que se presentan en este trabajo son: Tipos de atributos difusos (tipo de información que se desea modelar), distintos tipos de grados en un atributo difuso, entidades difusas,

52 RITOS2

interrelaciones difusas, agregación difusa y grados en especializaciones difusas. El artículo finaliza con una tabla comparativa de modelos difusos, conclusiones y referencias bibliográficas. 2 Conceptos de Lógica Difusa

En ocasiones el término “imprecisión” engloba varios significados que es interesante distinguir. Por ejemplo: Puede ser que la información que tenemos sea incompleta o “difusa” (fuzzy, vague), o bien, que no sabemos si es cierta o no “incertidumbre” (uncertainty), o tal vez, desconocemos totalmente la información “ignorancia” (“unknown”) o sabemos que dicha información no es aplicable a determinada entidad “no definido” (“undefined”), o bien, ni siquiera sabemos si el dato en cuestión es aplicable o no al ente tratado “ignorancia total” (“null”) (Umano y Fukami, 1994). Cada uno de estos términos dependerá del contexto en el que se aplique. A veces estos significados no son disyuntivos, sino que pueden unirse en una determinada información.

En este trabajo, para los diferentes tipos de datos que constituyen la definición de dominio difuso consideramos las siguientes definiciones: Datos precisos (crisp, clásicos), para los que se empleará la representación que proporciona el modelo de datos EER (numéricos, alfanuméricos, fecha, etc.) y Datos imprecisos (o difusos), consideramos los datos de naturaleza imprecisa soportados por los modelos difusos de hoy en día pueden ser sintetizados en dos grupos, con distinta representación para cada uno de ellos: sobre referencial (o dominio subyacente) ordenado y sobre referencial discreto no ordenado.

2.1 Conjuntos Difusos

La teoría de conjuntos difusos (también llamada borrosos) parte de la teoría clásica de conjuntos, añadiendo una función de pertenencia al conjunto, definida ésta como un número real entre 0 y 1 (Zadeh, 1965; Pedrycz y Gomide, 1998). Así, se introduce el concepto de conjunto o subconjunto difuso asociado a un determinado valor lingüístico, definido por una palabra, adjetivo o etiqueta lingüística A. Para cada conjunto o subconjunto difuso se define una función de pertenencia o inclusión µA (u), que indica el grado en que la variable u está incluida en el concepto representado por la etiqueta. Un conjunto difuso A sobre un universo de discurso U (dominio ordenado) es un conjunto de pares dado por:

A = {µA (u) /u : u ∈ U, µA (u) ∈ [0,1]} Donde, µ es la llamada función de pertenencia y µA (u) es el grado de pertenencia

del elemento u al conjunto difuso A. Este grado oscila entre los extremos 0 y 1, definido como:

• µA (u) = 0, indica que u no pertenece en absoluto al conjunto difuso A. • µA (u) = 1, indica que u pertenece totalmente al conjunto difuso A.

Por ejemplo si consideramos el valor lingüístico estatura_de_una_persona podría definirse tres subconjuntos difusos, cada uno identificado por una etiqueta {bajo, medio, alto}, y con una función de pertenencia µbajo(u), µmedio(u), µalto(u), respectivamente.


Por otro lado, para dominios con referencial no ordenado tenemos la función de similitud. Esta función define que, para cada dominio D, escalar o numérico, se establece una relación de similitud que sirve para medir la similitud o parecido entre cada dos elementos del dominio (Dubois y Prade, 1998) . Normalmente, los valores de similitud están normalizados en un intervalo [0,1], correspondiendo el 0 al significado “totalmente diferente” y el 1 al significado “totalmente parecido” o iguales. Por tanto, una relación de similitud puede ser vista como una función sr, tal que:

sr : D×D → [0,1] sr(di, dj) l→ [0,1] con di, dj ∈U

Tanto los dominios con referencial ordenado como no ordenado, pueden representar de forma adecuada conceptos de “imprecisión” con la teoría de conjuntos difusos. Es necesario hacer notar que muchos de estos conceptos naturales dependen, en mayor o menor medida, de la persona que los expresa.

2.2 Atributos Difusos

Para modelar atributos difusos consideraremos datos con dominio de referencial ordenado y no ordenado. En un referencial ordenado tenemos las representaciones de: Distribución de posibilidad trapezoidal, Etiquetas lingüísticas, Valores aproximados e Intervalos de posibilidad. En un referencial no ordenado: Escalares simples y Distribución de posibilidad sobre escalares. También son considerados los valores Unknown, Undefined y Null en el sentido explicado en Umano y Fukami, (1994). Por otro lado, los atributos clásicos cuyo dominio sea impreciso pueden ser tratados pero con un formato especial para representar atributos difusos. La clasificación adoptada se basa en criterios de representación y de tratamiento de los datos “imprecisos”: se clasifica según el tipo del dominio subyacente y por si permiten representar la información imprecisa o sólo permiten el tratamiento impreciso de datos sin imprecisión. Los atributos difusos pueden ser de cuatro tipos:

• Tipo 1: Estos son atributos con “datos precisos”, clásicos o crisp (tradicionales, sin imprecisión), que pueden tener etiquetas lingüísticas definidas sobre ellos. Este tipo de atributos reciben una representación igual que los datos precisos, pero admiten que se puedan transformar utilizando condiciones difusas.

• Tipo 2: Son atributos que pueden recoger “datos imprecisos sobre referencial ordenado”. Estos atributos admiten tanto datos crisp como difusos, en forma de distribuciones de posibilidad sobre un dominio subyacente ordenado.

• Tipo 3: Son atributos sobre “datos de domino discreto no ordenado con analogía”. En estos atributos se definen algunas etiquetas (“rubio”, “pelirrojo”, “castaño”...), que son escalares con una relación de similitud (o proximidad) definida sobre ellas, de forma que esta relación indique en qué medida se parecen entre sí cada par de etiquetas.

• Tipo 4: Son atributos propuestos en este trabajo y se definen de la misma forma que los atributos Tipo 3, sin la necesidad de que exista una relación de

54 RITOS2

similitud entre las etiquetas (o valores) del dominio. En este caso importa el grado asociado a cada etiqueta de forma individual, sin evaluar la similitud entre las etiquetas. Por eso, en este caso será en principio más habitual encontrar valores no normalizados. Un ejemplo podría ser el tipo del rol que cumple un cliente en una inmobiliaria, por ejemplo con qué grado (de importancia) un cliente es “demandante” u “ofertante” de un inmueble.

Hay que considerar que, el conjunto difuso de posibles valores que puede tomar

una determinada característica se denomina dominio difuso. 2.3 Grados Difusos

Como hemos visto, la información que se puede modelar en los atributos difusos depende de su dominio, sin embargo, hay varias formas de permitir la información imprecisa o incierta en entidades o interrelaciones difusas. Además, esas formas pueden ser mezcladas para permitir una mayor flexibilidad. Algunas de las más importantes formas de modelar información difusa en las entidades o interrelacionnes son:

• Valores difusos en los atributos: Esto se refiere a que en los atributos de una entidad se pueden contener valores difusos y también operar con ellos. Los tipos de estos valores pueden ser muy variados, tales como: valor nulo, valor desconocido, valor indefinido, distribución de posibilidad, función de similitud, etc., (Galindo, 1999).

• Grado en cada valor de un atributo: Esto implica que cada valor de un atributo puede tener asociado un grado, generalmente en un intervalo [0,1], que mida el nivel de difuminado de dicho valor. El significado de estos grados puede ser variado (Medina et al., 1994).

• Grado en toda la instancia de la entidad: Esto es similar al caso anterior, pero aquí el grado está asociado a toda la instancia de la entidad y no exclusivamente a un valor particular de una instancia. Puede medir el grado con que esa tupla (o instancia) pertenece a esa tabla de la base de datos (Umano y Fukami, 1994).

• Grado en un conjunto de valores de diversos atributos: Este es un caso intermedio entre los casos anteriores. Aquí el grado está asociado a algunos atributos. Este puede ser un caso poco usual pero puede ser a veces muy útil (Galindo, 1999).

El dominio de estos grados se puede encontrar en un intervalo [0,1], pero también

permiten otros valores, como por ejemplo una distribución de posibilidad. Además el significado de esos grados es variado. Dependiendo de este significado el tratamiento de los datos podrá ser diferente. Los posibles significados más importantes de los grados son los siguientes:


• Grado de cumplimiento (satisfacción): Una propiedad puede cumplirse con cierto grado entre dos extremos. La propiedad se cumple totalmente (usualmente grado 1) y la propiedad no se cumple en absoluto (usualmente grado 0). Esto suele emplearse tras establecer alguna condición sobre los valores de una entidad o interrelación (i.e. una selección con una condición difusa) y los grados expresarán en qué medida esa condición ha sido satisfecha (Medina et al., 1994).

• Grado de incertidumbre: El grado de incertidumbre expresa la seguridad con que se conoce un dato determinado. Si se está seguro de la veracidad de dicho grado, éste será 1 y si se está seguro de su falsedad dicho grado será 0. Los valores entre 0 y 1 expresan distintos niveles de incertidumbre, indicando que no se está completamente seguros. Este significado es, en cierta forma, bastante parecido al anterior, pues puede extenderse esa incertidumbre como expresada sobre la pertenencia de una tupla a la tabla de la base de datos para nuestro caso se hablará de la instancia de la entidad (Umano y Fukami, 1994).

• Grado de posibilidad: Mide la posibilidad de la información utilizada. Este significado es similar al anterior, pero se ve este grado como más débil ya que contiene información que es más o menos posible y no más o menos cierta (Mouabdid, 1994).

• Grado de importancia: Distintos objetos (instancias, atributos ...) pueden tener diferente importancia, de forma que existan objetos más importantes que otros (Mouabdid, 1994).

Al definir los conjuntos difusos se habla de un grado de pertenencia a un

conjunto difuso, el cual se añade a los presentados aquí. Tanto el grado de cumplimiento, incertidumbre, posibilidad, importancia y pertenencia han sido estudiado por diversos autores (Dubois y Prade, 1998; Petry, 1996; Medina, 1994...). En este trabajo no pretendemos demostrar la utilidad de dichos grados y de sus distintos significados, ya que de eso se han encargado diversos autores que han usado esos grados con distintos significados. Nuestro objetivo es capturar esa necesidad para representarla en un modelo conceptual basado en el modelo EER, lo cual lo hacemos en la siguiente sección.

3 Atributos Difusos en el Modelo FuzzyEER

En los apartados 2.2 y 2.3, se definieron varias formas de permitir la información imprecisa en entidades o interrelaciones difusas. A continuación, para cada uno de estos casos se propone su representación o notación gráfica, junto con algunos ejemplos en el modelo conceptual FuzzyEER.

3.1 Valores Difusos en los Atributos

Los valores difusos en los atributos hacen referencia a los distintos tipos de atributos de una entidad, que pueden modelar valores difusos (imprecisos), al igual que en el

56 RITOS2

tercer nivel de Zviely y Chen (1986) pero de una forma más clara, son aquí definidos y clasificados según el tipo de referencial (ordenado o no) que tengan asociado. El tipo de valor para cada atributo puede ser muy variado, algunos de los más conocidos son: valor nulo, valor desconocido, valor indefinido, distribución de posibilidad, etc.

Los atributos clásicos no incluyen atributos cuyo dominio sea impreciso, considerándose que pueden ser tratados, pero con un formato especial, para representar atributos imprecisos (difusos). En el punto 2.2 se clasificaron los atributos difusos en cuatro tipos: Tipo 1 para datos precisos que admiten tratamiento difuso, Tipo 2 para datos imprecisos en dominio de referencial ordenado, Tipo 3 para datos imprecisos con dominio de referencial no ordenado asociados a una relación de similitud y Tipo 4 que son semejante al Tipo 3 pero no asocian una relación de similitud.

La representación gráfica de los atributos el modelo EER se realiza mediante un círculo etiquetado y unido mediante un arco a la entidad a la pertenece (De Miguel et al., 1999). Estos autores proponen notación para varios tipos de atributos, por ejemplo, atributo identificador o clave denotado por un círculo relleno (negro), atributo simple denotado por un círculo normal, atributo compuesto denotado por un arco con un círculo normal que cruza todo los atributos que compone, todos ellos unidos al tipo de entidad o interrelación a la que pertenecen. Definición 1: Sea un tipo de entidad E con atributos A1, A2, ... , An y sea D1, D2, ... , Dm conjuntos finitos de los dominios respectivos para cada Ai con i =1,..., n. Un atributo difuso es aquel que tienen un dominio impreciso (difuso) asociado al tipo de entidad E. Se representa gráficamente con un círculo normal para T1 y un círculo estrellado para T2, T3 y T4, con una línea que lo une a la entidad. Dicho de otra forma, en el caso de atributos clásicos se utiliza un círculo normal, y aquellos que admiten valores difusos se representan con un círculo estrellado, Además, al nombre del atributo se le debe anteponer el tipo de atributo que representa sea este T1, T2, T3 o T4. Opcionalmente, se puede incorporar junto al nombre del atributo las etiquetas lingüísticas que están definidas para ese atributo.

* En la Figura 1 se muestra un esquema para representar los cuatro tipos de atributos

difusos que consideramos en esta definición. Respecto a esos cuatro tipos de atributos difusos que aquí consideramos, hacemos

las siguientes aclaraciones: Tipo 1: Dj es el dominio es un atributo atómico y cada valor de Dj es crisp o Aj es un atributo clásico. Sin embargo, lo denominamos como atributo difuso porque este tipo de atributo admite que sobre él puedan efectuarse consultas difusas, y como en esas consultas difusas pueden utilizarse etiquetas lingüísticas, valores aproximados... entonces, es necesario que esos conceptos estén definidos previamente. Tipo 2: Dj es el dominio de conjuntos difusos definidos por una distribución de posibilidad µ que exprese un concepto difuso X. A cada uno de los valores de Dj, se le asocia un valor en un intervalo [0,1], representando el grado de pertenencia al conjunto, o la posibilidad de que ese valor sea cierto en la instancia al cual está asociado:

µX (d), con d ∈ Uj (1)


donde Uj es el dominio subyacente de Dj, es decir, el conjunto de valores crisp de dicho dominio. Tipo 3: Dj es el dominio de conjuntos difusos o distribuciones de posibilidad definidas sobre un conjunto de términos, escalares o etiquetas lingüísticas, que no tienen asociada una distribución de posibilidad. Estas etiquetas se definen en un dominio no ordenado y sobre estas etiquetas se define una relación de similitud que permite medir el parecido existente entre cada par de etiquetas del dominio. La representación son distribuciones de posibilidad similares a la Ecuación 1, pero ahora el dominio Uj es el conjunto de etiquetas lingüísticas definidas, a las cuales la función µ le asocia un valor en el intervalo [0,1]. Tipo 4: Dj es un dominio similar al anterior pero en el que no existe una relación de similitud entre cada par de etiquetas del dominio.

También se puede utilizar la clasificación de los atributos definidos en el modelo EER, como atributo: Simple, compuesto, derivado, múltiple, etc. (por ejemplo para el atributo difuso Tipo 2, como lo muestra la Figura 1). Los atributos difusos que definen estas características y conserva la notación de las definidas por los autores De Miguel et al. (1999), incorporando la propuesta del modelo FuzzyEER. Entendiéndose por atributo difuso derivado aquellos que se obtienen a partir de otros ya existentes (estos pueden o no ser atributos difusos) y d es la regla de derivación documentada en el diccionario de datos. Un atributo difuso simple es aquel que toma un sólo valor en un dominio difuso en una entidad. Los atributos difusos múltiples (o multivaluado) toman más de un valor en un dominio difuso en una entidad definiéndose en su representación el número mínimo y máximo de valores, para el caso opcional el valor mínimo será 0 y este atributo puede no tomar valores y en el caso de obligatorio (mínimo) vale 1 y el atributo debe por lo menos tomar un valor en un dominio difuso. Definición 2: Los atributos difusos simple, compuesto, derivado, múltivaluado y compuestos conservan la misma definición y representación gráfica cuando son difusos, esto es, que sólo hay que distinguir qué tipo de atributo difuso representa (T1, T2, T3, o T4) colocado delante del nombre del atributo y cambiar el círculo a estrellado (excepto para T1).

*

Figura 1: Representación gráfica en FuzzyEER para: a) Tipo 1, b) atributo difuso Tipo n, con n=2, 3 y 4, c) atributo difuso simple, d) atributo difuso derivado, e) atributo difuso

múltiple opcional y f) atributo difuso múltiple. .

Tn:

(0,m)Tn:

nombre:{opcional} Tn:d

Tn:(1,m)

nombre:{opcional}

nombre:{opcional}

nombre:{opcional}

Tn: nombre:{opcional}T1:nombrea)

e)

c)

f)

d)

b)

58 RITOS2

Ejemplo 1: En una compañía de teatro se puede considerar una entidad EMPLEADO para representar los actores de la compañía. En esta entidad se pueden considerar de forma simplificada los siguientes atributos: {DNI,Altura,Edad,Color_pelo, Color_piel}. Algunos de estos atributos pueden estar caracterizados como atributos imprecisos. Veamos en detalle la definición de los atributos: Atributo Clásico = DNI: Su dominio corresponderá a valores numéricos, siendo este atributo definido como clave primaria para la entidad Empleado. Atributo Tipo 1 = Altura: Su dominio puede ser definido como el conjunto de valores entre {0,..., 2.50}, identificado como un atributo preciso, pero se le pueden asociar etiquetas lingüísticas, como por ejemplo, (“bajo”, “mediano”, “alto”), siendo esto documentado en un diccionario de datos. En este caso se supone que sí se conoce la altura de un empleado, se dice que, se conoce el valor de ese dato en forma precisa (exacta). Nótese que este atributo difuso podría ser de Tipo 2. Atributo Tipo 2 = Edad: Su dominio corresponderá a un conjunto difuso sobre las edades consideradas como valores numéricos (referencial ordenado), permitiendo representar las etiquetas lingüísticas “joven”, “maduro” y “mayor”, definidas como distribuciones de posibilidad. En la Figura 2 pueden verse todas las etiquetas que considera este atributo difuso, los valores que cada una toma, y el grado de pertenencia asociado a cada valor en cada etiqueta. Obsérvese por ejemplo que la edad 26, tiene un grado de pertenencia 0.8 para la etiqueta “joven”, que es un trapecio dado por sus cuatro valores característicos {0/15, 1/20, 1/25, 0/30}.

Figura 2: Distribuciones de posibilidad para las etiquetas lingüísticas del atributo difuso T2:Edad.

Atributo Tipo 3 = Color_pelo: Su dominio subyacente corresponderá al conjunto: {“rubio”, “moreno”, “pelirrojo”}, a cada una de estas etiquetas se debe asociar un valor de semejanza o similitud según corresponda en un intervalo [0,1]. Observe que los valores de ese dominio no están ordenados, disponen de una relación de orden. Su función de similitud asociada está representada en la Tabla 1. El dominio real son valores simples de ese referencial (por ejemplo 1/Rubio) o una distribución de posibilidad sobre el mismo (por ejemplo {1/Rubio, 0.6/Pelirrojo}).

grado de pertenencia

0

1

0.8

25 2617 30 40 45 65edad

joven maduro mayor

20

Q (x)


Rubio Moreno Pelirrojo Rubio 1 0.1 0.8 Moreno 0.1 1 0.3 Pelirrojo 0.8 0.3 1

Tabla 1: Función de similitud para atributo difuso T3:Color_pelo.

Atributo Tipo 4 = Color_piel: Su dominio corresponderá a añadir un único grado a una o varias etiquetas del dominio subyacente: {“blanca”, “amarilla”, “café”, “negra”}. Por ejemplo, un valor válido es {0.8/blanca, 0.6/amarilla, 0.4/café, 0.1/negra}. A diferencia del caso anterior, en este atributo difuso no existe una tabla de similitud, sino que grados que se definen por cada atributo difuso en un intervalo [0,1].

La Figura 3, presenta la entidad EMPLEADO con la notación del modelo FuzzyEER, que define atributos difusos Tipo 1, Tipo 2, Tipo 3 y Tipo 4, correspondiendo al Ejemplo 1. Dicha entidad puede ser de mucha utilidad si los empleados pertenecen a una compañía de teatro, estamos hablando de actores, en particular cuando se requiere de algunos rasgos especiales al representar alguna escena donde el actor debe cumplir con algunas características físicas del personaje.

Figura 3: Entidad EMPLEADO con atributos difusos Tipo 1, Tipo 2, Tipo 3 y Tipo 4.

La representación de los datos que se desea modelar en un sistema de información, considerando que estos tengan datos precisos o imprecisos, fue discutida en este apartado, pero se debe considerar que un grado puede tener distintos significados, a su vez, este tipo de grado requiere modelar uno o varios grados, según sea el significado de este grado en un esquema de datos dado, esto se discutirá en el siguiente apartado. 3.2 Grado en Cada Valor de un Atributo

En este caso, el valor de cada atributo puede tener asociado un grado, generalmente en un intervalo [0,1], que mida el nivel de difuminado de dicho valor. Los significados de estos grados pueden ser variados, como por ejemplo: de cumplimiento, de incertidumbre, de posibilidad, etc.

Para mostrar la utilidad de los significados de grados en atributos difusos, se hace referencia a trabajos de algunos autores que han utilizado este concepto (Galindo, 1999; Ma et al., 2001; Medina et al., 1994). Cabe destacar que para cada uno de los

T2: Edad {joven, maduro, mayor}

T3: Color pelo {rubio, moreno, pelirrojo}

T4: Color_piel {blanca, amarilla, cafe, negra}

EMPLEADOT1: Altura

DNI

60 RITOS2

grados, si toma el valor 1 representa la máxima expresión del grado, y si toma el valor 0 lo contrario.

El dominio de los grados suele estar delimitado al intervalo unidad [0,1]. También pueden considerarse etiquetas (como “mucho”, “normal”,...) definidos como conjuntos difusos sobre el intervalo [0,1], pero esto no aporta grandes ventajas y sí más complejidad técnica y semántica, por lo que no consideramos este tipo de grados. Nuestro interés se centra en representar algunos grados difusos definidos en el punto 2.3, en este caso: grado de cumplimiento, grado de incertidumbre, grado de posibilidad, grado de importancia y grado de pertenencia. A continuación para cada uno de ellos se define su correspondiente notación gráfica de la siguiente forma: Definición 3: Se define grado difuso asociado a un atributo con cierto significado. Este significado se expresa con la notación Gn o Gsignificado, donde “n” o su significado es uno de los que se definen a continuación u otros nuevos. Esa expresión se ubica delante del nombre de un atributo que define el grado unido por una flecha al atributo del que se le asocia. Véase Figura 4.

Sea una entidad E con atributos (A1, A2, ...,An), para cada atributo Ai con i∈{1,..., n}, puede existir un grado difuso asociado a cada valor que dicho atributo toma en cada instancia de E. El significado de ese grado se define a continuación:

• Grado de pertenencia: La pertenencia de un valor a una instancia concreta

puede ser cuantificada por un grado. Se representa con G0 o GPertenencia. • Grado de cumplimiento (satisfacción): En una instancia, una propiedad

puede cumplirse con cierto grado entre dos extremos. Se representa con G1 o GCumplimiento.

• Grado de incertidumbre: El grado de incertidumbre expresa la certeza o seguridad con que conocemos un dato determinado para una instancia concreta. Se representa con G2 o GIncertidumbre.

• Grado de posibilidad. Mide la posibilidad de la información que se está modelando para cada instancia de la entidad. Se representa con G3 o GPosibilidad.

• Grado de importancia: Distintos valores de un atributo pueden tener diferentes importancias, de forma que existan ciertos valores de cierto atributo más importantes que otros. Se representa con G4 o GImportancia..

* Obsérvese que la notación de este tipo de atributo difuso que contiene algún tipo de

grado que representa, deberá considerar dos formas: 1. Si tiene una función Q(x) que define el cálculo de un atributo, este será un

grado difuso derivado. Con esa función se obtiene el grado respectivo. O sea, la función permite calcular esos grados de forma automática basándose en el valor de otros atributos o en cualquier otra información almacenada o disponible en la base de datos. Esa función puede ser, por ejemplo, una distribución de posibilidad de una etiqueta lingüística.

2. Si no tiene definida una función es un atributo difuso simple que sólo debe llevar el nombre del atributo que contiene el grado difuso.


Aunque estos dos casos son producto de un cálculo para obtener el respectivo valor del atributo, el caso 1 es más complejo que el caso 2, ya que este último trata de un valor que se calcula de forma no automática.

La Figura 4, muestra un ejemplo del caso 1 para una notación gráfica en FuzzyEER de grado en un atributo. Considérese, que el atributo difuso generalmente es diferente al grado que representa. Por ejemplo, decir que el valor del color del pelo tiene una importancia (o un grado de cumplimiento de cierta propiedad), no implica que este grado sea porque es un atributo Tipo 3, sino que representa un grado de importancia de todo el valor que tome el color del pelo (aparte, insistimos que ese atributo puede tener un valor difuso). Por tanto, cada grado debe estar asociado a un atributo cuyo nombre se sitúa tras Gn. Puede considerarse como un atributo doble, ya que tiene dos valores relacionados (el valor del atributo, sea o no difuso, y el grado asociado al mismo). Ejemplo 2: Para un atributo difuso T2:Edad con etiquetas de la Figura 2 {joven, maduro, mayor}, definidas en un referencial ordenado perteneciente a una entidad PERSONA. Se puede definir un conjunto difuso considerando la etiqueta lingüística “joven” con distribución de posibilidad dada por un trapecio con: {α, β, δ, γ} correspondiente a: {0, 20, 25, 30}. Algunos de los significados de grados de atributos difusos que pueden definirse en este ejemplo son:

a) Persona con x edad pertenece al conjunto de personas jóvenes con Q(x), donde la función Q, es la función de pertenencia G0 del conjunto difuso “joven”.

b) Persona con posibilidad G3 de que tenga entre 21 y 24 de edad es Q(x). c) Para cada persona, la edad puede ser más o menos importante G4 según su

cargo.

Para éste caso el atributo difuso T2:Edad tiene una función de distribución asociada Q(x), por tanto es un atributo difuso derivado que representa algún grado. El esquema de la entidad PERSONA asociado al caso a) está representado en la Figura 4.

Figura 4: Representación en modelo FuzzyEER de significado de grado G0 y G3 para el atributo T2:Edad.

En caso de que no sea definido el significado como 0, 1, 2, 3, ó 4, el atributo

representará por omisión el grado de pertenencia G0.

PERSONA

DNI

Q(X) G0 Edad

T2: Edad {infantil, ..., mayor}

62 RITOS2

3.3 Grado Asociado a los Valores de Diversos Atributos

Para este caso, se crea un atributo cuyo valor es un grado. Este grado está asociado a un conjunto de atributos pertenecientes a la entidad, siendo un caso poco usual pero puede dar expresividad si se incorpora a un modelo de datos, un ejemplo de este atributo se encuentra en el concepto de dependencia difusa planteada por Raju y Majumdar (1988).

Definición 4: Sea una entidad E con atributos (A1, A2, ...,An), para un subconjunto X de atributos Ai con i∈I, siendo I un conjunto de índices tal que I⊂{1,..., n}, puede existir un grado difuso asociado a cada valor que los atributos de X toman en cada instancia de E. A este grado se le denomina Grado asociado a los valores de diversos atributos, y puede tener diversos significados. En un modelo FuzzyEER este tipo de atributo es representado como un atributo difuso (derivado o no), unido por una línea que atraviesa los atributos de X (los que están asociados a este grado) y junto a la línea, una punta dirigida al nuevo atributo difuso. En general, el grado del atributo será derivado de esos atributos. Véase Figura 5.

* Ejemplo 3: Supongamos los atributos {DNI,Oficio,Experiencia, Habilidad} de una entidad Empleados. Para este caso se considera, que el dominio del atributo Oficio es clásico u ordinario (alfabético), y los dominios de los atributos Experiencia y Habilidad son conjuntos difusos con etiquetas {aprendiz, normal, experto} para experiencia y las etiquetas {torpe, normal, hábil} para la habilidad.

A partir de estos dos atributos podemos añadir un grado al grupo de atributos {experiencia, habilidad}. El significado de este “grado de experticia” que se obtiene del conjunto {experiencia, habilidad} puede variar dependiendo del contexto. Por ejemplo, se puede dar: • Grado de incertidumbre G2: Representa en qué medida los valores de los atributos

{Experiencia, Habilidad} son ciertos, dependiendo de cómo se hayan calculado esos dos valores (si se ha basado en muchas pruebas o en pocas...). Véase G2 de la Figura 5, donde “d” representa la fórmula de cálculo de derivación del atributo difuso.

• Grado de importancia G4: Para un empleado esos atributos pueden ser más importantes que otros. Por ejemplo un cirujano requiere más experiencia y habilidad que un auxiliar administrativo.

Figura 5: Gráfica de atributos para grado de conjunto de valores con grado G2.

d

T2:

T3:

EMPLEADO

Oficio

DNIExperiencia:{aprendiz, normal, experto}

Habilidad:{torpe, normal, hábil}

G2 {experiencia, habilidad}


Otro ejemplo del uso de este tipo de caso es que de dicha entidad se puede obtener

un grado de “interés por la perfección”. 3.4 Grado Difuso con Significado Propio

Otra forma de analizar los grados es considerar el caso que un determinado grado no tiene porqué estar asociado a otro atributo, sino que puede ser difuso y tener valor (o significado) por sí mismo, en otras palabras, se tienen dos formas de grados en atributos difusos: grado asociado a un atributo (que mide algo difuso de cierto atributo) o grado sin asociar a ningún atributo (que tiene información difusa con sentido por sí mismo). Ejemplo 4: En una entidad MEDICAMENTO, puede tener diversos atributos (Nombre, Tipo, Compuesto_1, Compuesto_2, Peligrosidad, Color), analicemos el color y la peligrosidad, considerados como grado de atributos difusos que toma valores en un intervalo [0.1] con las siguientes características:

• Color puede ser un atributo difuso con un grado asociado a cada valor que mide en qué medida ese color es “intenso”.

• Peligrosidad medirá cuánto de peligroso es dicha sustancia.

O sea que, un Grado_color es un grado difuso que mide alguna característica difusa de un atributo, mientras que la peligrosidad es un grado difuso que mide alguna característica difusa de la instancia. Nótese qué ambos atributos difusos no representan el mismo concepto de grado, tal vez dependiendo del caso habría que especificar una notación distinta en el modelo FuzzyEER.

5 Agregación Difusa

De Miguel et al. (1999) dicen que una agregación permite representar tipos de entidades compuestas que se obtienen por la unión de otras más simples. Al tipo compuesto se refiere como el todo, mientras que los componentes son las partes. Estos autores consideran dos tipos de agregación: compuesto/componente y miembro/colección. Para la agregación difusa que se quiere representar aquí, se utiliza la primera de ellas, la cual es definida como una abstracción que permite representar que un todo se obtiene por la unión de diversas partes que pueden ser tipos de objetos distintos y que desempeñan diferentes roles en la agregación. La representación gráfica de la agregación de compuesto/componente, es un rombo junto a la entidad que forma el todo, y con líneas que unen las distintas entidades que forman las partes. Por otro lado, en Batini et al., (1994) se considera la agregación de los atributos a una entidad, su representación grafica son rectángulo para la entidad y los atributos, donde estos últimos se unen a la entidad con una línea con punta.

64 RITOS2

Definición 5: Se define una agregación difusa de dos formas: 1. Agregación de tipos de entidades, que permite representar que un todo se obtiene

por la unión de las diversas partes que pueden ser tipos de objetos distintos, que pertenecen al todo con un cierto grado y que desempeñan diferentes roles en la agregación. Siguiendo la notación de De Miguel et al. (1999), la representación grafica de la agregación difusa de entidades es un rombo, que aquí escribimos con línea discontinua, unido a la entidad que forma el todo, y con líneas discontinuas se unen a las distintas entidades que forman las partes. Junto a dichas líneas se define el grado que la asocia a la agregación y su significado. Véase Figura 6..

2. Agregación de atributos, que permite representar una entidad y un conjunto de atributos que representan sus partes componentes. Siguiendo la notación de que hemos propuesto en la Definición 1, la representación gráfica de la agregación difusa de atributos es un círculo con línea discontinua, junta a esté, el grado que el atributo tiene para la entidad..Véase Figura 6.

*

La representación de agregación de entidad clásica incluye la notación (min,max), pues en la representación de la agregación de entidad difusa, esta puede ser incorporada en el mismo sentido como fue explicada en Galindo et al., (2001), sólo habría que incluir junto a la línea discontinua la notación (Qmin,Qmax).

Considérese que en la Definición 5, no son excluyentes la agregación clásica y la agregación difusa, ya que normalmente algunas de las entidades de la agregación compuesto/componente pueden representar ambas características. Lo mismo ocurre en la agregación de atributos, por lo general, sólo algunos atributos serán de agregación difusa a la entidad.

Ejemplo 5: Un Coche es la unión de diversos componentes, por ejemplo Chasis, interior y radio. También, Coche se compone de la agregación de atributos {identificación, color, año}. Consideraremos que Radio tiene un grado de importancia 0.5, interior un grado de importancia 0.8 para Coche, la Figura 6 muestra la gráfica de este caso. Por otro lado tendremos que, identificación tiene un grado de importancia 1, color un grado de importancia 0.6 y año un grado de importancia 0.8 para un coche, la Figura 6 muestra su representación.

Nótese que el ejemplo representado por la Figura 6 es también tratado por Ma et al.

(2001), a nuestra opinión, la notación propuesta en el modelo FuzzyEER es más representativa que la de este autor. También, el tipo de ejemplo de la Figura 6 es tratado en Chen G. (1998), pero este autor no usa el concepto agregación, sino que sólo como atributos que componen la entidad. La notación del modelo FuzzyEER queda más representativa de este modo.


Figura 6: Ejemplo de agregaciones difusas: a) agregación de entidades, b) y c) agregación de atributos de las dos formas posibles.

6 Entidades e Interrelaciones Difusas en FuzzyEER

En el apartado 3 se definen algunos tipos de datos difusos que serán utilizados aquí para formalizar algunos conceptos, notaciones y ejemplos de una entidad difusa; ya sea esta regular (tratada como grado en toda la instancia de la relación) o débil (dependencia de existencia o dependencia de identificación). Para el caso de las interrelaciones difusas se definen si tienen un atributo difuso que vincula las entidades que asocia.

6.1 Entidad Difusa (Grado de Toda la Instancia de la Entidad)

Como sabemos, una entidad es un objeto real o abstracto acerca del cual se quiere almacenar información en la base de datos, y se denomina a la estructura genérica tipo de entidad. Por otra parte, una instancia (ocurrencia) de la entidad es cada una de las realizaciones concretas (objetos o valores) de ese tipo de entidad. La representación gráfica de los tipos de entidades es un rectángulo etiquetado con el nombre del tipo de entidad que representa (Elmasri y Navathe, 2002; De Miguel et al., 1999).

En el modelo FuzzyEER una entidad difusa consiste en generar tipos de entidades difusas, de forma que cada instancia del tipo de entidad tenga un grado para medir la relación de esa instancia con su tipo de entidad (su grado de pertenencia a ese tipo de entidad, o su grado de importancia dentro de ese tipo, su grado de certeza...). El grado difuso puede ser calculado por el sistema en forma opcional, si el usuario no introduce el valor de los grados.

Coche

Chasis Interior Radio

G4=0.8 G4=0.5

Identificador G4 =1Color G4 = 0.6

Año G4 =0.8

Dueño G4 =0.7

66 RITOS2

Definición 6: Se define tipo de entidad difusa en un modelo FuzzyEER, como una entidad a la que se le añade un atributo que expresa un grado (con cualquier significado) definida como:

Sea E una entidad, con n instancias, e1, e2, …, en se define E como entidad difusa si ∃ una función µE definida sobre dichas instancias tal que ∀ ei ∈ E ,

µE (ei) ∈ [0,1] con i= 1,2,...,n (2)

La expresión µE (ei) puede medir el grado con que la instancia ei “pertenece” a E,

aunque puede tener otros significados, como los expresados en la Definición 3. La notación de un tipo de entidad difusa es representada con un rectángulo de líneas discontinuas. También se debe añadir el atributo difuso, con el significado del grado que represente, señalado con un círculo con línea discontinua. Véase Figura 7.

* Esto es similar a los casos anteriores, pero aquí el grado está asociado a toda la

instancia de cierto tipo de entidad y no exclusivamente a un valor particular de un atributo de una instancia. Por lo general, indicando el grado de pertenencia G0 u otro tipo de grado que se desea representar. Este caso consiste en generar tipos de entidades difusas, de forma que cada instancia del tipo de entidad tenga un grado para medir la relación de esa instancia con su tipo de entidad (su grado de pertenencia a ese tipo de entidad, o su grado de importancia dentro de ese tipo, su grado de certeza...).

Como extensión a la anterior definición podemos admitir que una entidad tenga varios grados asociados a la misma. El concepto semántico se complica, pero no tendría sentido limitar cada entidad a un único grado posible. Incluso, podrían establecerse restricciones entre ambos grados (por ejemplo, la importancia de cada empleado en su departamento debe ser superior a su grado de capacitación para cierta tarea).

Ejemplo 6: Se puede considerar una entidad difusa EMPLEADO, para la cual se define correspondiente el total de horas trabajadas que asignaría cierto grado de pertenencia a la entidad para cada empleado. Los empleados, que trabajan una cierta cantidad de horas distinta para cada uno, pertenecerán al tipo de entidad empleado con un cierto grado. Ese grado será calculado dividiendo el número total de horas trabajadas por el número mínimo de horas para que la pertenencia sea total. A partir de ese número mínimo de horas el grado de pertenencia será siempre 1. Se genera así, un atributo difuso derivado para obtener el grado de pertenencia. La Figura 7 representa un esquema que modela este ejemplo, donde Q(h) es el cálculo del grado, definido por: min{1, nº horas trabajadas/ nº mínimo de horas para la pertenencia total}. Así se tiene que, si h es el número de horas semanales trabajadas por cierto empleado y 35 es el número mínimo de horas para ser considerado empleado totalmente (con grado 1), entonces se obtiene que el grado de pertenencia para dicho empleado viene dado por la expresión Q(h) mín (1, h/35). Así, un empleado que trabaje en la empresa


15 horas, será considerado como un empleado con grado 0.43, de forma que este grado pueda tenerse en cuenta en diversos cálculos (selecciones para distintos fines, gratificaciones...).

Figura 7: Entidad difusa con grado de pertenencia de número de horas trabajadas.

6.2 Entidades Débiles Difusas en FuzzyEER

Existen dos clases de entidades, las regulares, que son aquellas que tienen existencia en la base de datos por sí mismas y las débiles, cuya existencia depende de una entidad regular por una interrelación de dependencia de identificación o una interrelación de dependencia de existencia. La representación gráfica de los tipos de entidades débiles son dos rectángulos concéntricos con su nombre en el interior conectadas a un tipo de interrelación marcada con una E (Existencia) o una ID (Identificación) definido en De Miguel et al. (1999).

También, en un modelo EER, por lo general, ante la existencia de un atributo multivaluado en una entidad regular, se define un tipo de entidad débil por dependencia de existencia, esto quiere decir, que la entidad débil no puede existir si desaparece el tipo de entidad regular a la cual pertenece. El caso contrario es una dependencia de identificación (Elmari y Navathe, 2002; De Miguel et al., 1999). En una representación del modelo FuzzyEER que considere un tipo de atributo difuso definido sobre etiquetas lingüísticas, se da el caso que este puede tomar más de un valor (atributo difuso multivaluado), para atributos difusos con esta característica se obtiene más de un grado de pertenencia al conjunto, dependiendo de la etiqueta asociada. Definición 7: Se define una entidad débil difusa en dos casos: a) Si una entidad débil se define por dependencia de existencia. Para este caso, si

una entidad regular tiene uno o más atributos multivaluados y alguno es un atributo difuso, entonces en el modelo FuzzyEER se define una entidad débil difusa, identificada como EF. La representación gráfica es denotada por dos rectángulos con línea discontinua y asociado a éstos el atributo difuso multivaluado (que ejerce de clave parcial) y asociado a éste el grado, el cual opcionalmente puede tener algún significado, tal y como muestra la Figura 8a). La Ecuación siguiente muestra a EF definiendo sus instancias a partir de las m instancias de la entidad propietaria E. Así, para cada instancia de E,

DNI

EMPLEADO N° horas semanales (h)

G pertenecia Q(h)=min{1,h/35}

68 RITOS2

EF tiene n instancias: zFij = <k, bj, µbj (k)>, para i = 1, 2, ..., m (3)

donde k es la clave de la entidad propietaria E, bj son las n etiquetas con j=1,..., n. En este caso la clave de la entidad débil será la unión de los atributos de la clave de la entidad propietaria más el atributo bj que señala la etiqueta.

b) Si una entidad débil es establecida por dependencia de identificación. La representación gráfica es denotada por dos cuadrados con líneas punteada, junto a esta un atributo con círculo de líneas cortadas que índica un tipo de grado asociado al atributo, tal como lo muestra la Figura 8b). Este caso supone que la clave de la entidad débil será la unión de la clave de la entidad propietaria y una clave extra llamada clave parcial que debe tener la entidad débil. Así, los valores de esa clave parcial pueden repetirse en EF si pertenecen a distinta instancia de E.

* Algunos autores (Elmari y Navathe, 2002) prefieren unir la entidad débil con el

rombo de la interrelación con una doble línea, indicando así que todos los elementos de la entidad débil deben estar relacionados con la entidad propietaria. Además, el rombo prefieren ponerlo con doble línea para indicar más claramente cual es la interrelación de la entidad propietaria. Ejemplo 7: Se tiene una entidad EMPLEADO con los atributos (DNI, Nombre_empleado, Año_contrato, Evaluación). Para este caso, el atributo Evaluación es una calificación que obtiene cada empleado por su desempeño durante un período. El atributo es definido como T2: Evaluación y tiene asociadas las siguientes etiquetas: “deficiente”, “regular”, “bueno” y “excelente”. Desde este punto de vista, “Evaluación” es un atributo que presenta imprecisión, pudiendo en algunas instancias ser tratado como Tipo 1 con las mismas etiquetas definidas en el caso del atributo Tipo 2, y poder ser consultadas difusamente, o bien, puede transformarse a un dominio difuso, en ambos casos el conjunto de “deficiente”, “regular”, “bueno” y “excelente” son etiquetas lingüísticas de forma trapezoidal.

Para este caso, un empleado puede tener un grado de pertenencia a más de una etiqueta en el atributo Evaluación, de forma tal, que se obtenga el grado de pertenencia más representativo que se ajuste al desempeño del empleado. Por ejemplo, si un empleado es evaluado bueno; que tan cerca de excelente o que tan cerca de regular es la evaluación. Considérese que no es lo mismo un “bueno” con un alto grado de pertenencia a “regular” que un “bueno” con un alto grado de pertenencia a “excelente”.

En la Figura 8a), dado que cada atributo identificador principal de Empleado, tendrá uno o más grados de pertenencia en EMPLEADOF se puede representar una cardinalidad máxima de n. Para una instancia de E (identificada por k) puede asociarse n instancias en EF, donde n es el número de etiquetas lingüísticas (bj).

En la Figura 8b), muestra un ejemplo de una entidad débil difusa por dependencia de identificación, para el caso que un dueño de animales que tenga una cierta preferencia por cada uno de ellos. Ese grado de importancia G4 es identificado en la


entidad débil difusa mediante un atributo que considera “el grado de importancia de cada animal”.

Figura 8: Ejemplo esquema FuzzyEER de entidad débil difusa: a) con interrelación de dependencia de existencia, b) con interrelación de dependencia de identificación.

Este tipo de entidad débil abarca y mejora la definición de Chaudhry et al. (1994).

Su ventaja principal es que acelera algunos tipos de consultas difusas al estar en la entidad EF los grados ya calculados. Por ejemplo, ver los empleados que son “excelentes” (con grado mínimo 0.8), consiste en buscar el EMPLEADOF aquellas instancias con evaluación = excelente y G0 ≥ 0.8. Otra opción es que esos grados también pueden ser calculados en vez de almacenarse, cuando sea necesario.

7 Interrelaciones Difusas en FuzzyEER

Hasta aquí se ha mostrado la definición, notación y algunos ejemplos de atributos, y entidades que se pueden representar en el modelo FuzzyEER. En este apartado presentamos una extensión al concepto de interrelación difusa.

Algunos autores como Connolly et al. (1998) y Elmasri y Navathe (2002) llaman Vínculo o Tipo de interrelación (relationship) a la estructura genérica del conjunto de interrelaciones existentes entre dos o más tipos de entidad (en algunos casos se define una interrelación que asocian a la misma entidad, llamada interrelación recursiva), mientras que la ocurrencia (o instancia) de una interrelación será la vinculación existente entre las ocurrencias concretas de cada tipo de entidad que intervienen en la interrelación. Se representa el tipo de interrelación mediante un rombo etiquetado con el nombre de la interrelación, unido mediante arcos a los tipos de entidades asociadas.

También en De Miguel et al (1999) definen el concepto de atributo de las interrelaciones teniendo en cuenta que si una interrelación 1:N tiene un atributo asociado, este puede llevarse a la entidad cuya cardinalidad es máxima N. Semánticamente en ocasiones puede conservarse el atributo dependiendo de la

EMPLEADO

Transformar

EMPLEADOF

Nombre_ empleado

(0,2)G0 Evaluación

1:M

a) Año_contrato

T2: Evaluación {deficiente, regular, bueno, excelente}

T2: Evaluación

E

Codigo_ dueño

DUEÑO

Posee

ANIMAL

G4 animal

1:M

b)

ID

Codigo_animal

Código_dueño

70 RITOS2

interrelación, siendo esta última definición la que es utilizada en el modelo de datos FuzzyEER. Definición 8: Un tipo de interrelación I con una o más entidades se considera Interrelación difusa si tiene un atributo difuso que relacione las entidades asociadas a I. Su representación gráfica es un rombo con línea cortada con un atributo que establece dos tipos de interrelación difusa:

a) Un Tipo de atributo difuso T1, T2, T3 o T4, que enlaza un tipo de entidad con las etiquetas de un tipo de atributo difuso, las cuales son vistas como instancias de un tipo de entidad. Ese tipo de atributo difuso tendrá sus características propias. Por ejemplo, una relación de similitud si es Tipo 3, y esa relación de similitud “puede” declarase explícitamente, a través de la interrelación difusa. Opcionalmente, puede colocarse entre paréntesis el número máximo de valores asociados al atributo difuso.

b) Un Tipo de grado difuso con un significado propio G0, G1, G2, G3, G4 de un atributo difuso. Este tipo de interrelación difusa enlaza o relaciona dos o más tipos de instancias, asociando un grado a ese enlace, para cada pareja de instancias relacionadas.

La Definición 8 tienen asociada la notación (min,max) correspondiente a los tipos

de entidades. Véase Figura 9. *

Ejemplo 8: Se tiene la entidad BARRIO, que puede establecer un esquema de {Código_barrio, Nombre_barrio, Calidad}. Los atributos de código y nombre son definidos, para este caso, atributos crisp. El atributo Calidad del barrio se identifica como atributo difuso Tipo 3, dado por un dominio perteneciente al conjunto {“malo”, “regular”, “bueno”, “excelente”} que es previamente establecido.

Cada inmueble puede estar situado en un punto tal que pertenezca a varios barrios, o bien, que pertenezca a uno pero relativamente cerca de otro u otros barrios. Por ejemplo, para un inmueble se puede indicar que su barrio toma la siguiente distribución de posibilidad {0.5/Norte, 1/Oriente, 0.2/Plaza_España}, indicando que está situado propiamente en la zona del barrio de Oriente más cerca del barrio Norte que del barrio de la Plaza de España. Este es un caso especial, porque BARRIO es una entidad relacionada con la entidad INMUEBLE, de forma que un inmueble puede estar relacionado con varios. A la vez, un barrio para un Inmueble concreto, puede tener un grado con el que ese inmueble pertenece a ese barrio. Por tanto, el tipo de atributo T3 Barrio_colindante, genera un atributo difuso que relaciona las entidades INMUEBLE y BARRIO en la interrelación pertenece con un máximo de 3 barrios asociados a cada inmueble. Véase Figura 9.

La relación de proximidad sobre el atributo T3:Barrio puede representarse

como interrelación difusa cerca_de como lo muestra la Figura 9.


Figura 9: Interrelaciones difusas por atributos difuso y tipo de grado. Un ejemplo más detallado de este caso se encuentra en el Urrutia y Galindo (2002)

y Urrutia (2003).

8 Grado Difuso en las Especializaciones

En el mismo sentido como fueron incorporados los grados difusos en la agregación en el apartado 5, se puede utilizar como grados difusos en las especializaciones, es así como tenemos:

Definición 9: Se define un grado difuso en las especializaciones difusas de dos formas:

1. Grado de especialización en sus subclases, esto es dar un grado a cada subclase. La representación gráfica es Gn=<grado> junto a la línea que une a cada subclase con el vínculo de la especialización.

2. Grado de la especialización, esto es dar un mismo grado todas las subclases de esa especialización. La representación gráfica es Gn=<grado> junto al vínculo de la especialización.

* Para ambos casos se debe considerar los tipos de grados expuestos en el apartado

2.3 como Gn, En la notación Gn=<grado>, <grado> indicará el valor del grado que esta representando en un intervalo entre 0 y 1. La Figura 10 muestra para estos casos la notación en el modelo FuzzyEER, donde las subclases pueden ser, a su vez, vistas como entidades difusas o no.

INMUEBLE pertenece BARRIO

T3: Barrio_colindante (3)

(0,3) (0,n)

T3 Calidad {malo, regular, bueno, excelente}

Código_Barrio

Nombre_Barrio

cerca_de

Gproximidad T3:Barrio

72 RITOS2

Figura 10: Notación FuzzyEER . a) Grado en cada subclase de la especialización y b) Grado en la especialización.

Considérese que este tipo de concepto y representación (algún tipo de grado) se

puede usar para todas las jerarquías de especialización, generalización y agregación de igual forma como fueron tratadas aquí, en Marín et al. (2000) se muestran ejemplos similares a la notación de la Figura 10. Otras aplicaciones de la teoría de conjuntos difusos en especializaciones difusas se encuentran en Galindo et al., (2002), Galindo y Urrutia, (2003). 9 Comparación de Modelos Difusos

En el apartado 1 fueron discutidos los modelos conceptuales difusos de Chaudhry et al., (1994); Yazici y Merdan, (1996); Chen G., (1998); Ma et al., (2001), en ninguna de estas investigaciones se incorpora una herramienta CASE de apoyo al modelo propuesto que ayude en un diseño de un sistema que involucre incertidumbre. Nuestra propuesta tienen una herramienta FuzzyCASE asociada, la que permite modelar tanto el EER como FuzzyEER, la que incorpora todas las notaciones mostrada en este trabajo.

Por otro lado nuestra propuesta incorpora distintas notaciones, la Tabla 2 muestra una comparación del modelo FuzzyEER con los modelos de Chaudhry et al. (1994); Yazici y Merdan (1996); Chen (1998); Ma et al. (2001). Cada celda denota un “Sí” si el modelo tiene esa notación, en caso contrario la celda esta vacía. Cuando además la celda incluya un “Sí*” significa que la notación está presente en ese modelo pero con características distintas a la del modelo FuzzyEER, o bien, sus características son limitadas y más reducidas que las del modelo FuzzyEER aquí propuesto. Por lo general esta diferencia está dada por el uso de distintos tipos de dominios y tratamiento de la imprecisión, o bien, por algún tipo de grado en los otros modelos.

Superclase

d/o/fo/fd

Subclase...

Subclase

[Atributo clasificación]

Gn=<grado>

⊃⊃

b)Superclase

d/o/fo/fd

Subclase...

Subclase

[Atributo clasificación]

Gn=<grado> Gn=<grado>⊃⊃

a)


Componentes \ modelos difusos FEER Ma et al. (2001)

FERM Chaudhry

et al. (1994)

ExIFO Yazici y Merdan (1996)

Fuzzy ER Chen (1998)

FuzzyEER Urrutia (2003)

1. Valores difusos en los atributos Tipo 1Tipo 2Tipo 3Tipo 4

Sí*

Sí* Sí*

Sí*

Sí*

Sí*

Sí* Sí*

Sí*

Sí*

Sí Sí Sí Sí Sí

2. Grado difuso asociado a un atributo Sí* Sí* Sí* Sí 3. Entidades difusas Sí* Sí* Sí* Sí 4. Entidad débil difusa Sí* Sí 5. Entidad débil por grado de atributo Sí 6. Interrelación difusa Sí Sí 7. Interrelación por grado de un atributo Sí* Sí* Sí* Sí 8. Agregación difusa en entidades Sí* Sí* Sí* Sí 9. Agregación difusa de atributos Sí Sí Sí Sí 10. Grado en la especialización Sí Sí* Sí Sí 11.Grado en las subclases Sí Sí Sí 12 Herramienta gráfica Sí Tabla 2: Comparación de modelos difusos FEER, FERM, ExIFO, Fuzzy ER y FuzzyEER.

10 Conclusiones

Las bases de datos difusas han sido ampliamente estudiadas con el objetivo de permitir el almacenamiento de datos imprecisos o difusos y la consulta de forma imprecisa de los datos existentes. Sin embargo, tradicionalmente la aplicación de la lógica difusa a las bases de datos ha prestado escasa atención al problema del modelado conceptual, pocas investigaciones referencian la posibilidad de representar una notación completa y exhaustiva de tipos de atributos difusos, significados de los grados de éstos, entidades, interrelaciones, y en ningún caso encontramos una herramienta CASE que permita modelar datos con esta característica.

La teoría de conjuntos difusos permite definir atributos con referencial ordenado y no ordenado, normalizados (con máximo valor 1), o no normalizados (otros umbrales), para modelar información imprecisa perteneciente a cuatro tipos de atributos difusos definidos: Tipos 1, 2, 3, y 4. Además se puede representar distintos grado de un atributo, o de un conjunto de atributos (a todos sus atributos), estos grados pueden entenderse con distintos significados: de pertenencia G0, importancia G4, etc. Todos estos conceptos permiten extender el modelo EER a un modelo difuso FuzzyEER. Por consiguiente, se puede decir que un modelo de datos que contemple datos difusos, permite representar un tipo de datos de un sistema de información, que los sistemas tradicionales no abarcan y, por tanto, esa información se pierde en tales sistemas. Esto reduce el riesgo de obtener respuestas vacías de consultas efectuadas a

74 RITOS2

la base de datos, ya que permite utilizar una escala de discriminación más fina que considera el intervalo [0,1] en vez del conjunto {0,1}. Es decir, permite recuperar instancias, que en modo preciso no se obtendrían, por cumplir la condición impuesta sólo de forma parcial. Además, el conjunto de instancias puede ordenarse respecto a su nivel de cumplimiento en dicha condición.

Algunos casos de aplicación del modelo FuzzyEER son: Control de la calidad del papel (Urrutia, 2002 y 2003); Agencia inmobiliaria (Urrutia y Galindo, 2002) y (Urrutia, 2003). Extensión de un modelo difuso para gestión del conocimiento (Urrutia et al. 2001). También algunas de las extensiones de las notaciones de FuzzyEER presentadas aquí, se encuentran en: Urrutia et al., 2002a; Urrutia et al., 2002b; Galindo et al., 2001.; Urrutia, 2003.

Por último, el modelo FuzzyEER tiene una herramienta gráfica FuzzyCASE que permite la difusión del modelo propuesto. A su vez algunas de las notaciones FuzzyEER pueden ser implementadas en un servidor FSQL difuso construido en Galindo, (1999). En un futuro próximo intentaremos extender el FSQL con los conceptos del modelo FuzzyEER.

Referencias Bibliográficas

• Batini C., Ceri S., Navathe S. (1994): “Diseño Conceptual de Bases de Datos”,

Addison_Wesley/Díaz de Santos. • Chaudhry N., Moyne J., Rundensteiner E. (1994): “A Design Methodology for

Databases with uncertain Data”. 7th International Working Conference on Scientific and Statistical Database Management, Charlottesville, VA, (www.mitexsolutions.com).

• Chen G. (1998): “Fuzzy Logic in Data Modelling, Semantics Constraints, and Databases Desing”. Kluwer Academic Publishers.

• Connolly T., Begg C., Strachon A. (2001): “Data Bases System, a Practical aprroch to design, implementation and management”. Second edition, Addison Wesley.

• De Miguel A., Piattini M., Marcos E. (1999): “Diseño de Bases de Datos Relacionales”. Rama.

• Dubois D., Prade H. (1998): “Théorie des Posibilites Application á la Représentation des Connaissances en Informatique”, Masson, 2a édition.

• Elmasri R., Navathe S. B. (2000): “Fundamentals of Database Systems”, Third Edition. Addison-Wesley.

• Galindo J., Urrutia A., "Fuzzy Extensions to EER Specializations". Eighth CAiSE/IFIP8, International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD'03). Velden, Austria. June 16-17, 2003.

• Galindo J. (1999): “Tratamiento de la Imprecisión en Bases de Datos Relacionales: Extensión del Modelo y Adaptación de los SGBD Actuales”. Ph. Doctoral Thesis, University of Granada (Spain). (www.lcc.uma.es).

• Galindo J., Urrutia A., Carrasco R. (2001): “Fuzzy Constraints using the Enhanced Entity-Relationship Model”. Proceedings published by IEEE-CS Press of XXI International Conference of the Chilean Computer Science Society (SCCC). Punta Arenas (Chile).


• Galindo J., Urrutia A., Carrasco R. (2002): “Cuatro Tipos de Restricciones Difusas en Especializaciones”. I Workshop de bases de datos, JCC’2002 Copiapó Chile. ISBN: 956-291-506-9, pp. 79-88.

• Ma Z. M., Zhang W. J., Ma W. Y., Chen Q. (2001): “ Conceptual Design of Fuzzy Object-Oriented Databases Using Extended Entity-Relationship Model”. International Journal of Intelligent System, 16(6). pp. 697-711.

• Marín N., Pons O., Vila M.A. (2000). Fuzzy Types: “A New Concept of Type for Managing Vague Structures”. International Journal of Intelligent Systems, 15, pp. 1061-1085.

• Medina J.M. (1994): “Bases de datos Relacionales Difusas: Modelo Teórico y Aspectos de su Implementación”, Ph. Tesis Doctoral, Universidad de Granada, España. (decsai.urg.es).

• Mouaddib N. (1994): “Fuzzy Identification Database: the Nuanced Relation Division”, International Journal of Intelligent System, 9, pp. 461-473.

• Pedrycz W., Gomide F. (1998): “An Introduction to Fuzzy Sets: Analysis and Design”. A Bradford Book. ISBN 0-262-16171-0. The MIT Press, Massachusetts.

• Petry F. E. (1996): “Fuzzy Databases: Principles and Applications (with chapter contribution by Patrick Bosc)”, International Series in Intelligent Technologies. Ed. H.J. Zimmermann. Kluwer Academic Publ. (KAP).

• Raju K., Majumdar A. (1988): “Fuzzy Funcional Dependencies and Lossless Jion Decomposition of Fuzzy Reoltional Database System”, ACM Transaction on Database System, june Vol 13, N°2, pp 129-166.

• Rumbaugh J., Jacobson J., Booch G., (1999): “The Unified Modeling Language Reference Manual”, Addison Wesley.

• Umano M., Fukami S. (1994): “Fuzzy Relation Algebra for Possibility-Distribution-Fuzzy-Relation Model of Fuzzy Data”, Journal of Intelligent Information System, 3, pp. 7-28.

• Urrutia A. (2003): “Definición de un Modelo Conceptual para Bases de Datos Difusas”, Tesis Doctoral, Universidad de Castilla-La Mancha, España.

• Urrutia A. (2002): “Implementación de Bases de Datos Difusas: un Caso de Control de la Calidad del Papel”. Revista electrónica Gerencia Tecnología Informática AEDO, Noviembre, Volumen 1, número 1. Colombia. http://cidlisuis.org.

• Urrutia A., Galindo J. (2002): “Algunos Aspectos del Modelo Conceptual EER Difuso: Aplicación al Caso de una Agencia Inmobiliaria", XI Congreso Español sobre Tecnologías y Lógica Fuzzy (ESTYLF'2002), León (Spain), Septiembre, pp. 359-364.

• Urrutia A., Galindo J., Jiménez L. (2002a): “Extensión del Modelo Conceptual EER para Representar Tipos de Datos Difusos”. I+D Computación, Noviembre de 2002, Volumen 1, número 2, ISSN:1665-238X. http://www.sd-cenidet.com.mx/Revista/, (México).

• Urrutia A., Galindo J., Piattini M. (2002b): “Modeling Data Using Attributes Fuzzy”. IEEE Computer Society Press, XXII International Conference of the Chilean Computer Science Society. Nov, Chile. ISBN: O-7695-1867-2 ISSN: 1522-4902, pp.117-123.

• Yazici A., Merdan O. (1996): “Extending IFO Data Model for Uncertain Information”, 4th International Conference on Information Processing and Management of Uncertainty, IPMU’96. Pág. 1283-1282.

• Zadeh L. A. (1965): “Fuzzy Sets”. Information and Control, 8, pp. 338-353. • Zvieli A., P. Chen. (1986):”ER Modeling and Fuzzy Databases”, 2nd International

Conference on Data Engineering, pp. 320-327.

76 RITOS2

Sistemas de Información Geográfica: Revisión de su Estado Actual

Nieves R. Brisaboa, José A. Cotelo Lema, Antonio Fariña, Miguel R. Luaces, José R. R. Viqueira

Laboratorio de Bases de Datos. Facultade de Informática. Universidade da Coruña Campus de Elviña s/n. 15071. A Coruña. España.

{brisaboa, fari, luaces, joserios}@udc.es, [email protected]

Abstract. Los sistemas de información geográfica (SIG) ofrecen un entorno adecuado para la captura, almacenamiento y gestión tanto de información alfa-numérica como de la información necesaria para representar sobre el plano los objetos manejados por la aplicación. Éstos sistemas han experimentado un gran desarrollo en los últimos años, gracias entre otras cosa a las mejoras en rendi-miento de los ordenadores convencionales y a la aparición en el mercado de di-versas herramientas de desarrollo SIG, las cuales tratan de suministrar al des-arrollador un conjunto de utilidades que le asistan en el desarrollo de aplicaciones SIG lo más adaptadas posible al dominio de aplicación para el que han sido diseñadas. En este artículo describimos los conceptos básicos de esta tecnología y analizamos su evolución y las líneas de investigación actuales, tra-tando de describir el estado del arte de un campo poco conocido y en el que en general reciben poca formación los profesionales de la informática, a pesar de que en el mercado existe una demanda cada vez más grande de este tipo de aplicaciones.

1 Introducción

El incremento exponencial de la potencia de los equipos informáticos ha posibilitado que en la actualidad no sólo sea factible trabajar con grandes volúmenes de datos al-fanuméricos, sino que además también se les pueda asociar información sobre aspec-tos geográficos (espaciales) de los objetos a los que se refieren, de modo que, por ejemplo, se pueda representar gráficamente sobre mapas o esquemas gráficos. Igual-mente, han mejorado drásticamente las capacidades de consulta gráfica de toda esta información, gracias no sólo a ese incremento de potencia, sino también a la mejora en las capacidades gráficas de los sistemas informáticos.

Los sistemas de información geográfica (SIG) tratan de dar un paso más sobre los sistemas de información tradicionales para pasar a ofrecer un entorno adecuado para la captura, almacenamiento y gestión tanto de información alfanumérica (como hacían los sistemas tradicionales) como de información geográfica. Por información geográ-fica entendemos en este contexto información referente a la localización en el espacio de los objetos sobre los que queremos almacenar información. Esta información geo-

gráfica puede ser tan simple como la localización sobre un mapa de cada uno de los hospitales de un país o el área de un municipio ocupada por una parcela, o tan com-pleja como la distribución del territorio de un país en función del tipo de cultivo a que se dedica o de la salinidad de sus suelos. Además, las funcionalidades que ofrezca un SIG han de permitir una eficiente explotación de toda la información en él almacena-da, lo cual no sólo incluye la capacidad para realizar operaciones espaciales sobre los datos geográficos sino también la de consultar y analizar gráficamente esta informa-ción. El aspecto gráfico adquiere un papel especialmente relevante en estos sistemas, ya que las relaciones entre datos geográficos o entre éstos y datos alfanuméricos se pueden hacer mucho más fácilmente identificables para el usuario mediante una ade-cuada representación gráfica.

Aunque pueda parecer una puntualización superflua, es conveniente distinguir claramente lo que es un SIG de lo que es una herramienta de desarrollo de SIG. Una herramienta de desarrollo SIG ofrece las funcionalidades necesarias para el almace-namiento y gestión de la información alfanumérica y geográfica, así como un conjun-to de herramientas para la captura de datos y realización de consultas de esos mismos datos. Sin embargo, no ofrecen un entorno de captura y consulta adaptado a la infor-mación específica que se pretende almacenar en el SIG. Un símil de esta sutil y a la vez importante diferencia la tenemos entre un sistema gestor de bases de datos (SGBD) y un sistema de información tradicional. Si bien el SGBD ofrece el soporte para el almacenamiento y gestión eficiente de la información y las herramientas bási-cas (léase lenguajes de definición de datos, actualización y consulta) para la captura y consulta de datos, no se puede considerar a éste un sistema de información, sino que el sistema de información será una aplicación (o conjunto de aplicaciones) que haga uso de las funcionalidades ofrecidas por el SGBD para adaptarlo y presentar al usua-rio un entorno mucho más específico y sencillo.

Ejemplos significativos de áreas de aplicación de los SIG son la gestión catastral, de redes de saneamiento, de infraestructuras viarias o de comunicaciones, la navega-ción asistida por ordenador, o la toma de decisiones con respecto a la distribución de recursos, entre otros. Para el desarrollo de éstos sistemas, existen en la actualidad her-ramientas de desarrollo SIG que ofrecen al desarrollador la funcionalidad básica y las capacidades de desarrollo necesarias para poder construir un SIG adaptado al entorno de aplicación deseado.

Ante este panorama, parece necesario realizar una descripción precisa del estado del arte en el campo de los sistemas de información geográfica, que permita al no ini-ciado entender los conceptos en los que se basan y las funcionalidades que se deben esperar de ellos, así como tener una visión más clara de las implicaciones de los mo-delos de datos ofrecidos por las diferentes herramientas de desarrollo, para poder así realizar una elección más consciente de la misma. Para ello, un punto clave es distin-guir claramente las dos filosofías reinantes en las herramientas de desarrollo SIG ac-tuales, que se corresponden a lo que llamaremos herramientas orientadas a cartografía y herramientas orientadas a bases de datos espaciales.

El resto del artículo está estructurado del siguiente modo. La sección 2 muestra los conceptos básicos manejados en el dominio de los SIG. La sección 3 analiza las dos filosofías reinantes en las herramientas de desarrollo SIG actuales, a la vez que mues-tra la evolución experimentada por este tipo de herramientas. La sección 4 muestra las técnicas de representación de objetos geográficos típicas de cada una de estas filosofí-

78 RITOS2

as. Las secciones 5 y 6 analizan las necesidades de análisis espacial y de interfaces de consulta de los sistemas SIG, respectivamente. La sección 7 muestra las principales líneas de investigación en SIG. Por último, la sección 8 concluye el artículo.

2 Conceptos básicos

A la hora de comprender las características y funcionalidades de los SIG es necesario que previamente se tengan claros ciertos conceptos básicos sobre las características de la información que éstos van a manejar. La información de tipo geográfico puede clasificarse claramente en dos categorías, dependiendo de si ésta representa carac-terísticas del espacio geográfico (atributos referentes al espacio geográfico) o por el contrario representa propiedades de los objetos gestionados (atributos referentes a los objetos).

2.1 Conceptos básicos referentes al espacio geográfico

Se denomina espacio geográfico al espacio de coordenadas (normalmente R2) en el que los datos geográficos son representados, el cual suele ser o bien cartesiano (en ca-so de que el SIG utilice un modelo plano del mundo) o bien geodésico. Sobre este es-pacio geográfico es a menudo interesante almacenar cierta información, consistente en atributos alfanuméricos de los cuales se asocia un valor de su dominio a cada punto del espacio. Esta información que queremos almacenar sobre el espacio geográfico es lo que denominaremos atributos del espacio geográfico (en adelante AEG). Un AEG puede ser continuo (si el valor asociado a los puntos del espacio puede variar de modo gradual a lo largo del espacio geográfico) o discreto (si el conjunto de valores que puede tomar el atributo asociado al espacio geográfico es discreto). Un ejemplo de AEG discreto es el tipo de cultivo, mientras que un ejemplo de atributo continuo sería la salinidad del suelo, la temperatura o la presión atmosférica.

2.2 Conceptos básicos referentes a los objetos

Sobre el espacio geográfico se representan los objetos geográficos, que son objetos que el SIG debe manejar y representar gráficamente. Así tenemos:

• Objeto o entidad geográfica. Es un objeto sobre el que la aplicación SIG guarda no sólo información alfanumérica sino también información geográfica que permita representarlo gráficamente sobre un mapa. Por ejemplo, si consideramos el objeto geográfico "Ciudad de A Coruña", además de atributos alfanuméricos como el "nombre", "población", etc. puede tener un atributo geográfico “Localización del Ayuntamiento” que represente la posición del edificio de su ayuntamiento y otro atributo geográfico “área” que represente el área del espacio geográfico ocupada por la misma. En el momento de visualización el GIS puede, por ejemplo, utilizar el atributo “Localización del Ayuntamiento” para representar la ciudad en pre-sentaciones a escala 1:25.000 ó menor, y utiliza el atributo “área” para representar


a la ciudad en presentaciones a escalas mayores, donde esta información puede ser más útil. Es conveniente no confundir aquí la escala (de visualización) con la pre-cisión de la representación de los atributos geográficos, que es la resolución con la que la información geográfica es almacenada en el SIG.

c

r

c rts1

ts2

ts3

ts4

(a) Escala E1 (b) Escala E2

Fig. 1.Ejemplos de objetos geográficos y atributos del espacio geográfico a dos escalas distintas

• Atributo geográfico. Es un atributo que representa información referente a una característica geográfica del objeto al que pertenece (posición, extensión, etc.). Es un subconjunto no vacío y posiblemente infinito del espacio geográfico. Los atributos geográficos se representan mediante figuras geográficas, y su tipo se cor-responde con el tipo de figura geográfica que se utiliza para representarlo.

• Figura geográfica. Se usan para representar sobre el plano de forma gráfica atribu-tos geográficos de un objeto. En el dominio de los SIG se utilizan diversos tipos de figuras geográficas, siendo las más comunes las siguientes:

− Punto: El valor de una figura geográfica de este tipo se corresponde con un elemento (punto) del espacio geográfico. Un ejemplo de atributo geográfico representable mediante una figura geográfica de este tipo es la posición de un objeto, como por ejemplo la localización geográfica de una oficina de correos.

− Línea: Una figura geográfica de este tipo se corresponde con un conjunto de curvas en el espacio geográfico, donde una curva es una secuencia de puntos del espacio contiguos. Un ejemplo de atributos geográficos que pueden ser representados mediante una línea es el curso de un río o el trazado de una carretera.

− Región: El valor de una figura geográfica de este tipo se corresponde con un conjunto de áreas del espacio geográfico. Ejemplos de atributos geográficos representables mediante una región son el área del espacio ocupada por una parcela de terreno o la zona de un país afectada por las nevadas en un día dado.

− Geográfico: El valor de una figura geográfica de este tipo se corresponde con un conjunto de puntos y/o líneas y/o regiones del espacio geográfico. Aunque menos usado que los anteriores, este tipo de figura geográfica también es de utilidad en ciertos dominios de aplicación para representar atributos geográficos.

− Partición: Una figura geográfica de este tipo representa un elemento de una partición del espacio geográfico en áreas disjuntas. Un ejemplo de

80 RITOS2

atributo geográfico de tipo partición es el área de un ayuntamiento de una provincia, en la que los ayuntamientos no pueden superponerse y el área ocupada por el conjunto de todos sus municipios ha de coincidir exacta-mente con todo el área de la provincia.

Como ejemplo, en la Fig 1 pueden verse los atributos geográficos correspondientes a varios objetos geográficos a dos escalas distintas, así como la representación de dos atributos del espacio geográfico. Más en concreto, se observa cómo a la escala E1 el objeto geográfico "c" (que representa una ciudad) se representa mediante su atributo geográfico “Localización del Ayuntamiento”, de tipo punto, mientras que el objeto geográfico "r" se representa mediante un atributo geográfico de tipo línea. A la escala E2, el objeto "c" pasa a ser representado mediante su atributo geográfico “área”, de ti-po región, mientras que "r" continúa representándose mediante el mismo atributo de tipo línea (aunque al usar una escala mayor en la presentación podemos visualizar la misma con más detalle). A esta escala E2 puede verse además el atributo del espacio geográfico (AEG) discreto “tipo de suelo", que divide el espacio en cuatro regiones con valores ts1, ts2, ts3 y ts4 respectivamente, y el AEG continuo "salinidad" (colores más oscuros representan valores de salinidad del suelo más baja).

3 Herramientas de desarrollo SIG

En los últimos años han aparecido en el mercado numerosas herramientas de desar-rollo de SIG, las cuales ofrecen al desarrollador un entorno orientado a facilitar el de-sarrollo de aplicaciones SIG. Estas herramientas se caracterizan por ofrecer al desar-rollador las funcionalidades básicas para la gestión y almacenamiento de información tanto alfanumérica como geográfica, junto con ciertas facilidades para el desarrollo de interfaces de captura y consulta de los datos, de modo que éste pueda enfocar su es-fuerzo en adaptar el interfaz de la aplicación a las necesidades específicas del SIG de-sarrollado.

3.1 Filosofías seguidas por las herramientas de desarrollo SIG

Las herramientas de desarrollo de SIG se ajustan a una de las dos filosofías o enfo-ques fundamentales que existen a la hora de ver la relación entre información alfanu-mérica y geográfica. La filosofía seguida por la herramienta condiciona algunas deci-siones de diseño en el modelo de datos usado, así como la gestión y almacenamiento de los mismos, introduciendo con ello ciertas restricciones y limitaciones que han de ser tomadas en cuenta a la hora de elegir la herramienta a utilizar. Estas dos filosofías son:

• Herramientas orientadas a cartografía. Es el enfoque seguido por las herramientas de desarrollo SIG evolucionadas a partir de sistemas de gestión cartográfica o sis-temas CAD (como por ejemplo Microstation), en los cuales la información geográfica se almacena en ficheros estructurados en capas, cada una de los cuales contiene todos los objetos del plano de una determinada clase (por ejemplo, el


fichero contiene una capa de carreteras, una de ríos y una de parcelas). En este en-foque, la componente geográfica de los objetos es el elemento principal en torno al cual se agrupa la información a manejar, de modo que a cada objeto de una capa se le asociará además, probablemente, alguna información alfanumérica (por ejemplo, esa objeto es un núcleo urbano, al que se asociará su nombre o el número de habi-tantes). Como resultado, se asume que un objeto geográfico contendrá un único atributo geográfico y un conjunto quizás vacío de atributos alfanuméricos, dando un trato diferencial a cada tipo de atributos.

• Herramientas orientadas a bases de datos espaciales. Es el enfoque seguido por aquellas herramientas de desarrollo SIG que han evolucionado desde el domino de los SGBD. En este enfoque un atributo geográfico es un atributo más del objeto que se pretende modelar, sin hacer ninguna distinción especial entre éstos y los atributos alfanuméricos. En un SGBD esto implica que será posible utilizar predi-cados espaciales (relacionando atributos espaciales) en una consulta SQL, o que será posible realizar JOINs espaciales (cuando los atributos por los que se realiza el JOIN de las dos tablas son espaciales).

3.2 Evolución de las herramientas SIG

Las técnicas utilizadas para afrontar los aspectos de gestión y almacenamiento de la información manejada por los SIGs han ido evolucionando a lo largo de los años, con-forme la tecnología de desarrollo de estos sistemas ha ido madurando. Además, la fi-losofía seguida por las herramientas de desarrollo SIG utilizadas también ha tenido un peso importante en la arquitectura adoptada. Fundamentalmente, podemos distinguir tres etapas o generaciones en la evolución de los SIG [4]:

• Primera generación. En las herramientas SIG de primera generación la informa-ción geográfica (e índices asociados) se almacena en ficheros cuyo formato es par-ticular del SIG, por lo que éste es la única herramienta que puede ser utilizada para interpretar y manipular los datos. Las desventajas de estos sistemas son varias:

− Sólo pueden tratar de forma nativa información espacial, por lo que en caso de necesitar combinar datos geográficos con datos tradicionales, se necesita que una aplicación funcionando sobre el SIG realice esta tarea.

− El modelo de datos y la interfaz de la herramienta SIG son propietarios. − La aplicación SIG misma debe gestionar las cuestiones relacionadas con

seguridad, recuperación, e integridad de los datos, ya que la herramienta SIG no da soporte.

• Segunda generación. La segunda generación de herramientas SIG nació del deseo de integrar los datos geográficos con los de una base de datos tradicional. Las dos técnicas que se utilizaron en mayor medida son la arquitectura en capas y la ar-quitectura dual. En la arquitectura en capas, la funcionalidad del SIG se implementa sobre un SGBD comercial sin ninguna variación, tal y como se muestra en la Figura 2(a). La principal ventaja de estos sistemas es que los datos geográficos son gestionados por el SGBD, lo que permite utilizar su funcionalidad de control de transacciones,

82 RITOS2

seguridad, recuperación de fallos, etc. Hay dos posibles estrategias para representar los valores geográficos:

Geographic Information System

Database Management System

Geographic Information System

DatabaseManagement System

Geographic datamanagement system

(a) Arquitectura en capas. (b) Arquitectura dual

Fig. 2. Arquitecturas de segunda generación.

− Dividir la representación de un atributo geográfico en tuplas de forma que cada tupla almacene una componente de ésta. La desventaja de esta aproximación es que cada operación espacial debe reconstruir el objeto antes de realizar la operación, lo que resulta muy costoso.

− Utilizar un SGBD que proporcione objetos largos y almacenar en ellos los objetos geográficos. Esta aproximación es más eficiente, pero todavía pre-senta problemas debido a que los tipos de datos geográficos son opacos para el SGBD, lo que provoca que sus características no pueden ser utili-zadas para optimizar las consultas y que no se pueda utilizar con ellos ín-dices espaciales avanzados (únicamente un B-Tree con z-elementos).

Por otra parte, en la arquitectura dual (Figura 2(b)), se utiliza un SGBD para alma-cenar los datos alfanuméricos y un segundo subsistema que se encarga de gestionar los valores geográficos. Ambos subsistemas se integran a continuación mediante una capa que proporciona, además, el interfaz de usuario. Esta arquitectura permite utilizar la representación más apropiada para los valores geográficos, además de permitir el tipo de índice más apropiado para ellos. Un problema que presenta esta arquitectura es que la realización de consultas se complica, y la optimización global de las mismas es imposible. Además, el subsistema de gestión de datos geográficos debe implementar de nuevo funcionalidad estándar de los SGBD, tal como control de transacciones, recuperación de fallos, etc.

La arquitectura dual es característica de las herramientas orientadas a cartogra-fía, donde lo que se hace es asociar a la información geográfica que se almacena en un sistema la información alfanumérica almacenada en el otro. Un ejemplo de este tipo de herramientas es Microstation Geographics, que permite el desarrollo de SIGs que almacenan la información geográfica en ficheros de Microstation con-vencionales y la información alfanumérica en un SGBD convencional. Por su par-te, la arquitectura de capas es característica de las primeras generaciones de herra-mientas orientadas a bases de datos espaciales. Un ejemplo de esta arquitectura lo tenemos en las primeras extensiones espaciales de Oracle.

De forma general, los problemas que presentan las herramientas SIG de segunda generación son los siguientes:

− El SIG obliga al usuario a seguir el esquema de base de datos que se im-plementa, por lo que la integración con datos preexistentes es compleja y el sistema pierde en flexibilidad.


− La estructura y la semántica de los datos geográficos son totalmente des-conocidos para el SGBD, con lo cual ciertos beneficios de los SGBD no pueden ser disfrutados por el SIG (indexación, optimización de consultas, etc..).

− El administrador del SGBD debe conocer el funcionamiento del SIG y cómo interactúa éste con el SGBD para poder gestionar las bases de datos.

• Tercera generación. La tercera generación de herramientas SIG, de la cual co-mienzan a aparecer en los últimos tiempos los primeros productos comerciales, consiste en sistemas que utilizan los nuevos SGBD extensibles, los cuales pueden ser extendidos mediante módulos. Estos módulos incorporan nuevos tipos de datos, nuevos operadores y nuevos índices que permiten que el SGBD entienda de forma nativa los datos espaciales y sus operadores, gestionándolos de forma eficiente. Es-to permite integrar totalmente el SIG sobre el SGBD, trasladando toda la responsa-bilidad de gestión de datos a éste último, permitiendo al usuario realizar consultas mediante un lenguaje de consulta estándar extendido (p.e. SQL), y permitiendo que las herramientas de optimización del SGBD sean utilizadas de forma efectiva.

Afortunadamente, las herramientas GIS orientadas a bases de datos espaciales parecen estar migrando claramente hacia esta última generación, y así las últimas extensiones espaciales de Oracle, entre otras, ya lo han hecho. Por su parte, las herramientas orientadas a cartografía, aunque más reacias a migrar a esta tercera generación por su especial visión de la relación entre información geográfica y alfanumérica, sí lo están haciendo al menos parcialmente, principalmente en cuanto a usar los SGBD para al-macenar también la información espacial y así hacer uso de las funcionalidades ofre-cidas por éstos en cuanto a seguridad, recuperación, e integridad de los datos.

4 Representación de los datos

Si bien hasta este punto nos hemos centrado en la visión de las herramientas de desa-rrollo SIG desde un punto conceptual, hablando de objetos con atributos geográficos y representaciones de éstos en el espacio R2, lo cierto es que a la hora de representar esos atributos geográficos en un sistema informático no queda más remedio que res-tringirse a representaciones finitas, por lo que se vuelve necesario aproximar el con-junto R2 mediante algún tipo de malla finita de puntos. Dicha malla puede ser mode-lada, por ejemplo, con el conjunto finito Rm

2, donde Rm = {-m, ..., -1, 0, 1, ..., m}. Los tipos de datos geográficos, definidos en el nivel conceptual mediante subcon-

juntos de R2, se suelen representan sobre esta malla mediante aproximaciones lineales [10]. Sin embargo, el modo en que estas representaciones finitas son definidas, la se-mántica de sus valores e incluso el número de tipos definidos varía de unos autores a otros. Así, en [14] se utilizan aproximaciones lineales basadas en quantums, en las cuales un valor espacial es representado mediante un conjunto finito de puntos y seg-mentos paralelos a los ejes de coordenadas. Por su parte, en [12] los tipos de datos es-paciales se representan mediante elementos de un realm, el cual es un conjunto finito (no fijo) de puntos y segmentos tal que los segmentos pertenecientes a éste no se in-tersecan entre sí. En la Figura 3 se muestra un ejemplo de ambas representaciones.

84 RITOS2

a) b)

Fig. 3. Representación de valores espaciales mediante realms y mediante quantums.

Por otra parte, a la hora de almacenar los objetos geográficos, la solución usada depende de la filosofía seguida por la herramienta de desarrollo GIS. Para ilustrar la diferencia entre ambos enfoques se muestra a continuación cómo el modelo Rela-cional, como ejemplo de modelo conceptual usado en sistemas de información con-vencionales, puede ser utilizado para facilitar el modelado de información geográfica siguiendo cada una de las dos filosofías.

CAPAS:

CIUDAD_E1 (cod_ci, cod_mun, nombre, punto) CIUDAD_E2 (cod_ci, cod_mun, nombre, region) TIPO_SUELO (tipo, paticion)

CARRETERAS (cod_car, linea) SALINIDAD (salinidad, particion)

RELACIONES: MUNICIPIO (cod_municip, poblacion)

Fig. 4. Representación en capas en herramientas orientada a cartografía

En las herramientas de desarrollo SIG orientadas a cartografía, la información se almacena por capas. Una capa se define como una relación (en el sentido dado a esta palabra en el modelo relacional) que contiene en su esquema un atributo cuyo tipo de dato es uno de los tipos de dato geográficos soportados. Cada capa contendrá por tan-to toda la información referente a un tipo de objeto geográfico (un objeto por tupla). Los atributos del espacio geográfico (AEGs), tanto continuos como discretos, también generan sus correspondientes capas, una por cada AEG. Una capa, además de soportar las operaciones usuales del álgebra relacional sobre sus atributos no geográficos, ofrece también un conjunto de operaciones específicas entre capas, referentes a sus atributos geográficos (como se explicará más detalladamente en la sección 5).

En la Figura 4, se muestra cómo podría modelarse en este tipo de herramientas el ejemplo de la Figura 1 mediante un conjunto de capas y relaciones.

Nótese que aquellas relaciones entre capas que pueden resolverse mediante rela-ciones entre atributos geográficos (por ejemplo, qué ciudades comunica la carretera “r”) no generan ninguna tabla nueva, sino que son implícitas (gracias a que están de-finidos sobre el mismo espacio geográfico), y pueden obtenerse aplicando operadores espaciales. Extensiones del modelo relacional siguiendo esta filosofía han sido defini-das, entre otros, en [5] y [19].

En las herramientas de desarrollo SIG orientadas a bases de datos espaciales no se hace ningún tratamiento especial a las entidades o relaciones que contienen atributos geográficos. En el caso de los atributos del espacio geográfico, por su parte, éstos se


representan de modo similar a como se hace en las herramientas orientadas a cartogra-fía. Al contrario que en la filosofía de herramientas orientadas a cartografía, aquí las operaciones aplicables a relaciones que contienen atributos geográficos en su esque-ma son exactamente las mismas que las aplicables a aquellas que no los contienen, consiguiendo de esta manera la integración total en la manipulación de todos los tipos de datos. En la Figura 5 se muestra como el modelo entidad-relación del ejemplo de la Figura 1 produce un conjunto de relaciones con tipos de dato espaciales.

Extensiones de otros modelos lógicos, como por ejemplo el relacional anidado [1], objeto relacional [20] (utilizado en las extensiones espaciales de la mayoría de siste-mas de bases de datos comerciales [17, 13, 4]), orientado a objetos [21], etc. han sido propuestas en la literatura de bases de datos espaciales. La inclusión de tipos de dato espaciales en un modelo orientado a objetos se incluye en el estándar OpenGIS [16].

RELACIONES: CIUDAD (cod_ci, cod_mun, nombre, punto_e1, region_e2) TIPO_SUELO (tipo, paticion) CARRETERAS (cod_car, linea)

SALINIDAD (salinidad, particion) MUNICIPIO (cod_municip, poblacion)

Fig. 5. Representación en herramientas orientada a bases de datos espaciales

5 Manipulación de los datos: álgebras y lenguajes

En una herramienta de desarrollo SIG, además de la capacidad de almacenamiento de información alfanumérica y geográfica hay un aspecto clave a cuidar, que es la capa-cidad de explotación de la información almacenada, tanto alfanumérica como geográ-fica. Para ello es necesario incluir en el sistema de información geográfica un conjun-to de herramientas de análisis espacial.

5.1 Funcionalidad requerida

La gran diversidad de aplicaciones de los sistemas de información geográfica hace imposible ofrecer un conjunto de herramientas que soporten toda la funcionalidad re-querida. La solución a este problema se centra en suministrar un conjunto de herra-mientas básicas que sean utilizadas en un gran número de aplicaciones, y proporcio-nar además un entorno extensible en el que el usuario pueda definir nuevas herramientas adaptadas a su aplicación concreta. Las herramientas básicas que deberí-an ser suministrar la herramienta de desarrollo SIG son, entre otras, las siguientes:

• Herramientas para comprobar las distintas relaciones topológicas entre atributos geográficos [2, 8] (por ejemplo comprobar si las figuras A y B son disjuntas, si A está contenida en B, etc.).

• Cálculo de características de tipo numérico a partir de datos de tipo espacial, como por ejemplo el calculo de áreas de regiones, longitudes de líneas, distancias entre figuras geográficas, etc.

86 RITOS2

• Construcción de figuras geográficas a partir de otras. Ejemplos de este tipo de herramientas son la intersección, unión y diferencia de figuras, la creación de áreas de influencia, cálculo del borde de regiones, puntos de inicio y final de líneas, etc.

• Manipulación conjunta de datos alfanuméricos y geográficos, como son las opera-ciones de reclasificación (permite fusionar los valores geográficos de una capa o relación que contengan la misma información en los atributos alfanuméricos y cu-yos atributos geográficos sean adyacentes) overlay (permite agrupar en una sola capa o relación de salida la información que contienen dos capas o relaciones de entrada) y los joins espaciales (joins usando condiciones espaciales).

• Análisis espaciales de tipo más complejo y específico, como por ejemplo el cálculo del camino más corto entre dos puntos en una red de líneas.

• Estudio estadístico de atributos del espacio geográfico de tipo continuo, como pue-de ser la interpolación (construcción de una capa o relación de temperaturas a par-tir de un conjunto finito de mediciones) y la discretización (a partir de una capa o relación de temperaturas dividir el espacio en zonas donde la temperatura sea ma-yor o menor que cero grados centígrados).

5.2 Consultas en herramientas orientadas a cartografía

Como ya se ha visto anteriormente, en las herramientas orientadas a cartografía los objetos geográficos se almacenan en capas. Una capa no es más que una relación en la que se incluye un atributo geográfico. Una capa no admite el mismo conjunto de operaciones sobre atributos geográficos que el álgebra relacional proporciona sobre atributos alfanuméricos, por lo que para permitir la correcta explotación de los datos almacenados en capas debe definirse un álgebra especializada para ellas.

De una manera general, las operaciones que debe contener un álgebra de capas son las siguientes:

• Selección: Permite seleccionar el conjunto de tuplas de una capa que cumple una determinada condición. Esta condición puede ser una condición sobre atributos al-fanuméricos, sobre el atributo geográfico o incluso mixta.

• Proyección: Permite eliminar de una capa uno o varios atributos no geográficos. • Unión, diferencia e intersección: Dadas dos capas con el mismo esquema (mismos

tipos de datos en sus atributos), permiten calcular la unión, diferencia e intersec-ción de sus tuplas.

• Cálculo convencional: Esta operación permite calcular una o varias columna de in-formación alfanumérica mediante la aplicación de una determinada función a los atributos de una capa. Las nuevas columnas de información pueden ser añadidas a la propia capa.

• Cálculo geográfico: Permite sustituir el atributo geográfico de una capa por el re-sultado de aplicar una función al mismo.

• Overlay: Dadas dos capas C1(a, G) y C2(b, G), donde a y b representan un conjun-to de atributos alfanuméricos. Esta operación produce una capa C0(a, b, G), conte-niendo los siguientes conjuntos de tuplas:

− Para las intersecciones de figuras geográficas de C1 y C2 se almacenan los atributos alfanuméricoss (a, b).


− Para las partes de figuras geográficas de C1 que no intersecan con figuras geográficas de C2, se almacenan los atributos alfanuméricos (a, null).

− Para las partes de figuras geográficas de C2 que no intersecan con figuras geográficas de C1, se almacenan los atributos alfanuméricos (null, b).

Nótese que tanto la operación producto cartesiano como la operación join, aplicadas a dos capas, producirían como resultado una relación con dos atributos de tipo geográ-fico, que no cumple con la definición de capa. Por ello, estas operaciones no pueden aplicarse sobre dos capas, aunque sí sobre una capa y una relación alfanumérica. Un ejemplo de un álgebra de capas se presenta en [5].

5.3 Consultas en herramientas orientadas a bases de datos espaciales

En las herramientas orientadas a bases de datos espaciales se apuesta por un manejo integrado de todos los tipos de información almacenados en el sistema. Esto, en el ámbito del álgebra relacional se traduce en que las operaciones aplicables a relaciones que sólo contengan atributos alfanuméricos han de ser también aplicables a aquellas que también contengan atributos geográficos.

La extensión de la funcionalidad del álgebra relacional se realiza mediante la:

• Definición de un conjunto de predicados espaciales, los cuales pueden ser utiliza-dos como condiciones en las operaciones de selección y join.

• Definición de un conjunto de funciones espaciales. Estas funciones, permiten cal-cular información alfanumérica a partir de atributos geográficos y calcular valores espaciales (geográficos) a partir de otros valores espaciales (union, diferencia, creación de zonas de influencia, etc.). Al igual que los predicados, pueden ser in-cluidas en las expresiones de las condiciones utilizadas en las operaciones de se-lección y join.

• Definición de nuevas operaciones relacionales. Estas nuevas operaciones permiti-rán el manejo integrado de la información alfanumérica y geográfica contenida en una o dos relaciones. Ejemplos de estas operaciones son de nuevo la reclasifica-ción y el overlay, cuya funcionalidad ya ha sido especificada en la sección anterior. La diferencia entre estas operaciones y las operaciones definidas para capas es que este caso las operaciones deben poder ser aplicadas a relaciones que no contengan atributos geográficos.

Extensiones del álgebra relacional para el manejo de información espacial se pre-sentan en [9, 14]. Otros modelos, como el orientado a objetos o el objeto-relacional, han sido también elegidos para su extensión para el tratamiento de datos geográficos. Tanto en el modelo objeto-relacional como en el orientado a objetos, la extensión vie-ne dada por la definición de nuevos tipos de datos espaciales, en forma de clases abs-tractas de objetos, en las que no sólo se incluye la estructura de datos, sino que tam-bién se definen métodos para su manipulación. Entre los métodos definidos en los tipos de datos espaciales se incluyen tanto predicados como funciones espaciales. Por último, en [12] se define un álgebra para la manipulación directa de valores de tipos de dato espaciales. Esta álgebra puede ser incluida en muchos de los modelos lógicos existentes.

88 RITOS2

5.4 Lenguajes de consulta

En lo que se refiere a lenguajes de consulta, la mayoría de los sistemas de informa-ción geográfica comerciales proporcionan amplios conjuntos de comandos, incluidos o no en una interfaz gráfica de usuario, que implementan operaciones entre capas (en el caso de una relación con más de un atributo geográfico, ésta puede verse como va-rias capas, una por cada atributo geográfico). Éste es el caso de paquetes comerciales como Arc/Info 7 y Geomedia 3.0. La expresividad y facilidad de uso de estos conjun-tos de comandos, a pesar de estar incluidos en entornos gráficos de usuario, está lejos de la proporcionada por los lenguajes clásicos de consulta a bases de datos, como son el SQL.

En el mundo de las bases de datos espaciales son muchas las extensiones de SQL que se presentan en la literatura [7, 18]. Centrándonos de nuevo en el modelo rela-cional, SQL92 se extiende con nuevos tipos de datos, nuevos predicados y funciones espaciales para incluir en las expresiones usadas en consultas (sobre todo en la cláusula WHERE de las sentencias SELECT), y nuevas operaciones, como OVERLAY, que se añaden a las ya existentes UNION, JOIN, etc.

Similarmente, las extensiones del modelo objeto-relacional deberían considerar el estándar SQL99, mientras que las extensiones del modelo orientado a objetos deberí-an basarse en el lenguaje OQL y el estándar OpenGIS. Este estándar define un conjunto básico de tipos de datos geográficos que los SIG y bases de datos espaciales deberían de ser capaces de manejar y las operaciones espaciales sobre ellos que de-berían de suministrar.

6 Interfaces

Dos son los aspectos que debemos considerar en cuanto a las interfaces de los SIG: las interfaces de usuario y las interfaces con otros sistemas (interconectividad).

6.1 Interfaces de usuario

La finalidad principal de un SIG es la de servir como herramienta de análisis y ayuda a la toma de decisiones, para lo cual debe permitir el análisis cualitativo de los datos geográficos. A diferencia de los sistemas gestores de bases de datos tradicionales, en los que se almacenan datos alfanuméricos que pueden ser introducidos fácilmente mediante el teclado y cuyos resultados pueden ser mostrados textualmente, los datos que manejan los sistemas de información geográfica deben ser mostrados en una in-terfaz gráfica. Además, tal y como se remarca en [6], el análisis cualitativo, que se ba-sa a menudo en la comparación visual de situaciones diferentes, es difícil de conse-guir a no ser que las situaciones a comparar sean visibles simultáneamente, por lo que las interfaces de SIG deben ser dispuestas de tal manera que varios mapas e informa-ción alfanumérica sean visibles simultáneamente y puedan ser comparados directa e indirectamente. Esto se consigue en los SIGs mediante el concepto de capas.

Una capa muestra un conjunto de objetos geográficos o un atributo del espacio geográfico (AEG). Una capa con objetos geográficos será transparente allí donde no


hay ningún elemento de este tipo, de modo que se puedan ver las capas inferiores. En las zonas donde hay algún elemento éste se puede representar como un objeto opaco, translúcido o bien mediante su contorno. En el caso de una capa que represente un AEG, el funcionamiento será similar. Un AEG discreto puede representarse como si existiese un objeto geográfico por cada posible valor tomado por el atributo alfanumé-rico asociado, representando los puntos del espacio que tienen asociado el mismo va-lor. Para los AEGs continuos, existen dos opciones, que son representar éstos por ni-veles (es decir, discretizándolos) o bien representarlos mediante gamas de colores, de modo que cada punto tenga un color proporcional al del valor alfanumérico asociado a él. El SIG incorpora un gestor de capas que permite al usuario configurar el orden en el que se muestran las capas, añadir y eliminar capas, de forma que permite cons-truir de modo dinámico un mapa con la información. Además, se permite al usuario almacenar de forma permanente configuraciones interesantes que pueden ser recupe-radas más adelante, con la particularidad de que no se almacenan los datos que com-ponen el mapa, sino la estructura del mismo, con lo que un cambio en los datos pro-voca un cambio en el mapa. Es importante remarcar que las propiedades de los elementos cartográficos dibujados pueden ser modificadas fácilmente y asignadas en función de los datos alfanuméricos. Por tanto, los objetos geográficos se encuentran completamente desacoplados de los objetos cartográficos.

La naturaleza dual de los datos almacenados, geográficos y alfanuméricos, también es tenida en cuenta en estos sistemas, que permiten mostrar resultados alfanuméricos, en particular los de un objeto geográfico determinado. Esto hace que los SIG deban proporcionar un método para seleccionar un objeto geográfico y, dado que los objetos pueden solaparse, esto debe ser considerado por el sistema y proponer una solución que permite determinar precisamente qué elemento se desea seleccionar. Además, es conveniente que la interfaz permita realizar una selección “burda”, o “grosera”, es de-cir, que no obligue a apuntar a los objetos con precisión milimétrica, sino que permi-tan seleccionar un objeto pulsando en un punto “relativamente” cercano a él. Los mé-todos de consulta se apoyan también en las interfaces gráficas y las herramientas de selección, pues los parámetros geográficos de las consultas suelen ser seleccionados o introducidos mediante la interfaz.

La escala de los mapas es un parámetro fundamental en el mundo cartográfico, y debe estar presente en los SIGs. Una diferencia fundamental es que los mapas de un SIG no se encuentran a una escala determinada, sino que ésta puede ser cambiada de forma dinámica. Es importante que el SIG muestre en todo momento la escala a la cual se visualizan los datos, y que permita conocer las coordenadas de los objetos geográficos. Un aspecto relacionado, pero a la vez completamente diferente, es la re-solución con la que la información geográfica es almacenada en el SIG, la cual ha de ser la adecuada para el uso que se vaya a dar a dicha información, ya que limitará el nivel de detalle con el que ésta podrá ser mostrada.

Una característica importante en los SIG es la capacidad de mostrar representacio-nes diferentes de los objetos geográficos en escalas diferentes. Esto se conoce como problema de la generalización [22, 23, 24]. Las posibles opciones a la hora de cons-truir nuevos objetos geográficos a partir de los existentes son las siguientes:

• Simplificar el contorno de un objeto geográfico. Si la escala utilizada es tal que es imposible mostrar todo el detalle del contorno de un objeto geográfico, puede re-ducirse el detalle del mismo para acelerar el proceso de dibujado.

90 RITOS2

• Asignar una nueva representación a un objeto en función de la escala, por ejemplo, las ciudades que se representan con superficies en un mapa de gran detalle, se rep-resentan con puntos en un mapa de pequeña escala. Es posible, incluso, que se permita que objetos desaparezcan a no ser que tengan importancia semántica.

• Agregar objetos que representan una partición del plano, por ejemplo agregando las provincias de un país para mostrar únicamente el contorno del país en mapas de pequeña escala.

• Seleccionar algunos de los elementos de un objeto geográfico complejo, como por ejemplo seleccionar sólo algunos edificios de una ciudad.

6.2 Interconectividad

Conforme el acceso a la información a través de redes de datos (como Internet) ha de-jado de ser algo excepcional para pasar a estar a la orden del día, la capacidad de los sistemas SIG para interrelacionar información almacenada en distintos sistemas y procedente de diferentes fuentes se ha vuelto un requerimiento imprescindible. Una herramienta de desarrollo SIG debería permitir la fácil interconexión de éste con nue-vas fuentes de información, situadas en ordenadores completamente distintos y que utilizan distintos sistemas de almacenamiento, y permitir utilizar esta información como si estuviese almacenada localmente. Esto implica por un lado que el método de acceso a la fuente de los datos ha de ser lo más transparente posible al usuario, pero también que la estructura concreta de las capas a analizar (en cuanto a qué atributos han de contener) no debería de tener que ser prefijada de antemano. Asimismo, el sis-tema SIG debería ser capaz de trabajar con datos representados en diferentes sistemas de coordenadas e interrelacionarlos igual que si todos los datos estuviesen utilizando el mismo.

Dado que un importante grupo de las aplicaciones que trabajan con información geográfica son los sistemas CAD, y la interoperabilidad con sistemas existentes es siempre algo deseable, es también importante que los SIG permitan utilizar, de forma cómoda, datos provenientes de éstos sistemas.

Por último, no se debe descuidar la capacidad para hacer pública la información gestionada por el SIG, lo cual implica, por un lado la capacidad de exportar la infor-mación gestionada siguiendo los principales estándares (por ejemplo, OpenGIS [16]), y por otro la posibilidad de ofrecer al público la capacidad de realizar consultas al sis-tema SIG (por ejemplo, a través de la WEB).

7 Nuevas líneas de investigación

Aunque a lo largo de los últimos años se han dado grandes pasos en el desarrollo de herramientas SIG, aún quedan funcionalidades deseables que incorporar a éstas. Entre los aspectos a investigar y/o incorporar están los siguientes:

• Indexación. Aunque se ha realizado una gran cantidad de investigación en el área de indexación de información espacial, la expectativa de que los SIG tengan que manejar cantidades de información geográfica cada vez más grandes implica la ne-


cesidad de seguir mejorando los métodos de indexación existentes, para así lograr una mayor eficacia de los mismos.

• Modelos de datos. El uso de representaciones finitas para la información geográfica genera no pocos problemas de robustez y consistencia de datos, así como en la integración de información representada a diferentes resoluciones. Aunque ya se han propuesto mejoras para reducir estos problemas [3, 12, 14, 15], todavía queda bastante camino por recorrer en esta dirección.

• Tiempo en SIG y BB.DD. espacio-temporales. Un aspecto interesante y un reto para la comunidad SIG es la incorporación de la dimensión temporal, tanto en la representación y gestión de información espacio-temporal que cambia a intervalos discretos como aquella que evoluciona de forma continua en el tiempo [11].

• Interoperabilidad. Aspectos como la integración de información geográfica, posiblemente a distinta resolución, y proveniente de distintas fuentes requiere to-davía más investigación para poder mejorar las capacidades de interconexión de sistemas SIG.

• Indexación y joins en atributos heterogéneos (por ejemplo, figuras geográficas del tipo geográfico).

• Manipulacion de atributos espaciales y redes. La mayoría del trabajo en el dominio SIG se ha centrado en la visión del espacio como un almacén de objetos, pero to-davía queda mucho trabajo que hacer en la gestión de atributos del espacio geográfico (especialmente los continuos) y en el desarrollo de herramientas SIG orientadas a la gestión de redes.

• Manejo de información difusa.

8 Conclusiones

Se espera que los sistemas SIG sufran gran impulso en los próximos años debido a su capacidad de representar gráficamente objetos geográficos, demostrando así las rela-ciones espaciales entre ellos fácilmente y mejorando las funcionalidades y facilidad de uso de muchas aplicaciones. Por otro lado, la evolución de las herramientas de de-sarrollo SIG facilita el desarrollo de aplicaciones SIG eficaces y adaptadas a cada dominio de aplicación. Las nuevas líneas de investigación descritas anteriormente do-tarán además a los SIG de mayores funcionalidades que las herramientas actuales, principalmente en ciertos entornos de aplicación (catastro, gestión de redes, navega-ción, etc.)

Por ello consideramos que éste será un campo con una gran demanda de profesio-nales en los próximos años y lamentamos que los recién licenciados carezcan, en ge-neral, de formación en el manejo y programación de este tipo de aplicaciones.

Referencias

[1] E P. F. Chan, R. Zhu. QL/G – A Query Language for Geometric Data Bases. Proc. First International Conference on GIS, Urban Regional and Environmental Planning, Samos, Greece, 271-286, 1996.

92 RITOS2

[2] E. Clementini, P. Di Felice, P. van Oosterom. A Small Set of Formal Topological Rela-tionships Suitable for End-User Interaction. Advances in Spatial Databases, D. Abel, B. C. Ooi (eds.), Third International Symposium, SSD’93, Lecture Notes in Computer Sci-ence 692, Springer-Verlag, Singapore, 277-295, 1993.

[3] J. A. Cotelo Lema, R. H. Güting. Dual Grid: A New Approach for Robust Spatial Algebra Implementation. FernUniversität Hagen, Informatik-Report 268, May 2000.

[4] J. R. Davis. IBM's DB2 Spatial Extender: Managing Geo-Spatial Information within the DBMS. http://www.ibm.com/software/data/pubs/papers/. Technical Report IBM Corpora-tion, May 1998.

[5] V. Delis, Th. Hadzilacos, N. Tryfona. An Introduction to Layer Algebra. Proc. 6th Interna-tional Symposium on Spatial Data Handling (SDH’94), 1020-1041, 1994.

[6] M. J. Egenhofer. Interaction with Geographic Information Systems via Spatial Queries. Journal of Visual Languages and Computing, Vol. 1, pp. 389-413, Academic Press Lim-ited, 1990.

[7] M. J. Egenhofer. Spatial SQL: A Query and Presentation Language. Transactions on Knowledge and Data Engineering, Vol. 6(1), pp. 86-95, 1994.

[8] M. J. Egenhofer, J. R. Herring. Categorizing Binary Topological Relations Between Re-gions, Lines, and Points in Geographic Databases. Technical Report, Department of Sur-veying Engineering, University of Maine, 1990.

[9] M. Gargano, E. Nardelli, M. Talamo. Abstract data types for the logical modeling of com-plex data. Information Systems 16(6), 565-583 (1991).

[10] R. H. Güting. Special Issue on Spatial Database Systems: An Introduction to Spatial Da-tabase Systems. VLDB Journal: Very Large Data Bases, 3(4), pp. 357-399, October 1994.

[11] R.H. Güting, M.H. Böhlen, M. Erwig, C.S. Jensen, N.A. Lorentzos, M. Schneider, and M. Vazirgiannis. A Foundation for Representing and Querying Moving Objects. FernUniver-sität Hagen, Informatik-Report 238, September 1998. Revised version to appear in ACM Transactions on Database Systems.

[12] R. H. Güting, M. Schneider. Realm-Based Spatial Data Types: The ROSE Algebra. VLDB Journal 4, 100-143, 1995.

[13] Illustra 2D Spatial Datablade (Release 1.3) Guide. October 1994. [14] N. A. Lorentzos, N. Tryfona, J. R. Rios Viqueira. Relational Algebra for Spatial Data

Management. Proc. of the International Workshop Integrated Spatial Databases: Digital Images and GIS (ISD'99), pp 192-208, Lecture Notes in Computer Science 1737, June 1999.

[15] V. Muller, N. W. Paton, A. A. A. Fernandes, A. Dinn, M. H. Williams. Virtual Realms: An Efficient Implementation Strategy for Finite Resolution Spatial Data Types. Proc. 7th In-ternational Symposium on Spatial Data Handling, M. Kraak and M. Molenaar (eds.), Tay-lor & Francis, 697-710, 1997.

[16] OpenGIS® Abstract Specification (Version 4). June 1999. http://www.opengis.org/techno/specs.htm.

[17] Oracle 8i Spatial User’s Guide and Reference. Release 8.1.5. February 1999. [18] N. Roussopoulos, S. Kelley. PSQL: An Inexpensive GIS Solution for Oracle. Advanced

Communications Technology Inc. Technical Report, 1995. [19] M. Scholl, A. Voisard. Thematic Map Modeling. A. Buchmann et al. (Eds.), Design and

Implementation of Large Spatial Databases, Lecture Notes in Computer Science 409, Springer-Verlag, Berlin, 1989.

[20] T. Vijlbrief, P. van Oosterom. The GEO++ system: An Extensible GIS. Proc. 5th Int. Symp. on Spatial Data Handling (SDH'92), Charleston, SC, 1992, 40-50.

[21] A. Voigtmann, L. Becker, K. Hinrichs. An Object-Oriented Data Model and Query Lan-guage for Geographic Information Systems. Technical Report 15/95-I, University of Mu-nich, 1995.


[22] A. Voisard. Towards a Toolbox for Geographic User Interfaces. Second International Symposium in Advances in Spatial Databases (SSD), pp. 75-97, 1991.

[23] A. Voisard. Designing and Integrating the User Interface of Geographic Database Appli-cations. ACM International Conference on Advanced Visual Interfaces (AVI), pp. 133-143, 1994.

[24] A. Voisard. Mapgets: A Tool for Visualizing and Querying Geographic Information. Jour-nal of Visual Languages and Computing, Vol. 6, Academic Press, December 1995.

94 RITOS2

Comparación de un Sistema de Colonias de Hormigas y una Estrategia Evolutiva para el Problema del

Ruteo de Vehículos con Ventanas de Tiempo en un Contexto Multiobjetivo

Benjamín Barán y Augusto Hermosilla

Centro Nacional de Computación, Universidad Nacional de Asunción San Lorenzo, Casilla de Correos 1439 - Paraguay {bbaran, ahermosilla}@cnc.una.py

http://www.cnc.una.py

Resumen. Este trabajo compara un Sistema de Optimización basado en Colonias de Hormigas (Ant Colony Optimizatiom) con una estrategia evolutiva (variante del Pareto Archived Evolutionary Strategy), utilizados en la resolución multiobjetivo del problema de ruteo de vehículos con ventanas de tiempo. (Vehicle Routing Problem with Time Windows).

1 Introducción

El problema del ruteo de vehículos (Vehicle Routing Problem, o VRP) es ya considerado un paradigma en la literatura especializada [1]. Este problema se plantea como un depósito central que cuenta con una flota de vehículos y debe atender a un conjunto de clientes geográficamente distribuidos. El objetivo del VRP es entregar bienes a este conjunto de clientes con demandas conocidas, al mínimo coste, encontrando las rutas óptimas que se originan y terminan en el referido depósito. Cada cliente es servido una sola vez y todos los clientes deben ser atendidos, para lo cual se los asigna a vehículos que llevarán la carga (demanda de los clientes que visitará) sin exceder su capacidad.

Para extender el VRP tradicional agregando la restricción adicional de asociar una ventana de tiempo a cada cliente, se define un intervalo en el que cada cliente debe ser atendido y se obtiene el problema del ruteo de vehículos con ventanas de tiempo (Vehicle Routing Problem with Time Windows, o VRPTW) [2]. Al considerar estas ventanas de tiempo, el costo total de ruteo y planeamiento (scheduling) incluyen: la distancia total recorrida que está asociada al tiempo total de viaje efectivo, el tiempo total de espera en que se incurre cuando un vehículo llega muy temprano a la ubicación de un cliente y el tiempo total de servicio (tiempo para descargar todas las mercaderías solicitadas por cada cliente). Claramente, el tiempo en el que se inicia el servicio a un cliente debe ser mayor o igual al inicio de su ventana de tiempo y el instante en que se llega a cada cliente debe ser menor o igual al fin de su ventana de

tiempo. Si un vehículo llega a la ubicación de un cliente antes del inicio de su ventana de tiempo, debe esperar hasta esa hora para servir a ese cliente.

El problema espacial del ruteo de vehículos ha sido extensamente estudiado en la literatura. Una gran variedad de abordajes han sido ya publicados para resolver este problema, utilizando implementaciones paralelas [3], estrategias híbridas combinando métodos de búsqueda local con algoritmos evolutivos [4], redes neuronales [5, 6], una heurística que utiliza información de feromonas [7] y trabajos que resuelven este problema con estrategias evolutivas para optimizar la demanda de cada vehículo además de la optimización del número de vehículos y el tiempo total de viaje [8].

La restricción de ventanas de tiempo solo ha sido considerada recientemente y varios abordajes han sido presentados para resolver el VRPTW: algoritmos paralelos con un número polinomial de procesadores [9], algoritmos genéticos [10, 11, 12, 13], recocido simulado paralelo [14, 15] y colonias múltiples de hormigas [16]. Estos trabajos analizan el problema en cuestión en un contexto mono-objetivo, aunque en algunos casos se proponen priorizaciones y/o combinaciones de objetivos, sin llegar a calcular el conjunto completo de soluciones Pareto. Estudios de las principales heurísticas y metaheurísticas pueden ser encontrados, por ejemplo, en [17] y [18]. Por su parte, el presente trabajo resuelve el problema del VRPTW en un contexto multiobjetivo, considerando dos técnicas evolutivas que han demostrado su capacidad de resolver adecuadamente problemas de similar complejidad:

(1) las optimizaciones con colonias de hormigas (ACO), en la versión conocida como MOACS-VRPTW, propuesta por Barán y Shaerer [19], a partir de una optimización del MACS-VRPTW publicado por Gambardella et al. [16]; y (2) los algoritmos evolutivos multiobjetivos (Multi-Objective Evolutionary Algorithms – MOEAs) en una variante propuesta en este trabajo que daremos en llamar PAES-DRI, obtenida a partir de la propuesta ESDRI presentada por Mester [21].

A conocimiento de los autores, esta es la primera comparación experimental entre un ACO y un MOEA para el problema del VRPTW en un contexto multiobjetivo, en el que los distintos objetivos tienen la misma prioridad [22]. El resto del trabajo es organizado de la siguiente manera: la sección 2 presenta la formulación tradicional del problema, la sección 3 contiene la formulación multiobjetivo, la sección 4 resume el MOACS-VRPTW, la 5 explica el PAES-DRI, la 6 presenta las métricas de desempeño utilizadas para la comparación, mientras la sección 7 presenta resultados experimentales. Finalmente, la sección 8 presenta las conclusiones del trabajo.

2 Formulación Matemática del VRPTW

El VRPTW es un problema combinatorial que puede ser formulado matemáticamente como un grafo dirigido G(V, A). El problema considera un conjunto de vértices

96 RITOS2

{ }nvvvV ,,, 10 K= , donde 0v representa el depósito, mientras que iv (i = 1, ..., n) representa a cada uno de los n clientes (o ciudades) a ser visitados. Por su parte, el conjunto de arcos está dado por: ( ){ }jiVvvvvA jiji ≠∈= ;,/, .

Por su parte, C= { ijc } ∈ ℜ(n+1) x (n+1) es una matriz de distancias o costos no

negativos entre cada par de vértices iv y jv (incluyendo depósito y clientes).

d es el vector de las demandas de los clientes y iq representa la cantidad de

bienes requeridos por el cliente iv . m representa el número de vehículos, que se asumen todos idénticos, y con una

capacidad Q por vehículo. A cada vehículo i se le asignará una ruta iR .

],[ ii le representa la ventana de tiempo del cliente iv ; con ie como la hora más

temprana y il como la hora más tardía en que se puede iniciar el servicio a dicho

cliente iv . Por su parte, iδ representa el tiempo requerido en descargar la cantidad

de mercaderías iq en el cliente iv .

Como el problema aquí considerado es simétrico jiij cc = para cada ( ) Avv ji ∈, y

es común reemplazar A por el conjunto ( ){ }jiVvvvvE jiji <∈= ;,|, . Sin pérdida de

generalidad, y por simplicidad, se asume que el tiempo ijt necesario para ir de iv a

jv es igual a la distancia ijc (se asume velocidad constante e unitaria para los

vehículos). El intervalo [ ]00 , le en el depósito se llama horizonte de planeación (scheduling horizon).

Definiendo vb como el instante de inicio del servicio al cliente v , se puede escribir la condición de factibilidad que debe cumplir una ruta

{ }ik

ik

iii ii

vvvvR 110 ,,,, += K , donde Vvij ∈ , 010 == +

ik

ii

vv (el 0 denota el

depósito) y ik es la cantidad de clientes atendidos en la ruta i :

∑=

≤ik

j

ij Qq

1. (1)

ij

ij

ij vvv lbe ≤≤ . (2)

00,lcb i

ikiik

iik vvv

≤++ δ , con kj ≤≤1 . (3)


Asumiendo que todo vehículo viaja al próximo cliente una vez que haya terminado de servir al cliente actual, i

jvb puede ser calculado recursivamente de la

siguiente manera:

{ }ij

ij

ij

ij

ij

ij vvvvvv

cbeb,111

;max−−−

++= δ , con 00 ebi = y 00 =iδ . (4)

Así, el tiempo de espera en el cliente ijv puede ser definido como:

{ }ij

ij

ij

ij

ij

ij vvvvvv

cbbw,111

;0max−−−

−−−= δ . (5)

El costo de la ruta iR puede estar dado por la duración total de la misma, en cuyo caso estaría definido como:

( ) ∑∑∑===

++=+

i

ij

i

ij

i

ij

ij

k

jv

k

jv

k

jvvi wcRT

010, 1

δ . (6)

Tradicionalmente, el objetivo primario es la minimización del tamaño n de la flota de vehículos y el objetivo secundario es la minimización de la distancia total recorrida (tiempo total de viaje) o la duración total de las rutas (tiempo total de entrega), [17, 18].

3 Formulación del VRPTW como un Problema Multiobjetivo

Como ya fuera discutido, el VRPTW es tradicionalmente formulado como un problema bi-objetivo lexicográfico. En contrapartida, este trabajo utiliza una formulación multiobjetivo presentada en [19]. En este contexto, la función objetivo es un vector tridimensional [ ]TFFFF 321 ,,= , y ningún objetivo es más importante que los otros. Los tres objetivos utilizados son:

• mF =1 ... es el número de vehículos (o tamaño de la flota);

• ∑∑= =

+=

m

i

k

jvv

i

ij

ij

cF1 0

,21

es el tiempo total de viaje (o distancia total recorrida);

• ∑∑ ∑∑= = = =

++=m

i

k

j

m

i

k

jvv

i i

ij

ij

wFF1 1 1 0

23 δ ... es el tiempo total de entrega.

donde ijv denota el cliente servido en el j-ésimo orden de la ruta iR y ik representa el

número total de clientes servidos en dicha ruta iR .

98 RITOS2

Dado que ningún objetivo se considera más importante que los demás, se trata de un contexto realmente multiobjetivo donde en principio, la solución puede no ser única, sino un conjunto de soluciones óptimas, no comparables entre sí, conocido como Conjunto Pareto P. La imagen de P en el contra-dominio de las funciones objetivo es conocida como Frente Pareto FP [22].

4 Algoritmo MOACS-VRPTW

Barán y Schaerer [19] propusieron una variación del Algoritmo de Colonias Múltiples de Hormigas para el VRPTW (MACS-VRPTW), originalmente propuesto por Gambardella y otros [16]. Esta variación fue denominada Colonia de Hormigas para Optimización Multiobjetivo del VRPTW (MOACS-VRPTW). Esta metaheurística utiliza una sola colonia de hormigas para minimizar simultáneamente las tres funciones objetivo, presentadas en la sección anterior. Todas las funciones comparten los mismos rastros de feromonas. De esta manera, el conocimiento de buenas soluciones es igualmente importante para cada función objetivo. El referido MOACS-VRPTW puede ser resumido con el siguiente pseudocódigo: Pseudocode MOACS-VRPTW /* Inicialización */ Repeat /* Loop principal */ for each ant k ∈ {1,…, m} do Construir una solución (ψk)

if ψk ∈ P /* si solución encontrada forma parte del conjunto Pareto */

grabar ψk y borrar soluciones dominadas de P end if end for /* Actualizar feromonas τ */ if τ0’ > τ0 /* Un mejor FP ha sido encontrado */ Reinicializar rastros {τ} con τ0 else for each ψP∈ P do Actualización global de feromonas end for end if until criterio de parada ha sido satisfecho.

5 Algoritmo PAES-DRI

El presente trabajo, propone una nueva variante de MOEA que damos en llamar PAES-DRI, inspirada en el ES-DRI originalmente propuesto por Mester [20]. El ES-DRI (Evolutionary Strategy - Dichotomy Remove-Insert) es un algoritmo heurístico muy efectivo para determinar la solución de versiones en gran escala del VRPTW.


Este algoritmo esta basado en las ideas de estrategias evolutivas (1+1) y algunos operadores de mutación que trabajan con un esquema dicotómico de remover-insertar. Por su parte, el PAES (Pareto Archived Evolutionary Strategy) [23] es un esquema simple de evolución para problemas multiobjetivo. Este algoritmo es una estrategia evolutiva (1+1) que utiliza búsqueda local en una población de un individuo, pero usando un archivo de referencia de soluciones previamente encontradas a fin de identificar el ranking de dominancia aproximado de las soluciones actual y candidata. El PAES-DRI puede ser resumido con el siguiente pseudocódigo: Pseudocode PAES-DRI /* Inicialización. */ Obtener una solución actual Inicializar aleatoriamente R con 1 o 2 Inicializar β con la ecuación (8)

inicialactual ← /* Inicializar solución actual */ Repeat /* Loop principal */ ),,( βRactualmutarcandidata ← /*obtener candidata mutando

solución actual */ If candidataactual f /* si actual es mejor */ actualcandidata ← End if )(_ candidatalocalónoptimizacicandidata ← If candidataactual f /* si actual es mejor */ Descartar candidata Cambiar aleatoriamente parámetros mutación Else if actualcandidata ≥ /* candidata no es peor */ candidataactual ← Agregar candidata a conjunto Pareto P Eliminar soluciones dominadas de P

else /* candidata es dominada por algún miembro del conjunto Pareto P */

Descartar candidata endif Endif Until un criterio de parada ha sido alcanzado.

Considerando que esta variante está siendo propuesta en este trabajo, se la

describirá en mayores detalles en las siguientes subsecciones, de forma a conocer los elementos que conforman este algoritmo.

5.1 Solución inicial

La inicialización de la población es realizada utilizando una heurística basada en la inserción más económica [24]. Las rutas son construidas una a la vez en forma secuencial. Para esto, es necesario determinar los nodos que inicialicen las rutas.

100 RITOS2

Estos nodos son denominados nodos semillas (seed nodes). Primero se determinan los cuatro nodos primarios (PC). El primer nodo es el cliente más lejano al depósito y los siguientes tres son determinados encontrando un nodo que se encuentre geográficamente lo más alejado posible de los clientes previamente seleccionados y del depósito. Luego, de forma similar se seleccionan cuatro nodos secundarios (SC) utilizando los nodos primarios. Como los nodos primarios forman un cuadrilátero, los nodos secundarios son los clientes más cercanos al punto medio de cada lado del mismo. Finalmente, se selecciona un conjunto T de los n clientes más alejados del depósito.

Una vez conformados los conjuntos PC, SC y T, se selecciona un cliente del nodo PC que esté más alejado del depósito, como el inicio de la primera ruta. El siguiente nodo semilla que inicialice la próxima ruta deberá ser seleccionado del conjunto

SCPCTI ∪∪= de manera que sea el cliente no enrutado más cercano al primer nodo semilla. Finalmente, si no existen clientes no enrutados en I, el siguiente nodo semilla es el cliente no enrutado con el menor índice (los clientes son indexados de 1 a n, donde n es el número total de clientes).

Una vez determinado el nodo semilla de la ruta en formación, se selecciona el cliente no enrutado que minimiza la combinación ponderada del detour y el tiempo de espera y se lo incorpora en el mejor lugar factible de inserción. Para la inserción se consideran solamente los clientes más cercanos geográficamente a por lo menos uno de los clientes previamente insertados en la ruta. Se considera que un cliente es geográficamente cercano a una ruta, si la distancia del cliente a algún cliente previamente insertado en la ruta es menor o igual a una constante d . De esta manera, después de cada inserción es necesario actualizar el conjunto de los nodos cercanos a la ruta parcial actual.

La función de costo de inserción de un cliente uv está dada por:

uuuu cWDC 0321 ααα −+= . (7)

donde,

ijujiuu cccD −+= . (7.1)

bu

auu WWW −= . (7.2)

121 =+ αα ; 03 >α . (7.3)

Las distancias entre los correspondientes pares de clientes ( )ui vv , , ( )ju vv , y

( )ji vv , son denotados por iuc , ujc y ijc respectivamente. Además auW y

buW corresponden el tiempo total de espera antes y después de la inserción,

respectivamente.


5.2 Operador de mutación

Tal como se había mencionado con anterioridad, el PAES-DRI es una variación del ES-DRI [20]. El operador de mutación utilizado en dicho trabajo genera una nueva solución removiendo e insertando β clientes de la solución actual para obtener la solución candidata. Este procedimiento genera nuevas rutas factibles en un proceso de dos fases que construye y mejora nuevas soluciones. El número de clientes a ser removidos de la solución actual es determinado conforme a la ecuación:

( )nrnd5.01.0 +=β . (8)

donde n es siempre el número total de clientes y rnd es un número generado aleatoriamente y distribuido uniformemente entre 0 y 1.

Los clientes removidos forman un conjunto denominado reject. Los clientes no removidos de la solución actual forman una solución parcial denominada remnant. Los clientes a ser removidos son determinados de dos maneras (el tipo de remoción está definido por la variable R, que es seleccionada aleatoriamente). La primera, consiste en remover β clientes en forma aleatoria. Para realizar este procedimiento asignamos a R el valor de 1. La segunda, que corresponde a 2=R , realiza remociones aleatorias de los clientes ubicados geográficamente en el interior de un anillo creado con dos círculos concéntricos con centro en el depósito y radios aleatorios.

Después de remover los clientes de la solución actual se procede a insertarlos en la solución remnant para obtener una solución candidata factible. La inserción se realiza en forma secuencial hasta que no queden nodos sin insertar. Se ordenan los nodos de reject en forma aleatoria y se los inserta uno por uno. Para insertar un cliente uv se determinan todos los lugares factibles de inserción y se halla para cada uno de ellos el costo de inserción de acuerdo a la una función vectorial [ ]uu TD , . Para hallar uD utilizamos la ecuación (7.1) y uT es definido como sigue:

uuu WDT += . (9)

donde uW es calculada con la ecuación (7.2). Como la función de inserción tiene dos dimensiones, se determinan todas las opciones de inserción que no son dominadas y se selecciona una al azar. Cada n1.0 inserciones se realizan procedimientos de optimización local de la solución parcial obtenida. Para esto también se utiliza el criterio multiobjetivo arriba mencionado.

Si la solución candidata, obtenida con el operador de mutación, domina a la solución actual, los mismos parámetros de mutación son aplicados a la nueva solución actual. Si no, para generar una nueva solución candidata, el algoritmo utiliza otros parámetros de mutación. Este tipo de operador de mutación es denominado “Dichotomy Remove-Insert“. Después de la mutación, la solución candidata es mejorada con procedimientos combinatorios de complejidad ( )2nO como por ejemplo:

102 RITOS2

(i) Or-Opt [25], o

(ii) 1-interexchange [26].

En cuanto a la búsqueda local, se utiliza el criterio multiobjetivo explicado anteriormente para decidir si se acepta o no una nueva solución.

6 Métricas de desempeño

Para evaluar los resultados experimentales de los dos algoritmos arriba presentados, se seleccionaron tres métricas, considerando que no existe una única métrica que pueda por sí sola medir el desempeño, eficiencia y efectividad de los algoritmos evolutivos multiobjetivos [22]. Las métricas utilizadas para el presente trabajo son las siguientes:

• Overall Non-dominated Vector Generation (ONVG): simplemente cuenta el

número de soluciones en el Frente de Pareto calculado, denotado como

knownY

cknownYONVG ||∆

= . (10)

donde c denota cardinalidad. A mayor valor del ONVG, se tiene un mejor

conocimiento de los detalles del Frente de Pareto.

• Overall True Non-dominated Vector Generation (OTNVG): cuenta el número de soluciones en Yknown que también se encuentran en el Frente de Pareto Óptimo denotado como Ytrue. Como Ytrue no es conocido en teoría, debe estimarse haciendo muchas corridas de diversos algoritmos multiobjetivos para el mismo problema, escogiendo las soluciones Pareto óptimas encontradas con la unión de los resultados obtenidos con todos los experimentos. Claramente, un mayor valor de OTNVG, indica que un conjunto Yknown es mejor que otro.

{ }ctrueknown YyYyyOTNVG ∈∧∈=

∆. (11)

• Coverage (C): cuenta el número de soluciones del Frente de Pareto de un

algoritmo 1, denotado como Yknown1, que son dominadas por alguna solución del Frente de Pareto del Algoritmo 2 (Yknown2). Lógicamente, al comparar dos algoritmos, el que tenga un menor valor de C, será superior.


7 Resultados Experimentales

El MOACS-VRPTW ha sido implementado en una computadora personal, corriendo un sistema operativo UNIX y utilizando el lenguaje C. El PAES-DRI ha sido implementado en MATLAB sobre un sistema operativo Windows 98. Los resultados presentados a continuación pertenecen al conjunto de datos (problema tipo), publicado en [2] con la denominación de “R101“ . Los parámetros utilizados en la implementación del PAES-DRI son 7.01 =α , 3.02 =α , 5.03 =α , escogidos en forma experimental sin hacer un ajuste fino de sus valores óptimos para este problema.

Se han realizado cinco corridas de cada algoritmo, formando los Frentes Pareto

YMOACS y YPAES-DRI . Como no se conoce la solución teórica óptima del problema, se aproximó Ytrue. mediante la unión de todas las soluciones obtenidas por los investigadores, utilizando los 2 algoritmos que se están comparando, y eliminando de este conjunto las soluciones dominadas.

Cabe destacar que el tiempo medio de ejecución del PAES-DRI fue de 4 horas 20

minutos, considerablemente mayor al tiempo de 1 hora 5 minutos, utilizado para la ejecución del MOACS-VRPTW, lo que en parte puede justificar los excelentes resultados obtenidos con el PAES-DRI, propuesto en este trabajo.

En la Tabla 1 se pueden observar los resultados experimentales que demuestran

experimentalmente que el PAES-DRI obtiene en general mejores soluciones (ver métricas OTVGN y C) pero sin llegar a encontrar la misma variedad de soluciones que el MOACS-VRPTW, que resulta superior si se considera la métrica ONVG, y sobre todo, el tiempo requerido para encontrar buenas soluciones Pareto.

Tabla 1. Métricas de desempeño para los dos algoritmos comparados en el presente trabajo.

Algoritmo ONVG OTVNG C

MOACS-VRPTW 12 0 12

PAES-DRI 5 5 0

En efecto, la Tabla 1 muestra que el MOACS-VRPTW obtiene un mayor número de soluciones no dominadas, pero todas estas soluciones terminan siendo sub-óptimas, pues a su vez son dominadas por las soluciones obtenidas con el PAES-DRI, que en todos los casos pertenecen al frente de Pareto óptimo. Es decir, todas las soluciones del MOACS-VRPTW son dominadas por el PAES-DRI.

104 RITOS2

7 Conclusión

El problema del ruteo de vehículos con ventana de tiempo va ganando importancia en la medida que el mundo globalizado fuerza a las empresas distribuidoras modernas a ser cada vez más eficientes e incrementar su región de trabajo, para mantenerse competitivas. Como natural consecuencia, crece el interés en el área y se van proponiendo nuevos abordajes, entre los que se destacan los algoritmos evolutivos, por su flexibilidad para analizar circunstancias cambiantes y objetivos contradictorios. A raíz de esto, resulta interesante comparar las nuevas alternativas que se van proponiendo para lograr aplicar el abordaje más adecuado a cada realidad.

Es en este contexto que el presente trabajo propone una variante de algoritmo

evolutivo multiobjetivo y realiza por primera vez una comparación entre un sistema de colonias de hormigas y una estrategia evolutiva para el problema del ruteo multiobjetivo de vehículos con ventanas de tiempo.

Los experimentos demuestran que aunque el MOACS-VRPTW obtenga mayor

cantidad de soluciones no dominadas, todas éstas son a su vez dominadas por las soluciones obtenidas por el PAES-DRI, pero esta superioridad se ve opacada por el hecho de requerir un mayor tiempo de ejecución (en el orden de 4 veces, en las experiencias reportadas). En consecuencia, a pesar de que el MOACS-VRPTW no encuentra soluciones de la misma calidad que el PAES-DRI, todavía es razonable su utilización cuando es suficiente obtener buenas soluciones sub-óptimas en un tiempo más limitado.

Como los resultados aquí reportados no son totalmente conclusivos, los autores se

encuentran trabajando en pruebas más exhaustivas, con problemas más grandes y con diversas variantes de algoritmos evolutivos multiobjetivos, con el objeto de reconocer claramente las circunstancias en que cada abordaje presenta sus mejores propiedades, dado que no es posible encontrar un único abordaje que presente soluciones igualmente favorables en todas las instancias del problema.


Referencias

1. Bodin, L. Golden, B., Assad, A. y Ball, M. Routing and Scheduling of Vehicles and Crews (1983). The State of the Art. Comput. Opns. Res. 10, 62-212.

2. Salomon, M.M. Algorithms for Vehicle Routing and Scheduling Problems with time window constraints. Northeastern University, Boston, Massachusetts, December 1985.

3. Lau, K.K., Kumar, M.J. y Achuthan, N.R. Parallel implementation of branch and bound algorithm for solving vehicle routing problem on NOWs. 3rd Internationl Symposium on Parallel Architectures, Algorithms, and Networks, 1997, 247-253.

4. Pedroso, J.P. Niche search: An application in vehicle routing. IEEE World Congress on Computational Intelligence, 1998, 177–182.

5. Yoshiike, N.y Takefuji, Y. Vehicle routing problem using clustering algorithm by maximum neural networks. 2nd International Conf. on Intelligent Processing and Manufacturing of Materials, 2, 1999, 1109–1113.

6. Gomes,L. y von Zuben, F.J. A neuro-fuzzy approach to the capacitated vehicle routing problem. Int. Joint Conference on Neural Networks, 2, 2002, 1930-1935.

7. Murao, H., Tohmata, K., Konishi, M. y Kitamura, S. Pheromone based transportation scheduling system for the multi-vehicle routing problem IEEE Int. Conference on Systems, Man, and Cybernetics, 4, 1999, 430–434.

8. Takeno, T., Tsujimura, Y. y Yamazaki, G. A single-phase method based on evolution calculation for vehicle routing problem. 4th Int. Conf. on Computational Intelligence and Multimedia Applications, 2001, 103–07.

9. Gupta, A. y Krishnamurti, R. Parallel algorithms for vehicle routing problems. Fourth International Conference on High-Performance Computing, 1997, 144-151.

10. Louis, S.J., Xiangying, Y. y Zhen, Y.Y. Multiple vehicle routing with time windows using genetic algorithms. Congress on Evolutionary Computation, 1808(3), 1999.

11. Maeda, O., Nakamura, M., Ombuki, B.M. y Onaga, K. A genetic algorithm approach to vehicle routing problem with time deadlines in geographical information systems. International Conference on Systems, Man, and Cybernetics, 4, 1999, 595-600.

12. Chin, A., Kit, H. y Lim, A. A new GA approach for the vehicle routing problem. 11th IEEE International Conference on Tools with Artificial Intelligence, 1999, 307-310.

13. Tan, K.C., Lee, T.H., Ou, K. y Lee, L.H. A messy genetic algorithm for the vehicle routing problem with time window constraints. Congress on Evolutionary Computation, 1, 2001, 679-686.

14. Arbelaitz, O., Rodriguez, C. y Zamkola, I. Low cost parallel solutions for the VRPTW optimization problem. Fourth International Conference on Parallel Processing Workshops, 2001, 176-181.

15. Czech, Z.J. y Czarnas, P. Parallel simulated annealing for the vehicle routing problem with time windows. 10th Euromicro Workshop on Parallel, Distributed and Network-based Proc., 2002, 376-383.

16. Gambardella, L., Taillard, E. y Agazzi, G. News ideas in optimization. Mac Graw-Hill, London 1999, 73–76.

17. Bräysy, O. y Gendreau, M. Route construction and local search algorithms for the vehicle routing problem with time windows, Report STF42 A01024, App. Mathematics, Dep. of Optimization, Norway. 2001.

18. Bräysy, O. y Gendreau, M. Metaheuristics for the vehicle routing problem with time windows, Internal Report STF42 A01025, SINTEF Applied Mathematics, Department of Optimization, Norway. 2001.

106 RITOS2

19. Barán, B. y Schaerer, M. "A multiobjective Ant Colony System for Vehicle Routing Problem with Time Windows". Proceedings of the 21st IASTED International Conference APPLIED INFORMATICS. Innsbruck, Austria. 2003.

20. Mester, D. "The Parallel algorithm for Vehicle Routing Problem with Time Windows restrictions". Scientific Report, Minerva Optimization Center, Technion, Israel. 1999.

21. Mester, D. An evolutionary strategies algorithm for large scale vehicle routing problem with capacitate and time windows restrictions, Institute of Evolution, Mathematical and Population Genetics, Univ. of Haifa, Israel. 2002.

22. Van Veldhuisen, D. A. Multiobjective Evolutionary Algorithms: Classifications, Analyses and New Innovations. PhD thesis, Department of Electrical and Computer Engineering. Graduate School of Engineering. Air Force Institute of Technology. Ohio, USA. May, 1999.

23. Knowles, J. and Corne, D. The Pareto Archived Evolution Strategy: A New Baseline Algorithm for Pareto Multiobjective Optimisation. Dept. of Computer Science. University of Reading. UK. 1999.

24. Bräysy, O. A reactive variable neighborhood for the Vehicle Routing Problem with Time Windows. 2001. To appear in Informs Journal on Computing.

25. Or, I. Traveling Salesman-Type Combinatorial Problems and their Relation to the Logistics of Regional Blood Banking, Ph.D. thesis, Northwestern University, Evanston, Illinois. 1976.

26. Osman, I.H. Metastrategy simulated annealing and tabu search algorithms for the vehicle routing problems, Annals of Operations Research 41, 421−452. 1993.


A System for the Integrated Access to Digital Libraries

Nieves R. Brisaboa, Miguel R. Penabad, Ángeles S. Places, Francisco J. Rodríguez

Departamento de Computación. Facultade de Informática Universidade da Coruña

{brisaboa, penabad, asplaces, franjrm}@udc.es

Abstract. There has been lately much effort put on the creation of digital libraries containing antique documents, in order to preserve our cultural heritage and provide a broader access to them, but they are usually isolated one from another. This work presents a system, based on the use of XML trees, to federate three existing digital libraries that contain documents from the Spanish Golden Age (16th-18th centuries). This federation offers very valuable advantages to a wide community of researchers, who will be able to access (at present time, three) databases of historic documents through a unique entry point.

Keywords. Digital Library Federation, XML trees, User Interfaces.

1 Introduction

Internet has become one of the most important places to publish any kind of information. It is especially important if we consider documents such as antique books, manuscripts, or any other element of our documental heritage, because their publication using the usual methods is too expensive and not economically viable, These documents are kept in museums and libraries with historical archives with very restricted access, so their Web publication serves two purposes: offering them to the research community, and preserving them. These documents, besides their great beauty, are a magnificent source of information about different cultures like the Spanish Baroque. Through the analysis of these works, researchers can find information about morality, habits, technology, education, or other aspects that are of interest for a wide range of researchers, including for example Anthropologists, Historians, or Philologists. Additionally, and no less important, it helps the preservation of the documents, preventing them from disappearing due to their antiquity and fragility.

With these two goals, much effort has been put to publish these documents on Internet, usually in the form of documental databases or digital libraries. We have

This work was partially supported by CICYT, grants TEL99-0335-C04-02 and

TIC2002-04413-C04-04.

created two of them, one for Spanish Emblem Books [2] and one for Early Spanish Press [10]. However, it is common that these digital libraries are isolated, thus making it difficult to jointly use several (often closely related) sources of information. As for our libraries, they are already available on Internet by using separate interfaces.

In order to augment their potential usefulness, it would be desirable to have a system for the users to access, through a unique interface, all available corpora. There has been a lot of effort on the field of database federation [7,11,12]. There are also works especially focused on the federation of documental databases [8]. However, these works lack some aspects we consider crucial. As they only federate databases, they do not consider the user interface, which is important for us to provide a unique Web access point. Specific aspects about documental databases, such as the exploitation of the available Text Retrieval techniques on each database are also usually ignored.

We have built a federated system that considers these aspects, focusing specifically on federating digital libraries, keeping their text retrieval capabilities, and also giving special importance to the user interface to access them. Our system integrates our two digital libraries (their underlying databases), plus a new one containing non Spanish Emblem Books that were translated into Spanish in this period because of their importance. These emblem books were very popular at the time, so their study is very interesting, because they inspired other Spanish authors to write their own emblem books. This system is already functional, but it will be available through Internet only when the database of Translated Emblem Books is completed.

The federated system offers a unique access point to browse through the documents or perform searches. This interface has been developed following some guidelines that will make it intuitive and easy to use, yet powerful and flexible enough to respond to queries over any (or all) databases in the system. This federated system was initially built ad hoc for these databases; however, the design of its architecture allows us to extrapolate the ideas we used to build it, so they can be used to federate any set of documental databases. These ideas are based on the requirements that any federated system must meet: scalability (increasing the number of databases in the federation should not decrease the overall system efficiency), easy adaptation to changes (adding, dropping or modifying databases must be easy and quasi-automatic) and user-friendliness. In order to build a system that meets these requirements, we based our work on the use of a layered structure, and the use of XML trees to perform the schema conciliation of the databases and to help building the user interface.

The rest of this paper is organized as follows. Section 2 describes the three databases included in our federation, showing their interest and how we manage them. Section 3 describes the XML trees and how we use them to help integrating the different databases and building the user interface. Section 4 offers an overview of the architecture of the system. The implementation of the system is described in Section 5, and the last section offers our conclusions.

110 RITOS2

2 Description of the Databases

We are currently working with three databases that store information about Literature from the 16th-18th centuries: Spanish Emblem books, Early Spanish Press (Relaciones de Sucesos), and Non-Spanish Emblem books translated into Spanish at that time. They are two large databases that store digitized pages as well as transcriptions, enriched with a huge amount of information coming from the analysis of the documents by experts on History of Art and Hispanic and Latin Philology.

The first two databases correspond to Literature written in Spanish, from the Spanish Golden Age (“Siglo de Oro”) and are already available through the Web; the third one stores emblem books that originally appeared in non-Spanish languages (Italian, Latin, or other European languages), and were translated into Spanish during that period. This last database is still being populated and will also be available soon.

Emblem Literature was basically a moral literature, trying to promote moral and ethical norms as well as ideas and concepts about morality in general. Emblem books were formed by emblems, which are types of ideograms that expressed an abstract idea through a picture, accompanied by a motto containing the moral principle. The idea was further explained by an epigram or short poem and a commentary.

The Spanish Emblem Books database [2] stores information for 27 emblem books, containing more than 1800 emblems. These emblems lead to a thesaurus of about 15000 authorities, 7000 exemplas, 16000 onomastics, and 10000 sources for the images. Likewise, we offer about 6500 digitized pages. We have not yet reliable information about the quantity of information available for the last database, Translated Emblem Books, because we are still populating it.

Spanish early press documents (“Relaciones de sucesos” in Spanish) come from the 15th-17th centuries, and were the precursor of the current journalism. They related an event with the goal of informing and entertaining the public. According to the subject of the story, there were different types of reports, like Festive events, such as monarchic or religious events, extraordinary events like miracles or strange events (the current sensationalist press), or Bullfight events, predecessor of the sports press.

The Early Spanish Press database [10] stores information about these reports, including catalogues of reports, thesauri of epithets, illustrations, the different editions of a given report, and the libraries where they can be found nowadays. The digitized pages of all available reports are also stored in the database. The current content of the database includes information about more than 1800 reports, with 280 illustrations, and a thesaurus of about 1000 epithets used in them. There is also information about the 22 libraries where the original reports can be found.

All the works considered in these databases constitute a very rich and complex source of information related to the customs of those centuries in Europe in general and in Spain in particular, because they provide data about society, morality, customs, news, knowledge and conventions. A characteristic, common to all these works, is that they are very useful to a wide range of researchers from a variety of disciplines (History of Literature, History of Art, Anthropology, Sociology, Philology, etc.).


3 System Overview

The architecture of our system is based on the use of XML files, named Concept Trees and Mapping Trees, that store key information that controls how all modules of the system work. Concept Trees representing all relevant “searchable” concepts of the component databases are used to help the user build the query. Each underlying database has a Mapping Tree that is used to translate the query to the appropriate database query language.

3.1 Architecture of the System

The architecture of the system described in this paper is composed of four separate layers. The communication among them is carried out by using two exchange, intermediate languages, exclusively defined for this purpose. This architecture, shown in Fig. 1, is fully described in [6]. What follows is only a brief overview:

UI components

Query Interface Answer Interface

Mappings

Component DBs

Database of Emblem Books

Query Translator

Mappings

Query Translator

Mappings

Query Translator

Database of Early Spanish Press

Database of Translated Emblem

Books

Query Interface

Generator

Presentation Manager

Query Builder and Distributor

Answer Issuer

Answer Issuer

Answer Issuer

Concept Tree

Query Flow Answer Flow

Layer 2: Mediator

Layer 1: User Interface

Layer 3: Wrappers

Layer 4: Databases

Fig. 1. Architecture of the System

1. Layer 1. User Interface: The user interface is generated every time a user accesses the system, so it is not a real layer of the architecture. However, we represent it as a (conceptual) layer in order to properly describe the interaction of the users with our system, because all interactions (queries and answers) are made through the user interface.

112 RITOS2

2. Layer 2. Mediator: The Mediator generates the user interface following the Concept Tree, as we shall see in the next section. After the user expresses his query, the Mediator analyses and redirects it to the Wrappers of the databases involved in that query. After the query is executed in the pertinent databases, the Mediator shows the user an answer Web page with a summary of the results obtained from the databases, as well as the appropriate links to the answer interfaces of these digital libraries, so users can navigate through the obtained documents.

3. Layer 3. Wrappers: Every Wrapper is associated to a particular database. Its tasks are to query it and retrieve the answers. For these purposes, this layer uses the Mapping Tree of the database. Although all the Wrappers perform similar tasks, they need to be adapted to the specific associated database.

4. Layer 4. Documental Database: The databases that can be integrated in our system are preexisting and independent of it. Moreover, in our case we have that two of the three considered databases are currently available through Internet, with a particular user interface that enables to use them as Digital Libraries. The fact of federating these Digital Libraries in our system does not mean that they cannot answer other queries coming from their own interface. Likewise, we must note that if a database has Text Retrieval capabilities, our system is capable of exploiting them, but any needed preprocess (such as indexing) has to be already performed and those Text Retrieval techniques have to be already implemented. That is, managing the databases is not a task of our system.

3.2 Trees

The execution of all the modules in our architecture is guided by the information stored in a set of XML files, denoted Trees here because or their hierarchical representation. All Trees are composed of nodes that represent “searchable” concepts existing in the databases. That is, not all concepts of a database, but only those that can be used to perform searches, are included. These concepts are described by properties or attributes, and arranged in a tree in order to represent the relationships among them. For our domain of interest, digital libraries, we have considered relevant only the following two types of relationships: − Generalization/Specification: It represents the typical “is a” relationship. For

instance, a “Work” is a “Thesis”, a “Book” or a “Journal”. − Description: It can be represented as a “has” relationship. It is used to represent

that a concept is described by other (sub)concept. For example, a Work “has” an Edition, which in turn is described by the attributes “Year of edition”, “Publisher”, and “Promoter”. We deal in our system with two types of trees, designed for two different

purposes: Concept Trees, which are placed in the Mediator, and Mapping Trees, which are placed in the Wrappers (see Fig. 1):

− Concept Trees: They are abstractions of the schemas of all component databases. The root concept of these trees is the object (concept) that can be retrieved by a query. There will be as many concept trees as different concepts can be retrieved.


When the user expresses a query, he must decide which concept wants to retrieve, selecting the Concept Tree that will be used to express the query. This type of tree is used to generate the user interface, offering the user to navigate through all the concepts on it, or to establish the query constraints for any of them. Thus, each attribute has associated the different ways a user can establish the search conditions for the attribute. Depending on each case, it can be a Bounded Natural Language [4, 5] sentence, or a Cognitive Metaphor [4], as we shall see in Section 4.1. If the attribute describes a characteristic with a finite number of possible values, the list of values is also stored. For example, for the “Stanza” attribute in the Concept Tree of Fig. 2. This attribute stores the list “Quatrain, Sonnet, Tercet …” with all the possible values for this attribute.

− Mapping Trees: A Mapping Tree is defined for each documental database, and describes only the concepts of its associated database. Every concept and attribute in a Mapping Tree has associated the expression necessary to access the corresponding data in the associated database, which is completely dependant on the database DBMS. For example, a concept represented in a Mapping Tree for a relational database can have the relation and attribute names where the concept is stored, or a more complex expression, like a complete SQL SELECT statement. If the database is capable of using some kind of Text Retrieval technique, the information associated to a concept like “content” or “topic” will be the directions to call the Text Retrieval algorithm implemented in the database. Table 1 shows the XML fragment of the Mapping Tree for the Emblem Book database that shows the mapping information associated to the attribute “Topic”.

Emblem Book Title

Edition

has

Publisher

Year Place

Author

PrinterPromoter

Emblem

TextType

Epigram TextMotto

verseStanza

Number of verses

Language

Motif Image Commentary

Summary

Keywords

has

Onomastics

Authority

Authority

Exempla

Object

Work Title

Topic Year

Author

Publishing Place

is a

Early Spanish Press Report Title

Edition

has

Publishing

Year Place

Author

Printer

Binding Copy

Library

has

PlaceYear of event

TipologySubgenus

oWriting style

Name

has

Exlibris

Translated Emblem Book Title

has

Author

...

<concept name=“Work”> ... <attribute name=“Topic”> <ui>ske1.jsp</ui> <db>1</db><db>2</db><db>3</db> ... <isa> <ui>library.jsp<ui> <concept name=“Work”> ... <concept name=“Emblem Book”> ...

Fig. 2. A Concept Tree

114 RITOS2

4 Implementation of the System

4.1 Query Interface Generator

We believe the user interface is a crucial aspect for the success of any Web system. Therefore, our architecture is highly concerned about the design of an intuitive, friendly and easy to use interface. We have proposed in [4] the following three techniques to design user interfaces that, being combined and systematically used, can guarantee the success of the interface: − Use of Cognitive Metaphors [4]: Web pages are built taking elements from the

real world. This technique is widely used, not only for the design of Web pages but for any computer interface.

− Use of Bounded Natural Language [4, 5]: It consists on offering the user a set of natural language sentences with gaps. The user must choose the sentences of interest and fill the gaps on them in order to express the query.

− Navigational Approach [4]: The main idea is to present the user a single query interface, where the user can obtain a first set of results. From these results the system will allow the user to navigate through them and obtain information about the items that he clicks. So, instead of a form full of text fields to express the constraints of the attributes to build a query, and when it is possible, this approach makes available the possible values of these attributes and allows expressing the constraints (refining the query) with simple clicks. Also, showing the answers sorted by some attribute, the user can select one value without previous knowledge of it, and browse and locate the results of interest. We also believe that having several complexity levels for different user profiles is

very useful, so we offer unsophisticated interfaces to allow expressing simple queries for general users, and slightly more complicated interfaces to allow experts expressing more complex queries.

The Query Interface Generator offers the user a “controlled” natural language (Bounded Natural Language or BNL) or Cognitive Metaphors (applying or not the Navigational Approach) to express the queries. The Query Interface Generator dynamically builds the query interface using the Concept Trees, providing the user with the mechanisms to express conditions over attributes, and to navigate through the Concept Tree to choose the attributes the user is interested in.

Basically, it takes as its first input the root concept of the Concept Tree previously selected by the user, and operates depending on the concept. If the concept has a specialization (an “is-a” relationship), the appropriate procedure allows the user to choose one of its specializations or work with the general concept without considering its specializations. The query interface generated to perform this selection is based on a sentence in BNL or, if it exists, on the Cognitive Metaphor associated to the is-a relationship. If the relationship is a Description relationship (has), it offers the user the possibility of considering as many attributes and subconcepts as the user wants, thus going down the Concept Tree. Again the interface is generated by using a sentence in BNL or the cognitive metaphor associated to the “has” relationship.


Finally, the Query Interface Generator permits to establish restrictions over the chosen attributes. To do this, the Query Interface Generator shows the user the Bounded Natural Language or the Cognitive Metaphor associated to these attributes in the concept tree.

4.2 Query Builder and Distributor

As the user is expressing the query, by navigating through the concepts on the Concept Tree, the query is being internally stored as an XML document. Depending on the considered concepts, the query can be sent to all the Wrappers or only to one of them. In the example that follows, the whole XML query will be sent to the Wrappers of all the databases in the federation because all databases are involved. If the user had chosen “Emblem Book” in the first step, the query would consider only concepts in the Emblem Book subtree and that query would be sent only to the Emblem Book database. An example of a XML query is shown in Table 2 (a).

4.3 Query Translator

XML queries must be translated into the language of each database (in our case, all of them use SQL). To carry out this task the Query Translators read the XML query and take, for each concept or attribute, the fragment of the SQL statement (stored in the associated Mapping Tree) needed to translate the condition over that concept or attribute.

Recall that Table 1 shows a fragment of the Mapping Tree for the Emblem Book database, which will be used to translate the XML query of the Table 2(a). There, the mapping tag can be distinguished for the attribute “Topic”. Notice that each mapping is made up of other three elements named by select, from and where tags. These elements contain the fragments to be added to corresponding part of the final SQL statement.

Table 1. Fragment of Mapping Tree for the Emblem Book Database <attribute name=“Topic”> <mapping> <where>#limit# = (select count(*) from clave cl where em.cod_obra = cl.cod_obra and em.cod_emblem = cl.cod_emblem and cl.clave like #value#</where> <optional end=“)”>and cl.clave like #value#</optional> </mapping> </attribute>

Different degrees of gray in Table 2 depict the process followed by the Query

Translator of the Emblem Book Query System to build the final SQL statement. Each degree indicates a fragment of XML and its corresponding SQL.

Table 3 shows the final SQL Early Spanish Press database. The process of building these two SQL queries is similar to the one for Emblem Literature database. Since the Spanish Press database is managed by Oracle 9i, which has text retrieval capabilities, the SQL query includes a “Contains” clause. This clause is offered by the

116 RITOS2

Oracle interMedia package included in Oracle since version 8i and allows for different types of text retrieval searches.

Table 2. XML query and the generated SQL for the Emblem Literature database

(a) XML (b) SQL <query> <concept=“Work”> <attribute=“Topic”>

<contains limit=“5”/> <value cons=“sin”/> <value cons=“cleric”/> <value cons=“Inquisition”/> <value cons=“stake”/> <value cons=“witch”/>

</attribute> <attribute=“Year”>

<between/> <value cons=“1500”/> <value cons=“1650”/>

</attribute> </concept> </query>

select cod_obra, cod_emblem from obra ob, emblema em, edicion ed where ob.cod_obra = em.cod_obra and ed.cod_edic = ob.cod_edic and 5 = (select count(*) from clave cl where em.cod_obra = cl.cod_obra and em.cod_emblem = cl.cod_emblem and (cl.clave like “sin” or cl.clave like “cleric” or cl.clave like “Inquisition” or cl.clave like “stake” or cl.clave like “witch”)) and (ed.cod_edic >= 1500 and ed.cod_edic =< 1650)

Table 3. Query to Early Spanish Press database select tituloabre, cod_edic from relacion rel, edicion ed where rel.tituloabre = ed.tituloabre and contains(rel.titulo, ‘sin & cleric & inquisition & stake & witch’, 10) > 0 and (rel.fecha_acon >= 1500 and rel.fecha_acon =< 1650)

4.4 Presentation Manager

The Presentation Manager displays the first answer page just when the Builder and Distributor Module sends the query to the appropriate wrappers. This Web page presents the list of digital libraries where the query is to be executed. For each digital library, the following attributes (using unqualified Dublin Core fields) are specified: the name or title of the database; a description of the data stored in the database; a surface address, a telephone number or a contact e-mail; the date of the last update; the main URL of the digital library; and the query that is to be executed in the database (it is possible that the database does not include some of the concepts appearing in the query).

This Web page is updated as the Presentation Manager receives (from the Answer Issuer) the summary of the results obtained from the databases, showing for each digital library the number of results that match the query. Once this answer is obtained, users can access each of the digital libraries to display the documents matching his/her query, using the digital library’s own interface.

Note the difference between the queries and the answers: while queries are performed in an integrated way, answers are always displayed using the digital libraries own interface. The main reasons that lead us to take this decision are the following:


− The answer interface of each one of the digital libraries is specifically designed for its data (see, for example, the Emblem Literature answer interface [2]). Therefore, those answer interfaces will always be more intuitive and user friendly than any other interface we can build to display (in an integrated way) the results from the databases.

− The federated databases are heterogeneous, so there will not appear, in any case, duplicates of the results obtained from any query coming from different databases. There is another reason for this decision, even when it does not happen in our

system (because we have also built each independent digital library): the administrators of the digital libraries might not be willing to offer their database information through an answer interface different from their own. Furthermore, there will be cases when the direct link to their answer interface showing the results of the query will not be available, and the user will have to repeat the query using the interface of the digital library to be able to display the results. In this case, our system is useful only to locate interesting sources of information about the topic of interest.

5 Conclusions

We have described in this paper a system to federate a set of digital libraries, initially designed to federate three digital libraries containing antique Spanish documents, but adequate to federate any set of related documental databases. The main idea of the system, the use of XML trees, gives a number of advantages, the main ones being those that make our system to accomplish the three aims shown in the introduction that any federated system should achieve: a system that is scaleable and easy to adapt to changes, with a friendly user interface created using the three techniques presented in this work.

References

1. Baeza-Yates, R. Ribeiro-Neto, B. Modern Information Retrieval Addison-Wesley, 1999. 2. Biblioteca Virtual de Literatura Emblemática. http://rosalia.dc.fi.udc.es/cicyt 3. Brisaboa, N.R., Penabad, M.R., Places, A.S., Rodríguez, F.J. Problems and Solutions to

federate Digital Libraries. Poster in 5th European Conf. on Research and Advanced Technology for Digital Libraries (ECDL’2001). Darmstadt, Alemania, 2001.

4. Brisaboa, N. R., Penabad, M. R., Places, A.S., Rodríguez, F. J. Tools for the design of user friendly Web applications. Lecture Notes in Computer Science (LNCS 2115), Springer Verlag (EC-WEB’2001), pp. 29-38. Munich, Alemania 2001.

5. Brisaboa, N.R., Penabad, M.R., Places, A.S., Rodríguez, F.J. A Document Database Query Language. Lecture Notes in Computer Science (LNCS 2405), Springer Verlag (BNCOD’02), pp. 183-198. Sheffield, England. Julio 2002.

6. Brisaboa, N. R., Penabad, M. R., Places, A. S., Rodríguez, F. J.. Ontologías en Federación de Bases de Datos. Novática, Núm. 157. Information Retrieval and the Web, Ricardo Baeza-Yates, Peter Schauble (Eds.). ATI. 2002.

118 RITOS2

7. Busse, S., Kutsche, R.-D., Leser, U. Strategies for the Conceptual Design of Federated Information Systems In M. Roantree, W. Hasselbring, and S. Conrad (eds.), Engineering Federated Information Systems, Proc. of the 3rd Workshop EFIS 2000, pp. 23-32. 2000.

8. Gonçalves, M. A., France, R. K., Fox, E. A., Doszkocs, T. E. MARIAN Serching and Querying across Heterogeneous Federated Digital Libraries. DELOS Workshop: Information Seeking, Searching and Querying in Digital Libraries 2000. 2000.

9. Mena, E., Illarramendi, A., Kashyap, V., Sheth, A. OBSERVER: An Approach for Query Processing in Global Information Systems based on Interoperation across Pre-existing Ontologies. Published in the journal Distributed And Parallel Databases (DAPD). 1998.

10. Relaciones de Sucesos. http://rosalia.dc.fi.udc.es/Relaciones 11. Samos, J., Abelló, A., Oliva, M. Rodríguez, E., Saltor, F., Sistac, J. Araque F., Desgado, C.,

Garví, E., Ruiz, E. Sistema Cooperativo para la Integración de fuentes Heterogéneas de Información y Almacenes de Datos. Novatica ATI, 1999.

12. Chawathe,S; Garcia-Molina, H.; Hammer, J.; Ireland, K; Papakonstantinou, Y; Ullman, J; Widom, J.. The TSIMMIS project: Integration of heterogenous information sources. 16th Meeting of the Inf. Proc. Soc. of Japan, pp. 7-18, Tokyo, Japan, October 1994.


��

��

��

� ��

��

��

��

�� !��" �� # �� $ �� %��!�� &� �� $ �� &�� %�� $

� �� !�"��

� ��

�� #�� $� ��%�� "�� $��&�� '� �(�� ) * � ��(�&��#�� +�� ,--. �� /-0� !�� 1� �� 2�� (�&�� #�� * �� 2� �� * �� 1�� %�� * �� * �� * �"� ��

� � ��

+� �� #�� $� �� "�� * ��

�� !�� (�� 3 �� %�� %�� %�� /40�

5��#�� $ ��6�� #�� %�� 1(�#�� %�� * �� (�� 1��

�� 6�� #�� !�� %�� 2�� 7�%�� , �� 1�� % �� 3� �� "�� (�� %�� (�� % �� * 6� �� #�� (�� 2�� (�� * ��2�� "��

Procesadores

ComputacionesLocales

Comunicaciones

Sincronización

(Barrier)

�� " �� # ��&�� '� ��

�� #�� $�� %�� 1�� !�� #�� #�� #�� 3��(�� 8�� %�� *� ��

3�� (�� %�� $� �� * �� &�9��

3 �� (�&�� "� �� $ �� 1�� %�� * :� �� ;"(�� %�

122 RITOS2

�� ,--4 ;"(�� * /<0� �� #�� 1�� #�� $�� 6� �� 5 6� �� (�� * �� 1�� #�� 3�� #�� "� ��;�� * �� /=0�

�� (�� (�� (�#�� %�� >� �� %��

� �� 2�� * ��

� �� %�� %�� 2�� * ��

� �� 2�� 1%�� %�� * ��%��* 6� �� %�� #�� 2�� (�� 6��

� �� $�� #�� 2��

� ��

��

�� (�� * � �� $�� 1�� 3�� 2� �� "�� '� ��) �� 3 ��2�� 1�� #�� 2�� 6��

��

3 �� ? � � � �� "1�� #�� #�� ? �@A ��#�� %�� (��%��


+� �� #�� 1 �� %�� ;�� #�� 1�� %� �� #�� #�� #��#�� 9��% 6� '�� ) * ��%� ��%�� 1�� $�� 2�� #��

�� 3�� #�� % �� 2� �� #�� % �� #�� * �� #�� "�� #�� 3 ��

�� "�� 3�� 2�� #�� (��

��

�� #�� (�� (�� #�� *#�� %� �� %� �� 1�� "��%��6�� 'B�*) * �� 6�� #�� '��1�� (�� * �� #�� #�� )� 3� �� 2� � ��(�#�� $ �"� �� 1�� * �� % �� %�� %�� 1�� #�� #�� *� �� 2�� #�� 3� 6%�� A �� '�� #�� #�� )�� 6%�� C �� "��

% �� %�� * ��%� �� % �� (�� #��

��

� 7�%�� D �� 3 �� 2�� %�� #��

124 RITOS2

��

��

��

��

� � ��! � �� "��

�#� ��

��

�� $��"��

�� $ ��

�� $ �

��

�%��

� � ��! � �� "��

�&��$�� '��

��

��

� ��$�� '��

� � ��

�#� ��

��

�� #�� 7�%�� = �� % ��

� ��

3� �� %�� '�� %�� ) �� %� �� %�� #�� $* �� $* �� %�� * �� (��

3� �� ,A�� '�� ) ��

3 �� 2� � �� #�� $� �� !��


��

��$��

�(�� $��"��

�� $��"��

� ��$��

�)�� "��

�)�� *��

�� '�

�(�� '�

�� )�� + � ��

�� *��

� ��$�� '�

� � ��! � �� $�� '�

��

� ��$�� '�

� � ��! � �� "�� $ ��

�(�� "��

�� "��

� ��$�� '��

�,�� $ � ��

�� $��

�(�� $��"��

�� $��"��

� ��$��

�(��

�� (��

� �� "� �*�� 2� �� #�� * ��#��

�� 7�%�� 4 * E �� ,... �� "�� %�� * % �� *� �� #�� *��

126 RITOS2

��

��$��

�(�� $��"��

�� $��"��

� ��$��

�#�� '� ��

�)�� "��

�(�� '� � �� ! ��

��

�� )�� + � ��

��

� ��$�� '�

� � ��! � �� "�� $ ��

�(�� "��

�� "��

� ��$�� '��

�,�� $ � ��

�� $��

�(�� $��"��

�� $��"��

� ��$��

�(��

�� (��

�� %� �� #�� % �� %�� % �� "�� 3�� #�� 3�� %� �� #��

�� 7�%�� < * - �� %�� * % �� 3�� , * A �� #�� #�� #�� #�� * �� %� �� C ��


�� )*** ��

�� '� �� )*** ��

�� %� ��

��

:�� %�� %�� "�� * % �� #�� 3� ��%� �� *� �� 2�� #�� % �� *�� 2�� * �� *� ��(��

128 RITOS2

�� + ,�� &�� )*** ��

�� '� �� + ,�� &�� )*** ��

3� ��%� % �� (�� #�� %� �� %� �� #�� % ��

!�� $�� "�� %�� #�� * � �� #��8�� 2�� (�� "�� % �� 3�� #�� "�� %��6�� #��8��


��

3�� 2� $ �� +�� '5�%��) * �% �� '�$� �)� : �� F�� !�� %�� (�&�� %�� '��) �� $ �� 2� ��2�� %� �� * �� %�� 5�� #�� "�� * ��

�� *�� %1�� 5%�� *�� * #��

�� $�� 1�� "�� G� ��

!��

)$ �$�$ ��-�� .$�$ �� # �$�$( ��$�� $ �� /��$ �� #�� (��0***$

0$ � �� '$ �� $�$ �� 1)*��$ �� #�� )2234$

5$ 6�� 7$� .��8 6$� �� 7�� $� (�� $ �� ! "�� #�� #�� 1)5��$ �� #�� 9 )*��$ �#�� )222$4

:$ �$6$ �8�� .$�$�$ ;�� # <$-$ ��$�$�� %�� $(�� ('+,(+)=+23�� 7!��)223$

=$ '�� $� 6�� $� �� .$� .�� <$� ��8 ($� �� >$ �&�'�� &�� ! ( �� )�� *��%��+ �� !#�� 1��, �� )22:4

3$ '�� ($ �� -$ �� $�$ �� )�� ,�� ,��!�� 1,�� )0�� #�+�� $ 1��+)04� 1��6�� (�� 05)+05/$ ��# � )2224$

/$ ;�� .$� �� 6$� �� $� '�� $� �� ?$� (� 6$� �� ,$� ,��$�6�� ($ �� ' �� 17!�� # ��+�� #� �('+,(+02+2/� )22/$4

@$ �� %� �$� 6�� $� �� $�(�� %� ��-�� -��

2$ �� %� �$ �� -� $�� #�� )*$ ��# ��8�� (�� 6��# A�� # ;�� '��+�� !

�� "�� .��!��-� ��- �� /��$ �� ,�� #��0**)$

))$ �� $� 7�� $� ;��+�� $� <��8�� $� �� .$ ��' �� #��0�� 1�� " ��, �� )2234

)0$ >�� $'$ �� #�� 1�� $ 55� �� @� ��$ )*5 � )))� )22*$4

)5$ 6�� <��B�� "CCBBB$ ��+B��B��$��C$):$ 6�� 6 �� # �� #� ��"CCBBB$��+�� $�C ��$

130 RITOS2

Index structures for distributed text databases

Mauricio Marin�

Universidad de MagallanesCasilla 113-D, Punta Arenas, Chile

Abstract. The Web has became an obiquitous resource for distributedcomputing making it relevant to investigate new ways of providing effi-cient access to services available at dedicated sites. Efficiency is an ever-increasing demand which can be only satisfied with the development ofparallel algorithms which are efficient in practice.This tutorial paper focuses on the design, analysis and implementationof parallel algorithms and data structures for widely-used text databaseapplications on the Web. In particular we describe parallel algorithmsfor inverted files and suffix arrays structures that are suitable for im-plementing search engines. Algorithmic design is effected on top of theBSP model of parallel computing. This model ensures portability acrossdiverse parallel architectures ranging from clusters to super-computers.

1 Introduction

In the last decade, the design of efficient sequential data structures and algo-rithms for text databases and related applications has received a great deal ofattention due to the rapid growth of the Web [3]. Typical applications are thoseknown as client-server in which users take advantage of specialized services avail-able at dedicated sites. For the cases in which the number and type of servicesdemanded by clients is such that it generates a very heavy work-load on theserver, its efficiency in terms of running time is of paramount importance. Assuch it is not difficult to see that the only feasible way to overcome limitationsof sequential computers is to resort to the use of several computers or processorsworking together to service the ever-increasing demands of clients.

The advent of powerful processors and cheap storage has allowed the consid-eration of alternative models for information retrieval other than the traditionalone of a collection of documents indexed by keywords. One such a model whichis gaining popularity is the full text model. In this model documents are repre-sented by either their complete full text or extended abstracts. The user expresseshis/her information need via words, phrases or patterns to be matched for andthe information system retrieves those documents containing the user specifiedstrings. While the cost of searching the full text is usually high, the model ispowerful, requires no structure in the text, and is conceptually simple [3].

An approach to efficient parallelization is to split up the data collection anddistribute it onto the processors in such a way that it becomes feasible to exploit� E-mail: [email protected]

locality by effecting parallel processing of user requests, each upon a subsetof the data. As opposed to shared memory models, this distributed memorymodel provides the benefit of better scalability [20]. However, it introduces newproblems related to the communication and synchronization of processors andtheir load balance.

The bulk-synchronous parallel (BSP) model of computing [29, 35] has beenproposed to enable the development of portable and cost-predictable softwarewhich achieves scalable performance across diverse parallel architectures. BSPis a distributed memory model with a well-defined structure that enables theprediction of running time. Unlike traditional models of parallel computing, theBSP model ensures portability at the very fundamental level by allowing algo-rithm design to be effected in a manner that is independent of the architectureof the parallel computer. Shared and distributed memory parallel computersare programmed in the same way as they are considered emulators of the moregeneral bulk-synchronous parallel machine.

The practical model of BSP programming is SPMD, which is realized asP program copies running on the P processors, wherein communication andsynchronization among copies is performed by ways of libraries such as BSPlib[33] or BSPub [34]. We emphasize that BSP is actually a paradigm of paral-lel programming and not a particular communication library. In practice, it iscertainly possible to implement BSP programs using the traditional PVM andMPI libraries. However, a number of studies have shown that BSP algorithmslead to more efficient performance than their message-passing or shared-memorycounterparts in many applications [29, 30].

To reduce the cost of searching a full text, specialized indexing structuresare adopted. The most popular of these are inverted lists [3]. Inverted lists areuseful because their search strategy is based on the vocabulary (the set of distinctwords in the text) which is usually much smaller than the text, and thus fits inmain memory. For each word, the list of all its occurrences (positions) in thetext is stored. Those lists are large and take space which is 30% to 100% of thetext size.

On the other hand, Suffix arrays or pat arrays [3] are more sophisticatedindexing structures than inverted indexes, which also take space close to thetext size. They are superior to inverted lists for searching phrases or complexqueries such as regular expressions [3]. In addition, suffix arrays can be used toindex texts other than occidental natural languages, which have clearly separatedwords that follow some convenient statistical rules [3]. Examples of these appli-cations include computational biology (ADN or protein strings), music retrieval(MIDI or audio files) and oriental languages. However, their efficient paralleliza-tion is more involved than inverted lists since they exhibit a very poor datalocality during query processing.

This tutorial paper focuses on the design, analysis and implementation ofparallel algorithms for these two index data structures. It surveys our workon BSP realizations of inverted lists and suffix arrays [16–18] and cites relatedwork built upon traditional models of parallel computation such asynchronous

132 RITOS2

message passing. In section 2 we present a description of the BSP model ofparallel computing. Section 3 presents methods for inverted lists and section 4presents methods for suffix arrays. Finally section 5 describes research topics.

2 Model of parallel computing

In the BSP model [29, 35], any parallel computer is seen as composed of a setof P processor-local-memory components which communicate with each otherthrough messages. The computation is organised as a sequence of supersteps.During a superstep, the processors may perform sequential computations onlocal data and/or send messages to other processors. The messages are availablefor processing at their destinations by the next superstep, and each superstep isended with the barrier synchronisation of the processors.

In most cases, optimal efficiency comes from solutions devised using pure BSPconcepts rather than translations from algorithms devised for the traditionalmodels of computing. The cost of a BSP algorithm is given by the sum of thecost of its supersteps where every superstep is costed taking the observed maximain computation and communication. Proper load balancing is crucial and alsoalgorithms should minimize the total number of supersteps.

More specifically, the total running time cost of a BSP program is the cumu-lative sum of the costs of its supersteps, and the cost of each superstep is the sumof three quantities: w, h g and l, where w is the maximum of the computationsperformed by each processor, h is the maximum of the messages sent/receivedby each processor with each word costing g units of running time, and l is thecost of barrier synchronising the processors. The effect of the computer archi-tecture is cost by the parameters g and l, which are increasing functions of P .These values along with the processors’ speed s (e.g. mflops) can be empiricallydetermined for each parallel computer by executing benchmark programs at in-stallation time [29] or by determining asymptotic expressions in accordance withthe topology of the communication network connecting the BSP processors [20].

As an example of a basic BSP algorithm let us consider a broadcast operationwhich will be implicitly used in the algorithms described in the following sections.Suppose a processor “wants” to send a copy of P chapters of a book, each ofsize a, to all other P processors (itself included). A naive approach would be tosend the P chapters to all processors in one superstep. That is, in superstep 1,the sending processor sends P chapters to P processors at a cost of O(P 2 (a +a G) + L) units of running time. Thus in superstep 2 all P processors haveavailable into their respective incoming message buffers the P chapters of thebook. An optimal algorithm for the same problem is as follows. In superstep 1,the sending processor sends just one different chapter to each processor at a costof O(P (a + a G) + L) units. In superstep 2, each processor sends its arrivingchapter to all others at a cost of O(P (a + a G) + L) units. Thus at superstep 3,all processors have a copy of the whole book. That is, the broadcast of a largeP -pieces a-sized message can be effected at O(P (a + a G) + L) cost.


The well-defined structure of BSP computations allows optimizations such aspacking into a single large message a set of small messages sent by a processor toanother processor. This amortizes overheads associated with the communicationof many small messages addressed to the same processor. Also the requirementof periodically barrier synchronizing the processors can be relaxed in situationsin which a given processor knows before hand the number of messages it shouldexpect from all others. In this case, a given processor just waits until it receivesthe proper number of messages to further continue its computations on localdata. Barrier synchronization of sub-sets of processors is also possible [34, 35].

3 Inverted Lists

Server-broker relationship

We assume a server operating upon a set of P identical machines, each con-taining its own main and secondary memory. We treat secondary memory likethe communication network. That is, we include an additional parameter D torepresent the average cost of accessing the secondary memory. Its value can beeasily determined by benchmark programs available on Unix systems. The tex-tual database is evenly distributed over the P machines. If the whole databaseindex is expected to fit on the P sized main memory, we just assume D = 1.

Clients request service to one or more broker machines, which in turn dis-tribute them evenly onto the P machines implementing the server. Requests arequeries that are solved by using an index data structure distributed on the P pro-cessors. We assume that the index is implemented using an inverted list which,as described in the next section, is composed of a vocabulary (set of terms) anda set of identifiers representing all the documents that contain at least one ofthe words that are members of the vocabulary. The inverted list data structureenables the efficient retrieval of all identifiers for which a given term appears inthe respective documents.

We assume that under a situation of heavy traffic the server is able to processbatches of Q = q P queries. Every query is composed of one or more vocabularyterms for which it is necessary to retrieve all document identifiers associatedwith them. Only the identifiers of the most relevant documents are presentedto the user, namely those which more closely match the user information needrepresented by the query terms. For this, it is necessary to perform a rankingof documents. A widely used strategy for this task is the so-called vector model[3], which provides a measure of how close is a given document to a certainuser query. We assume that the reader is familiar with this method and overallterminology [3].

Minimal broker

In order to exploit the available parallelism we try to minimize the amount ofsequential work performed by the broker machine. We restrict its functionality

134 RITOS2

to receive user requests, distribute the queries onto the processors (uniformly atrandom), receive the best ranked documents (K in total) from the server, andpass them back to the user.

The two most basic operations related to providing answers to user queriesare left to the parallel sever. That is, the retrieval of document identifiers and itsrespective ranking. Both operations are effected in parallel where the broker isresponsible for scheduling those in a manner that keeps load balance of processorswork as close to the optimal 1/P as possible. This is achieved by the combinationof two strategies.

Firstly, the terms of the vocabulary are distributed uniformly at randomonto the processors. This kind of strategy has proven to be a very effectivetool for destroying correlation among the input data [35]; query terms in ourcase, with imbalance coming from the fact that user preferences could causethat many terms be routed to the same processor. We use a hashing functionon the term’s characters for this purpose. This function is used to distributethe vocabulary’s terms at index construction time and during the broker’s termdistribution process.

Secondly, for every query the broker chooses a server processor in whichperforming the ranking of documents. Later this processor sends the K bestranked ones back to the broker. As the terms of a given query (or set of queries),are likely to be located in different processors, the broker chooses such processorin a way that tends to maintain a good load balance with all other processors.That is, this processor is chosen in a way that attempts to evenly distribute allranking tasks onto the P processors. This is effected by maintaining a counterfor each processor. These counters keep the number of ranking tasks scheduledin every processor for queries which have not been completed yet. A rankingtask for a given query is scheduled on one of the processors that are associatedwith their respective terms. From those, the processor with the smallest countervalue is the selected one.

Thus the query terms are distributed uniformly at random by ways of thehashing function. The targets processors for these terms perform the work re-quired to retrieve their associated lists of document identifiers. Then the listsassociated with every query are routed to the processor selected for their finalranking. Lists associated with different queries are expected to be routed todifferent processors.

A pseudo-code for the steps executed by the broker is the following,

while(true)

{

msg= rcvMessage(); // wait until it gets a new message.

switch( msg.from() ) // where is the message from.

{

case USER: // new query arrival.

// select a server processor for the final ranking of documents.

proc= rankingProcessor(msg.Query()); // apply load balancing.


foreach term in msg.QueryTerms()

{

term.ranker(proc); // let it know its ranker processor.

serverProc= hashFunction(term.str()); // distribute evenly.

sndMsg(serverProc,term); // send the term to its processor.

}

break;

case SERVER: // server answer arrival.

updateLoadBalancingCounters(msg.Query());

// send back to the user the query’s results.

sndMessage(msg.user,msg.rankedDocumentsList);

break;

}

}

Bulk-synchronous parallel server

The details of the operations executed by the parallel server are described inthe next section as its design is conditioned by the inverted lists strategy beingemployed. In general, the server executes a never-ending sequence of superstepsin which batches of q terms are processed in each processor along with theranking of documents. The terms are routed to each processor by the brokeras described above. In each superstep, the processing of a new batch is started.Depending on the kind of index strategy employed the processing of a giventerm plus the associated ranking of documents can take two or more superstepsto complete. Thus at any given superstep we can have several batches beingprocessed, each at a different stage of execution. This is intended to achieve agood amortization of communication and synchronization costs.

Local and global inverted lists

For a collection of documents the inverted lists strategy can be seen as a vo-cabulary table in which each entry contains a term (relevant word) found in thecollection and a pointer to a list of document’s identifiers that contains suchterm. These lists are called inverted-lists. Thus, for example, a query composedof the logical AND of terms 1 and 2 can be solved by computing the intersectionbetween the inverted-lists associated with the terms 1 and 2. The resulting listof documents can be then ranked so that the user is presented with the mostrelevant documents first (the technical literature on this kind of topics is largeand diverse, e.g., see [3]). Parallelization of this strategy has been tackled usingtwo approaches [2, 9, 19, 27, 32].

136 RITOS2

In the local index approach the documents are assumed to be uniformlydistributed onto the processors. A local inverted-lists index is constructed ineach processor by considering only the documents there stored respectively. Wethus have P individual inverted-lists structures so that a query consisting of,say, one term must be solved by simultaneously computing the local sub-lists ofdocument identifiers in each processor, and then producing the final global listfrom these P local sub-lists.

The BSP realization of the local index approach is as follows. Once the brokermachine routes by ways of the hashing function a term w belonging to a queryu to processor i, this processor broadcasts the term w to all other processors inthe current superstep. Every processor does the same for each term they receive.In the following superstep, all processors scan their local inverted lists to obtainthe sub-list of document identifiers for each term they received in the previousbroadcast. These sub-lists are then sent to the processors acting as rankers.Thus if processor k happens to be the ranker for query u, the sub-list associatedwith term w in processor i along with the ones located in all other processorsfor term w, are routed to processor k. The same is effected for all other termsbelonging to the query u so the processor k can perform the final ranking inthe following superstep. The size of these sublists is reduced by performing apre-ranking before sending them to their rankers. Also if two terms of query uhappens to be in the same processor a pre-merging is performed (see [2] for thiskind of optimizations). The whole process of a query u takes 3 supersteps tocomplete and send back the final list of document identifiers to the broker.

The second approach is the so-called global index. Here the whole collection ofdocuments is used to produce a single inverted lists index which is identical to thesequential one. Then the T terms that form the global term table are uniformlydistributed onto the P processors along with their respective lists of documentidentifiers. This is done by ways of the same hashing function employed by thebroker. Thus, after the mapping, every processor contains about T/P terms perprocessor. In the local index case, each processor contains the same T terms butthe length of document identifier lists are closely a fraction 1/P of the globalindex ones.

The BSP realization of the global index is as follows. Like the previous strat-egy, each term is routed to one server processor by the broker. For each term wbelonging to a query u the inverted lists associated with terms of u are retrievedin their respective processors. Then these lists are sent to the ranker proces-sor defined for the query u to then proceed in the next superstep like the localinverted lists case. The whole process takes 2 supersteps to complete.

An efficiency reduction problem in the global index strategy may arise whenthe most frequently visited terms tend to be located in the same processors.This produces load imbalance both in computation and communication. Thereexists some solutions to this problem. For example, in [9] a statistical analysis ofterms co-occurrence in every document is effected at initialization time in orderto determine which terms should be mapped on different processors. This is anexample of static mapping. However, below we provide empirical evidence that


when static mapping is done in a randomized manner by using a hash functionthis imbalance does not arise. On the other hand, a dynamic re-distribution ofterms can be applied to move pairs (term, list) to other processors when loadimbalance is detected.

Note that real-life textual databases produce index structures with very dif-fering lengths for the document identifier lists (e.g., try to evaluate the Zipf’sformula described in [3]). Combining a term with a small-sized list with a termwith a large-sized one into the same query can have a catastrophic effect in theglobal index approach. The local index approach does not have this problem butit is less efficient with small-sized lists because of the relative increase of thecost of broadcasts. Yet small sized lists arise frequently when user put into theirqueries terms which are very specific to the subject they are looking for. Thisclearly suggests an approach which combines the two strategies. That is, termswith large identifier document lists are treated using the local index approachwhereas terms with small lists are treated using the global one. We call thiscomposite inverted lists.

Simulation study

To motivate the introduction of the composite approach described in the nextsection, we present simulation results describing the performance of the twothe local and global approaches to parallel inverted lists. Note that other re-searchers have already shown that it is feasible to achieve efficient performancewith distributed inverted lists on clusters [2]. Also the fully parallel constructionof inverted lists has been investigated in [26].

Table 1 shows the performance of global and local inverted lists for 8 ... 64processors. The results were obtained for 128 new query arrivals per superstepwith simulation runs of 20000 completed queries. Queries were randomly gener-ated by choosing uniformly from 1 to 4 terms, wherein terms for the first andsecond part of the table were also chosen uniformly at random from a total of1300 and 6500 terms respectively. The sizes of the lists associated with theseterms ranged from La (the maximum) to Lb (the minimum) in accordance withthe Zipf’s law normalized to the FR-TREC collection excluding stopwords asdescribed in [1].

Efficiency columns Ee and Em indicate the load balance (speed-up divided bythe number of processors) for computation and communication respectively. Theratio m/e indicates the total amount of communication over the total amountof computation effected during the simulation.

The results of table 1 confirm the above claims, namely the global and localapproaches can outperform each other under different situations. First and giventhat only 128 new queries arrive in each superstep, for 64 processors we have amodest amount of terms to be processed in each cycle (between 128 and 512,with average 320). Thus as the number of processors increases from 8 to 64we see a clear reduction of the efficiencies in computation and communication.As expected, the local strategy has better efficiencies in all cases. Its efficiencyis decreased only because of imbalance in the process of composing the final

138 RITOS2

global lists index local lists index

P La Lb Ee Em m/e Ee Em m/e

8 116 76 0.88 0.88 0.68 0.92 0.93 1.3816 116 76 0.82 0.79 0.73 0.89 0.89 1.5232 116 76 0.75 0.70 0.73 0.82 0.85 1.6964 116 76 0.62 0.56 0.75 0.76 0.79 1.92

8 104355 76 0.58 0.72 0.25 0.97 0.92 0.2916 104355 76 0.47 0.52 0.35 0.91 0.81 0.4532 104355 76 0.30 0.35 0.41 0.81 0.72 0.6564 104355 76 0.19 0.18 0.52 0.58 0.50 0.83

Table 1. Global vs local inverted lists. 128 new queries per superstep

answers to queries. However, when the differences between inverted list sizes issmall, the efficiencies of the global approach are competitive. In addition, forsmall sized inverted lists the efficiencies in both cases are fairly the same but thelarger values of m/e for the local approach show that broadcasts start to havea significant effect in the communication cost. Note that queries using termswhich are more specific are expected to work on small inverted lists. When weincrease from 128 to 1024 the number of queries that arrive at every superstep,efficiencies increase to be near optimal. This for terms selected uniformly atrandom. However, if we chose terms with very large and very small inverted listssizes to compose the queries, this in an alternate and random fashion, then theefficiencies decrease rather dramatically in the global lists approach. A situationlike this can arise when users submit queries that contain very specific termsand less specific ones.

Note that in the proposed BSP server both the selection and ranking ofdocuments is performed in the BSP processors. In particular, the ranking, whichis running time demanding, is performed in parallel by attempting to choosea different processor to rank the documents associated with every query. Forsmall rate of query arrivals per superstep, the way we select these processorscan have a significant impact on load balance and thereby in computation andcommunication efficiencies. The load balancing method we described in section3 is simple and allows the achievement of efficiencies much better than justselecting at random the ranker processor.

Composite Inverted Lists

It is straightforward to combine into a single BSP algorithm the two abovedescribed inverted lists strategies. Each processor maintains a hash table to keepinformation about which terms are kept as in the local index case and which asin the global one. The following pseudo-code shows the superstep executed by aBSP server using a composite inverted list index to solve user queries,


while(true) // Each BSP processor executes the same superstep.

{

* Receive new messages and put them in a queue Q.

* Foreach message msg in the queue Q do

{

switch( msg.type )

{

case BROKER: // new term received from the broker.

if ( IsLocal(msg.term) == true )

Broadcast(msg.term);

else

{ // retrieve and sub-rank document list.

List= getInvertedList(msg.term);

subList= preRanking(List);

// buffer message to be sent to the ranker processor.

bufferMsg(msg.ranker,RANKING,subList);

}

break;

case BROADCAST: // arrival of a broadcast term.

List= getInvertedList(msg.term);

subList= preRanking(List);

bufferMsg(msg.ranker,RANKING,subList);

break;

case RANKING:

if ( queueSize(msg.queryId) == msg.numTermsQry )

{

List= CalculateFinalRanking( dequeueAll(msg.queryId) );

bufferMsg( broker, SERVER, List);

}

else // queue up to wait for more terms

enqueue(msg.queryId,msg);

}

}

* Send all buffered messages to their target processors,

and synchronize processors.

}

A term is treated as global or local depending on the size of its associated invertedlist. We set the maximum size of a list to be the one which produces the sameratio of computation to communication than the global inverted list approach.List sizes below this maximum are treated as in the global index case whereassizes above the maximum are treated as in the local index one.

This straightforward combination of the local and global approaches is astrategy which we have found to be practical, efficient and very simple to im-

140 RITOS2

plement. Its efficiency comes from the fact that most queries containing relevantterms tends to have inverted lists of small sizes. Table 2 shows simulation re-sults for the same conditions to the one above described. It can be seen thatefficiencies are similar to those of the local approach whilst the ratio communi-cation/computation (m/e) are similar to that of the global approach.

comp. lists index global lists index local lists index

P Ee Em m/e Ee Em m/e Ee Em m/e

8 0.88 0.88 0.68 0.88 0.88 0.68 0.92 0.93 1.3816 0.82 0.79 0.73 0.82 0.79 0.73 0.89 0.89 1.5232 0.75 0.70 0.73 0.75 0.70 0.73 0.82 0.85 1.6964 0.62 0.56 0.75 0.62 0.56 0.75 0.76 0.79 1.92

8 0.97 0.90 0.25 0.58 0.72 0.25 0.97 0.92 0.2916 0.90 0.78 0.37 0.47 0.52 0.35 0.91 0.81 0.4532 0.75 0.61 0.44 0.30 0.35 0.41 0.81 0.72 0.6564 0.53 0.43 0.54 0.19 0.18 0.52 0.58 0.50 0.83

Table 2. Composite, global and local inverted lists. 128 queries per superstep. Thefirst part of the table is for La= 116 and Lb= 76, and the second part is for La= 104355and Lb= 76.

4 Suffix arrays

Suffix arrays or pat arrays [3] are data structures for full text retrieval based onbinary searching. Given a text collection, the suffix array contains pointers to theinitial positions of all the retrievable strings, for example, all the word beginningsto retrieve words and phrases, or all the text characters to retrieve any substring.These pointers identify both documents and positions within them. Each suchpointer represents a suffix, which is the string from that position to the end ofthe text. The array is sorted in lexicographical order by suffixes as shown inFigure 1. Thus, for example, finding all positions for terms starting with “tex”leads to a binary search to obtain the positions pointed to by the array members7 and 8 of Figure 1. This search is conducted by direct comparison of the suffixespointed to by the array elements.

A typical query consists of finding all text positions where a given substringappears in. For the purpose of the description of the algorithms presented inthis paper we assume that this is the query of interest and that it is solved byperforming two searches which locate the delimiting positions of the array for agiven substring. Processing a single query of this kind in a text of size N takeslog N time on the standard sequential suffix array.

A suffix array can be distributed onto the processors using a global indexapproach in which a single array is built from the whole text collection andmapped evenly on the processors. A realization of this idea for the example in


28 14 38 17 11 25 6 30 1

1 2 3 4 5 6 987

This text is an example of a textual database

1 6 11 14 17 25 28 30 38

Fig. 1. Suffix array.

Figure 1 is shown in Figure 2 for 2 processors. Notice that in this global indexapproach each processor stands for a lexicographical interval or range of suffixes(for example, in Figure 2 processor 1 represents suffixes with first letters from“a” to “e”). The broker machine mantains information of the values limiting theintervals in each machine and route queries to the processors accordingly. Thisfact can be the source of load imbalance in the processors when queries tend tobe dynamically biased to particular intervals.

28 14 38 17 11 25 6 30 1

1 2 3 4 5 6 987


1 6 11 14 17 25 28 30 38

Processor 1 Processor 2

Fig. 2. A global index suffix array distributed on two processors.

A search for all text positions associated with a batch of Q = q P queriescan be performed as follows. The broker routes the queries to their respectivetarget processors. Once the processors get their q queries, in parallel each ofthem performs q binary searches. Note that for each query, with high probability1 − 1/P , it is necessary to get from a remote processor a T -sized piece of textin order to decide the result of the comparison and go to the next step in thesearch. This reading takes one additional superstep plus the involved cost ofcommunicating T bytes per query. Note that, it is not necessary to wait for agiven batch to finish since in each superstep we can start the processing of a newbatch. This forms a pipelining across supersteps in which at any given superstepwe have a number of batches at different stages of execution. The net effect isthat at the end of every superstep we have the completion of a batch. We callthis strategy G0.

A very effective way to reduce the average number of remote memory accessesis to associate with every array entry the first t characters of the suffix pointed.This technique is called pruned suffixes. The value of t depends on the text and

142 RITOS2

usual queries. In [14] it has been shown that this strategy is able to put below 5%the remote memory references for relatively modest t values. Our experimentsshow rates below 1%.

In the local index strategy, on the other hand, a suffix array is constructedin each processor by considering only the subset of text stored in its respectiveprocessor. See Figure 3. No references to text postitions stored in other processorsare made. Thus it is not necessary to pay for the cost of sending T -sized piecesof text per each binary search step.

1 2 3 4 5


1 6 11 14 17 25 28 30 38

14 17 11 6 1 30253828

1 2 3 4


Fig. 3. Local index suffix array.

However, for every query it is necessary to search in all of the processors inorder to find the pieces of local arrays that form the solution for a given intervalquery. As an answer, it suffices to send to the broker P pairs (a, b), one perprocessor, where a/b are the start/end positions respectively of the local arrays.Unfortunately, the broker must send every query to every processor which canbecome significant cost for large number of processors.

One drawback of the global index approach is related to the possibility of loadimbalance coming from large and sustained sequences of queries being routed tothe same processor. The best way to avoid particular preferences for a givenprocessor is to send queries uniformly at random among the processors. Wepropose to achieve this effect by multiplexing each interval defined by the originalglobal array, so that if array element i is stored in processor p, then elementsi + 1, i + 2, ... are stored in processors p + 1, p + 2, ... respectively, in a circularmanner as shown in Figure 4. We call this strategy G2.

In this case, any binary search can start at any processor. Once a searchhas determined that the given term must be located between two consecutiveentries k and k+1 of the array in a processor, the search is continued in the nextprocessor and so on, where at each processor it is only necessary to look at entryk of its own array. For example, in Figure 4 a term located in the first interval,may be located either in processor 1 or 2. If it happens that a search for a termlocated at position 6 of the array starts in processor 1, then once it determinesthat the term is between positions 5 and 7, the search is continued in processor2 by directly examining position 6. In general, for large P , the inter-processors


search can be done in at most log P additional supersteps by performing a binarysearch accross processors.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20


1 1 1 1 1 1 1 1 112 2 2 2 2 2 2 2 2 22

1 3 5 7 9 2 4 6 8 10

11 13 15 17 19 12 14 16 18 20

Fig. 4. Multiplexing the global index suffix array entries.

Note that the multiplexed strategy (G2) can be seen as the opposite extremeof the global index distributed lexicographically starting from processor 0 toP − 1, wherein each processor holds a certain interval of the suffixes pointedto by the N/P array elements (G0). The delimiting points of each interval ofthe G0 strategy can be kept in an array of size P − 1 so that a binary searchconducted on it can determine to which processor to route a given query.

An intermediate strategy (G1) between G0 and G2 can be obtained by con-sidering the global array as distributed on V = 2k P virtual processors withk > 0 and that each of the V virtual processors is mapped circularly on the Preal processors using i mod P for i = 0...V with i being the i-th virtual proces-sor. In this case, each real processor ends up with V/P different intervals of N/Velements of the global array. This tends to break apart the imbalance introducedby biased queries. Calculation of the array positions are trivial.

In our realization of G0 and G1 we keep in each processor an array of P (V )strings of size L marking the delimiting points of each interval of G0 (G1). Thebroker machine routes queries uniformly at random to the P real processors, andin every processor a log P (log V ) binary search is performed to determine towhich processor to send a given query (we do so to avoid the broker becoming abottleneck). Once a query has been sent to its target processor it cannot migrateto other processors as in the case of G2. That is, this strategy avoids the inter-processors log P binary search. In particular, G1 avoids this search for a modestk whilst it approaches well the load balance achieved by G2, as we show inthe experiments. The extra space should not be a burden as N � P and k isexpected to be small.

Yet another method which solves both load imbalance and remote referencesis to redistribute the original global array so that every element of local arrayscontain only pointers to local text, as shown in Figure 5. This becomes similar

144 RITOS2

to the local index strategy whilst it still keeps global information that avoids theP parallel binary searches and broadcast per query. Unfortunately we now losethe capability of performing the inter-processors log P -cost binary search, sincethe owners of the next global array positions are unknown. In [17] we proposean O(r P 1/r) cost strategy to perform this search when necessary, at the cost ofstoring r values per suffix array cell (instead of storing a pruned suffix of t charsper cell). The practicality of this method remains to be further investigated.

1 2 3 4

17 14 28 38

4321


1 6


11 14 17 25 28 30 38

11 6 1 25 30

51 2 3 4 1 2 3 4 5

Fig. 5. Combining multiplexing with local-only references.

Experimental Results

We compared the multiplexed strategy (G2) with the plain global suffix array(G0), and the intermediate strategy (G1). The local index strategy was at least3 times slower than all others so we do not show empirical results for it. Foreach element of the array we kept t characters which are the t-sized prefix of thesuffix pointed to by the array element. We found t = 4 to be a good value forour text collection.

In G2 the inter-processors binary search is conducted by sending messageswith the first t characters of the query. The complete query is sent only when itis necessary to decide the final outcome of the search or when the t characters arenot enough to continue the search (this reduces the amount of communicationduring the inter-processors search).

The text collection is formed by a 1GB sample of the Chilean Web retrievedby the search engine www.todocl.cl. We treated it as a single string of char-acters. Queries were formed in three ways: (1) by selecting at random initialword positions within the text and extracting substrings of length 16; (2) sim-ilarly but starting at words that start with the four most popular letters ofthe Spanish language, “c”, “m”, “a” and “p” ; (3) taken from the query log ofwww.todocl.cl, which registers a few hundred thousand user queries submittedto the web site. In set (1) we expect optimal balance, while in (2) and (3) weexpect large imbalance as searches tend to end up in a subset of the global array.


The results were obtained on a PC cluster of 16 machines (PIII 700, 128MB)contected by a 100MB/s communication switch. Experiments with more than16 processors were performed by simulating virtual processors. In this smallcluster most speed-ups obtained against a sequential realization of suffix arrayswere super-linear. This was not a surprise since due to hardware limitationswe had to keep large pieces of the suffix array in secondary memory whilstcommunication among machines was composed by a comparatively small numberof small strings. The whole text was kept on disk so that once the first t charsof a query were found to be equal to the t chars kept in the respective arrayelement, a disk access was necessary to verify that the string forming the querywas effectively found at that position. This frequently required an access to adisk file located in other processor, in which case the whole query was sent tothat processor to be compared with the text retrieved from the remote disk.

We define two performance metrics devised to evaluate load balance in com-putation and communication. They are average maxima across supersteps. Dur-ing the processing of a query each strategy performs the same kind of operations,so for the case of computation the number of these ones executed in each pro-cessor per superstep suffices as an indicator of load balance for computation. Forcommunication we measured the amount of data sent to and received from ateach processor in every superstep. We also measured balance of disk accesses.In all cases the same number of supersteps were performed and a very similarnumber of queries were completed. In each case 5 runs with different seeds wereperformed and averaged. At each superstep we introduced 1024/P new queriesin each processor.

In Table 3(1) we show results for queries biased to the 4 popular letters.Columns 2, 3, and 4 show the ratio G2/G0 for each of the above defined per-formance metrics (average maximum for computation, communication and diskaccess). The results for G2/G1 are shown in Table 3(2). These results confirm in-tuition, that is G0 can degenerate into a very poor performance strategy whereasG2 and G1 are a much better alternative. Noticeably G1 can achieve similarperformance to G2 at a small k = 4. This value depends on the application, inparticular on the type of queries generated by the users. G2 is independent ofthe application but, though well-balanced, it tends to generate more messagetraffic due to the inter-processors binary searches (especially for large t). Thedifferences among G2, G1, G0 are not significant for the case of queries selecteduniformly at random. G2 tends to have a slightly better load balance.

As speed-ups were superlinear due to disk activity, we performed experimentswith a reduced text database. We used a sample of 1MB per processor, whichreduces very significantly the computation costs and thereby it makes much morerelevant the communication and synchronization costs in the overall runningtime. We observed an average efficiency (speed-up divided by the number ofprocessors) of 0.65.

In Table 3(3) we show running time ratios obtained with our 16 machinescluster. The upper of the table shows results for the biased query terms (queriesof type (2)) and the lower part shows results for terms selected uniformly at

146 RITOS2

P comp comm disk

2 0.95 0.90 0.894 0.49 0.61 0.698 0.43 0.45 0.53

16 0.39 0.35 0.3632 0.38 0.29 0.2464 0.35 0.27 0.17

P comp comm disk

2 1.10 0.90 0.894 0.92 0.82 0.698 0.86 0.65 0.53

16 0.80 0.55 0.3632 0.78 0.45 0.2464 0.75 0.43 0.17

P G2/G0 G2/G1

4 0.68 0.878 0.55 0.66

16 0.61 0.67

4 0.78 0.778 0.78 0.73

16 0.86 0.83

(1) Ratio G2/G0. (2) G2/G1 witk k = 4. (3) Running times ratios

Table 3. Comparison of search costs.

random (queries of type (1)). The biased workload increased running times bya factor of 1.7 approximately.

The results of Table 3(3) show that the G2 strategy outperformed the othertwo strategies, though G1 has competitive performance for the imbalanced case(first part of the table). Notice, however, that for the work-load with good loadbalance (second part of the table) G2 tends to lose efficiency as the number ofprocessors increases. This is because, as P grows up, the effect of performinginter-processors binary searches becomes more significant in this very low-costcomputation and ideal load balance scenario (case in which G0 is expected toachieve its best performance). We observed that the cost of broadcasts andincreased number of binary searches at each processor were significant and toodetrimental for the local index strategy.

5 Research topics

Inverted lists. Note that a better approach for large number of processors isto actually look at an intermediate situation between the local and global ap-proaches. The practical realization of this idea is to set buckets of a fixed sizewhose value is defined by the capacity of disk pages. Every inverted list is dividedin a certain number of buckets which are distributed evenly onto the processorat initialization. The key problem to solve in this case is the method employedto properly balancing the processing of queries as we explain in the following.

A distribution of buckets uniformly at random onto the processors is ex-pected to solve in part the load imbalance produced by queries containing natu-ral language text. However it is necessary to consider that the set of documentsproduced as a result of a given query must be ranked to present them to theuser sorted by relevance order. Previous approaches leave this task to the brokermachine. We believe that this is not a good idea because ranking demands a sig-nificant amount of computation which can transform the broker in a bottleneck.A broker machine should not perform much more operations than just routingarriving queries to the server processors, receiving the respective answers andpass them back to the user.

Document ranking in parallel (which is a parallelization of a strongly sequen-tial algorithm presented in [25]) is effected in [2, 27] using two major steps. First,


for each term present in a batch query, a pre-ranking is performed among therespective documents associated with the term. Then a subset of the retrieveddocuments are selected to perform the final ranking among all the documentsassociated with the terms contained in the query. In [2] this final ranking is per-formed in the broker. We believe it is more efficient to effect this in one of theserver processors so that good parallelism is achieved when queries from one ormore batches reach this stage and the final ranking tasks are scheduled in dif-ferent processors in a well balanced manner. No scheduling algorithms for thiscase have been proposed so far.

Note that it is possible, as we did in the case of the composite inverted listsapproach [16], to employ heuristics such as “the least loaded processor first”.However, it is also possible to think in terms of whole batches of queries ratherthan applying heuristics to individual queries. An interesting research topic hereis the analysis of existing job scheduling algorithms to see which are more suitablefor this case and how they can be modified to deal with dynamically biaseduser query terms as in natural language applications. In this case dynamic re-allocation of buckets is a feasible option.

Suffix arrays. The efficient construction of suffix arrays is a non-trivial prob-lem which by itself justifies the use of parallel computing because of the largesequential running times involved. In the parallel setting the main problem tocope with is the lack of locality. What one basically looks for is an evenly dis-tributed array of pointers to text positions or documents that usually are locatedat different processors. The array is lexicographically sorted in the sense that thestring pointed to by the position i of the array is less than the one pointed to byposition i + 1. Previous work on parallel construction of suffix arrays has beendone in [14, 24] for the message passing model of parallel computing. No imple-mentations have been effected and the strategies proposed have been based onthe adaptation of various sorting algorithms, some of them specialized to text.However, very recently three new sequential algorithms have been proposed forconstructing suffix arrays (submitted). It is then relevant to study how to use theconcepts behind those algorithms to formulate BSP algorithms for this problem.

Dealing with compressed text. Compression techniques are widely used in naturallanguage text databases [10, 21–23]. These techniques are particularly relevantto parallel text databases because they reduce the amount of information to betransmitted among server machines themselves and between server and brokermachines.

In a distributed memory parallel computation setting like the one supportedby the BSP model, the database is evenly distributed onto the machines. In this“sharing-nothing” scheme, text compression can be applied in each machine asthey were independent text collections. Alternatively to this local approach, textcan be compressed by considering the whole text collection. In both cases theamount and type of operations that is necessary to effect are different.

Very recently a new method for text compression was proposed in [8]. Themethod is particularly suitable for searching. It is worthwhile to investigate the

148 RITOS2

effectiveness of this method in the parallel context. A key part of the compressionprocess is the construction and maintenance of the coding alphabet table thatallows the mapping between actual words and the compressed representation ofthem. This table enables encoding of new text being entered to the database andthe necessary decoding for presentation and other important operations such assearching. It appears interesting to investigate efficient ways of maintaining thistable as new text is distributed onto the machines and search queries must reactproperly to this dynamics.

Concurrency control. Another type of problem that is worthwhile to study isconcurrency control upon inverted lists. In this case updates take place simul-taneously with queries (e.g., a news service) [11]. In [13] the classic invertedlist approach [3] is instrumented with a simple concurrency control mechanismwhich is based on the use of locks. However, locks tend to significantly reducethe level of parallelism that is possible to exploit from typical workloads for textdatabases applications. The application of optimistic concurrency control tech-niques such Time Warp [12, 15] remains to be investigated so far [3–7, 13, 28, 31,36].

References

1. M.D. Araujo, G. Navarro, and N. Ziviani. Large text searching allowing errors.In Workshop on String Processing (WSP’97), pages 2–20. (Carleton UniversityPress), 1997.

2. C. Badue, R. Baeza-Yates, B. Ribeiro, and N. Ziviani. Distributed query processingusing partitioned inverted files. In Eighth Symposium on String Processing andInformation Retrieval (SPIRE’01), pages 10–20. (IEEE CS Press), Nov. 2001.

3. R. Baeza and B. Ribeiro. Modern Information Retrieval. Addison-Wesley., 1999.4. R. Baeza-Yates, A. Moffat, and G. Navarro. Handbook of Massive Data Sets.

Kluwer Academic Publishers, 2002. Chapter 7, pages 195–243.5. N. Barghouti and G. Kaiser. Concurrency control in advanced database applica-

tions. ACM Computing Surveys, 23(3), September 1991.6. B. K. Bhargava. Concurrency control in database systems. Knowledge and Data

Engineering, 11(1):3–16, 1999.7. S. Blott and H. Korth. An almost-serial protocol for transaction execution in main-

memory database systems. In 28th International Conference on Very Large DataBases, Aug. 2002. Hong Kong, China.

8. N. Brisaboa, E. Iglesias, G. Navarro, and J. Parama. An efficient compression codefor text databases. In Proceedings of the 25th European Conference on InformationRetrieval Research (ECIR’03), LNCS 2633, pages 468–481, 2003.

9. S.H. Chung, H.C. Kwon, K.R. Ryu, H.K. Jang, J.H. Kim, and C.A. Choi. Parallelinformation retrieval on a sci-based pc-now. In Workshop on Personal Computersbased Networks of Workstations (PC-NOW 2000). (Springer-Verlag), May 2000.

10. E. Silva de Moura, G. Navarro, N. Ziviani, and R. Baeza-Yates. Fast and flexibleword searching on compressed text. ACM Transactions on Information Systems,18(2):113–139, April 2000.

11. Daniela Florescu, Alon Y. Levy, and Alberto O. Mendelzon. Database techniquesfor the world-wide web: A survey. SIGMOD Record, 27(3):59–74, 1998.


12. D.R. Jefferson. Virtual time. ACM Trans. Prog. Lang. and Syst., 7(3):404–425,July 1985.

13. M. Kamath and K. Ramamritham. Efficient transaction management and queryprocessing in massive digital databases. Technical Report UM-CS-1995-093, Uni-versity of Massachusetts, , 1995.

14. J. Kitajima and G. Navarro. A fast distributed suffix array generation algorithm.In 6th International Symposium on String Processing and Information Retrieval,pages 97–104, 1999.

15. M. Marın. Time Warp on BSP Computers. In 12th European Simulation Multi-conference, June 1998.

16. M. Marın. Parallel text query processing using Composite Inverted Lists. In SecondInternational Conference on Hybrid Intelligent Systems (Web Computing Session).IO Press, Feb. 2003.

17. M. Marın and G. Navarro. Distributed query processing using suffix arrays. In Int.Conf. on String Processing and Information Retrieval, Lecture Notes in ComputerScience. Springer-Verlag, Sept. 2003. (to appear).

18. M. Marın and G. Navarro. Suffix arrays in parallel. In International Conferenceon Parallel Processing (EuroPar’03), Lecture Notes in Computer Science, page (toappear). Springer-Verlag, Aug. 2003.

19. A.A. MacFarlane, J.A. McCann, and S.E. Robertson. Parallel search using par-titioned inverted files. In 7th International Symposium on String Processing andInformation Retrieval, pages 209–220. (IEEE CS Press), 2000.

20. W.F. McColl. General purpose parallel computing. In A.M. Gibbons and P. Spi-rakis, editors, Lectures on Parallel Computation, pages 337–391. Cambridge Uni-versity Press, 1993.

21. A. Moffat. Word-based text compression. Software – practice and experience,19(2):185–198, 1989.

22. A. Moffat and A. Turpin. On the implementation of minimum-redundancy prefixcodes. In Data Compression Conference, pages 170–179, 1996.

23. G. Navarro, E. Silva de Moura, M. Neubert, N. Ziviani, and R. Baeza-Yates.Adding compression to block addressing inverted indexes. Information retrieval,3(1):49–77, 2000.

24. G. Navarro, J. Kitajima, B. Ribeiro, and N. Ziviani. Distributed generation ofsuffix arrays. In 8th Annual Symposium on Combinatorial Pattern Matching, pages102–115. (LNCS 1264), 1997.

25. M. Persin, J. Zobel, and R. Sacks-Davis. Filtered document retrieval withfrequency-sorted indexes. Journal of the American Society for Information Sci-ence, 47(10):749–764, 1996.

26. B. Ribeiro-Neto, J. Kitajima, G. Navarro, C. Santana, and N. Ziviani. Parallelgeneration of inverted lists for distributed text collections. In XVIII Conference ofthe Chilean Computer Science Society, pages 149–157. (IEEE CS Press), 1998.

27. B.A. Ribeiro-Neto and R.A. Barbosa. Query performance for tightly coupled dis-tributed digital libraries. In Third ACM Conference on Digital Libraries, pages182–190. (ACM Press), 1998.

28. S.Dandamudi and J.Jain. Architectures for parallel query processing on networksof workstation. In 1997 International Conference on Parallel and Distributed Com-puting Systems, Oct. 1997.

29. D.B. Skillicorn, J.M.D. Hill, and W.F. McColl. Questions and answers about BSP.Technical Report PRG-TR-15-96, Computing Laboratory, Oxford University, 1996.Also in Journal of Scientific Programming, V.6 N.3, 1997.

150 RITOS2

30. D.B. Skillicorn and D. Talia. Models and languages for parallel computation. ACMComputing Surveys, 20(2):123–169, June 1998.

31. T. Tamura, M. Oguchi, and M. Kitsuregawa. Parallel database processing on a100 node pc cluster: Cases for decision support query processing and data mining.In SC’97, 1997.

32. A. Tomasic and H. Garcia-Molina. Performance of inverted indices in shared-nothing distributed text document information retrieval systems. In Second Inter-national Conference on Parallel and Distributed Information Systems, pages 8–17,1993.

33. URL. BSP and Worldwide Standard, http://www.bsp-worldwide.org/.34. URL. BSP PUB Library at Paderborn University, http://www.uni-

paderborn.de/bsp.35. L.G. Valiant. A bridging model for parallel computation. Comm. ACM, 33:103–

111, Aug. 1990.36. C. Yu and C. Chang. Distributed query processing. ACM Computing Surveys,

16(4):399–433, December 1984.


Minería de Datos en la Web usando ComputaciónEvolutiva

Jose Aguilar, Junior Altamiranda

CEMISID, Dpto. de Computación, Facultad de Ingeniería, Av. Tulio Febres. Universidadde los Andes, Mérida 5101, Venezuela

[email protected]

Resumen. La Minería de Datos envuelve un conjunto de métodos para la ex-tracción de conocimiento desde grandes bases de datos. Uno de esos métodosson los de Computación Evolutiva. Particularmente la Programación Genética,es utilizada en este trabajo como herramienta para construir un Sistema de Mi-nería de Datos en la Web que permite definir un conjunto de patrones para cla-sificar los datos contenidos en las páginas web. Para realizar esta tarea se cons-truyó una “gramática”, la cual es usada por la Programación Genética paraconstruir las “reglas” que representan los patrones de los datos contenidos enlas páginas web. De esta forma se pueden agrupar los datos en clases, de mane-ra de simplificar el contenido de las páginas web en un conjunto de patrones in-formativos.

1. Introducción

El incremento en el uso de computadoras y sistemas distribuidos ha generado unaexplosión en la cantidad de información disponible, la cual debe ser procesada pormecanismos sofisticados para poder ser usada eficientemente. Particularmente, Inter-net es un gran deposito de información que crece constantemente. En ella existe unainfinidad de sitios que necesitan ser visitados y clasificados a la hora de hacer unabúsqueda. Existen y son muy conocidas las poderosas herramientas de búsqueda quetratan de encontrar información por categoría o por contenido, tales como Altavista,Yahoo, Google, etc. A estos buscadores se introducen palabras claves y determinanlas paginas o sitios web que contengan estas palabras, tratando de satisfacer los reque-rimientos del usuario. Muchas veces estas consultas traen resultados inconsistentes ydocumentos que cumplen con el criterio de búsqueda, pero no con el interés del usua-rio. Por esta razón, existe un área en computación denominada Minería en la Web(Web Mining), que puede definirse como la aplicación de técnicas de Minería deDatos en Internet para el descubrimiento y análisis de páginas web, y luego extraerpatrones de ellas para clasificar la información.

El Web Mining ofrece ventajas para los usuarios que buscan un tema o productoespecifico y para las personas que diseñan las páginas. Para los usuarios, porque sim-plifica y clasifica la información que se les presenta. Para los que diseñan las páginas,

porque al analizar los patrones obtenidos de los links de las páginas, se puede enten-der el comportamiento y los requerimientos de los navegantes, y así, de esta maneramejorar el diseño de los links de sus páginas. Por esta razón, la necesidad de sistemaspara obtener patrones o reglas clasificadoras desde las páginas web recopiladas poralgunos buscadores (Yahoo, Google, etc.) en una base de datos. Las reglas clasifica-doras permiten clasificar y categorizar la información.

La Minería de Datos, cuya meta es descubrir conocimientos desde un conjunto dedatos del mundo real [7, 8, 9, 11, 12], es un tema de interés para investigadores enáreas tales como: base de datos, aprendizaje automático, programación lógica induc-tiva, inteligencia artificial, estadística, entre otros. Este trabajo sigue el espíritu delárea de Minería de Datos, en particular, estaremos interesados en el conocimientodescubierto expresado como reglas de clasificación “SI <CAUSA> – ENTONCES<CONSECUENCIAS>”. La parte SI de la regla contiene una combinación lógica decondiciones, mientras que la parte ENTONCES contiene atributos que son causadospor la parte SI de la regla.

Por otro lado, existen varios paradigmas para algoritmos de Minería de Datos. Eneste trabajo usaremos la Programación Genética, la cual es una de las técnicas de laComputación Evolutiva. El uso de la Programación Genética para el descubrimientode reglas de clasificación, en el espíritu de la Minería de Datos es un área relativa-mente inexplorada [8]. Se cree que este es un enfoque prometedor, debido a la efi-ciencia de la Programación Genética en la búsqueda y construcción de patrones quese adapten a un entorno según una estructura dada (en nuestro caso, una estructuragramatical). Así, en este trabajo se construirá un Sistema de Minería de Datos queemplea la Programación Genética para descubrir patrones, los cuales son reglas clasi-ficadoras de datos. La Programación Genética utiliza una estructura gramatical, quedefine como debe ser la forma de las reglas clasificadoras permitidas, para controlarlas reglas generadas.

2. Marco Teórico

2.1. Minería de Datos

La Minería de Datos es un término genérico que engloba las técnicas y herramientasusadas para extraer información útil desde grandes bases de datos. En general, lastécnicas de Minería de Datos intentan obtener patrones o modelos a partir de los datosrecopilados, este proceso involucra un análisis de los datos, el reconocimiento depatrones sobre el conjunto de datos y una clasificación o agrupación de los mismos.Los algoritmos de Minería de Datos se enmarcan en un proceso completo de extrac-ción de información conocido como KDD (Knowledge Discovery in Databases), quese encarga, además, de la preparación de los datos y de la interpretación de los resul-tados obtenidos Entre las técnicas que pueden ser usadas en tareas de Minería deDatos tenemos: Arboles de Decisión, Redes Neuronales, Algoritmos Genéticos, Bús-

154 RITOS2

queda de Asociaciones, Programación Genética, Lógica Difusa, etc. Dichas técnicastoman los datos y los transforman en información útil y entendible [7, 8, 9].

2.2. La Computación Evolutiva

La Computación Evolutiva aplica las teorías de la evolución natural y la genética enla adaptación evolutiva de estructuras computacionales, proporcionando un medioalternativo para resolver problemas complejos en diversas áreas. Se basa en la utiliza-ción de una población de posibles soluciones a un problema dado, lo cual es análogoa una población de organismos vivos que evoluciona en cada generación. La Com-putación Evolutiva combina los mejores individuos de la población y transmite lascaracterísticas de dichos individuos a sus descendientes [1].

La Programación Genética fue creada por John Koza a finales de los años 80 [1, 3,4, 5, 6]. En esta técnica, los individuos de la población representan esquemas o pro-cedimientos potenciales de solución al problema a ser optimizado. A la solución ofre-cida por cada individuo se le asigna una aptitud (un valor numérico), la cual indicacuan cercana esta de la solución optima. Nuevos individuos son generados por proce-dimientos análogos a la reproducción biológica, con padres escogidos de la poblaciónexistente con una probabilidad proporcional a su aptitud. Los operadores evolutivosincluyen copia, cruce y mutación, entre otros. Los individuos nuevos reemplazan alos miembros menos aptos de la población, así la aptitud de la población mejorará concada generación, hasta obtener el mejor individuo que representará la solución delproblema

3. Diseño General del Sistema

3.1. Diseño Preliminar

Actualmente, debido a los avances tecnológicos en cuanto a la automatización deprocesos y almacenamiento de los datos, se facilita la recolección de grandes cantida-des de datos. Esta gran cantidad de datos almacenados es una gran fuente de informa-ción, y por lo tanto, de conocimiento. El conocimiento puede ser expresado en laforma de patrones o reglas que describen las propiedades de los datos. Es necesariopoder eficientemente explorar e identificar datos útiles para convertirlos en conoci-miento. Nuestro Sistema de Minería de Datos es capaz de realizar esta tarea de formaautomática. El Sistema de Minería de Datos esta formado por tres componentes:

� Una estructura gramatical general.� Una base de datos que contiene la información a ser clasificada� Un algoritmo que realice la construcción y reconocimiento de patrones, basa-

do en la Programación Genética.


Nuestro Sistema de Minería de Datos trabajará de acuerdo al siguiente macro – al-goritmo:

1. Definición de una gramática general para ser utilizada por la ProgramaciónGenética. La gramática general es usada para describir la manera como se vana construir las reglas clasificadoras. Ella garantiza la construcción de indivi-duos válidos.

2. Extracción de los átomos para la gramática general desde la base de datosobjeto de estudio. Para realizar esta tarea, desde la base de datos se toman pa-labras contenidas en ella (átomos), que serán utilizados por la ProgramaciónGenética para construir las reglas clasificadoras.

3. Utilización de la Programación Genética para construir y evaluar las reglasclasificadoras. En este caso, cada regla clasificadora será un individuo, el cualserá evaluado según su aptitud para agrupar la información. Además, la Pro-gramación Genética proporciona nuevos individuos usando sus mecanismosevolutivos.

El proceso desde el paso 2 es iterado hasta que el conjunto de reglas obtenidas lo-gre clasificar la mayor cantidad de información contenida en la base de datos. Estopermite estar incorporando nueva información desde la base de datos, en forma deátomos, a la gramática general, lo cual enriquecerá el conjunto de reglas que se vayangenerando. Esto es necesario ya que las reglas generadas pueden estar incompletas, esdecir, estas pueden cubrir solo una pequeña fracción de las posibles combinaciones delos distintos átomos que puede proveer una base de datos. Por otro lado, aunque tam-bién se pueden generar reglas sin sentido, la Programación Genética las elimina. ElSistema de Minería de Datos descubrirá un conjunto de reglas validas, suficientes ycomprensibles.

Para medir la suficiencia y la comprensión de las reglas clasificadoras generadaspor nuestro Sistema de Minería de Datos, se debe tener en cuenta que:

� Las reglas clasificadoras deben tener un alto grado de exactitud, es decir, laprobabilidad de que los patrones generados se encuentren frecuentemente enla base de datos debe ser alta. Si la exactitud es 1, significa que la regla se en-cuentra en todos los registros de la Base de Datos. Si la exactitud es un valorcercano a 1, la regla es una regla fuerte. Si la exactitud de la regla no es muyalta, entonces la regla es una regla débil. Nuestro Sistema de Minería de Datosno debe descubrir solo las reglas fuertes, porque las reglas débiles pueden su-ministrar también conocimiento útil [9].

� Las reglas clasificadoras deben ser comprensibles por el usuario. La compren-sibilidad de las reglas es un concepto muy subjetivo. Generalmente, la com-prensibilidad de las reglas esta asociado con la simplicidad sintáctica de lamisma, que consiste en el número de elementos que componen cada uno delos individuos [8].

156 RITOS2

� Las reglas deben identificar las relaciones entre los átomos de la base de datosque no se conocían previamente y que están presentes en los registros.

3.2. Estructura Gramatical Genérica para Construir Reglas Gramaticales

Para construir las reglas clasificadoras es necesario definir la gramática general. Estees un punto critico de nuestro Sistema de Minería de Datos, ya que las reglas genera-das por la Programación Genética dependerán de ella. La población inicial que utilizala Programación Genética para ser evolucionada es creada aleatoriamente usando lagramática general establecida. El uso de la gramática suministra una poderosa repre-sentación del conocimiento y concede gran flexibilidad para la construcción de lasreglas la regla. La gramática se comporta como la plantilla bajo la cual se establece-rán los patrones posibles sobre la información almacenada en la base de datos, permi-tiendo una combinación natural de los átomos para la construcción de los patrones,las cuales siguen la estructura genérica establecida en el conjunto de producciones dela gramática [10]. Un modelo de gramática general para construir un conjunto dereglas clasificadoras es:

� Operador � YONO� Atributo_Nombre �Nombre del campo del átomo extraído de la base de datos

sobre la cual se está realizando la Minería de Datos.� Atributo_Nombre: Atributo_Valor � Valor aleatorio generado desde el

dominio de ese átomo en la base de datos Valor de ese átomo tomado de la base de datos.

� Atributo � Atributo_Nombre:Atributo_Valor� Causa � Atributo (Operador Atributo)*� Consecuencia � Atributo.� Regla � SI Causa ENTONCES Consecuencia.

Las partes CAUSA y CONSECUENCIA están formadas por atributos, dando lugara los siguientes dos tipos de reglas:

Si (atributo) Entonces (atributo)Si (atributo 1) [y/o] (atributo 2)...[y /o] (atributo n) Entonces (atributo).

El modelo de gramatica general presentado anteriormente es el ideal para cualquiertipo de problemas. Ahora, en nuestro caso de determinación de reglas declasificación, en las cuales se estan construyendo patrones basado en los registros quese encuentran en la Base de Datos, el papel del consecuente no es relevante. El mismosi sería importante en un Sistema de Minería de Datos en el cual se quisiera verificarel cumplimiento de las relaciones entre los valores de los campos de una base dedatos, y como estas generan la ocurrencia de un valor en un otro campo. Por lo tanto,


nosotros les hicimos modificaciones a la gramática general, para adaptarla a nuestroproblema:

� Operador � YO� Atributo_Nombre � Nombre del campo del átomo extraído de la base de

datos sobre la cual se esta realizando la Minería de Da-tos.

� Atributo_Nombre: Atributo_Valor � Valor aleatorio generado desde eldominio de ese átomo en la base de datos Valor de ese átomo tomado de la basede datos.

� Atributo � Atributo_Nombre: Atributo_Valor� Causa � Atributo (Operador Atributo)*� Regla Clasificadora Causa.

3.3. Componentes de la Programación Genética para nuestro Sistema

� Función aptitud: La función aptitud nos permite evaluar cómo funciona cadaindividuo (regla) de la población en el problema. Cuando usamos una regla, laidea es caracterizar a un grupo de datos bajo un patrón. Así, la función aptitudusada en este Sistema combina dos indicadores, llamados Exactitud Predictiva(EP) y Simplicidad (Sim).

En el caso de la Exactitud Predictiva de la regla (EP), usando los atributos dela causa de la regla se busca en la base de datos los registros donde se encuen-tra estos términos. Se van contando los registros que los contienen, y luego,este valor se divide entre el número de registros de la base de datos:

gistrosBDRe.No

ivadosBDgistrosActRe.NoEP =

Por otro lado, la Programación Genética no necesariamente produce reglassimples. Considerando que la comprensibilidad de una regla es inversamenteproporcional a su tamaño, tenemos que hacer que la Programación Genéticaproduzca reglas lo más cortas posibles. Por lo tanto, definimos una segundafunción que mide la simplicidad de una regla (Sim), dada por [8]:

1regla_eltosmax_

5.0regla_eltos_num*5.0regla_eltosmax_Sim

−−−=

Donde num_elementos es el número exacto de elementos en la regla, ymax_elementos es el número máximo de elementos permitido en una regla. Laecuación produce su valor máximo en 1.0 cuando una regla es tan simple quesu contenido es solo un término. El valor de la ecuación decrece hasta un valor

158 RITOS2

mínimo de 0.5, que es producido cuando el número de nodos es igual al máxi-mo permitido. La razón por la que Sim baja hasta 0.5 es para penalizar indivi-duos de gran tamaño sin ser forzados a desaparecer. Esto es importante para losindividuos de las primeras generaciones, cuando muchos de ellos tienen muybaja Exactitud Predictiva (EP), pero pueden llevar buen material genético ca-paz de producir mejores individuos al aplicarles los operadores genéticos [8].

Finalmente, el objetivo de la Programación Genética, es maximizar la Exac-titud Predictiva y minimizar simultáneamente el tamaño de la regla (maximizarel valor de Sim). Así, la función aptitud usada por nuestro Sistema esta defini-da como:

Función Aptitud = (EP x Sim)

� Estructura del individuo: Un individuo es una regla clasificadora, por consi-guiente, su estructura tipo árbol describe una posible regla, la cual está forma-da por un conjunto de átomos extraídos de la base de datos que constituyen losterminales, y las funciones YO que son utilizadas para formar las relacionesentre los terminales (ver Fig. 1).

�

� �

VacacionesTurismo NieveHotel

Figura 1. Estructura de un Individuo. (regla clasificadora:((HOTEL Y TURISMO) O (VA-CACIONES Y NIEVE)))

� Conjunto de terminales y funciones: El conjunto de terminales más el conjuntode funciones deben ser capaces de expresar la solución del problema. Por otrolado, las funciones debe aceptar como argumento cualquier valor de la base dedatos que pueda ser usado como terminal, tal como fue definido en la gramáti-ca general. El conjunto Terminal (átomos) consiste de atributos o palabras cla-ves seleccionadas de la Base de Datos existente. El conjunto de Funcionesconsiste de las funciones, llamadas Y y O, de las reglas de producción de lagramática general. Por lo tanto, un individuo (regla) consiste de una combina-ción de las funciones aplicadas a los átomos.

� Tamaño de la población: En nuestro sistema, su rango puede estar entre 0 y99.999 [6]. Tomar un valor elevado para el tamaño de la población sería idealya que nos garantizaría una enorme diversidad de reglas, pero debemos tomaren cuenta el costo computacional.

� Número de generaciones: En nuestro sistema, su rango puede estar entre 1 y32.000 [6]. Mientras mayor sea el número de generaciones nuestro Sistema


podría evolucionar por mucho más tiempo, y así, podría encontrar reglas me-jores, pero se puede producir que después de cierto número de generaciones elconjunto de reglas no mejore.

� Operadores de la programación genética: En nuestro Sistema se usan tresoperadores genéticos:� Cruce: produce dos hijo de dos padres. Los padres son escogidos por me-

dio del valor de la función aptitud. Una parte del primer padre es selec-cionada y reemplazado por una parte compatible del segundo padre paraobtener un hijo. Este mismo procedimiento se realiza para obtener el otrohijo, pero partiendo del segundo padre.

� Mutación: Es una operación que se realiza sobre un individuo. Una partede la regla es seleccionada y reemplazada por una parte generada aleato-riamente. Para generar la parte aleatoria se utiliza la gramática general, deesta manera, la parte seleccionada puede solo mutar a otra parte con unaestructura compatible a la gramática establecida.

� Copia: Selecciona una regla de acuerdo al valor de la función aptitud y latraslada a la generación siguiente sin realizar ningún cambio en su es-tructura.

� Criterio del término de la ejecución: Se establecerá un número máximo de ge-neraciones para evolucionar las reglas, al cumplirse esta, el conjunto de reglasobtenidas en la ultima generación será la solución del problema.

4. Experimentos

Para la Construcción del Sistema se utilizó el Paquete “Estudio de ProgramaciónGenética” [6]. Para realizar la parte experimental se hizo una búsqueda a través deGoogle de las palabras Mérida y Venezuela, obteniéndose como resultado 8.640 re-gistros. Con estos se construyó un archivo texto que contiene por cada registro:

� Titulo de la pagina.� Dirección.� Descripción.

Se realizo una limpieza de los datos eliminando registros repetidos y direccionesde páginas web inconsistentes. Con el archivo de texto resultante se construirán reglasgramaticales utilizando la Programación Genética. Los átomos fueron tomados apartir de las palabras que más se repetían dentro de la base de datos. Los parámetrosde la Programación Genética utilizados para la extracción de las reglas clasificadorasson:

� Número de átomos {4, 6, 8, 10, 12, 14}.� Número de individuos {10, 20, 30, 40, 50, 80, 100, 200, 300}� Número de generaciones {200, 400, 500, 600, 800, 1000}� Probabilidad de cruce {0.9}

160 RITOS2

� Probabilidad de copia {0.1}� Probabilidad de mutación {0.01}� Número máximo de elementos en un individuo = {20, 50}

No se variaron los valores de la probabilidad de cruce, copia y mutación, porqueen pruebas realizadas tomando distintos valores de estos parámetros no se obtuvieroncambios significativos en los resultados de las simulaciones realizadas. Por cuestionesde espacio, a continuación solo se presentaran los resultados más resaltantes, el restode los resultados para diferentes casos de estudio (numero de átomos, etc.) están en[10].

4.1 Simulaciones Iniciales

Utilizamos 10, 12, 15, 20 átomos para las pruebas iniciales: En este trabajo mostrare-mos solos las de 10, para el resto ver [10]. Se tomaron los terminales CONGRESOS,TELEFERICO, TURISMO, HOTEL, VACACIONES, ESTUDIANTES, MONTA-ÑAS, NIEVE, UNIVERSIDAD, ANDES, para generar las reglas clasificadoras. Elcriterio de fin de la ejecución fue 500 generaciones. Con estos datos se obtuvieron lossiguientes resultados:

Figura 2. Diversidad de las Reglas utilizando 10 Atomos.

En la figura 2 podemos ver como al aumentar el número de individuos crece la di-versidad de las reglas, pasando de 0.4 reglas diferentes para 10 individuos a 0.8 reglasdiferentes para 40 individuos. Esto se debe a que cuando se aumenta el número deindividuos, la Programación Genética tiene un mayor espacio de búsqueda sobre elcual aplicar los operadores genéticos, ocasionando que se produzcan más individuosdiferentes.

Diversidad de las Reglas utilizando 10 Atomos

0,4

0,650,733

0,8 0,8

00,10,20,30,40,50,60,70,80,9

10 20 30 40 50

Nº de Individuos

% R

egla

s d

ifer

ente

s


Figura 3. Exactitud Predictiva Promedio de las Reglas VS Nº de Individuos.

En la figura 3 se observa que cuando se aumenta el número de individuos la Exac-titud Predictiva Promedio crece desde 0.7352 para 10 individuos hasta llegar a 0,7775en 100 individuos. Vemos como la Exactitud Predictiva va mejorando, lo cual quieredecir que cuando se aumenta el número de individuos las reglas clasificadoras que seproducen tienen la capacidad de cubrir una mayor cantidad de registros de la base dedatos. Como se dijo antes, esto se debe a que cuando se aumenta el número de indivi-duos la exploración del espacio combinatorio de los átomos se hace más eficiente.

Exactitud Predictiva de las Reglas VS N° de Individuos

0,73520,7387

0,7456

0,7601

0,7664

0,77450,7775

0,71

0,72

0,73

0,74

0,75

0,76

0,77

0,78

0,79

10 20 30 40 50 80 100

N° de Individuos

Exa

ctit

ud

Pre

dic

tiva

Pro

med

io

162 RITOS2

Exactitud Predictiva Promedio de las Reglas VS N° de Generaciones

0,7434

0,7631

0,7699

0,77980,7845

0,72

0,73

0,74

0,75

0,76

0,77

0,78

0,79

200 400 600 800 1000

N° de Generaciones

Exa

ctit

ud

Pre

dic

tiva

P

rom

edio

Figura 4. Exactitud Predictiva Promedio de las Reglas VS Nº de Generaciones

En la figura 4 se ve que la Exactitud Predictiva Promedio de las Reglas va de0,7434 en 200 generaciones hasta 0,7845 en 1000 generaciones. Así, las reglas clasi-ficadoras van evolucionando para ir mejorando levemente el valor de la ExactitudPredictiva.

Figura 5. Nº de Atributos Promedio de las Reglas VS Nº de Individuos.

La figura 5 indica que a medida que se aumenta la cantidad de individuos en laProgramación Genética las reglas clasificadoras que se obtienen se hacen más com-

Nº de Atributos Promedio en las Reglas VS Nº de Individuos

4,7

6,75

8,679,3 9,8

0

2

4

6

8

10

12

10 20 30 40 50

Nº de Individuos

Nº

de

Atr

ibu

tos

Pro

med

io e

n la

s R

egla

s


plejas. Estás pasan de tener en promedio 4,7 atributos para 10 individuos a 9,8 atri-butos para 50 individuos.

REGLA EP Sim EP x Sim

(((UNIVERSIDAD Y ANDES)O MONTAÑAS) O CON-GRESOS)))

0,7607 0,84 0,6389

((UNIVERSIDAD Y ESTUDIANTES)O(CONGRESOS YANDES))

0,7514 0,84 0,6311

((TELEFERICO Y CONGRESOS)O(UNIVERSIDAD Y AN-DES))

0,7422 0,84 0,6234

((ANDES Y ESTUDIANTES) O (VACACIONES Y TURIS-MO))

0,7393 0,84 0,6210

(((UNIVIVESIDAD Y ANDES)O(ESTUDIANTES Y CON-GRESOS))O(TURISMO Y MONTAÑAS))

0,7961 0,78 0,6209

(((UNIVERSIDAD Y ANDES)O(ESTUDIANTES Y UNI-VERSIDAD))O(TURISMO Y NIEVE))

0,7885 0,78 0,6150

((UNIVERSIDAD Y NIEVE)O(HOTEL Y VACACIONES)) 0,7223 0,84 0,6067((((MONTAÑAS O (TURISMO Y ANDES)) O (UNIVERSI-DAD Y ANDES)) O (CONGRESOS Y ESTUDIANTES))

0,8006 0,68 0,5444

(((TURISMO O (NIEVE Y MONTAÑAS)) O (UNIVERSI-DAD Y CONGRESOS)) O (ESTUDIANTES Y VACACIONES))

0,7719 0,68 0,5248

Tabla 1. Exactitud Predictiva y Simplicidad de las mejores reglas utilizando 10 Atomos

Como podemos observar en la Tabla 1, las reglas producidas por nuestro Sistemaclasifican más del 70% de los registros de la base de datos, llegando incluso algunasde ellas a clasificar al 80%, dejando solo 20% de los registros sin clasificar. Por otrolado, la mayoría de las reglas tienen pocos elementos, con lo cual se cumple el criteriode Simplicidad. Particularmente, las reglas con valor de Exactitud Predictiva másaltas poseen bastantes palabras, lo que nos indica que el número de palabras es muyimportante. Así, algo a resaltar es que estas reglas contienen las palabras más repre-sentativas que aparecen en las paginas web con información sobre el Estado Mérida,para un 80% de los casos.

Por otro lado, las reglas conseguidas con alta eficiencia pueden ser divididas en va-rias subreglas, aportando cada una de ellas un porcentaje al valor de la ExactitudPredictiva dado a la regla original. Por ejemplo, en la tabla 1, la primera regla clasifi-cadora con alta Exactitud Predictiva es:

(((UNIVERSIDAD Y ESTUDIANTES) O MONTAÑAS) O CONGRESOS)).

Esta regla puede ser dividida en:

UNIVERSIDADY ESTUDIANTESMONTAÑAS

164 RITOS2

CONGRESOS

Cada una de las subreglas describe un agrupamiento posible de los datos del archi-vo texto (paginas web sobre el Edo. Mérida).

4.2 Comparación con otros trabajos

A continuación presentamos una serie de resultados para un conjunto de pruebas quese hicieron con la finalidad de buscar cual es el valor máximo de la Exactitud Predic-tiva (EP) que se podía obtener con nuestro Sistema de Minería de Datos, y poderlosasí comparar con otros trabajos.

Atomos Genera-ciones

Nº Ind. Regla EP TiempoEjec. (Hrs)

12 500 200 (ESTUDIANTES Y UNIVERSI-DAD)O(HOTEL Y VIA-

JES)O(CONGRESOS Y ESTUDIAN-TES)O(CONGRESOS Y ALOJA-

MIENTO)O(TURISMO Y HO-TEL)O(ESTUDIANTES YALOJA-

MIENTO)O(TELEFERICO Y MON-TAÑAS)O(UNIVERSIDAD Y ANDES)

0.82 1.5

15 500 300 (HOTEL Y ALOJAMIENTO)O(CONFERENCIAS Y CONGRESOS)O

(CONFERENCIAS Y ESTUDIAN-TES)O(RESTAURANT Y VACACIO-

NES)O(VACACIONES Y TURIS-MO)O(NIEVE Y TELEFERI-CO)O(UNIVERSIDAD Y AN-DES)O(VIAJES Y TURISMO)O(ESTUDIANTES Y CONGRE-

SOS) O(TURISMO Y MONTA-ÑAS)O(NIEVE Y TURISMO)

0.88 2.5

Tabla 2. Exactitud Predictiva para algunos casos particulares.

En la Tabla 2 se observa que se obtuvo una regla clasificadora con un valor deExactitud Predictiva (EP) de 0.8860, es decir, la regla descubierta clasifica correcta-mente 311 registros de los 351 contenidos en la base de datos. Al comparar nuestroSistema de Minería de Datos con [8], en el cual el mejor valor de Exactitud Predictiva(EP) que obtuvieron fue de 0.875 para una base de datos de 48 registros, vemos quenuestro sistema logra mejorar dichos resultados. Para estos casos, el tiempo de ejecu-ción de nuestro Sistema de Minería de Datos no es corto para obtener estos resultadosy las reglas obtenidas contienen muchos elementos. La razón de lo primero se debe ala forma de búsqueda de las palabras claves en el archivo texto donde se guarda lainformación conseguida por las herramientas de búsqueda, la cual se realiza secuen-cialmente.


5. Conclusiones

Antes que nada, es bueno recordar que la Minería de Datos es una herramienta explo-rativa y no explicativa, es decir, explora los datos para sugerir hipótesis. Los resulta-dos nuestros van en esa línea. Particularmente, el Sistema de Minería de Datos desa-rrollado en este trabajo permite extraer patrones desde Internet y ser representadoscomo reglas clasificadoras de la información. Para eso, el Sistema utiliza una repre-sentación explícita del conocimiento (gramática general), logrando descubrir relacio-nes que no podrían ser encontradas por un humano.

Los resultados son muy prometedores, ya que el sistema descubre reglas compren-sibles y logra resultados consistentes. Aunque es bueno resaltar que la eficiencia denuestro Sistema de Minería de Datos depende en gran parte de los átomos introduci-dos [10]. Por otro lado, las reglas conseguidas pueden ser divididas en varias subre-glas. Cada una de las subreglas representa un agrupamiento posible de los datos.

Entre las posibles extensiones del Sistema se pueden mencionar:

� El Sistema de Minería de Datos actúa sobre datos previamente recolectados enuna base de datos, es decir, los datos no están cambiando mientras están sien-do analizados. Los resultados generados son confiables para ese conjunto dedatos. En la actualidad, la información contenida en entornos como Internetcambian constantemente, por lo cual, nuestro Sistema debería adaptarse a es-tos cambios de la información y generar patrones o reglas clasificadoras queestén adaptándose continuamente. El macroalgoritmo de la sección 3.1 puedeajustarse a esta situación.

� El sistema podría ser usado para encontrar un conjunto de reglas que describanpropiedades de los datos guardados en una base de datos. La gramática generalpropuesta en la sección 3 fue hecha para realizar esta tarea. Esta modalidad deexploración de datos, permitiría encontrar relaciones del tipo:

Si Compra: Pan y Compra: SalchichasEntonces Compra: Mostaza

Si Persona: Joven y Realiza: DeporteEntonces Practica: Fútbol.

Es decir, serian reglas que dirían que cuando se satisface la CAUSA de laregla, para un conjunto determinado de atributos con valores específicos, gene-rarían como CONSECUENCIA una situación dada. Dichas reglas deberían seranalizadas para tomar decisiones más precisas que sean de utilidad dentro deldominio del problema. Por ejemplo, una posible conclusión ante la regla ante-rior sería poner en oferta las salchichas y los panes, pero subir el precio de lamostaza.

166 RITOS2

Estas son algunas de las posibles aplicaciones que pueden ser realizadas en trabajosfuturos.

Referencias

1. Aguilar J, Rivas F (Ed.), “Introducción a la Computación Inteligente”, Meritec, Mérida –Venezuela, 2001.

2. Aguilar J, “Compiler’s Course”, Houston University, USA, Summer 2000.3. Kinnear K (Ed.), “Advances in Genetic Programming”, The MIT Press, 1994.4. Koza John, "Genetic Programming: On the programming of Computers by Means of Natural

Selection", The MIT Press, 1992.5. Koza John, "Genetic Programming II: Automatic Discovery of Reusable Programs", The

MIT Press, 1994.6. “Manual de Usuario. Estudio de Programación Genética”, Universidad de Córdoba, Escuela

Universitaria Politécnica Andrés del Campo Novales, España, 1998.7. Kovalerchuk B, Vityaev E, Ruiz J, “Consistent Knowledge Discovery in Medical Diagno-

sis”, IEEE Engineering in Medicine and Biology, pp. 26 – 37, July/August 2000.8. Bojarczuk C, Lopes H, Freitas A, “Genetic Programming for Knowledge Discovery in Chest

– Pain Diagnosis”, IEEE Engineering in Medicine and Biology. pp. 38 – 44, July/August2000.

9. Wong M, Lam W, Kwong L, Ngan P, Cheng J, “Discovery Knowledge from Medical Data-bases Using Evolutionary Algorithms”, IEEE Engineering in Medicine and Biology, pp. 45– 55, July/August 2000.

10. Altamiranda J, Aguilar J, “Introducción a la Programación Genética”, Technical Report 20-02, CEMISID, Universidad de los Andes, Mérida – Venezuela, Julio 2001.

11. Aguilar J, "Los Algoritmos Genéticos y la Minería de Datos", Publicado en Gerencia Tec-nológica Informática, Instituto Tecnológico Iberoamericano de Informática, Vol. 1, No. 1,pp. 40-52, 2002.

12. Aguilar J, Altamiranda J, "Un Algoritmo Basado en la Programación Genética para Mineríade Datos", Coautor: J. Altamiranda, Proceeding of the XXVIII Latinoamerican InformaticsConference. Montevideo, Uruguay (11 páginas, CD). Noviembre 2002.


Compresion de textos en Bases de DatosDigitales

Nieves R. Brisaboa1, Antonio Farina1, Gonzalo Navarro3, Eva L. Iglesias2,Jose R. Parama1 y Marıa F. Esteller1

1 Database Lab., Univ. da Coruna, Facultade de Informatica, Campus de Elvina s/n,15071 A Coruna. {brisaboa,fari,parama}@udc.es, [email protected]

2 Dept. de Informatica, Univ. de Vigo , Esc. Sup. de Enxenerıa Informatica, CampusAs Lagoas s/n, 32001, Ourense. [email protected]

3 Dept. of Computer Science, Univ. de Chile, Blanco Encalada 2120, Santiago, [email protected]

Resumen Este trabajo presenta una revision de los metodos decompresion de textos, que permiten la busqueda directa de palabras yfrases dentro del texto sin necesidad de descomprimirlo.Se presentan las tecnicas de compresion basadas en Huffman y dostecnicas mas recientes: el metodo Denso con Post-Etiquetado y elmetodo (s,c)-Denso. Ademas se muestra como estos nuevos metodosson directamente comparables, en tasa de compresion, con las tecnicasbasadas en Huffman y como proporcionan una compresion mas simple yrapida, manteniendo sus caracterısticas mas interesantes. De este modoestas nuevas tecnicas son extremadamente adecuadas para la compresionde textos sobre los que haya que realizar operaciones de Text Retrieval,pues facilita la indexacion y preprocesado de los mismos sin necesidadde descomprimirlos.

1. Introduccion

En los ultimos anos las colecciones de textos han crecido de forma sustancialdebido principalmente a la generalizacion del uso de las bibliotecas digitales,bases de datos documentales, sistemas de ofimatica y la Web.

Aunque la capacidad de los dispositivos actuales para almacenar informacioncrece rapidamente mientras que los costes asociados decrecen, el tamano delas colecciones de texto crece mas rapidamente. Ademas, la velocidad de lacpu crece mucho mas rapidamente que las velocidades de los dispositivosde almacenamiento y de las redes, por lo tanto, almacenar la informacioncomprimida reduce el tiempo de entrada/salida, lo cual es cada vez masinteresante a pesar del tiempo extra de cpu necesario.

Sin embargo, si el esquema de compresion no permite buscar palabrasdirectamente sobre el texto comprimido, la recuperacion de documentossera menos eficiente debido a la necesidad de descomprimir antes de la busqueda.

Las tecnicas de compresion clasicas, como los conocidos algoritmos de Zivy Lempel [14,15] o la codificacion de Huffman [4], no son adecuadas para lasgrandes colecciones de textos.

Los esquemas de compresion basados en la tecnica de Huffman no se utilizancomunmente en lenguaje natural debido a sus pobres ratios de compresion. Porotro lado, los algoritmos de Ziv y Lempel obtienen mejores ratios de compresion,pero la busqueda de una palabra sobre el texto comprimido es ineficiente [6].

En [11] se presentan dos tecnicas de compresion, denominadas Plain Huffmany Tagged Huffman, que permiten la busqueda de una palabra en el textocomprimido (sin necesidad de descomprimirlo) de modo que la busqueda puedeser hasta ocho veces mas rapida para ciertas consultas, al mismo tiempo queobtienen buenos ratios de compresion.

En [3] presentamos un codigo denominado Codigo Denso con Post-etiquetado,que mantiene las propiedades del Tagged Huffman mejorandolo en algunosaspectos: (i) ratio de compresion, (ii) mismas posibilidades de busqueda, (iii)codificacion mas simple y rapida y (iv) una representacion mas simple y pequenadel vocabulario. En [7] presentamos el Codigo (s, c)-Denso, una generalizaciondel Codigo Denso con Post-etiquetado que mejora el ratio de compresion aladaptar el proceso de codificacion al corpus a comprimir.

En este artıculo se describen las tecnicas de compresion que permiten larealizacion de busquedas sobre texto comprimido. En la seccion 2 se introducenlas tecnicas basadas en Huffman. En la seccion 3 se muestra la codificacionDensa con Post-Etiquetado y en la siguiente seccion la codificacion (s, c)-Densa.En la seccion 5 se muestran resultados empıricos que permiten comparar losratios de compresion alcanzados por cada tecnica. Para finalizar se exponen lasconclusiones de este trabajo.

2. Tecnicas de compresion basadas en Huffman

Huffman es un metodo de codificacion ampliamente conocido [4]. La idea dela codificacion Huffman es comprimir el texto asignando codigos mas cortos a lossımbolos mas frecuentes. Se ha probado que el algoritmo de Huffman obtiene,para un texto dado, una codificacion optima de prefijo libre.

Una codificacion se denomina de prefijo libre (o codigo instantaneo) si noproduce ningun codigo que sea prefijo de otro codigo. Un codigo de prefijo librepuede ser decodificado sin necesidad de comprobar codigos futuros, dado que elfinal de un codigo es inmediatamente reconocible.

En los ultimos anos se han desarrollado nuevas tecnicas de compresionespecialmente indicadas para su aplicacion sobre textos en lenguaje natural.Estas tecnicas surgen con la premisa de permitir la realizacion de busquedasdirectamente en el texto comprimido, evitando ası la necesidad de descomprimirantes de buscar. Todas ellas se basan en la utilizacion de las palabras comolos sımbolos a comprimir [5] (en lugar de los caracteres, como sucede en losmetodos clasicos). Esta idea encaja perfectamente con los requerimientos de losalgoritmos de Recuperacion de Textos, dado que las palabras son generalmentelos atomos de dichos sistemas.

En [11] Moura et al. presentan dos esquemas de compresion basados enpalabras que utilizan Huffman para la codificacion. Ambos metodos usan un

170 RITOS2

modelo semi-estatico; esto es, en el proceso de codificacion se realiza una primerapasada para obtener las frecuencias de las n palabras distintas del texto originaly, en una segunda pasada, se lleva a cabo la compresion del texto. Cada palabradel texto original se reemplaza por un codigo que es una secuencia de sımbolosde un alfabeto de codificacion formado por b sımbolos.

Los metodos de Moura et al. siguen la idea principal del metodo Huffmanclasico [4]; esto es, pretenden codificar el texto original de forma que se asignencodigos mas cortos a aquellos sımbolos mas frecuentes. Los codigos generadosson de prefijo libre, lo que significa que ningun codigo es prefijo de otro.

Para la generacion de los codigos Huffman se utiliza un arbol que se construyea partir de las probabilidades de los sımbolos (palabras, en este caso) queforman el texto a comprimir. La construccion del arbol Huffman comienzacreando un nodo hoja por cada palabra del documento original. A continuacionse crea un nodo padre para las [1 + ((n − b)mod(b − 1))] palabras de menorfrecuencia de aparicion [10] (o para las b palabras de menor frecuencia cuando((n − b)mod(b − 1)) = 0). Al nuevo nodo padre se le asigna una frecuencia quees igual a la suma de las frecuencias de sus nodos hijo. Esta operacion se repitesucesivamente eligiendo los b nodos con menor probabilidad (ignorando los nodosque ya son hijos) hasta que quede un unico nodo sin procesar, que sera el nodoraız del arbol (ver [2,9,12] para mas detalle).

Una vez construido el arbol ya se puede calcular el codigo correspondiente acada palabra del vocabulario. Para ello, en cada nivel del arbol se etiquetan lasramas con los diferentes sımbolos del alfabeto de codificacion. El codigo final decada palabra estara formado por la secuencia de sımbolos asignados a las ramasque unen la raız con la hoja que representa dicha palabra.

Mientras el metodo basico propuesto por Huffman es mayormente usadocomo un codigo binario, esto es, cada palabra del texto original es codificadacomo una secuencia de bits, en [16,11] se modifica la asignacion de codigos demodo que a cada palabra del texto original se le asigna una secuencia de bytesen lugar de una secuencia de bits (por lo tanto, el alfabeto esta formado por lossımbolos del 0 al 255 en lugar de los sımbolos 0 y 1). Se denominan por ello,metodos de Codificacion Huffman orientada a byte basada en palabras. Estudiosexperimentales han mostrado que no existe una degradacion significativa en elratio de compresion de textos en lenguaje natural al utilizar bytes en lugar debits. Sin embargo, la descompresion y la busqueda sobre textos comprimidosusando bytes en lugar de bits son mas eficientes debido a que no es necesaria lamanipulacion de bits.

El primero de los metodos presentados en [11], la codificacion Plain Huffman,emplea los 8 bits de cada byte en el proceso de codificacion.

El segundo, denominado Tagged Huffman, reserva un bit de cada byte comomarca, lo que permite distinguir claramente el comienzo de cada codigo dentrodel texto comprimido. En concreto, el primer byte de cada codigo tiene un bitde marca con valor 1, mientras que los bytes restantes del codigo tienen su bitde marca a 0. Al usar un bit de marca, quedan solo disponibles 7 bits de cadabyte para realizar la construccion del arbol Huffman. Observese que el uso del


codigo Huffman sobre los 7 bits restantes de cada byte es obligatorio, dado queel bit de marca no es suficiente para garantizar un codigo de prefijo libre.

Veamos como varıan los codigos generados por ambas codificaciones en elsiguiente ejemplo:

Ejemplo 1 Consideremos un texto con vocabulario A,B,C,D,E, F,G,H, I, Jcuyas frecuencias de aparicion son 0.2, 0.2, 0.15, 0.15, 0.14, 0.09, 0.04, 0.02,0.015, 0.015. En la Figura 1 se muestra un posible arbol para la codificacionPlain Huffman y otro para la Tagged Huffman, suponiendo, por simplicidad,que los sımbolos del alfabeto de codificacion estan formados por 3 bits (en lugarde 8). Los codigos resultantes figuran en el Cuadro 1.

Plain Huffman

E F G

0 0 0 0 0 1 0 1 0

0 1 1

A B C D

1 1 1 1 1 0 1 0 1

1 0 0 H I J

0 0

1

0 0 0

0 1 0 Tagged Huffman

1 0 0

1 0 1

1 1 0

1 1 1

E F

A B C

D

G H I J

0 0 0

0 0 1

0 1 0

0 1 1

0 0 0 0

0 1 0 1 0

0 1 1

Figura1. Arboles para Plain Huffman y Tagged Huffman

El codigo Tagged Huffman tiene un precio en terminos de compresion: sealmacenan bytes completos pero solo se usan 7 bits de cada byte para codificarinformacion. Por lo tanto, el fichero comprimido crece aproximadamente un 11 %con respecto a la codificacion Plain Huffman.

La adicion del bit de marca en el codigo Tagged Huffman permite realizarbusquedas directamente sobre el texto comprimido. Para ello simplemente secomprime el patron y, posteriormente, se utiliza cualquier algoritmo clasicode emparejamiento de patrones. Si se utiliza Plain Huffman esto no funcionacorrectamente debido a que la version codificada del patron puede aparecer enel texto comprimido a pesar de no aparecer en el texto real. Este problema sedebe a que la concatenacion de partes de dos codigos puede formar el codigocorrespondiente a otra palabra del vocabulario. Esta situacion no puede darsecon el codigo Tagged Huffman gracias al uso del bit de marca que, en cada codigodetermina para cada byte si dicho byte es el primero del codigo o no. Por ello,los algoritmos de busqueda usados en Plain Huffman han de tener una fase depostprocesado que permita verificar si una ocurrencia es valida, lo que ocasionauna gran perdida de rendimiento en las busquedas.

3. Codificacion Densa con Post-Etiquetado

El metodo Denso con Post-Etiquetado [3] es un nuevo esquema de compresionque conserva las ventajas de la codificacion Tagged Huffman pero consigue

172 RITOS2

mejores ratios de compresion. Esta nueva tecnica emplea un algoritmo massencillo para la generacion de codigos que aquel y no esta basado en Huffman.Su sencillez a la hora de la codificacion permite agilizar tambien los procesosde compresion y descompresion del texto. Es importante destacar que, a pesarde estas destacables mejoras, se basa igualmente en la utilizacion de marcas quepermiten distinguir los codigos dentro del texto comprimido, por lo que mantienelas mismas posibilidades que la codificacion Tagged Huffman a la hora de realizarbusquedas (exactas o aproximadas) directamente sobre el texto comprimido.

La codificacion Densa con Post-Etiquetado es una codificacion orientada abyte y basada en palabras donde cada codigo esta formado por una secuenciade bytes. Al igual que sucedıa con la codificacion Tagged Huffman, el primer bitde cada byte se emplea como bit de marca. La unica diferencia estriba en que,en lugar de utilizarlo como marca de comienzo de palabra, ahora el bit indica siel byte actual es el ultimo de un codigo o no. En concreto, el bit de marca es 1para el ultimo byte de cada codigo.

Este cambio tiene sorprendentes consecuencias. El que el bit de marca indiqueel final de un codigo es suficiente para asegurar que un codigo no es nunca prefijode otro, sin importar el contenido de los 7 bits restantes, pues unicamente el bitde marca del ultimo sımbolo de cada codigo vale 1. Por lo tanto, ya no es necesarioaplicar codificacion Huffman sobre los 7 bits restantes y se pueden utilizar todaslas combinaciones de 7 bits para cada uno de los sımbolos del codigo.

Proceso de codificacion Una vez eliminada la necesidad de utilizarcodificacion Huffman, el problema reside en encontrar una asignacion de codigosoptima; es decir, una codificacion que minimice la longitud de la salida. Se sigueconservando, por tanto, la idea de asignar codigos mas cortos a las palabras masfrecuentes, como en todas las tecnicas de compresion.

El proceso de codificacion consta de dos fases: en primer lugar se ordenanlas palabras por orden decreciente de frecuencias de aparicion; a continuacionse realiza una asignacion secuencial de codigos a cada palabra utilizando 7 bitsy anadiendo el bit de marca a cada uno de los bytes que componen un codigo.Este bit de marca sera 1 en el caso del primer bit del ultimo byte, y 0 en elcaso del primer bit de cualquier otro byte del codigo. De este modo, la primerapalabra se codificara como 10000000, la 128 como 11111111, la palabra 129como 00000000 10000000 y la 130 como 00000000 10000001. Tras el codigo01111111 11111111 se pasa a 00000000 00000000 10000000, y ası sucesivamente.

La codificacion, por tanto, es extremadamente simple y resulta ser mucho masrapida que la correspondiente a cualquiera de las tecnicas basadas en Huffman,al no ser preciso construir un arbol para realizar la asignacion de codigos.

Al contrario de lo que sucedıa en la codificacion Huffman donde la frecuenciade las palabras influıa en la longitud de los codigos asignados, esta nuevacodificacion no depende de dicha frecuencia sino de la posicion que una palabraocupe dentro del vocabulario (estando este ordenado decrecientemente porfrecuencias). Ası, el codigo asignado a una palabra que ocupe la posicion i,con frecuencia 0.15 sera el mismo que si esa palabra tuviese frecuencia 0.01.


4. Codigos (s,c)-Densos

Como ya se ha visto en la seccion anterior, los Codigos Densos con Post-etiquetado usan 2b−1 valores, desde el 0 hasta el 2b−1 − 1, para los bytes alcomienzo de un codigo (valores no terminales), y utiliza otros 2b−1 valores,del 2b−1 al 2b − 1, para el ultimo byte de un codigo (valores terminales).Pero la pregunta que se plantea ahora es cual es la distribucion optima devalores terminales y no terminales, esto es, para un corpus determinado conuna distribucion de frecuencias de palabras determinada, puede ocurrir que unnumero diferente de valores no terminales (continuadores) y valores terminales(stoppers) comprima mejor que la alternativa de utilizar 2b−1 valores para cadaconjunto. Esta idea ya fue apuntada en [8]. Nosotros definimos los Codigos (s, c)-stop-cont como sigue.

Definicion 1 Dado un conjunto de sımbolos fuente con probabilidades {pi}0≤i<n,una codificacion (s, c)-stop-cont (en la cual c y s son enteros mayores que cero)asigna a cada sımbolo fuente i un codigo unico formado por una secuencia desımbolos de salida en base c y un sımbolo final que estara entre c y c + s − 1.

Hemos llamado a los sımbolos que estan entre 0 y c − 1 “continuadores” ya aquellos entre c y c + s − 1 “stoppers”. Por lo tanto, cualquier codigo (s, c)stop-cont es de prefijo libre.

Entre todas las posibles codificaciones (s, c) stop-cont para una distribucionde probabilidades dada, el codigo denso es la que minimiza la longitud media delos sımbolos.

Definicion 2 Dado un conjunto de sımbolos fuente con probabilidadesdecrecientes {pi}0≤i<n, los codigos correspondientes a su codificacion (s, c)-Denso ((s, c)-DC) se asignan de la siguiente manera: sea k ≥ 1 el numero debytes del codigo correspondiente a un sımbolo fuente i, entonces k sera tal que:

s ck−1−1c−1 ≤ i < s ck−1

c−1

Ası, el codigo correspondiente al sımbolo fuente i estara formado por k − 1sımbolos (de salida) en base-c y un sımbolo final. Si k = 1 entonces el codigo essimplemente el stopper c+ i. De otro modo el codigo estara formado por el valor

bx/sc escrito en base c, seguido por c + (x mod s), en el cual x = i − sck−1−sc−1 .

Ejemplo 2 Los codigos asignados a los sımbolos i ε 0 . . . 15 por un (2,3)-DC seran:〈3〉, 〈4〉, 〈0,3〉, 〈0,4〉, 〈1,3〉, 〈1,4〉, 〈2,3〉, 〈2,4〉, 〈0,0,3〉, 〈0,0,4〉, 〈0,1,3〉, 〈0,1,4〉,〈0,2,3〉, 〈0,2,4〉, 〈1,0,3〉 y 〈1,0,4〉.

Observe que los codigos no dependen en las probabilidades exactas de cadasımbolo sino es su ordenacion por frecuencia.

Dado que con k dıgitos obtenemos sck−1 codigos diferentes, denominamos

W sk =

∑kj=1 scj−1 = s ck−1

c−1 , (donde W s0 = 0) al numero de sımbolos fuentes que

174 RITOS2

pueden ser codificados con hasta k dıgitos. Denominamos f sk =

∑W sk

j=W sk−1

+1 pj a

la suma de probabilidades de los sımbolos fuente codificadas con k dıgitos porun (s, c)-DC.

Entonces, la longitud media de los codigos para tal (s, c)-DC, LD(s,c), es

LD(s,c) =

Ks∑

k=1

kfsk =

Ks∑

k=1

k

W sk

∑

j=W sk−1

+1

pj = 1 +

Ks−1

∑

k=1

k

W sk+1

∑

j=W sk+1

pj = 1 +

Ks−1

∑

k=1

W sk

∑

j=W sk+1

pj

Kx = dlog(2b−x)

(

1 + n(2b−x−1)x

)

e y n es el numero de sımbolos en el vocabulario.

Por la Definicion 2 el codigo denso con Post-Etiquetado [3] es un (2b−1,2b−1)-DC y por ello (s,c)-DC puede ser visto como una generalizacion del codigodenso con Post-Etiquetado en el que s y c han sido ajustados para optimizar lacompresion segun la distribucion de frecuencias del vocabulario.

En [3] esta probado que (2b−1,2b−1)-DC es de mayor eficiencia que el TaggedHuffman. Esto es debido a que el Tagged Huffman es un codigo (2b−1,2b−1) (nondense) stop-cont, mientras que el metodo denso con Post-Etiquetado sı es uncodigo (2b−1,2b−1)-Denso.

Ejemplo 3 El Cuadro 1 muestra los codigos asignados a un pequeno conjuntode palabras ordenadas por frecuencia usando el Plain Huffman (P.H.), (6,2)-DC, metodo denso con Post-Etiquetado (ETDC) que es un (4,4)-DC, y TaggedHuffman (TH). Por simplicidad se han utilizado sımbolos de tres bits (b=3 ).Las ultimas cuatro columnas muestran el producto del numero de bytes porlas frecuencia de cada palabra y su suma (la longitud media de los codigos), semuestra en la ultima fila.

Los valores (6,2) para s y c no son los optimos sino que una codificacion (7,1)-Densa obtendrıa el texto comprimido optimo, siendo en este ejemplo el mismoresultado que en el Plain Huffman. El problema ahora consiste en encontrar losvalores s y c (asumiendo un b fijo donde 2b = s + c) que minimice el tamano deltexto comprimido.

Frec × bytesPalabra Frec P.H. (6,2)-DC ETDC T.H. P.H. (6,2)-DC ETDC T.H.

A 0.2 [000] [010] [100] [100] 0.2 0.2 0.2 0.2B 0.2 [001] [011] [101] [101] 0.2 0.2 0.2 0.2C 0.15 [010] [100] [110] [110] 0.15 0.15 0.15 0.3D 0.15 [011] [101] [111] [111][000] 0.15 0.15 0.15 0.3E 0.14 [100] [110] [000][100] [111][001] 0.14 0.14 0.28 0.28F 0.09 [101] [111] [000][101] [111][010] 0.09 0.09 0.18 0.18G 0.04 [110] [000][010] [000][110] [111][011][000] 0.04 0.08 0.08 0.12H 0.02 [111][000] [000][011] [000][111] [111][011][001] 0.04 0.04 0.04 0.05I 0.005 [111][001] [000][100] [001][100] [111][011][010] 0.01 0.01 0.01 0.015J 0.005 [111][010] [000][101] [001][101] [111][011][011] 0.01 0.01 0.01 0.015

Tamano total comprimido 1.03 1.07 1.30 1.67

Cuadro1. Comparativa entre metodos de compresion


4.1. Valores s y c optimos: Unicidad del mınimo

Antes de dar un algoritmo para obtener los valores optimos para s y c,s + c = 2b y 1 ≤ s ≤ 2b − 1, necesitamos mostrar que el tamano del textocomprimido decrece a medida que se incrementa s hasta alcanzar el valor soptimo. Tras este punto, al incrementar el valor de s, se produce una perdida enel ratio de compresion. Este hecho se muestra en la figura 2. Recordemos que elvalor de c depende del valor de s pues c = 2b − s.

Aunque disponemos de una demostracion formal de la unicidad de un valoroptimo de s, debido a su complejidad, se ha decidido incluir aquı una explicacionintuitiva de dicha propiedad que permite entrever el camino seguido en dichademostracion pero sin profundizar en detalles.

Se puede observar que cuando s toma valores muy pequenos (proximos a 1), elnumero de palabras muy frecuentes que se pueden codificar con pocos bytes (unoo dos bytes) es tambien muy pequeno (s palabras pueden ser codificadas con unbyte y s ·c con dos bytes). Pero en este caso c es grande, y por tanto hay un grannumero de palabras de baja frecuencia que estan siendo codificadas con pocosbytes (s·c2 palabras se codifican con 3 bytes, s·c3 con 4 bytes ası sucesivamente),pero cuando c es muy grande, normalmente 3 bytes son suficientes para codificarla ultima palabra del vocabulario (la menos frecuente).

Es facil de ver que, a medida que s crece, mas palabras de alta frecuencia soncodificadas con menos bytes, lo que incrementa su compresion. Pero al mismotiempo, cuando el valor de s aumenta, las palabras de menor frecuencia necesitanmas bytes para codificarse, lo que reduce la compresion de estas palabras.

Como consecuencia, si se prueban todos los valores posibles de s, comenzandoen s = 1, se observa (Figura 2) que, al principio, la compresion creceenormemente debido a que el aumento de s origina que las palabras de altafrecuencia se codifiquen con codigos mas cortos. Poco a poco, para cadaincremento de s, la ganancia de compresion obtenida al codificar con pocos byteslas palabras mas frecuentes se ve contrarrestada por el incremento del tamanode los codigos utilizados en la codificacion de las palabras menos frecuentes.Existe un punto donde esta ganancia comienza a ser menor que la perdida decompresion debida a las palabras menos frecuentes. Este punto nos indica elvalor optimo de s.

En la Figura 2 se muestran los ratios de compresion para dos corpus dados,en funcion del valor de s. Se puede observar como los valores de compresioncercanos al optimo son practicamente insensibles al valor de s. Este hecho es elque da lugar a que la curva sea muy suave en su parte inferior.

Nuestro algoritmo saca ventaja de esta propiedad. De esta forma no esnecesario comprobar el ratio de compresion alcanzado con todos los valores de sposibles, sino que al conocer la forma de la distribucion del ratio compresion enfuncion de s, es posible buscar unicamente en la direccion en la que los valoresde s originan una mejora en el ratio de compresion.

176 RITOS2

0 50 100 150 200 25026

28

30

32

34

36

38

40

values of s

com

pres

sion

rat

io (

%)

ZIFFSpanish

Figura2. Tamano del texto comprimido en funcion de s.

4.2. Algoritmo para obtener los valores optimos de s y c

En esta seccion se describe un algoritmo para buscar el mejor s y,consecuentemente, c para un corpus y un b dado. El algoritmo basico presentadoes una busqueda binaria que calcula inicialmente el tamano del texto para dosvalores consecutivos de s: (b2b−1c − 1 y b2b−1c). Mediante la propiedad de launicidad del mınimo, sabemos que existe a lo sumo un mınimo local, por lo queel algoritmo dirige la busqueda hasta obtener el punto que proporcione el mejorratio de compresion. En cada iteracion del algoritmo, el espacio de busqueda sereduce a la mitad y se calcula la compresion en dos puntos centrales del nuevointervalo, lo que permite dirigir la busqueda en la direccion deseada.

El algoritmo findBestS calcula el mejor valor para s y c para un b y unalista de frecuencias acumuladas dadas. El tamano del texto comprimido (enbytes) se calcula, para unos valores especıficos de s y c, mediante la funcionComputeSizeS

Finalmente se devuelven los valores de s y c que minimizan el tamano deltexto comprimido.

findBestS (b, freqList)

//Entrada: b valor (2b = c + s).//Entrada: Una Lista de frecuencias acumuladas ordenadas por orden decreciente de frecuencia.//Salida: Los mejores valores para s y c

begin

Lp := 1; //Lp y Up puntos menor y mayor

Up := 2b − 1; // del intervalo que se compruebawhile Lp + 1 < Up do

M := bLp+Up

2c

sizePp := computeSizeS(M − 1, 2b − (M − 1), freqList)// tamano con M-1

sizeM := computeSizeS(M, 2b − M, freqList)// tamano con M

if sizePp < sizeM then

Up := M − 1else Lp := Mend if

end while

if Lp < Up then //Lp = Up − 1 y M = Lp

sizeNp := computeSizeS(Up, 2b − Up, freqList); // tamano con M+1

if sizeM < sizeNp then

bestS := M


else bestS := Upend if

else bestS := Lp //Lp = Up = M − 1end if

bestC := 2b − bestSreturn bestS, bestC

end

Para cualquier s y c, el siguiente algoritmo calcula el tamano del textocomprimido.

computeSizeS (s, c, freqList)//Entradas: s, c, y una lista de frecuencias acumuladas//Salida: tamano del texto comprimido s,cbegin

k := 1, n := number ofwords in ′freqList′

Right := min(s, n); Left := Right;total := freqList[Right − 1];while Right < n do

Left := Right;

Right := Right + sck;k := k + 1if Right > n then

Right := nend if

total := total + k ∗ (freqList[Right − 1] − freqList[Left])end while

return totalend

Calcular el tamano del texto comprimido para un valor especıfico de stiene un coste de O(logc n), excepto para c = 1, en cuyo caso su coste es deO(n/s) = O(n/2b). La secuencia mas cara de llamadas a computeSizeS enuna busqueda binaria es la de valores c = 2b−1, c = 2b−2, c = 2b−3, . . .,c = 1. El coste total de computeSizeS sobre esa secuencia de valores c esn2b +

∑b−1i=1 log2b−i n = n

2b + log2 n∑b−1

i=11

b−i = O(

n2b + log n log b

)

.Las demas operaciones de la busqueda binaria son constantes, aunque

tenemos un coste extra de O(n) para calcular las frecuencias acumuladas. Portanto, el coste total de encontrar s y c es O(n+log(n) log(b)). Puesto que el mayorb de interes es aquel tal que b = dlog2 ne (en este punto podemos codificar cadasımbolo usando un unico stopper), el algoritmo de optimizacion tiene un costea lo sumo de O(n + log(n) log log(n)) = O(n), suponiendo que el vocabularioestuviera ya ordenado.

El algoritmo de Huffman es tambien linear una vez el vocabularioesta ordenado, pero resulta mas lento en tiempo debido a que las operacionesque se deben realizar para la construccion del arbol son mas costosas que lasrealizadas en la obtencion de los valores s y c optimos.

5. Resultados empıricos

Hemos utilizado algunas colecciones grandes de textos del trec-2 (APNewswire 1988 y Ziff Data 1989-1990) y del trec-4 (Congressional Record 1993,Financial Times 1991, 1992, 1993 y 1994). Tambien hemos usado un corpus deliteratura espanola que creamos previamente. Se han comprimido todos ellos

178 RITOS2

usando Plain Huffman, Codigo (s,c)-Denso, Denso con PostEtiquetado y TaggedHuffman. Para crear el vocabulario hemos utilizado el modelo spaceless [10] queconsiste en que si una palabra va seguida de un espacio tan solo se codifica lapalabra.

Hemos excluido el tamano del vocabulario comprimido en los resultados (porser despreciable y similar en todos los casos)

Corpus Tamano original Palabras del Voc θ P.H. (s,c)-DC ETDC T.H.

AP Newswire 1988 250,994,525 241,315 1.852045 31.18 (189,67) 31.46 32.00 34.57Ziff Data 1989-1990 185,417,980 221,443 1.744346 31.71 (198,58) 31.90 32.60 35.13Congress Record 51,085,545 114,174 1.634076 27.28 (195,61) 27.50 28.11 30.29Financial Times 1991 14,749,355 75,597 1.449878 30.19 (193,63) 30.44 31.06 33.44Financial Times 1992 175,449,248 284,904 1.630996 30.49 (193,63) 30.71 31.31 33.88Financial Times 1993 197,586,334 291,322 1.647456 30.60 (195,61) 30.79 31.48 34.10Financial Times 1994 203,783,923 295,023 1.649428 30.57 (195,61) 30.77 31.46 34.08Spanish Text 105,125,124 313,977 1.480535 27.00 (182,74) 27.36 27.71 29.93

Cuadro2. Comparacion de los ratios de compresion.

El Cuadro 2 muestra los ratios de compresion obtenidos para los corpusmencionados. La segunda columna contiene el tamano original del corpusprocesado y las siguientes columnas indican el numero de palabras delvocabulario, el parametro θ de la Ley de Zipf [13,1] y el ratio de compresion paracada metodo. La sexta columna, que se refiere al metodo (s, c)-DC, proporcionalos valores optimos de (s, c) encontrados usando el algoritmo findBestS.

Como se puede observar, Plain Huffman obtiene el mejor ratio de compresion(como cabıa esperar por ser la codificacion optima de prefijo libre) y el metododenso con PostEtiquetado siempre obtiene mejores resultados que el TaggedHuffman, con una mejora de hasta 2.5 puntos. Como esperabamos, (s, c)-DCmejora los resultados obtenidos por (128, 128)-DC (ETDC). De hecho, (s, c)-DCes mejor que (128, 128)-DC en mas de 0.5 puntos y peor que Plain Huffman enmenos de 0.5 puntos de media.

6. Conclusiones

Se ha presentado una revision de los metodos de compresion que permitenbusqueda sobre texto comprimido. Se han mostrado los metodos basados enHuffman, centrandonos especialmente en el Tagged Huffman. Tambien se hancomentado las mejoras aportadas por la Codificacion Densa con Post-Etiquetadoy la generalizacion de este: la codificacion (s, c)-Densa. Esta codificacion mejorael ratio de compresion respecto a la Densa con Post-Etiquetado, adaptandosus parametros (s, c) al corpus que sera comprimido. Se ha proporcionado unalgoritmo que calcula los valores optimos de s, c que maximizan la compresion.

Hemos presentado algunos resultados empıricos comparando nuestros dosmetodos con otros codigos de similares caracterısticas. Se observa que nuestroscodigos siempre son mejores que el Tagged Huffman, obteniendo tan solo un 0.5 %menos de ratio de compresion sobre la codificacion optima Huffman. Ademas el


metodo (s, c) − Denso y el Denso con Post-Etiquetado resultan mas rapidos ysimples de construir.

Referencias

1. R. Baeza-Yates and B. Ribeiro-Neto. Modern Information Retrieval. Addison-Wesley Longman, May 1999.

2. T. C. Bell, J. G. Cleary, and I. H. Witten. Text Compression. Prentice Hall, 1990.3. N. Brisaboa, E. Iglesias, G.Navarro, and J. Parama. An efficient compression code

for text databases. In 25th European Conference on IR Research, ECIR 2003,LNCS 2633, pages 468–481, 2003.

4. D. A. Huffman. A method for the construction of minimum-redundancy codes.Proc. Inst. Radio Eng., 40(9):1098–1101, 1952.

5. A. Moffat. Word-based text compression. Software - Practice and Experience,19(2):185–198, 1989.

6. G.Navarro and J. Tarhio. Boyer-Moore string matching over Ziv-Lempelcompressed text. In Proc. 11th Annual Symposium on Combinatorial PatternMatching (CPM 2000), LNCS 1848, pages 166–180, 2000.

7. GonzaloNavarro Nieves R. Brisaboa, Antonio Farina and Maria F. Esteller. (s,c)-dense coding: An optimized compression code for natural language text databases.In String Processing and Information Retrieval, to appear, Manaos, Brazil, 2003.

8. J. Rautio, J. Tanninen, and J. Tarhio. String matching with stopper encodingand code splitting. In Proc. 13th Annual Symposium on Combinatorial PatternMatching (CPM 2002), LNCS 2373, pages 42–52, 2002.

9. David Salomon. Data Compression: The Complete Reference. Springer-Verlag,Berlin, Germany /Heidelberg, Germany /London, UK /etc., 2o edition, 2000.

10. E. Silva de Moura, G.Navarro, N. Ziviani, and R. Baeza-Yates. Fast searching oncompressed text allowing errors. In Proc. 21st Annual International ACM SIGIRConference on Research and Development in Information Retrieval (SIGIR-98),pages 298–306, 1998.

11. E. Silva de Moura, G.Navarro, N. Ziviani, and R. Baeza-Yates. Fast and flexibleword searching on compressed text. ACM Transactions on Information Systems,18(2):113–139, 2000.

12. Ian H. Witten, A. Moffat, and Timothy C. Bell. Managing Gigabytes: Compressingand Indexing Documents and Images. Morgan Kaufmann Publishers, USA, 1999.

13. G.K. Zipf. Human Behavior and the Principle of Least Effort. Addison-Wesley,1949.

14. J. Ziv and A. Lempel. A universal algorithm for sequential data compression.IEEE Transactions on Information Theory, 23(3):337–343, 1977.

15. J. Ziv and A. Lempel. Compression of individual sequences via variable-rate coding.IEEE Transactions on Information Theory, 24(5):530–536, 1978.

16. Nivio Ziviani, Edleno Silva de Moura, G. Navarro, and Ricardo Baeza-Yates.Compression: A key for next-generation text retrieval systems. IEEE Computer,33(11):37–44, 2000.

180 RITOS2

Obtención automática de información sintáctica para un diccionario de patrones de manejo

para el lenguaje español*

Sofía N. Galicia-Haro, Alexander F. Gelbukh e Igor A. Bolshakov

Centro de Investigación en Computación Instituto Politécnico nacional Av. Juan de Dios Batiz S/N

07738 México, D. F. {sofia, gelbukh, igor }@cic.ipn.mx

Resumen El procesamiento de lenguaje natural requiere el análisis sintáctico como una de las etapas iniciales del análisis. En el enfoque de constituyentes, para limitar la gran cantidad de variantes de estructura sintáctica, originada por la complejidad combinatoria en el análisis sintáctico mediante computadora, se han desarrollado métodos automáticos de obtención de marcos de subcategorización. Basándonos en el análisis de algunas características del español, para su análisis sintáctico proponemos la aplicación del formalismo de dependencias. Con esta finalidad se presenta un nuevo formato para los denominados patrones de manejo y un método de obtención automática de la información sintáctica para ellos. Esta información es de gran utilidad en generación de textos y en la enseñanza del lenguaje español a extranjeros, entre otras aplicaciones.

1 Introducción

La importancia del empleo de marcos de subcategorización en el análisis sintáctico ha sido establecida en diversos trabajos. En el enfoque de constituyentes, existen varias líneas de investigación en la obtención de marcos de subcategorización en forma automática [4; 1]. En cambio, en el enfoque de dependencias el trabajo manual es la forma tradicional de obtener la información sintáctica. Mientras en el enfoque de constituyentes se consideran clases que agrupan información sintáctica para varios verbos, en el enfoque de dependencias se considera de forma individual para verbos, adjetivos y sustantivos.

En el enfoque de dependencias, las valencias semánticas corresponden a los participantes (o actantes) implicados en el significado específico de los verbos, adjetivos y sustantivos. Este enfoque presenta ventajas en la descripción de lenguajes con restricciones menos estrictas en el orden de palabras y con uso amplio de preposiciones simples y compuestas. Este método considera también la correspondencia entre las valencias semánticas y sus realizaciones sintácticas, y la * Trabajo realizado bajo apoyo parcial de CGEPI-IPN, SNI y CONACyT, México.

relación entre valencias y significado de la palabra, las cuales se describen en un patrón de rección o de manejo sintáctico.

El trabajo que aquí se presenta tiene el objetivo de compilar automáticamente un diccionario de patrones de manejo sintáctico para el español en cuanto a información sintáctica se refiere, para lo cuál se propone un método estadístico que utiliza un corpus grande de textos.

En este artículo, primero se describen los patrones de manejo avanzados, presentando su origen en la Meaning ⇔ Text Theory (MTT), discutiendo algunas características del español que tienen una representación más adecuada bajo este formalismo y proponiendo una nueva estructura que considera las características mencionadas. En segundo lugar se describe el método propuesto para la compilación del diccionario. Finalmente se discuten algunas aplicaciones de la información obtenida

2 Patrones de Manejo Avanzados

2.1 Patrones de Manejo en la MTT

En la MTT [5] se describe, con la ayuda de una tabla de patrones de manejo (PM), la información de correspondencia entre las valencias semánticas y sintácticas de la palabra encabezado, todas las formas en que se realizan las valencias sintácticas y la indicación de obligatoriedad de la presencia de cada actante, si es necesario.

Después de la tabla de PM se presentan dos secciones: restricciones y ejemplos. Las restricciones consideradas son de todo tipo: semánticas, sintácticas o morfológicas. La sección de ejemplos cubre todas las posibilidades: ejemplos para cada actante, ejemplos de todas las posibles combinaciones de actantes, y finalmente los ejemplos de combinaciones imposibles o indeseables.

La parte principal de la tabla de PM es la lista de valencias sintácticas de la palabra encabezado. Se listan de una manera arbitraria pero se prefiere el orden de incremento en la oblicuidad. También la forma de expresión del significado1 de la palabra encabezado influye en el orden, por ejemplo la expresión para acusar1: Person V accuses person W in action X. Esta expresión precede cada PM.

A continuación se presenta un ejemplo, el verbo acusar1, aunque una descripción más amplia de este diccionario aparece en [2]. En esta descripción GN representa un sintagma nominal e INF representa un verbo en infinitivo.

1 = V 2 = W 3 = X 1. GN 2. a GN 1. de GN

2. de INF Obligatoria Obligatoria

1 Una descripción corta en inglés para evitar el uso de palabras específicas en español.

182 RITOS2

Posibles: C.1 + C.2 La policía acusa a Ana. C.1 + C.2 + C.3.1 La policía acusa a Ana de robar.Prohibidas: C.1 + C.3.1 La policía acusa de robar.

2.2 Características del español

Algunas características del español no tienen una representación adecuada en los formalismos de constituyentes. De entre ellas se consideran el orden de palabras, el objeto directo y la animidad, y la repetición de valencias. Los ejemplos se tomaron de un corpus grande del español: LEXESP2.

2.2.1 Orden de palabras El orden de palabras en el español es más libre que en otros lenguajes como el inglés. Por ejemplo, en las frases siguientes el objeto indirecto no aparece después del verbo, de tres maneras distintas: 1) en la forma de pronombre antes del verbo, 2) como pronombre reflexivo entre sujeto y verbo, y 3) como clítico dentro del verbo. 1. A quienes acusan de comportamiento arrogante. 2. El fiscal me acusa de delito de alta traición. 3. Acusándole de ser el sostenedor y portavoz de Mario Segni.

Para el análisis sintáctico del español, esta información de posibles posiciones de cada valencia es necesaria, y corresponde a las combinaciones posibles en los PM.

2.2.2 Objeto directo En muchos lenguajes europeos el objeto directo está conectado con el verbo sin preposiciones; pero en español, las entidades animadas están conectadas mediante la preposición a y las no animadas directamente (veo a mi vecina y veo una casa). La animidad se considera como una personificación. Además de personas, la animidad abarca grupos de personas, animales, países, entidades abstractas (organizaciones, partidos políticos), etc. En cambio, por ejemplo, en ruso los grupos de personas, los países, las ciudades no se personifican en sentido gramatical.

Así que la animidad es una característica evidentemente sintáctica pero con alusión semántica que se considera para la realización de las valencias, por ejemplo: a GN(an) para la valencia W de acusar1.

2.2.3 Valencias repetidas Generalmente las entidades referidas por diversas valencias son diferentes. Esta es una situación normal en lenguajes naturales, cada valencia semántica puede representarse en el nivel sintáctico mediante un solo actante.

2 El corpus LEXESP fue proporcionado amablemente por H. Rodríguez, UPC-LSI, Barcelona,

España.


Sin embargo, existen lenguajes como el español que permite la duplicación de valencias. Los siguientes ejemplos muestran en cada oración dos grupos en negritas que representan el mismo objeto: • Arturo le dio la manzana a Víctor. • El disfraz de Arturo, lo diseñó Víctor. • A Víctor le acusa el director.

Mientras que en la primera oración se duplica el objeto indirecto, en las siguientes oraciones se duplica el objeto directo. Mientras en la primera oración la repetición es opcional, en las siguientes es obligatoria. El orden de palabras y los verbos específicos imponen algunas construcciones.

2.3 Formato de los PMA

Se propone una nueva estructura que considera las características mencionadas del español, además de un formato modernizado. La nueva estructura se basa en un sistema de atributo-valor. El nuevo formato se denomina Patrones de manejo avanzados (PMA).

En la Figura 1 se presenta la estructura formal y la notación de los PMA. El primer atributo denominado Lexema corresponde a la palabra encabezado. El segundo atributo, descripción, corresponde a la segunda sección de los PM, la explicación semántica de la situación relacionada a cada verbo específico.

El tercer atributo, valencias, corresponde a la tabla de patrones de manejo, las realizaciones de las valencias sintácticas se describen recursivamente con una matriz atributo – valor. El índice de realización se utiliza para las valencias repetidas. En cada realización se permiten los siguientes atributos: palabra introductora, categoría gramatical, tipo semántico y peso. Las palabras introductoras son preposiciones simples o compuestas, principalmente, aunque también pueden ser palabras que introducen cláusulas subordinadas, como que, o φ en el caso de una realización con grupo nominal. Las categorías gramaticales son de cualquier tipo. Por ahora, los descriptores semánticos considerados son animados y locativos.

[ ]

+

∅

∅

* peso)X W~ V (como nescombinacionesCombinacio

*

100% ... 0 peso...|locativo |animado | ánticosem tipo

... |V_INF|GNaícategor ... |nespreposicio|raintroducto palabra

nRealizació

n,...,3,2,1nrealizaciódeíndiceZY,X,W,V,Valencia

Valencias

Z)..., W,(V, asen valenci basada semántica-sintáctico FórmulanóDescripci)(Lexema

kji

núnicoosignificadverbo

Figura 1. Estructura formal de los PMA

Aquí: + denota uno o más elementos; * denota cero o más elementos; ~ denota el verbo.

184 RITOS2

El peso define las probabilidades de llenado de diferentes valencias. Este valor tiene aplicación inmediata en análisis sintáctico y en filtros para rechazar resultados intermedios imposibles o no deseados. La condición de obligatoriedad se marca con un peso de 100%.

El último atributo, corresponde a los ejemplos de combinaciones posibles y de las combinaciones no permitidas. Las cuales se consideran de una forma diferente, mediante una medida probabilística.

3 Método estadístico

La información necesaria para llenar estos PMA es la información usual de los marcos de subcategorización más la relación de esta información sintáctica con las valencias, las características semánticas (animado, locativo), y las estadísticas del uso común.

Para el español, no hay diccionarios con información completa de subcategorización y sólo existen algunos intentos para la adquisición automática de marcos de subcategorización [7]. Tomando en cuenta que el español tiene restricciones menos estrictas en el orden de palabras, la combinación de complementos resulta en un problema complejo. Por lo que se propone un método de desambiguación. El método se basa en las estadísticas de los errores que un analizador sintáctico específico empleado para el análisis de textos hace en unos documentos determinados. Para cada frase, se determina un peso (o probabilidad) para cada variante.

Como ejemplo se presenta la frase: Trasladaron la filmación desde los estudios hasta el estadio universitario. A esta frase puede asignársele al menos las interpretaciones sintácticas mostradas en la Figura 2 donde aparecen árboles de dependencias simplificados para cinco variantes. Para este ejemplo, un hablante nativo escogería la primera estructura como la interpretación más probable, tomando en cuenta cierta información léxica. Así que un analizador sintáctico requiere información léxica para desambiguar la frase, es decir, para seleccionar la estructura correcta de entre todas las variantes asignadas.

Como ya se mencionó, dicha selección se realiza en términos cuantitativos, asignando un peso o una probabilidad a cada variante; a mayor peso mayor la probabilidad de que la variante sea la correcta. En nuestro caso, se trabaja con las estadísticas de marcos de subcategorización individuales a los que llamamos combinaciones. Por ejemplo el árbol número 1 de la Figura 2 contiene solamente una combinación: trasladar +desde +hasta +?, el árbol número 3 contiene: trasladar +?, filmación +desde +hasta, donde ? es un grupo nominal.

La selección de estas combinaciones no es aleatoria, en buen grado son realmente fijas para cada palabra, así que sus estadísticas son más confiables que las de pares de palabras arbitrarias .

La desambiguación propuesta se basa en las frecuencias de esas combinaciones, en las variantes correctas (pi

+) y en los árboles generados por el analizador pero rechazados por revisores (pi

–). No es un gran problema calcular esos pesos si se cuenta con texto marcado sintácticamente. Sin embargo, para un área específica, para


un género determinado o para un lenguaje como español o ruso, no se dispone de esa información.

En nuestro método hay dos metas interrelacionadas, primero determinar la estructura correcta de cada frase y segundo, compilar un diccionario para esa desambiguación. El procedimiento que usamos es iterativo. Aproxima las dos metas mencionadas en pasos alternados: primero estima las hipótesis en base a los pesos actuales en el diccionario, después reevalúa los pesos en el diccionario conforme a los pesos de las hipótesis de cada frase3, y repite el proceso.

El proceso comienza con un diccionario vacío. En la primera iteración, para cada frase, todas las hipótesis producidas por el analizador sintáctico tienen pesos iguales. Después, se determinan las frecuencias pi

+ y pi– para cada combinación encontrada al

menos una vez en cualesquiera de las variantes producidas por el analizador. Ya que se desconocen las variantes correctas, para calcular pi

+ se suman los pesos wj de cada variante donde la combinación fue encontrada, porque estos pesos representan la probabilidad de que la variante sea correcta. Similarmente, para determinar pi

– se suman los valores (1 - wj) que representan la probabilidad de que la variante dada sea incorrecta. Lo anterior se resume en estas expresiones:

( )[ ] ( )( ) ,1,

,1

,

=×=

−+−=

=

∑∏∑∑

−+

−

+

kiij

ji

ji

wppCw

SVwp

Swp

donde S es el número total de oraciones, V es el número total de variantes (hipótesis) en el corpus, C es una constante de normalización y λ es un valor para contrarrestar los efectos de palabras que no existían previamente en los datos. Una explicación detallada de la obtención de estas fórmulas se presenta en [3].

Para nuestros propósitos creamos una gramática extendida independiente del contexto (con concordancia) e implementamos un analizador sintáctico tipo chart. La Tabla 1 muestra los resultados producidos por el algoritmo cuando se aplica al corpus

3 El peso de la variante es el producto de los pesos de sus combinaciones. 4 Las letras significan: T = trasladar, F = la filmación, E = estudios y U = estadio universitario.

T F E U

desde

hasta

T F E U

desde

hasta

T F E U

desde

hasta

T F E U

desdehasta

T F E U

desde hasta

Figura 2. Variantes de la estructura sintáctica4 para la frase Trasladaron la filmación desde los estudios hasta el estadio universitario.

186 RITOS2

LEXESP5 para oraciones con el verbo acusar. A pesar de que estos resultados fueron obtenidos con muy pocas oraciones, se pueden comparar con la sección 2.1 observando que solamente tres combinaciones son incorrectas, las que tienen “obj:con” que consideran un objeto introducido con la preposición con. Estos errores se eliminarían al analizar mayor número de oraciones. En la Tabla 1, el signo “?” indica un grupo nominal, el signo “x” un clítico, el valor pi

+/pi– es representado por

+/-, dobj_suj indica objeto directo o sujeto. No hay un orden, por lo que acusar, dobj_suj:?, obj:? también representa acusar, obj:?,dobj_suj:?

La Tabla 2 se obtuvo para el verbo trasladar2 (person X transfers issue Y from place Z to place W), aún cuando se muestran todas las valencias no se obtuvieron todas las realizaciones sintácticas. Por ejemplo la frase “la trasladó desde su casa” muestra la realización sintáctica “desde NP” que no aparece en la Tabla 2. esto se debe a que solamente pocas oraciones contribuyeron en los resultados. Para mejorar los resultados se requiere entonces un corpus más grande o mejorar el analizador básico tipo chart.

El algoritmo es no supervisado y produce una lista de preposiciones usadas con cada palabra. La técnica para adquirir este conocimiento léxico es diferente de los métodos conocidos para enlaces de grupos preposicionales, porque se dirigen al enlace de patrones tipo, como V N1 P N2 en [8] o emplean textos con marcas sintácticas [6].

4 Aplicaciones

La información sintáctica obtenida para los PMA es de utilidad en diferentes tareas del procesamiento del lenguaje natural, entre ellas se encuentran las siguientes: • Generación de texto

Para esta tarea, se requiere conocer además de las reglas gramaticales las preposiciones correctas que se enlazan a cada palabra. Por ejemplo: intervenir utiliza

5 El corpus LEXESP nos fue proporcionado amablemente por el Dr. Horacio Rodríguez de la

UPC, Cataluña, España.

+/- Combinación para “acusar1” 11.3512 obj:con,obj:de,x:? 11.3512 dobj_suj:?,obj:de,x:? 11.3512 dobj_suj:?,obj:con,obj:de,x:? 11.3512 dobj_suj:?,dobj_suj:?,obj:de,x:? 11.3512 dobj_suj:?,dobj_suj:?,obj:con, obj:de,x:?4.48254 obj:de,x:? 3.59065 obj:de,obj:de,x:? 3.00859 x:? 1.32416 dobj_suj:?,dobj_suj:?,obj:a,obj:de 1.29413 dobj_suj:?,dobj_suj:?,obj:a

Tabla 1. Resultados del método estadístico.


las preposiciones en y a para enlazar sus complementos. Con las combinaciones obtenidas se tendría el conocimiento de que existen las formas: intervenir en (algo), intervenir a (alguien). El sustantivo intervención también utiliza algunas preposiciones específicas, por ejemplo: intervención de (alguien), intervención en (algo), intervención ante (alguien). • Desambiguación de sentidos

Principalmente el contexto circundante se utiliza para reconocer significados diferentes. Sin embargo, en algunos casos el uso de las preposiciones también es de utilidad, por ejemplo: intervenir en (algo) tiene el significado “participar”, intervenir a (alguien) tiene el significado “operar”. En este caso se utilizaría la información semántica de los patrones de manejo. • Enseñanza del lenguaje español a extranjeros

Como los lenguajes naturales tienen construcciones sintácticas propias y dependientes de cada uno de ellos y muchas de las combinaciones de palabras que se establecen no obedecen a reglas específicas se requiere describirlas en manuales para enseñanza del idioma a extranjeros. Un ejemplo es la utilización correcta de preposiciones, esta información no se encuentra en los diccionarios comunes de forma exhaustiva. Por ejemplo: en español se utiliza la preposición con para determinar el objeto de la acción casar, así decimos: María se casó con Juan, en inglés sería Mary married John (sin preposición).

Conclusiones

Describimos un formato mejorado para los patrones de manejo, y un método para obtener la información sintáctica de los patrones de manejo avanzados. Las ventajas de la aplicación de estos patrones para el análisis sintáctico se sustentan en algunas características del español, además de que los patrones de manejo pueden usarse no solamente para verbos sino para sustantivos y adjetivos que subcategorizan complementos.

El método de obtención semiautomática de los patrones de manejo que proponemos tiene las siguientes características:

+ip / −

ip +ip −

ip

4.32213 trasladar,dobj_suj:?,obj:a,obj:de,x:? 2.9359e-06 6.7927e-07

4.32213 trasladar,dobj_suj:?,dobj_suj:?,obj:a,x:? 1.46795e-05 3.39636e-06

1.65632 trasladar 0.000383159 0.0002313

0.48383 trasladar,dobj_suj:?,x:? 2.58667e-05 5.3462e-05

0.43699 trasladar,obj:a,x:? 2.63742e-05 6.0353e-05

Tabla 2. Estadísticas para el verbo trasladar2

188 RITOS2

• No requiere corpus con marcas sintácticas para entrenar el modelo, aunque si requiere de un analizador morfológico y un analizador sintáctico.

• El método considera el balance entre las asignaciones correctas e incorrectas de preposiciones a palabras. Los resultados obtenidos aplicando nuestro método en el corpus LEXESP fueron

empleados en el análisis sintáctico de un corpus de 100 oraciones, y se logró que las estructuras correctas para esas oraciones se clasificaran en el rango tope del 35%.

Referencias

[1] Briscoe, E. & Carroll, J. 1997. Automatic extraction of subcategorization from corpora. In Proceedings of the 5th ACL Conference on Applied Natural Language Processing.

[2] Galicia-Haro, S. N., I. A. Bolshakov & A. F. Gelbukh. 1998. Diccionario de patrones de manejo sintáctico para análisis de textos en español. Proc. XIV Congreso Internacional de la SEPLN, Septiembre 23-25, Alicante, España.

[3] Galicia-Haro, S. N. 2000. Análisis Sintáctico conducido por un Diccionario de Patrones de Manejo Sintáctico para Lenguaje Español. Tesis de Doctorado en Ciencias de la Computación. México, D.F., Instituto Politécnico Nacional, Centro de Investigación en Computación.

[4] Manning, C. 1993. Automatic acquisition of a large subcategorisation dictionary from corpora. In Proc. of the 31st Annual Meeting of the Association for Computational Linguistics.

[5] Mel’cuk, I. A. 1988. Dependency Syntax: Theory and Practice. State University of New York Press.

[6] Merlo, P., Crocker, M. and Berthouzoz, C. Attaching Multiple Prepositional Phrases: Generalized Backed-off Estimation. In Proceedings of the EMNLP-2, 1997.

[7] Monedero, J. et al. 1995. Obtención automática de marcos de subcategorización verbal a partir de texto etiquetado: el sistema SOAMAS. En Actas del XI Congreso de la SEPLN 95, págs. 241-254.

[8] Ratnaparkhi, A. 1998. Statistical Models for Unsupervised Prepositional Phrase Attachment. In Proc. of the 36th Annual Meeting of the Association for Computational Linguistics.


Procesamiento del Lenguaje Natural: presentey perspectivas futuras

Maximiliano Saiz Noeda

Departamento de Lenguajes y Sistemas InformaticosUniversidad de AlicanteAlicante, [email protected]

1. Introduccion

El Procesamiento del Lenguaje Natural (en adelante PLN), desde sus co-mienzos en los anos 50, ha intentado poner a prueba a investigadores de todo elmundo en la resolucion de tareas que, bajo una aparente simplicidad desde elpunto de vista humano, han escondido una elevada complejidad de resoluciondesde la perspectiva computacional.

La cinematografıa y la novela de ciencia ficcion de las ultimas decadasdel siglo XX predecıan la existencia de engendros mecanicos y grandes “su-perordenadores” que a comienzos del presente siglo tendrıan completamentesuperadas las barreras de comunicacion hombre-maquina a traves del lengua-je natural. Desgraciadamente, muchas de estas barreras siguen siendo retosaparentemente inalcanzables.

El PLN, que intenta simular el comportamiento linguıstico humano, sedefine como “una parte esencial de la Inteligencia Artificial que investiga yformula mecanismos computacionalmente efectivos que faciliten la interrela-cion hombre-maquina y permitan una comunicacion mucho mas fluida y menosrıgida que los lenguajes formales” [34].

El PLN como disciplina cientıfica, se enmarca dentro de la LinguısticaComputacional, ciencia que se centra en el estudio de la lengua y su represen-tacion, ası como en el desarrollo de lenguajes de representacion y adquisicionde conocimiento para el tratamiento del lenguaje humano. Su objetivo finales el de establecer una comunicacion natural entre el usuario y los sistemasinformaticos siendo estos ultimos capaces de realizar tareas de comprension yelaboracion de textos en lenguaje natural.

El PLN se centra en los aspectos mas pragmaticos de la Linguıstica Com-putacional, ya que pretende resolver problemas concretos aplicados al uso dellenguaje natural en sistemas informaticos. Ası, el PLN abarca una ingentecantidad de tecnicas como la traduccion automatica, la indexacion de docu-

mentos, la extraccion y recuperacion de informacion, el resumen de textos, laresolucion de fenomenos linguısticos, las generacion de respuestas, etc.

Un pilar fundamental en el que el PLN se apoya es la Ingenierıa Linguısticao Linguıstica informatica, fundamentalmente orientada al desarrollo de herra-mientas y recursos que sirven como apoyo a las tareas antes mencionadas.

Por tanto, podrıamos definir el PLN como el uso de ordenadores para pro-cesar el lenguaje (escrito, hablado o de cualquier otro tipo), con un objetivopractico y util, tal como la traduccion, la obtencion de informacion y de res-puestas a partir de bases masivas de datos, la conversacion con maquinas,etc.

1.1. Historia del Procesamiento del Lenguaje Natural

Los anos 50 introdujeron el Procesamiento del Lenguaje Natural en elmundo cientıfico a traves de los primeros sistemas de traduccion automatica.Durante el apogeo de la guerra frıa, se invirtieron grandes esfuerzos en larealizacion de programas de traduccion del ruso al ingles.

Sin embargo, en 1966, el comite ALPAC (Automatic Language Proces-sing Advisory Committee) elaboro, a peticion del Gobierno de los EstadosUnidos, un informe con su mismo nombre [37] sobre el estado de la traduc-cion automatica y sus posibilidades de futuro. Este informe provoco que seredujeran dramaticamente las subvenciones con fondos oficiales a todos los in-vestigadores involucrados en proyectos de este tipo por considerarlos esteriles.

A pesar de las vicisitudes, EL PLN comenzo a recuperarse a finales delos 60 y a ofrecer algunos resultados muy preliminares. Ası, empezaban adesarrollarse los primeros sistemas que eran capaces de reconocer a travesde la voz movimientos de ajedrez, determinar informacion basica a partir denoticias de prensa o conversar de forma aparentemente natural con un usuariohumano. No obstante estos sistemas tenıan grandes limitaciones y cometıanerrores garrafales.

Sin embargo, estos primeras experiencias de hace tres decadas, han pro-porcionado ideas muy valiosas y fundamentales en el estudio e investigaciondel PLN. En primer lugar, que es facil dejarse impresionar por ejemplos apa-rentemente espectaculares. En segundo lugar, que cuando se tratan dominiosrestringidos, es mas sencillo conseguir buenos resultados y que las aplicacio-nes de PLN requieren el uso de multiples fuentes de conocimiento para podercubrir una cantidad de ejemplos aceptable.

El trabajo desarrollado en PLN durante los ultimos 30 anos ha sido ımpro-bo y los resultados obtenidos, a pesar de no responder a las expectativasde cineastas y visionarios, ha conseguido una importante cantidad de logrosfundamentados, entre otros, en los crecientes avances tecnologicos que hanpropiciado una velocidad de proceso cada vez mayor y necesaria para estossistemas.

192 RITOS2

Trataremos a continuacion el ciclo del PLN y los elementos que intervienenen el, haciendo un breve repaso por los recursos, herramientas, tareas y apli-caciones mas relevantes en el area del Procesamiento del Lenguaje Natural.

2. El ciclo del PLN

Un sistema general de PLN podrıa ser definido a partir de tres bloquesclaramente diferenciados pero estrechamente relacionados que cooperan en unsistema global: recursos, tareas y aplicaciones. La figura 1 muestra un esquemaque sigue la mencionada estructura y que incorpora un modulo de resolucionde la anafora basado en el metodo enriquecido ERA definido en [48].

Sistema de PLN

RESOLUCIÓN de FENÓMENOS LINGÜÍSTICOS

CORPUSde entrada

WordNetCON ENRIQUECIMIENTOS

Resolución dela anáfora

método ERA

DesambiguaciónWSD

analizadorsintáctico

etiquetadorgramatical

ETIQUETADO del CORPUS

CORPUSenriquecido

APLICACIONES

BÚSQUEDA DERESPUESTAS

RECUPERACIÓNDE INFORMACIÓN

EXTRACCIÓN DEINFORMACIÓN

Created by Paraben's Flow Charter (Unlicensed Software).Visit www.paraben.com/html/flow.html to register.

Figura 1. Ejemplo de sistema general de PLN con un modulo de resolucion de laanafora integrado

A continuacion, se detallaran los aspectos fundamentales de cada uno deestos bloques, realizando una clasificacion o enumeracion de las areas de tra-bajo mas importantes vinculadas a cada uno de ellos.

Los recursos (corpus, redes semanticas, ...) sirven como entrada a las distin-tas tareas y herramientas que tratan problemas concretos a resolver (analisis,correferencia, desambiguacion del sentido de las palabras), pudiendo despuesllevar estas tareas a aplicaciones concretas (extraccion y recuperacion de in-formacion, busqueda de respuestas, sistemas de dialogo).


2.1. Recursos

Los recursos son el principal punto de partida para cualquier sistema dePLN y uno de los pilares fundamentales en el PLN moderno. Durante muchosanos se han realizado distintas aproximaciones y elaborado multiples teorıasque no siempre han podido ser probadas por la ausencia de este tipo de re-cursos.

Son, habitualmente, repositorios de datos que, por su extension o por lainformacion adicional a la propiamente textual que aportan, resultan extre-madamente valiosos para el desarrollo y evaluacion tanto de tareas concretascomo de aplicaciones de PLN.

Corpus

Una de las aproximaciones clasicas en tareas de PLN es precisamente labasada en corpus. Contar con grandes cantidades de texto que incorporen lamayor cantidad de informacion posible resulta fundamental en el desarrollo y,sobre todo, en la evaluacion de herramientas.

Es esta relevancia la que esta originando una mayor inversion en esfuerzoseconomicos y humanos para el desarrollo de corpus anotados con distintosniveles linguısticos. Si bien los corpus disponibles para el ingles son relativa-mente amplios, esto no ocurre en el caso del espanol, en el que la extensiony la riqueza de los corpus es mucho menor. En este sentido, el proyecto 3LB1

tiene como objetivo construir un corpus anotado sintactica, semantica y re-ferencialmente (treebanks) para los idiomas espanol, catalan y euskera. Estecorpus viene a cubrir una importante carencia de recursos que es especial-mente dramatica para lenguas distintas del ingles. En este sentido, el corpuscreado en esta propuesta estara etiquetado y supervisado para los diferentesniveles linguısticos. Ası, contendra informacion lexica sobre el lema de cadapalabra, morfologica, sintactica (completa), semantica y correferencial. Todosestos niveles de etiquetado seran descritos mas adelante en las diferentes fasesde analisis en el PLN.

Diccionarios y glosarios

Los diccionarios y glosarios contienen informacion de utilidad y son un va-lor anadido en tareas de ingenierıa linguıstica. Son, en principio, bases de datosque contienen informacion sobre las palabras de una lengua y cuyo desarrollopuede ser mas o menos sofisticado, desde la simple enumeracion monolingue depalabras hasta recursos multilingues con desarrollo de definiciones polisemicaso incluso diccionarios de formas verbales o colocaciones.

1 Este proyecto se describe con mayor detalle en 3.1

194 RITOS2

Redes semanticas y ontologıas

Las redes semanticas son un paso adelante dentro del conjunto de recursoslinguısticos. Suponen, no solo una base de datos con informacion lexica, sinouna completa red de nodos interrelacionados a traves de vınculos semanticosy que forman un complejo entramado cuyas posibilidades son ilimitadas.

WordNet [31], probablemente la mas popular y utilizada en los ultimosanos, es una base de datos formada por relaciones semanticas entre los signifi-cados de las palabras (llamadas synsets), a las cuales se accede como si fueraun tesauro, donde las palabras estan agrupadas por sus significados. De estamanera, la idea de palabra deja paso a la de concepto como elemento funda-mental. Los conceptos se agrupan entre sı formando conjuntos de sinonimosque se relacionan con otros conjuntos de sinonimos a traves de una enormevariedad de relaciones semanticas (hiperonimia, hiponimia, meronimia, holo-nimia, generalizacion, etc.).

Ademas, dentro del proyecto EuroWordNet [55, 56] se ha definido un con-junto de ındices que comparten los WordNets de las diferentes lenguas, crean-do ası un modulo inter-lenguas que dota a este recurso de enormes capacidadesde aplicacion en tareas que involucren el multilinguismo.

WordNet define ademas un conjunto de niveles conceptuales que clasificanlos distintos synsets de la red a partir de un conjunto de criterios. Estosniveles conforman las denominadas ontologıas principales [57] cuyo objetivoes el de realizar una representacion conceptual del conocimiento a partir deun conjunto de rasgos mas o menos generales.

En esta lınea, proyectos como Mikrokosmos2 estan orientados a la repre-sentacion del significado de los textos en lenguaje natural. En concreto, Mi-krokosmos usa un formato multilingue denominado TMR (text meaning re-presentation), que representa el resultado del analisis de un texto de entradadado en cualquiera de los idiomas soportados y sirve de entrada para el pro-ceso de generacion. El sentido del texto de entrada, derivado por el analisisde su informacion lexica, sintactica, semantica y pragmatica, se representa enel TMR como elementos a interpretar en terminos de un modelo del mundou ontologıa, tal y como se muestra en [28].

Ademas, algunos trabajos, como el desarrollado en el proyecto Euroterm3,han extendido WordNet con terminologıa concreta, en este caso, con termi-nologıa del sector publico y, en particular, del sector medioambiental. Esto

2 El proyecto Mikrokosmos ha sido desarrollado por el Laboratorio de Investi-gacion Computacional (CRL, The Computing Research Laboratory) de la Uni-versidad del Estado de Nuevo Mexico. Para mas informacion, puede visitarsehttp://crl.nmsu.edu/Research/Projects/mikro/index.html

3 EuroTerm es un proyecto financiado por la Comision Europea (EDC-2214) conuna duracion total de dieciocho meses (del 01/01/01 al 30/06/02) e incluido enlas acciones preparatorias del programa e-content. El consorcio esta formado porinvestigadores de las universidades de Patras (Grecia), de Tilburg (Holanda) yde Alicante (Espana). Los participantes espanoles son miembros del Grupo deProcesamiento del Lenguaje y Sistemas de Informacion del Departamento de


propicia el desarrollo de ontologıas y redes de dominio especıfico que puedenser aplicadas directamente a documentos de dicho dominio, algo que potenciaconsiderablemente las capacidades de estos recursos.

2.2. Tareas y Herramientas

Las tareas y las herramientas se integran en los sistemas de PLN y suobjetivo fundamental es el de enriquecer aun mas la informacion con la quecuentan las aplicaciones. Ası, una tarea fundamental es la de la anotacionde los corpus que sirven como entrada, para lo que resulta imprescindible laresolucion de todo tipo de ambiguedades.

Podrıamos, ası, diferenciar varios niveles de conocimiento, correspondien-tes a los distintos niveles linguısticos, necesariamente implicados en el PLN:nivel lexico, referente al vocabulario de una lengua; nivel morfologico, relativoesencialmente a los morfemas de genero, numero y persona; nivel sintactico,que analiza estructuras de secuencias de unidades lexicas; nivel semantico, quetrata el significado o sentido de los elementos y estructuras oracionales; nivelpragmatico, que pone en relacion las unidades linguısticas con el contexto ex-tralinguıstico. Hablaremos, por tanto, de las distintas fases de analisis segunsea la fuente de conocimiento implicada.

Analisis lexico

La informacion lexica esta contenida en el lexicon, esto es, en el conjuntode unidades lexicas pertenecientes a un sistema linguıstico. Dicha informa-cion consta de: la etiqueta relativa a la categorıa gramatical de cada unidadlinguıstica (nombre, verbo, pronombre,...) y de una o varias etiquetas corres-pondientes a cada uno de los rasgos de subcategorizacion o de seleccion quehacen posible que cada unidad linguıstica seleccione otra u otras a la ho-ra de combinarse formando las distintas oraciones posibles de una lengua(+−

concreto, +−

transitivo, . . . ).La necesidad de esta informacion para cualquier tarea de PLN es evidente.

Esta informacion proporcionada por los lexicones, cuya cobertura depende desu implementacion, resulta un valioso recurso para obtener las unidades lexicasque forman el texto.

A partir de un texto a procesar, un analizador lexico se encarga de transfor-mar las secuencias de sımbolos en unidades lexicas y, a traves de un conjuntode reglas, resolver posibles ambiguedades lexicas categoriales. Estos analiza-dores se denominan etiquetadores gramaticales4.

Lenguajes y Sistemas Informaticos de la Universidad de Alicante. La informacionrelativa a este proyecto puede encontrarse en http://dblab.upatras.gr.

4 Del ingles POS taggers o Part-of-speech taggers.

196 RITOS2

Algunos ejemplos de estos etiquetadores son relax 5 (espanol, catalan eingles), TreeTagger5 (espanol e ingles), Brill’s tagger 6 (ingles) o el propuestopor [44, 45].

Analisis morfologico

La morfologıa trata las palabras tomadas independientemente de sus rela-ciones en la oracion y estudia su forma. Por tanto, la informacion morfologicaque proporciona una palabra incluye datos sobre su flexion (genero, numero,persona, . . . ), derivacion (sufijos, prefijos, . . . ) y composicion (palabras sim-ples, palabras compuestas). Asimismo, es objeto del estudio morfologico lacategorıa gramatical de las palabras (nombre, verbo, adverbio, . . . ).

La correcta identificacion de unidades morfologicas es esencial para cual-quier proceso posterior. El analisis morfologico trata de establecer las cadenasde morfemas que forman una palabra, identificando sus rasgos de flexion,composicion y derivacion.

Si se combina el analisis morfologico con el lexico se puede obtener informa-cion morfologica mas completa sobre las unidades lexicas ya desambiguadas.

Algunos analizadores morfologicos son maco+7 (espanol, catalan e ingles)y PC-KIMMO8 (ingles).

Analisis sintactico

La sintaxis trata la combinacion de las palabras en la frase [13]. Los pro-blemas principales de los que se ocupa la sintaxis se refieren al orden de laspalabras, a los fenomenos de reccion (es decir, la manera en que ciertas pa-labras imponen a otras variaciones de numero, genero, . . . ) y a las funcionesque las palabras pueden cumplir en la oracion.

Muchos de los mecanismos sintacticos en el PLN se fundamentan en unconjunto de teorıas que parten de la teorıa de reccion y ligamento [9]9.

5 Desarrollado por el Grupo de Investigacion de Lenguaje Natural del Depar-tamento de Lenguajes y Sistemas Informaticos de la Universidad Politecnicade Cataluna en colaboracion con el Laboratorio de Linguıstica Computacionalde la Universidad de Barcelona. Demostracion del etiquetador disponible enhttp://nipadio.lsi.upc.es/cgi-bin/demo/demo.pl.

6 El etiquetador esta disponible en http://www.cs.jhu.edu/ brill/

y una demostracion del mismo se puede encontrar enhttp://rayuela.ieec.uned.es/cgi-bin/ircourse/brill.perl.

7 Desarrollado por el Grupo de Investigacion de Lenguaje Natural del Depar-tamento de Lenguajes y Sistemas Informaticos de la Universidad Politecnicade Cataluna en colaboracion con el Laboratorio de Linguıstica Computacio-nal de la Universidad de Barcelona. Demostracion del analizador disponible enhttp://nipadio.lsi.upc.es/cgi-bin/demo/demo.pl.

8 Disponible en http://www.sil.org/pckimmo/ntnlp94.html9 Algunos autores han enunciado teorıas fundamentadas en la de Chomsky, como

es el caso de las reglas c-comando [46].


La obtencion de la informacion sintactica para las tareas computaciona-les de PLN supone el uso de un analizador sintactico. Podemos distinguirdos clases de analisis sintactico, el analisis parcial o superficial y el analisiscompleto.

En el analisis superficial, se identifican constituyentes sintacticos aislados.No se establecen relaciones sintacticas entre ellos, con lo que el coste com-putacional es bajo, a costa de disminuir la profundidad y la complecion. Sonanalizadores rapidos, fiables y robustos.

El analisis completo, por su lado, es menos robusto y fiable, ya que rechazacualquier oracion que no sea capaz de analizar de forma global. Sin embargo,proporciona informacion mucho mas valiosa, ya que establece enlaces oracio-nales entre los diferentes elementos sintacticos.

Algunos analizadores sintacticos son SUPP [39] (analisis parcial en es-panol), tacat10 (parcial y completo en espanol y catalan) y Conexor 11 [50](analisis completo en ingles y espanol).

Analisis semantico

La semantica proporciona el significado de las palabras segun el contexto.Gran parte de la informacion semantica de una unidad lexica se encuentracontenida ya en forma de rasgos semanticos en la descripcion de dicha unidad.Esto es, la informacion semantica es responsable de la correcta combinacionde unidades lexicas en un discurso.

Para la aplicacion de esta informacion semantica es necesario contar conrecursos lexicos, como los vistos en la seccion anterior, que proporcionen lossentidos posibles de las palabras, ası como con herramientas de desambigua-cion del sentido de las palabras (Word Sense Disambiguation). Estas herra-mientas se encargaran de determinar cual de los sentidos posibles es el masadecuado.

Analisis contextual

Hay que tener en cuenta que la correcta interpretacion del lenguaje puedeen ocasiones no depender de factores relacionados con el discurso en el que seda, sino con el universo sociocultural previo. Es evidente, por tanto, que lainformacion pragmatica, esto es, segun [34], la relativa al conocimiento generaldel mundo, a la situacion comunicativa concreta y a las presuposiciones einferencias que conlleva, es fundamental para el correcto desarrollo de tareasde PLN.10 Desarrollado por el Grupo de Investigacion de Lenguaje Natural del Depar-

tamento de Lenguajes y Sistemas Informaticos de la Universidad Politecnicade Cataluna en colaboracion con el Laboratorio de Linguıstica Computacio-nal de la Universidad de Barcelona. Demostracion del analizador disponible enhttp://nipadio.lsi.upc.es/cgi-bin/demo/demo.pl.

11 Demostracion del analizador disponible en http://www.conexor.fi.

198 RITOS2

La aplicacion de informacion pragmatica es una tarea difıcil de afrontar. Sibien se pueden definir algunas reglas especıficas para resolver casos concretos,el uso de este tipo de conocimiento es una lınea de investigacion completa-mente abierta dada la ausencia de recursos que aporten informacion valiosade este tipo.

No obstante, para conseguir una representacion contextual completa, sehace necesario en uso de tecnicas de resolucion de fenomenos linguısticos comola elipsis o la anafora. Algo tan simple para un lector humano como relacionarlas entidades del discurso en funcion de la evolucion de un texto o resolver laambiguedad introducida por elementos textuales sin carga semantica, comoel caso del pronombre, tiene ocupados a muchos grupos de investigacion a lolargo de la ultima decada.

Resolucion de la anafora

Tomando la definicion clasica de [20], podemos decir que la anafora esel “Mecanismo que permite hacer en un discurso una referencia abreviada aalguna entidad o entidades con la confianza de que el receptor del discurso seacapaz de interpretar la referencia y por consiguiente determinar la entidad ala que se alude.”

Contextualizando la anafora en el marco de los fenomenos linguısticos rela-cionados, y segun [35], podemos emplear el termino fora para designar aquellasunidades del discurso que remiten a otro elemento (interno o externo al mis-mo mensaje). Ademas, en ocasiones la relacion se establece entre un elementogeneralmente pronominal y otro denominado antecedente, que aparece en elcontexto linguıstico inmediato, es decir, en la misma frase o en otra anterior,como en “Juani cree que no loi llamaran”, o en “[Ya he comprado el libro]i.No se loi dire.”. Dicha relacion se denomina deixis anaforica o simplementeanafora (del griego αναφoρα, ‘referencia, remision’). Cuando la relacion decorreferencia se establece entre un elemento, generalmente pronominal, y otroque aparece a continuacion (consecuente), decimos que se trata de una deixiscataforica o catafora, como sucede en “Todos los que lai conocen dicen queMarıai es muy simpatica”. Podemos incluir estas definiciones en el siguienteesquema.

FORAP

PP

PP

��

��

EXOFORA ENDOFORA

aa

a

!!

!

ANAFORA CATAFORA

Ası pues, tanto la anafora como la catafora se consideran categorıas deendofora [34], la cual viene definida por su dependencia del contexto linguısti-co, en oposicion a la exofora, que se desarrolla en el contexto situacional.

Si bien el espectro de clasificaciones de la anafora es enormemente amplio,podemos hacerlo en funcion de tres criterios que aluden, por una parte, a la


relacion entre el elemento anaforico y su antecedente y, por otra, a la categorıagramatical tanto del antecedente como de la anafora. Este planteamiento reco-ge la esencia del fenomeno linguıstico de la anafora en sus diferentes vertientesy sirve como punto de partida optimo para el desarrollo de este trabajo.

Ası segun la relacion entre el elemento anaforico y su antecedente

hablaremos de:

• Anafora de referencia o profunda.

(1) Luisa corto el vestidoi y Marıa loi cosio.

• Anafora de sentido o superficial.

(2) Andres perdio su pasaportei y a Luis se loi robaron.

Por otro lado, segun la categorıa gramatical del antecedente habla-remos de:

• Sintagma nominal. El antecedente tiene como nucleo un nombre,comun (3) o propio (4).

(3) Arturo se ha puesto gafas i. Lasi ha comprado en la optica dePedro.

(4) Arturoi se ha puesto gafas. Lei quedan muy bien.

• Sintagma verbal. El antecedente tiene como nucleo un verbo.

(5) Mi mujer quiere conducir durante toda la noche i pero yo no quieroque lo hagai.

• Sintagma adverbial. El antecedente anaforico esta representado por unadverbio, como ocurre en (6).

(6) Marıa esta arribai. Allıi se trabaja mejor.

(7) Marıa esta trabajando en la buhardillai. Allıi hay mas luz.

• Oracion completa, hecho o idea. Un antecedente anaforico puede estarrepresentado por una oracion completa, como en (8), ası como por unconjunto de ellas, texto o fragmento de texto, por lo que la anaforahara alusion a un hecho o una idea mencionados anteriormente.

(8) Marisa esta embarazadai. Su marido no loi sabe.

Por ultimo, segun la categorıa gramatical del elemento anaforico

distinguiremos entre

200 RITOS2

• Anafora pronominal: es la mas frecuente de todas, tambien la de mayorcomplejidad, por la amplitud y complejidad de la categorıa misma delpronombre.1. Anafora de pronombre personal

◦ De pronombre personal sujeto

(9) Andresi sabe la combinacionj de la cajak fuerte.El i esta hoyde viaje.

(10) El monok subio al arbol j a coger un platanoi. (Øi) estabamaduro.

◦ De pronombre personal complemento:

(11) No tengo noticias de Luis i. No loi veo desde octubre.

(12) La televisioni esta encendida cuando Luisaj llega a la cocinak.Ella lai apaga cuando se acuesta.

2. Anafora de pronombre omitido

(13) Luisi entrego los papeles a los asesores. Ø i Estaba preocupadopor los plazos de presentacion.

(14) Isabel i llamo a la empresaj de mudanzas. Øi Deseaba marcharsecuanto antes.

3. Anafora de pronombre demostrativo

(15) De entre los asistentes destacaba una joveni con rasgos orien-tales. Estai parecıa ausente.

(16) Antonio conoce el nombrei del pintor j . Estei se pronuncia condificultad.

4. Anafora de pronombre posesivo

(17) Tus ojosi son azules. Los suyos i son verdes.

(18) Este cochei es del hermanoj de su amigok. El mıoi esta estro-peado.

5. Anafora de pronombre reflexivo

(19) Martai sei pinta mucho.


(20) Luisi fue de excursion al rıoj . Sei bano con sus amigos.

6. Anafora de relativo

(21) Los discosi quei te preste son muy antiguos.

(22) El perroi de mi amigoj , quej trabaja en un banco, es de puraraza.

7. One anaphora

(23) I have washed all my skirtsi and the blue onei has shrunk.

He lavado todas mis camisas i y la azul i ha encogido.

(24) I have a black bicyclei and a white bicyclej, but I prefer thedark onei.

Tengo una bicicleta negraj y una bicicleta blancaj , pero prefierola oscurai.

• Anafora de sintagma nominal (descripciones definidas): la clasificacionde los tipos de anafora de sintagma nominal esta basada en el tipo dedeterminante del SN que cumple la funcion anaforica (artıculo deter-minado, demostrativo o posesivo).1. SN con artıculo determinado

(25) De entre los asistentes destacaba una joveni con rasgos orien-tales. La joveni parecıa ausente.

(26) Luis tiene una empresai de exportacion. La companıai cuentacon 200 empleados.

2. SN con determinante demostrativo

(27) De entre los asistentes destacaba una joveni con rasgos orien-tales. Esta joveni parecıa ausente.

(28) El bambui es la base de nuestros productos. Oriente nos pro-porciona esta plantai.

3. SN con determinante posesivo

(29) De entre los asistentes destacaba una joveni. Su indumentariai

era muy llamativa.

202 RITOS2

(30) La casai de Marıaj es enorme. Su saloni tiene 30 metros cua-drados.

• Anafora superficial numerica: si bien este tipo de anafora puede serincluido en cualquiera de los dos grupos anteriores, al poder estar re-presentado tanto por un adjetivo sustantivado como por un pronombre,tiene entidad suficiente para ser tratado de forma independiente.

(31) Luisi y Marianoj tienen una tienda. El primeroi trabaja solo porla manana.

(32) Romaj , Milank, Madridm, Barcelonai y Parısn presentan sus co-lecciones de otono. La segunda de las ciudades espanolas i amplıael numero de disenadores.

(33) Alumnosi y profesoresj comparten la misma opinion. Los unos i ladefienden desde sus pupitres y los otrosj lo hacen desde la tarima.

(34) Los rusosi y los americanosj han llegado a la luna. Estosi lo hi-cieron en 1969 y aquellosj poco tiempo despues.

• Anafora verbal: en la anafora verbal la forma pronominal lo se refierea un verbo o a un sintagma verbal (sin complemento directo) al que sealude mediante un verbo auxiliar o similar (pro-verbo).

(35) No se puede fumar i en este recinto, ası que no lo hagas i.

• Anafora adverbial: dividimos este grupo de anaforas en temporales ylocativas segun la circunstancia temporal (36) o espacial (37) descritapor el antecedente.

(36) No acabare mis estudios hasta el ano que viene i. Entoncesi

hare unas practicas en una empresa.

(37) Frente a la oficinaj hay un taller i. Ahıi encontraras los recambiospara tu coche.

Las estrategias para la resolucion de la anafora se pueden resumir en tresgrandes grupos de metodos, si bien algunos trabajos pueden integrarse en masde un grupo.

Metodos de conocimiento limitado: aproximaciones que resuelven la anafo-ra con el uso de informacion morfologica y/o sintactica. Muchos de es-tos metodos han sido desarrollados a partir de los trabajos de Hobbs en[21, 22]. En este sentido se recomienda revisar los trabajos de [27], [26],


[2], [33], [15], siendo uno de los trabajos mas recientes y comparativos enesta lınea el presentado en [40].Metodos enriquecidos: estrategias que incorporan, junto a las anteriores,fuentes de informacion adicional como la semantica (bien basada en eti-quetados o en el uso de ontologıas) o la pragmatica (a traves del analisisdel discurso o el conocimiento del mundo). En esta linea, pueden estudiar-se los trabajos de [6], [47], [32], [8]. Ası mismo, dentro de este grupo, sehan aplicado teorıas muy interesantes como la del centering [18] para laresolucion de la anafora. Tal es el caso de [4] o de [51] para la resolucionde pronombres.El tratamiento computacional del fenomeno de la anafora se ha centradofundamentalmente en la resolucion de pronombres, exceptuando algunostrabajos importantes en la resolucion de descripciones definidas. Trabajosrecientes en esta linea son los de [54] y [36].Metodos alternativos: este grupo incluye aquellas estrategias no cata-logadas en los dos anteriores. Usan tecnicas basadas en la estadıstica([11, 12],[17, 16]), en tecnicas de clustering ([7]) o modelos de inteligenciaartificial y algoritmos geneticos ([5]) .

El metodo ERA definido en [48] es un metodo enriquecido de resolucionde la anafora pronominal en espanol (ERA) que incorpora a las fuentes deconocimiento limitado las provenientes de los papeles sintacticos y la infor-macion semantica. Basado en un conjunto de restricciones y preferencias, elmetodo ERA aporta criterios adicionales a la resolucion de la anafora, criterioscuya eficacia se ha puesto de manifiesto en diferentes ejemplos y en la propiaevaluacion. El esquema basico del metodo se presenta en la figura 2

2.3. Aplicaciones

En este apartado trataremos un conjunto de aplicaciones clasicas dentrodel Procesamiento del Lenguaje. En este trabajo, nos centraremos en aplica-ciones textuales, sin describir aquellas fundamentadas en el procesamiento delHabla.

La traduccion automatica

Sin duda, la traduccion automatica supone una de las primeras aproxi-maciones cientıficas al problema del PLN. Los inicio de las aplicaciones detraduccion se fundamentaban en el uso de diccionarios bilingues que susti-tuıan unas palabras por otras.

Segun el Diccionario de la Real Academia Espanola12, la traduccion es la“accion y efecto de traducir”, es decir, “accion y efecto de expresar en unalengua lo que esta escrito o se ha expresado antes en otra”. Por lo tanto, el

12 Edicion electronica, Espasa Calpe, S.A., 1995.

204 RITOS2

CORPUSenriquecido

WordNet

Método ERA

Módulo derestricciones ypreferencias

Conversorde entrada

Datos para resolución

AnáforaLista de

candidatos

Conocimientosemántico deincompatibilidadnombre-verbo

SOLUCIÓN

Ontología deEuroWordNet

Generadorsemántico

Patrones deincompatibilidad

Texto conformato Colecciones

semánticasPatrones de

compatibilidad

BASE de CONOCIMIENTO SEMÁNTICO

Figura 2. Detalle de los modulos integrantes del metodo ERA

termino traduccion es, en sı mismo, ambiguo ya que denota tanto la accionde traducir como el resultado (efecto) de este proceso.

Segun Jakobson [24] se distinguen 3 maneras de interpretar un signo verbal:(1) traducirlo a otros signos de la misma lengua, (2) a otra lengua, o (3) acualquier otro sistema no verbal de sımbolos. Estos tres tipos de traduccionpueden designarse de modo diferente:

1. La traduccion intralinguıstica o reformulacion (rewording) es una inter-pretacion de los signos verbales mediante otros signos de la misma lengua.

2. La traduccion interlinguıstica o traduccion propiamente dicha (translationproper) es una interpretacion de los signos verbales mediante cualquierotra lengua.

3. La traduccion intersemiotica o transmutacion (transmutation) es una in-terpretacion de los signos verbales mediante los signos de un sistema noverbal.


En la traduccion intralinguıstica de una palabra se emplea otra palabramas o menos sinonima o se recurre al circunloquio13. Sin embargo, por re-gla general, el sinonimo no suele dar una equivalencia completa: por ejemplo,“todo celibe es soltero, pero no todo soltero es celibe”. Una palabra o una ex-presion idiomatica, en suma, solo puede ser interpretada plenamente medianteun mensaje (combinacion de expresiones) que se refiera a esta expresion: “to-do soltero es una persona que no ha contraıdo matrimonio y toda persona queno ha contraıdo matrimonio es soltera”.

De igual modo, a nivel de la traduccion interlinguıstica no hay normalmen-te una equivalencia entre las expresiones, aunque los mensajes puedan servirde interpretaciones correctas de mensajes pertenecientes a otras lenguas. Sinembargo, lo mas frecuente es que en la traduccion de una lengua a otra sesustituyan mensajes, no por expresiones por separado sino por mensajes ente-ros, a su vez, en la otra lengua. Tal traduccion equivale a un estilo indirecto;el traductor recodifica y transmite un mensaje recibido de otra fuente. Unatraduccion semejante requiere dos mensajes equivalentes en dos codigos dife-rentes.

La falta de algun recurso gramatical en la lengua a la cual se traduce noimposibilita la traduccion literal de la totalidad de la informacion contenida enel original. Si en un determinado lenguaje falta alguna categorıa gramatical,su significado puede traducirse a este lenguaje por medios lexicos.

Para traducir correctamente la frase inglesa I hired a worker (Yo con-trate un trabajador), un ruso necesita ademas que se le diga si esta accion secompleto o no y si el trabajador (worker) era hombre o mujer, porque debeelegir entre un verbo de aspecto completivo o uno no completivo –nanjal onaminal– y entre un sustantivo masculino y uno femenino –rabotnika o ra-botnitsu–. Si le preguntamos al hablante ingles si el trabajador era hombre omujer, la pregunta podra parecer impertinente o indiscreta, mientras que enla version rusa de esta frase la respuesta a este interrogante es obligatoria.El hecho de que los artistas alemanes pintaran al pecado en forma de mujersorprendio al pintor ruso Repin porque desconocıa que pecado es femeninoen aleman (die Sunde), pero masculino en ruso (grjech). El tıtulo de un li-bro de poemas de Boris Pasternak, Mi hermana la vida, no presenta ningunadificultad en ruso, lengua en que la palabra vida es femenina (zizn’ ), pero pre-sento muchas dificultades al poeta checo Josef Hora, en su intento de traducirel libro, ya que en checo vida es masculino (zivot).

Con estos ejemplos queda patente que la traduccion interlinguıstica o tra-duccion propiamente dicha no es una tarea sencilla y requiere un amplio do-minio de las dos lenguas entre las que se quiere realizar la traduccion. Siesta labor es, a veces, difıcil incluso para un humano, podemos imaginar loque supone realizar esta tarea de un modo automatico. Esta idea de reali-

13 El circunloquio se define segun el Diccionario de la Real Academia Espanola como“rodeo de palabras para dar a entender algo que hubiera podido expresarse masbrevemente”.

206 RITOS2

zar el proceso de la traduccion interlinguıstica entre dos lenguas de un modoautomatico dio lugar al nacimiento del concepto Traduccion Automatica.

La Traduccion Automatica (TA) se puede definir como “el proceso (o elresultado) de traducir un texto en un idioma origen a un idioma destino de unamanera automatica”. En esta definicion hay que matizar dos conceptos: textoy automatica. Texto se refiere a un texto informatizado (fichero de ordenadorque contiene un texto codificado en un formato determinado) y automatica serefiere al uso de un programa de ordenador.

Tal y como se presenta en [23] la mecanizacion de la traduccion ha sidouno de los suenos mas viejos de la humanidad. En el siglo XX este sueno sehizo realidad en forma de programas de ordenadores capaces de traducir unaamplia variedad de textos de un idioma a otro. Sin embargo, como siempre,la realidad no es perfecta. No existen “maquinas traductoras” que tomen untexto en un idioma y produzcan una traduccion perfecta en otro idioma sinla intervencion o asistencia humana. Este es un ideal para el futuro, que sibien es factible en principio, requerira un esfuerzo considerable para llegar aalcanzarlo.

Por el momento lo que se ha obtenido es el desarrollo de programas quepueden producir traducciones “sin refinar” de textos de dominio bien definido.Estas traducciones pueden ser revisadas posteriormente por especialistas pa-ra proporcionar una mejor calidad a los textos traducidos. En algunos casos,controlando el lenguaje de los textos de entrada, se pueden obtener automati-camente traducciones de alta calidad sin la necesidad de revisiones posteriores.

Sin embargo, estos solidos logros alcanzados por la TA son a menudomal comprendidos. La percepcion publica de la TA es distorsionada por dosextremos. Por una parte, aquellos que estan convencidos de la facilidad quesupone analizar el lenguaje, ya que incluso los ninos pequenos son capacesde aprender idiomas facilmente. Ademas, estan convencidos de que cualquieraque conozca un idioma extranjero debe ser capaz de traducir con facilidad.Estas personas son incapaces de apreciar las dificultades que conllevan unproceso de TA y de los logros que se han obtenido. Por otra parte, estanaquellos que creen que la traduccion automatica de autores literarios comoCervantes, Shakespeare, etc. no es factible y por lo tanto cualquier sistemade traduccion basado en un ordenador no tiene sentido. Son incapaces deevaluar la contribucion que estas traducciones “imperfectas” podrıan haceren su propio trabajo o en la mejora general de la comunicacion internacional.

Segun [29] podemos distinguir dos tipos de aplicaciones de TraduccionAutomatica:

Aplicaciones orientadas a la comprension de textos: el sistema de tra-duccion opera como una herramienta cuyo objetivo es hacer entender alusuario un texto escrito en una lengua diferente a la suya. Los textos a tra-ducir suelen ser cortos, las lenguas de traduccion lejanas y la calidad de latraduccion no es lo mas relevante ya que se trata de hacerse una idea de lo


que quiere decir el texto. Ademas, los sistemas informaticos sobre los quese desarrollan estas tareas suelen ser ordenadores personales o Internet.Aplicaciones orientadas a agilizar el proceso de traduccion masiva: el siste-ma de traduccion es una herramienta industrial para obtener traduccionesde grandes volumenes de texto. La rapidez y la claridad en estos sistemases un tema crıtico para lo que las lenguas de traduccion suelen ser lenguasmas cercanas ya que los sistemas de TA actuales no pueden alcanzar unacalidad realmente buena entre lenguas no proximas.

Relacionando el problema de la resolucion de la ambiguedad referencial yel de la TA, los trabajos de [42] y [43] tratan el problema de la TA median-te una representacion interlingua centrada en la resolucion y generacion deexpresiones anaforicas pronominales.

Los sistemas de dialogo

De acuerdo con Fernandez [14] hay tres grandes tendencias de investi-gacion actuales en el campo de los sistemas de dialogo visto desde las tresgrandes perspectivas de la Inteligencia Artificial. Desde el punto de vista me-todologico, dicha investigacion pretende una obtencion de modelos de dialogohombre-maquina ası como su formalizacion teorica. Desde el punto de vistacognitivo se busca la motivacion de los modelos propuestos. Y por ultimo, des-de el punto de vista computacional lo que se pretende es la implementacionde los modelos de gestion de dialogo, y su integracion en otros componentesde procesamiento del lenguaje natural como el reconocimiento y generacionde voz o la interpretacion y generacion del lenguaje natural. Estos componen-tes deben incluir la resolucion de sus fenomenos linguısticos, tal y como sedemuestra en [30] y [41].

Existe un criterio tradicional sobre el desarrollo de sistemas de dialogo porel cual estos se construyen generalmente a partir de una arquitectura basicaformada por tres niveles que se puede extraer del modelo basico conversacionaldefinido por Bernsen et al. en [3]. De acuerdo a este modelo la arquitecturabasica de un sistema de dialogo debe contener una serie de modulos distribui-dos en los siguientes niveles tecnologicos:

Procesamiento del habla (reconocimiento y sıntesis).Procesamiento del lenguaje natural (comprension y generacion).Gestion del dialogo (control y contexto).

El nivel de procesamiento de habla contiene los modulos de reconocimientoy sıntesis del habla que permiten al sistema de dialogo realizar una conversionentre el lenguaje hablado introducido en el sistema por el usuario humanoy el lenguaje escrito que sera el analizado y procesado por la maquina. Eneste sentido existe una doble tarea a procesar. El sistema debe ser capaz dereconocer el lenguaje hablado para interpretar las entradas del usuario pero

208 RITOS2

tambien debera ser capaz de sintetizar el lenguaje hablado para obtener unasalida para ese usuario.

El nivel de procesamiento del lenguaje natural describe el procesamientolexico, gramatical y semantico que es necesario, por una parte, para obtenerla informacion basica que se usara en la gestion del dialogo mediante la com-prension del lenguaje, y por otra parte, para tratar los aspectos linguısticosde la generacion del lenguaje.

Por ultimo, el nivel de gestion de dialogo se encarga de controlar la es-tructura del dialogo desde dos aspectos distintos. Por un lado, debe modelarla estructura del dialogo desde el mantenimiento de la estructura intencional,el estado atencional y la estructura linguıstica [19]. Y por otro lado, debe en-cargarse del mantenimiento de un contexto en el que se incluya la historia deldialogo, un modelo del usuario, un modelo del dominio, o las caracterısticasdel dialogo. De esta forma, el nivel de gestion del dialogo permitira llevar acabo los fines de dicho dialogo, es decir, la ejecucion de una tarea concreta sise trata de un sistema de dialogo orientado a tareas, o la obtencion de unainformacion si estamos ante un sistema de recuperacion de informacion.

En el esquema basico descrito por Bernsen et al. en [3] la informacion fluyesecuencialmente de un nivel a otro, de forma que la entrada del sistema seproduce a traves de un modulo reconocedor de habla que produce una salidaescrita hacia un modulo de comprension del lenguaje natural que analiza ellenguaje y lo interpreta, y produce la entrada del modulo gestor de dialogo.Este modulo finalmente genera la estructura controlada provocando que elmodulo de generacion del lenguaje natural construya una salida de lenguajeque debe ser sintetizado en forma de voz pseudo-humana gracias al modulosintetizador de voz. De esta forma, se crea una cierta independencia entre lostres niveles tecnologicos, enlazados unicamente por el flujo de informacion queconstituye las entradas y salidas entre los distintos niveles.

Sin embargo, trabajos recientes publicados por Allen et al. en [1], demues-tran que el mantenimiento de una arquitectura con este flujo de informacionsimple no es viable cuando se pretende construir un sistema capaz de gestionardialogos de cierta complejidad. En este sentido, Allen et al. proporcionan unaarquitectura generica para los sistemas de dialogo por medio de la cual, existeun flujo principal de informacion desde la entrada de un enunciado habladohasta la generacion de la respuesta por parte de la maquina, pero ademasexiste un flujo de informacion secundario entre los diferentes componentesque remarcan la necesidad de una interaccion entre los distintos niveles masalla del flujo principal.

La figura 3 muestra el flujo de informacion entre cada uno de los compo-nentes de la arquitectura propuesta por Allen et al..

En la figura mostrada, se distingue mediante lıneas de trazo continuo elflujo de informacion principal que corresponde con el comportamiento descritoen el modelo basico de Bernsen et al. Sin embargo, existe ademas un flujo deinformacion secundario representado mediante lıneas de trazo discontinuo que


Gestor del discurso

Reconocedor del habla

Sintetizador de voz

Planificador de respuestas

Planificador de contenidos

Parser

Gestor de pantalla

Gestor del contexto del

discurso

Gestorde referenciasGestor del plan Agente de

comportamiento

Flujo Principal

Flujo Secundario

Independiente del dominio

Dependiente del dominio

Figura 3. Arquitectura de un sistema generico de dialogos por Allen et al. (2000)

permite una interaccion constante entre los distintos niveles del sistema, y querompe con el esquema cerrado basado en tres niveles independientes.

Acceso a la informacion

Generalmente, cuando un usuario emplea un ordenador para buscar unainformacion determinada, lo que realmente esta intentando es encontrar res-puesta a sus necesidades de informacion. Para facilitar esta tarea, se nece-sitarıa disponer de sistemas -llamemosles “ideales”- que fuesen capaces delocalizar la informacion requerida, procesarla, integrarla y generar una res-puesta acorde a los requerimientos expresados por el usuario. Ademas, estossistemas deberıan ser capaces de comprender preguntas y documentos escritosen lenguaje natural en dominios no restringidos permitiendo ası, una inter-accion comoda y adecuada a aquellos usuarios inexpertos en el manejo decomputadores. Sin embargo, y aunque las investigaciones avanzan en buenadireccion, todavıa no existe hoy ningun sistema operacional que cumpla todosestos requisitos.

Ante la creciente necesidad de aplicaciones que facilitaran -al menos enparte- el acceso y tratamiento de grandes cantidades de informacion, la co-munidad cientıfica concentro sus esfuerzos en la resolucion de problemas masespecializados y por ello, mas facilmente abordables. Esta circunstancia propi-cio el desarrollo de campos de investigacion que afrontaron el problema desdediferentes puntos de vista: la recuperacion de informacion (RI), la extraccionde informacion (EI) y, posteriormente, la busqueda de respuestas (BR).

210 RITOS2

La recuperacion de informacion

Los sistemas de recuperacion de informacion (RI) realizan las tareas deseleccionar y recuperar aquellos documentos que son relevantes a necesidadesde informacion arbitrarias formuladas por los usuarios. Como resultado, estossistemas devuelven una lista de documentos que suele presentarse ordenada,en funcion de valores que intentan reflejar en que medida cada documen-to contiene la informacion que responde a las necesidades expresadas por elusuario.

Los sistemas de RI mas conocidos son aquellos que permiten -con mayor omenor exito- localizar informacion a traves de Internet. Sirvan como ejemploalgunos de los motores de busqueda mas utilizados actualmente como Goo-gle14, Alta Vista15 o Yahoo16.

Una de las caracterısticas de estos sistemas reside en la necesidad de pro-cesar grandes cantidades de texto en un tiempo muy corto (del orden demilisegundos para busquedas en Internet). Esta limitacion impone una severarestriccion en cuanto a la complejidad de modelos y tecnicas de analisis dedocumentos que pueden emplearse.

Dentro del ambito de la RI podemos destacar la aparicion de dos lıneasde investigacion orientadas a mejorar el rendimiento de estos sistemas: Larecuperacion de pasajes (RP) [25] y la aplicacion de tecnicas de procesamientodel lenguaje natural (PLN) al proceso de RI [49].

La extraccion de informacion

Los sistemas de extraccion de informacion (EI) realizan la tarea de buscarinformacion muy concreta en colecciones de documentos. Su finalidad consisteen detectar, extraer y presentar dicha informacion en un formato que seasusceptible de ser tratado posteriormente de forma automatica.

Estos sistemas se disenan y construyen de forma especıfica para la rea-lizacion de una tarea determinada, y en consecuencia, dispondremos de unsistema diferente en funcion del tipo de informacion a extraer en cada caso.Estos sistemas necesitan aplicar tecnicas complejas de PLN dada la gran pre-cision que se requiere para la deteccion y extraccion del tipo de informacionque les es relevante.

La investigacion en este campo ha sido muy intensa. En particular, la seriede conferencias Message Understanding Conference (MUC) han constituidouno de sus principales foros de promocion [10]. Estas conferencias han permi-tido la evaluacion y comparacion de diversos sistemas, realizando para la EIla misma funcion que las conferencias TREC en el ambito de la recuperacionde informacion.

14 http://www.google.com/15 http://www.altavista.com/16 http://www.yahoo.com/


La busqueda de respuestas

La investigacion en sistemas de RI y EI facilito el tratamiento de grandescantidades de informacion, sin embargo, las caracterısticas que definieron estaslıneas de investigacion presentaban serios inconvenientes a la hora de facilitarla obtencion de respuestas concretas a preguntas muy precisas formuladasarbitrariamente por los usuarios.

Por una parte, los sistemas de RI se vieron incapaces por sı solos de afron-tar tareas de este tipo. De hecho, una vez que el usuario recibıa la lista dedocumentos relevantes a su pregunta, debıa revisarlos manualmente para lo-calizar en su interior la informacion puntual deseada.

Por otra parte, y aunque los sistemas de EI son mucho mas precisos enla tarea de encontrar informacion concreta en documentos, estos sistemas nopermiten el tratamiento de preguntas arbitrarias sino que el tipo de informa-cion requerida necesita ser definida de forma previa a la implementacion delsistema.

Se puede definir la busqueda de respuestas (BR) como aquella tareaautomatica realizada por ordenadores que tiene como finalidad la de encon-trar respuestas concretas a necesidades precisas y arbitrarias de informacionformuladas por los usuarios. Los sistemas de BR son especialmente utiles ensituaciones en las que el usuario final necesita conocer un dato muy especıficoy no dispone de tiempo -o no necesita- leer toda la documentacion referenteal tema de la busqueda para solucionar su problema. A modo de ejemplo,algunas aplicaciones practicas podrıan ser las siguientes:

Sistemas de ayuda en lınea de software.Sistemas de consulta de procedimientos y datos en grandes organizaciones.Interfaces de consulta de manuales tecnicos.Sistemas de consulta de bases de datos textuales de todo tipo (financieras,legales, de noticias, . . . ).

Las primeras investigaciones en este campo utilizaron, como base de de-sarrollo, la aplicacion de tecnicas de RI adecuadas al proceso de BR. Sinembargo, estas aproximaciones presentaron un pobre rendimiento cuando serequiere una respuesta escueta y precisa como contestacion a la pregunta. Apartir de ese momento, se empezo a experimentar con la aplicacion de tecnicasde PLN cada vez mas complejas que permiten, sobre todo, mejorar la preci-sion de los sistemas a la hora de localizar y extraer la respuesta exacta. Lostrabajos desarrollados en [52, 53] constituyen una buena guıa de referenciadel estado actual de las investigaciones en este campo.

3. Perspectivas de futuro

Tal y como se describe en [38], la Tecnologıa del Lenguaje Humano (TLH)se considera una tecnologıa esencial para la gestion del conocimiento y para el

212 RITOS2

uso de interfaces naturales. La TLH proporciona herramientas que facilitan eluso de servicios y aplicaciones basados en el conocimiento y ayuda a eliminarbarreras tecnologicas y sociales entre los sistemas informaticos y las personas.

Las tecnologıas demandadas por la sociedad van orientadas a la obtencionde sistemas de representacion del conocimiento y de gestion de la informacion;herramientas para el uso de contenidos digitales; creacion de interfaces multi-modales y multilingues que conlleva la interpretacion y comprension tanto dela lengua hablada como la escrita, ası como otras formas de interaccion. Estastecnologıas, realmente, lo que intentan es facilitar el acceso a la informacion.

Todo ello se traduce en la busqueda de tecnologıas que permitan un accesomultimodal a la informacion y que esta sea multilingue. Durante los ultimosanos se ha potenciado desde los programas de investigacion el acceso a ladenominada “Sociedad de la Informacion”. En sı lo que se pretende es dar,por un lado, mayor cobertura al modo de acceso a la informacion (acceso a lainformacion mediante el habla, el texto, los signos, los gestos, etc) y al tipo deinformacion (acceso multilingue a la informacion), y por otro lado, dar mayorprecision al acceso a la informacion, es decir que la busqueda de la informacionde como consecuencia la respuesta esperada por el usuario.

Figura 4. Esquema de acceso a la informacion

Tal y como se muestra en la figura 4, tres aspectos destacan en el objetivoexpuesto, que deben ser investigados: la multiculturalidad, la multimodalidady el mutilinguismo. Tres aspectos que deben marcar el acceso a la informacion.


El multilinguismo

El termino “Recuperacion de Informacion Translingue” hace referenciaal problema de, dada una consulta en determinado idioma origen, ser capazde identificar documentos relevantes escritos en uno o varios idiomas destinodistintos al de la consulta. Este problema, sin embargo, es solo uno de los as-pectos del acceso a informacion multilingue. Por ejemplo, si introducimos unaconsulta en espanol en un motor de busqueda y recibimos una lista ordenadade documentos en chino, ¿como podemos reconocer aquellos que realmentenos interesan? ¿como podemos refinar y modificar nuestra consulta a partirde esos resultados y la informacion que contienen? ¿como podemos usar lainformacion contenida en documentos que no podemos leer? Son cuestionesque apenas han sido investigadas por parte de la comunidad cientıfica inter-nacional.

Las suposiciones que se hacen sobre este tipo de problemas, para un motorde busqueda multilingue, son a) que siempre se puede acceder a un sistema co-mercial de Traduccion Automatica que traduzca los documentos al idioma delusuario, y b) que la seleccion de documentos y el refinamiento de la consultatambien puede hacerse a partir del resultado de esas traducciones.

La multiculturalidad

En ocasiones, no es suficiente proporcionar informacion meramente tra-ducida, sino que esta informacion debe adaptarse al receptor de la misma enfuncion de su origen y su entorno cultural.

Ası, es necesaria la busqueda de la representacion del conocimiento uni-versal, que pueda adaptarse con posterioridad a las caracterısticas especıficasde cada usuario.

Un ejemplo concreto de esta representacion es precisamente el uso de onto-logıas. Por ejemplo, si un usuario consulta informacion de tipo medio ambien-tal, puede hallarla en fuentes procedentes de diversas instituciones (locales,autonomicas, nacionales, internacionales, ONG’s) o entidades incluso priva-das. Esta informacion, aunque util, puede resultar difıcil de utilizar debidoa su redundancia e inconsistencia. Acceder de modo preciso a esta informa-cion es una tarea ardua y una alternativaque trata de simplificar el problemaes, desde el punto de vista de la Tecnologıa del Lenguaje Humano, el uso deontologıas.

La multimodalidad

Que se pretende con el estudio de la multimodalidad o acceso multimodala la informacion? Se pretende dar mayor cobertura de acceso a la informa-cion, derribar barreras tecnologicas, dar acceso a la informacion a colectivosmarginados por la tecnologıa, reducir el vacıo comunicativo humano-maquinarespecto a humano-humano, poner rampas a Internet, difundir otras formasde comunicacion desconocidas por la mayorıa (lenguaje de signos...). En otras

214 RITOS2

palabras, se pretende estudiar la interaccion persona-ordenador, dedicada aldesarrollo de tecnologıas que permitan que los ordenadores:

Oigan (reconocimiento de voz del hablante)Vean (cara, gestos, mirada, escritura)Hablen (voz, sıntesis facial)Sientan (sensores, reconocimiento de afectos)

3.1. Lıneas de investigacion en PLN en el GPLSI

El Grupo de Procesamiento del Lenguaje y Sistemas de Informacion delDepartamento de Lenguajes y Sistemas Informaticos es sin duda uno de losmas activos y fructıferos en el panorama del PLN espanol. Los programas dedoctorado vinculados a este grupo se enriquecen cada ano con nuevas propues-tas que atraen al estudiante de doctorado por dos razones, la formacion enPLN a traves de los cursos y la investigacion en PLN a traves de los proyectosy las tesis doctorales derivadas.

Una de las principales canteras de investigadores en el seno de este gruposon precisamente los proyectos de investigacion tanto privados como publicosnacionales y europeos. Se presentan a continuacion un conjunto de lıneas detrabajo, investigacion y desarrollo completamente actuales que estan abiertasa la incorporacion de nuevos investigadores y grupos participantes.

El GPLSI abarca, a traves de estos proyectos, la mayorıa de las lıneas detrabajo involucradas en el PLN y desarrolladas en este artıculo. Estas lıneasvan desde la creacion de recursos y herramientas de PLN hasta el desarrollode aplicaciones y plataformas de PLN orientadas al acceso a la informacionmultilingue.

El proyecto 3LB

Este proyecto, de tıtulo “Construccion de una base de datos de arbolessintactico semanticos”, fue solicitado en la convocatoria 2002 como proyectoplurianual (2002-2003) y concedida ayuda para los anos 2002 y 2003 con refe-rencias FIT-150500-2002-244 y FIT-150500-2003-411 respectivamente. El pro-yecto tiene como objetivo construir un corpus anotados sintactica, semanticay referencialmente (treebanks) para los idiomas espanol, catalan y euskera.

A pesar de que la construccion de un treebank es una tarea costosa, cree-mos que es una labor imprescindible para el desarrollo de aplicaciones realesen el area del Procesamiento del Lenguaje Natural (PLN) y como tal parael desarrollo de la sociedad de la informacion. En estas aplicaciones resultaimprescindible la obtencion de gramaticas computacionales a partir de corpusque son un primer paso hacia procesos posteriores que requieren mas elabora-cion. Entre estos procesos se halla la delimitacion de las entidades discursivas,lo que, junto con la identificacion de los elementos anaforicos y correferentes


mejora sustancialmente la calidad de los sistemas de Traduccion Automati-ca (TA), Extraccion de Informacion (EI), Recuperacion de Informacion (RI),Resumen Automatico (RA) y sistemas de Pregunta-Respuesta (PR). Otrastareas linguısticas que pueden abordarse si se dispone de un treebank son elaprendizaje de restricciones de seleccion o el de los patrones de subcategori-zacion de los verbos.

A nivel puramente linguıstico, el treebank es una base de datos impres-cindible para el estudio de la lengua ya que proporciona ejemplos analiza-dos/anotados de lenguaje real. El estudio linguıstico revierte directamente enla mejora de la calidad de los recursos mencionados, dotandolos de una mayorrobustez.

La estrategia de anotacion morfologica y sintactica de los corpus se harealizado de manera semiautomatica intentando facilitar la tarea mediante eluso de herramientas de desambiguacion automatica (desambiguacion morfo-sintactica y sintactica) que proporcionan unos niveles de precision aceptablespara su uso en el proceso de supervision. Ademas de los niveles sintactico ysemantico, la anotacion tambien trata una tercera dimension, el etiquetadocorreferencial en el que se abordaran algunos fenomenos de elipsis y anaforaası como el establecimiento de las cadenas de correferencia. En el caso de laanotacion automatica de la semantica, los metodos actuales obtienen unosniveles de precision que no son lo suficientemente adecuados para su utili-zacion en el proceso de supervision. Debido a esto, se ha optado por definiruna estrategia totalmente manual disenando una herramienta que, utilizan-do los recursos linguısticos disponibles, facilite la tarea a los anotadores. Sinembargo, se ha dejado abierta la posibilidad de utilizar un sistema de desam-biguacion semantica automatico, bien exigiendo que el formato de salida deldesambiguador se ajuste al XML definido en el proyecto, o bien incorporando-lo a la herramienta.

3LB-SEARCH: la explotacion del corpus 3LB

3LB-Search supone una ramificacion natural a partir de las experienciascon el proyecto 3LB antes descrito. El principal objetivo que se persigue enesta accion es la construccion de un sistema de explotacion, consulta y busque-da de informacion en un corpus anotado morfologica, sintactica, semantica ycorreferencialmente. Este objetivo se pretende conseguir a traves de la conse-cucion de las siguientes lıneas de actuacion cientıfico-tecnologicas:

Analisis linguıstico de las principales fuentes de informacion de especialinteres para la comunidad cientıfica y social para la definicion de los re-quisitos de informacion relevante a extraer desde los recursos.Definicion de la plataforma computacional que integre herramientas y re-cursos en lo referente a los lenguajes de programacion, plataformas web ysistemas operativos.Implementacion del sistema de explotacion, consulta y busqueda de infor-macion en corpus.

216 RITOS2

Evaluacion y retroalimentacion que permitira definir con mayor y mejorprecision las caracterısticas del sistema desarrollado.

Dada la estrecha vinculacion de esta accion especial con el proyecto 3LB,los integrantes del equipo investigador de la presente propuesta tambien lo sondel proyecto 3LB. La necesidad de una herramienta de este tipo basada en laexperiencia en el desarrollo de corpus en el contexto de 3LB es precisamenteuna de las motivaciones principales para la peticion de esta accion. Cada unade las lıneas de actuacion cientıfico-tecnologicas definidas con anterioridad,constituyen un bloque dentro del plan de trabajo de la presente accion:

Tarea 1: Analisis linguıstico y definicion de requisitos. La definicion ini-cial de el conjunto de elementos relevantes en cuanto a las necesidades deexplotacion y busqueda de informacion resulta imprescindible para la crea-cion de una herramienta que se adecue a las necesidades de los usuariospotenciales.Tarea 2: Definicion de la plataforma computacional. Es necesario definirel conjunto de herramientas software que intervendran en los procesos deimplementacion del sistema. Ası, tanto los lenguajes de programacion autilizar, los sistemas de indexacion, las posibles plataformas web o lossistemas operativos seran definidos convenientemente para cumplir los ob-jetivos de claridad, accesibilidad y universalidad definidos en la accion.Tarea 3: Implementacion del sistema. A partir de las dos tareas anteriores,la accion conlleva una importante labor de implementacion en la que sedesarrollaran los programas e interfaces necesarios para la explotacion,consulta y busqueda de informacion en el corpus 3LB objeto de la presentepropuesta.Tarea 4: Evaluacion. Una vez desarrollado el sistema con los requerimien-tos tecnologicos y linguısticos adecuados, se pondra en marcha un procesode evaluacion del sistema que asegurara el correcto funcionamiento y acce-sibilidad del usuario al mismo. Los problemas y modificaciones que surjana partir de este proceso de evaluacion serviran para mejorar el sistema deacuerdo a las necesidades del usuario.

Proyecto ELEDOS

La Sociedad de la Informacion demanda aplicaciones de facil acceso e in-tuitivas que le proporcionen la posibilidad de acceder al ambito multilingue ymulticultural europeo.

Tal y como se ha comentado, el desarrollo de recursos linguısticos es unalınea de investigacion de gran impulso y larga trayectoria. Sin embargo, existeuna ausencia de plataformas que integren todos estos recursos con el objetivode cooperar entre sı, en concreto, orientados al ambito educativo y especial-mente al aprendizaje de lenguas. El proyecto ELEDOS “Plataforma multi-lingue para el aprendizaje de segundas lenguas basada en la integracion de


recursos de Ingenierıa Linguıstica” esta siendo gestado en el seno del GPLSIcomo solicitud para la convocatoria de los proyecto europeos e-CONTENT.Este proyecto pretende el desarrollo de una plataforma que integre recursosexistentes de Ingenierıa Linguıstica a traves de Internet orientada al apren-dizaje de lenguas que haga accesible, de forma amigable e intuitiva, a la co-munidad europea e internacional recursos linguısticos que hasta el momentohabıan sido utilizados por la comunidad cientıfica pero que habıan tenido unabaja disponibilidad para el usuario no experto.

Para la consecucion de este proyecto se propone la integracion de recursoslinguısticos multilingues a diferente escala en funcion de la disponibilidad derecursos por cada una de las lenguas con una tecnologıa informatica abier-ta independiente de las herramientas elegidas que permita la actualizacion,sustitucion y extension de los diferentes modulos linguısticos que la integran.

Esta plataforma, independiente de la lengua, define un conjunto de nivelesde desarrollo que involucran diferentes etapas dentro del proyecto:

1. Integracion, adaptacion y uso de los recursos linguısticos disponibles pa-ra cada una de las lenguas participantes en el proyecto (catalan, ingles,espanol, euskera, rumano, polaco)

2. Analisis del sistema de informacion que integre los diferentes modulos queconforman la aplicacion final.

3. Definicion de estandares de comunicacion entrada/salida de los diferentesmodulos entre sı y con el sistema ası como la arquitectura de intercambiode informacion.

4. Diseno y funcionalidades psicopedagogicas con la definicion de itinerariosdidacticos.

5. Diseno de una interfaz de usuario amigable e intuitiva que se fundamenteen las bases metodologicas previamente definidas.

6. Implementacion de la plataforma de integracion de los recursos linguısticosmultilingues orientada al aprendizaje de distintas lenguas.

7. Evaluacion y retroalimentacion por parte de los usuarios finales.8. Definicion de criterios y lıneas de actuacion para la creacion de recursos

en las lenguas menos extendidas sobre la base de los existentes para laslenguas mas utilizadas.

Tal y como se ha comentado, el principal objetivo que se persigue en estapropuesta es la construccion de una plataforma que integre recursos linguısti-cos multilingues ya existentes orientada al aprendizaje de segundas lenguas.

Para llevar a cabo este objetivo principal se definen los siguientes objetivosconcretos:

Difusion e integracion de las lenguas de la Union Europea.Promocion, a traves de la plataforma, de la multiculturalidad y el multi-linguismo en la Sociedad de la Informacion.Uso de un modelo psicolinguıstico que garantice la adecuacion a los obje-tivos del aprendizaje.

218 RITOS2

Disponibilidad, accesibilidad y uso de contenidos linguısticos digitales eu-ropeos en las redes mundiales.Definicion de un marco tecnologico y linguıstico abierto y escalable quepermita la incorporacion progresiva de recursos independientemente delnivel de disponibilidad de los mismos para cada una de las lenguas.

Cada lengua incorporara los recursos actualmente disponibles, lo quedara lugar a diferentes niveles de funcionalidad segun la lengua. Con el tiem-po se podran ir cubriendo los diferentes modulos. La participacion en esteproyecto podra servir de orientacion en el diseno e implementacion de nuevosrecursos partiendo de la base del trabajo ya realizado en las otras lenguas.

Ademas de las evidentes connotaciones computacionales que acarrea laconsecucion de una plataforma orientada al aprendizaje de lenguas no serıaposible desarrollarla sin definir una base psicopedagogica solida que sustentelas funcionalidades del sistema. Desde nuestro punto de vista, y en terminosmuy generales, un sistema de este tipo tiene que incorporar las siguientescaracterısticas:

Conocimiento linguıstico rico y justificadoPlan didactico relacionado con el contenido linguısticoRecursos computacionales que permitan al sistema ser mas que un libroen formato electronico, con una interfaz amigable e intuitiva que permitausarlo con comodidadPortabilidad a otras lenguas y capacidad de ser actualizado y extendidocon nuevos modulosIndependencia de la plataforma con respecto a los modulos linguısticos quela integran

Los usuarios que accedan al sistema contaran con un amplio abanico defuncionalidades que se adaptara a sus criterios particulares y sus necesidades.Ası, el usuario podra navegar por el sistema definiendo sus propios itinerariosde aprendizaje. Veamos un ejemplo de este tipo de itinerarios:

- Una persona esta leyendo un libro en espanol y encuentra una palabra queno sabe:. P.e.: tuvo.

- Al escribir esta palabra en la interfaz el sistema le informa de que es elpreterito indefinido del verbo tener (llamada al analizador morfologico).

- Como no conoce el significado de tener, consulta el diccionario y obtieneuna lista de definiciones. Tras leerlas, sigue sin entender los matices.

- Entonces el usuario solicita ejemplos de uso para cada sentido/definicion.(llamada al corpus etiquetado semanticamente).

- Para que le quede mas claro, solicita palabras relacionadas con cada unode los sentidos (busqueda en WordNet ).

- Finalmente, solicita la traduccion de cada uno de los sentidos a ingles(llamada a diccionario bilingue espanol-ingles).


Con itinerarios de este tipo, no predefinidos sino completamente abiertosal usuario en funcion de sus necesidades, el aprendizaje de segundas lenguasalcanza dimensiones hasta ahora desconocidas ante la inexistencia de unaplataforma de estas caracterısticas basada exclusivamente en herramientas yrecursos de Ingenierıa Linguıstica.

R2D2: Recuperacion de Respuestas en Documentos Digitalizados

Durante los ultimos veinte anos se ha producido un crecimiento expo-nencial de la cantidad de informacion digital disponible unido a una fuer-te expansion de las comunicaciones entre ordenadores como vıa principal detransmision de informacion entre usuarios. La gran cantidad de informaciondisponible -principalmente de caracter textual- junto al creciente numero deusuarios finales que disponen de acceso directo a dicha informacion a travesde ordenadores personales, ha impulsado la investigacion en sistemas de in-formacion textual que faciliten la localizacion, acceso y tratamiento de todaesta ingente cantidad de datos.

Ademas, la creciente informacion existente en diferentes lenguas requieresistemas que permitan recuperar o extraer informacion solicitada en el idiomano solo origen (es decir en el que se formula la pregunta) sino tambien en elidioma destino (es decir en el que esta escrita la pregunta).

Todos estos inconvenientes, la apuesta e inversion por el desarrollo de sis-temas realistas en determinados escenarios de busqueda (aunque hay otros es-cenarios realistas en los que el proyecto no se centra, y que requieren otro tipode tecnologıas) y, principalmente, un creciente interes en sistemas que afronta-ran con exito la tarea de localizar respuestas concretas en grandes volumenesde informacion, dejaron la puerta abierta a la aparicion de nuevos campos deinvestigacion tales como Busqueda de Respuestas (BR) -Question Answering(QA)-, Busqueda interactiva de Respuestas (BiR), Recuperacion interactivade informacion (RiI), Busqueda de documentos transcritos -Spoken DocumentRetrieval (SDR)- o Recuperacion de informacion translingue (RIT). Estos nue-vos campos de investigacion indican el interes cientıfico por impulsar el accesointeractivo a la informacion multilingue, denominador comun del proyecto queaquı se presenta.

El gran interes de estos sistemas ha sido potenciado por la definicion detareas especıficas para la evaluacion de sistemas de BR, BiR, RIT y SDRdentro de la serie de congresos TREC (Text REtrieval Conference) patroci-nadas por NIST17 , DARPA18 y ARDA19. Estas reuniones han dado un granempuje a estas lıneas de investigacion no solo como plataforma de evaluacion,comparacion y difusion de los sistemas existentes, sino, principalmente, porsu decidida apuesta en fomentar mejoras en los sistemas a traves de la conti-nua introduccion de nuevos retos a afrontar. Por ello, en solo tres anos, estos

17 National Institute of Standards and Technology18 Technology Office of the Defense Advanced Research Projects Agency19 Advanced Research and Development Activity

220 RITOS2

congresos se han convertido en el principal foro de discusion y promocion deeste tipo de sistemas en todo el mundo.

La campana internacional CLEF (Cross-Language Evaluation Forum) secentra en el desarrollo de infraestructura necesaria para la experimentacion yevaluacion de sistemas de recuperacion de informacion que trabajen sobre laslenguas europeas en contextos monolingues y translingues, y en la creacionde conjuntos de datos reutilizables por los sistemas desarrollados. La organi-zacion de estas campanas de evaluacion esta permitiendo la creacion de unacomunidad de investigadores y desarrolladores centrados en el mismo proble-ma y facilitando llevar a cabo iniciativas de colaboracion futura entre gruposparticipantes que comparten intereses similares. Estas campanas CLEF per-miten a los grupos participantes establecer lazos de union, intercambio deideas y la posibilidad de compartir de resultados. Existen iniciativas simila-res de evaluacion en EEUU y Asia, aunque trabajen para otros conjuntos delenguas. Las campanas CLEF destacan por su caracter dinamico, dado quelos investigadores pueden proponer nuevas tareas para ser evaluadas. Por otrolado, la participacion en estas campanas supone para los grupos participantes,y en concreto para los grupos espanoles un gran reto y gran valıa cualitativadesde la base que pueden probar y evaluar sus ideas ademas de la tecnologıadesarrollada (los equipos investigadores de la UNED, la UA y la UJA queproponen este proyecto han participado de forma activa durante los ultimosanos).

Siguiendo la lınea tratada en las perspectivas futuras del presente traba-jo, el GPLSI ha propuesto como coordinador un proyecto en el seno de laconvocatoria de ayudas de Proyectos de Investigacion Cientıfica y DesarrolloTecnologico del ano 2003.

La finalidad principal u objetivo del proyecto es doble. En primer lugar sepersigue participar en la organizacion de la campana internacional de evalua-cion multilingue (CLEF), proponiendo criterios y nuevas tareas relacionadascon el acceso a la informacion multilingue (Multilingual Information Access):evaluar sistemas de acceso a la informacion, y estudiar aspectos interactivosde este tipo de tareas. En segundo lugar, se plantea el desarrollo de sistemasde acceso a la informacion, estudiando, por un lado, los aspectos multilinguese interactivos y, por otro, la robustez de los sistemas en documentos escritosy transcritos.

El proyecto se centra, pues, en la organizacion de campanas internacionalesde evaluacion:

Evaluacion de sistemas de Busqueda de Informacion Multilingue (CLEF)Evaluacion de sistemas de Busqueda de Respuestas multilingues (CLEFQ & A)Evaluacion de aspectos interactivos de la Busqueda de Respuestas Multi-lingue (iCLEF)


Y en el desarrollo de sistemas de acceso a la informacion, en sus variantesinteractivas y multilingues. A continuacion se definen los sistemas propuestospara dicho desarrollo:

Sistemas de busqueda de respuestas

• Construccion de un sistema de Busqueda de Respuestas multilingue(Multilingual Question Answering)

• Construccion de un sistema de Busqueda interactiva de Respuestasmultilingue (Interactive Multilingual Question Answering)

• Construccion de un sistema de Busqueda de Respuestas en documentostranscritos (Spoken Document Retrieval)

Sistemas de busqueda de documentos

• Recuperacion de informacion multilingue basada en pasajes• Recuperacion de objetos multimedia

Para el desarrollo de los sistemas propuestos se propone la reutilizacion ycreacion de recursos y tecnicas orientadas a este tipo de tareas que permitanafrontan como denominador comun el acceso a la informacion multilingue.

4. Conclusiones

Este trabajo ha realizado un pequeno recorrido por el ciclo del Procesa-miento del Lenguaje Natural y los elementos que este involucra.

Es evidente que el tema es suficientemente amplio como para ser recogidoen unas pocas paginas, y este artıculo no persigue tal ambicion. Recoge, porun lado una breve descripcion de los recursos, herramientas y aplicacionesmas relevantes en el Procesamiento de la lengua escrita y se fundamenta enlas experiencias del Grupo de Procesamiento del Lenguaje y Sistemas de In-formacion del Departamento de Lenguajes y Sistemas Informaticos de la Uni-versidad de Alicante. La bibliografıa acompanada, no obstante, podra servirde complemento para completar informacion sobre aspectos menos tratados.

Ası mismo, se han descrito las principales lıneas de trabajo e investigacionque, con caracter abierto y actual, se estan desarrollando en el seno del GPLSIintentando abarcar, a traves de su experiencia, la mayor cantidad de aspectosrelacionados con el ciclo del PLN.

Confıo en que este documento pueda servir de ayuda y referencia a todosaquellos que, sin dominar el area del PLN, sientan interes por conocer sualcance y les permita profundizar mas y mejor en cualquiera de los aspectosaquı tratados.

Agradecimientos

Quiero agradecer a los miembros del Grupo de Procesamiento del Len-guaje y Sistemas de Informacion del Departamento de Lenguajes y Sistemas

222 RITOS2

Informaticos de la Universidad de Alicante la ayuda prestada para la elabo-racion del presente documento, en especial a Patricio Martınez (sistemas dedialogos), Manuel Palomar (perspectivas de futuro), Jesus Peral (traduccionautomatica) y Jose Luis Vicedo (acceso a la informacion).

Referencias

1. J. Allen, D. Byron, M. Dzikovska, G. Ferguson, L. Galescu, and A. Stent. To-wards a Generic Dialogue Shell. Natural Language Engineering, 6(3):1–16, 2000.

2. Breck Baldwin. CogNIAC: high precision coreference with limited knowled-ge and linguistic resources. In Proceedings of the ACL’97/EACL’97 workshopon Operational Factors in Practical, Robust Anaphor Resolution, pages 38–45,Madrid, Spain, July 1997.

3. N.O. Bernsen, H. Dybkjaer, and L. Dybkjaer. Designing interactive SpeechSystems: From first Ideas to User Testing. Springer, Berlin/New York, 1998.

4. S.E. Brennan, M.W. Friedman, and C.J. Pollard. A centering approach topronouns. In Proceedings of the 25st Annual Meeting of the Association forComputational Linguistics (ACL’87), pages 155–162, Stanford, California. USA,July 1987.

5. Donna K. Byron and James F. Allen. Applying Genetic Algorithms to PronounResolution. In Proceedings of the Sixteenth National Conference on ArtificialIntelligence (AAAI’99), page 957, Orlando, Florida, July 1999.

6. Jaime G. Carbonell and Ralph D. Brown. Anaphora resolution: a multi-strategyapproach. In Proceedings of 12th International Conference on ComputationalLinguistics (COLING’88), pages 96–101, Budapest, Hungary, 1988.

7. Claire Cardie and Kiri Wagstaff. Noun Phrase Coreference as Clustering. InProceedings of the Joint SIGDAT Conference on Empirical Methods in NLP andVery Large Corpora, pages 82–89, Maryland, USA, June 1999.

8. David M. Carter. Common sense inference in a focus-guided anaphor resolver.Journal of Semantics, 4:237–246, 1987.

9. Noam Chomsky. Lectures on Government and Binding. Foris Publications,Dordrecht, Holland, 1981.

10. Nancy A. Cinchor. Overview of MUC/MET-2. In Seventh Message Understan-ding Conference, Washington D.C., USA, 1998.

11. Ido Dagan and Alon Itai. Automatic processing of large corpora for the reso-lution of anaphora references. In Proceedings of 13th International Conferenceon Computational Linguistics (COLING’90), pages 330–332, Helsinki, Finland,1990.

12. Ido Dagan and Alon Itai. A statistical filter for resolving pronoun references.Artificial Intelligence and Computer Vision, pages 125–135, 1991.

13. Oswald Ducrot and Jean-Marie Schaffer. Nuevo diccionario enciclopedico de lasciencias del lenguaje. Arrecife, Madrid, Espana, 1998.

14. M.G. Fernandez. Un modelo para la especificacion linguıstica y la gestion com-putacional en dialogos hombre-maquina mediante instrucciones expresadas enlenguaje natural. PhD thesis, Universidad de Sevilla, Departamento de Filo-logıa Inglesa. Facultad de Filologıa, Sevilla, 2000.


15. Antonio Ferrandez. Aproximacion computacional al tratamiento de la anaforapronominal y de tipo adjetivo mediante gramaticas de unificacion de huecos.PhD thesis, Departamento de Lenguajes y Sistemas Informaticos, Universidadde Alicante, Alicante, Espana, 1998.

16. Niyu Ge. An approach to anaphoric pronouns. PhD thesis, Department ofComputer Sicence. Brown University, Providence. Rhode Island. USA, 2000.

17. Niyu Ge, John Hale, and Eugene Charniak. A statistical approach to anaphoraresolution. In Eugene Charniak, editor, Proceedings of Sixth WorkShop on VeryLarge Corpora, pages 161–170, Montreal, Canada, 1998.

18. Barbara Grosz, Aravind Joshi, and Scott Weinstein. Centering: a framework formodeling the local coherence of discourse. Computational Linguistics, 21(2):203–225, 1995.

19. Barbara Grosz and Candace Sidner. Attentions, intentions and the structure ofdiscourse. Computational Linguistics, 12:175–204, March 1986.

20. Graeme Hirst. Anaphora in Natural Language Understanding: A Survey, volume119 of Lecture Notes in Computer Science. Springer-Verlag Publishers, Berlin,Germany, 1981.

21. Jerry R. Hobbs. Pronoun resolution. Research report # 76-1, Department ofComputer Sciences. City College. City University of New York, New York, USA,August 1976.

22. Jerry R. Hobbs. Resolving pronoun references. Lingua, 44:311–338, 1978.23. W.J. Hutchins and H.L. Somers. An Introduction to Machine Translation. Aca-

demic Press Limited, London, 1992.24. R. Jakobson. Ensayos de linguıstica general. Obras maestras del pensamiento

contemporaneo. Planeta-Agostini, Barcelona, 1985.25. Marcin Kaszkiel, Justin Zobel, and Ron Sacks-Davis. Efficient passage ranking

for document databases. ACM Transactions on Information Systems, 17(4):406–439, October 1999.

26. Christopher Kennedy and Branimir Boguraev. Anaphora for everyone: pronomi-nal anaphora resolution without a parser. In Proceedings of 16th InternationalConference on Computational Linguistics, volume I, pages 113–118, Copenha-gen, Denmark, 1996.

27. Shalom Lappin and Herbert Leass. An algorithm for pronominal anaphoraresolution. Computational Linguistics, 20(4):535–561, 1994.

28. Kavi Mahesh and Sergei Nirenburg. A Situated Ontology for Practical NLP.In Proceedings of Workshop on Basic Ontological Issues in Knowledge Sharing.International Joint Conference on Artificial Intelligence (IJCAI’95), Montreal,Canada, August 1995.

29. Marıa A. Martı, Juan A. Alonso, Toni Badia, Joan Campas, Xabier Gomez, JulioGonzalo, Joaquim Llisterri, Joaquim Rafel, Horacio Rodrıaguez, Joan Soler, andM. Felisa Verdejo. Tecnologıas del Lenguaje. Editoral UOC, Barcelona, 2003.

30. P. Martınez-Barco. Resolucion computacional de la anafora en dialogos: es-tructura del discurso y conocimiento linguıstico. PhD thesis, Universidad deAlicante, Alicante, Spain, 2001.

31. George A. Miller, Richard Beckwith, Christiane Fellbaum, Derek Gross, andKatherine J. Miller. Five Papers on WordNet. Special Issue of the InternationalJournal of Lexicography, 3(4):235–312, 1993.

32. Ruslan Mitkov. Anaphora resolution: a combination of linguistic and statisticalapproaches. In Proceedings of the Discourse Anaphora and Anaphor ResolutionColloquium (DAARC’96), Lancaster, UK, 1996.

224 RITOS2

33. Ruslan Mitkov. Robust pronoun resolution with limited knowledge. In Procee-dings of the 36th Annual Meeting of the Association for Computational Linguis-tics and 17th International Conference on Computational Linguistics (COLING-ACL’98), pages 869–875, Montreal, Canada, August 1998.

34. Lidia Moreno, Manuel Palomar, Antonio Molina, and Antonio Ferrandez. In-troduccion al Procesamiento del Lenguaje Natural. Servicio de Publicaciones dela Universidad de Alicante, Alicante, Espana, 1999.

35. Juan C. Moreno-Cabrera. Curso universitario de linguıstica general, volume 1.Sıntesis, Madrid, Espana, 1991.

36. Rafael Munoz and Manuel Palomar. Semantic-driven Algorithm for DefiniteDescription Resolution . In Proceedings of the International Conference on Re-cent Advances in Natural Language Processing (RANLP’2001), pages 180–186,Tzigov Chark, Bulgaria, September 2001.

37. Division of Behavioral Sciences. National Academy of Sciences National Resear-ch Council. The ALPAC Report. 1966.

38. Manuel Palomar. R-evolucion tecnologica, chapter Acceso Multimodal a la In-formacion Multilingue, pages 49–54. 2003.

39. Manuel Palomar, Antonio Ferrandez, Lidia Moreno, Maximiliano Saiz-Noeda,Rafael Munoz, Patricio Martınez-Barco, Jesus Peral, and Borja Navarro. ARobust Partial Parsing Strategy based on the Slot Unification Grammars. InProceeding of the Sixth Conference on Natural Language Processing (TALN’99),pages 263–272, Corsica, France, 1999.

40. Manuel Palomar, Antonio Ferrandez, Lidia Moreno, Patricio Martınez-Barco,Jesus Peral, Maximiliano Saiz-Noeda, and Rafael Munoz. An algorithm forAnaphora Resolution in Spanish Texts. Computational Linguistics, 27(4):545–567, 2001.

41. Manuel Palomar and Patricio Martınez-Barco. Computational approach toanaphora resolution in Spanish dialogues. Journal of Artificial Intelligence Re-search, 15:263–287, 2001.

42. Jesus Peral. Resolucion y generacion de la anafora pronominal en espanol e in-gles en un sistema interlingua de traduccion automatica. PhD thesis, Departa-mento de Lenguajes y Sistemas Informaticos. Universidad de Alicante, Alicante,Espana, 2001.

43. Jesus Peral and Antonio Ferrandez. Translation of Pronominal Anaphora bet-ween English and Spanish Languages: Discrepancies and Evaluation. Journalof Artificial Intelligence Research, 18:117–147, 2003.

44. Ferran Pla. Etiquetado lexico y analisis sintactico superficial basado en modelosestadısticos. PhD thesis, Departamento de Sistemas Informaticos y Computa-cion. Universidad de Politecnica de Valencia, Valencia, Espana, 2000.

45. Ferran Pla and Antonio Molina. Part-of Speech Tagging with Lexicalized HMM.In Proceedings of the International Conference on Recent Advances in NaturalLanguage Processing (RANLP’2001), Tzigov Chark, Bulgaria, September 2001.

46. Tanya Reinhart. Anaphora and Semantic Interpretation. Croom Helm linguisticsseries. Croom Helm Ltd, London, UK, 1983.

47. Elaine Rich and Susan Luperfoy. An Architecture for Anaphora Resolution. InProceedings of the Second Conference on Applied Natural Language Processing,pages 18–24, Austin, Texas, 1998.

48. Maximiliano Saiz-Noeda. Influencia y aplicacion de papeles sintacticos e infor-macion semantica en la resolucion de la anafora pronominal en espanol. PhD


thesis, Departamento de Lenguajes y Sistemas Informaticos. Universidad deAlicante, Alicante, Espana, junio 2002.

49. T. Strzalkowski, G. Stein, G. Bowden Wise, J. Perez-Carballo, P. Tapananinen,T. Jarvinen, A. Voutilainen, and J. Karlgren. Natural language informationretrieval: TREC-7 report. In Seventh Text REtrieval Conference, volume 500-242 of NIST Special Publication, pages 217–226, Gaithersburg, USA, nov 1998.National Institute of Standards and Technology.

50. Pasi Tapanainen and Timo Jarvinen. A non-projective dependency parser. InProceedings of the Fifth Conference on Applied Natural Language Processing,pages 64–71, Washington DC, USA, April 1997.

51. Joel R. Tetreault. Analysis of Syntax-Based Pronoun Resolution Methods. InProceedings of the 37th Annual Meeting of the Association for ComputationalLinguistics (ACL’99), pages 602–605, Maryland, USA, June 1999.

52. Jose Luis Vicedo. SEMQA: Un modelo semantico aplicado a los sistemas deBusqueda de Respuestas. PhD thesis, Departamento de Lenguajes y SistemasInformaticos. Universidad de Alicante, Ctra. de San Vicente s/n. 03080 Alicante.Espana, May 2002.

53. Jose Luis Vicedo. La Busqueda de Respuestas: Estado Actual y Perspectivas deFuturo. Revista Ibero-americana de Inteligencia Artificial. Monografico Accesoa Informacion Multilingue (Pendiente de publicacion)., (20), 2003.

54. Renata Vieira and Massimo Poesio. An Empirically-Based System for Proces-sing Definite Descriptions. Computational Linguistics, 26(4):539–593, 2000.

55. Piek Vossen. EuroWordNet: Building a Multilingual Database with WordNetsfor European Languages. The ELRA Newsletter, 3(1), 1998.

56. Piek Vossen. EuroWordNet: a Multilingual Database with WordNets in 8 lan-guages. The ELRA Newsletter, 5(1):9–10, 2000.

57. Piek Vossen, Laura Bloksma, Horacio Rodrıguez, Salvador Climent, NicolettaCalzolari, Adriana Roventini, Francesca Bertagna, Antonietta Alonge, and WimPeters. The EuroWordNet Base Concepts and Top Ontology. Deliverable D017,D034, D036, WP5, EuroWordNet, LE2-4003 TR-11, 1998.

226 RITOS2

Modelando Interfaces para Aplicaciones Web

Luis A. Guerrero

Departamento de Ciencias de la Computación Universidad de Chile

Blanco Encalada 2120, Santiago, Chile [email protected]

Abstract. Muy poco de lo aprendido en el área de Ingeniería de Software se aplica en el desarrollo de sistemas Web, entre otras cosas, porque hay diferencias importantes en cuanto al diseño, desarrollo y mantenimiento de los sistemas Web, respecto de las aplicaciones tradicionales. Parte importante de un sistema Web tiene que ver con su contenido, su diseño gráfico y su modelo de navegación, además de su funcionalidad. En el presente artículo se muestran algunas taxonomías para sistemas Web, y se revisan algunas de las principales propuestas para modelar las interfaces de estos sistemas.

1. Introducción

El desarrollo y crecimiento de la Web han sido vertiginosos y sin precedentes durante los últimos años, en cuanto a número de usuarios conectados, cantidad de sitios o portales Web, y cantidad y tipo de herramientas para construir páginas y sitios Web. Este crecimiento ha provocado un significativo impacto en áreas tales como: negocios, finanzas, entretenimiento, comunicación, educación, gobierno, industria, e incluso en nuestra vida personal. Existen numerosos lenguajes y tecnologías relacionadas con la programación de aplicaciones que permiten generar páginas Web, no sólo del lado del servidor (server-side Web pages) sino también del lado del cliente (client-side Web pages). Esta enorme cantidad de recursos, y esta característica dual de las aplicaciones Web (que poseen un conjunto de funcionalidades independientes del lado del cliente y del lado del servidor), dificulta enormemente el análisis y diseño de este tipo de aplicaciones.

Las nuevas tendencias hacia el comercio electrónico, el trabajo en la casa, la transformación de aplicaciones tradicionales (legacy systems) a aplicaciones con interfaces Web, y la expansión de Internet hacia nuevos servicios y hacia otras áreas como la televisión, los teléfonos celulares (tecnología WAP), e incluso algunos electrodomésticos, hace pensar que este gran auge va a continuar por mucho más tiempo. Se van a requerir, entonces, aplicaciones cada vez más sofisticadas, pero con interfaces más claras y fáciles de usar, que puedan llegar a más gente. También es de esperar que se desarrollen más y mejores herramientas para el desarrollo de aplicaciones y páginas Web, que apoyen tanto su funcionalidad como el diseño gráfico de su interfaz y su contenido.

Podríamos decir que el actual desarrollo de sitios y aplicaciones Web está caracterizado por cuatro importantes factores: (1) las aplicaciones y sitios Web son cada vez más complejos en cuanto a gráfica, contenido y funcionalidad; (2) cada vez hay más y mejores herramientas de desarrollo; (3) los tiempos de desarrollo requeridos por las empresas son cada vez más cortos, para estar mejor posicionados que la competencia; (4) las aplicaciones y sitios Web requieren cambios periódicos tanto de contenido como de gráfica, para mantenerse atractivos a los usuarios, es decir, requieren un gran esfuerzo en mantenimiento.

Estos cuatro factores, entre otros, contribuyen a que el actual desarrollo de aplicaciones y sitios Web sea hecho ad hoc para cada proyecto, lo que requiere, en el corto plazo, un gran número de parches y cambios. Murugesan et. al sostienen que “el desarrollo de sistemas basados en Web, carece de rigor, de un enfoque sistemático, de control de calidad y de aseguramiento de la calidad” [1]. La alta probabilidad de fallas de los sistemas Web construidos hasta ahora (por falta de metodologías más rigurosas), y el hecho de que, al hacerse los sistemas cada vez más complejos, una falla puede ser propagada a muchos lugares a la vez (un error puede ser ejecutado muchas veces en muchos sitios simultáneamente), pueden provocar un quiebre irreparable de la confianza de los usuarios en el Web, causando así lo que ha sido definido como la crisis del Web [2].

Para evitar una posible crisis del Web, y lograr éxito en el desarrollo de aplicaciones Web cada vez más complejas, hay una imperiosa necesidad por enfoques disciplinados, y nuevos métodos y herramientas de desarrollo y evaluación de sistemas basados en Web [1]. Esta rigurosidad quizás debería partir por el diseño de la interfaz. La interfaz del sitio o aplicación Web es lo primero que piensa el cliente que solicita un proyecto de desarrollo sobre Web, y por tanto debería ser uno de los primeros artefactos que se diseñen, contrario al desarrollo de aplicaciones tradicionales, donde el diseño de la interfaz se realiza en una de las etapas finales del ciclo de desarrollo.

En el presente artículo se hace una revisión de las más recientes tecnologías para modelar y diseñar aplicaciones Web, principalmente aquellas que ponen énfasis en la forma de modelar interfaces. En la sección 2 se discuten algunas características de los sistemas Web, y se muestran algunas taxonomías. En la sección 3 se presentan algunas de las metodologías de desarrollo de proyectos Web más referenciadas en la literatura. La sección 4 presenta la propuesta de la arquitectura J2EE para el desarrollo de aplicaciones sobre Internet. Finalmente, en la sección 5 se discuten algunas diferencias entre sistemas tradicionales y sistemas Web, y se presentan algunas conclusiones sobre la importancia de utilizar métodos formales para el desarrollo de aplicaciones Web, principalmente para el diseño y construcción de sus interfaces.

2. Taxonomías Web

La poca rigurosidad en el desarrollo de sitios Web se nota desde la terminología utilizada. Términos como aplicación Web y sitio Web tienen distintos significados para distintos autores. Varios autores han definido taxonomías para tratar de clasificar

228 RITOS2

los distintos tipos de aplicaciones Web. Por ejemplo, Ginige y Murugesan [7] definen las siguientes categorías de aplicaciones Web: informativas (noticias en línea, servicios de noticias, catálogos, manuales), interactivas (formularios de registro, servicios en línea), transaccionales (compras electrónicas, bancos en línea), sistemas de workflow (planificación en línea, administración de inventarios, monitoreo), ambientes de trabajo colaborativo (sistemas distribuidos de autoría, herramientas colaborativas), comunidades en línea (grupos de chat, sistemas de recomendación), portales Web (centros comerciales electrónicos, intermediarios en línea).

Por su parte, Pressman define las siguientes categorías de aplicaciones Web [8]: informativas (se proporciona un contenido sólo de lectura con navegación y enlaces simples), de descarga (el usuario descarga información desde el servidor), personalizable (el usuario personaliza el contenido según sus propias necesidades), interactivas (comunicación entre comunidades de usuarios), con entradas de usuario (el ingreso de información por parte del usuario a través de formularios es el mecanismo primario), orientadas a transacciones (solicitudes del usuario al servidor Web), orientadas a servicios (proporcionan servicios a los usuarios), portales (el usuario navega en la aplicación y esta lo lleva a servicios fuera del dominio del portal), con acceso a bases de datos (el usuario extrae información de una base de datos), almacenes de datos (el usuario consulta información en una colección grande de datos).

Jim Conallen trata de establecer algunas diferencias entre los sistemas Web desde el punto de vista de la modificación de la lógica del negocio. Según Conallen, una aplicación Web es un sistema Web (servidor Web, red, protocolo HTTP, y browser) en el cual el usuario, a través de navegación y entrada de datos, afecta el estado del negocio [3]. De este modo, un sitio Web es un sistema Web donde la navegación del usuario no modifica lógica de negocio, o un sistema Web donde no hay lógica del negocio. Sin embargo, esta clasificación es un poco confusa. Una buena parte de los sistemas Web existentes extraen parte de la información que presentan a los usuarios desde bases de datos, y ocasionalmente modifican esta información, dependiendo de las acciones del usuario. De las cuatro operaciones básicas para el manejo de datos: crear (insert), recuperar (select), modificar (update) y borrar (delete), es común que los sistemas Web utilicen la segunda para desplegar información. Sin embargo, son las otras tres las que modifican el estado de una base de datos (el estado de la lógica del negocio), y es la presencia de estas operaciones, según la definición de Conallen, lo que define la funcionalidad de un sistema Web: en qué proporción la interacción del usuario con el sistema permite modificar el estado de los datos del sistema.

Por otra parte, la clasificación dada por Conallen no contempla la complejidad de los sistemas Web, la cual es de vital importancia en la Ingeniería Web para la construcción de las aplicaciones y para su futuro mantenimiento. Por ejemplo, según la clasificación de Conallen, algunos motores de búsqueda (searh engines) serían catalogados como “sitios Web”, ya que la navegación e interacción de los usuarios con el sistema no afecta el estado de la lógica del negocio, pues solamente son ejecutadas instrucciones de tipo select para obtener la información presentada. Y claramente un sitio Web de este tipo es mucho más complejo que un portal donde se muestre, por ejemplo, la cartelera cinematográfica de la semana. No obstante, estos dos sitios Web tienen algo en común, y es que la información que despliegan a sus usuarios cambia periódicamente, es decir, el contenido del sitio cambia.


Podríamos entonces decir que un sistema Web tiene tres componentes fundamentales: el diseño gráfico, el contenido y la funcionalidad. Es muy importante diferenciar estos aspectos pues el perfil de la persona encargada de implementar cada componente, es distinto. De acuerdo con estos tres nuevos criterios, podríamos definir una nueva taxonomía para sistemas Web. Los sistemas Web se clasificarían dependiendo de la cantidad y tipo de código (HTML, scripts y otros lenguajes de programación) que posean, según la cantidad de información que contengan, y según la calidad y complejidad del diseño. La figura 1 muestra esta taxonomía, compuesta por un sistema con tres dimensiones: contenido, diseño y funcionalidad [4].

Fig. 1. Taxonomía de sistemas Web según su diseño, contenido y funcionalidad. En la taxonomía de la figura 1, el plano de la zona A determina los sistemas que no

contienen código ejecutable, es decir, los sistemas que no poseen funcionalidad. Estos sistemas podrían ser llamados portales o sitios Web. La zona B, por el contrario, define los sistemas que contienen mucha funcionalidad, independientemente del contenido y del diseño. Estos sistemas podrían llamarse aplicaciones Web. Pero, ¿qué pasa con un sistema Web que no cae en ninguna de las dos regiones señaladas?, ¿sería considerado un sitio o una aplicación Web? En realidad lo más importante es estimar el tiempo y esfuerzo en el desarrollo del sistema Web. El límite que hace la diferencia entre sitio y aplicación, dependerá de las métricas de estimación de cada empresa. Para nuestros efectos, diremos que una aplicación Web es aquella que requiere suficiente esfuerzo en cuanto a su funcionalidad, como para que se requiera un ingeniero de software.

A partir de la anterior taxonomía, es posible clasificar los sistemas Web de acuerdo con el tipo de código que poseen sus páginas, o al tipo de código que construye esas páginas. Esta taxonomía podría ser de utilidad para una empresa de desarrollo que necesite estimar el tiempo y el esfuerzo requerido para que sus distintos profesionales (ingenieros de software, diseñadores gráficos y arquitectos de información) desarrollen un proyecto Web.

230 RITOS2

3. Metodologías de desarrollo

En la literatura pueden encontrarse varias metodologías que sugieren diversas formas de enfrentar el desarrollo de una aplicación Web. Algunas de estas metodologías se revisan a continuación.

3.1. Iweb

Iweb (Ingeniería Web) [8] aplica un enfoque genérico de estrategias, tácticas y métodos especializados. Se deben aplicar las mismas tácticas de aseguramiento de la calidad aplicadas en todos los proyectos de ingeniería de software. Las aplicaciones basadas en Web incluyen sitios completos, funcionalidad especializada dentro de los sitios Web y aplicaciones de procesamiento de información que residen en Internet o en una intranet. Según los creadores de Iweb, algunos de los atributos que se encuentran en la mayoría de las aplicaciones Web son: intensivas en red, controladas por el contenido, evolución continua, inmediatez, seguridad, estética. Las actividades a realizar en proyectos de este tipo son: formulación del proyecto, planificación, análisis, ingeniería, generación de páginas y pruebas, y evaluación del cliente. Durante la formulación del proyecto se identifican las metas y objetivos de la aplicación Web y se establece el ámbito del primer incremento, se establece por qué es necesaria la aplicación, y quién la va a utilizar. Durante la planificación se estima el costo total del proyecto, se evalúan los riesgos asociados al esfuerzo de desarrollo, y se define un plan de trabajo. En el análisis se establecen los requisitos técnicos y los requisitos de diseño gráfico, se realiza un análisis de contenido, un análisis de la interacción, un análisis funcional, y un análisis de la configuración. Durante la ingeniería se diseña el contenido, y se realiza la producción. Paralelamente se diseña la arquitectura, la navegación y la interfaz. Durante la etapa de generación de páginas y pruebas, se revisa la navegación, se depuran los applets y otros scripts, y se prueba la aplicación en varios browsers. Finalmente, durante la evaluación del cliente se solicitan cambios, se integran de forma incremental, y se validan.

3.2. WSDM

WSDM (Web Site Design Modeling) [9] centra la generación del diseño en el usuario más que en los datos. Para esto trata de definir las “clases de usuarios” que visitarán el sitio. Según estas futuras visitas, y la forma en que estos usuarios recorrerán el sitio, se establecen los parámetros de diseño. El método está compuesto por cuatro fases: modelado de los usuarios, diseño conceptual, diseño de implementación, e implementación. En la primera fase se define el tipo de información que buscarán los usuarios cuando ingresen al sitio. En el diseño conceptual se modela la información requerida y se detallan las clases de usuarios. También se crea el diseño de navegación. En el diseño de la implementación se especifican los requisitos y restricciones del diseño gráfico del sitio, según lo definido en el diseño conceptual. Finalmente, en la implementación se selecciona el ambiente de desarrollo y se


implementa el sitio. WSDM se centra principalmente en el desarrollo de sitios Web de información (kiosk Web sites), más que en sitios interactivos o aplicaciones.

3.3. WebML

WebML (Web Modeling Language) [10] es un lenguaje conceptual para apoyar las actividades del diseño de sitios Web. Provee gráficos, formalismos, especificaciones, y diseño de procesos apoyados por herramientas gráficas. Define cinco tipos de modelos: estructura, derivación, composición, navegación y presentación. En el modelo de estructura se definen las entidades o contenedores de datos y sus relaciones. En el modelo de derivación se definen diferentes vistas y agrupaciones de los mismos datos. En el modelo de composición se especifican las páginas que componen el hipertexto, así como el contenido de éstas. El modelo de navegación especifica los vínculos (links) entre páginas y entre unidades de una misma página. Finalmente en el modelo de presentación se describe la apariencia gráfica de las páginas. WebML se enfoca en el diseño de la interfaz. Para esto provee una serie de estereotipos que pueden ser implementados usando XML.

3.4. WCPM

WCPM (WebComposition Process Model) [11] permite modelar componentes con distinto grado de funcionalidad, que van desde un simple link, hasta un script con cierta funcionalidad. Usando estos componentes es posible desarrollar una aplicación Web. Las aplicaciones así creadas son más fáciles de modificar y mantener. Este método, basado en la orientación a objetos, se enfoca en reutilizar el código y en mantener la integridad de las aplicaciones Web desarrolladas. Introduce conceptos de un modelo de procesos abierto, que permite desarrollar componentes reutilizables. Estos componentes se modelan usando el WebComposition Markup Language (WCML), que es una extensión de XML.

3.5. Web Engineering

Web Engineering [12] está compuesto por un conjunto de actividades necesarias para llevar a cabo el desarrollo de un sitio Web. Las actividades sugeridas por sus creadores son: análisis de contexto, modelo de productos, modelo de procesos, plan del proyecto, desarrollo, y mantenimiento. Durante el análisis de contexto se estudia el dominio del problema, identificando las posibles soluciones. Se analiza también el presupuesto y el tiempo de desarrollo. Usando un modelo de productos, las páginas Web pueden ser creadas por demanda, haciendo las consultas respectivas a la base de datos. El modelo de procesos considera las fases de desarrollo y la integración. Este modelo describe el tipo de desarrollo a seguir, según el proyecto. El plan del proyecto considera aspectos de gestión de proyectos, documentación, aseguramiento y control de calidad.

232 RITOS2

3.6. Otros métodos

RMM (Relationship Management Methodology) [13] se enfoca en el diseño y construcción de aplicaciones multimediales que tienen estructuras estables, pero con información altamente cambiante.

En JESSICA [14] se propone una metodología que cubre el ciclo de vida completo de una aplicación Web, basada en un modelo de abstracción orientado a objetos. Propone un lenguaje para modelar basado en XML, y un mecanismo para el mapeo automático del diseño a los recursos Web.

OOHDM (Object Oriented Hypermedia Design Method) [15] es un método basado en modelos para el desarrollo de sitios Web, sistemas de información, presentaciones multimediales, quiscos de información, etc. Se trata por separado el diseño de componentes, el modelo de navegación y el diseño de la interfaz.

Web Design Guidelines [16] es una guía planteada por IBM para el diseño de procesos centrados en el usuario. Contiene cuatro fases: planificación, diseño, producción y mantenimiento.

4. Arquitectura J2EE

En los últimos años, el proceso de desarrollo de software empresarial ha sufrido varios cambios, y en el centro de estos cambios se encuentra, sin lugar a dudas, la plataforma Java 2 Edición Empresarial o J2EE (Java 2 Enterprise Edition). J2EE provee una plataforma unificada para el desarrollo de aplicaciones distribuidas basadas en servidores.

La arquitectura J2EE es multicapa, y está formada por cuatro capas: capa cliente, capa Web, capa de negocios, y capa de sistemas empresariales de información o sistemas legados [5]. Las relaciones entre los componentes de las distintas capas se muestra en la figura 2.

Fig. 2. Arquitectura J2EE.

La capa del cliente interactúa con el usuario y le muestra a éste la información que

le envía el sistema. Algunos ejemplos de clientes son: clientes HTML, applets Java y

Applet

Contenedor de Applets

Contenedor deaplicación cliente

Aplicacióncliente

Contenedor Web

JSP Servlet

Contenedor EJB

EJB

Base dedatos

Applet

Contenedor de Applets

Contenedor deaplicación cliente

Aplicacióncliente

Contenedor Web

JSP Servlet

Contenedor EJB

EJB

Base dedatos


aplicaciones Java. La capa Web genera la lógica de la presentación (clientes HTML, applets Java y otros clientes Web) y acepta las respuestas que el usuario envía. Esta capa es implementada a través de servlets y JSP (Java Server Pages). La capa de negocio administra la lógica del negocio de la aplicación. Los componentes de negocio típicamente se implementan como componentes EJB (Enterprise Java Beans). Finalmente, la capa de sistemas empresariales de información (EIS) incluye sistemas de bases de datos, sistemas transaccionales, y sistemas de planificación. Esta capa es el punto de enlace de la plataforma J2EE con sistemas empresariales no-J2EE, o sistemas legados.

Una muy buena y antigua práctica de programación sugiere separar la interfaz de la lógica de la aplicación. Este concepto está inmerso en la plataforma J2EE. Una aplicación Web es vista como una aplicación de software normal, pero con una interfaz Web. Por tanto, para modelar y diseñar una aplicación Web, se puede utilizar cualquier metodología de desarrollo de software (por ejemplo RUP o XP). La única diferencia radica en la etapa en que se modela la interfaz gráfica de usuario [6].

5. Discusión

Desde el punto de vista del desarrollo de proyectos, existen claras diferencias entre una aplicación Web y una aplicación tradicional. Donald Reifer [17] establece estas diferencias a través de las características mostradas en la tabla 1.

Las diferencias entre estos tipos de proyectos son de vital importancia en la selección de los perfiles del equipo de trabajo, y en la estimación del tiempo de desarrollo y del costo. Es muy difícil, o casi imposible, utilizar las mismas métricas en ambos tipos de proyectos.

Un enfoque que parece razonable, desde el punto de vista de las nuevas tendencias de desarrollo como la plataforma J2EE, parece ser la separación de un proyecto Web en dos sub-proyectos: uno referido a la funcionalidad de la aplicación, y otro referido al diseño gráfico y al contenido. El primer sub-proyecto se puede atacar utilizando la experiencia y metodologías del desarrollo tradicional de aplicaciones. El segundo sub-proyecto, enfocado en la interfaz de la aplicación (diseño gráfico y contenido) debe ser realizado utilizando paradigmas y metodologías no tradicionales en la Ingeniería de Software. El tipo de personal, así como la estimación de costos y tiempos varía para cada sub-proyecto.

La taxonomía presentada en la figura 1, podría entonces dividirse en dos partes: un plano bi-dimensional que muestre el contenido y diseño necesarios para la aplicación Web, y un eje que refleje la cantidad y complejidad de la funcionalidad requerida.

Los proyectos Web sin funcionalidad, o con poca funcionalidad, podrían desarrollarse utilizando alguna de las metodologías revisadas, pero para aplicaciones con cierto grado de funcionalidad quizás requieran una combinación de alguna de las metodologías revisadas, junto con las metodologías tradicionales para el desarrollo de aplicaciones.

234 RITOS2

Table 1. Proyectos de desarrollo Web versus proyectos tradicionales.

Característica Desarrollo tradicional Desarrollo Web

Objetivo primario Productos de calidad al mínimo costo Productos de calidad al mercado lo más rápido posible

Tamaño típico del proyecto

Mediano a grande (equipos de cientos de miembros)

Pequeños (equipos de 3 a 5 miembros)

Tiempo de desarrollo 10 – 18 meses 3 – 6 meses

Enfoque de

desarrollo

Clásico, basado en requisitos, entregas incrementales, casos de uso, documentación

Desarrollo rápido de aplicaciones (RAD), agrupar bloques de construcción, prototipos, RUP

Tecnologías de

ingeniería usadas

Orientación a objetos, lenguajes modernos, herramientas CASE, etc.

Métodos basados en componentes, lenguajes de cuarta y quinta generación, visualización, etc.

Procesos Basados en CMM Ad hoc

Desarrollo de

productos

Sistemas basados en código, reuso, muchas interfaces externas, algunas aplicaciones complejas

Sistemas basados en objetos, componentes reutilizables, pocas interfaces externas, aplicaciones relativamente simples

Personal involucrado Ingenieros de software profesionales con 5 o más años de experiencia en al menos dos dominios de aplicación

Diseñadores gráficos, ingenieros con poca experiencia (2 o más años), recién graduados

Tecnologías de

estimación

Uso de datos históricos, modelos basados en puntos por función, WBS para proyectos pequeños

Uso de la actual experiencia, diseño ajustable basado en recursos disponibles, WBS para proyectos pequeños

Referencias

[1] Murugesan, S., Deshpande, Y., Hansen S., and Ginige, A. “Web Engineering: A New Discipline for Development of Web-based Systems”. Proceedings of the International Conference on Software Engineering, ICSE'99, May, 1999, Los Angeles, U.S.A.

[2] Zelnick, N. “Nifty Technology and Nonconformance: The Web in Crisis”. IEEE Computer, October, 1998, pp. 115-116 and 119.

[3] Conallen, J. “Modeling Web Application Architectures with UML”. Communications of the ACM, 42(10), October, 1999, pp. 63-70.

[4] Bravo, C., y Guerrero, L. A. “Métricas de Funcionalidad: Una Taxonomía para Sistemas Web”. Actas del Primer Workshop de Ingeniería de Software, Punta Arenas, Chile, Noviembre, 2001.

[5] Alur, D., Crupi, J., and Malks, D. Core J2EE Patterns. Sun Microsystems Press, Prentice Hall, Palo Alto, California, U.S.A., 2001.

[6] Larman, G. Applying UML and Patterns. An introduction to Object-Oriented Analysis and Design and the Unified Process. Prentice Hall, Second Edition, 2002.

[7] Ginige, A., and Murugesan, S. “Web Engineering: An Introduction”. IEEE Multimedia, 8(1), pp. 14-18, 2001.

[8] Pressman, R. E. Ingeniería de Software, McGraw Hill, Quinta Edición en Español, 2002.


[9] De Troyer, O. “WSDM: A User Centered Design Meted for Web Sites”. In 7th World Wide Web Conference, Brisbane, Australia, 1998.

[10] WebML User Guide. http://www.WebML.org. [11] Gaedke, G. “Development and Evolution of Web Application using the Web Composition

Process Model”. International Workshop on Web Engineering at the 9th World Wide Web Conference, Ámsterdam, The Netherlands, May, 2000.

[12] Ginige, A., and Murugesan, S. “Web Engineering: An Introduction”. IEEE Multimedia, 8(1), pp. 14-18, 2001.

[13] Isakowitz, T. “RMM: A Methodology for Structured Hypermedia Design”. Communications of the ACM, 38(8), pp. 26-30, 1995.

[14] Barta, R., and Schanz, M. “JESSICA: An Object Oriented Hypermedia Publishing Processor”. In 7th World Wide Web Conference, Brisbane, Australia, 1998.

[15] Schwabe, D., Rossi, G., and Barbosa, J. “Systematic Hypermedia Design with OOHDM” ACM International Conference on Hypertext’ 96. Washington, USA, 1996.

[16] IBM Web Design Guidelines. http://www-3.ibm.com/ibm/easy/eou_ext.nfs/publish/558. [17] Reifer, D. “Web Development: Estimating Quick-to-Market Software”. IEEE Software,

November/December 2000, pp. 57-64.

236 RITOS2

Las Ontologías Como un Medio de Hacer Portable una Interfaz en Lenguaje Natural a Bases de Datos

J. Antonio Zárate M.1, Rodolfo A. Pazos R.1, Alexander Gelbukh2

1 Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET)

Interior Internado Palmira S/No, 62490 Cuernavaca, Mor., México

2 Centro de Investigación en Computación (México)

Instituto Politécnico Nacional

{jazarate, pazos}@sd-cenidet.com.mx, [email protected]

Resumen. Se presentan los primeros resultados de una interfaz en lenguaje natural hacia bases de datos, diseñada para disminuir el esfuerzo de implantar la herramienta y portarla a otras bases de datos en diferentes contextos. Este trabajo es la continuación de una serie de interfaces para facilitar el acceso a bases de datos a través de Internet. Se propone el uso de ontologías como un medio para que la interfaz sea portable a diferentes bases de datos, y que contribuya a mejorar la tarea de configuración de este tipo de interfaces, uno de los principales factores que han limitado su popularización. Se incorporan en este trabajo tecnologías que proponen a la Internet como un medio en donde se tenga conocimiento portable, estándar y reutilizable, junto con aportaciones del procesamiento de lenguaje natural, el cual ha tomado nuevo impulso en los últimos años, y se propone como la mejor solución al problema de la comunicación hombre-máquina. En este artículo se describe la arquitectura conceptual de una interfaz en lenguaje natural para bases de datos en Internet, así como los avances realizados.

1 Introducción

El informe Asilomar [3] plantea que el crecimiento de la Internet está fomentando una sociedad que demanda cada vez más servicios de almacenamiento, organización, acceso y análisis de la información, dando un giro completo a la investigación en todas las áreas de la ciencia, en especial las relacionadas con las bases de datos.

Este crecimiento acelerado del número de usuarios de la Internet, ha creado la necesidad de que usuarios sin amplios conocimientos de computación, puedan acceder a los datos disponibles en la Internet. Lo anterior ha llevado al desarrollo de múltiples tipos de interfaces como QBE (consultas mediante ejemplos), formularios, lenguajes acotados, etc. con el inconveniente para el usuario de traducir lo que normalmente expresaría a otra persona, en una forma estructurada para la herramienta de consulta.

Una solución al problema de que un usuario cualquiera pueda expresar de la manera más sencilla una consulta a una base de datos, son las interfaces en lenguaje natural hacia bases de datos (ILNBDs). Este tema ha despertado interés desde la década de los años 70s, y ha motivado una larga serie de desarrollos; Sin embargo,

éstos no han tenido mucha aplicación, debido a que son vistos como sistemas “exóticos”, y a lo complicado y tedioso de su configuración, ya sea para que la interfaz trabaje en un contexto de base de datos determinado, o para cambiar la interfaz de una base de datos en la cual ya se está trabajando a otra, cuya semántica puede ser diferente de la primera.

2 Antecedentes del proyecto

El primer trabajo del grupo de Sistemas Distribuidos del Cenidet fue el Sistema Manejador de Bases de Datos Distribuidas (SiMBaDD) a principios de la década pasada. En los últimos años el grupo se ha enfocado a problemas de acceso a datos en la red mundial (Internet), y con un interés particular en interfaces a sistemas de bases de datos que sean lo bastante amigables para la gran cantidad de usuarios nuevos y generalmente inexpertos en el manejo de datos que usan Internet. Algunos de los trabajos que se han desarrollado se describen a continuación:

• Herramienta para Consultas Basadas en Ejemplos (QBE) para una Base de Datos

en Internet. Su principal objetivo fue desarrollar una herramienta que permitiese el acceso a bases de datos de usuarios inexpertos y casuales a través de Internet, en una plataforma neutral (esto se logró por medio de su implementación en lenguaje Java) [21].

• Herramienta para Consultas Basadas en Ejemplos (QBE) [28] para Multibases de Datos en Internet. Este trabajo mejoró algunas prestaciones de la interfaz, al permitir consultas con tablas en diferentes bases de datos, procesamiento de subconsultas, ayudas, y además se definió la arquitectura actual de la herramienta [13].

• Herramienta para Consultas EzQ para Multibases de Datos en Internet. Siendo la última etapa de desarrollo de esta herramienta, agregó la facilidad de que un usuario inexperto pueda formular consultas que involucren reuniones sin que el usuario tenga que comprender el concepto de reunión [4].

El grupo de trabajo consideró agotado el interés sobre el desarrollo de la interfaz

QBE y propuso un cambio en la dirección de la investigación hacia las interfaces en lenguaje natural, sin dejar por eso de cubrir nuestro principal objetivo, estudiar las interfaces que disminuyan el esfuerzo para que un usuario inexperto pueda acceder a datos almacenados. La arquitectura actual de la herramienta QBE se muestra en la Figura 1.

Las interfaces en lenguaje natural a bases de datos, como se ha demostrado en un estudio [25], no son la panacea para solucionar los problemas derivados de la interacción hombre-máquina, pero han demostrado una gran ventaja en casos donde la consulta involucra varias tablas o donde la solución no se parece en nada a los ejemplos que anteriormente había conocido el usuario. Las interfaces en lenguaje natural a bases de datos demostraron ser más sencillas que las interfaces gráficas o los ambientes de programación [25].

238 RITOS2

Fig. 1. Arquitectura de la herramienta para consultas basadas en ejemplos

Un experimento efectuado con Intellect [1] concluyó que “el lenguaje natural es un método efectivo para la interacción de usuarios casuales con un buen conocimiento de la base de datos en un ambiente restringido”. Los criterios que permiten evaluar los requisitos que deben cumplir este tipo de interfaces, se encuentran definidos en un trabajo desarrollado en la Universidad de Edimburgo [1].

3 Problemática encontrada

Aunque existen varios prototipos de ILNBDs, su uso ha sido bastante reducido, debido a las limitantes de la cobertura lingüística y a su poca difusión. Sin embargo, algunos de los resultados de las investigaciones ya han sido incorporados en manejadores de bases de datos comerciales.

A pesar de que existen ILNBDs que ofrecen portabilidad hacia múltiples tipos de sistemas (sistemas expertos, manejadores de bases de datos etc.), múltiples sistemas operativos y múltiples sistemas manejadores de bases de datos, y que además fueron diseñadas de una manera modular, lo cual les permite ser versátiles [24], la portabilidad de un dominio de conocimiento a otro, es decir, la capacidad de que la misma interfaz pueda trabajar con diferentes bases de datos, no ha sido totalmente alcanzada. Esto se debe a que aquellas ILNBDs que aseguran que son fácilmente trasladables de un dominio a otro, se basan en el hecho de que se puede acceder a su base de conocimientos y modificarla para el nuevo dominio. La solución anterior no considera que para poder modificar la base de conocimiento, ésta debe ser construida en forma modular, de tal manera que se le hagan únicamente los cambios necesarios. Además, si se dispone de alguna manera de “conocimiento” en otra base de conocimiento, éste no se puede reutilizar para construir la base de conocimiento para el nuevo dominio.

Recibe URL y puerto de atención Opción: 1. Metadatos

2. Consulta

BBDD

•Obtiene solicitud de metadatos•Crea hilo de atención •Regresa a estado de espera

Servidor de Web(Intermediario)Cliente (Apliquete)

Hilo de Atención

JDBC

JDBC

JDBC

BBDD

BBDD

•Solicita metadatos •Recibe metadatos •Genera consulta •Recibe resultados

Si N>1


Lo anterior es un punto importante, dado que necesariamente “alguien” (generalmente el administrador de la base de datos o el diseñador de la misma) debe configurar la interfaz en lenguaje natural, cambiando las reglas gramaticales de acuerdo a la naturaleza de la base de datos y/o agregando palabras al diccionario, de acuerdo al nuevo contexto.

Fig. 2. Base de datos de una escuela ficticia

En base al análisis del estado del arte, se concluyó que actualmente no se cuenta con una estrategia que permita, de la misma manera en que se construye un sistema de software, construir de la nada o a partir de un antecedente, una base de conocimiento de una interfaz en lenguaje natural, adecuada al contexto de la base de datos en la que se quiere usar la herramienta. Es necesario que exista una metodología de diseño que permita hacer esta configuración de una manera semejante a como se construye software; es decir, que se haga uso de componentes genéricos y que aquellos detalles particulares de la aplicación sean los únicos que necesiten ser construidos. Además, una de las tendencias más importantes es la de compartir información, con el fin de disminuir los costos que implica construir sistemas basados en conocimiento.

Las situaciones descritas anteriormente se pueden ver más claras a través del siguiente ejemplo: se tiene una base de datos de una escuela (Figura 2), y se quiere configurar una ILNBD para acceder a los datos. La configuración puede implicar la captura de todo el diccionario de palabras a utilizar con la herramienta y las reglas gramaticales, tanto del lenguaje en general como aquellos elementos particulares del contexto [2], y además agregar las relaciones que tienen entre sí los objetos de la base de datos (tablas y columnas). Cabe destacar que para realizar la tarea anterior, es

240 RITOS2

necesario conocer el formalismo en el cual se deben codificar el diccionario de palabras y las reglas gramaticales para que puedan ser usados por la herramienta. Algunos ejemplos de formalismos usados son los siguientes: redes de transición aumentadas (ATN) para GILeNa [2], reglas en Prolog para Masque [1] y Natlin [23], marcos de instanciación de casos para la herramienta del ITESM Morelos [5, 10], o el llenado de ciertas tablas en EnglishQuery [14].

Ninguna de las técnicas antes mencionadas fue diseñada para compartir conocimiento; es decir, que si ya se codificó cierto conocimiento, se pueda reutilizar para otra aplicación. En dichas técnicas no es tan sencillo construir una base de conocimiento a partir de otro, ya que muchas veces el conocimiento está muy “alambrado” en la aplicación para la cual se usa. Esto se debe a que la forma en que se codificó el conocimiento depende mucho de la forma en que fueron implementados los analizadores sintáctico y semántico de la ILNBD.

Continuando con el ejemplo anterior, al configurar la ILNBD para la base de datos de una escuela con cualquiera de los prototipos y herramientas comerciales, no se podría disponer de cierto conocimiento útil para construir la base de conocimiento, como las bibliotecas de ontologías de DAML [6]. Debido a esto se tendrían que capturar muchas relaciones de sentido “común”, como que un profesor tiene como jefe al jefe departamento al cual pertenece, que su lugar de procedencia, según la semántica de la base de datos, es muchas veces donde nació, etc. La forma en que se representa la información depende mucho del funcionamiento interno de la ILNBD, por lo cual, es difícil tomar información de otras fuentes que cumplieran un estándar para compartir información, y que a su vez se pudiera reutilizar el conocimiento almacenado para otras aplicaciones [17, 20, 34, 44].

Fig. 3. Base de datos del personal de una empresa ficticia

Ahora supóngase que la misma interfaz que se configuró para la base de datos escolar, se quiere utilizar para acceder a una base de datos de personal (Figura 3). El trabajo de configuración involucrado podría ser muy grande, ya que, dependiendo de la forma en que se codifique el conocimiento, sería necesario introducir de nuevo


Módulo PLN

Módulo de Sesión

JDBC

JDBC

JDBCBBDD

BBDD

BBDD

Onto-logías •Solicita ontologías

•Recibe ontologías •Genera consulta LN •Recibe resultados

•Obtiene solicitud de ontología •Crea hilo de servicio •Regresa a estado de espera

Recibe URL y puerto servicio y regresa ontologías

Si N>1

Servidor de Web(Intermediario)

Cliente (Apliquete+ Interfaz de Voz)

•Recibe consulta en LN •Genera consulta en SQL

Módulo de Atención

Editor de Ontologías

muchos conceptos y relaciones, que posiblemente son muy semejantes en el nuevo contexto a las que se habían codificado en el anterior.

Detallando la situación anterior, si se pudiese reutilizar conocimiento, las reglas y buena parte del vocabulario necesarios para contestar la pregunta ¿qué maestros trabajan en el departamento de ciencias computacionales?, en el contexto de una base de datos de control escolar (figura 2), podrían servir para la pregunta ¿quiénes trabajan en el departamento de contaduría? dentro del contexto de la base de datos de personal (Figura 3). Como se puede apreciar en dichas figuras, pueden existir similitudes entre las bases de datos que pueden ser utilizadas para configurar las ILNBDs las cuales no son actualmente aprovechadas.

La técnica usada para construir la base de conocimiento de la ILNBD, no solamente debe considerar las características de ser estándar y orientada al compartimiento de recursos, sino también debe ser lo suficientemente poderosa para poder expresar relaciones, axiomas, excepciones y generalidades entre conceptos del lenguaje, para realizar la difícil tarea de “entender” la consulta del usuario.

4 Sistema de procesamiento de consultas en lenguaje natural

Este sistema [27] servirá para el idioma español, y tendrá como elementos adicionales a otros semejantes [2, 5, 7, 10, 23], una mayor cobertura del lenguaje, una mayor portabilidad tanto de manejador como de ambiente operativo, y un acceso transparente a través de la red.

Fig. 4. Arquitectura propuesta del sistema

Se plantea modificar de manera substancial la arquitectura anterior, que conservaría su estructura de tres niveles, cliente-intermediario-servidor, pero cambiando la funcionalidad de cada uno de estos niveles. Se simplificarán las funciones del cliente, lo cual solucionará en parte los problemas que se tienen con el

242 RITOS2

Analizador Sintáctico

Analizador Semántico

Generador de Código

Módulo de Sesión del Intermediario

Estructura sintáctica

Representación interna

Error

Analizador Pragmático y del Discurso

Consulta SQL

Ontología particular

Lexicón

actual QBE, a cambio de que el intermediario tuviese más actividades. La arquitectura propuesta del sistema de procesamiento de consultas en lenguaje natural a través de la Web, se muestra en la Figura 4.

Al iniciar una sesión con la interfaz, el usuario emitirá su consulta por medio de la interfaz de voz, cuyo resultado será enviado por el cliente al módulo de atención del intermediario, el cual pasará la consulta al módulo de procesamiento de lenguaje natural (PLN). La arquitectura de éste es muy semejante a la que aparece en la literatura, excepto que el lexicón estaría compuesto por dos partes: la primera sería una ontología lingüística general, en base a las directivas del proyecto Wordnet [15], y una ontología del dominio que se acoplaría a la primera y que describirá la semántica de la base de datos (Figura 5). La ontología del dominio se diseña a través de un editor de ontologías (Figura 4), y la ontología general se obtendrá a través del análisis de un corpus de textos, con técnicas de minería de datos.

Fig. 5. Modulo de procesamiento de lenguaje natural

La consulta en lenguaje natural recibida por el módulo PLN, es analizada sintáctica y semánticamente para transformarla en una representación interna, la cual se traduce a una consulta en el lenguaje de consultas estructurado (SQL). Esta consulta es regresada al módulo de sesión para que la reenvíe a un sistema manejador de bases de datos (SMBD) para su evaluación. El mismo módulo de sesión se encarga de hacer llegar al usuario final el resultado de la consulta que regrese el SMBD.

Aunque existen otras propuestas para separar el conocimiento lingüístico y el del dominio [11, 22], en ninguna de ellas se contó con una representación del conocimiento que fuese reutilizable, compartible, ni formalizado usando algún


Filtro de Palabras

Oración

Archivo de Texto

Oración Filtrada

Palabrasa Filtrar

Análisis Léxico

Oración Etiquetada

Dicionario de Palabras

estándar en su implementación. En cambio, este proyecto propone crear el lexicón en base a los lineamientos del proyecto Wordnet [15], el cual se está volviendo un estándar de facto, e implementar la ontología del dominio en base al lenguaje de marcado de agentes de la Agencia de Defensa Norteamericana (DAML por sus siglas en inglés) [6], el cual está teniendo un gran apoyo en el desarrollo de herramientas, y está siendo usado en diferentes tipos de aplicaciones.

Las ventajas que encontramos en DAML es que se pueden implementar en él, tanto la ontología como los mecanismos de inferencia que exploten la información de la ontología. Un elemento innovador es el hecho de que el analizador semántico será implementado tratando de aprovechar al máximo las posibilidades que da el lenguaje DAML.

5 Trabajo desarrollado

Actualmente se han capturado para el lexicón, dieciocho categorías de sustantivos y siete categorías de verbos, codificados de acuerdo a los principios de Wordnet [15]; además, se han terminado los módulos del análisis léxico y morfológico [20], y se está terminando el analizador sintáctico, que usará un subconjunto de la gramática desarrollada en [8]. El funcionamiento general del analizador morfológico se describe a continuación (Figura 6).

El usuario introduce la oración dictándola a la interfaz del Dragón Naturally Speaking (seleccionamos esta herramienta porque su vocabulario es bastante completo, es de fácil entrenamiento y puede generar archivos de texto de fácil acceso). Esta oración dictada por el usuario, puede contener palabras que no tienen información útil para el analizador morfológico, por lo cual son eliminadas de la consulta. La lista de palabras “irrelevantes” fue obtenida por medio de una encuesta y puede se modificada según sea necesario. Algunos ejemplos de este tipo de palabras son las siguientes: quiero, dame, lístame, muéstrame, etc.

Fig. 6. Funcionamiento general del analizador morfológico

Después del filtrado anterior, la oración depurada pasa al analizador morfológico, que clasifica las palabras y registra su información sintáctica. Esto se logra acompañando cada palabra con una etiqueta, en la cual se codifican todas las

244 RITOS2

categorías sintácticas a las cuales pertenece. A este proceso se le llama etiquetado de partes del habla.

Fig. 7. Proceso interno del analizador morfológico

El algoritmo para realizar dicho etiquetado (Figura 7) es por etapas: En la primera se busca etiquetar ciertas palabras cortas (artículos, conjunciones, uniones, etcétera), que presentan menor probabilidad de presentar ambigüedad sintáctica. En la segunda etapa, a partir de las palabras ya etiquetadas, se procede a etiquetar la que le sigue en base a una gramática de Markov [12], que dice que conociendo la categoría sintáctica de una palabra es posible predecir con cierta confianza la categoría sintáctica de la palabra que le sigue (estas dos son conocidas como bigrama, existen también trigramas, cuatrigramas o su generalización N-gramas). Un ejemplo de los bigramas usados se muestra en la Tabla 1.

Tabla 1. Ejemplo de la tabla de bigramas

Ocurrencia Palabra Etiqueta Fija Etiqueta Siguiente 3 El A&MS N&13MS 2 El A&MS R&13MS 1 El A&MS V&13MS

Es bastante factible que existan ciertas ambigüedades léxicas, ya que al buscar la

categoría de una palabra, se puede elegir entre varias opciones, para lo cual, estamos ampliando el algoritmo para que involucre trigramas o grupos de palabras de mayor grado, lo cual nos ayude en el trabajo de desambiguación sintáctica. Un supuesto que hemos hecho es el que la semántica de la base de datos, definida en la ontología, limitará sustancialmente la aparición de ambigüedades en la consulta.

Después de la segunda etapa, se repite el proceso, buscando etiquetar las palabras que falten y resolviendo las posibles ambigüedades que aparezcan. El algoritmo termina cuando se tiene la oración completamente etiquetada, y pueda ser revisada por el analizador sintáctico, para posteriormente reestructurar la oración y generar un árbol sintáctico.

Para el diccionario de palabras se crearon las siguientes tablas, en parte manual y en parte automáticamente: sustantivos, verbos conjugados en sus diferentes tiempos y personas, palabras cortas (artículos, pronombres, conjunciones y uniones, que son palabras que tienen una longitud menor o igual a cinco caracteres), adjetivos y

Identifica Palabras Cortas

Oración Filtrada

Palabras Cortas

Oración Etiquetada

Bigramas

Bigrama Diccionario de Palabras

Oración Etiquetada


Editor

Diseñador

<Class ID="Female"> <subClassOf resource="#Animal"/> <disjointFrom resource="#Male"/>

</Class> <restrictedBy> <Restriction> <onProperty resource="#parent"/> <toClass resource="#Person"/> </Restriction> </restrictedBy>

Ontología

Diccionario de Datos

adverbios. Con esto se redujo el tiempo de búsqueda de cada palabra, ya que si se hiciera una lemantización de cada palabra en tiempo de ejecución, el tiempo de procesamiento y la búsqueda de las excepciones sería mucho mayor que manteniendo una buena parte de las palabras y sus variantes en tablas de base de datos, las cuales pueden mantenerse totalmente en memoria principal, considerando los bajos costos de la misma en la actualidad.

Fig. 8. Esquema general del editor de ontologías

Además se ha desarrollado un prototipo del editor de ontologías [9] que le permite a un diseñador (generalmente el que diseñó la base de datos o el administrador de la misma) construir la ontología del dominio de la base de datos. El editor permite que, a partir de la información del diccionario de datos, se vaya construyendo una ontología.

Se obtienen los metadatos directamente del manejador de la base de datos y el diseñador debe agregar la información necesaria para construir la ontología. Parte de la información obtenida del diccionario de datos y que sirve como base para la ontología es la siguiente: nombre del campo, nombre de la tabla, llaves primarias, llaves foráneas, tipo de datos, descripción de la columna, tamaño de la columna, y si ésta permite o no tomar un valor nulo.

El editor permite agregar y manipular conceptos y sus atributos, las relaciones entre ellos, axiomas que definen las restricciones y características de los conceptos, y además permite agregar ejemplares a la ontología por medio de consultas a la base de datos. Después de que el diseñador le ha agregado toda la información necesaria para poder crear la ontología, el editor permite automáticamente formalizar el diseño de la ontología en el lenguaje DAML+OIL [6]. Un ejemplo de la interfaz del editor se muestra en la Figura 9.

El editor muestra información estadística de la ontología (número de conceptos, número de relaciones, número de ejemplares, número de axiomas, fecha de creación, etc.) y permite agregarle a la ontología documentación tal como descripción de la ontología y datos de los diseñadores. Adicionalmente a las facilidades descritas, el editor permite agregar conceptos definidos en otras ontologías y definir dominios genéricos que pueden ser reutilizados en otras ontologías. Además hace algunas sugerencias de diseño, por ejemplo, si existen columnas de las tablas que tienen

246 RITOS2

características muy parecidas (igual tipo, longitud, o restricciones), hará la recomendación de que pueden ser columnas relacionadas de alguna manera o que se las agrupe en un mismo dominio. Estas últimas características distinguen a este editor de otras herramientas similares como OntoWeb [18] y Protégé-2000 [19].

Fig. 9. Interfaz del editor de ontologías

6 Comentarios finales

De un estudio sobre la utilidad que un conjunto de administradores de sistemas de información estimaba sobre diferentes aplicaciones de interfaces de lenguaje natural, se concluyó que las enfocadas a obtener información de bases de datos atraían la mayor preferencia entre un grupo de usuarios [25], después de las de recuperación y preparación de texto, quedando muy por atrás otras como las interfaces de traducción.

Existen dos puntos destacables de este trabajo: el primero es el poco uso de ontologías y de herramientas para su explotación para el lenguaje español [16], y el segundo es la portabilidad de dominio de las ILNBDs. El primero es muy importante, porque las ontologías están siendo el soporte para una amplia gama de temas de investigación (administración de conocimiento, PLN, buscadores de páginas Web, Web semántica). De igual manera, la falta de portabilidad, aunada a otros problemas del PLN, han ocasionado que las ILNBDs no hayan tenido una aplicación y difusión más amplia.

El trabajo en interfaces de lenguaje natural es necesario porque cada vez hay más personas que necesitan acceder a recursos informáticos y no tienen experiencia en ello ni tiempo muchas veces de adquirirla; además, siendo el español, por número de


hablantes, la tercera lengua del mundo, es muy importante desarrollar herramientas adecuadas para este gran mercado.

Referencias

1. Androutsopoulos, I., Ritchie, G., Thanisch, P.: Natural Language Interfaces to Databases, an Introduction. Department of Artificial Intelligence, University of Edinburgh (1992). http://citeseer.nj.nec.com/androutsopoulos95natural.html

2. Atkinson, J.: GILENA (Generador de Interfaces en Lenguaje Natural). Tesis de maestría, Universidad de Concepción, Chile (1991). http://www.dai.ed.ac.uk/homes/atkinson/ private/gilena

3. Bernstein, P., Brodie, M., Ceri, S., DeWitt, D., García-Molina, H., Gray, J., Held, J., Ellerstein, J., Jagadish, H.V., Lesk, M., Maier, J., Naughton, J., Pirahesh, H., Stonebraker, M., Ullman, J.: The Asilomar Report on Database Research (1998)

4. Carreón, G.: Herramienta para Consultas EzQ para Multibases de Datos en Internet. Tesis de maestría. Departamento de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, México (2003)

5. Chay, E.: Una Interfaz en Lenguaje Natural en Español para Consultas a Bases de Datos. Tesis de maestría. Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Cuernavaca, Cuernavaca, México (1990)

6. DAML, Darpa Agent Markup Language, http://www.daml.org/ 7. Domínguez, A.P.: Implementación de un Analizador Gramatical en Lenguaje Español.

Tesis de maestría. Instituto Tecnológico de Cd. Madero, Cd. Madero, México (2001) 8. Galicia, S.N.: Análisis Sintáctico Conducido por un Diccionario de Patrones de Manejo

Sintáctico para Lenguaje Español. Tesis doctoral. Centro de Investigación en Computación del I.P.N. (2001)

9. García, M.: Herramienta para la Generación de Ontologías a Partir de un Diccionario de Datos. Tesis de maestría en desarrollo. Departamento de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, México

10. Huerta, V.O.: Un Método para el Reconocimiento a Bases de Datos en Interrogaciones en Lenguaje Natural. Tesis de maestría. Instituto Tecnológico y de Estudios Superiores de Monterrey, Campus Cuernavaca, Cuernavaca, México (1989)

11. InBase, Russian Research Institute of Artificial Intelligence, Moscow, http:// www.inbase.artint.ru/article/voicnl-eng.asp

12. Jurafsky, D., Martin, J.H.: Speech and Language Processing. ISBN 0-13-095069-6. Prentice Hall (2000)

13. May, A.: Herramienta para Consultas Basadas en Ejemplos (QBE) para Multibases de Datos en Internet. Tesis de maestría. Departamento de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, México (2000)

14. Microsoft: English Query, Microsoft SQL Server, http://www.microsoft.com 15. Miller, G.: Wordnet, a Lexical Database. Cognitive Science Laboratory, Princeton

University. http://www.cogsci.princeton.edu/~wn/ 16. Morales, E.: Curso de Representación de Conocimiento. Instituto Tecnológico y de

Estudios Superiores de Monterrey, Campus Cuernavaca, Cuernavaca, México (1999). http://w3.mor.itesm.mx/~rdec/node1.html

17. OIL “Ontology Interchange Language”. http://www.ontoknowledge.org/oil/ 18. OntoWeb. http://delicias.dia.fi.upm.es/ontoweb/sig-tools/ 19. Protégé-2000. http://protege.stanford.edu/index.html

248 RITOS2

20. Padrón, J.I.: Analizador Morfológico-Sintáctico de Oraciones en Lenguaje Español. Tesis de maestría en desarrollo. Departamento de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, México

21. Rasgado, F.: Herramienta para Consultas Basadas en Ejemplos (QBE) para una Base de Datos en Internet. Tesis de maestría. Departamento de Ciencias Computacionales, Centro Nacional de Investigación y Desarrollo Tecnológico, Cuernavaca, México (1999)

22. Reis, P., Matias Nuno, J.: Edite - a Natural Language Interface to Databases, a New Dimension for an Old Approach. Instituto de Engenharia de Sistemas e Computadores, Lisboa, Portugal

23. Rocher, G.: Traducción de Queries en Prolog a SQL. Tesis de licenciatura. Universidad de las Américas, Puebla, México (1999)

24. Rojas, J., Torres, J.: A Survey in Natural Language Databases Interfaces. Memoria del 8vo. Congreso Internacional de Investigación en Ciencias Computacionales. Instituto Tecnológico de Colima, Colima, México (2001) pp. 63-70

25. Sethi, V.: Natural Language Interfaces to Databases: MIS Impact, and a Survey of their Use and Importance. Graduate School of Business, University of Pittsburgh, Pittsburgh, E.U.A.

26. SHOE, Simple HTML Ontology Extensions. http://www.cs.umd.edu/projects/plus/SHOE 27. Zárate, J.A., Pazos, R., Gelbukh, A.: Natural Language Interface for Web-based Databases.

Proc: 2nd WSEAS Int. Conf. on Robotics, Distance Learning and Intelligent Communication Systems (ICRODIC 2002), http://www.wseas.com/conferences/2002/ skiathos/icrodic/

28. Zloof, M.: Query by Example: a Database Language. IBM Sys. Journal Vol. 16 No. 4 (1977) 137-152


MoProSoft: Modelo de Procesos para la Industria de Software

Hanna Oktaba1 y Claudia Alquicira Esquivel2

1 Asociación Mexicana para la Calidad en la Ingeniería de Software (AMCIS), UNAM [email protected]

2 Asociación Mexicana para la Calidad en la Ingeniería de Software (AMCIS), Avantare Consultores

Resumen. Se presenta el modelo de procesos para la industria de software mexicana, MoProSoft, el cual fue desarrollado en el año 2002 como conse-cuencia de los acuerdos de la mesa 6 del Programa para el Desarrollo de la In-dustria de Software dirigido por la Secretaría de Economía.

1 Introducción

La Secretaria de Economía, por medio del Programa para el Desarrollo de la Industria de Software (ProSoft), desea fortalecer a la industria de software en México. Este programa está conformado por siete estrategias:

1. Promover las exportaciones y la atracción de inversiones 2. Educación y formación de personal competente en el desarrollo de software,

en cantidad y calidad convenientes 3. Contar con un marco legal promotor de la industria 4. Desarrollar el mercado interno 5. Fortalecer a la industria local 6. Alcanzar niveles internacionales en capacidad de procesos 7. Promover la construcción de infraestructura física y de telecomunicaciones

Se organizaron mesas de trabajo para definir la forma de abordar cada una de las

estrategias mencionadas. Para la número seis se reunió un equipo constituido por representantes de organizaciones o áreas de desarrollo de software mexicanas. Ini-cialmente, para lograr los objetivos de la estrategia 6 este equipo propuso las siguien-tes líneas de trabajo:

6.1. – Definición de modelos de procesos y de evaluación apropiados para la in-dustria de software mexicana

6.2. – Formación de instituciones de capacitación y asesoría en mejora de proce-sos

6.3. – Apoyo financiero para la capacitación y la evaluación de capacidad de pro-cesos

Una de las primeras tareas del grupo encargado de la estrategia 6 fue identificar las

necesidades de la industria mexicana de software con respecto a un modelo de proce-so. Las principales necesidades identificadas fueron:

• Específico para el desarrollo y mantenimiento de software. • Fácil de entender (comprensible). • Definido como un conjunto de procesos. • Práctico y fácil de aplicar, sobre todo en organizaciones pequeñas. • Orientado a mejorar los procesos para contribuir a los objetivos del negocio

y no simplemente ser un marco de referencia de certificación. • Debe de tener un mecanismo de evaluación o certificación, que indique un

estado real de una organización durante un periodo de vigencia específico. • Aplicable como norma mexicana.

Estas necesidades se tomaron en cuenta para realizar un análisis de los modelos

existentes, tales como ISO 9001:2000 [1], SW-CMM [2], ISO/IEC TR:15504 [3] entre otros, para evaluar si estos modelos podrían ser aplicables como norma mexica-na.

El punto más débil de estos modelos es cumplir con el requisito de ser prácticos y fáciles de aplicar, sobre todo en organizaciones pequeñas. Esto motivó la propuesta de realizar un proyecto cuyo propósito era generar el documento base para la Norma Mexicana para la Industria de Desarrollo y Mantenimiento de Software, que diera respuesta a las necesidades planteadas y, en particular, a este punto.

Para la realización del proyecto, la Secretaría de Economía estableció un convenio con la Facultad de Ciencias de la Universidad Nacional Autónoma de México bajo la responsabilidad de la Dra. Hanna Oktaba, quien convocó a personas con experiencia y conocimiento en los modelos de procesos y calidad de software para conformar al grupo editor. Este grupo estuvo constituido por :

• M. en C. Claudia Alquicira Esquivel • M. en C. Angélica Su Ramos • M. en C. Alfonso Martínez Martínez • M. en C. Gloria Quintanilla Osorio • Mara Ruvalcaba López • Francisco López Lira Hinojo • Maria Elena Rivera López • Mat. Maria Julia Orozco Mendoza • Dra. Yolanda Fernández Ordóñez • Miguel Ángel Flores Lemus

252 RITOS2

El proyecto se realizó en el periodo de septiembre a diciembre del 2002. Como re-sultado se generó el documento titulado Modelo de Procesos para la Industria de Software (MoProSoft).

La elaboración del Anexo “Relación de MoProSoft con ISO 9001:2000, CMM v1.1 e ISO/IEC TR 15504-2:1998”, estuvo a cargo de Øyvind Mo, alumno de la Maestría en Ciencia e Ingeniería de la Computación (UNAM).

2 Modelo de Procesos para la Industria de Software (MoProSoft)

El propósito del Modelo de Procesos para la Industria de Software es fomentar la estandarización de su operación a través de la incorporación de las mejores prácticas en gestión e ingeniería de software. La adopción del modelo permitirá elevar la capa-cidad de las organizaciones para ofrecer servicios con calidad y alcanzar niveles in-ternacionales de competitividad.

Con base en el conocimiento de los modelos de referencia del grupo editor, se es-tablecieron un conjunto de criterios que conformaron la base para la estructura del modelo, así como de la elaboración del patrón de proceso que se utilizó para la do-cumentación de los procesos. Los criterios fueron los siguientes:

1. Generar una estructura de los procesos que esté acorde con la estructura de las

organizaciones de la industria de software (Alta Dirección, Gestión y Operación). 2. Destacar el papel de la Alta Dirección en la planeación estratégica, su revisión y

mejora continua como el promotor del buen funcionamiento de la organización. 3. Considerar a la Gestión como proveedor de recursos, procesos y proyectos, así

como responsable de vigilar el cumplimiento de los objetivos estratégicos de la organización.

4. Considerar a la Operación como ejecutor de los proyectos de desarrollo y mante-nimiento de software.

5. Integrar de manera clara y consistente los elementos indispensables para la defi-nición de procesos y relaciones entre ellos.

6. Integrar los elementos para la administración de proyectos en un sólo proceso. 7. Integrar los elementos para la ingeniería de productos de software en un solo

marco que incluya actividades o prácticas de soporte, tales como verificación, va-lidación, documentación, administración de configuración y mediciones.

8. Destacar la importancia de la gestión de recursos, en particular los que componen la base de conocimiento de la organización tales como: productos generados por proyectos, datos de los proyectos, incluyendo las mediciones, documentación de procesos y los datos recaudados a partir de su uso y lecciones aprendidas.

9. Basar el modelo de procesos en ISO9000:2000 [1] y nivel 2 y 3 de CMM V.1.1 [2]. Usar como marco general ISO/IEC 15504 - Software Process Assesment [3] e incorporar las mejores prácticas de otros modelos de referencia tales como PMBOK [4], SWEBOK [5] y otros más especializados.


El desarrollo y mantenimiento de software se lleva a cabo a través de una serie de actividades realizadas por equipos de trabajo. La Ingeniería de Software se ha dedi-cado a identificar las mejores prácticas para realizar estas actividades recopilando las experiencias exitosas de la industria de software a nivel mundial. Estas prácticas se han organizado por áreas de aplicación, y se han dado a conocer como áreas clave de procesos, en caso de CMM, o como procesos de software en ISO/IEC 15504.

El modelo que se propone está enfocado en procesos y considera los tres niveles básicos de la estructura de una organización que son: la Alta Dirección, Gestión y Operación. El modelo pretende apoyar a las organizaciones en la estandarización de sus prácticas, en la evaluación de su efectividad y en la integración de la mejora con-tinua.

2.1 Estructura del Modelo de Procesos

MoProSoft tiene tres categorías de procesos: Alta Dirección, Gestión y Operación que reflejan la estructura de una organización. Está estructura la mostramos en la Fig. 1 como un diagrama de paquetes de UML [6].

Alta Dirección <<Categoría>>

+ Gestión de Negocio

Operación <<Categoría>>

+ Administración de Proyectos Específicos + Desarrollo y Mantenimiento de Software

Gestión <<Categoría>>

+ Bienes Servicios e Infraestructura + Conocimiento de la Organización

+ Gestión de Procesos + Gestión de Proyectos + Gestión de Recursos

+ Recursos Humanos y Ambiente de Trabajo

Fig. 1. Estructura del modelo de procesos

La categoría de Alta Dirección (DIR) aborda las prácticas relacionadas con la ges-tión del negocio. Proporciona los lineamientos a los procesos de la Categoría de Ges-tión y se retroalimenta con la información generada por ellos. Esta categoría contiene el proceso Gestión de Negocio (DIR 1).

La categoría de Gestión (GES) aborda las prácticas de gestión de procesos, proyec-tos y recursos en función de los lineamientos establecidos en la Categoría de Alta Dirección. Proporciona los elementos para el funcionamiento de los procesos de la

254 RITOS2

Categoría de Operación, recibe y evalúa la información generada por éstos y comu-nica los resultados a la Categoría de Alta Dirección. Esta categoría se integra por los procesos de Gestión de Procesos (GES 1), Gestión de Proyectos (GES 2) y Gestión de Recursos (GES 3). Éste último está constituido por los subprocesos de Recursos Humanos y Ambiente de Trabajo (GES 3.1), Bienes, Servicios e Infraestructura (GES 3.2) y Conocimiento de la Organización (GES 3.3).

La categoría de Operación (OPE) aborda las prácticas de los proyectos de desarro-llo y mantenimiento de software. Esta categoría realiza las actividades de acuerdo a los elementos proporcionados por la Categoría de Gestión y entrega a ésta la informa-ción y productos generados. Esta Categoría se integra por los procesos de Adminis-tración de Proyectos Específicos (OPE 1)y de Desarrollo y Mantenimiento de Softwa-re (OPE 2).

En cada proceso están definidos los roles responsables por la ejecución de las prác-ticas. Los roles se asignan al personal de la organización de acuerdo a sus habilidades y capacitación para desempeñarlos.

En MoProSoft se clasifican los roles en Grupo Directivo, Responsable de Proceso y otros roles involucrados. Además se considera al Cliente y al Usuario como roles externos a la organización.

2.2 Procesos de MoProSoft

En esta sección se presentan los propósitos, los objetivos y las salidas de cada uno de los procesos de MoProSoft.

DIR.1 Gestión de Negocio El propósito de Gestión de Negocio es establecer la razón de ser de la organización, sus objetivos y las condiciones para lograrlos, para lo cual es necesario considerar las necesidades de los clientes, así como evaluar los resultados para poder proponer cam-bios que permitan la mejora continua.

Adicionalmente habilita a la organización para responder a un ambiente de cambio y a sus miembros para trabajar en función de los objetivos establecidos.

Los objetivos a cumplir para asegurar el cumplimiento del propósito del proceso son:

• Lograr una planeación estratégica exitosa mediante el cumplimiento del Plan Estratégico.

• Lograr que la organización trabaje en función del Plan Estratégico mediante la correcta comunicación e implantación del mismo.

• Mejorar el Plan Estratégico mediante la implementación de la Propuesta de Mejoras.

Como productos de salida del proceso de Gestión de Negocio son el Plan Estraté-gico, Plan de Comunicación e Implantación, Reporte de Mediciones y Sugerencias de Mejora, Plan de Adquisiciones y Capacitación, y Lecciones Aprendidas.


GES.1 Gestión de Procesos El propósito de Gestión de Procesos es establecer los procesos de la organización, en función de los procesos requeridos identificados en el plan estratégico. Así como definir, planear, e implantar las actividades de mejora en los mismos.


• Planear las actividades de definición, implantación y mejora de los procesos en función del Plan Estratégico.

• Dar seguimiento a las actividades de definición, implantación y mejora de los procesos mediante el cumplimiento del Plan de Procesos.

• Mejorar el desempeño de los procesos mediante el cumplimiento del Plan de Mejora.

• Mantener informado a Gestión de Negocio sobre el desempeño de los proce-sos mediante el Reporte Cuantitativo y Cualitativo

Como productos de salida del proceso de Gestión de Procesos son Plan de Proce-sos, Documentación de Procesos, Reporte Cuantitativo y Cualitativo, y Lecciones Aprendidas.

GES.2 Gestión de Proyectos El propósito de la Gestión de Proyectos es asegurar que los proyectos contribuyan al cumplimiento de los objetivos y estrategias de la organización.


• Cumplir con el Plan Estratégico de la organización mediante la generación e instrumentación de proyectos.

• Mantener bajo control las actividades Gestión de Proyectos mediante el cumplimiento del Plan de Gestión de Proyectos.

• Proveer la información del desempeño de los proyectos a Gestión de Nego-cio mediante la generación del Reporte Cuantitativo y Cualitativo.

• Atender los Comentarios y Quejas del Cliente mediante la definición y eje-cución de Acciones Correctivas o Preventivas.

Como productos de salida del proceso de Gestión de Recursos son el Reporte Cuantitativo y Cualitativo, Reporte de Acciones Correctivas o Preventivas Relacio-nadas con Clientes, Reporte de Mediciones y Sugerencias de Mejora, Plan de Adqui-siciones y Capacitación, Contrato, Registro de Proyecto, Lecciones Aprendidas, Responsable de Administración del Proyecto Específico, Descripción del Proyecto, Metas Cuantitativas para el Proyecto y Acciones Correctivas o Preventivas.

GES.3 Gestión de Recursos El propósito de Gestión de Recursos es conseguir y dotar a la organización de los recursos humanos, infraestructura, ambiente de trabajo y proveedores, así como crear y mantener la base de conocimiento de la organización. La finalidad es apoyar el cumplimiento de los objetivos del plan estratégico de la organización.

256 RITOS2


• Lograr los objetivos del Plan Estratégico mediante la provisión de los recur-sos suficientes y calificados a la organización.

• Proveer a los miembros de la organización de los medios y mecanismos ade-cuados para el uso y resguardo de la información mediante la Base de Cono-cimiento.

• Mantener a la organización informada oportunamente sobre las tendencias tecnológicas mediante la elaboración de Propuestas Tecnológicas.

Como productos de salida del proceso de Gestión de Recursos son el Reporte Cuantitativo y Cualitativo, Propuestas Tecnológicas, Reporte de Mediciones y Suge-rencias de Mejora, Plan Operativo de Recursos Humanos y Ambiente de Trabajo, Plan Operativo de Bienes, Servicios e Infraestructura·, Plan Operativo de Conoci-miento de la Organización, Acciones Correctivas y Lecciones Aprendidas.

GES.3.1 Recursos Humanos y Ambiente de Trabajo El propósito de Recursos Humanos y Ambiente de Trabajo es proporcionar los recur-sos humanos adecuados para cumplir las responsabilidades asignadas a los roles den-tro de la organización, así como la evaluación del ambiente de trabajo.


• Proveer a la organización de recursos humanos calificados mediante la se-lección y capacitación adecuada a los roles que se les asignen.

• Evaluar el ambiente de trabajo de la organización mediante la Encuesta so-bre el Ambiente de Trabajo.

Como productos de salida del subproceso de Recursos Humanos y Ambiente de Trabajo son la

Asignación de Recursos, Reporte de Mediciones y Sugerencias de Mejora, Reporte de Recursos Humanos Disponibles, Capacitación y Ambiente de Trabajo, Plan de Capacitación y Lecciones Aprendidas.

GES.3.2 Bienes, Servicios e Infraestructura El propósito de Bienes, Servicios e Infraestructura es proporcionar proveedores de bienes, servicios e infraestructura que satisfagan los requisitos de adquisición de los procesos y proyectos.


• Proporcionar a la organización los bienes y servicios requeridos por los pro-cesos y los proyectos mediante la selección y evaluación de los proveedores.

• Mantener la infraestructura de la organización mediante el cumplimiento del Plan de Mantenimiento.


Como productos de salida del subproceso de Bienes, Servicios e Infraestructura son el Reporte de Bienes, Servicios e Infraestructura, Reporte de Mediciones y Suge-rencias de Mejora y Lecciones Aprendidas.

GES.3.3 Conocimiento de la Organización El propósito de Conocimiento de la Organización es mantener disponible y adminis-trar la base de conocimiento que contiene la información y los productos generados por la organización.

El objetivo a cumplir para asegurar el cumplimiento del propósito del proceso es: • Proporcionar a la organización la Base de Conocimiento de forma confiable,

oportuna y segura mediante el cumplimiento del Plan de Administración de la Base de Conocimiento.

Como productos de salida del subproceso de Conocimiento de la Organización son la Base de Conocimiento, Reporte del Estado de la Base de Conocimiento, Reporte de Mediciones y Sugerencias de Mejora y Lecciones Aprendidas.

OPE.1 Administración de Proyectos Específicos El propósito de la Administración de Proyectos Específicos es establecer y llevar a cabo sistemáticamente las actividades que permitan cumplir con los objetivos de un proyecto en tiempo y costo esperados.


• Lograr los Objetivos del proyecto en tiempo y costo mediante la coordina-ción y el manejo de los recursos del mismo.

• Mantener informado al Cliente mediante la realización de reuniones de avan-ce del proyecto.

• Atender las Solicitudes de Cambio del cliente mediante la recepción y análi-sis de las mismas.

Como productos de salida del proceso de Administración de Proyectos Específicos son el Reporte de Mediciones y Sugerencias de Mejora, Plan del Proyecto, Reporte de Seguimiento, Documento de Aceptación, Plan del Proyecto, Plan de Adquisiciones y Capacitación, Lecciones Aprendidas y Plan de Desarrollo.

OPE.2 Desarrollo y Mantenimiento de Software El propósito de Desarrollo y Mantenimiento de Software es la realización sistemática de las actividades de análisis, diseño, construcción, integración y pruebas de produc-tos de software nuevos o modificados cumpliendo con los requerimientos especifica-dos.

Los objetivos a cumplir para asegurar el cumplimiento del propósito del proceso

son: • Lograr que los productos de salida sean consistentes con los productos de

entrada en cada fase de un ciclo de desarrollo mediante las actividades de verificación, validación o prueba.

258 RITOS2

• Sustentar la realización de ciclos posteriores o proyectos de mantenimiento futuros mediante la integración de la Configuración de Software del ciclo ac-tual.

• Llevar a cabo las actividades de las fases de un ciclo mediante el cumpli-miento del Plan de Desarrollo actual.

Como productos de salida del proceso de Desarrollo y Mantenimiento de Software

son la Especificación de Requerimientos, Análisis y Diseño, Componente, Software, Configuración de Software, Manual de Usuario, Manual de Operación, Manual de Mantenimiento, Reporte de Actividades, Lecciones Aprendidas, Reporte de Medicio-nes y Sugerencias de Mejora, Registro de Rastreo, Plan de Pruebas de Sistema, Re-porte de Pruebas de Sistema, Plan de Pruebas de Integración y Reporte de Pruebas de Integración.

3 Patrón de procesos

El patrón de procesos es un esquema de elementos que sirvió para la documentación de los procesos. Está constituido por tres partes:

• Definición general del proceso, • Prácticas y • Guías de ajuste.

En la Definición general del proceso se identifica su nombre, categoría a la que pertenece, propósito, descripción general de sus actividades, objetivos, indicadores, metas cuantitativas, responsabilidad y autoridad, subprocesos en caso de tenerlos, procesos relacionados, entradas, salidas, productos internos y referencias bibliográfi-cas.

En las Prácticas se identifican los roles involucrados en el proceso y la capacita-ción requerida, se describen las actividades en detalle, asociándolas a los objetivos del proceso, se presenta un diagrama de flujo de trabajo, se describen las verificacio-nes y validaciones requeridas, se listan los productos que se incorporan a la base de conocimiento, se identifican los recursos de infraestructura necesarios para apoyar las actividades, se establecen las mediciones del proceso, así como las prácticas para la capacitación, manejo de situaciones excepcionales y uso de lecciones aprendidas.

En las Guías de ajuste se sugieren modificaciones al proceso que no deben afectar los objetivos del mismo.

4 Aplicación de MoProSoft

El modelo de procesos MoProSoft está dirigido a las empresas o áreas internas dedi-cadas al desarrollo y/o mantenimiento de software. Las organizaciones, que no cuen-ten con procesos establecidos, pueden usar el modelo ajustándolo de acuerdo a sus necesidades. Mientras que las organizaciones, que ya tienen procesos establecidos,


pueden usarlo como punto de referencia para identificar los elementos que les hace falta cubrir.

4 Trabajos futuros Aplicación de MoProSoft

Como MoProSoft fue definido por un grupo editor reducido es importante realizar una revisión pública del contenido del documento, para darlo a conocer y obtener sugerencias de mejora por parte de la industria de software.

Adicionalmente, se deberá elaborar un modelo de evaluación, basado en MoPro-Soft, que permita conocer la capacidad y madurez de procesos y, a su vez, ser compa-tible con los modelos de evaluación internacionalmente establecidos.

Otro punto importante es la realización de pruebas piloto en empresas o áreas in-ternas que desarrollan software para validar la aplicación práctica de MoProSoft y, de esta manera, obtener la retroalimentación para sus futuros ajustes.

Referencias

1. ISO 9001:2000 Sistemas de gestión de la calidad – Requisitos 2. The Capability Maturity Model: Guidelines for Improving the Software Process. Carnegie

Mellon University, Software Engineering Institute. 1994. Addison- Wesley. 3. ISO/IEC TR:15504 – SOFTWARE PROCESS ASSESSMENT. Part 2: A reference model

for process and process capability. 4. A guide to Project Management Body of Knowledge (PMBOK). Project Management Insti-

tute. Edición 2000 5. SWEBOK, Trial Version. Software engineering Coordinating Committee, Computer Soci-

ety, Software Engineering Institute. 2001. 6. Unified Modeling Language versión 1.4

www.omg.org/technology/documents/formal/uml.htm

260 RITOS2