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

This article mainly introduces the UML package map in the package introduction and package merger how to use, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

Package introduction and package merging in UML package Diagram

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 into the UML specification in the UML package diagram, from which you can see 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.

Thank you for reading this article carefully. I hope the article "how to introduce and merge packages in UML package Map" shared by the editor will be helpful to everyone. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.