AVA coders, UML package diagram is a kind of a structural diagram that shows the location and organization of model elements in a medium scale and large scale projects. A package diagram can display both the structure and the dependencies between subsystems or modules, illustrating various kinds of systems, such as a layered application for example. If the system is of a significant size, it should be divided into smaller subsystems, each with its own class diagram. In UML notation, these partitions or subsystems are called packages. A package is a group of elements of the model and it can also be used in other UML diagrams.
Packages themselves can be nested in other packages, which is basically a UML version of folders. Package diagrams are usually used when it is necessary to group related UML elements and determine the scope of their names or when you need to provide a way to visualize dependencies between parts of the system as well as to provide some support for analysis or determine the compilation order. Package diagrams are used to structure high-level system elements.
When modeling a package diagram you should bear in mind that a package is a UML mechanism for grouping elements including other packages. Each package has its own namespace in which all names must be unique. Each model element belongs to a single package.
Packages form a hierarchy. Packages are displayed as rectangles with small tabs at the top. Packages name is normally written on its tab or dedicated rectangle namespace.
Dotted lines with arrows depict dependencies. One package is said to be dependent on another if changes in that other package can cause changes in the first one as well. A system could be depicted in the form of a package with the stereotype system and it represents all the elements of the model that are relevant to a particular project. You can also break the system apart into business systems and application systems when creating more detailed models to make them smaller but more efficient. The package diagram can also display the logical architecture of a system.
A subsystem is a group of model elements that are part of some larger system. Since the system or subsystem is a stereotypical package, it has all the properties of the package and it also follows the rules of the package. And all those model elements that are contained inside the system or the subsystem will also belong to the package and follow the same rules. Now What does this word stereotype actually mean?
Stereotype is a high-level classification of an object that gives some idea of what the object is. Classes can be grouped by stereotypes. Their names are written inside the angle brackets above the class name.
Stereotype allows us to extend UML to fit our modeling needs more specifically. In other words, stereotyping a UML element makes it act as something that has specific properties. Elements in packages may also have different visibility of elements of other packages, and this also needs to be taken into account during the process of modeling of a system. Elements of a package with public visibility are available outside the package, while elements with private visibility are available only for other elements within the package. In UML, public, protected and private visibilities correspond to a class that is a public protected or private.
A public element is visible to all elements that can access the content of the namespace to which it belongs. Public visibility is represented by the plus sign. A protected element is visible to elements related to generalization relationship to the namespace that owns it.
Protected visibility is represented by the hash sign. A package element is owned by a namespace that is not a private element. package and is visible to all elements that are in the same package. Package visibility is marked by a tilde.
A private element is visible only inside the namespace that owns it. Private visibility is represented by the minus sign. Let's look at the types of dependency relationships represented by the stereotypes. The element in the client package uses the public element in the supplier package. The client depends on the supplier.
If the package dependency is shown without a stereotype, then it should be marked with a use stereotype. Public elements of the supplier namespace are added as public elements to the client namespace. Elements in the client's namespace can access all public elements in the supplier namespace using unqualified names. Public supplier namespace elements are added as private elements to the client namespace.
Elements in the client namespace can access all public elements in the supplier namespace using unqualified names. Trace normally represents a historical development of one element into another, more developed version. Usually this is the relationship between models, not elements.
Public elements of the supplier package are combined or merged with the client package elements. The dependency is used only in meta-modelling and the chance of encountering it in the modern object-oriented analysis and design is even less than encountering an elephant in the central London. Next, we will analyze an example diagram of the order tracking scenario for an online store. In this diagram, the track order module is responsible for providing tracking information for product ordered by our customers.
The types of customers are encrypted inside the tracking number. Track order module refers to the system and updates the current delivery status for the customer. Based on the description of the project, first we must determine what packages will be present in the system and figure out the relationships between them. So how to determine which packages do we need to model the system?
Suppose that we have a module that tracks an order. It could be some sort of a tracking module and in order to perform its duty, it must communicate with another module in order to figure out the details of the order. Let's call this module OrderDetails.
After receiving the details of the order, it needs to know the shipping details. So let's introduce a shipping module. And now let's determine the dependencies between them. The Truck Order module must receive the order details from the Order Details module.
In response, Order Details module requires to know the information provided by the client. Two modules communicate with each other, which provides the access dual dependency. To learn the shipping information, the Shipping module can import the Truck Order module to make the navigation easier.
Finally, the Truck Order is dependent on the UI framework and this completes our order processing subsystem design. Please give this video an Emperor's thumbs up, toll the bell and subscribe. That was V, thank you and goodbye.