PARTICIPANTES:
ROBERTO DEHEZA ARIAS
ARNOLD MAURICIO QUINTANILLA MALLEA
. 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.
nombre
Sensor de fusión
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.
Reglas de negocio
Nombre del
Paquete
contenedor
Cliente
+ FormularioDePedido
+ FormularioDeSeguimiento
- Pedido
Nombre del Paquete
Sensores::Visión
(versión = 2.24)
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 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.
Cliente
+ FormularioDePedido
+ FormularioDeSeguimiento
- Pedido
Anidamiento textual
Cliente
+FormularioDePedido
-Pedido
+FormularioDeSeguimiento
Anidamiento gráfico
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.
Cliente
Cliente
+ FormularioDePedido
+ FormularioDeSeguimiento
- Pedido
Anidamiento textual
+FormularioDePedido
-Pedido
+FormularioDeSeguimiento
Anidamiento gráfico
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.
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).
GUI
+ Ventana
+ Formulario
# GestorEventos
Generalización
WindowsGUI
+ GUI::Ventana
+ Formulario
# GUI::GestorEventos
+ VBForm
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.
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.
• 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 Implementación
Vista de Casos de Uso
Vista de Procesos
Vista de Despliegue
Figura 12.7. Modelado de vistas arquitectónicas
Para modelar grupos de elementos:
•
•
•
•
•
•
Hay que examinar los elementos de modelado de una determinada vista
arquitectónica en busca de grupos definidos por elementos cercanos entre sí desde
un punto de vista conceptual o semántico.
Hay que englobar cada uno de esos grupos en un paquete.
Para cada paquete, hay que distinguir los elementos que podrían ser accedidos
desde fuera. Deben marcarse estos elementos como públicos, y los demás como
protegidos o privados. En caso de duda, debe ocultarse el elemento.
Hay que conectar explícitamente los paquetes que dependen de otros a través de
dependencias de importación.
En el caso de familias de paquetes, hay que conectar los paquetes especializados
con sus partes más generales por medio de generalizaciones.
Por ejemplo, la Figura 12.6 representa un conjunto de paquetes que organiza las
clases de diseño de un sistema de información en una arquitectura clásica de tres
capas. Los elementos del paquete Servicios de usuario proporcionan la interfaz
visual para presentar información y capturar datos. Los elementos del paquete
Servicio de Datos mantienen, acceden y actualizan los datos. Los elementos del
paquete Servicios de Negocio enlazan los elementos de los otros dos paquetes e
incluyen todas las clases y demás elementos que gestionan las solicitudes del
usuario para ejecutar una tarea del negocio, incluyendo las reglas que dictan las
políticas de gestión de los datos.
Servicios de Usuario
<< import >>
Servicios de Negocios
<< import >>
Servicios de Datos
• B. MODELADO DE VISTAS ARQUITECTÓNICAS
El uso de paquetes para agrupar elementos relacionados es
importante; no se puede desarrollar modelos complejos sin utilizar
sin utilizarlos. Este enfoque funciona bien para organizar elementos
relacionados como clases, interfaces, componentes, nodos y
diagramas. Cuando se consideran las diferentes vistas de la
arquitectura de un sistema software incluso se necesitan bloques
mayores. Los paquetes se pueden emplear para modelar las vistas
de una arquitectura.
Recuérdese que una vista es una proyección de la organización y
estructura de un sistema, centrada en un aspecto particular del
sistema. Esta definición tiene dos implicaciones. Primer, se puede
descomponer un sistema en paquetes casi ortogonales cada uno de
los cuales cubre un conjunto de decisiones significativas
arquitectónicamente. Por ejemplo, podría tenerse 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. Segunda, esos
paquetes contienen todas las abstracciones pertinentes para esa
vista. Por ejemplo, todos los componentes del modelo
pertenecerían al paquete que representara la vista de
implementación.
•
•
•
•
•
•
•
•
•
Cuando se modelan paquetes en UML hay que recordar que existen sólo para
ayudar a organizar los elementos del modelo. Si tienen abstracciones que se
manifiestan como objetos en el sistema real, no se deben utilizar paquetes. En vez
de ello, se utilizarán elementos de modelado, tales como clases o componentes. Un
paquete bien estructurado:
Es cohesivo, proporcionando un límite bien definido alrededor de un conjunto de
elementos relacionados.
Está poco acoplado, exportando sólo aquellos elementos que otros paquetes
necesitan ver realmente, e importando sólo aquellos elementos necesarios y
suficientes para que los elementos del paquete hagan su trabajo.
No está profundamente anidado, porque las capacidades humanas para comprender
estructuras profundamente anidadas son limitadas.
Posee un conjunto equilibrado de elementos; los paquetes de un sistema no deben
ser demasiado grandes en relación a los otros (si es necesario, deben dividirse) ni
demasiado pequeños (deben combinarse los elementos que se manipulen como un
grupo).
Cuando se dibuje un paquete en UML:
Hay que emplear la forma simple del icono de un paquete a menos que sea
necesario revelar explícitamente el contenido.
Cuando se revele el contenido de un paquete, hay que mostrar sólo los elementos
necesarios para comprender el significado del paquete en el contexto.
Especialmente si se están usando los paquetes para modelar elementos sujetos a
una gestión de configuraciones, hay que revelar los valores de las etiquetas
asociadas a las versiones.
• La idea de un paquete se puede aplicar a cualquier
elemento de un modelo, no sólo a las clases. Sin cierta
heurística que agrupe las clases, el agrupamiento se
vuelve arbitrario. El más útil y el que recibe mayor
énfasis en el UML, es la de dependencia. Se emplea el
término diagrama de paquetes para indicar un
diagrama que muestra los paquetes de clases y la
dependencia entre ellos.
• Los paquetes y las dependencias son elementos de un
diagrama de clases, por lo cual un diagrama de
paquetes es sólo una forma de un diagrama de clases.
•
En la figura tenemos las clases de dominio que modelan el negocio, las
cuales se agrupan en dos paquetes: Pedidos y Clientes. Ambos paquetes
son parte de un paquete que abarca todo el dominio. La aplicación de
Captura de pedidos tiene dependencias con los dos paquetes del dominio.
La Interfaz de Usuario (IU) para Captura de pedidos tiene dependencias
con la aplicación Captura de pedidos y con AWT (un juego de herramientas
GUI de Java).
IU
Captura de pedidos
IU
Lista de correo
AWT
Aplicación de Lista de
correo
Aplicación de Captura de pedidos
Dominio
Pedidos
Clientes
Interfaz con Oracle
Común {global}
Cantidad
Moneda
IntervaloFechas
Interfaz con base de datos
{abstracta}
Interfaz con Sybase
Los paquetes no dan respuestas sobre la manera de reducir las dependencias
en el sistema, pero sí ayudan a ver cuáles son las dependencias, y sólo se
puede efectuar el trabajo para reducirlas, cuando es posible verlas. Los
diagramas de paquetes son, desde mi punto de vista, una herramienta
clave para mantener el control sobre la estructura global de un sistema.
• Existe una dependencia entre dos paquetes si existe algún tipo de
dependencia entre dos clases cualquiera en los paquetes. Por ejemplo, si
cualquier clase en el paquete Lista de correo depende de cualquier clase
del paquete Clientes, entonces se da una dependencia entre sus paquetes
correspondientes.
IU
Captura de datos
IU
Lista de correo
AWT
Paquete
Aplicación de Captura de
pedidos
Dependencia
Aplicación de Lista de
correo
Pedidos
Clientes
• Los paquetes son una herramienta vital para los
proyectos grandes. Úselo siempre que un diagrama de
clases que abarque todo el sistema ya no sea legible en
una hoja de papel tamaño carta.
• Usted querrá mantener sus dependencias al mínimo, ya
que ello reduce el acoplamiento. Sin embargo, la
heurística de esto no está bien comprendida.
• Los paquetes son especialmente útiles para pruebas.
Cada paquete deberá tener una o más clases de
pruebas que verifiquen su comportamiento.
Descargar

diagrama de paquetes