Definición
Según UML ([UML04]), una clase es un subtipo de clasificador encapsulado y metaclase a la vez, lo
que proporciona a una clase la capacidad de tener una estructura interna y puertos. UML también define los componentes
como un subtipo de clase. Por lo tanto, en el contexto de RUP, tanto los componentes como las
clases se consideran clases estructuradas.
Componente
Una instancia de una clase estructurada contiene un objeto o un conjunto de objetos correspondientes a cada parte.
Todas estas instancias se destruyen cuando se destruye la instancia de clase estructurada que las contiene.
El ejemplo de abajo muestra dos vistas posibles de la clase Coche:
En la figura (a), Coche tiene una asociación de composición con el nombre de rol
trasera a una clase Rueda y una asociación de composición con el nombre de rol
e a una clase Motor. Cualquier instancia de la clase Motor se
puede enlazar con un número arbitrario de instancias de la clase Rueda.
En la figura (b), se especifica lo mismo. Sin embargo, en la figura (b) también se especifica que:
-
trasera y e pertenecen a la estructura interna de la clase
Coche. Esto permite especificar los detalles exclusivos de las instancias de las clases
Rueda y Motor en el contexto de la clase Coche, pero que
no son aplicables a ruedas y motores en general.
-
en el contexto de la clase Coche, la instancia que desempeña el rol de e
sólo se puede conectar a dos instancias que desempeñen el rol de trasero. Además, las
instancias que desempeñan los roles e y trasero sólo se pueden enlazar si
son roles de la misma instancia de la clase Coche.
-
En otras palabras, en las instancias de las clases Rueda y Motor se aplican
restricciones adicionales, cuando desempeñan los roles respectivos en una instancia de la clase
Coche. Estas restricciones no son ciertas para instancias de Rueda y
Motor en general. Tal como se especifica en la figura (a), se pueden enlazar arbitrariamente
otras ruedas y motores.
Ejemplo: Componentes que desempeñan su rol en una clase estructurada
Conector
Un conector es una instancia de relación entre dos componentes de una clase estructurada. Es un enlace que permite la
comunicación. Los conectores se pueden implementar mediante asociaciones ordinarias o relaciones transitorias, como
parámetros del procedimiento, variables, valores globales u otros mecanismos.
El "cableado" interno de una clase estructurada se especifica con los conectores de ensamblaje y los conectores de
delegación:
-
En la implementación de una clase estructurada, los conectores de ensamblaje conectan puertos de
componentes diferentes. Un mensaje que se envía en un puerto de una clase estructurada se recibe en un puerto
conectado de otra clase estructurada. Un conjunto de componentes se puede conectar mediante los puertos. No es
necesario que un componente sepa nada sobre los otros componentes, salvo que existen y cumplen las restricciones de
los puertos conectados. La comunicación entre las clases estructuradas la modelan sus puertos.
-
-
Un conector de delegación conecta un puerto externo de una clase estructurada con un puerto de uno
de sus componentes internos. Un mensaje recibido por el puerto externo se pasa al puerto del componente interno; un
mensaje enviado por el puerto interno se pasa al puerto externo y, después, a la clase estructurada que está
conectada al puerto externo.
Puerto
Un puerto es una característica estructural de una clase estructurada. La encapsulación se puede aumentar forzando las
comunicaciones desde fuera de la clase estructurada para que pasen a través de los puertos que obedecen a las
interfaces declaradas, lo que otorga una precisión adicional en la especificación y la interconexión para dicha clase
estructurada.
Las interfaces necesarias y proporcionadas de un puerto especifican todo lo necesario para las interacciones mediante
el punto de interacción. Si se alcanzan todas las interacciones de una clase estructurada con su entorno a través de
los puertos, las cualidades esenciales de la clase estructurada se aíslan totalmente del entorno. Esto permite que una
clase estructurada de este tipo se utilice en cualquier contexto que cumpla las restricciones que especifican sus
puertos.
No se presupone nada sobre el modo de implementación de un puerto. Se puede implementar como un objeto explícito o
puede ser simplemente un concepto virtual que no aparece explícitamente en la implementación.
A continuación, se proporcionan ejemplos de puertos:
Ejemplo 1
Puerto de un motor que se utiliza en un coche y en un barco
La figura de arriba muestra una clase Motor con un puerto p y dos interfaces:
-
Una interfaz proporcionada tren transmisor de potencia, que especifica los servicios que ofrece el
motor en este puerto (es decir, las operaciones y las recepciones a las que se pueden acceder mediante la
comunicación que llega a este puerto).
-
Una interfaz necesaria alimentación, que especifica los servicios que el motor espera que
proporcione el entorno.
En el puerto p, la clase Motor está totalmente encapsulada; se puede especificar sin
ningún conocimiento del entorno en que se integrará el motor. Mientras el entorno obedezca las restricciones que
expresan las interfaces proporcionadas y necesarias del motor, el motor funcionará correctamente.
Para ilustrarlo, en este ejemplo se muestran dos usos de la clase Motor:
-
La clase Coche conecta el puerto p del motor a un conjunto de ruedas mediante el
eje.
-
La clase Barco conecta el puerto p del motor con una hélice mediante el
eje.
Mientras la interacción entre el Motor y el componente enlazado con su puerto p
cumpla las restricciones que especifican las interfaces necesarias y proporcionadas, el motor funcionará tal como se
especifica, independientemente de si se trata del motor de un coche o del motor de un barco.
Además, aunque el Motor tuviese otros puertos declarados, como un puerto f para el
Consumo de combustible, las ruedas de un coche y la hélice de un barco seguirían accediendo al
Motor a través del puerto p. El puerto f sería interesante para un
medidor de combustible, independientemente de la clase de combustible que se utilizase y la clase de medidor de
combustible que puedan tener los coches y los barcos.
Ejemplo 2
Este ejemplo de puertos se basa en la API de registro con Java ([JAV03]), que es
un paquete que proporciona las siguientes clases e interfaces de los recursos centrales de registro de la plataforma
Java 2, entre otras:
-
Registrador es la entidad principal donde las aplicaciones hacen llamadas de registro. Se utiliza
para registrar mensajes para un componente de la aplicación o del sistema específico
-
Nivel proporciona un baremo de la importancia y la urgencia de un mensaje de registro
-
Filtro proporciona un control exhaustivo de lo que se registra, además del control que
proporcionan los niveles de registro
-
Manejador coge los mensajes del registrador y los exporta a diferentes destinos (memoria,
corrientes de salida, consolas, archivos y sockets)
-
Formateador proporciona soporte para formatear los registros
Estas clases e interfaces están involucradas en dos tipos importantes de colaboraciones. Algunas clases e interfaces se
utilizan para escribir en el registro y otras se utilizan para administrarlo. La figura de abajo muestra dos
colaboraciones diferentes que los clientes y los administradores tienen con el registro, modeladas como colaboraciones
UML:
-
Colaboración de escritura, donde el rol ClienteRegistro se conecta con el rol
EscritorRegistro para escribir en el registro.
-
Colaboración de administración, donde el rol AdministradorRegistro se conecta con
el rol ControladorRegistro para acceder al registro y cambiar su configuración.
Diferentes colaboraciones que tienen los clientes y los administradores con el registro
Una posible representación UML 2.0 para modelar los servicios de registro y sus colaboraciones sería utilizar un
componente con puertos e interfaces declaradas, como se muestra en la figura de abajo:
Paquete de la API de registro con Java que se está implementando como un componente con las interfaces proporcionadas
agrupadas en puertos
En la especificación API de registro con Java, algunos de los servicios de registro se implementaron como clases y
otros como interfaces. En este ejemplo, modelamos estos servicios como interfaces proporcionadas, que se podrían
realizar por partes en el componente. Las dos clases diferentes de comportamiento relacionadas con las colaboraciones
de escritura y administración que se mencionan más arriba podrían representarse
mediante interfaces agrupadas lógicamente en puertos. Por lo tanto, tenemos:
-
Interfaces de registrador y nivel agrupadas en el puerto
EscritorRegistro. Los clientes de registro acceden a estas interfaces para escribir en el
registro.
-
Interfaces de manejador, filtro y formateador agrupadas en el
puerto ControladorRegistro. Los administradores de registro acceden a estas interfaces para tener
acceso a la configuración del registro de cambios y al registro.
Esta alternativa de modelado supone una separación de asuntos, ya que agrupa lógicamente las interfaces en puertos
diferentes. Esto nos proporciona una precisión adicional para la especificación del componente y la interconexión que
pueda tener con el mundo externo.
Modelado
Durante el diseño, las clases y los componentes se pueden descomponer en recopilaciones de componentes conectados que,
a su vez, se pueden a descomponer.
Un diagrama de estructura compuesta se puede utilizar para mostrar la descomposición de una clase
estructurada. A modo de ejemplo, la figura de abajo muestra un diagrama de estructura compuesta para la taquilla del
sistema de entradas. Esta clase se descompone en tres partes:
-
Una interfaz de vendedor de entradas
-
Una guía de rendimiento que recupera realizaciones en función de la fecha y otros criterios
-
Un conjunto de bases de datos que contienen los datos de las realizaciones y las entradas.
Cada parte interactúa mediante una interfaz bien definida que especifican los puertos. La taquilla entera interactúa
con el exterior a través de un puerto. Los mensajes de este puerto se envían a la clase de vendedor de entradas, pero
la estructura interna de la clase de taquilla se oculta de los clientes externo.
Ejemplo: Diagrama de estructura compuesta para un sistema de entradas.
Representación UML 1.x
Tenga en cuenta que una clase estructurada es un concepto nuevo en UML 2.0.
Gran parte de lo que RUP define como Cápsula se puede representar utilizando una clase estructurada como notación
(consulte los apartados Producto de trabajo: Cápsula y Directriz de producto de
trabajo: Cápsula para obtener más información sobre este tema).
Si su herramienta sólo soporta UML 1.5, en los apartados Producto de
trabajo: Cápsula y Directriz de producto de
trabajo: Cápsula se describe una representación alternativa.
Consulte Diferencias entre UML 1.x y UML 2.0 para obtener más información.
|