Características Fundamentales de Bases de Datos Orientadas a Objetos y Gestión de Solicitudes de Modificación de Software

Características y Criterios de Bases de Datos Orientadas a Objetos (BDOO)

Una base de datos orientada a objetos es un sistema inteligente que soporta el paradigma orientado a objetos, almacenando tanto métodos como datos. Está diseñada para ser eficaz y más segura, ya que restringe el acceso directo a los datos (objetos); el acceso debe realizarse exclusivamente a través de los métodos definidos por el programador.

Criterios Fundamentales

Una BDOO se basa en dos criterios esenciales:

• Debe ser un sistema orientado a objetos.
• Debe ser un sistema gestor de base de datos (SGBD).

Características Clave de las BDOO

Las bases de datos orientadas a objetos deben soportar las siguientes 13 características:

1. Soporte de Objetos Complejos: Debe ser posible construir objetos complejos aplicando constructores a objetos básicos.
2. Identidad del Objeto: Todos los objetos deben poseer un identificador único, independiente de los valores de sus atributos.
3. Encapsulamiento: Los programadores solo tienen acceso a la especificación de la interfaz de los métodos; los datos y la implementación interna de estos métodos permanecen ocultos dentro de los objetos.
4. Tipos o Clases: El esquema de la base de datos debe contener un conjunto de clases o tipos definidos.
5. Herencia: Los tipos o clases deben ser capaces de heredar atributos y métodos de sus supertipos o superclases.
6. Soporte de Sobrecarga: Los métodos deben poder aplicarse a diferentes tipos (sobrecarga de métodos).
7. DML Completo: El Lenguaje de Manipulación de Datos (DML) en los SGBD orientados a objetos debe ser un lenguaje de programación de propósito general.
8. Conjunto de Tipos de Datos Extensible: No debe existir distinción entre los tipos definidos por el usuario y los tipos definidos por el sistema.
9. Persistencia de Datos: Los datos deben mantenerse activos después de que la aplicación que los creó haya finalizado; el usuario no necesita realizar copias explícitas.
10. Manejo de Grandes Bases de Datos: El SGBD debe ser capaz de gestionar bases de datos de gran volumen.
11. Soporte de Concurrencia: Debe disponer de mecanismos adecuados para el control de la concurrencia.
12. Recuperación: El sistema gestor debe proveer mecanismos de recuperación de la información en caso de fallos del sistema.
13. Facilidad de Consulta: El SGBD debe ofrecer una manera sencilla para realizar consultas sobre los datos.

Proceso de Petición de Cambios en Productos de Software

Los procesos de evolución del software varían significativamente según la organización. En algunos entornos, la evolución es un proceso informal donde las solicitudes de cambio surgen de conversaciones directas entre usuarios y desarrolladores. En contraste, otras organizaciones implementan un proceso formalizado que requiere documentación exhaustiva.

Fuentes y Naturaleza de las Propuestas de Cambio

Las propuestas de cambio al sistema son el motor principal de su evolución. Estas modificaciones pueden originarse por:

• Requerimientos existentes que no fueron implementados en la versión liberada.
• Peticiones de nuevos requerimientos funcionales o no funcionales.
• Reportes de errores (*bugs*) emitidos por los participantes del sistema.
• Nuevas ideas para la mejora del software aportadas por el equipo de desarrollo.

Los procesos de identificación de cambios y evolución del sistema son inherentemente cíclicos y se mantienen activos durante toda la vida útil del sistema.

Actividades del Proceso de Evolución

El proceso de evolución del software incluye varias actividades clave:

Fases Principales

El ciclo de evolución abarca actividades como la planeación de la versión, la implementación del sistema, la estimación de costos y el análisis de impacto de los cambios propuestos.

Toma de Decisiones y Ejecución

Si los cambios propuestos son aceptados, se procede a:

1. Planear una nueva versión del sistema.
2. Definir las acciones específicas a realizar.
3. Tomar la decisión final sobre qué cambios se implementarán en la siguiente liberación.

Una vez implementados, los cambios se validan y se libera la nueva versión del sistema. Este ciclo se repite continuamente con el siguiente conjunto de cambios propuestos para la subsiguiente liberación.