. Un paquete es un mecanismo de propósito general para organizar elementos en grupos. Los paquetes nos ayudan a organizar los elementos en los modelos con el fin de comprenderlos más fácilmente. Los paquetes también permiten controlar el acceso a sus contenidos para controlar las líneas de separación de la arquitectura del sistema.
UML proporciona una representación gráfica de los paquetes, como se muestra en la figura esta notación permite visualizar grupos de elementos que se pueden manipular como un todo y en una forma que permite controlar la visibilidad y el acceso a elementos individuales.
(Gp:) Sensor de fusión
(Gp:) nombre
PAQUETES EN UML
Cada paquete ha de tener un nombre que lo distingue de otros paquetes. Un nombre es una cadena de texto. El nombre solo se denomina nombre simple; un nombre de camino consta del nombre del paquete precedido por el nombre del paquete en el que se encuentra, si es el caso. Un paquete se dibuja normalmente mostrando sólo su nombre, como se muestra en la figura. Al igual que con las clases, se pueden dibujar paquetes adornados con valores etiquetados o con apartados adicionales para mostrar sus detalles.
(Gp:) + FormularioDePedido
+ FormularioDeSeguimiento
– Pedido
(Gp:) Cliente
(Gp:) Sensores::Visión
(versión = 2.24)
(Gp:)
Reglas de negocio
Nombre del Paquete contenedor
Nombre del Paquete
NOMBRES
Un paquete puede contener otros elementos, incluyendo clases, interfaces, componentes, nodos, colaboraciones, casos de uso, diagramas e incluso otros paquetes. La posesión 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 único paquete.
Un paquete forma un espacio de nombres, lo que quiere decir que los elementos de la misma categoría deben tener nombres únicos en el contexto de su paquete contenedor. Por ejemplo, no se pueden tener dos clases llamadas Cola dentro del mismo paquete, pero se puede tener una clase Cola en el paquete P1 y otra clase (diferente) llamada Cola en el paquete P2.. las clases P1::Cola y P2 son, de hecho, clases diferentes y se pueden distinguir por sus nombres de camino. Diferentes tipos de elementos pueden tener el mismo nombre.
ELEMENTOS CONTENIDOS
Elementos de diferentes tipos pueden tener el mismo nombre dentro de un paquete. Así, se puede disponer de una clase llamada Temporizador, así como de un componente llamado Temporizador dentro del mismo paquete. En la práctica sin embargo, para evitar la confusión, es mejor asociar a cada elemento un nombre único para todas las categorías dentro de un paquete.
Como se muestra en la figura, se puede mostrar explícitamente el contenido de un paquete, bien textualmente, bien gráficamente. Cuando se muestran los elementos que posee, el nombre del paquete se coloca en la pestaña de la carpeta de esta forma. En vez de ello, se emplean herramientas software para penetrar en los contenidos de un paquete.
(Gp:) + FormularioDePedido
+ FormularioDeSeguimiento
– Pedido
(Gp:) Cliente
(Gp:)
Cliente
(Gp:) +FormularioDePedido
(Gp:) +FormularioDeSeguimiento
(Gp:) -Pedido
Anidamiento gráfico
Anidamiento textual
Para especificar la visibilidad de un elemento contenido en su paquete se antepone al nombre el símbolo de visibilidad apropiado. Los elementos públicos se muestran con su nombre precedido del símbolo +, como pasa con FormularioDePedido en la Figura 12.3. el conjunto de las partes públicas de un paquete constituye la interfaz del paquete.
Al igual que con las clases, se puede designar a un elemento como protegido o privado, con el nombre del elemento precedido del símbolo # o del símbolo -, respectivamente. Los elementos protegidos sólo son visibles para los paquetes que heredan de otro paquete; los elementos privados no son visibles para nadie fuera del paquete.
(Gp:) + FormularioDePedido
+ FormularioDeSeguimiento
– Pedido
(Gp:) Cliente
(Gp:)
Cliente
(Gp:) +FormularioDePedido
(Gp:) +FormularioDeSeguimiento
(Gp:) -Pedido
Anidamiento gráfico
Anidamiento textual
VISIBILIDAD
Supongamos que tenemos dos clases llamadas A y B, que se conocen mutuamente. Al ser compañeras, A puede ver a By B puede ver a A, así que cada una depende de la otra. Dos clases tan solo constituyen un sistema trivial, así que realmente no se necesita ningún tipo de empaquetamiento.
Ahora imaginemos que tenemos unos cientos de clases, que se conocen entre ellas. No hay límites para la intrincada red de relaciones que se puede establecer. Además, no hay forma de comprender un grupo de clases tan grande y desorganizado. Este es un problema real para grandes sistemas (el acceso simple y no restringido no permite el crecimiento). Para estas situaciones se necesita algún tipo de empaquetamiento controlado para organizar las abstracciones.
Ahora imaginemos 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 B se declaran ambas como públicas en sus respectivos paquetes. Esta es una situación muy diferente. Aunque A y B son ambas públicas, ninguna puede acceder a la otra porque sus paquetes contenedores forman un muro opaco. Sin embargo, si el paquete de A importa al paquete de B, A puede ver ahora a B, aunque B no puede ver a A. la importación concede un permiso de un solo sentido para que los elementos de un paquete accedan a los elementos de otro. En 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 número de abstracciones.
IMPORTACIÓN Y EXPORTACIÓN
Existen dos tipos de relaciones que pueden darse entre paquetes: las dependencias de acceso e importación, utilizadas para importar en un paquete los elementos exportados por otro, y las generalizaciones, para especificar familias de paquetes.
La generalización entre paquetes es muy parecida a la generalización entre clases. Por ejemplo, en la figura 12.5 se ve que el paquete GUI exporta dos clases (Ventana y Formulario) y tiene una clase protegida (GestorEventos). Ahora, los paquetes GUI que son: WindowsGUI y MacGUI especializan al paquete más general GUI. Estos paquetes especializados heredan los elementos públicos y protegidos del paquete más general. Pero, al igual que con la herencia entre clases, los paquetes pueden reemplazar a los elementos más generales y añadir nuevos. Por ejemplo, el paquete WindowsGUI hereda de GUI, de forma que incluye las clases GUI::Ventana y GUI::GestorEventos. Además, WindowsGUI redefine una clase (Formulario) y añade otra nueva (VBForm).
GENERALIZACIÓN
(Gp:) Generalización
(Gp:) + Ventana
+ Formulario
# GestorEventos
(Gp:) GUI
(Gp:) + GUI::Ventana
+ Formulario
# GUI::GestorEventos
+ VBForm
(Gp:) WindowsGUI
(Gp:)
MacGUI
Figura 12.5. Generalización entre paquetes
Todos los mecanismos de extensibilidad de UML se aplican a los paquetes. Con mucha frecuencia, se utilizan valores etiquetados para añadir nuevas propiedades al paquete (tales como especificar el autor) y estereotipos para especificar nuevas categorías de paquetes (tales como los paquetes que encapsulan servicios del sistema operativo).
UML define cinco estereotipos estándar que se aplican a los paquetes:
1.- facade Especifica en paquete que es sólo una vista de algún otro paquete.
2.- framework Especifica un paquete que consta principalmente de patrones.
3.- stub Especifica un paquete que sirve de proxy para el contenido público de otro paquete.
4.- subsystem Especifica un paquete que representa una parte independiente del sistema completo que se está modelando.
5.- system Especifica un paquete que representa el sistema completo que se está modelando.
UML no especifica iconos para ninguno de estos estereotipos. Además de estos cinco estereotipos de paquetes, también se emplearán las dependencias con la importación estándar de estereotipos.
ELEMENTOS ESTÁNDAR
La mayoría de estos elementos estándar se discuten en otras partes del texto, excepto facade (fachada) y stub. Estos dos estereotipos ayudan a manejar modelos muy grandes. Las fachadas se utilizan para proporcionar vistas simplificadas de paquetes que de otra forma serían excesivamente complejos. Por ejemplo, el sistema podría contener el paquete ModeloDeNegocio. Quizás sea necesario mostrar un subconjunto de sus elementos a un grupo de usuarios (por ejemplo, para mostrar sólo aquellos elementos asociados con clientes), y otro subconjunto a otro grupo distinto de usuarios (por ejemplo, para mostrar sólo aquellos elementos asociados con productos). Para hacer esto, se definirán fachadas, que importan (y nunca contienen) sólo un subconjunto de los elementos en otro paquete. Los stubs se utilizarán cuando se tengan herramientas que particionen un sistema en paquetes que se manejarán en momentos diferentes y potencialmente en lugares diferentes. Por ejemplo, si hay un equipo de desarrollo trabajando en dos ubicaciones, el equipo de un lado proporcionaría el stub para los paquetes que necesitase el otro equipo. Esta estrategia permite a los equipos trabajar independientemente sin interrumpir uno el trabajo del otro, capturando los paquetes stub las líneas de separación en el sistema, las cuales deben ser manejadas cuidadosamente.
A. MODELADO DE GRUPOS DE ELEMENTOS
El objetivo más frecuente para el que se utilizan los paquetes es organizar elementos de modelado en grupos a los que se puede dar un nombre y manejar como conjunto. Si se está desarrollando una aplicación trivial, no harán falta paquetes. Todas las abstracciones encajarán perfectamente en un paquete. Sin embargo, para cualquier otro sistema, se detectará que muchas de las clases, interfaces, componentes, nodos e incluso diagramas del sistema tienden a agruparse de forma natural. Estos grupos se modelan como paquetes.
TÉCNICAS COMUNES DE MODELADO
Para modelar vistas arquitectónicas:
Hay que identificar el conjunto de vistas arquitectónicas que son significativas en el contexto del problema. En la práctica, normalmente se incluyen una vista de diseño, una vista de procesos, una vista de implementación, una vista de despliegue y una vista de casos de uso.
Hay que colocar en el paquete adecuado los elementos (y diagramas) necesarios y suficientes para visualizar, especificar, construir y documentar la semántica de cada vista.
Si es necesario, hay que agrupar aún más estos elementos en sus propios paquetes.
Normalmente existirán dependencias entre los elementos de diferentes vistas. Así que, en general, hay que permitir a cada vista en la cima del sistema estar abierta al resto de vistas en el mismo nivel.
Por ejemplo, la Figura 12.7 ilustra una descomposición canónica de nivel superior apropiada incluso para los sistemas más complejos que puedan encontrarse.
Vista de Diseño
Vista de Casos de Uso
Vista de Implementación
Vista de Procesos
Vista de Despliegue
Figura 12.7. Modelado de vistas arquitectónicas
Página siguiente  |