· Dependency
Dependency indicates the semantic relationship between two or more model elements. It only connects the model elements themselves and does not need a group of instances to express their meaning. It indicates a situation where changes to the provider may require or indicate changes to customers in the dependency.
According to this definition, association and generalization are dependent, but they have more special semantics, so they have their own names and detailed semantics. We usually use the word dependency to refer to other relationships. Table 4-3 lists some dependencies in the basic UML model.
Dependency |
Function |
Keywords |
Access |
Allow one package to access the content of another package |
Access |
Bind |
Specify a value for the template parameter to generate a new model element. |
Bind |
Call |
Declare a class to call other class operations |
Call |
Derived |
Declare that one instance can be exported from another instance |
Derive |
Friends |
Allow one element to access another, regardless of whether the accessed element is visible. |
Friend |
Input |
Allow one package to access the content of another package and add an alias for the components of the accessed package |
Import |
Instantiation |
Statement about creating an instance of another class for a class Method |
Instantiate |
Parameters |
The relationship between an operation and its parameters |
Parameter |
Implementation |
Description and ing between specific implementations of this description |
Realize |
Refinement |
Declare a ing between two elements at different semantic levels |
Refine |
Send |
Relationship between the sender and receiver |
Send |
Tracking |
Declare that there are some connections between elements in different models, but the ing is not as accurate |
Trace |
Use |
Declaration to use one model element requires another existing model element to correctly implement the user's functions (including calling, instantiation, parameters, and sending) |
Use |
Table 4-3 dependency types
Tracking is a conceptual expression of the connection between elements in different models. These models are usually models of different stages in the development process. Tracing lacks detailed semantics, which is especially used to trace the system requirements across models and trace the changes in models that affect other models.
Refinement represents the relationship between two forms of a concept at different development stages or at different abstract levels. This does not mean that the two concepts will coexist in the final model. One of them is usually an imperfect form. In principle, there is a ing between imperfect and well-developed concepts, but this does not mean that the conversion is automatic. Generally, a more detailed concept includes the designer's design decisions, which can be determined through many ways. In principle, changes to one model with an offset mark can be confirmed by another model. In fact, the existing tools cannot complete all these mappings, although some simple mappings can be implemented. Therefore, refinement usually reminds modelers of the relationship between multiple models in a predictable manner.
Export means that one element can be obtained by calculating another element (and the exported element can be explicitly included in the system to avoid Iterative Computing at too much cost ). Exporting, implementation, refinement, and tracing are abstract dependencies-they link different forms of the same potential thing.
The behavior or implementation of one element affects the behavior or implementation of another element. This usually comes from implementation-related issues, such as compilation.ProgramDefine another class before compiling a class. Most of the dependencies can beCodeAnd they do not need to be explicitly declared unless they are part of a top-down design style system (for example, using a predefined component or function library ). A special relationship can be described in detail, but it is often ignored because the purpose of the relationship is to highlight the dependency. The exact details can be obtained from the implementation code. The constructors used include calls and instances. A call indicates that a method in a class calls an operation of another class; an instance indicates that a method of one class creates an instance of another class.
Several types of dependencies allow some elements to access other elements. The access dependency allows one package to view the content of another package. The introduction of dependency can meet higher requirements. You can add the name of the target package content to the namespace of the imported package. The user dependency is an access dependency that allows the customer to view the private content of the provider.
Binding is a parameter that assigns a value to the template. It is a highly structured relationship with precise semantics, which can be achieved by replacing the parameters in template backup. Use and bind dependencies to include strong semantics into the element at the same semantic layer. They must be connected to elements at the same layer of the model (either the analysis layer or the design layer, and at the same abstraction layer ). The tracking and precision dependencies are more vague, and the elements of different models or different abstraction layers can be connected.
An instance of a link (meta-link, not limited to dependencies) indicates that one element (such as an object) is an instance of another element (such as a class.
The dependency is represented by a virtual arrow pointing from the customer to the provider, and its type is differentiated by a constructor keyword, as shown in Figure 4-11.
Figure 4-11 dependency