UML Class Diagram Relations Daquan

UML Class Diagram Relations Daquan1. Association


Bidirectional Association:
C1-C2: Refers to both sides know each other's existence, can call each other's public properties and methods.

This is described in the GOF design pattern book: Although this relationship is applicable in the analysis phase, we feel that it is too abstract to describe the class relationship within the design pattern, because the association relationship must be mapped to an object reference or pointer in the design phase. Object references are inherently self-contained and better suited to expressing the kind of relationship we are talking about. Therefore, this relationship is less used in the design time, the association is generally a direction.

The code generated by using Rose is this:Class C1
... {
Public
C2* theC2;

};

Class C2
... {
Public
C1* theC1;

};

Two-Way association in the code of the performance of both sides have a pointer to each other, of course, can also be a reference or value.





One-Way Association:
C3->C4: Indicates an acquaintance relationship, meaning that C3 knows C4,C3 can invoke the public properties and methods of C4. There is no life-time dependency. is generally represented as a reference.

The generated code is as follows:

Class C3
... {
Public
c4* theC4;

};

Class C4
... {

};

The one-way association code behaves as C3 has C4 pointers, and C4 is ignorant of C3.

Self-correlation (reflexive Association):
Himself by quoting himself, with a reference of his own.

The code is as follows:

Class C14
... {
Public
c14* theC14;

};

is to have a self-reference within yourself.

2. Aggregation/Combination

When there is a whole-part relationship between classes, we can use combinations or aggregations.



Aggregation: Represents the C9 aggregation C10, but C10 can leave the C9 and exist independently (independently of the meaning that this class exists in the problem domain of an application. How to solve this sentence, please see the following in the combination of explanations).

The code is as follows:

Class C9
... {
Public
C10 theC10;

};

Class C10
... {

};

Combination (also known as containment): The general is a solid diamond plus solid line arrows, as shown, indicates that C8 is C7 tolerant, and C8 can not leave C7 and independent existence. But this is depending on the problem domain, for example, in the field of care for cars, tires must be combined in the car category, because it is meaningless to leave the car. But in the business of selling tires, even if the tires leave the car, it makes sense, and it can be aggregated. In "agile development" also said that a combination B, then a need to know the life cycle of B, that is, may be responsible for generating or releasing B, or a in some way to know the generation and release of B.

Their code is as follows:

Class C7
... {
Public
C8 theC8;

};

Class C8
... {
};

You can see that the code and the aggregation are the same. Specific how to distinguish, may only be used to distinguish the meaning of words.

3. Reliance



Depend on:
Refers to C5 may need to use some of the methods of C6, can also say, to complete all the functions of C5, must have C6 method of assistance. C5 relies on the definition of C6, which typically contains the C6 header file in the header file of the C5 class. Rose does not produce a property on the dependency relationship.

Note that you want to avoid two-way dependencies. In general, there should be no bidirectional dependencies.

Rose generates the following code:

C5.h
#include "C6.h"

Class C5
... {

};

C6.h
#include "C5.h"

Class C6
... {

};

Although Rose does not generate attributes, it is generally formally a method in a that uses the object of B as a parameter (assuming a depends on B). As follows:

#include "B.h"
Class A
... {
void Func (B &b);
}

What is the difference between dependency and aggregation \ combination, correlation, etc.?

Association is a relationship between classes, such as teachers teaching students, husbands and wives, water bottles and so on is a kind of relationship. This relationship is very obvious and can be derived directly from the analysis in the problem area.

Dependency is a weak association, as long as one class is used to another class, but the relationship to another class is not too obvious (it can be said that the "uses" the Class), it can be regarded as a dependency, dependence can be said to be an accidental relationship, rather than the inevitable relationship, that is, "I used it in some way, But in reality I don't have much to do with it. " Like me and the hammer, I had nothing to do with the hammer, but I used it when I was going to nail a nail, and it was a dependency that depended on the hammer to nail the nail.

The combination is a whole-part relationship, which is obvious in the problem domain, and can be obtained by direct analysis. For example, tires are part of a car, leaves are part of the tree, hands and feet are part of the body of this relationship, a very obvious whole-part relationship.

Several of these relationships (associations, aggregations/combinations, dependencies) may appear in code in another class in the form of pointers, references, values, and so on, but logically they have the difference.

It is also stated here that the so-called relationships are only valid in a problem domain, leaving the problem domain, which may not be the case, for example, in a problem domain, I am a carpenter, need to take a hammer to work, perhaps the whole question is the description of how I nailed the table with the hammer, nailed the chair, nailed the cupboard Since the whole problem is to describe this, I and the hammer is not only accidental dependence, I and the hammer relationship becomes very close, may rise to a combination of relations (let me suddenly think of the martial arts swordsman Sword, the sword died ... ）。 This example may be a bit absurd, but it is also to illustrate the truth that relationships and classes are all set up in a problem area, leaving the problem domain and they may no longer exist.


4. Generalization (inheritance)



Generalization relationship: Used when two classes have generalized relationships, such as fathers and children, animals and tigers, plants and flowers.
The code rose generates is simple, as follows:

#include "C11.h"

Class C12:public C11
... {
};

5, here by the way to mention the template



The code for the above diagram corresponds to the following:

Template<int>
Class C13
... {
};

Repeat here again, in fact, after reading the above description, we should understand the relationship between the relationships and specific to the code is how, so-called repetition, is only the above extension, such as A and B has a "1-to-many" of the repetition, there is a list in a, which holds the B object's n references , that's it.

Well, to here, already put the above diagram of the relationship is finished, I hope you can have some gains, I also spent a lot of time ah (drawing, generate code, write to the blog, alas, a sweat). But it's worth it if you can get a thorough understanding of these relationships in UML class diagrams. :)


+++++++++++++++++++++++++++++++++++++++++++++++++++++

In UML modeling, it is important to understand the elements that appear on the class diagram. The developer must understand how to convert the elements appearing on the class diagram into Java. With Java as the representative of some examples of the Internet, here are some basic personal collection and summary: basic element symbols: 1. Class (Classes) class consists of 3 components. The first one is the class name defined in Java. The second is a property (attributes). The third is the method provided by the class. You can attach a visibility modifier before the property and operation. A plus sign (+) indicates a public visibility. A minus sign (-) indicates private visibility. #号表示受保护的可见性. Omitting these modifiers indicates visibility with the package level. If the property or operation has an underscore, it is static. In an operation, you can list the parameters it accepts as well as the return type, as shown in:

2. Package packages are a general-purpose combination mechanism. A package in UML directly corresponds to a package in Java. In Java, a package may contain other packages, classes, or both. When modeling, you typically have logical packages that are primarily used to organize your models. You'll also have a physical package, which is converted directly to the Java package in the system. The name of each package uniquely identifies the package.

3. The interface (Interface) interface is a collection of operations that specifies the services provided by a class. It corresponds directly to an interface type in Java. The interface can be represented by one of the following icons (above a circle symbol, the circle symbol below is the interface name, the middle is a straight line, the line below is the method name), or it may be represented by a standard class with <<interface>> attached. Typically, you know the relationship to other classes based on what the interface looks like on the class diagram.

Relationship: 1. A "use" relationship between dependent (Dependency) entities implies that the specification of an entity changes and may affect other instances that depend on it. More specifically, it can be converted to any type of reference to a class or object that is not within the scope of the instance. This includes a local variable, a reference to an object obtained through a method invocation (as shown in the following example), or a reference to a static method of a class (without an instance of that class). You can also use dependencies to represent the relationship between packages and packages. Because the package contains classes, you can represent the relationship between packages and packages based on the relationships between the classes in those packages.

2. A structured relationship between the associated (association) entities indicates that the objects are interconnected. The arrows are optional and are used to specify navigation capabilities. If there are no arrows, hinting is a two-way navigation capability. In Java, the association is converted to an instance-scoped variable, just as the code shown in the Java area of Figure E. Additional modifiers can be attached to an association. The multiplicity (multiplicity) modifier implies a relationship between instances. In the model code, an employee can have 0 or more timecard objects. However, each timecard only belongs to a single employee.

3. Aggregation (Aggregation) aggregation is a form of association that represents a global/local relationship between two classes. Aggregation implies that the whole is conceptually at a higher level than the local, and the association implies that two classes are conceptually at the same level. Aggregations are also converted to an instance-scoped variable in java. The difference between association and aggregation is purely conceptual, and is strictly reflected in semantics. Aggregation also implies that there are no loops in the instance diagram. In other words, it can only be a one-way relationship.

4. Synthetic (composition) synthesis is a special form of aggregation that implies a "partial" lifetime responsibility within the "whole". The composition is also unshared. Therefore, although the local does not have to be destroyed with the overall destruction, but the overall responsibility to maintain a local survival, or be responsible for destroying it. Local cannot be shared with other whole. However, the whole can transfer ownership to another object, which will then assume the lifetime responsibility. The relationship between employee and timecard may be better represented as "compositing" rather than "associative".

5. Generalization (generalization) generalization represents a relationship between a more generalized element and a more specific element. Generalization is a UML element that is used to model inheritance. In Java, this relationship is represented directly by the extends keyword.

6. The implementation (Realization) instance relationship specifies a contract between two entities. In other words, one entity defines one contract and the other guarantees the performance of the contract. When modeling a Java application, the implementation relationship can be expressed directly with the Implements keyword.

Like aggregation is divided into: non-shared aggregation, shared aggregation, composite aggregation and so on. and other content, add it next time.

UML Class Diagram Relations Daquan