Chapter 4 model management view 10.1 Overview
Any large system must be divided into several small units so that only limited information can be processed at a time and the working groups that process the information separately will not interfere with each other. Model Management consists of dependencies between packages and packages.
10.2 packages
A package is a part of the model. Each part of the model must belong to a certain package. The Modeler can allocate the model content to the package. However, to make it work, allocation must follow reasonable principles, such as public rules, tightly coupled implementations, and public opinions. UML does not force rules on how to group packages, but a good solution greatly enhances the maintainability of the model.
The package contains the top-level model elements, that is, why are other elements included, such as the relationship between classes and them, state machines, Use Case Diagrams, interactions, and collaboration. Some elements, such as attributes, operations, status, lifeline, and messages, are included by other elements and appear directly in the package. Each top-level element has a package, which is declared in the package. The package is called the "home" package of the element. It may be referenced by another package, but its ownership belongs to the home package. In a good configuration control system, The Modeler must be able to access the home package to modify the content of elements, which provides an access control mechanism for handling large models. Packages are also the Unit of any version publishing mechanism.
A package can contain other packages. The root package can indirectly include the entire model of the system. There are several possible methods for packages in an organization. You can plan packages using views, functions, or other basic principles selected by the modeler. A package is a general hierarchical organizational unit in a UML model. They can be used for storage, access control, configuration management, and building reusable model component libraries.
If the package plan is reasonable, it can reflect the high-level architecture of the system-the system is composed of subsystems and dependencies between them. The dependency between packages outlines the dependency between packages.
10.3 dependency between packages
Dependencies appear between independent elements, but in systems of any scale, they should be observed at a higher level. The dependency between packages provides an overview of the dependencies between elements in a package. That is, dependencies between packages can be exported from dependencies between independent elements.
The existence of the dependency between packages indicates that there is a bottom-up method (an existing declaration), or that it is allowed to exist in a top-down method (a constraint that limits any other relationships, the corresponding package contains at least one dependency element of the specified type between independent elements. This is an "existing declaration" and does not mean that all elements in the package are dependent. This indicates the existence of further information for the modeler. However, the package layer dependency does not contain any deeper information. It is just a summary.
The top-down method reflects the entire structure of the system. The bottom-up method can be automatically generated from an independent element. Two methods have their own role in modeling, even in a single system.
Multiple dependencies of independent elements in the same category are clustered into an independent package layer dependency. Independent elements are contained in these packages. If the dependency between independent elements includes Constructor (such as several different ones), constructor in the package layer dependency may be ignored to generate a single high-level dependency.
The package is represented by a rectangle with labels, and the dependency is represented by a dotted arrow.
Figure 10-1 shows the Package Structure of the ticket booking system. External package. There is a dependency between the two changes of seat selection, and any implementation of the subsystem and will only include one change.
Figure 10-1 Relationship between packages
10.4 access and introduce dependency
Generally, one package cannot access the content of another package. Packages are not transparent and can be opened only when they are accessed or dependency is introduced. Access dependencies are directly applied to packages and other package containers. In the package layer, access dependency indicates that the content of the provider package can be referenced by elements in the customer package or sub-packages embedded in the customer package. The element in the provider must have sufficient visibility in its package so that the customer can see it. Generally, a package can only see elements specified as public visibility in other packages. The element with protected visibility is only visible to the Child package containing the package. Visibility can also be used for class content (attributes and operations ). The descendant of a class can see members with public or protected visibility in its ancestor, while other classes can only see members with public visibility. For referencing an element, access permission and correct visibility are required. Therefore, if the elements in a package need to see unrelated elements of another package, the first package must access or introduce the second package, the target element must have public visibility in the second package.
A package nested in another package is a part of the package container, and can fully access the content of the package container. However, if the nested package is not accessed, the inside of the nested package cannot be seen, and its content is encapsulated.
Note that the access dependency does not change the user's namespace or automatically creates a reference in any other way. It only grants the permission to create a reference. The dependency is introduced to add the name to the name field of the customer package as the alias of the path name.
10.5 models and subsystems
A model is a package that fully describes the system from a certain perspective. It provides a closed description of a system from a single point of view. It does not have a strong dependency on other packages, such as implementing dependencies or inheriting dependencies. The trace relationship indicates the existence of certain connections. It is a weak form of dependency between elements of different models. It does not need special semantic descriptions.
Generally, the model is a tree structure. The root package contains nested packages in its body. The nested package groups all the details of the system from a given point of view.
Subsystems are packages with separate descriptions and implementations. It indicates a coherent model unit with a clean interface for other parts of the system. It usually indicates that the system is implemented according to certain functional or implementation requirements. Both the model and subsystem are represented by a packet with a constructor keyword (10-1 ).
|
