1. UML:
Paquetes
Lic. César Alcántara Loayza

2. Propósito y Función
 Los paquetes son contenedores de
propósito general. Como tales
proporcionan una herramienta versatil
para organizar los elementos del
modelo cuando un proyecto es muy
grande o complejo.
CAL/Fundamentos 2

3. Propósito y Función
Procesamiento De Ordenes
+ Orden
+ Cliente
+ EmpleadoProcesoOrden
CAL/Fundamentos 3

4. Propósito y Función
 Los paquetes pueden contener cualquiera de
los elementos del modelo lógico, como clases,
interfaces, diagramas y aún otros paquetes.
 Los paquetes también pueden ser usados para
agrupar componentes físicos de software. El
hecho de que un paquete contenga otro
paquete le permite organizar sus modelos de
manera jerárquica.
CAL/Fundamentos 4

5. Propósito y Función
 Los paquetes se dice que “poseen” los
elementos que continen. Este tipo de
contensión es por definición composición. Si el
paquete es destruido, entonces su contenido
también es destruido.
 Los componentes colocados en un paquete
son, por default, visibles solo dentro del
paquete. Sin embargo, la visibilidad de
elementos de modelo individuales dentro del
paquete se pueden definir como público,
privado o protegido.
CAL/Fundamentos 5

6. Propósito y Función
 Cada paquete debe tener por lo
menos una interface pública, esto es,
al menos una clase con una interface
pública.
CAL/Fundamentos 6

7. Elementos Del Paquete
 Denominar los elementos del modelo dentro
de un paquete requiere dos piezas de
información: el nombre del elemento y el tipo
del elemento. Los nombres deben ser únicos
dentro de los elementos del mismo tipo dentro
de un paquete pero no tienen que ser únicos
entre tipos diferentes. Ejem. Un paquete
puede contener una clase Producto y un
diagrama de estados Producto. Un paquete no
podría tener dos clases llamadas Producto.
CAL/Fundamentos 7

8. Elementos Del Paquete
 Los elementos del modelo pueden
tener el mismo nombre en diferentes
paquetes. Pero siempre que los dos
elementos son usados juntos, ellos
deben ser calificados con el nombre del
paquete que lo posee. Un nombre de
elemento completamente calificado usa
la notación Paquete :: elemento
CAL/Fundamentos 8

9. Notación
 Los paquetes se referencian unos a
otros usando la notación de
dependencia estandar, una flecha con
linea discontinua. Ejemplo: El paquete
Recepción depende de Compra.
Despacho depende del paquete
Recepción.
CAL/Fundamentos 9

10. Notación
Orden de Compra Recepción Empleado de
Compra recepción
Despacho
CAL/Fundamentos 10

11. Notación
 La relación de dependencia significa que al
menos una clase en un paquete tiene
comunicación con al menos una clase en el
otro paquete. En el ejemplo, Empleado de
recepción en el Paquete Recepción necesita
hablar con la orden de compra del paquete
Compra para validar los productos que
ingresan antes de colocar los productos en
inventario.
CAL/Fundamentos 11

12. Estereotipos De Paquetes
 Las dependencias de paquetes pueden estar
rotuladas con un estereotipo como
<<import>> para describir específicamente la
naturaleza de la dependencia. El estereotipo
<<import>> significa que el paquete
Recepción adiciona a si mismo la clase
OrdenDeCompra, permitiendo referencias
internas a la clase sin especificar el nombre
del paquete fuente.
CAL/Fundamentos 12

13. Estereotipos De Paquetes
Compra Recepción
<<Import>>
<<Access>>
Despacho
CAL/Fundamentos 13

14. Estereotipos De Paquetes
 Diferente del estereotipo <<access>>,
donde debe usarse el calificador de
nombre del paquete, paquete :: clase,
porque la clase no se adiciona al
paquete receptor.
CAL/Fundamentos 14

15. Clases En Un Paquete
 También se pueden crear diagramas
de clase de las clases dentro de un
paquete para mostrar las
asociaciones entre los elementos
poseidos.
CAL/Fundamentos 15

16. Clases En Un Paquete
Despacho
EmpleadoDespacho
empaca
envía
envia Orden
Despacho
(from Procesamiento De Ordenes)
0..* 1
1..*
Producto
(from Compra)
1..*
CAL/Fundamentos 16

17. Subsistemas
 Se pueden usar los estereotipos <<subsystem>> y
<<system>>
<<subsystem>> <<subsystem>>
Compra <<Import>> Recepción
<<Access>>
Recuerde que los estereotipos son Definidos
por el usuario. No está limitado al estandar
<<subsystem>>
proporcionado por UML Despacho
CAL/Fundamentos 17