10.Diseño en el nivel de Componentes

Ramiro Estigarribia Canese

¿Qué es el diseño a nivel de componentes?El diseño en el nivel de componentes define las estructuras de datos, algoritmos y mecanismos de comunicación asignados a cada componente del software.Antes de elaborar el software, tenemos que ser capaces de determinar si funcionará. ➔ Se busca garantizar la corrección y la consistencia

con otras representaciones del diseño. ➔ Esto proporciona un medio para evaluar si

funcionarán las estructuras de datos, interfaces y algoritmos.

¿Qué es un Componente?Un componente es un bloque de construcción de software. La Especificación UML define un componente como: “Es una parte modular, desplegable y sustituible de un sistema, que incluye la implantación y expone un conjunto de interfaces”.

Los componentes juegan un papel importante en el éxito del sistema que se va a construir.

Visión Orientada a Objetos➔ Un componente contiene un conjunto de clases que

colaboran. ➔ Cada clase dentro de un componente se elabora

por completo para que incluya todos los atributos y operaciones relevantes para su implantación.

➔ También deben definirse todas las interfaces que permiten que las clases se comuniquen y colaboren.

➔ Para lograr esto, se elaboran clases de análisis y clases de infraestructura.

MódulosSe conoce como módulo a una estructura o bloque de piezas que, en una construcción, se ubican a fin de hacerla más sencilla.

Tienen tres funciones importantes:1. Coordina la invocación de los componentes del

dominio del problema.2. Implanta una necesidad que requiere el cliente.3. Es responsable de las funciones que dan apoyo al

procesamiento requerido en el dominio del problema.

Ejemplo: Sistema de Imprenta.Considere un software que debe elaborarse para una imprenta.El objetivo es obtener los requerimientos que plantea el cliente en el mostrador, presupuestar un trabajo de impresión y después pasar éste a una instalación automatizada de producción.En la próxima figura: cada rectángulo representaun componente del software. Cada operación se representa como módulo aisladoque se invoca como se indica en la figura. Para controlar el procesamiento se utilizan otrosmódulos, por lo que son componentes de control.

Sistema de Imprenta.

Diagrama de componentes: ‘Compute Page Cost’.El comportamiento del módulo se representa con un diagrama de estado. Para ilustrar este proceso, considere el módulo ‘Compute Page Cost’. El objetivo de este módulo es calcular el costo de impresión por página con base en las especificaciones dadas por el cliente. Los datos requeridos para realizar esta función son: número de páginas en el documento, número total de documentos que se va a producir, impresión por uno o dos lados, color y tamaño. El costo por página es inversamente proporcional al tamaño del trabajo y directamente proporcional a su complejidad.

Diagrama de componentes: ‘Compute Page Cost’.Página

Reutilización de Componentes.➔ En las últimas dos décadas, la comunidad de la

ingeniería de software ha puesto el énfasis en la necesidad de elaborar sistemas que utilicen componentes ya existentes.

➔ En esencia, a medida que avanza el trabajo de diseño se dispone de un catálogo de diseño probado o de componentes en el nivel de código.

➔ Como estos componentes fueron construidos teniendo en mente lo reutilizable, se dispone totalmente de la descripción de su interfaz, de las funciones que realizan y de la comunicación y colaboración que requieren.

Principios básicos del diseñoHay cuatro principios básicos que son aplicables al diseño en el nivel de componentes y que hansido ampliamente aceptados para la aplicación de la ingeniería de software orientada a objetos:

La motivación para aplicar estos principios es crear diseños que sean más factibles de cambiar, así como reducir la propagación de efectos colaterales cuando se hagan cambios.Estos principios pueden usarse como guía cuando se desarrolle cada componente del software.

1.Principio Abierto-Cerrado (PAC).“Un módulo [componente] debe ser abierto para la extensión pero cerrado para la modificación” [Mar00]. Este enunciado parece ser una contradicción,pero representa una de las características más importantes de un buen diseño en el nivel de componentes. Dicho en pocas palabras, debe especificarse el componente en forma tal que permita extenderlo (dentro del dominio funcional a que está dirigido) sin necesidad de hacerle modificaciones internas (en el nivel del código o de la lógica). Para lograr esto, se crean abstracciones que sirven como búfer entre la funcionalidad que sea probable extender y la clase de diseño en sí.

Ejemplo: Sistema Casa SeguraLa función de seguridad CasaSegura utiliza la clase Detector que debe revisar el estado de cada tipo de sensor de seguridad. Es probable que, conforme pase el tiempo, crezca el número y tipos de sensores de seguridad. Si la lógica de procesamiento interno se implementa como una secuencia de comandos si-entonces-en otro caso, cada uno dirigidoa un tipo diferente de sensor, cuando se agregue uno nuevo se requerirá una lógica de procesamientointerno adicional (otro si-entonces-en otro caso). Esto sería una violación del PAC.

Ejemplo: Sistema Casa Segura

2.Principio de sustitución de Liskov.“Las subclases deben ser sustituibles por sus clasesde base”. Un componente que use una clase de base debe funcionar bien si una clase derivada de la clase base pasa al componente. El PSL demanda que cualquier clase derivada de unaclase de base debe respetar cualquier contrato implícito entre la clase de base y los componentesque la usan. En el contexto de este análisis, un “contrato” es una precondición que debe ser verdadera antes de que el componente use una clase de base y una poscondición que debe ser ver dadera después de ello.

3.Liberación de la Reutilización➔ Cuando las clases o componentes se diseñan para

ser reutilizables, existe un contrato implícito que se establece entre el desarrollador de la entidad reutilizable y las personas que la emplearán.

➔ El desarrollador se compromete a establecer un sistema que controle la liberación para que dé apoyo y mantenimiento a las versiones anteriores de la entidad mientras los usuarios se actualizan poco a poco con la versión más nueva.

4.Principio de cierre común.“Las clases que cambian juntas pertenecen a lo mismo”. Las clases deben empacarse en forma cohesiva. Es decir, cuando las clases se agrupan como parte de un diseño, deben estar dirigidas a la misma área de funciones o comportamiento.Cuando deba cambiar alguna característica de dicha área, es probable que sólo aquellas clases que haya dentro del paquete requieran modificación. Esto lleva a un control de cambios y a un manejo de la liberación más eficaces.

Componentes - Cohesión.La cohesión implica que un componente o clase sólo contiene atributos y operaciones que se relacionande cerca uno con el otro y con la clase o componente en sí. Existen 3 categorías:1. Funcional. Lo tienen sobre todo las operaciones; este

nivel de cohesión ocurre cuando un componente realiza un cálculo y luego devuelve el resultado.

2. De capa. Lo tienen los paquetes, componentes y clases; este tipo de cohesión ocurre cuando una capa más alta accede a los servicios de otra más baja, pero ésta no tiene acceso a las superiores.

3. De comunicación. Todas las operaciones que acceden a los mismos datos se definen dentro de una clase.

Acoplamiento.Es la medición cualitativa del grado en el que las clases se conectan una con otra. Conforme las clases (y componentes) se hacen más interdependientes, el acoplamiento crece. Un objetivo importante del diseño en el nivel de componente es mantener el acoplamiento tan bajo como sea posible.

I.S. basada en Componetes.La ISBC (ingeniería del software basada en componentes, CBSE) es un proceso que se centra en el diseño y construcción de sistemas basados en computadora que utilizan componentes de software reutilizables.

Objetivos de la ISBC:

• Desarrollar sistemas a partir de componentes ya construidos.

• Desarrollar componentes como entidades reusables.

• Mantener y evolucionar el sistema a partir de la adaptación y reemplazo de sus componentes.

Resumen y Conclusiones➔ El proceso de diseño en el nivel de componentes

incluye una secuencia de actividades que reduce el nivel de abstracción con el que se representa el software.

➔ El diseño en el nivel de componentes ilustra al software en un nivel de abstracción cercano al código.

➔ El enfoque orientado a objetos se centra en la elaboración de clases de diseño que provienen tanto del dominio del problema como de la infraestructura.