Contexto


Imagina que necesitas tener un automóvil. Entonces decides construirlo. Comienzas por las ruedas, los ejes, el cigüeñal, continúas con el motor: la cámara de combustión, los cilindros, las bujías, etc.; prosigues por los interiores: los asientos, el tablero, y así sucesivamente hasta completar cada parte del automóvil. ¿Te imaginas cuánto tardaremos en diseñarlo y después en construirlo?

Si en lugar de empezar a diseñar y construir tu automóvil desde cero, decides comprar las partes que conformarán tu auto. Entonces podrías ir a una refaccionaria o un negocio que ofrece partes de autos y ensamblas cada pieza hasta terminar de construir el auto, posiblemente terminarás tu auto en menos tiempo.

El diseño de software basado en componentes es parecido a construir un sistema sin tener que empezar desde abajo, es decir, permite aprovechar la reutilización de módulos prefabricados que puedas tomar cada vez que requieras, y si acaso no encuentras el componente que necesitas, crearías uno con la idea de hacerlo reutilizable en caso de que en un futuro requieras de ese componente.


  • ¿Qué características deben tener los componentes para poder ser reutilizables?
  • ¿Qué proceso se sigue para generar un diseño por componentes?
  • ¿Dónde buscar componentes que puedas necesitar para agilizar el desarrollo de software?

Explicación

12.1. Características de los componentes


En todo diseño basado en componentes deben existir dos características que permiten establecer la capacidad que tiene cada componente de interactuar entre sí: la cohesión y el acoplamiento.

Cohesión

Según Pressman (2010), la cohesión es la relación que mantienen los componentes o clases a través de sus atributos y operaciones.

Existen tres tipos de cohesión que ofrecen la ventaja de facilitar su implantación, verificación y mantenimiento:

Haz clic en cada concepto para conocer más detalle.

Funcional

La cohesión funcional aparece cuando un método de un componente ayuda a generar un resultado a través de un cálculo.

De capa

Este tipo de cohesión aparece cuando es posible que un componente pueda acceder a los servicios de componentes de niveles jerárquicos bajos, sin embargo, no puede acceder a servicios de componentes superiores. Este tipo es bastante útil cuando se trata de componentes con acceso a seguridad.

De comunicación

Todas las operaciones que acceden a los mismos datos se deben definir dentro de una clase.


Acoplamiento

Para Pressman (2010), el acoplamiento es “la medición cuantitativa del grado en el que las clases se conectan una con otra”. Entre más interdependientes se vuelvan los componentes, mayor será el acoplamiento. Es además una característica inevitable en el desarrollo de software, ya cualquier módulo debe interactuar en mayor o menor medida con otros componentes, ya sean internos o externos al desarrollo.

Las clases de acoplamiento son las siguientes:

Haz clic en cada concepto para conocer más detalle.


De contenido

Este tipo de acoplamiento aparece cuando un componente modifica datos internos de otro componente.

Común

Se genera un acoplamiento común cuando varios componentes utilizan variables comunes, también llamadas variables globales, lo que provoca que al modificarla un componente puede introducir defectos en otro que suelen ser difíciles de detectar en las pruebas.

Del control

Surge cuando un componente pasa el control de una función a otra. Si existe algún cambio, es necesario que se verifique que el control no se pierda entre las funciones.

De externo

Aparece cuando un componente interactúa con otros componentes relacionados con la infraestructura (funciones del sistema operativo, bases de datos, telecomunicaciones). Para evitar la complejidad y dependencia del sistema, Pressman (2010) recomienda limitar el número de componentes o clases.


Según Sommerville (2011), citando a Szyperski, los componentes de software deben contar con las siguientes características esenciales:

Característica

Descripción
Estandarizado
Un componente debe ajustarse a un modelo de componentes estándar. Este modelo puede definir interfaces de componentes, metadatos de componentes, documentación, composición e implementación.
Independiente Debe ser factible construirlo e implementarlo sin usar otros componentes específicos.
Componible Todas las interacciones externas deben tener lugar mediante interfaces definidas públicamente.
Implementable Debe ser capaz de ejecutarse como entidad independiente (autocontenido) que permita una implementación del modelo de componentes.
Documentado Los componentes deben documentarse por completo, para que los usuarios potenciales puedan decidir si los componentes cumplen o no sus necesidades.

12.2 Pasos del diseño a nivel componente

El diseño por componentes lleva un proceso que ayuda a transformar los requerimientos del cliente en detalles que sirven de guía para la construcción del software.

Pressman (2010) explica este proceso a través de los siguientes pasos:

Haz clic en cada concepto para conocer más detalle.

Paso 1

Identificar todas las clases de diseño que correspondan al dominio del problema.

A partir de la documentación generada del análisis se pueden complementar las clases que fueron identificadas.

Paso 2

Identificar todas las clases de diseño que correspondan al dominio de la infraestructura.

Las clases que pertenecen a la infraestructura tienen que ver con funciones externas al sistema, pero es importante considerarlas porque son necesarias para dotar de diferentes servicios al sistema. Por ejemplo, si un componente necesita guardar un archivo, puede utilizar las clases que administran los archivos y hacer uso de sus operaciones.

Paso 3

Elaborar todas las clases de diseño que no sean componentes reutilizables.

Paso 3a. Especificar detalles del mensaje cuando colaboren clases o componentes.
Paso 3b. Identificar interfaces apropiadas para cada componente.
Paso 3c. Elaborar atributos y definir tipos y estructuras de datos requeridos para implantarlos.
Paso 3d. Describir en detalle el flujo del procesamiento dentro de cada operación.

El diseño debe detallar el contenido de las clases (atributos y métodos) y otros elementos que ayudan al acoplamiento y a la cohesión de los componentes (interfaces) que en muchas ocasiones no son reutilizables, pero sí son necesarios para solucionar un problema del dominio del sistema.

Las estructuras de los datos pueden ser tomadas del diccionario de datos. Pressman (2010) sugiere utilizar la siguiente nomenclatura:

nombre : tipo-de-expresión = valor-inicial {cadena de propiedades}

Donde:
nombre= nombre del atributo.
tipo-de-expresión= escribe el tipo de datos (cadena, numérico, fecha).
valor-inicial = valor que toma el atributo cuando se crea el objeto.
Cadena de propiedades= define una propiedad o característica del atributo.

Ejemplo:
TipodeCliente : cadena = “A” {contiene 1 de 3 valores: A=Premium, B=Golden, C=Platinum}

Para describir el flujo de procesamiento se utiliza el diagrama UML de actividades, que incluye la secuencia de pasos para arrojar un resultado esperado. Aunque no en todos los casos es necesario incluirse, el algoritmo puede aclarar procesamiento de datos complejos, incluso sirve para generar un pseudocódigo para la etapa de construcción. Observa en el siguiente diagrama que el cálculo del costo por página depende del tamaño y del color.

Diagrama de actividades UML para calcular “CostodelPapel()”.
Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.
Fig. 10.8, Pág. 249.
Sólo para fines educativos.

Paso 4

Describir las fuentes persistentes de datos (bases de datos y archivos) e identificar las clases requeridas para administrarlos.

En este paso se describen las bases de datos y archivos que serán utilizados en el diseño. Por lo general el diseño de la base de datos es una actividad particular del arquitecto de bases de datos, quien toma como base el diccionario de datos y la estructura de datos para crear las tablas, atributos, campos, índices y accesos necesarios que mantendrán la integridad y consistencia a la información del sistema.

Paso 5

Desarrollar y elaborar representaciones del comportamiento para una clase o componente.

En este paso se modelan o se complementan los componentes que representan comportamientos del sistema y que fueron desarrollados en la fase de Análisis del ciclo de vida del desarrollo. Será necesario que el diseñador o arquitecto del sistema tome en cuenta los casos de uso documentados que proporcionan detalles sobre el comportamiento del sistema. Entre las herramientas que puedes utilizar están los diagramas estado, acompañados de un diccionario de estados con la siguiente nomenclatura:

nombre-del-evento (lista de parámetros) [guardar-condición] / expresión de acción

Donde:
nombre-del-evento= identifica al evento.
lista de parámetros= datos asociados con el evento.
guardar-condición = especifica la condición que habrá de cumplirse para disparar el evento.
expresión de acción = acción que ocurre a medida que cambia de estatus.

Ejemplo:
EntradadeDatosTerminada (todos los datos son consistentes) / MostrarOperaciones del usuario

Diagrama de estado.
Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.

Paso 6

Elaborar diagramas de despliegue para dar más detalles de la implantación. Estos diagramas permiten ubicar las partes del software en la arquitectura física, lo cual es bastante útil para el equipo técnico y para determinar las características y capacidades del hardware y el sistema operativo.

Paso 7

Rediseñar cada representación del diseño en el nivel de componentes y siempre considerar alternativas. Este paso permite introducir en el diseño un mecanismo de mejora continua y depuración, además de tener la finalidad de ajustar características del software mientras se encuentra en el proceso de diseño.

12.3 Desarrollo basado en componentes

Una de las metas del desarrollo basado en componentes es la reutilización, es decir, tomar diseños y código que alguna vez fueron creados e implementados de forma exitosa, permitiendo mejorar los tiempos de entrega de los proyectos de sistemas.

Sería parecido a ir a un supermercado para comprar lo que necesitas para cocinar tu desayuno. Pasas por los pasillos buscando aquellos elementos que consideras que son ideales y los echas en tu carrito de compras.

Esa es justamente una de las ventajas de la reutilización, tomar componentes prefabricados para conformar el sistema.

Ingeniería del dominio

“El objetivo de la ingeniería del dominio es identificar, construir, catalogar y diseminar un conjunto de componentes de software que sean aplicables al software existente y al del futuro en un dominio particular de aplicaciones” (Pressman, 2010).

En otras palabras, la ingeniería del dominio permite contar con información relacionada a los componentes que puedes reutilizar en un desarrollo de sistemas, algo así como tener una sección amarilla en la que puedes encontrar diferentes servicios agrupados en categorías.

Según Pressman (2010), las actividades principales de la ingeniería del dominio consisten en el análisis, construcción y diseminación.

Haz clic en cada concepto para conocer más detalle.

Análisis

En el análisis se realizan las siguientes acciones:

  1. Definir el dominio que se va a investigar.
  2. Clasificar los aspectos extraídos del dominio.
  3. Reunir una muestra representativa de aplicaciones en el dominio.
  4. Analizar cada aplicación en la muestra y definir clases de análisis.
  5. Desarrollar un modelo de requerimientos para las clases.
Construcción

En la construcción se elaboran:

  1. Una biblioteca de componentes que pueden ser reutilizables. Los componentes pueden ser fabricados de forma interna, de aplicaciones existentes o de proveedores externos.
  2. Clasificación de los componentes, que servirá para ubicar fácilmente los componentes a reutilizar. Entre los elementos a clasificar están los siguientes:
    1. Las API necesarias (Aplicación de programación de la interfaz).
    2. Herramientas de desarrollo e integración que requiere el componente.
    3. Requerimientos técnicos como memoria, velocidad, protocolo de comunicación, interfaces con el sistema operativo.
    4. Características de seguridad (autenticación y listas de controles de acceso).
    5. Manejo de excepciones.
  3. Adaptación de componentes que consiste en determinar lo siguiente:
    1. Cómo implementar métodos consistentes.
    2. Cómo administrar datos comunes.
    3. Cómo implementar interfaces internas y externas al sistema.
  4. Combinación de componentes consisten en ensamblar componentes clasificados y adaptados a una arquitectura establecida. Para ello es posible utilizar estándares propuestos por compañías y organizaciones no lucrativas del software. Los estándares que predominan son los siguientes: GAO / ATOCS, Componentes JavaBeans de Sun, MCO de Microsoft y .NET
Diseminación

Durante la etapa de diseminación se requiere

Poner a disposición del equipo técnico la biblioteca de componentes. Según Pressman (2010), es necesario contar con un ambiente propicio para poder integrarlos y recuperar los componentes que se requieran. Este ambiente debe tener las siguientes características:

  1. Tener una base de datos que pueda almacenar los componentes de software y la información de su clasificación para poder recuperarlos.
  2. Un sistema de administración de la biblioteca con acceso a la base de datos.
  3. Un sistema de recuperación de componentes de software.
  4. Herramientas de ISBC (Ingeniería de software basado en componentes) que apoyen a la integración de componentes reutilizados en un diseño o implantación de nuevos.

Modelo 3C

Tracz (1995) ideó una forma muy sencilla de describir a los componentes para poder reutilizarlos con facilidad, que llamó el modelo 3C: concepto, contenido y contexto.


  • Concepto: describe lo que hace un componente, el objetivo que persigue, las interfaces que utiliza, sus condiciones previas y posteriores.
  • Contenido: describe detalles del procedimiento que realiza para generar el resultado esperado. Esto suele ser bastante útil sobre todo con componentes a los que no se puede tener acceso a su código de implementación.
  • Contexto: explica el dominio en el que puede ser aplicado. Describe las características de concepto, operación y de implantación, con el objetivo de darle información al ingeniero de software para que encuentre el componente que está buscando.

Este modelo puede ser incorporado a la biblioteca de componentes reutilizables como parte de los metadatos de cada componente, que puedan ser utilizados para generar búsquedas más finas sobre sus características.

Cierre

El diseño basado en componentes ofrece grandes ventajas a los desarrollos de sistemas que se espera crezcan a través del tiempo y reducen el tiempo de entrega.

Así, si se diseña un software para ayudar a operar las bombas de combustible de una gasolinera, es muy probable que este mismo software sea la base para operar un consorcio de gasolineras, agregando otros componentes dedicados a dar servicio a las diferentes áreas del negocio.

Una compañía de software podría generar una biblioteca de componentes reutilizables conforme construye sistemas para un dominio específico. Estos componentes podrían ayudar a otros proyectos siempre y cuando se analicen las condiciones e interfaces que requieren para hacer funcionar cada componente.

Generar código que pueda ser reutilizable es una tarea que requiere un mayor esfuerzo por parte del programador, sin embargo, los beneficios de reducción del tiempo que trae consigo serían razón suficiente para hacerlo; por otro lado, los lenguajes de programación de última generación permiten utilizar extensas librerías con clases que pueden ser integradas al código fácilmente.

Checkpoint

Asegúrate de poder:

  • Aplicar los principios del diseño basado en componentes para sacarle provecho a la reusabilidad del software.
  • Conocer el proceso que sigue la elaboración de componentes para el diseño de software.
  • Analizar las características de una biblioteca de componentes que sirven para reutilizar componentes que ya fueron implementados con éxito en algún momento.

Referencias

  • Pressman, R. (2010). Ingeniería de Software. Un enfoque práctico (7ª ed.). México: McGraw Hill.
  • Sommerville, I. (2011). Ingeniería de Software (9ª ed.). México: Pearson.
  • Tracz, W. (1995). Third International Conference on Software Reuse – Summary. ACM Software. Engineering Notes. Vol. 20, Núm. 2. pp. 21-22.

Glosario

Dominio: un dominio del software representa a todos los aspectos del problema a resolver.

Interfaz: es el equivalente a una clase abstracta dado que no contiene una estructura interna, ni atributos ni asociaciones, que provee una conexión controlada entre las clases.