Go A summary of several relations of UML common graphs

In UML class diagrams , the following relationships are common: generalization (generalization), implementation (realization), Association (association), Aggregation (Aggregation), composition (composition), dependent (Dependency)

1. Generalization (generalization)

Generalization relationship: is an inheritance relationship that represents a general and special relationship that specifies how subclasses can characterize all the characteristics and behaviors of a parent class . For example, tigers are a kind of animal, that is, the characteristics of tigers have animals in common.

Arrow pointing to: Solid line with triangular arrows, arrow pointing to Parent class

2. Implementation (realization)

Implement relationship: is a class-to-interface relationship that indicates that a class is an implementation of all the characteristics and behaviors of an interface .

Arrow pointing: Dashed line with triangular arrows, arrow pointing to Interface

3. Association (Association)

Association: An owning relationship that enables a class to know the properties and methods of another class, such as: teachers and students, husbands and wives

Associations can be bidirectional or unidirectional. Two-way associations can have two arrows or no arrows, and one-way associations have an arrow.

"Code embodiment": member variable

Arrows and points: solid lines with normal arrows (or solid triangular arrows), pointing to the owner

, teachers and students are two-way association, the teacher has many students, students may also have more than one teacher. But the relationship between a student and a course is a one-way link, a student may have to take many courses, the course is an abstract thing he does not own students.

To associate itself with:

4. Aggregation (Aggregation)

"Aggregation relationship": is the whole and part of the relationship , and some can leave the whole and exist alone . As the car and the tyre are the whole and part of the relationship, the tires leaving the car can still exist.

The aggregation relation is one kind of association relation, is the strong association relation, the Association and the aggregation cannot distinguish syntactically, must examine the concrete logical relation.

"Code embodiment": member variable

"Arrows and points": solid lines with hollow diamonds, diamonds pointing to the whole

5. combination (composition)

"Combinatorial relationship": it is the relationship between the whole and the part , but the part cannot leave the whole and exist alone . if the company and Department are the whole and part of the relationship, no company does not exist in the department.

A combinatorial relationship is a relationship that is stronger than the aggregation relationship, which requires that an object representing the whole in an ordinary aggregation relationship be responsible for the life cycle of the object representing the part.

"Code embodiment": member variable

Arrows and points: solid lines with solid diamonds, diamonds pointing to the whole

6. Dependency (Dependency)

Dependency: A relationship that uses a class that requires the assistance of another class , so try not to use two-way interdependence .

"Code representation": A local variable, a parameter to a method, or a call to a static method

Arrows and points: dashed lines with arrows pointing to the user

The order of strength of the various relationships:

Generalization = implementation > Composition > Aggregation > Association > Dependencies

The following UML diagram shows the various class diagram relationships in a more vivid way:

====================================================

sequence Diagram mainly used to show the order of interactions between objects.

A sequence diagram represents an interaction as a two-dimensional graph. The vertical is the timeline, and the time extends downward along the vertical bar. The horizontal axis represents the meta roles of individual objects in collaboration. The class meta role is represented by a lifeline. When an object is present, the character is represented by a dashed line, and the lifeline is a double-lane when the object's procedure is active.

Messages are represented by arrows from the lifeline of one object to the lifeline of another object. The arrows are arranged in chronological order from top to bottom in the diagram.

Elements involved in a sequence diagram:

1. Lifeline:

The lifeline name can be underlined. When an underscore is used, it means that the lifeline in the sequence diagram represents a specific entity of a class.

2. Synchronizing messages

The sender waits for a synchronous message response before it continues

3. Asynchronous messages

Messages that do not wait for a response before the sender continues

4. Notes

5. Constraints

The symbol for the constraint is simple; the format is: [Boolean Test]

6. Combining fragments

combined fragments are used to solve the conditions and methods of interactive execution . It allows a logical component to be represented directly in a sequence diagram to define special conditions and sub-processes for any part of any lifeline by specifying the conditions or the area of application of the child process.

Common combinations of fragments are:

A. choice (ALT)

The choice used to indicate a mutually exclusive selection between two or more message sequences, equivalent to the classic if. else ...

The choice takes place only one sequence in any situation. You can set a threshold in each fragment to indicate the conditions that the fragment can run. Else The critical indicates that any other critical is not true when the fragment should run. If all the thresholds are False and there is no else, no fragments are executed.

B. option (OPT)

Contains a sequence that can or does not occur

C. loops (Loop)

The fragment repeats a certain number of times. You can indicate the condition of the fragment repetition in the threshold.

D. parallelism (Par)

The following table lists the commonly used combined fragments:

Fragment type	Name	Description
Opt	Options	Contains a sequence that may or may not occur. You can specify the condition in which the sequence occurs in the critical.
Alt	Choice	Contains a list of fragments that contain an alternate message sequence. Only one sequence occurs on any occasion. You can set a threshold in each fragment to indicate the conditions that the fragment can run. Else The critical indicates that any other critical is not true when the fragment should run. If all the thresholds are False and there is no else, no fragments are executed.
Loop	Cycle	The fragment repeats a certain number of times. You can indicate the condition of the fragment repetition in the threshold. Loop Combo fragments have the min and Max properties, which indicate the minimum and maximum number of times a fragment can be repeated. The default value is unrestricted.
Break	Interrupt	If this fragment is executed, the remainder of the sequence is discarded. You can use a guard to indicate the condition in which the interrupt occurred.
Par	Parallel	Parallel processing. Events in a fragment can be interleaved.
Critical	The essential	Used in Par or Seq fragments. Indicates that messages in this fragment must not be interleaved with other messages.
Seq	Weak order	There are two or more operand fragments. Messages involving the same lifeline must occur in the order of the fragments. Messages from different fragments may be interleaved in parallel if the message involves a different lifeline.
Strict	Strong order	There are two or more operand fragments. These fragments must occur in the given order.

Fragment about how to interpret a sequence

By default, a sequence diagram indicates a series of messages that may occur. On a running system, you may see other messages that you have not selected to display on the diagram.

The following fragment types can be used to change this interpretation:

Fragment type	Name	Description
Consider	Consider	Specifies the list of messages described by this fragment. Other messages can occur on a running system, but this is not a very meaningful description. Type the list in the Messages property.
Ignore	Ignore	A list of messages not described in this fragment. These messages can occur in a running system, but it does not make much sense for this description. Type the list in the Messages property.
Assert	Assertion	The operand fragment specifies the only valid sequence. Typically used in consider or Ignore fragments.
Neg	Negative	The sequence shown in this fragment must not occur. Typically used in consider or Ignore fragments.

====================================================

Use case diagrams are primarily used to describe the relationships between users, requirements, and system functional units . It shows a model diagram of a system function that an external user can observe.

"Purpose": helps the development team to understand the functional requirements of the system in a visual way.

use case diagram The following elements are included:

1. Participant (actor)

Represents a user, organization, or external system that interacts with your application or system. With a villain.

2. Use Cases

Use cases are externally visible system functions that describe the services provided by the system. To represent with an ellipse

3. Subsystems (Subsystem)

Used to show a part of the system function, this part of the function is closely related.

4. Relationship

The relationships involved in the use case diagram are: Association, generalization, inclusion, extension;

As shown in the following table:

Relationship Type	Description	Representing symbols
Association	The relationship between the participant and the use case
Generalization	Relationships between participants or use cases
Contains	The relationship between use cases
Extended	The relationship between use cases

A. Association (association)

Represents the communication between a participant and a use case, and either party can send or accept a message.

Arrow point to: Point to the message receiver

B. Generalization (inheritance)

Is the commonly understood inheritance relationship, where the child use case is similar to the parent use case, but behaves more specifically, and the child use case inherits all the structures, behaviors, and relationships of the parent use case. A child use case can use a section of the parent use case, or it can be overloaded. The parent use case is usually abstract.

Arrow pointing to: pointing to the parent use case

C. Include (include)

The inclusion relationship is used to break down the functions represented by a more complex use case into smaller steps;

"Arrow pointing": pointing to decomposed function use cases

D. Extensions (Extend)

An extension relationship is an extension of a use case feature, which is equivalent to providing an additional function for the underlying use case.

Arrow pointing to: pointing to the underlying use case

E. Dependency (Dependency)

The above 4 relationships are standard relationships defined by UML. However, in the VS2010 use case Model diagram, a dependency is added with a dashed line with arrows

Indicates that the source use case relies on the target use case;

"Arrow pointing": pointing to a dependent

5. Project (Artifact)

Use case diagrams are used to help people visualize functional needs, but few people can understand it. Many times communicating with users or even using Excel is stronger than use case diagrams, and VS2010 introduces an element such as "project," which allows developers to link a common document in a use case diagram.

To rely on a use case for a project

Then set the project-"HYPERLINK" property to your document.

This opens the associated document when you double-click the item on the use case diagram.

6. Notes (Comment)

include (include), extension (extend), generalization (inheritance) differences:

Conditionality: The sub-use cases in generalization and included in the include are unconditionally occurring, while the occurrence of extension cases in extend is conditional;

Directness: Child use cases in generalization and extension cases in extend provide direct service to participants, while the use cases included in the include provide indirect services to participants.

For extend, the extension use case does not contain the content of the underlying use case, nor does the underlying use case contain the content of the extension use case.

For inheritance, a child use case contains all the contents of the underlying use case and its relationship to other use cases or actors;

A use case diagram example:

Complaints:

The sense of use case diagram is immature, and does not represent the requirements of the system very well, and users without UML backgrounds hardly know what to draw.

Secondly, the arrow symbols that contain the relationship and extend the relationship are the same arrows, which can be distinguished only by writing a text above, and translated into other languages, almost without knowing what it means. The arrow facing the extended relationship is also difficult to understand, why point to the base use case, not to the extension case

VS2010 adds a "project" element that is a good innovation to associate word,excel these documents in a use case diagram. But why not integrate these functions directly into the use case, double-click the use case to pop up a document is not much easier to understand, it is necessary to add a component, just to provide a link function.

Use Case Description Table:

Since the use of diagram does not clearly express the functional requirements, the development of people usually use a description table to supplement some difficult to express use cases, the table provides a reference for you:

Go A summary of several relations of UML common graphs