2015/03/26-09:25
"Declaration" Welcome reprint, but please keep the article original source: http://blog.csdn.net/yelangjueqi/article/details/45529235
In Object-oriented system modeling, there are 3 particularly important relationships: dependencies (dependency), which represent the use relationships between classes (including refinement, tracking, and binding relationships) , and generalization, It connects the generic class to its special class; Association (Associatiota), which represents the structure relationship between objects. Each of these relationships provides different methods for combining objects.
1, Getting Startedin UML, the way things are interconnected (both logically and physically) are modeled as relationships. In object-oriented modeling, there are three important relationships: dependency,
Association and generalization.
(1), Dependency (dependency): is the use relationship.
(2), Association (Association): is the structural relationship between instances.
(3), generalization (generalization): Connects a generic class to a more special class, also known as a superclass/subclass relationship or parent/child relationship.
These 3 relationships cover the important ways in which most things work together. Obviously, these 3 relationships can also map well to the way that most object-oriented languages provide connection objects.
UML provides a graphical representation of each relationship. This notation allows the visualization of relationships out of a specific programming language and can be used to emphasize the most important part of the relationship: off
The characteristics of the name, the thing that the relationship is connected to, and the relationship.
2, Terminology and conceptsRelationship (relationship) is the connection between things. In object-oriented modeling, 3 of the most important relationships are dependency, generalization, and association. On the graph, draw a line into the relationship
and use different lines to differentiate the kind of relationship.
2.1, Dependency (dependency) is a usage relationship that shows the information and services of a thing (such as a class window) using another thing (such as class event), but not necessarily.
On the graph, the dependency is drawn as a dashed line pointing to the dependent thing. When you want to indicate that one thing uses another, you choose to rely on it.
in most cases, the use of a dependency between a class and a class indicates that one class uses another class's operation, or it uses variables and parameters defined by other classes, such as this is indeed a
with a relationship, if the class being used changes, the operation of the other class is also affected. Because the class being used may exhibit different interfaces or behaviors at this time. In the
In UML, dependencies can also be created among many other things, especially annotations and packages.
Note: Dependencies can have a name but are rarely used unless the model has a lot of dependencies, and you want to reference them or make a difference. Under normal circumstances, the difference between different dependent
meaning.
2.2, generalization (generalization) is the relationship between a general thing (called a superclass or a parent class) and a more special kind of the thing (called a subclass or a child). Sometimes also referred to as the "is a kind of" relationship: a thing (such as a class Baywindow) is a "kind" of something more general (such as window). The return means that the object of the subclass can be used anywhere the object of the parent class may appear. Conversely, in other words, generalization means that a subclass can replace the declaration of a parent class. Subclasses inherit the attributes of the parent class, especially the parent class
and operations. Typically (but not always), subclasses have more properties and operations in addition to the properties and operations of the parent class. If an implementation of an operation of a subclass overrides the parent class's same
an implementation of an operation, this condition is called polymorphism. In common, two operations must have the same signature (same name and parameter).
On the graph, the generalization is drawn as a directed solid line with a large, hollow triangular arrow pointing to the parent class. Generalization is used when you want to represent a parent/child relationship.
A class can have 0, one, or more parent classes. A class that does not have a parent class and has at least one subclass is called a root class or base class, and a class without subclasses is called a leaf class. If a class has only one
parent class, it uses single inheritance, and if a class has more than one parent class, it uses multiple inheritance.
in most cases, an inheritance relationship is indicated by a generalization between classes or interfaces. In UML, you can also create a generalization relationship between other classes, such as a node relationship.
2.3, Association (association) is a structural relationship that indicates the connection between the object of one thing and the object of another. The Association of two classes given a connection. An object of another class can be contacted from an object of one class. It is legal to have both ends of the association connected to the same class. This means that a given object from a class can connect to other objects of that class. The association that happens to connect two classes is called a two-dollar association. Although less common, there can be associations with more than two classes connected, called N-ary associations. On the graph, draw the association into a solid line that joins the same class or not. When representing a structural relationship, the association is used.
PS: How to understand associations, how to use associations? Personal feel that the object of things to exclude dependence, generalization, the realization of these relations, but also exist relations, but this relationship is not dependent, generalization, implementation of the relationship, then this relationship can be divided into related relations. Can be represented by an association. (That is, if you do not know what the relationship is, use this exclusion method to determine the line.) )
In addition to this basic form, there are 4 kinds of modifiers that apply to associations:
A, name
an association can have a name that describes the nature of the relationship. To disambiguate the name, provide a triangle that indicates the direction of the name, giving the name a direction.
Note: Although an association can have a name, it is generally not necessary to give a name in case the associated end-call is explicitly given. If you are using multiple associations to connect to the same class, it is necessary to distinguish them by using either the close joint or the associated end name. If an association has more than one endpoint on the same class, it is necessary to use the association end name to differentiate the endpoint. If there is only one association between the two classes, some modelers omit the associated name, but it is best to use the association name in order for the association to be clearly intended.
B, role
When a class participates in an association, it plays a particular role in the relationship. A role is a face that is rendered to a class on the other end of a class that is close to its end in the association. You can display the role that a class plays in the association. The role of the associated endpoint is called the end name. In, the class person who plays the employee role is associated with the class company that plays the employer role.
Note:
A, the same class can play the same or different roles in other associations.
B, you can think of a property as a one-way association owned by a class, and a property name corresponding to the name of the associated remote.
C, associations represent the structural relationships between objects. In many modeling problems, it is important to explain how many interconnected objects are in an associated instance. This "How much" is called the multiplicity of the associated role, which represents the range of an integer that indicates the number of possible groups of related objects. The multiplicity is written as an expression that represents the range of values, and the maximum and minimum values can be the same, separating them with two dots. Declares the multiplicity of one end of an association, which means that for each object of the class that is associated with the other end, there may be many objects for the class on this side. The number of objects must be within a given range. The multiplicity can be precisely expressed as: one (1), 0, or one (0). 1), multiple (0.. *), one or more (1.. *）。 It can be given a range of integers, such as 2. 5), it is even possible to specify the multiplicity as a numeric value (such as 3 and 3) precisely. 3 equivalent).
For example, each company object can hire one or more person objects (multiplicity is 1). *); Each person object is employed by 0 or more company objects (multiplicity = *, which is equivalent to 0). *）。
D, Aggregation
A simple association between two classes represents the structural relationship between the two equal status classes, which means that the two classes are conceptually equivalent, and one class is not more important than the other class. Sometimes you model A "whole/part" relationship, where one class describes a larger thing ("whole"), which consists of smaller things ("parts"). This relationship is called aggregation, which describes the "has a" relationship, meaning that the whole object has part of the object. In fact, aggregation is just a special kind of association, which is expressed as a simple association with a hollow diamond at one end of the whole.
Note: The meaning of this simple form of aggregation is entirely conceptual. The hollow diamond only separates the whole from the part. This means that simple aggregation does not change the navigation meaning of the entire association between the whole and the part. It is also independent of the declaration cycle of the whole and the part.
3, other featuresSimple, unmodified dependencies, generalizations, and associations with names, multiplicity, and roles are the most common features that are required to create abstractions. In fact, for most of the models built, the basic form of these three relationships is sufficient to express the most important semantics of the relationship. However, it is sometimes necessary to visualize or detail other features such as combinatorial aggregation, navigation, discriminant, association classes, special kinds of dependencies, and generalization. These and many other features can be expressed in UML. But they are all treated as high-level concepts.
dependencies, generalizations, and associations are static things that are defined at the level of the class. In UML, these relationships are typically visualized in a class diagram.
When you start modeling at the object level, especially when you start to work on the dynamic collaboration of these objects, you will encounter the chain (it is an associated instance that describes the connection between the objects that may send the message).
4, drawing styleTypically, modelers use one of the following two styles to draw lines:
A, use a diagonal line at any angle. Use only one line segment unless you want to avoid using other characters with multiple segments.
B, to draw the line parallel to the edge of the page. In addition to using a line segment to connect two side-by-side characters, the line is drawn as a set of segments connected at right angles.
5, Common modeling technology5.1, modeling for simple dependenciesA common dependency is a dependency between two classes, in which one class simply uses another class as its operational parameter. To model this usage relationship, do the following:
Create a dependency from the class that contains the action to the class that is used as a parameter by the operation.
5.2, modeling for single inheritanceIn lexical modeling of systems, it is common to encounter classes that are similar in structure or behavior to other classes. Each class can be modeled as a separate, unrelated object. But a better approach is to extract all of the common and behavioral traits and promote them into more general classes, from which special classes inherit these characteristics.
To model an inheritance relationship, do the following:
A, given a set of classes, looks for common responsibilities, attributes, and operations for two or more two classes.
b, promote these common responsibilities, attributes and operations to a more general class. If necessary, create a new class to allocate these elements (but be careful not to introduce too many layers)
C, draw a generalization relationship from each special class to its more general parent class to represent the more specific class that inherits the more general class.
5.3, modeling the structure relationshipwhen modeling with dependency and generalization relationships, it is possible to model classes that represent different levels of importance or different levels of abstraction. Given a dependency between two classes, one class relies on another, but the latter has no relation to the former. Given a generalization relationship between two classes, the subclass inherits from its parent class, but the parent class does not have any information that is unique to the child class. In short, both dependency and generalization relationships are asymmetric.
When modeling with association relationships, the two classes that are equal to each other are modeled. Given the association between the two classes, the two classes are somehow interdependent and often navigate from one side to the other. Dependency is the use of relationships, generalization is the "is-a-kind-of" relationship, and the association describes the structure path of the interaction between the objects of the class.
To model structural relationships, do the following:
A, for each class, if you need to navigate from object of one class to object of another class, describe an association between the two classes. This is an associated data-driven view.
B, for each class, if the object of one class is to interact with an object of another class, the latter is not the process local variable or operation parameter of the former. It is necessary to describe an association between these two classes. This is an associated behavior-driven view.
c, for each of these associations, describe their diversity (especially when multiplicity is not *, where * is the default multiplicity) and the role name (particularly when it helps to interpret the model)
D, if a class in an association is a whole in structure or organization compared to a class on the other end, and the latter looks like its part, it is decorated with a diamond at one end near the whole to mark it as an aggregation.
5.4, Tips and trickswhen modeling relationships with UML, the following strategies are followed:
A, use dependencies only if the modeled relationship is not a structural relationship.
B, generalization is only used when the relationship is a "is-a-kind-of" relationship. Aggregations can often be used instead of multiple inheritance.
C, be careful not to introduce a circular generalization relationship
d, it is generally necessary to maintain the balance of the generalization relationship: the hierarchy of inheritance should not be too deep (about more than 5 layers to think about), nor too wide (instead of looking for possible intermediate abstract classes)
E, association is mainly used for the structure of the object between the place. Do not use associations to represent temporary relationships, such as parameters or local variables of a procedure
when you use UML to draw relationships, follow these strategies:
A, use a straight line or slash in unison. The visual cues given by straight lines emphasize that the connection between related things is focused on a common thing. In complex graphs, slashes often have better spatial effects. Using two types of linetypes in the same diagram helps to steer people's attention to different relationship groups.
B, avoid cross-linking unless absolutely necessary.
C, showing only the necessary relationships to understand specific groups of things. Avoid the use of more relationships (especially more associations).
UML Modeling QuickStart 04 Basic Structure Modeling Relationships
