La industria del software y la literatura al respecto utilizan el término "componente" para referirse a muchas cosas
diferentes. A menudo se utiliza en un sentido amplio para hacer referencia a una "parte constitutiva". También suele
utilizarse en un sentido más restringido para denotar características específicas que permiten la sustitución y el
ensamblaje en sistemas más grandes.
En RUP, el término "componente" es un parte encapsulada de un sistema; idealmente, una parte sustituible, casi
independiente y segura de un sistema no trivial que desempeñe una función clara en el contexto de una arquitectura bien
definida. Esto incluye:
-
componente de diseño: una parte encapsulada del diseño significativa; incluye subsistemas de diseño y, a veces,
clases y paquetes de diseño significativos.
-
componente de implementación: una parte encapsulada de la implementación significativa; generalmente, código que
implementa un componente de diseño.
Idealmente, el diseño refleja la implementación, de modo que se puede hacer referencia sólo a los componentes, ya que
cada componente tiene un diseño y una implementación.
El UML ([UML04]) define "componente" de la siguiente manera:
Una parte modular de un sistema que encapsula su contenido y cuya manifestación se puede sustituir en su entorno.
Un componente define su comportamiento en términos de interfaces proporcionadas y necesarias. Como tal, un
componente sirve como un tipo, cuya conformidad se define mediante las interfaces proporcionadas y necesarias
(abarcando tanto la semántica estática como la dinámica).
Un componente se define como un subtipo de clase estructurada, que estipula que un componente debe tener atributos y
operaciones, ser capaz de participar en asociaciones y generalizaciones, y tener puertos y estructura interna. Consulte
el apartado Concepto: Clase estructurada para obtener más detalles.
Hay una serie de estereotipos del estándar UML que se aplican al componente, por ejemplo, <<subsistema>>
para modelar componentes a gran escala, y <<especificación>> y <<realización>> para modelar
componentes con definiciones de realización y especificación diferentes, donde una especificación puede tener varias
realizaciones.
La utilización que se hace en RUP del término componente es más amplia que la definición del UML. En lugar de definir
los componentes como poseedores de características del tipo de modularidad, capacidad de despliegue y sustituibilidad,
recomendamos estas características como deseables para los componentes. Consulte el apartado de abajo sobre
Sustituibilidad de componentes.
En la terminología de RUP y UML, los componentes deberían ser sustituibles. Sin embargo, esto puede significar
simplemente que el componente expone un conjunto de interfaces que ocultan una implementación subyacente.
Hay otras clases de sustituibilidad más fuertes. Estas clases se listan a continuación.
Sustituibilidad del archivo de origen
Si se implementan dos clases en un solo archivo de código fuente, normalmente, no se pueden realizar versiones de estas
clases ni se pueden controlar por separado.
Sin embargo, si un conjunto de archivos implementa totalmente un solo componente, y ningún otro, el componente es
sustituible por el archivo de origen. Esta característica facilita el control de versión, la creación de líneas de base
y la reutilización del código fuente del componente.
Sustituibilidad en despliegues
Si se despliegan dos clases en un solo ejecutable, estas clases no son sustituibles de forma independiente en un
sistema desplegado.
Una característica deseable de los componentes de mayor granularidad es que sean "sustituibles en el despliegue" y, de
este modo, admitan el despliegue de versiones nuevas del componente sin tener que reconstruir los otros componentes.
Normalmente, esto significa que hay un archivo o un conjunto de archivos que despliegan el componente, y ningún otro
componente.
Sustituibilidad en tiempo de ejecución
Si un componente se puede volver a desplegar en un sistema en ejecución, se conoce como "sustituible en tiempo de
ejecución". Esto permite actualizar el software sin perder disponibilidad.
Transparencia de ubicación
Los componentes con interfaces direccionables de red se conocen por tener "transparencia de ubicación". Esto permite
reubicar los componentes en otros servidores, o replicarlos en varios servidores, para dar soporte a la tolerancia a
errores, el equilibrio de carga, etc. Estas clases de componentes suelen conocerse como componentes "distribuidos" o
"distribuibles".
El componente UML es una construcción de modelado que proporciona las siguientes posibilidades:
-
puede agrupar clases para definir una parte de mayor granularidad de un sistema
-
puede separar las interfaces visible de la implementación interna
-
puede tener instancias que se ejecuten en tiempo de ejecución
Un componente tiene una serie de interfaces proporcionadas y necesarias, que conforman la base para cablear los
componentes juntos. Una interfaz proporcionada es aquella que implementó directamente el componente o sus
subcomponentes o clases de realización, o es el tipo de un puerto proporcionado del componente. Una interfaz necesaria
la designa una dependencia de utilización del componente o sus subcomponentes o clases de realización, o es el tipo de
un puerto necesario.
Un componente tiene una vista externa (o vista de "caja negra") por medio de sus propiedades y operaciones visibles
públicamente. De forma opcional, un comportamiento como una máquina de estado de protocolo se puede adjuntar a una
interfaz, a un puerto y al mismo componente, para definir la vista externa con mayor precisión haciendo las
restricciones dinámicas en la secuencia de llamadas de operación explícitas. El cableado entre componentes de un
sistema u otro contexto se puede definir estructuralmente utilizando dependencias entre interfaces del componente
(normalmente, en diagramas de componentes).
De forma opcional, se puede hacer una especificación más detallada de la colaboración estructural utilizando partes y
conectores en estructuras compuestas, para especificar la colaboración de niveles de instancia o rol entre componentes.
Esta es la vista interna del componente (o vista de "caja blanca") por medio de sus propiedades privadas y
subcomponentes o clases de realización. Esta vista muestra cómo se realiza internamente el comportamiento externo. La
correlación entre las vistas externa e interna se realiza por medio de dependencias (en diagramas de componentes), o
conectores de delegación con partes internas (en diagramas de estructura compuesta).
RUP recomienda la utilización de componentes como la representación de subsistemas de diseño. Consulte el Producto de trabajo: Subsistema de diseño, la Tarea: Diseño del subsistema y la Directriz:
Subsistema de diseño si desea información detallada. Consulte también las definiciones del apartado Concepto: Clase estructurada.
En el tiempo de ejecución, se pueden crear instancias directamente o no de un componente.
Una instancia de un componente creada indirectamente se implementa, o realiza, mediante un conjunto de clases,
subcomponentes o partes. El componente en sí no aparece en la implementación, sirve como diseño a seguir por una
implementación. El conjunto de partes, subcomponentes o clases de realización debe cubrir todo el conjunto de
operaciones que se especifica en la interfaz proporcionada del componente. La manera de implementar el componente es
responsabilidad del implementador.
Un componente cuya instancia se creó directamente especifica su propia implementación encapsulada; su instancia se crea
como un objeto direccionable. Esto significa que un componente de diseño tiene una construcción correspondiente en el
lenguaje de implementación, por lo que se puede hacer referencia a él de manera explícita.
UML 1.5 definió "componente" de la siguiente manera:
Un componente modular, desplegable y sustituible de un sistema que encapsula la implementación y expone un conjunto
de interfaces. Un componente suele especificarse mediante una o varias clases o subcomponentes que residen en él, y
lo pueden implementar uno o varios artefactos (por ej., archivos de scripts, ejecutables o binarios).
Tenga en cuenta que en UML 1.3 y en versiones anteriores de UML, la notación de "componente" se utilizó para
representar archivos en la implementación. Las definiciones más recientes de UML ya no consideran a los archivos como
"componentes". Sin embargo, muchas herramientas y perfiles UML siguen utilizando la notación de componente para
representar archivos. Consulte la Directriz: Elemento de implementación para obtener más información sobre la
representación de archivos en UML.
Desde la perspectiva del modelado, los componentes se comparaban con subsistemas UML en UML 1.5, porque proporcionaban
modularidad, encapsulación e instancias capaces de ejecutarse en tiempo de ejecución. RUP considera la construcción de
modelado de componentes de UML 1.5 como una notación alternativa para representar subsistemas de diseño. Consulte el Producto de trabajo: Subsistema de diseño y la Directriz: Subsistemas de diseño si desea información detallada.
Consulte Diferencias entre UML 1.x y UML 2.0 para obtener más información.
|