STATISTICAL ANALYSIS:

Es posible definir la arquitectura de un sistema específico como una colección de componentes junto con una descripción de la interacción entre dichos componentes [Shaw & Garlan, 1996; pp. 20].

Un componente de software es un artefacto de software que modela e implementa un conjunto coherente y bien definido de funciones. Un componente se compone de una interfaz y una implementación [Geppert & Dittrich, 2000; pp. 11] creados con el propósito de ser reutilizables [Jacobson et al., 1997; pp. 85]. La interfaz del componente representa el punto lógico de conexión entre el componente y el sistema. La interfaz debe de ocultar los detalles de implementación del componente y al mismo tiempo proporcionar información necesaria sobre sus características al resto del sistema [Molina, 2000; pp. 4]. Un componente es comparable con una caja negra, lo cual significa que los clientes pueden usarlos adecuadamente sin conocer su implementación a través de su interfaz. Es deseable que la interfaz y la implementación existan por separado para que puedan existir múltiples implementaciones para una interfaz y que las implementaciones puedan ser intercambiadas [Geppert & Dittrich, 2000; pp. 11].

Un componente es diseñando, empacado y documentado para ser reutilizable. Esto trae como consecuencia que el componente sea cohesivo y tenga una interfaz pública relativamente estable. El potencial de reutilización depende del alcance del componente, que puede ser muy general (reutilizable en mucho tipos de sistemas de aplicación) o limitado (específico para cierta área de negocios) [Jacobson et al., 1997; pp. 85]. Para que un componente tenga un alto potencial de reutilización se procura evitar la existencia de una gran cantidad de relaciones con otros componentes [Geppert & Dittrich, 2000; pp. 11] por lo que una buena parte del proceso de diseño de componentes debe de considerar como minimizar dichas relaciones y como dividir a un modelo en componentes reutilizables del

tamaño y estructura correctas [Jacobson et al., 1997; pp. 85]. Como parte de este trabajo de tesis, las relaciones entre los componentes de la arquitectura propuesta son identificadas en el capítulo 4 y se incluyen estadísticas referentes al tamaño de los mismos en el capítulo 5. Un componente no es útil por su propia cuenta, sino que es reutilizado conjuntamente con

otros componentes formando así un sistema basado en componentes [Jacobson et al., 1997;

pp. 86]. Este principio es conocido como reutilización por composición y los sistemas así

construidos pueden ser modificados o expandidos mediante el reemplazo o la adición de nuevos componentes. Se espera que un sistema basado en componentes facilite la adición o reemplazo de los componentes sin la necesidad de recompilar (o incluso apagar) el sistema [Geppert & Dittrich, 2000; pp. 11].

Es posible describir sistemas de software similares por medio de arquitecturas genéricas incrementadas y completadas por componentes. Siendo para esto necesario que la arquitectura genérica subyacente esté definida en términos de componentes y conexiones de tal forma que sea posible añadirle componentes de forma significativa y consistente [Geppert & Dittrich, 2000; pp. 11]. En este trabajo de tesis se propone una arquitectura genérica basada en componentes de la distribución de datos de una base de datos distribuida.

El paradigma orientado a objetos tiene muchas características que simplifican el desarrollo de buenos componentes, como lo son la encapsulación y el polimorfismo. Pero también posee elementos que, usados descuidadamente, pueden obstaculizar la meta de un desarrollo basado en componentes. Uno de esos mecanismos es la herencia. La herencia crea una fuerte dependencia entre una clase y su superclase, o un tipo y su supertipo. Lo que dificulta el mantenimiento de los componentes [Jacobson et al., 1997; pp. 86].

Con el fin de que el diseño de componentes no sea adversamente afectado por la fuerte dependencia creada por la herencia en los sistemas o modelos orientados a objetos, es común que los componentes posean un mayor nivel de granularidad que una clase u objeto. Un componente bien diseñado soporta un conjunto coherente de tareas mientras que los objetos y las clases típicamente comprenden solamente una fracción de dicho conjunto. Esto no significa que los conceptos de componente y objeto sean mutuamente excluyentes, más bien los componentes elevan la orientación a objetos a un nivel más alto de abstracción y granularidad. De hecho, los componentes con frecuencia son arreglos de objetos [Geppert & Dittrich, 2000; pp. 11].

En este trabajo de tesis se utilizará el paradigma orientado a objetos con el fin de aprovechar las características de encapsulación y polimorfismo facilitando así la creación de componentes y el diseño de los mismos tendrá un nivel de abstracción más elevando que el nivel clase-objeto para minimizar la fuerte dependencia creada por el mecanismo de la herencia con el propósito de crear componentes altamente reutilizables.

La arquitectura basada en componentes propuesta por este trabajo de tesis pretender ser una

alternativa a una arquitectura de D-DBMS monolítica. Entendiendo por arquitectura

conectadas dependiendo unas de otras a tal grado que no es fácil hacerle modificaciones o extensiones al sistema [Geppert & Dittrich, 2000; pp. 7].

Es de especial interés para este trabajo de tesis proponer una arquitectura basada en componentes dado que un DBMS monolítico podría presentar las siguientes desventajas [Castillo, 2002; pp. 8]:

• El DBMS podría llegar a ser tan grande y complejo que no podría ser mantenido a

un costo razonable;

• Los usuarios tendrían que pagar un alto precio para adicionar funcionalidad, aún si

ellos no requieren de la totalidad de las funciones del DBMS; y

• Un proveedor de DBMS podría no tener la experiencia para realizar tales

extensiones y podría no tener los recursos para comprometer todas las extensiones en un período de tiempo razonable.

Una aportación de este trabajo de tesis es presentar una posible solución a una tarea considerada compleja por los autores Geppert y Dittrich. Estos autores afirman que dividir la funcionalidad de un DBMS en partes independientes (componentes) es un problema complicado porque es necesario encontrar un balance adecuado entre la granularidad de los servicios y el número de relaciones entre servicios. De forma similar, determinar interfaces adecuadas entre los servicios también es una tarea compleja [Geppert & Dittrich, 2000; pp. 7]. A pesar de esta complejidad, los mismos autores proponen que las arquitecturas de DBMS basadas en componentes darán lugar a formas completamente nuevas de implementar aplicaciones y servidores de bases de datos. Lo cual reportará las siguientes ventajas:

• Las aplicaciones y los servidores de bases de datos podrán elegir al proveedor de

servicio óptimo para sus necesidades y no dependerán de un DBMS monolítico de gran tamaño; y

• En el caso de los tener servicios estandarizados, sería posible un escenario en el cual

se mezclen servicios de diferentes proveedores.

De acuerdo a Geppert y Dittrich, estas ventajas podrán ser alcanzadas sólo si estos servicios (las aplicaciones y los servidores de bases de datos) y sus implementaciones son descritos y construidos a partir de componentes de software.