Shulou(Shulou.com)06/03 Report--

This article introduces the knowledge of "package introduction and package introduction and explanation in UML package diagram". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

1 packet introduction

Package introduction (packageimport, see Section 7.3.39 of USS) is a relationship that allows unqualified name access to elements from another namespace. If we have a package An and a package B, and if package A does not introduce package B, then package A must use a qualified name, such as B::Integer, when accessing package B. When package An introduces package B, it can be accessed with an unrestricted name, and A can directly use Integer to access the Integer in package B. The introduction of package is like the usingnamespace keyword in C++ language and the import keyword in Java language.

Figure 1 is the syntax definition introduced by the package into the UML specification, and you can see from the figure that it contains an importingNamespace and an importedPackage, which means to introduce importedPackage into importingNamespace. In addition, we can see that PackageImport is a direct relationship. Also note that PackageImport contains a visibility attribute that represents the visibility of the package introduction relationship. The value of this attribute is defined in the UML specification as either public or private. The implication is: if a package introduction visibility is public, then the introduced package can be accessed by other elements outside the namespace; if a package introduction visibility is private, then the introduced package can only be accessed by elements in the namespace, but not by elements outside the namespace. This is the same as the meaning of public and private in our language.

Figure 1 the syntax introduced into the UML specification by the package

Figure 2 is an example of a package introduction, which also illustrates the representation of the package introduction relationship in UML. You can see that package introduction relationships and dependencies are represented in the same way. In the package introduction representation, a package with an arrow side is introduced into a package without an arrow side, as can be seen from the syntax definition in figure 1, because importedPackage is target. You might ask, is it right that the package introduction is defined in figure 1 as introducing a package into the namespace, but in figure 2 the package is introduced into the package? Remember the syntax definition of the package in UML mentioned in "packages and namespaces in the UML package diagram"? Because the package inherits from the command space, that is to say, the package is a namespace!

Figure 2 an example of package introduction

The visibility introduced by the package mentioned above is divided into public and private, which are distinguished by sterotype in UML. Public corresponds to a pattern, while private corresponds to a pattern, which is also illustrated in figure 2. We can see from figure 2 that the Auxiliary package and the Types package are introduced into the ShoppingCart package, and when introduced, the elements introduced into the ShoppingCart package can be accessed directly with an unqualified name. In addition, the Types package can also be accessed by elements outside the ShoppingCart package, because the visibility of its introduction relationship is public, that is, after the WebShop package introduces the ShoppingCart package, it can also directly access the elements in the Types package with an unqualified name. Because the visibility that the Auxiliary package introduces into the ShoppingCart package is private, although WebShop introduces the ShoppingCart package, it cannot access the Auxiliary package with an unqualified name. Of course, the WebShop package still accesses elements in the Auxiliary package with a qualified name such as Auxiliary::xyz. We can also understand that the relationship is transitive, but the relationship is not.

2 package merging

The package merge in the UML package diagram (packagemerge, see Section 7.3.40 of USS) defines the relationship between how the contents of one package are extended by another. The package merge relationship means that the contents of the two packages are merged together to get a new merge package, of course, this merge relationship also implies an extension of the merged package. Figure 3 lists the syntax of the package merge relationship in the UML specification.

Syntax of packagable elements in the figure 3UML specification

Figure 4 is an example of using package merging, where package merging relationships are represented the same as dependencies in the UML diagram. From the syntax in figure 3, you can see that the package pointed to by the target is the merged package. In figure 4, we can see three packages, namely the Merged package, the merging package, and the Importing package. We can also see that the Merging package merges the Merged package, and the Importing package introduces the Merging package. There is a class An in all three packages, and the class A here is just for convenience. In fact, there can be other elements in the package. What is the relationship between class An in those three packages before and after the merger?

Figure 4 an example of a package merge

To make it easier to understand this problem, see figure 5. The plus sign in the package merge of the UML package diagram indicates the merge operation, the left side of the equal sign indicates before the merge, and the right side of the equal sign indicates after the merge. Before merging, we can see that Merged::An and Merging::An are each a sector, but after merging Merging::A becomes a circle because the Merged package is merged into the Merging package, which is seen from the point of view of the Merging package. From the point of view of the Merged package, it is a sector before and after the merge, which is understandable because it is independent and does not merge other packages. For the Merging package, we can also understand that before the merge, it is a fan both from inside the package and from the outside of the package. But after the merger, An is still a fan from the inside, but a circle from the outside.

Figure 5

With the above understanding of package merging, it is not difficult to understand An in the Importing package, which is obviously a circle introduced from the outside of the Merging package.

3 Summary

The package introduces this relationship in order to make it easier for one namespace to refer to the elements in another package, and its convenience lies in that the elements in the introduced package can be accessed by an unqualified name. The concept of package merge relationship is introduced to model the incremental extension of a package, that is, we can merge a package on an existing package to get a more complete or powerful new package. To understand the UML specification, we need to have a good understanding of package introduction and package merging.

This is the end of the introduction and explanation of packages in the UML package diagram. Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.