The document discusses UML package diagrams and their notations and purposes. It describes how package diagrams can be used to logically modularize complex diagrams and organize source code. It explains how packages, elements, dependencies, imports, visibility, qualified names, and merges are represented in package diagrams.

1. UNIT I UML DIAGRAMS
Introduction to OOAD – Unified Process –
UML diagrams – Use Case – Class Diagrams–
Interaction Diagrams – State Diagrams –
Activity Diagrams –
Package, component and Deployment Diagrams.

2. Package Diagram
A diagram that shows packages of classes and
the dependencies among them

3. Introduction
– A UML construct that enables us to organize model elements, such as
classes, into groups.
– Namespace (i.e., all members should have unique names)
• Package diagram
– UML diagram which shows packages and dependencies b/w them.
• A dependency exists b/w 2 elements
.

4. Purpose of Package Diagram
• Create a package diagram to:
1. Depict a high-level overview of your requirements
2. Depict a high-level overview of your architecture/design
3. To logically modularize a complex diagram.
4. To organize programming source code.
• When to use a Package Diagram
– Used strictly for logical modularization
– When the application is very large
– Usually done in the design phase of a project

5. Notations - Package Representation
• Packages
– Represented as file folders
– Can contain other packages, creating hierarchy
Package org.hibernate
Members of the package may be shown
within the boundaries of the package
Package Types, some members
within the borders of the package

6. Package Representation
Members of the package may be
shown outside of the package

7. Notations - Element Visibility
• If an element that is owned by a package has visibility,
– It could be only public or private visibility.
(Protected or package visibility is not allowed)
• Visibility of a package element may be indicated by
– Preceding the name of the element by a visibility symbol
("+" for public and "-" for private)
All elements of Library Domain package
are public except for Account
Public elements of a package are always accessible
outside the package through the use of qualified names.

8. An element is owned by the package within which it is defined, but may be
referenced in other packages. In that case, the element name is qualified by
the package name using the pathname format PackageName::ElementName

9. Package Indication without Package Diagram

11. Relations
• Dependency
• Implementation
• Import / access
• Merge

12. Dependency
• Package A depends on package B
– if A contains a class which depends on a class in B
• Graphic representation:
There should be no cycles in the dependencies
Fish depends on water

13. Implementations
• Meaningful if multiple variants are present
• One element (client)
 Implements the behavior that the other element (supplier) specifies.

14. Importing
• Importing means accessing the elements of source by target.
• Importing grants a one-way permission
– For the elements in one package to access the elements in another
package.
• If A’s package imports B’s package,
– A can now see B, although B cannot see A.

15. Import / access
• To understand the import / access relation b/w packages
– We need to know how elements can reference each other
– What does an element import / access mean
– How this notion can be generalized to packages

16. Fully Qualified Name
• Fully qualified name:
– A globally unique identifier of a package, class, attribute, method.
• Fully qualified name is composed of
– Qualifier (all names in the hierarchic sequence above the given element) &
– The name of the given element itself
• Fully Qualified Name Notation in UML
p::A::foo
p::r::C
Element can refer to other elements
That are in its own package without using
fully qualified names

17. Element Import / Access
• Element import allows
– An element in another package to be referenced using its name without
a qualifier
– <<import>>
imported element within importing package is public
– <<access>>
imported element within importing package is private

18. Example on Element Import / Access
Public import of PageInfo element from Domain package.
Private import of SortInfo element from Domain package.

19. Example on Element Import / Access

20. Example on Element Import / Access

21. Example on Element Import / Access

22. Example on Element Import / Access

23. Package Import
• A package import is a directed relationship
– That identifies a package whose members are to be imported
• A Package Import relationship
– Drawn from a source Package to a Package whose contents are to be
imported.
Private members of a target Package (Package2) cannot be imported.

24. Visibility of a Package Import
• Visibility of a Package Import
– Could be either public or private.
• Keyword «access» is shown to indicate private visibility.
Private import of Presentation package
Public import of Domain package.

25. Package Merge
• A package merge is a directed relationship b/w 2 packages
– That indicates that content of one package is extended by the contents of
another package.
– i.e., contents of the two packages are to be combined.
• Package merge is similar to generalization
– Source element conceptually adds the ch.s of target element to its own ch.s
resulting in an element that combines the characteristics of both

26. Package Merge
• Package merge can be viewed as an operation
– That takes the contents of two packages and produces a new package
that combines the contents of the packages involved in the merge.

27. Example on Package Merge