Load Balancing and Processor Assignment

Un Modelo en Ingeniería de software es “una descripción simplificada de un proceso de software que presenta una visión de ese proceso” (Sommerville, Ibíd: 8). Puede incluir actividades que son parte de los procesos y productos de software y el papel de las personas involucradas en la ingeniería de software, siendo los más usados: a) el enfoque en cascada; b) desarrollo iterativo y c) ingeniería de software basada en componentes.

Dados los requerimientos planteados por el proyecto, el modelo seleccionado para el desarrollo de PEPE concuerda con la Ingeniería de Software Basada en Componentes (ISBC), funcionando en la filosofía cliente-servidor que se ajusta a casi todos los sistemas que basan su funcionamiento en la Web y que deben basar su funcionamiento en los estándares de Internet. La ISBC es definida por Pressman (Op. cít: 473) como “un proceso que se centra en el diseño y construcción de sistemas basados en computadora que utilizan «componentes» de software reutilizables”. A su vez, un componente es definido por Council y Heineman (2001) como “un elemento de software que se ajusta a un modelo de componentes y que puede ser desplegado y compuesto en forma independiente sin modificación según un estándar de composición”. Funcionando bajo el esquema cliente- servidor, tanto los servicios como la información de los sistemas residen en un computador remoto (servidor), mientras que los clientes desde su computador local se comunican con el servidor para requerir los servicios que tiene habilitados. Toda la teoría y conocimientos técnicos necesarios que sustentan el desarrollo de PEPE no son menores, considerando la complejidad que involucra la implementación del Modelo ISBC y dentro de este Modelo la conexión de los componentes seleccionados para su integración. Para simplificar su comprensión, la ISBC se puede comparar con la instalación de un equipo musical al cual se le pueden conectar componentes de diferentes origen como los parlantes, el amplificador, el receptor, el reproductor de audio, video, radio, etc., , lo cual no resulta ser tan evidente cuando se trata de componentes de software. De acuerdo a los definido por Pressman (Op. Cít: 473), “la ISBC acompaña a dos actividades de ingeniería paralelas: la ingeniería del dominio y el desarrollo basado en componentes”, cuya interrelación se muestra en la Figura 1. La ingeniería del dominio explora un dominio de aplicaciones con la intención de encontrar específicamente los componentes de datos funcionales y de comportamiento candidatos para la reutilización. Continúa Pressman, indicando que “el desarrollo basado en componentes obtiene los requisitos del cliente y selecciona el estilo arquitectónico adecuado para cumplir los objetivos del sistema que se va a construir, y a continuación: (1) selecciona posibles componentes para la reutilización; (2) cualifica los componentes para asegurarse de que encajan adecuadamente en la arquitectura del sistema; (3) adapta los componentes si se deben hacer modificaciones para poderlos integrar adecuadamente; (4) integra los componentes para formar subsistemas y la aplicación completa. Además, los componentes personalizados se han diseñado para afrontar esos aspectos del sistema que no pueden implementarse utilizando componentes que ya existen”.

Figura 1: Un Modelo de proceso de soporte a la ISBC

Fuente: (Christensen, 1995).

La Figura 1 ilustra un modelo de proceso típico que acopla la ISBC explícitamente (Christensen, 1995). “La ingeniería del dominio crea un modelo de dominio de aplicación que se utiliza como base para analizar los requisitos del usuario en el flujo de la ingeniería del software. Una arquitectura de software genérica (y los puntos de estructura correspondientes), proporciona la entrada para el diseño de la aplicación. Finalmente, después de que se han comprado los componentes reutilizables, se han seleccionado a partir de las bibliotecas existentes o se han construido (como parte de la ingeniería del dominio), los ingenieros del software dispondrán de ellos durante la actividad de desarrollo basada en componentes”.

El producto de la ISBC es el software operacional ensamblado utilizando los componentes de software existentes y los que se acaban de desarrollar, pudiéndose verificar su funcionamiento utilizando las mismas prácticas que se aplican en todos los procesos de ingeniería del software (las revisiones técnicas formales evalúan los modelos de análisis y diseño): las revisiones especializadas tienen en consideración temas asociados con los componentes adquiridos; y la comprobación se aplica para descubrir errores en el software nuevo y en componentes reutilizables que se hayan integrado en la arquitectura.

En la generación del producto final, sin duda que es vital la experiencia de los ingenieros, pero además se deben tener en cuenta las características que deben presentar los componentes. El hecho de que sean independientes y posteriormente sean parte de la composición fundamental de un sistema, obligan a que sus definiciones sean formales, como condición básica para su selección. La Tabla Nº 3, resume las principales características que deben presentar para ser seleccionables, puesto que la carencia de algunos de estos atributos puede influir notoriamente en el producto final (Sommerville, Op. cít: 405).

Tabla Nº 3: características formales deseables en un componente

Característica de los componentes

Descripción

Estandarizado La estandarización de componentes significa que un componente usado en un proceso de ISBC tiene que ajustarse a algún modelo estandarizado de componentes. Este modelo puede definir interfaces de componentes, metadatos de componentes, documentación, composición y despliegue.

Independiente Un componente debería ser independiente, debería ser posible componerlo y desplegarlo sin tener que usar otros componentes específicos. En las situaciones en las que el componente necesita servicios proporcionados externamente, estos deberían hacerse explícitos en una especificación de interfaz del tipo “requiere”. Componible Para que un componente sea componible, todas las interacciones externas deben dar

lugar a interfaces definidas públicamente. Además debe proporcionar acceso externo a la información sobre sí mismo, como por ejemplo a sus métodos y atributos. Desplegable Para ser desplegable, un componente debe ser independiente y debe ser capaz de

funcionar como una entidad autónoma o sobre una plataforma de componentes que implemente el modelo de componentes. Esto normalmente significa que el componente es binario y que no tiene que compilarse antes de ser desplegado. Documentado Los componentes tienen que estar completamente documentados para que los

usuarios potenciales puedan decidir si los componentes satisfacen o no sus necesidades. La sintaxis e, idealmente, la semántica de todas las interfaces de componentes tienen que ser especificadas.