Concepto: Clase estructurada
Una clase estructurada es una clase que consta de partes con una notación "anidada" explícita y se utiliza para modelar jerarquías de contención, que son clase compuestas de "partes".
Relaciones
Elementos relacionados
Descripción principal

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.

Diagrama descrito en el texto adjunto.

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

Diagrama descrito en el texto adjunto.

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.

Diagrama descrito en el texto adjunto.

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:

Diagrama descrito en el texto adjunto.

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.

Diagrama descrito en el texto adjunto.

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.