Classes represent the basic form of structuring an object-oriented System. Although they are wonderfully useful, we need something more to structure large Systems, which may have hundreds of classes.
A package is a grouping construct that allows you to take any construct in the UML and group its elements together into higher-level units. Its most common use is to group classes.
In a UML model, each class is a member of a single package. Packages can also be members of other packages, so we are left with a hierarchic structure in which top-level packages get broken down into sub packages with their own sub packages and so an until the hierarchy bottoms out in classes. A package can contain both sub packages and classes.
Each package represents a namespace, which means that every class must have a unique name within its own package.
Suppose, if we want to create a class called Date, and a Date class is already in the System package, we can have Date class as long as we put it in a separate package. To make it clear which is which, we can use a fully qualified name, that is, a name that Shows the owning package structure. We use double colons to Show package names in UML, so the dates might be System::Date and myPackage::Util::Date.
In diagrams, packages are shown with a tabbed folder. We can simply Show the package name or show the contents too. At any point, we can use fully qualified names or simply regular names. Showing the contents with class icons allows us to Show all the details of a class, even to the point of showing a class diagram within the package. Simply listing the names makes sense when all we want to do is indicate which classes are in which packages. UML allows classes in the package can be public or private.
The contents of a package can be drawn inside the package or outside the package attached by a line. If we draw the elements inside the package, write the name of the package in the folder tab.
Element Visibility
Elements in a package may have public or private visibility . Elements with public visibility are accessible outside the package. Elements with private visibility are available only to other elements inside the package. We can model public or private visibility in UML by writing a plus or minus symbol in front of the element's name
Package Dependency
Sometimes a class in one package needs to use a class in another package. This causes a dependency between packages : if an element in package A uses an element in package B, then package A depends on package B
Understanding the dependencies among packages is useful for analyzing the stability of software. In fact, the most common use of UML package diagrams is to give an overview of the core packages in our software and the dependencies among them. Packages can assist with organizing classes as deployment modules and in creating the build scripts.
Importing a package
When a package imports another package, elements in the importing package can use elements in the imported package without having to use their fully scoped names. This feature is similar to a Java import, in which a class can import a package and use its contents without having to provide their package names.
In an import relationship, the imported package is referred to as the target package. To show the import relation, draw a dependency arrow from the importing package to the target package with the stereotype import.
The package users imports security, so classes in users may use public classes in security without having to specify the package name
A package can also import a specific element in another package instead of the whole package. When importing a package, only public elements of the target package are available in the importing namespace.
The users package imports only the MyClassA element from the myPackage package
When to Use Package Diagrams
No comments:
Post a Comment