Asistida por computadoras

1. ¿Qué significa case?

El mejor taller de un artesano -sea mecánico, carpintero o ingeniero del software- tiene tres características fundamentales:

(1)  una colección de herramientas útiles que le ayudarán en todos los pasos de la construcción de un producto

(2)  una disposición organizada que permitirá hallar rápidamente las herramientas y utilizarlas con eficacia

(3)  un artesano cualificado que entienda la forma de utilizar las herramientas de manera eficaz.  Ahora es cuando los ingenieros del software reconocen que necesitan más herramientas y más variadas junto con un taller eficiente y organizado en el que puedan ubicarlas.

El taller de ingeniería del software se denomina un entorno de apoyo integrado a proyectos (que se describirá posteriormente en este capítulo), y el conjunto de herramientas que llena ese taller se denomina ingeniería del software asistida por computadora (CASE). CASE proporciona al ingeniero la posibilidad de automatizar actividades manuales y de mejorar su visión general de la ingeniería. Al igual que las herramientas de ingeniería y de diseño asistidos por computadora que utilizan los ingenieros de otras disciplinas, las herramientas CASE ayudan a garantizar que la calidad se diseñe antes de llegar a construir el producto.

2. Construcción de bloques básicos para CASE

La ingeniería del software asistida por computadora puede ser tan sencilla como una única herramienta que preste su apoyo para una única actividad de ingeniería del software, o tan compleja como todo un entorno que abarque «herramientas», una base de datos, personas, hardware, una red, sistemas operativos, estándares, y otros mil componentes más. Los bloques de construcción de CASE se ilustran en la Figura 31.1. Cada bloque de construcción forma el fundamento del siguiente, estando las herramientas situadas en la parte superior del montón. Es interesante tener en cuenta que el fundamento de los entornos CASE efectivos tiene relativamente poco que ver con las herramientas de ingeniería del software en sí. Más bien, los entomos para la ingeniería del software se construyen con éxito sobre una arquitectura de entornos que abarca un hardware y un software de sistemas adecuados. Además, la arquitectura del entorno deberá tener en cuenta los patrones de trabajo humano que se aplicarán durante el proceso de ingeniería del software.

Las arquitecturas del entorno, que constan de una plataforma hardware y de un soporte de sistema operativo (incluyendo software de red, gestión de la base de datos y servicios de gestión de objetos), establece los cimientos para un entorno CASE. Pero el entorno CASE en sí requiere otros bloques de construcción. Existe un conjunto de servicios de portabilidad que proporciona un puente entre las herramientas CASE, su marco de integración y la arquitectura del entorno. El marco de integración es un grupo de programas especializados que permiten a cada una de las herramientas comunicarse entre sí, para crear una base de datos del proyecto, y para mostrar el mismo aspecto al usuario final (el ingeniero del software). Los servicios de portabilidad permiten que las herramientas CASE y su marco de integración migren entre distintas plataformas del hardware y sistemas operativos sin un mantenimiento adaptativo significativo.

Los bloques de construcción representados en la Figura 3 1.1 representan un fundamento completo para la integración de herramientas CASE. Sin embargo, la mayor parte de las herramientas CASE que se utilizan en la actualidad no han sido construidas empleando todos los bloques de construcción anteriormente descritos. De hecho, algunas herramientas siguen siendo las «soluciones puntuales». Esto es, una herramienta se utiliza para prestar apoyo en una actividad de ingeniería del software concreta (por ejemplo, modelado de análisis), pero esta herramienta no se comunica directamente con otras, no está unida a una base de datos del proyecto, y no forma parte de un entorno integrado CASE (1-CASE). Aunque esta situación no es la ideal, se puede utilizar una herramienta CASE bastante eficiente, aunque se trate de una solicitud puntual.

Los niveles relativos de integración CASE se muestran en la Figura 3 1.2. En el extremo inferior del espectro de integración se encuentra la herramienta individual (solución puntual). Cuando las herramientas individuales proporcionan servicios para el intercambio de datos (como lo hacen la mayoría), el nivel de integración mejora ligeramente. Estas herramientas producen su salida en un formato estándar que deberá ser compatible con otras herramientas que sean capaces de leer ese formato. En algunos casos, los constructores de herramientas CASE complementarias trabajan juntos para formar un puente entre herramientas (por ejemplo, una herramienta de análisis y diseño que se enlaza con un generador de código). Mediante la utilización de este enfoque, la sinergia entre herramientas puede producir unos resultados finales que serían difíciles de crear empleando cada una de las herramientas por separado. La integración de fuente única se produce cuando un único vendedor de herramientas CASE integra una cierta cantidad de herramientas distintas y las vende en forma de paquete. Aunque este enfoque es bastante eficiente, la arquitectura cerrada de la mayoría de los entornos de fuente Única evita añadir fácilmente herramientas procedentes de otros fabricantes.

En el extremo superior del espectro de integración se encuentra el entorno de apoyo integrado a proyectos integrado (EAIP). Se han creado estándares en cada uno de los bloques de construcción descritos anteriormente. Los fabricantes de herramientas CASE utilizan los estándares EAIP para construir herramientas que sean compatibles con el EAIP, y que por tanto sean compatibles entre sí.

1. Una taxonomía de herramientas CASE

Existe un cierto número de riesgos que son inherentes siempre que se intenta efectuar una categorización de las herramientas CASE. Existe una sutil implicación que consiste en que para crear un entorno CASE efectivo se deberán implementar todas las categorías de herramientas esto no es ni sencillo, ni cierto-. Cuando hay personas que creen que una herramienta pertenece a una categoría, se puede crear cierta confusión (o contradicción) al ubicar una herramienta específica dentro de otra categoría. Es posible que algunos lectores piensen que se ha omitido una categoría completa -1iminando por tanto un conjunto de herramientas completo e incluirlo así en el entorno CASE global-. Además, una categorización sencilla tiende a ser plana - esto es, no se muestra la interacción jerárquica de las herramientas o las relaciones que existen entre ellas-. A pesar de estos riesgos, es necesario crear una taxonomía de herramientas CASE -para comprender mejor la amplitud de CASE y para apreciar mejor en donde se pueden aplicar estas herramientas dentro del proceso del software-.

Las herramientas CASE se pueden clasificar por su función, por su papel como instrumentos para administradores o personal técnico, por su utilización en los distintos pasos del proceso de ingeniería del software, por la arquitectura del entorno (hardware y software) que les presta su apoyo, o incluso por su origen o coste [QED89]. La taxonomía que se presenta a continuación utiliza como criterio principal la función.

Herramientas de ingeniería de procesos de negocio. Al modelar los requisitos de información estratégica de una organización, las herramientas de ingeniería de procesos de negocios proporcionan un «metamodelo» del cual se derivan sistemas de información específicos. En lugar de centrarse en los requisitos de una aplicación específica, estas herramientas CASE modelan la información de negocio cuando ésta se transfiere entre distintas entidades organizativas en el seno de una compañía. El objetivo primordial de las herramientas de esta categoría consiste en representar objetos de datos de negocio, sus relaciones y la forma en que fluyen estos objetos de datos entre distintas zonas de negocio en el seno de la compañía.

Modelado de procesos y herramientas de gestión. Si una organización trabaja por mejorar un proceso de negocio (o de software) lo primero que debe hacer es entenderlo. Las herramientas de modelado de procesos (llamadas también herramientas de tecnología de procesos) se utilizan para representar los elementos clave del proceso de manera que sea posible entenderlo mejor. Estas herramientas también pueden proporcionar vínculos con descripciones de procesos que ayuden a quienes estén implicados en el proceso de comprender las tareas que se requieren para llevar a cabo ese proceso. Además, las herramientas de gestión de procesos pueden proporcionar vínculos con otras herramientas que proporcionan un apoyo para las actividades de proceso ya definidas.

Herramientas de planificación de proyectos. Las herramientas de esta categoría se centran en dos áreas primordiales: estimación de costes y de esfuerzos del proyecto de software y planificación de proyectos. Las herramientas de estimación calculan el esfuerzo estimado, la duración del proyecto y el número de personas recomendado para el proyecto. Las herramientas de planificación de proyectos hacen posible que el gestor defina todas las tareas del proyecto (la estructura de desglose de tareas), que cree una red de tareas (normalmente empleando una entrada gráfica), que represente las interdependencias entre tareas y que modele la cantidad de paralelismo que sea posible para ese proyecto.

Herramientas de análisis de riesgos. La identificación de posibles riesgos y el desarrollo de un plan para mitigar, monitorizar y gestionar esos riesgos tienen una importancia fundamental en los proyectos grandes. Las herramientas de análisis de riesgos hacen posible que el gestor del proyecto construya una tabla de riesgos proporcionando una guía detallada en la identificación y análisis de riesgos.

Herramientas de gestión de proyectos. La planificación del proyecto y el plan del proyecto deberán ser rastreados y monitorizados de forma continua. Además, el gestor deberá utilizar las herramientas que recojan métricas que en Última instancia proporcionen una indicación de la calidad del producto del software. Las herramientas de esta categoría suelen ser extensiones de herramientas de planificación de proyectos.

Herramientas de seguimiento de requisitos. Cuando se desarrollan grandes sistemas, las cosas «se derrumban». Es decir, el sistema proporcionado suele no satisfacer los requisitos especificados por el cliente. El objetivo de las herramientas de seguimiento es proporcionar un enfoque sistemático para el aislamiento de los requisitos, comenzando por el RFP del cliente o por la especificación. Las herramientas típicas de seguimiento de requisitos combinan una evaluación de textos por interacción humana, con un sistema de gestión de bases de datos que almacena y categoriza todos y cada uno de los requisitos del sistema que se «analizan» a partir de la RFP o especificación original.

Herramientas de métricas y de gestión. Las métricas del software mejoran la capacidad del gestor para controlar y coordinar el proceso de ingeniería del software y la capacidad del ingeniero para mejorar la calidad del software que se produce. Las métricas o herramientas de medidas actuales se centran en características de procesos y productos. Las herramientas orientadas a la gestión se sirven de métricas específicas del proyecto (por ejemplo, LDC/persona-mes, defectos por punto de función) que proporcionan una indicación global de productividad o de calidad. Las herramientas con orientación técnica determinan las métricas técnicas que proporcionan una mejor visión de la calidad del diseño o del código.

Herramientas de documentación. Las herramientas de producción de documentos y de autoedición prestan su apoyo a casi todos los aspectos de la ingeniería del software, y representan una importante oportunidad de «aprovechamiento» para todos los que desarrollan software. La mayoría de las organizaciones dedicadas al desarrollo de software invierten una cantidad de tiempo considerable en el desarrollo de documentos, y en muchos casos el proceso de documentación en sí resulta bastante deficiente. Es frecuente que una organización de desarrollo de software invierta en la documentación hasta un 20 o un 30 por 100-de su esfuerzo global de desarrollo de software. Por esta razón, las herramientas de documentación suponen una oportunidad importante para mejorar la productividad.

Herramientas de software de sistema. CASE es una tecnología de estaciones de trabajo. Por tanto, el entorno CASE deberá adaptarse a un software de sistema en red de alta calidad, al correo electrónico, a los tablones de anuncios electrónicos y a otras posibilidades de comunicarse.

Herramientas de control de calidad. La mayor parte de las herramientas CASE que afirman tener como principal interés el control de calidad son en realidad herramientas de métricas que hacen una auditoría del código fuente para determinar si se ajusta o no a ciertos estándares del lenguaje. Otras herramientas extraen métricas técnicas en un esfuerzo por extrapolar la calidad del software que se está construyendo.

Herramientas de gestión de bases de datos. El software de gestión de bases de datos sirve como fundamento para establecer una base de datos CASE (repositorio), que también se denominará base de datos del proyecto. Dada la importancia de los objetos de configuración, las herramientas de gestión de bases de datos para CASE pueden evolucionar a partir de los sistemas de gestión de bases de datos relacionales (SGBDR) para transformarse en sistemas de gestión de bases de datos orientadas a objetos (SGBDOO).

Herramientas de gestión de configuración de software. La gestión de configuración de software (GCS) se encuentra en el núcleo de todos los entonos CASE. Las herramientas pueden ofrecer su asistencia en las cinco tareas principales de GCS -identificación, control de versiones, control de cambios, auditoría y contabilidad de estados-. La base de datos CASE proporciona el mecanismo de identificar todos los elementos de configuración y de relacionarlo con otros elementos; el proceso de control de cambios se puede implementar con ayuda de las herramientas especializadas; un acceso sencillo a los elementos de configuración individuales facilita el proceso de auditoria; y las herramientas de comunicación CASE pueden mejorar enormemente la Contabilidad de estados (ofreciendo información acerca de los cambios a todos aquellos que necesiten conocerlos).

Herramientas de análisis y diseño. Las herramientas de análisis y diseño hacen posible que el ingeniero del software cree modelos del sistema que vaya a construir. Los modelos contienen una representación de los datos, función y comportamiento (en el nivel de análisis), así como caracterizaciones del diseño de datos, de arquitectura, a nivel de componentes e interfaz'. Al efectuar una comprobación de consistencia y validez de los modelos, las herramientas de análisis y diseño proporcionan al ingeniero del software un cierto grado de visión en lo tocante a la representación del análisis, y le ayudan a eliminar errores antes de que se propaguen al diseño, o lo que es peor, a la propia implementación.

Herramientas PROISIM. Las herramientas PRO/SIM (de construcción de prototipos y simulación) [MCW] proporcionan al ingeniero del software la capacidad de predecir el comportamiento de un sistema en tiempo real antes de llegar a construirlo. Además, también le capacitan para desarrollar simulaciones del sistema de tiempo real, lo que permitirá que el cliente obtenga ideas acerca de su funcionamiento, comportamiento y respuesta antes de la verdadera implementación.

Herramientas de desarrollo y diseño de interfaz. Las herramientas de desarrollo y diseño de interfaz son en realidad un conjunto de herramientas de componentes de programas (clases) tales como menús, botones, estructuras de ventanas, iconos, mecanismos de desplazamiento de la pantalla, controladores de dispositivos, etc. Sin embargo, estos conjuntos de herramientas se están viendo sustituidos por herramientas de construcción de prototipos de interfaz que permiten una rápida creación en pantalla de interfaces de usuario sofisticadas, que se ajustan al estándar de interfaz que se haya adoptado para el software.

Herramientas de construcción de prototipos. Se puede utilizar toda una gama de herramientas de construcción de prototipos. Los generadores de pantallas permiten al ingeniero del software definir rápidamente la disposición de la pantalla para aplicaciones interactivas. Otras herramientas de prototipos CASE más sofisticadas permiten la creación de un diseño de datos, acompañado por diseños e informes de la pantalla. Muchas herramientas de análisis y diseño son más extensas y proporcionan opciones de construcción de prototipos. Las herramientas PRO/SIM generan un diseño esquemático de código fuente en Ada y C para las aplicaciones de ingeniería (en tiempo real). Por último, una gama amplia de herramientas de cuarta generación poseen también características de construcción de prototipos.

Herramientas de programación. La categoría de herramientas de programación abarca los compiladores, editores y depuradores disponibles para apoyar a la mayoría de los lenguajes de programación convencionales. Además, en esta categoría también residen los entornos de programación orientados a objetos (00), los lenguajes de cuarta generación, los entornos de programación gráfica, los generadores de aplicaciones y los lenguajes de consulta de bases de datos.

Herramientas de desarrollo de Webs. Las actividades asociadas a la ingeniería Web están apoyadas por una variedad de herramientas de desarrollo de WebApps. Entre estas herramientas se incluyen las que prestan ayuda en la generación de texto, gráficos, formularios, guiones, applets y otros elementos de una página Web.

Herramientas de integración y pruebas. En el directorio de herramientas de pruebas de software del Software Quality Engineering [SQE95], se definen las categorías de herramientas de pruebas siguientes:

1. adquisición de datos: herramientas que adquieren los datos que se utilizarán durante la prueba

2. medida estática: herramientas que analizan el código fuente sin ejecutar casos de prueba

3. medida dinámica: herramientas que analizan el código fuente durante la ejecución

4. simulación: herramientas que simulan las funciones del hardware o de otros elementos externos

5. gestión de pruebas: herramientas que prestan su asistencia en la planificación, desarrollo y control de las pruebas

6. herramientas de funcionalidad cruzada: se trata de herramientas que atraviesan los límites de las categorías anteriores.

Debería tenerse en cuenta que muchas de las herramientas de prueba poseen características que abarcan dos categorías o más de las anteriormente mencionadas.

Herramientas de análisis estático. Las herramientas de análisis estático prestan su asistencia al ingeniero del software a efectos de derivar casos prácticos. En la industria se utilizan tres tipos distintos de herramientas estáticas de prueba: herramientas de prueba basadas en código; lenguajes de prueba especializados y herramientas de prueba basadas en requisitos. Las herramientas de prueba basadas en código admiten un código fuente (o LDP) como entrada, y llevan a cabo varios análisis de los que se obtiene la generación de casos de prueba. Los lenguajes de prueba especializados (por ejemplo, ATLAS) hacen posible que el ingeniero del software escriba especificaciones de prueba detalladas para describir todos los casos de prueba y la logística de su ejecución. Las herramientas de prueba basadas en requisitos aíslan los requisitos del usuario y sugieren los casos de prueba (o clases de prueba) que ejercitarán esos requisitos.

Herramientas de análisis dinámico. Las herramientas de análisis dinámico interactúan con el programa que se esté ejecutando, prueban la cobertura de rutas, prueban las afirmaciones acerca del valor de variables específicas e instrumentan por otro lado el flujo de ejecución del programa. Las herramientas dinámicas pueden ser intrusivas, o no intrusivas. Las herramientas intrusivas modifican el software que hay que comprobar mediante la inserción de sondas (instrucciones adicionales) y que efectúan las actividades mencionadas anteriormente. Las herramientas de prueba no intrusivas utilizan un procesador hardware por separado que funciona en paralelo con el procesador que contiene el programa que se está probando.

Herramientas de gestión de pruebas. Las herramientas de gestión de pruebas se utilizan para controlar y coordinar las pruebas del software por todos y cada uno de los pasos principales de las pruebas. Las herramientas de esta categoría gestionan y coordinan las pruebas de regresiones, efectúan comparaciones que determinan las diferencias entre la salida real y la esperada y realizan pruebas por lotes de programas con interfaces hombre- máquina interactivas. Además de las funciones indicadas anteriormente, muchas herramientas de gestión de pruebas sirven también como controladores de pruebas genéricos. Un controlador de pruebas lee uno o más casos de prueba de algún archivo de pruebas, aplica formato a los datos de prueba para que se ajusten a las necesidades del software que se está probando, e invoca entonces al software que es preciso probar.

Herramientas de pruebas cliente/servidor. El entorno C/S exige unas herramientas de pruebas especializadas que ejerciten la interfaz gráfica de usuario y los requisitos de comunicaciones en red para el cliente y el servidor.

Herramientas de reingeniería. Las herramientas para el software heredado abarca un conjunto de actividades de mantenimiento que actualmente absorben un porcentaje significativo de todo el esfuerzo relacionado con el software. La categoría de herramientas de reingeniería se puede subdividir en las funciones siguientes:

1. herramientas de ingeniería inversa para producir especificaciones: se toma el código fuente como entrada y se generan modelos gráficos de análisis y diseño estructurados, listas de utilización y más información sobre el diseño

2. herramientas de reestructuración y análisis de código: se analiza la sintaxis del programa, se genera una gráfica de control de flujo y se genera automáticamente un programa estructurado

3. herramientas de reingeniería para sistemas online: se utilizan para modificar sistemas de bases de datos on-line (por ejemplo, para convertir archivos IDMS o DB2 en un formato de entidades y relaciones).

Muchas de las herramientas anteriores se ven limitadas a lenguajes de programación específicos (aunque abarcan la mayoría de los lenguajes principales) y requieren un cierto grado de interacción con el ingeniero del software.

2. Entornos CASE integrados

Aunque se pueden obtener beneficios individualmente de las herramientas CASE que abarcan actividades de ingeniería del software por separado, la verdadera potencia de CASE solamente se puede lograr mediante la integración. Entre los beneficios del CASE integrado (1-CASE) se incluyen:

(1)  una transferencia regular de información (modelos, programas, documentos, datos) entre una herramienta y otra, y entre un paso de ingeniería y el siguiente

(2)  una reducción del esfuerzo necesario para efectuar actividades globales tales como la gestión de configuración de software, el control de calidad y la producción de documentos

(3)   un aumento del control del proyecto que se logra mediante una mejor planificación, monitorización y comunicación

(4)  una mejor coordinación entre los miembros del personal que estén trabajando en grandes proyectos de software.

¿Cuáles son los beneficios de CASE integradas?

Ahora bien, 1-CASE también expone a desafíos significativos. En cada acción exige unas representaciones consecuentes de la información de la ingeniería del software; unas interfaces estandarizadas entre las herramientas, un mecanismo homogéneo para la comunicación entre el ingeniero del software y todas sus herramientas, y un enfoque efectivo que hará posible que 1-CASE se desplace a lo largo de distintas plataformas de hardware y distintos sistemas operativos. Los entornos 1-CASE generales han comenzado a surgir más lentamente de lo que inicialmente se esperaba. Sin embargo, los entornos integrados sí que existen, y con el paso de los años se van haciendo más poderosos.

El término integración implica tanto combinación como cierre. 1-CASE combina toda una gama de herramientas e información distintos de tal modo que hace posible el cierre de la comunicación entre las herramientas, entre personas y entre procesos de software. Las herramientas se integran de tal manera que la información de ingeniería del software esté disponible para todas las herramientas que se necesiten; la utilización se integra de tal modo que se proporciona un aspecto y una interacción común para todas las herramientas; y se integra una filosofía de desarrollo que aplica prácticas modernas y métodos ya probados.

Para definir la integración en el contexto del proceso del software, es necesario establecer un conjunto de requisitos para 1-CASE [FOR89a]. Un entorno CASE integrado debería:

(1)  Proporcionar un mecanismo para compartir la información de la ingeniería del software entre todas las herramientas dentro del entorno;

(2)  Hacer posible que un cambio de un elemento de información se siga hasta los demás elementos de información relacionados;

(3)  Proporcionar un control de versiones y una gestión de configuración general para toda la información de la ingeniería del software;

(4)  Permitir un acceso directo y no secuencia1 a cualquier herramienta del entorno;

(5)  Establecer un apoyo automatizado para el modelo de procesos de software que se haya seleccionado, integrando herramientas CASE y elementos de configuración del software en una estructura estándar de desglose de trabajo;

(6)  Permitir que los usuarios de cada una de las herramientas puedan experimentar con el aspecto e interacción de la interfaz hombre-máquina

(7)  Dar soporte a la comunicación entre ingenieros del software

(8)  Recoger métricas tanto técnicas como de gestión que se puedan utilizar para mejorar el proceso y el producto.

Para alcanzar estos objetivos, cada uno de los bloques de construcción de una arquitectura (CASE Fig. 3 1. 1-) deberá encajar con los demás sin ningún tipo de limitación. Los bloques de construcción fundamentales -arquitectura del entorno, plataforma hardware y sistema operativo- deberán «unirse» a través de un conjunto de servicios de portabilidad a un marco de referencia de integración que alcance los objetivos indicados anteriormente.

3. La arquitectura de integración

Un equipo de ingeniería del software utiliza herramientas CASE, los métodos correspondientes y un marco de referencia de proceso con objeto de crear un conjunto de informaciones de ingeniería del software. El marco de referencia de integración facilita la transferencia de información desde y hacia ese conjunto de informaciones. Para lograr esto, deberán existir los componentes de arquitectura siguientes: la creación de una base de datos (para almacenar la información); la construcción de un sistema de gestión de objetos (para gestionar los cambios efectuados en la información); la construcción de un mecanismo de control de herramientas (para coordinar la utilización de herramientas CASE), y una interfaz de usuario que proporcione una ruta consecuente entre las acciones efectuadas por el usuario y las herramientas que están dentro del entorno. La mayoría de los modelos (por ejemplo, [FOR90], [SHA95] del marco de referencia de integración representan a estos componentes como si fueran capas. En la Figura 31.3. se muestra un modelo sencillo del marco de referencia que representa únicamente los componentes indicados anteriormente.

La capa de interfaz del usuario (Figura 3 1.1) incorpora un conjunto de herramientas de interfaz estandarizado, con un protocolo de presentación común. El kit de herramientas de interfaz contiene software para la gestión de la interfaz hombre-máquina, y una biblioteca de objetos de visualización. Ambos proporcionan un mecanismo consecuente para la comunicación entre la interfaz y las herramientas CASE individuales. El protocolo de presentación es el conjunto de líneas generales que proporciona un mismo aspecto a todas las herramientas CASE. Las convenciones del diseño de pantalla, nombres y organización del menú, iconos, nombres de los objetos, utilización del teclado y del ratón, y el mecanismo para acceder a las herramientas se definen todos ellos como parte del protocolo de presentación.

La capa de herramientas incorpora un conjunto de servicios de gestión de herramientas con las herramientas CASE en sí. Los servicios de gestión de herramientas (SGH) controlan el comportamiento de las herramientas dentro del entorno. Si durante la ejecución de una o más herramientas se emplea la multitarea, SGH efectúa la sincronización y comunicación multitarea, coordina el flujo de información desde el repositorio y el sistema de gestión de objetos a las herramientas, realiza las funciones de seguridad y auditoría y recoge métricas acerca de la utilización de herramientas.

La capa de gestión de objetos (CGO) lleva a cabo las funciones de gestión de configuración que se describían en el Capítulo 8. En esencia, el software de esta capa de la arquitectura de marco de referencia proporciona el mecanismo para la integración de herramientas. Cada herramienta CASE «se enchufa» en la capa de gestión de objetos. Al funcionar en conjunto con el repositorio CASE, la CGO proporciona los servicios de integración -un conjunto de módulos estándar que acoplan las herramientas con el repositorio-. Además, la OML proporciona los servicios de gestión de configuración haciendo posible la identificación de todos los objetos de configuración, llevando a cabo el control de versiones y proporcionando apoyo para el control de cambios, auditorías y contabilidad de estados.

La capa de repositorio compartido es la base de datos CASE y las funciones de control de acceso que hacen posible que la capa de gestión de objetos interactúe con la base de datos. La integración de datos se logra mediante las capas de gestión de objetos y de repositorio compartido que se estudian más adelante y con más profundidad en este mismo capítulo.

1. El repositorio CASE

El Diccionario Webster define la palabra repositorio como  «todo objeto o persona considerado centro de acumulación o almacenamiento». Durante las primeras fases de la historia del desarrollo del software, el repositorio era en realidad una persona -el programador que tenía que recordar la ubicación de toda la información relevante para un determinado proyecto de software, que tenía que recordar información que nunca se había escrito y que tenía que reconstruir la información que se había perdido-. Tristemente, la utilización de una persona como «centro de acumulación y almacenamiento» (aunque corresponda con la definición del diccionario) no funciona demasiado bien. En la actualidad, el repositorio es una «cosa» -una base de datos que actúa como centro tanto para la acumulación como para el almacenamiento de información de ingeniería del software-.

El papel de la persona (del ingeniero del software) es interactuar con el repositorio empleando herramientas CASE integradas con él. En este libro, se utiliza un determinado número de términos distintos para hacer alusión al lugar de almacenamiento de la información de la ingeniería del software: base de datos CASE, base de datos del proyecto, base de datos de entorno de apoyo integrado a proyecto (EAIP), diccionario de requisitos (una base de datos limitada) y repositorio, Aunque existen sutiles diferencias entre algunos de estos términos todos ellos hacen referencia al centro de acumulación y almacenamiento.

El papel del repositorio en 1-CASE

El repositorio de un entorno 1-CASE es el conjunto de mecanismos y de estructuras de datos que consiguen la integración entre datos y herramientas, y entre datos y datos. Proporciona las funciones obvias de un sistema de gestión de bases de datos, pero, además, el repositorio lleva a cabo o precipita las funciones siguientes [FOR89b]:

(1)  Integridad de datos: incluye funciones para validar las entradas efectuadas en el repositorio, para asegurar la consistencia entre objetos relacionados, y para efectuar automáticamente modificaciones «en cascada» cuando un cambio efectuado en un objeto exige algún cambio en otros objetos relacionados con él

(2)  Información compartida: proporciona un mecanismo para compartir información entre múltiples desarrolladores y entre múltiples herramientas; gestiona y controla el acceso multiusuario a los datos, y bloquea/desbloquea objetos para que los cambios no se superpongan inadvertidamente

(3)  Integración datos-herramientas: establece un modelo de datos al que pueden acceder todas las herramientas del entorno 1-CASE; controla el acceso a los datos, y lleva a cabo las funciones de gestión de configuración adecuadas

(4)  Integración duros-datos: el sistema de gestión de bases de datos relaciona los objetos de datos de tal manera que se puedan alcanzar las demás funciones

(5)  Imposición de la metodología: el modelo E-R de datos almacenado en el repositorio puede implicar un paradigma específico de ingeniería del software; como mínimo, las relaciones y los objetos definen un conjunto de pasos que se llevará a cabo para construir el contenido del repositorio

(6)  Estandarización de documentos: la definición de objetos de la base de datos da lugar directamente a un enfoque estándar para la creación de documentos de ingeniería del software.

Para conseguir estas funciones, se define el repositorio en función de un metamodelo. El metamodelo determina la forma en que se almacena la información en el repositorio, la forma en que las herramientas pueden acceder a los datos y estos datos pueden ser visualizados por los ingenieros de software, el grado hasta el cual se puede mantener la seguridad e integridad de los datos, y la facilidad con que se puede ampliar el modelo ya existente para admitir nuevas necesidades [ WEL891.

El metamodelo es la plantilla en la cual se sitúa la información de ingeniería del software. Una descripción detallada de estos modelos va más allá del alcance de este libro. Para más información, el lector interesado podría consultar [WEL89], [SHA95] y [GRI95].

 

Características y contenidos

Las características y contenido del repositorio se entienden especialmente bien examinándolo desde dos perspectivas: ¿Qué es lo que hay que almacenar en el repositorio, y qué servicios específicos son los que proporciona el repositorio? En general, los tipos de cosas que habrá que almacenar en el repositorio incluyen:

• El problema que hay que resolver

• Información acerca del dominio del problema

• La solución del sistema a medida que va surgiendo

• Las reglas e instrucciones relativas al proceso de software (metodología) que se está siguiendo

• El plan del proyecto, sus recursos y su historia

• Información acerca del contexto organizativo.

En la Tabla 3 1.1 se ha incluido una lista detallada de tipos de representaciones, documentos y otros productos que se almacenan en el repositorio CASE. Un repositorio CASE robusto proporciona dos clases distintas de servicios:

(1)  los mismos tipos de servicios que puede uno esperar de cualquier sistema de gestión de bases de datos sofisticados;

(2)  servicios que son específicos del entorno CASE.

Muchos requisitos del repositorio son iguales a los de las aplicaciones típicas que se construyen tomando como base un sistema de gestión de bases de datos de comercial (SGBD). De hecho, muchos de los repositorios CASE actuales hacen uso de un SGBD (normalmente relaciona1 u orientado a objetos) como la tecnología de gestión de datos básica. Entre las características de un SGBD que dan soporte a la gestión de información de desarrollo del software se incluyen las siguientes:

• Almacenamiento de datos no redundante. Cada objeto es almacenado sólo una vez, aunque es accesible por todas las herramientas CASE siempre y cuando estas lo necesiten.

• Acceso de alto nivel. Se implementa un mecanismo común de acceso a los datos de tal modo que no sea preciso duplicar las funciones de gestión de datos en todas las herramientas CASE.

• Independencia de datos. Las herramientas CASE y las aplicaciones destino se aíslan del almacenamiento físico para que no se vean afectadas cuando la configuración del hardware se cambie.

• Control de transacciones. El repositorio implementa bloqueo de registros, admisiones de dos fases, registros de transacciones y procedimientos de recuperación para mantener la integridad de los datos cuando existen usuarios concurrentes.

• Seguridad. El repositorio proporciona mecanismos para controlar quién puede visualizar y modificar la información contenida en él.

• Consultas e informes de datos ad hoc. El repositorio permite acceder directamente a su contenido mediante una interfaz de usuario cómoda tal como SQL, o mediante un «navegador» (browser) orientado a formularios, haciendo posible un análisis definido por el usuario que va más allá de los informes estándar proporcionados por el conjunto de herramientas CASE.

• Apertura. Los repositorios suelen proporcionar un mecanismo de importación/exportación sencillo que hace posible las cargas o transferencias de información al por mayor.

• Soporte multiusuario. Un repositorio robusto deberá permitir que múltiples desarrolladores trabajen en una aplicación al mismo tiempo. Deberá gestionar el acceso concurrente a la base de datos mediante múltiples herramientas y por parte de múltiples usuarios, con arbitraje de accesos y con bloqueos en el nivel de archivos o registros. Para los entornos basados en redes, el soporte multiusuario implica también que el repositorio se podrá comunicar mediante interfaz con protocolos (agentes de solicitud de objetos) y servicios comunes de red.

El entorno CASE también efectúa demandas especiales con respecto al repositorio que van más allá de lo que está disponible directamente en un SGBD comercial. Entre las características especiales de los repositorios CASE se incluyen las siguientes:

Ø  Almacenamiento de estructuras de datos sofisticadas. El repositorio debe admitir tipos de datos complejos tales como diagramas, documentos y archivos, así como sencillos elementos de datos. Un repositorio también incluye un modelo de información (o metamodelo) que describe la estructura, relaciones y semántica de los datos almacenados en él. El metamodelo deberá poder ampliarse para dar cabida a representaciones nuevas y a una información organizativa única. El repositorio no solamente almacena modelos y descripciones de los sistemas en desarrollo, sino que los metamodelos asociados (esto es, una información adicional que describe la información de ingeniería del software en sí, tal como el momento en que se ha creado un componente de diseño concreto, su estado actual y la lista de componentes de los cuales depende).

Ø  Imposición de una integridad. El modelo de información del repositorio contiene también reglas, o políticas, que describen reglas de negocios válidas y otras restricciones y requisitos acerca de la información que se inserta en el repositorio (directamente o a través de una herramienta CASE). Es posible emplear un servicio llamado disparador para activar las reglas asociadas a un objeto siempre que este sea modificado, lo cual hace posible verificar la validez de los modelos de diseño en tiempo real.

Ø  Interfaz de herramientas ricas en términos semánticos. El modelo de información del repositorio (el metamodelo) contiene una semántica que hace posible que toda una gama de herramientas interpreten el significado de los datos almacenados en el repositorio. Por ejemplo, un diagrama de flujo de datos creado mediante una herramienta CASE se almacena en el repositorio en un formulario basado en el modelo de información e independiente de toda representación interna que pueda utilizar la herramientas en sí. Entonces otra herramienta CASE puede interpretar el contenido del repositorio y utilizar la información cuando la necesite para su tarea. De este modo, la semántica almacenada en un repositorio permite compartir datos entre una gran variedad de herramientas, a diferencia de las conversiones específicas entre herramientas, o entre «puentes».

Ø  Gestión de proceso y proyectos. Un repositorio contiene información no sólo acerca de la aplicación de software en sí, sino también acerca de las características de cada proyecto en particular, y del proceso general de la organización para el desarrollo del software (fases, tareas y productos). Esto abre posibilidades para la coordinación automatizada de la actividad de desarrollo técnico con la actividad de gestión del proyecto. Por ejemplo, la actualización del estado de las tareas de proyectos se podría efectuar de forma automática o bien como un producto derivado de la utilización de herramientas CASE. La actualización de estado resultará muy fácil para los desarrolladores, sin tener que abandonar el entorno de desarrollo normal. La asignación de tareas y consultas también se puede gestionar por correo electrónico. Los informes de problemas, las tareas de mantenimiento, las autorizaciones de cambios, y los estados de reparación se pueden coordinar y monitorizar mediante herramientas que acceden al repositorio.

Las siguientes características del repositorio son abarcadas todas ellas por la gestión de configuración del software. Se vuelven a examinar aquí para hacer hincapié en su interrelación con los entornos 1-CASE.

Ø  Versiones. A medida que avanza un proyecto, se irán creando muchas versiones de productos individuales. El repositorio deberá ser capaz de guardar todas estas versiones para hacer posible una gestión efectiva de las versiones de los productos y para permitir que los desarrolladores vuelvan a las versiones anteriores durante la comprobación y depuración. El repositorio CASE deberá ser capaz de controlar una amplia variedad de tipos de objetos entre los que se incluyen texto, gráficos, mapas de bits, documentos complejos y objetos Únicos como definiciones de pantalla y de informes, archivos de objetos, datos de comprobación y resultados. Un repositorio maduro rastrea las versiones de objetos con niveles arbitrarios de granularidad, por ejemplo, se puede rastrear cada definición de datos o agrupamiento de módulos. Para dar apoyo al desarrollo paralelo, el mecanismo de control de versiones deberá permitir múltiples derivados (variantes) a partir de un solo predecesor. Así pues, un desarrollador podrá estar trabajando al mismo tiempo, en dos soluciones posibles para un problema de diseño generadas las dos desde el punto de partida.

Ø  Seguimiento de dependencias y gestión de cambios. El repositorio gestiona una amplia variedad de relaciones entre los elementos de datos almacenados en él. Entre estas se cuentan las relaciones entre entidades y procesos de la empresa, entre las partes de un diseño de aplicación, entre componentes del diseño y la arquitectura de la información de la empresa, entre elementos de diseño y productos, etc. Algunas de las relaciones son meramente asociaciones, y algunas son dependencias o relaciones obligatorias. El mantenimiento de estas relaciones entre objetos de desarrollo se denomina administración de enlaces.

La capacidad de seguir la pista de todas estas relaciones es crucial para la integridad de la información almacenada en el repositorio y para la generación de productos basados en ella, y es una de las contribuciones más importantes que efectúa el concepto de repositorio para la mejora del proceso de desarrollo del software. Entre las muchas funciones que apoya la gestión de enlaces se cuenta la capacidad de identificar y estimar los efectos del cambio. A medida que los diseños evolucionan para satisfacer nuevos requisitos, la capacidad de identificar todos los objetos que podrían verse afectados hace posible una estimación más precisa del coste, del tiempo no operativo,

y del grado de dificultad. También se ayuda a evitar efectos colaterales que en caso contrario dan lugar a defectos y a fallos del sistema. La gestión de enlaces ayuda al mecanismo de repositorio para asegurar que la información del diseño sea correcta manteniendo sincronizadas las partes de un diseño. Por ejemplo, si se modifica un diagrama de flujo de datos, el repositorio puede detectar si los diccionarios de datos relacionados, definiciones de pantallas y módulos de códigos también requieren modificación y puedan llamar la atención del desarrollador los componentes afectados.

Ø  Seguimiento de requisitos. Esta función especial depende de la gestión de enlaces y proporciona la capacidad de hacer seguimiento de los componentes de diseño y de los productos derivados que proceden de una especificación de requisitos específica (seguimiento progresivo). Además, proporciona la capacidad de identificar cuáles son los requisitos que generaron cualquier producto derivado (seguimiento regresivo).

Ø  Gestión de configuración. Una función de gestión de configuración que trabaja muy cerca de las funciones de versiones y gestión de enlaces para hacer seguimiento de una serie de configuraciones que representarán hitos específicos del proyecto o de versiones de producción. La gestión de versiones proporciona las versiones necesarias, y la gestión de enlaces hace seguimiento de las interdependencias.

Ø  Seguimiento de auditoría. El seguimiento de auditoría establece información extra acerca de cuándo, por qué, y por quién son efectuados los cambios. La información acerca de las fuentes de las modificaciones se pueden introducir en forma de atributos de objetos específicos del repositorio. Un mecanismo disparador del repositorio resultará útil para solicitar al desarrollador o a la herramienta que esté utilizando que inicie la introducción de información de auditoría. (tal como la razón del cambio) siempre que se modifique un elemento de diseño.

Bibliografía:

Pressman .S. Roger. Ingeniería de Software. Un enfoque practico. Editorial McGraw-Hill V Edición. Pág. 559-571