<?xml version="1.0" standalone="yes"?>
<Paper uid="W98-1311">
  <Title>Using Genericity to Create Cutomizable Finite-State Tools</Title>
  <Section position="2" start_page="0" end_page="110" type="abstr">
    <SectionTitle>
1 Introduction
</SectionTitle>
    <Paragraph position="0"> The increasing need of finite-state components for different aspects in natural language processing has led us to the definition of a generic system for finite-state tools construction. An important aspect that should be considered comparing our resulting concrete finite-state automata with other existing ones (i.e. \[5\]) is that our automata are fed with data generated from an existing system, Word Manager (\[1\]; \[3\]), which is responsible for the specification, management and generation of morphological data. This means that the finite state component does not need a user defined regular expression input, instead it receives the extended paradigms, optimizing them following its internal needs. Another aspect to consider is the embedding of the single elements of the finite-state tools into a portable object-oriented framework, the architecture of which assures the reuse, the flexibility and the customization of the different parts.</Paragraph>
    <Paragraph position="1"> According to \[4\], a framework is more than a simple toolkit. It is a set of collaborating classes that make up a reusable design for a specific class of software~ The purpose of the framework is to define the overall structure of an application, its partitioning into classes and objects, their collaboration, and the thread of control. These predefined design parameters allow the programmer to concentrate on the specifics of his application. He will customizethe framework for a particular application by creating application specific subclasses of classes (eventually abstract) from the framework. The framework itself can be viewed as an abstract finite-state element. Only the definition of some concrete classes can generate from it a usable finite-state tool. The main design decisions have therefore already been taken, and the applications (finitestate elements) are faster to implement and even easier to maintain. The reasons why we have defined a framework are essentially two: 1. We wanted to achieve a broad software functionality with a small shared consistent structure. null</Paragraph>
    <Paragraph position="3"> 2. We wanted to offer the opportunity to customize our work simply by subclassing parts of it and reusing other parts (hopefully most of them) as they are.</Paragraph>
    <Paragraph position="4"> The aim of the project was not only the reA liT.ation of the framework. The implementation of concrete subclasses that you can put to work immediately has also played an important role. First, as an example of how you can adapt the framework classes to your needs, and, second, as a realization of the specialized morphology processing programs mentioned before.</Paragraph>
    <Paragraph position="5"> The description is divided in two main parts. In the first one (section 2) we will describe the framework, emphasazing its meaning, its design and its ability to create concrete finite-state tools. In the second part (section 3) we will show the different functionalities that we have realized with the tinlte-state elements created with the framework.</Paragraph>
  </Section>
class="xml-element"></Paper>