EL TT LENGUAJE crt UNIFICADO as D E MO ID: E EAD © SERIES EDITORS > UML 2.0 ® DA EDICION Grady Booch James Rumbaugh __ Ivar Jacobson | Aprenda UML . directamente ' de sus creadoresLENGUAJE UNIFICADO DE MODELADO Capitulo 12 PAQUETES En este capitulo m Paquetes, visibilidad, importacién y exportacién. 1 Modelado de grupos de elementos. m Modelado de vistas arquitectonicas. én a grandes sistemas. Visualizar, especificar, construir y documentar grandes sistemas conlleva mane- jar una cantidad de clases, interfaces, componentes, nodos, elementos que puede ser muy elevada. Conforme va creciendo el sistema hasta, aleanzar un gran tamaio, se hace necesario organizar estos elementos en bloques mayores. En UML el paquete es un mecanismo de propésito general para orga- nizar elementos de modelado en grupos. \gramas y otros Los paquetes se utilizan para organizar los elementos de modelado en partes ma- yores que se pueden manipular como un grupo. La visibilidad de estos elemen- tos puede controlarse para que algunos sean visibles fuera del paquete mientras que otros permanecen ocultos. Los paquetes también se pueden emplear para presentar diferentes vistas de la arquitectura del sistema, Los paquetes bien disefiados agrupan elementos cercanos seméinticamente y que suelen cambiar juntos. Por tanto, los paquetes bien estructurados son cohesivos y poco acoplados, y el acceso a su contenido esta muy controlado, 173174 Parte 3 MoveLapo ESTRUCTURAL AVANZADO Introduccion a aerencia Las casetas de perro no son complejas: hay cuatro paredes, una de ellas con un xt consis agujero del tamafio de un perro, y un techo. Al construir una caseta de perro s6lo sence y | Se necesitan unas cuantas tablas. No hay mucha mds estructura. dscuten en ef Capitulo 1 La arquitectura on of modelado de fa arguitectura do tun sisterna se discute en ef Capitulo 32 Las casas son mas complejas. Paredes, techos y suelos se combinan en abstrac- ciones mayores que Hamamos habitaciones. Incluso esas habitaciones se orga- nizan en abstracciones mayores: la zona publica, la zona de dormir, la zona de trabajo, etc. Estos grupos mayores no tienen por qué manifestarse como algo que construir en la propia casa, sino que pueden ser simplemente los nombres que damos a habitaciones relacionadas Iégicamente, y que se aplican cuando hablamos sobre el uso que se hard de la casa. Los grandes edificios son muy complejos. No s6lo existen estructuras elemen- tales, como paredes, techos y suelos. sino que hay estructuras més complejas, tales como las zonas piiblicas, el rea comercial y la zona de oficinas. Estas es- tructuras probablemente se agrupardn cn otras atin més complejas, como las Z0- nas de alquileres y las zonas de servicios del edificio. Puede que estas estructuras mids complejas no tengan nada que ver con el edificio final, sino que sean sitn- plemente artefactos que se utilizan para organizar los planos del edificio, Todos los sistemas grandes se jerarquizan en niveles de esta forma. De hecho, quiz4s la Gnica forma de comprender un sistema complejo sea agrupando las abs- tracciones en grupos cada vez mayores. La mayoria de las agrupaciones basicas (como las habitaciones) son, por derecho propio, abstracciones de la misma na. turaleza que las clases, para las que puede haber muchas instancias. La mayoria de las abstraceiones mayores son puramente conceptuales (como el drea comer cial), para las que no existen instancias reales. No existen objetos distinguidos en el sistema, sino que més bien representan vistas del propio sistema. Este tiltimo tipo de agrupaciones no tiene una identidad individual en el sis representa agrupamientos de partes seleccionadas a través de todo el sistema. En UML las abstracciones que organizan un modelo se denominan pacuetes. Un pa- quete es un mecanismo de propésito general pata organizar elementos en grupos. Los paquetes ayudin a organizar los elementos en Jos modelos con el fin de com- prenderlos més fécilmente. Los paquetes también permiten controlar el acceso a sus contenidos para controlar las lineas de separacién en la arquitectura del sistema. UML proporciona una representacién gréfica de los paquetes, como se muestra en la Figura 12.1. Esta notacién permite visualizar grupos de elementos que se pueden manipular como un todo y de una forma que permite controlar la visibilidad y el acceso a elementos individualesCairo 12 Paquetes «175, censorde | ‘usion igura 12.1; Paquetes. Términos y conceptos E¥nombre de un aquete debe ‘sr Unico dentro del paquete que lo comtiane, ‘Un paquete es un mecanismo de prop6sito general para organizar el propio mo- delo de manera jerdrquica. Graficamente, un paquete se representa como una carpeta con una pestata. El nombre del paquete va en la carpeta (si no se mues- tra su contenido) o en la pestafia (si se muestra el contenido) Nombres ‘Cada paquete ha de tener un nombre que lo distinga de otros paquetes. Un nom- bre es una cadena de texto. El nombre solo se denomina nombre simple; un nombre calificado consta del nombre de! paquete precedido por el nombre del paquete en el que se encuentra, si es el caso. Para separar los nombres de los pa- ‘quetes se emplea un signo de dos puntos duplicado (::). Un paquete se dibuja normalmente mostrando sdlo su nombre, como se ve en Ta Figura 12.2. Al igual ‘que con las clases, los paquetes se pueden dibujar adomados con valores etique- tados 0 con apartados adicionales para mostrar sus detalles. ——__~ Gliente nombres simples “+ FormulerioDeFedo = + FormulatloDeSeguimiento — Pesido Reglas de negocio ‘nombre del paquste cantenedor nombre del paquete nombre ea caliicaco oe a Sersores:Vision [version = 224) Figura 12.2: Nombres de paquetes simples y nombres calificados. CAiRUUE. ul 2 os176 Parte a compasicion 89 discute ¢ Capitulo 10. MopeLAavo ESTRUCTURAL AVANZAD0 Nota: El nombre de un paquete puede ser texto con cualquier nime- ro de letras, digitos y ciertos signos de puntuacién (excepto signos como los dos puntos, utilizados para separar el nombre de un paque- te del nombre de su paquete contenedor) y puede extenderse a lo largo de varias lineas. En la préctica, los nombres de los paquetes son nombres cortos 0 expresiones nominales extraidos del vocabulario del modelo. Elementos contenidos Un paquete puede contener otros elementos, tales como clases, interfaces. Componentes, nodos, colaboraciones, casos de uso, diagramas ¢ incluso otros pa- quetes. La posesi6n es una relacién compuesta, lo que significa que el elemento se declara en el paquete. Si el paquete se destruye, el elemento es destruido. Cada elemento pertenece exclusivamente a un tinico paquete. Nota: El paquete contiene a los elementos de modelado declarados en él. Estos pueden incluir elementos como clases, asociaciones, ge- neralizaciones, dependencias y notas. El paquete no contiene a los elementos que son simplemente reterenciados desde é1 Un paquete forma un espacio de nombres, lo que quiere decir que los elemen- tos de la misma categoria deben tener nombres tnicos en el contexto de su pa- quete contenedor. Por ejemplo, no se pueden tener dos clases Hamadas Co dentro del mismo paquete, pero se puede tener una clase Cola en el paquete PI y owra clase (diferente) Hamada Cola en el paquete P2. Las clases P1zCola y P2::Cola son, de hecho, clases diferentes y se pueden distinguir por sus nombres calificados. Elementos de diferentes tipos pucden tener el mismo nombre. Nota: Si es posible, es mejor evitar la duplicacién de nombres en diferentes paquetes, para prevenir el peligro de confusion. Elementos de diferentes tipos pueden tener el mismo nombre dentro de un pa~ quete. Asi, se puede disponer de una clase Hamada Pemporizador, asf como de un componente llamado Tempor izador dentro del mismo paquete. En la prictica, sin embargo, para evitar la confusidn, es mejor asociar a cada elemen- to un nombre tinico para todas las categorias dentro de un paquete.176 Parte 3 Mopetaoo Esrructurat AVANZAD0 Nota: El nombre de un paquete puede ser texto con cualquier nime- ro de letras, digitos y ciertos signos de puntuacién (excepto signos como |os dos puntos, utilizados para separar el nombre de un paque- te del nombre de su paquete contenedor) y puede extenderse a lo largo de varias lineas. En la prdctica, los nombres de los paquetes ‘son nombres cortos 0 expresiones nominales extraidos del vocabulario del modelo. Elementos contenidos ‘Un paquete puede contener otros elementos, tales como clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros pu quetes. La posesién ¢s una relacién compuesta, lo que significa que el elemento se declara en el paquete. Si el paquete se destruye, el elemento es destruido. Cada elemento pertenece exclusivamente a un vinico paquete. Nota: El paquete contiene a los elementos de modelado declarados en él. Estos pueden incluir elementos como clases, asociaciones, ge- neralizaciones, dependencias y notas. El paquete no contiene a los elementos que son simplemente referenciados desde él. Un paquete forma un espacio de nombres, lo que quiere decir que los clemen- misma categoria deben tener nombres tinicos en el contexto de su pa- guete contenedor. Por ejemplo, no se pueden tener dos clases llamadas Cola dentro de! mismo paquete, pero se puede tener una clase Cola en el paquete PI y otra clase (diferente) Hamada Cola en el paquete 22. Las clase: Pl:Colay P2::Cola son, de hecho, clases diferentes y se pueden distinguir Por sus nombres calificados. Elementos de diferentes tipos pueden tener el mismo nombre. "Nota: Si es posible, ¢s mejor evitar la duplicacion de nombres en diferentes paquetes, para prevenir el peligro de confusién. Elementos de diferentes tipos pueden tener el mismo nombre dentro de un pa- quete. Asi, se puede disponer de una clase llamada Tempor izadoz, asf como de un componente Hamado Tempor i zador dentro de! mismo paquete. En la préctica, sin embargo, para evitar la confusi6n, es mejor asociar a cada elemen- to un nombre tinico para todas las categorias dentro de un paquete.178 Parte 3 MopeLano ESTRUCTURAL AVANZADO Visibilidad Se puede controlar la visibilidad de los elementos contenidos en un paquete, del mismo modo que se puede controlar la visibilidad de los atributos y operucio- nes de una clase. Normalmente, un elemento contenido en un paquete es puibli- co, ¢s decir, es visible a los contenidos de cualquier paquete que importe al paquete contenedor del elemento. Por el contrario, los elementos protegidos solo pueden ser vistos por los hijos, y los elementos privados no son visibles f del paquete en el que se declaran. En la Figura 12.3, FormularioDePodi- do es una parte publica del paquete Cliente, y Pedido es una parte priva- da, Un paquete que importe a Cliente verd a FormularioDePedid pero no veré a Peli do. Visto desde fuera, el nombre totalmente calificada de FormlarioDePedido serfa Cliente: :FormularioDePedido. Para especificar la visibilidad de un elemento contenido en un paquete se ante- pone al nombre del elemento el simbolo de visibilidad apropiado. Los clemen- tos publicos se muestran con su nombre precedido del sfmbolo +, como pasa con FormularioDePedido en la Figura 12.3. El conjunto de las partes puiblicas de un paquete constituye la interfaz del paquete. Al igual que con Las clases, se puede designar a un elemento como protegido 0 privado, con el nombre del elemento precedido del simbolo # o del simbolo respectivamente. Los elementos protegidos s6lo son visibles para los paquetes que heredan de otro paquete; los elementos privados no son visibles para nadie fuera del paquete. La visibilidad de paguete indica que una clase es visible a otras clases declara- das en el mismo paquete, pero invisible a clases declaradas en otros paquetes. La visibilidad de paquete se muestra poniendo el simbolo ~ delante del nombre de la clase. Importaci6n y exportacion Supongamos que tenemos dos clases llamadas A y B, que se conocen mutua- mente. Al ser compaficras, A puede ver a 5 y P puede ver a A, asi que cada una depende de la otra. Dos clases tan s6lo constituyen un sistema trivial, asf que realmente no se necesita ninatin tipo de empaquetamiento. Ahora imaginemos que tenemos unos cientos de clases, que se conocen entre ellas. No hay limites para la intrincada red de relaciones que se puede establecer. ‘Ademis, no hay forma de comprender un grupo de clases tan grande y desorga-se discut Captuo 6; los id de extor: UML se discuten en of Capitut CapiruLo 12 Paqueres «179 nizado. Este es un problema real para grandes sistemas (el acceso simple y no restringido no permite cl crecimiento). Para estas situaciones se necesita alin tipo de empaquetamiento controlado para organizar las abstracciones. Asi que supongamos que en lugar de esto se coloca A en un paquete y B en otro, teniendo cada paquete conocimiento del otro. Supongamos también que A y 5 se declaran ambas como ptiblicas en sus respectivos paquetes, Esta es una situa- cién muy diferente. Aunque 4 y 5 son ambas ptiblicas, acceder a una de Las cla ses desde el otro paqucte requiere un nombre calificado. Sin embargo, si el paquete de A importa al paquete de B, A puede ahora ver a B, aunque 5 no pue- de veraA sin un nombre calificado. La importacidn afiade los elementos pabli- cos del paquete destino al espacio de nombres ptiblico del paquete importador. n UML una relacién de importacién se modela como una dependencia con el estereotipo import. Al empaquetar las abstracciones en bloques significativos y luego controlar los accesos mediante la importacién, se puede controlar la ‘complejidad de tener un gran ntimero de abstracciones. Nota: Realmenie, aqui se aplican dos estereotipos (import y ac cess) y ambos especifican que el paquete origen tiene acceso al contenido del destino. Tmport afiade el contenido del destino al espacio de nombres publico del origen, de forma que no hay que ca- lificar los nombres. Esto implica la posibilidad de colisién de nombres que hay que evitar para tener un modelo bien formado. Access afia~ de el contenido del paquete destino al espacio de nombres privado del origen. La Unica diferencia es que no se pueden reexportar los elementos importados si un tercer paquete importa el paquete origen inicial. La mayoria de las veces se usaré import Las partes ptiblicas de un paquete son sus exportaciones. Por ejemplo, en ta Figura 12.4. el paquete GU 1 exporta dos clases, Vent ana y Formulario. Gestorsventos no es exportada por GUI; GestorEventos es una parte protegida del paquete Las partes que exporta un paquete son sélo visibles al contenido de aquellos paquetes que lo importan explicitamente. En este ejemplo, Politicas: importa explicitamente al paquete GUI, Las clases GUI: : Ventana y GUT: :Formulario son, por tanto, visibles para el contenido del paque- te Politicas usando simplemente sus nombres simples ventana y Formular io. Sin embargo, GUI: : GestorEventos no es visible por- que es protegido. Como el paquete Serv iGor no importa a GUT, el conte- nido de Servidor puede acceder a contenido piiblico de GUT, pero debe180 Pante 3 Movetavo EsTRUCTURAL AVANZADO usar los nombres calificados para hacer esto; por ejemplo, GUT: : Window Andlogamente, el contenido de Gut no tiene permiso para acceder al con tenido de Sezvidor ya que éste es privado; es inaccesible utilizando inelu- so nombres calificados. Las dependencias de importacién y acceso son transitivas. En este ejemplo, Cliente importa Politicas y Politicas importa GUT, asf que Cliente importa Gut de manera transitiva, Si Politicas accede a GUL, en vez de importarlo, C1 iente no afiade los elementos de GUT a su espacio de nombres, pero atin podria referenciarlos utilizando nombres calificados (como GUT: : Window). ‘Servidor ~BaseDeDatos [Fetiente | ~ SorvicioDeRegistro le + FormularioDePedido nes — J» +FormularioDeSeguimionto —Pedido export imports Polltioas ee J? +ReglasDePedidos -QUI:Ventana 1 imrportacion eal ial ee ventana ' > sFormulario Ga --! NGestorEventos Figura 12.4: Importacién y exportacién. Nota: Si un elemento es visible en un paquete, es visible en todos los paquetes incluidos en ese paquete. Los paquetes anidados pueden ver todo lo que los paquetes que los contienen pueden ver. Un nom- bre en un paquete anidado puede ocultar un nombre en un paquete contenedor, en cuyo caso se necesita un nombre calificado para referenciarlo.Capiruo 12 Paaueres «181 Técnicas comunes de modelado Modelado de grupos de elementos FI objetive més freeuente para el que se utilizan los paquetes es organizar elementos de modelado en grupos a los que se puede dar un nombre y ma- nejar como un conjunto. Si se esté desarrollando una aplicacién trivial, no hardin falta paquetes. Todas las abstracciones encajaran perfectamente en v paquete. Sin embargo, para cualquier otro sistema, se detectaré que muchas de las clases, interfaces, componentes y nodos tienden 2 agruparse de for- ma natural. Estos grupos se modelan como paquetes. Hay una distinci6n importante entre clases y paguctes: las clases son abstrac- ciones de cosas encontradas en el problema 0 en a soluci6n; los paquetes son Ios mecanismos que se emplean para organizar los elementos del mode- lo. Los paquetes no aparecen en el sistema en ejecucién: son estrictamente mecanismos para organizar el disefto La mayor tipo de elementos. Po a de las veces, los paquetes se utilizaran para agrupar el mismo ejemplo, todas las clases de la vista de disefto del sis- tema y sus correspondientes relaciones se podrfan separar en una serie de pa quetes, utilizando las dependencias de importacién de UML para control el acceso entre esos paquetes, De la misma forma se podrfan organizar todos los componentes de la vista de implementacidn del sistema Los paquetes también se pueden emplear para agrupar diferentes tipos de elementos. Por ejemplo, en un sistema en desarrollo por un equipo distribui- do geograficamente, se podrian utilizar los paquetes como las unidades bé- sicas para Ia gestién de configuraciones, colocando en ellos todas las clases y diagramas que cada equipo puede registrar y verificar independientemen- te. De hecho, es frecuente emplear los paquetes para agrupar elementos de modelado y sus diagramas asociados. Para modelar grupos de elementos: minar los elementos de modelado de una determinada vis m Hay quee: ta arquitect6nica en busca de grupos definidos por elementos cercanos entre sf desde un punto de vista conceptual o seméntico, m Hay que englobar cada uno de esos grupos en un paquete, m Para cada paquete, hay que disting: smentos que podréin ser ac~ cedidos desde fuera. Deben marcarse estos elementos como pablicos,