2.4.4 Paquetes

¿Qué es un paquete?

Un paquete se puede definir como:

Un  mecanismo de propósito general para organizar elementos en grupos.

• Los modelos pueden contener cientos, o incluso, miles de elementos. Este número de elementos puede llegar a ser rápidamente inmanejable. En consecuencia, es crítico poder agrupar los elementos del modelo en colecciones lógicas que sean fáciles de mantener y fáciles de localizar dentro del modelo.
• Los paquetes son mecanismos que permiten agrupar elementos semánticamente relacionados.
• Un paquete contiene clases, pero no agrega ningún comportamiento adicional al ya definido en estas clases.
• En UML un paquete es representado a través de un folder.

Ejemplo de paquete:

Grupo de Diseño de Clases en Paquetes

Al identificar clases, éstas se deben agrupar en los paquetes para los propósitos de organización y configuración. El modelo de diseño se puede estructurar en unidades más pequeñas para hacerlo más comprensible. Agrupando los elementos modelo del diseño en los paquetes y los subsistemas, y mostrando cómo esas agrupaciones se relacionan una con otra, es más fácil entender la estructura total del modelo.
Es importante dividir el modelo de diseño por varias razones:

• Se pueden utilizar los paquetes y los subsistemas como orden, configuración o unidades de la entrega cuando termina un sistema.
  La asignación de los recursos y la capacidad de diversos equipos del desarrollo pueden requerir que el proyecto esté dividido entre diversos grupos en diversos sitios.
• Los subsistemas se pueden utilizar para estructurar el modelo del diseño de una manera que refleje los tipos del usuario.
• Los subsistemas aseguran de que los cambios de un tipo particular del usuario afecten solamente las partes del sistema que corresponden a ese tipo del usuario.
• Los subsistemas se utilizan para representar los productos existentes y los servicios del sistema.

Recomendaciones de empaquetado: Clases

Cuando las clases del límite se distribuyen a los paquetes, hay dos diversas estrategias que pueden ser aplicadas:

• Es probable que la interfaz del sistema sea substituida o experimente cambios considerables, la interfaz debe ser separada del resto del modelo del diseño. Cuando se cambia la interfaz utilizadora, sólo se afectan estos paquetes.
• Si no se perciben modificaciones importantes en la interfaz, los cambios a los servicios del sistema deben ser la guía que se maneje en principio, debido a los cambios en la interfaz. Las clases frontera deben ser colocadas junto con la entidad y las clases de control con las cuales son funcionalmente relacionadas.

Es fácil observar que las clases frontera se ven afectadas si se cambia cierta clase de la entidad o del control. Las clases frontera obligatorias que no se relacionan funcionalmente con ninguna entidad o clases de control se deben colocar en paquetes separados con las clases frontera que pertenecen a la misma interfaz.

Si una clase frontera se relaciona con un servicio opcional, se debe agrupar en un subsistema separado con las clases que colaboran para proporcionar el servicio.

Dependencia de Paquetes: Visibilidad de Elementos de Paquete

La visibilidad se puede definir para los elementos del paquete de la misma manera que se define para las cualidades y las operaciones de la clase. Esta visibilidad permite que usted especifique cómo otros paquetes pueden tener acceso a los elementos que son poseídos por el paquete.

La visibilidad de un elemento del paquete puede ser expresada incluyendo un símbolo de la visibilidad como prefijo al nombre del elemento del paquete.

Hay tres tipos de visibilidad definidos en el UML:

Public: Las clases públicas se pueden alcanzar afuera del paquete que posee. Visibility symbol: +

Protected: Las clases protegidas se pueden alcanzar solamente por el paquete que posee, y cualquier paquete que herede del paquete que posee. Visibility symbol: #

Private: Las clases privadas se pueden alcanzar solamente por las clases dentro del paquete que posee. Visibility symbol: -

Los elementos públicos de un paquete constituyen la interfaz del paquete. Todas las dependencias en un paquete deben ser dependencias en los elementos públicos del paquete. La visibilidad del paquete proporciona la ayuda para el principio de OO de la encapsulación. 

Paquetes de Acoplamiento: Recomendaciones

Un acoplador de paquete puede ser bueno y malo. Es bueno cuando el acoplador representa la reutilización, y malo cuando el acoplador representa las dependencias que hacen el sistema más difíciles de cambiar y desarrollarse.

Algunos principios generales a seguir:

• Los paquetes no deben cruzar los pares (es decir co-dependiente); por ejemplo, dos paquetes no deben depender uno de otro. En estos casos, los paquetes necesitan ser reorganizados para quitar las dependencias de crce.
• Los paquetes en capas más bajas no deben depender de los paquetes en capas superiores. Los paquetes deben solamente ser dependientes sobre los paquetes en la misma capa y en la capa más baja siguiente. En estos casos, la funcionalidad necesita estar repartida. Una solución es indicar las dependencias en términos de interfaces, y organizar las interfaces en la capa más baja.
• Las dependencias no deben saltarse capas, a menos que el comportamiento dependiente sea común a través de todas las capas. Los paquetes no deben depender de subsistemas, solamente de otros paquetes o de interfaces.