UML diagram detailed (ii) use case diagram __uml

first, the concept

use case diagram (Diagram): Primarily used to describe the behavior of systems and the relationships between functions, is a graph that describes the relationship between participants (Actor) and use cases, and use cases and use cases.

Use case diagram = actor + use case + Relationship II, use use case diagram shows who will be relevant users, what services users want the system to provide, and what users need to provide for the system. Use case diagrams are most commonly used to describe systems and subsystems.

In layman's terms: The use case diagram is not related to the concrete implementation, analyzing and investigating the behavior of the system from the point of view of the user and the external system, and describing the function characteristics of the system provided by the interaction between the participant and the system . Three, the use case diagram contains elements 1. Participants (Actor) can be people or other external systems. The initiator of the force, the participant is outside the use case and can initialize a use case and participate in the execution of the use case, but it is not part of the system. Each participant can participate in one or more use cases.

Presentation mode:

(In this way, the name of the participant is written below.) It is recommended to use this method to understand the image. ）

UML2. O represents the method of the participant:

(In this way, name is the participant's name, and "Actor" is a stereotype that indicates that the current element is a participant.) ）

To find participants , you can find participants in the system based on the following questions: Who or what is using the system, what role they play in the interaction, who installs the system, who initiates and shuts down the system, who maintains the system, what system interacts with the system, who gets information from the system, and who provides the information to the system;

Participant-related considerations: participants are external to the system, and they are outside of system control. Participants directly interact with the system to help define system boundaries. Participants represent the roles that people and things play when interacting with the system, rather than the specific person or thing. A person and thing can play multiple roles when interacting with the system. Example: A graduate student as a teaching assistant to a professor, from a career perspective, has played two roles-students and teaching assistants. Each participant needs to have a name that has business semantics. Each participant must have a short description, describing what the participant is from the business perspective. Participants can have columns that represent the participant properties and the events that it can accept. A generalization relationship can be used by a contributor to describe the public behavior between multiple participants. 2. Use cases is a description of a set of action sequences (business workflows) that the system performs to produce an observable result for the participants in the system. Use cases reflect the needs of users. A use case is a descriptive document that describes the order in which a participant uses the system to complete an event. Use cases, which describe the interaction between the participant and the system, are the process of using a system, a description of the user functional requirements of the system, and a use case that expresses the functions of the system and the services provided.

Presentation mode:

ways to identify use cases : Start with the participants in the analysis system and consider how each participant uses the system.

The following questions can help identify the use case: what function does a particular participant want the system to provide to store and retrieve information, and if so, which participant triggers when the system changes state, notifies the participant whether there are external events that affect the system? Which participant notifies the system of these 3. Association Relationship (Association)

Is the simplest and most commonly used relationship between a participant and a use case

4. Include relationship (include)

Separate the common steps of several use cases into a single contained use case; The containing use case is called the customer use case, which is called the provider use case.

use case A contains use case B, which is called a base use case, and B is called the included use case.

Contains a relationship representation base using a included use case. The event stream that contains the use case is inserted at a point in the base use case into the event flow of the base use case.

include relationship representation:

The base use case is attached to the end of the dashed arrow, the arrow points to the included use case, and an include tag is added to the dotted line to represent the extended relationship.

usage Scenario: If two use cases have a lot of consistent functionality, you can decompose this functionality into another feature. Other use cases can have an inclusion relationship with the use case, and a use case can have too many functions to model two small use cases using the inclusion relationship. 5. Extended Relationship (Extend)

Extensions allow each use case to extend the functionality of the base use case by adding additional behavior to the base use case.

use case A expands use case B, then a is called an extension use case or a child case, and B is expressed as a base use case.

The event flow of extension case A is inserted into and use cases according to the appropriate extension points, which requires defining one or more named extension points in and use cases. (This is not the same as the inheritance relationship)

An extended relationship can be used to encapsulate some optional operations separately in another use case, avoiding the complexity of the base use case.

Presentation mode:

The extension use case is connected to the end of the dashed arrow, the arrow points to the base use case, and adding a "extend" to the dotted line indicates an extended relationship.

6. Generalization relationship (generalization)

A generalization relationship is a relationship between two use cases or two participants.

The generalization relation can be understood as the inheritance in object-oriented relation in fact. The commonality in multiple use cases that have a similar structure and behavior is abstracted to the parent use case, which inherits all of the parent use case.

Presentation mode:

A solid line with a hollow arrow indicates that the child case is connected to the end of the arrow and the arrow points to the parent use case.

7. The difference between extended and inclusive relationships

Same point: is a relationship between two use cases. (Only a generalization relationship can represent two use cases, or it can be between two participants)

different points: conditionality: An extended relationship that contains an unconditional relationship is a conditional insertion principle: The event stream that contains the use case must be inserted into and the use case in the containing relationship. Extended relationships can determine whether to insert the event flow of an extended use case into the base use case event flow based on certain criteria. insertion point: There is only one insertion point in the containing relationship. The insertion point of an extended relationship can have more than one. Iv. System Boundaries

Requirements: Each function in a system has its own scope. And when deciding on a participant, designing a system, subsystem, or part, dividing a system boundary is important for determining the size of the system and assigning responsibility.

representation of system boundaries (systems boundary):

In UML, rectangular boxes are used to express the boundary of the system, and the top left of the rectangle box prevents the system from being named.

In the blog I wrote two blog is the collation of resources, may be helpful to everyone, you can see if you are interested. Resource broadcast-book and video tutorials. Common Software-Finishing

Blog number: 20160611151303