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.
(Gp:) Servicios de Usuario (Gp:) Servicios de Negocios (Gp:) Servicios de Datos
< < import >> < < import >>
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. SUGERENCIAS Y CONSEJOS
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. DIAGRAMAS DE PAQUETES
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). (Gp:) Interfaz con Oracle (Gp:) Interfaz con Sybase (Gp:) Común {global} (Gp:) Cantidad Moneda IntervaloFechas (Gp:) Interfaz con base de datos {abstracta} (Gp:) Pedidos (Gp:) Clientes (Gp:) IU Lista de correo (Gp:) Aplicación de Captura de pedidos (Gp:) Aplicación de Lista de correo (Gp:) IU Captura de pedidos (Gp:) 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.
(Gp:) IU Lista de correo (Gp:) Aplicación de Lista de correo (Gp:) Pedidos (Gp:) Clientes (Gp:) IU Captura de datos (Gp:) AWT (Gp:) Aplicación de Captura de pedidos (Gp:) Paquete (Gp:) 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. CUANDO UTILIZAR LOS DIAGRAMAS DE PAQUETES
| Página siguiente |