DISEÑO A NIVEL DE COMPONENTES

El diseño a nivel de componentes se presenta a menudo después que se ha terminado la primera iteración del diseño arquitectónico. y  el objetivo de esta fase es traducir el diseño en software operacional.

El diseño a nivel de componentes define las estructuras de datos, los algoritmos, las características de la interfaz  y los mecanismos de comunicación asignados a cada componente de software. esta fase permite revisar si los detalles de diseño son correctos y consistentes con las representaciones iníciales de diseño.

¿QUE ES UN COMPONENTE?
Es un bloque de construcción modular par el software de cómputo. Una parte modular desplegable y reemplazable de un sistema que encapsula implementación y expone un conjunto de interfaces.

Desde el punto de vista orientado a objetos un componente es un conjunto de clases que se interrelacionan entre si.

En el contexto convencional de ingeniería de software  un componente es un elemento funcional que incorpora  la lógica del procesamiento y las estructuras internas de datos necesarios para implementar dicha lógica  y una interfaz que permita la invocación del componente y el paso de los datos.

Los componentes pueden ser de tres tipos

1. Componente de control que coordina la invocación de todos los demás componentes del dominio del problema.

2.  Un componente del dominio del problema que implementa una función parcial o completa requerida por el cliente.

3.  Un componente de infraestructura  responsable de funciones que soportan el procesamiento requerido en el dominio del problema.

A continuación se presenta un ejemplo  de un diseño a nivel de componentes utilizando UML

DISEÑO DE COMPONENTES BASADOS EN CLASES

Cuando se elige un método de ingeniería de software basado en componentes el nivel de diseño de estos se concentra en la elaboración de clases de análisis y la definición y afinación de clases de infraestructura.

Hay cuatro principios básicos basados en el nivel de diseño de componentes

1. El principio abierto cerrado PAC un modulo debe estar abierto para extensiones pero cerrado para modificaciones.

2. Principio de sustitución de Liso PSL debe tenerse la opcion de sustituir las subclases con sus clases principales.

3. Principio de la inversión de la dependencia PID dependa de las abstracciones no de las concreciones, mientras un componentes dependa mas de de otros componentes concretos es mas difícil extenderlos.

4. Principio de la segregación de la interfaz es mejor tener  tener muchas interfaces específicas del cliente que una interfaz de propósito general.