El documento describe el diseño a nivel de componentes, el cual define las estructuras de datos, algoritmos y mecanismos de comunicación asignados a cada componente del software. Explica qué es un componente y cómo se relacionan entre sí mediante módulos. También cubre principios como el abierto-cerrado, sustitución de Liskov y cohesión, los cuales buscan facilitar la reutilización y reducir el acoplamiento entre componentes.

1. 10.Diseño en el nivel de
Componentes
Ramiro Estigarribia Canese

2. ¿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.

3. ¿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.

4. 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.

5. Módulos
Se 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.

6. 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 representa
un componente del software.
Cada operación se representa como módulo aislado
que se invoca como se indica en la figura.
Para controlar el procesamiento se utilizan otros
módulos, por lo que son componentes de control.

7. Sistema de Imprenta.

8. 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.

9. Diagrama de componentes:
‘Compute Page Cost’.

10. 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.

11. Principios básicos del
diseño
Hay cuatro principios básicos que son aplicables al
diseño en el nivel de componentes y que han
sido 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.

12. 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í.

13. Ejemplo:
Sistema Casa Segura
La 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 dirigido
a un tipo diferente de sensor, cuando se agregue uno
nuevo se requerirá una lógica de procesamiento
interno adicional (otro si-entonces-en otro caso). Esto sería
una violación del PAC.

14. Ejemplo:
Sistema Casa Segura

15. 2.Principio de sustitución de
Liskov.
“Las subclases deben ser sustituibles por sus clases
de 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 una
clase de base debe respetar cualquier contrato implícito
entre la clase de base y los componentes
que 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.

16. 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.

17. 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.

18. Componentes - Cohesión.
La cohesión implica que un componente o clase sólo
contiene atributos y operaciones que se relacionan
de 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.

19. 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.

20. 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.

21. 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.