PARTICIPANTES:

ROBERTO DEHEZA ARIASARNOLD 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.

Sensor de fusión

nombre

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.

+ FormularioDePedido+ FormularioDeSeguimiento- Pedido

Cliente

Sensores::Visión(versión = 2.24)

Reglas de negocio

Nombre del Paquete contenedor

Nombre del Paquete

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.

+ FormularioDePedido+ FormularioDeSeguimiento- Pedido

Cliente Cliente

+FormularioDePedido

+FormularioDeSeguimiento

-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.

+ FormularioDePedido+ FormularioDeSeguimiento- Pedido

Cliente

Cliente

+FormularioDePedido

+FormularioDeSeguimiento

-Pedido

Anidamiento gráfico Anidamiento textual

 

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).

Generalización

+ Ventana+ Formulario# GestorEventos

GUI

+ GUI::Ventana+ Formulario# GUI::GestorEventos+ VBForm

WindowsGUI

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 ELEMENTOSEl 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 Casos de Uso

Vista de Implementación

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

Servicios de Negocios

Servicios de Datos

<< import >>

<< import >>

• B. MODELADO DE VISTAS ARQUITECTÓNICASEl 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).

Interfaz con Oracle

Interfaz con Sybase

Común {global}

CantidadMonedaIntervaloFechas

Interfaz con base de datos{abstracta}

Pedidos Clientes

IULista de correo

Aplicación de Captura de pedidos Aplicación de Lista de correo

IUCaptura de pedidos AWT

Dominio

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.

IULista de correo

Aplicación de Lista de correo

Pedidos Clientes

IUCaptura de datos AWT

Aplicación de Captura de pedidos

Paquete Dependencia

• 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.