CAPITULO 26 Reutilización del Software

26.1 ASUNTOS DE GESTIONUn rápido estudio de los posibles beneficios de la reutilización del software revelará que se puede ganar mucho más que con un simple ahorro de costes durante el desarrollo del producto del software. Los beneficios evidentes de la reutilización suelen verse superados por los problemas organizativos, por la carencia de una verdadera comprensión de la naturaleza de la reutilización del software, y por una estrategia débil o inexistente para impulsar e implementar la tecnología de reutilización.

26.1.1. Dificultades para la Reutilización.Existe un cierto número de dificultades para la reutilización del software. Con objeto de desarrollar una estrategia de reutilización efectiva, los administradores deben de entender cuales son estos problemas.1. La reutilización del software no es en absoluto un asunto «de la máxima prioridad» para muchas

firmas de software.2. Aun cuando existe un número creciente de fabricantes de software que venden en la actualidad

herramientas o componentes que proporcionan una asistencia directa para la reutilización del software, la mayoría de los desarrolladores de software no la utilizan.

3. La cantidad de entrenamiento disponible para ayudar a los ingenieros del software y a los administradores a comprender y a explicar la reutilización es relativamente escasa.

4. Hay muchos especialistas de software que siguen creyendo que la reutilización es «más problema que beneficio».

5. Hay muchas compañías que siguen apoyando las metodologías de desarrollo del software que no facilitan la reutilización, a la vez que desaniman a otras que parecen impulsar la reutilización del software.

6. Hay pocas compañías que proporcionen incentivos para producir componentes reutilizables de programas. Los administradores del proyecto hacen lo posible por realizar el trabajo con componentes de programa que sean tan específicos como sea posible.

26.1.2. Una analogía con el Hardware.La reutilización del software: Se puede reutilizar más que el código fuente. La reutilización del código es lo que produce las

ganancias menores de productividad y fiabilidad. Se alcanzan unos beneficios bastante mayores al reutilizar los diseños y la documentación asociada al «código fuente reutilizable».

La mayoría de los productos de software se pueden ensamblar a partir de componentes reutilizables.

Existen muchas métricas asociadas a la reutilización del software. Oscilan entre las métricas que miden la mera extensión del código fuente y de la documentación reutilizadas en una aplicación, hasta las métricas que miden los efectos de la reusabilidad del software.

La tecnología de la reutilización del software es ciertamente una colección de cosas (componentes reutilizables, las taxonomías, los sistemas de reusabilidad, los conceptos de composición, las metologías y otros más).

26.1.3. Algunas sugerencias para establecer un enfoque de la reutilización. 1. Establezca un plan interno para la reutilización del software.2. Imponga que la reutilización del software sea parte integrante de cualquier formación técnica y de

administración.3. Adquiera las herramientas y bibliotecas que contribuyan de la forma más positiva a la reutilización

del software.4. Impulse la utilización de métodos y herramientas de los cuales se haya demostrado que mejoran la

reutilización del software.

1

5. Siga y mida tanto la reutilización del software como el impacto de la reutilización del software.6. La administración debe hacer saber que impulsa de forma activa la reutilización del software.7. Reconozca que se pueden reutilizar más cosas que los simples «módulos». 8. Reconozca que la reutilización del software no es «negocios como de costumbre».

26.2. EL PROCESO DE REUTILIZACIONLa reutilización debería ser parte integrante de cualquier proceso de software. Es necesario comprender los «artefactos» que se reutilizan cuando se emplea la ingeniería del software.

26.2.1. Artefactos reutilizables.Artefactos que son candidatos para la reutilización:Planes de Proyecto. La estructura básica y gran parte del contenido de un plan de proyecto de software se podrán reutilizar entre proyectos sucesivos.Estimaciones de Coste. Dado que es frecuente implementar funciones similares en distintos proyectos, quizá sea posible reutilizar las estimaciones para esas funciones con pocas modificaciones o quizá ninguna.Arquitectura. Existen relativamente pocos programas y pocas arquitecturas de datos distintas, aun cuando se consideren distintos programas de aplicación.Especificaciones y Modelos de Requisitos. Los modelos y especificaciones de clases y objetos son candidatos evidentes para la reutilización. Los modelos de análisis desarrollados empleando enfoques convencionales de ingeniería del software también se pueden reutilizar.Diseños. Los diseños arquitectónicos, de datos, de interfaz y de procedimientos desarrollados empleando métodos convencionales son candidatos para la reutilización.Código fuente. Los componentes verificados de programa escritos en lenguajes de programación compatibles son candidatos para la reutilización.Documentación del Usuario y Técnica. Suele ser posible reutilizar grandes porciones de la documentación de usuario y técnica, aun cuando las aplicaciones específicas sean distintas.Interfaces Humanas. Siendo posiblemente el artefacto del software más ampliamente reutilizado, el software de IGU se reutiliza con frecuencia.Datos. Los datos abarcan las tablas internas, listas y estructuras de registros, así como los archivos y base de datos completas.Costos de Prueba. Siempre que es preciso reutilizar un diseño o un componente de código, el caso de prueba relevante deberá de estar «asociado» a él.

26.2.2. Un Modelo de Procesos.Se ha propuesto toda una gama de modelos de procesos para la reutilización. Cada uno de ellos hace hincapié en los rastros paralelos en los cuales la ingeniería de dominios se produce de forma concurrente con la ingeniería del software. La ingeniería del dominio efectúa el trabajo necesario para establecer un conjunto de artefactos de software que se puedan reutilizar por parte del ingeniero del software. Estos artefactos se transportan entonces a través de unos «límites» que separan la ingeniería del dominio de la ingeniería del software.

26.3. INGENIERIA DE DOMINIOSEl objetivo de la ingeniería de dominios consiste en identificar, construir, catalogar y diseminar un conjunto de artefactos de software que tienen aplicación en el software actual y existente, dentro de un determinado dominio de aplicación. El objetivo global consiste en establecer mecanismos que capaciten a los ingenieros de software para compartir estos artefactos durante su trabajo aplicados a sistemas nuevos o existentes. Incluye 3 actividades principales –análisis, construcción y diseminación

26.3.1. El Proceso de Análisis del Dominio.Los pasos del proceso se definían en la forma siguiente:1. Definir el dominio que hay que investigar.2. Categorizar los elementos extraídos del dominio.

2

3. Recoger una muestra representativa de las aplicaciones del dominio.4. Analizar cada aplicación de la muestra.5. Desarrollar un modelo de análisis para los objetos.

Prieto-Diaz expande el segundo paso de análisis del dominio indicado anteriormente y sugiere un enfoque de ocho pasos para la identificación y categorización de artefactos reutilizables:1. Seleccionar funciones y objetos específicos2. Abstraer las funciones y objetos3. Definir una taxotomia4. Identificar las características comunes5. Identificar las relaciones específicas6. Abstraer las relaciones7. Derivar un modelo funcional8. Definir un lenguaje del dominio.

El análisis del dominio es aplicable a cualquier paradigma de ingeniería del software, y que se puede aplicar tanto para el desarrollo convencional como para el desarrollo orientado a objetos. El lenguaje del dominio hace posible la especificación y posterior construcción de aplicaciones dentro del dominio.

26.3.2. Funciones de Caracterización.A veces resulta difícil determinar si un artefacto potencialmente reutilizable es realmente aplicable en una situación determinada. Para llevar a cabo esta determinación, es necesario definir un conjunto de características del dominio que serán compartidas por todo el software en el seno del dominio. Una característica del dominio define algún atributo genérico de todos los productos que existen dentro del dominio.

26.3.3. Modelado estructural y puntos de estructura.Cuando se aplica el análisis del dominio, el analista busca tramas repetidas en las aplicaciones que residen dentro del dominio. El modelado estructural es un enfoque de ingeniería basado en tramas que opera efectuando la suposición en que todo dominio de aplicación posee tramas repetidas (de función, datos y comportamiento), que tienen un potencial de reutilización.El modelado estructural es un artefacto arquitectónico que puede y debe de reutilizarse entre aplicaciones pertenecientes al dominio.Punto de estructura: es una estructura bien diferenciada dentro de un modelo estructural. Tienen tres características:1. Un punto de estructura es una abstracción que debe de tener un número limitado de instancias; es

decir que el tamaño de la jerarquía de clases debe ser pequeño.2. Las reglas que gobiernan la utilización del punto de estructura deben de comprenderse fácilmente.3. El punto de estructura debe de implementar el ocultamiento de información, ocultando toda la

complejidad que contenga.

Conjunto de tramas estructurales predecibles: Una interfaz que capacite al usuario para interactuar con el sistema. Un mecanismo de gestión de sensores que se comunica con todos los sensores empleados en la

monitorización. Un mecanismo de respuesta que reacciona frente a las entradas proporcionadas por el sistema de

gestión de sensores. Un mecanismo de control que capacita al usuario para controlar la forma en que se efectúa la

monitorización.

Puntos de estructura genéricos:

3

Aplicaciones cliente. La IGU, incluyendo todos los menúes, paneles y capacidades de entrada y edición de órdenes.

Bases de datos. El depósito de todos los objetos relevantes para el dominio de la aplicación. Motores de calculo. Los modelos numéricos y no numéricos que manipulan datos. Generación de informes. La función que produce salidas de todo tipo. Editores de aplicación. El mecanismo adecuado para personalizar la aplicación ajustándola a las

necesidades de usuarios específicos.

26.4. CONSTRUCCION DE COMPONENETES REUTILIZABLES.Los conceptos de diseño tales como la abstracción, el ocultamiento, la independencia funcional, el refinamiento y la programación estructurada, junto con los modelos orientados a objetos, las comprobaciones SQA y los métodos de verificación de corrección contribuyen todos a la creación de componentes de software reutilizables.

26.4.1. Análisis y diseño para la reutilización.Se analiza el modelo de análisis para determinar aquellos elementos del modelo que indican unos artefactos reutilizables ya existentes. El problema está en extraer información a partir del modelo de requisitos forma que pueda llevar a una «coincidencia de especificaciones».Las funciones de caracterización y las palabras reservadas se emplean como ayuda para hallar componentes reutilizables.Si la coincidencia de especificaciones produce componentes que se ajusten a las necesidades de la aplicación en cuestión, el diseñador puede extraer estos componentes de una biblioteca de reutilización (deposito) y puede utilizarlos para diseñar el nuevo sistema. Si esto no ocurre el ingeniero del software debe crearlos.Cuando el diseñador comienza a crear un nuevo componente, es cuando se debe considerar el diseño para la reutilización (DPR); el cual requiere que el ingeniero aplique sólidos conceptos y principios de diseño de software.

Asuntos que deben de considerarse como base del diseño para la reutilización: Datos estándar. Es preciso investigar el dominio de la aplicación e identificar las estructuras de

datos estándares globales. Protocolos de interfaz estándar. Se debería establecer tres niveles de protocolo de interfaz. La

naturaleza de las interfaces intramodulares, el diseño de interfaces técnicas y la interfaz hombre- máquina.

Plantillas de programa. El modelo de estructura puede servir como plantilla para el diseño arquitectónico de un nuevo programa.

Una vez que se han establecido los datos estándar, las interfaces y las plantillas de programa, el diseñador posee un marco de referencia en el cual puede crear el diseño.

26.4.2. Métodos de construcción.La construcción de artefactos reutilizables se basa en métodos de la ingeniería del software. Se puede efectuar empleando lenguajes convencionales de programación, de 3ra generación, de 4ta generación, generadores de código o herramientas más avanzadas. Un ejemplo de técnicas de construcción mas avanzadas se denomina tecnología de marcos, y el enfoque define un conjunto de componentes adaptables y genéricos llamados marcos, los cuales encapsulan datos y operaciones.Se construye una aplicación mediante el ensamblaje de componentes procedentes de una jerarquía de marcos. Los marcos que se encuentran en la parte inferior de la jerarquía contienen estructuras de datos y operaciones que efectúan funciones de sistema de bajo nivel (interacción con el SO, construcción de interfaces). Los marcos que se encuentran en el punto medio se centran en funciones relevantes para los dominios de sistemas de información específicos (bancos, servicios al cliente). En

4

la parte superior de la jerarquía se encuentra un «marco de especificación» que actúa como «el plano fundamental del sistema y el único cuadro que crea el desarrollador para definir el sistema».

26.4.3. Desarrollo basado en componentes.Cuando la reutilizacion predomina durante el desarrollo de una aplicación, el enfoque de construcción suele conocerse con el nombre de desarrollo basado en componentes o software por componentes. Algunos de estos componentes reutilizables se desarrollan en la propia empresa, otros se pueden extraer de aplicaciones existentes y otros se pueden adquirir con otros fabricantes.Para implementar el desarrollo basado en componentes debería de estar presente un conjunto de cuatro «ingredientes arquitectónicos»: Un modelo de intercambio de datos. Se trata de mecanismos que capaciten a los usuarios y a las

aplicaciones para interactuar y transferir datos (ej. arrastrar y soltar, cortar y pegar). No solamente permiten la transferencia de datos entre hombre y programa y entre componentes, también hacen posible la interacción entre recursos del sistema.

Automatización. Debería de estar implementada toda una gama de herramientas, marcos y guiones que faciliten la interacción entre componentes reutilizables.

Almacenamiento estructural. Los datos heterogéneos (datos gráficos, voz, texto y numéricos) contenidos en un «documento compuesto» deben estar organizados y debe ser posible acceder a ellos como so se tratase de una sola estructura de datos.

Modelo de objetos subyacente. Asegura que los componentes desarrollados en distintos lenguajes de programación que residan en distintas plataformas puedan ser interoperables (esto es, los objetos deben ser capaces de comunicarse a través de la red). Para lograr esto, el modelo de objetos define un estándar para la interoperabilidad de componentes, el cual es independiente del lenguaje y se define empleando un lenguaje de definición de interfaz (LDI).

Dado que el posible impacto de la reutilización sobre la industria del software es enorme, un cierto número de compañías importantes y de consorcios industriales han propuesto unos estándares para el software por componentes:

OpenDoc: Un consorcio de grandes compañias técnicas (IBM, Apple Y Novell) ha propuesto el estándar OpenDoc para documentos compuestos y software por componentes. El estandar define los servicios, infraestructura de control, y arquitectura que es preciso implementar para hacer posible que los componentes proporcionados por un desarrollador interoperen con componentes porporcionados por otro desarrollador.

OMG/CORBA: el Object Management Group ha publicado una arquitectura común de solicitudes de objetos. Los distribuidores de solicitudes de objetos (ORB) proporcionan toda una gama de servicios que hacen posible que los componentes reutilizables se comuniquen con otros componentes, independientemente de su ubicación dentro del sistema.

Ole 2.0. Microsoft ha desarrollado un modelo de componentes de objetos (COM) que proporciona una especificación para utilizar objetos producida por distintos fabricantes dentro de una misma aplicación.

26.5. CLASIFICACION Y RECUPERACION DE COMPONENTES.26.5.1 Descripción de componentes reutilizables.Un componente de software reutilizable se puede describir de muchas formas, pero la descripción ideal abarca concepto, contenido y contexto.El concepto de un componente de software es «una descripción de lo que hace el componente». Se describe por completo la interfaz con el componente. Se debe comunicar la intención del componente.El contenido de un componente describe la forma en que se construye el concepto. Es una información que queda oculta a los ojos del usuario habitual y que solamente necesita conocer quien intente modificar ese componente.

5

El contexto, mediante la especificación de características conceptuales, operacionales y de implementación, capacita al ingeniero del software para hallar el componente adecuado para satisfacer los requisitos de la aplicación.Para que resulte útil, el concepto, el contenido y el contexto tienen que traducirse a un esquema de especificación concreto.

La gran mayoría de los esquemas de clasificación para los componentes de software caen dentro de tres categorías:Clasificación enumerada. Se describen los componentes mediante la definición de una estructura jerárquica en la cual se definen clases y diferentes niveles de subclases de componentes de software. Los componentes en sí se enumeran en el nivel mas bajo de cualquier ruta de la jerarquía enumerada.Clasificación por facetas. Se analiza un cierto área de dominio y se identifica un conjunto de características descriptivas básicas, llamadas facetas; las cuales reciben diferentes prioridades según su importancia, y se relacionan con un componente. La faceta puede describir la función que lleva a cabo el componente, los datos que se manipulan, el contexto en que se aplican, o cualquier otra característica. El conjunto de facetas que describen un componente se denomina descriptor de facetas.El esquema de clasificación por facetas es mas fácil de extender y de adaptar que el enfoque de enumeración.Clasificación de atributos y valores. Se define un conjunto de atributos para todos los componentes de una cierta zona de dominio. Luego se asignan valores a estos atributos de forma uy parecida a una clasificación por facetas. De hecho, la clasificación de atributos y valores se diferencia a la clasificación por facetas en: (1) no hay limite para el número de atributos que se pueden utilizar; (2) no se asignan prioridades a los atributos.

26.5.2. El entorno de reutilizaciónLa reutilización de componentes de software debe de estar apoyada por un entorno que abarque los siguientes elementos: Una base de datos de componentes capaz de almacenar componentes de software, así como la

información de clasificación necesaria para recuperarlos. Un sistema de gestión de bibliotecas que proporcione acceso a la base de datos. Un sistema de recuperación de componentes de software que permita que la aplicación cliente

recupere los componentes y servicios del servidor de la biblioteca. Unas herramientas CASE que presten su apoyo a la integración de componentes reutilizados en un

nuevo diseño o implementación.Cada una de estas funciones interactúa con una biblioteca de reutilización o bien se encuentra incorporada a ella.La biblioteca de reutilización abarca una base de datos y las herramientas necesarias para consultar esa base de datos y recuperar de ella componentes. Posibilita el almacenamiento de una amplia gama de artefactos reutilizables (ej. especificación, diseño, casos de prueba, guías para el usuario).

26.6. ECONOMIA DE LA REUTILIZACION DEL SOFTWARE.La economía de la reutilización del software debería de proporcionar a las organizaciones de software ventajas notables en lo que se refiere a la calidad y a tiempos de realización. Estas, a su vez, deberían de traducirse en unos ahorros de costes.

26.6.1. Impacto sobre la calidad, la productividad y el coste.Existen evidencias que indican que es posible obtener notables beneficios de negocios mediante una reutilización agresiva del software. Mejoran la calidad del producto, la productividad del desarrollador, y los costes en general.Calidad. Un componente del software que se desarrolle para su reutilización estará verificado y no contendrá defectos. En realidad, la verificación formal no se lleva a cabo en forma rutinaria; ya que con cada reutilización, los defectos se van hallando y van siendo eliminados, y como consecuencia

6

mejora la calidad del componente. Con el tiempo, el componente llega a estar virtualmente libre de defectos.Productividad. Cuando se aplican artefactos reutilizables se invierte menos tiempo creando los planes, modelos, documentos, códigos y datos necesarios para crear un sistema fiable.Se proporciona un mismo nivel de funcionalidad al cliente con menos esfuerzo; mejora la productividad.Coste. El ahorro de costes para la reutilización se estima proyectando el coste del proyecto si se hubiera desarrollado este desde cero, y restando después la suma de los costes asociados para la reutilización, y el coste actual del software cuando este finalmente se implanta.

Los costes asociados a la reutilización incluyen:

Modelado y análisis del dominio Desarrollo de la arquitectura del dominio Incremento de la documentación para facilitar la reutilización Mantenimiento y mejora de artefactos de la reutilización Licencias para componentes adquiridos externamente Creación o adquisición y funcionamiento de un depósito para la reutilización Formación del personal en el diseño y construcción para la reutilización.

26.6.2. Análisis de coste empleando puntos de estructura.El diseñador del software puede desarrollar una arquitectura para una nueva aplicación, sistema o producto mediante la definición de un arquitectura del dominio y probándola entonces con puntos de estructura (una trama arquitectónica que aparece repetidamente en el seno de un determinado dominio). Estos puntos de estructura son componentes reutilizables individuales o paquetes de componentes reutilizables.Como todos los puntos de estructura poseen una historia pasada, es posible recoger datos de costes para cada uno de ellos. Los costes de adaptación, integración y mantenimiento asociados a los componentes de una biblioteca de reutilización se mantienen para cada caso de utilización. Así es posible analizar estos datos para desarrollar una estimación de costes para el próximo caso en que se utilicen.

26.6.3. Métricas de reutilización

Se ha desarrollado toda una gama de métricas de software en un intento de medir los beneficios de la reutilización en un sistema basado en computadoras. Los beneficios asociados a la reutilización dentro de un sistema S se pueden expresar como el siguiente cociente:

R b(S) = (C sin reutilización – C con reutilización) / C sin reutilización

C= coste

7