UML Use case diagram

I. Introduction to UML Use case modeling

Use case modeling is part of UML modeling, and it is the most basic part of UML. The most important function of use case modeling is to express the functional requirements or behavior of the system. According to my understanding use case modeling can be divided into use case diagrams and use case descriptions. Use-case diagrams are composed of actors (actors), use cases (using case), system boundaries, and arrows, which are done by drawing. Use case descriptions are used to describe each use case in detail in a use case diagram and are completed with a text document.   The use case diagram also includes various relationships consisting of arrows, including generalization, inclusion, extension, and so on. 1. Use case diagram (1) participant (actor), also known as an action person, indicates the role that the system user can play. These users may be people, possibly other computers, some hardware, or even other software systems. The only criterion is that they must be outside the system part that is divided into the use case.        They must be able to stimulate the system part and receive the return. It is also important to note that the participant does not refer to the person or the thing itself, but to the role of the person or thing at that time. For example, Xiao Ming is the librarian of the library, he participates in the interaction of the library management system, when he can participate in the management as the administrator, also can borrow books from the library as a borrower, here Xiaoming plays two characters, is two different participants. Participants are represented in a drawing with a simple pen figure, with the name of the participant appended to the character.
(2) Use cases. A use case is a description of a set of action sequences, including variables, that the system performs to produce an observable result value for the actor performing the action. We can understand that the use case is what the participants want the system to do.      For example, the calculator can be used as a use case, the user who uses the calculator is a participant, the participant presses the 3+3 (action sequence), the calculator Returns a result of 6. For the use case naming, we can give the use case a simple, descriptive name, usually with the action of the word. The use case is represented by an ellipse in the drawing, and the name of the use case is attached below the ellipse. (3) The system boundary is used to represent the boundary of the modeling system. Within the boundary represents the part of the system, outside the boundary representing the outside of the system. The system boundary is represented in the paint frame, accompanied by the name of the system, where the participant is drawn outside the boundary and the use case is drawn inside the boundary.   Because the function of the system boundary is sometimes not very obvious, so I personally understand that in the drawing can be omitted. (4) arrow. Used to indicate an association between a participant and a system that interacts by sending signals or messages to each other. The tail of the arrows is used to indicate the party that initiates the interaction, and the arrow head is used to indicate the party being started, where the use case is always initiated by the participant.
(5) Generalization. Generalization is the same as the generalization concept in a class, where the child use case inherits the behavior and meaning of the parent use case, and can also increase or overwrite the behavior of the parent use case, and the child use case can appear where any parent use case occurs (both parent and child have concrete instances). Here are two illustrations illustrating the concept and meaning of generalization (meaning inheritance and behavior inheritance, respectively). (6) use. Its relationship is much like a function call or a sub-procedure. A UML use case used in this way is called an abstract use case because it cannot exist alone and must be used by other use cases. Examples of UPC readers in the system boundary block diagram. (7) include. It is possible to separate the common steps of several use cases into a single included use case. Similar to the Include in C language. As shown in the figure above, querying employee information is a separate included use case. (8) Extend. An extended relationship is a relationship from an extended use case to a basic use case, which shows how the behavior defined for an extension use case is inserted into the behavior defined for the base use case. It is inserted in an implicit form, that is, the extension use case is not displayed in the basic use case. You can use extension cases in the following situations:

A. Indicate that a part of the use case is optional system behavior (so that you can separate the optional behavior and the required behavior in the model);

B. A sub-branch that indicates that it is executed only under certain conditions, such as exceptional conditions;

C. Indicates that there may be a set of behavior segments in which one or more segments can be inserted at the extension point in the base use case.      The inserted behavior segments and the order of insertions depend on the interaction with the protagonist when the basic use case is executed. The following illustration shows an example of an extended relationship in which the sub-branch of a lost book is executed only in the case of exceptional conditions (the reader loses the book).

  2. Use case description       use case diagram simply describes the system with a diagram, but for each use case, we need to have a detailed explanation, so that others can have a more detailed understanding of the system, Then we need to write the use case description.      there is generally no hard-to-specify format for the contents of use-case descriptions, but some of the necessary or important content must be written into the use-case description. Use case descriptions typically include: a brief description (description), preconditions (preconditions), basic event flow, other event flow, exception event flow, post (ex post) conditions, and so on. Here are the meanings of each part: A brief description: A brief description of the role and purpose of the use case; preconditions: the state that the system must be in before executing the use case, or the conditions to be met; Basic event Flow: The basic process of describing the use case, which is what happens when each process is "working" There is no alternate stream and no exception flow, only the most likely event flow; Other event streams: Indicates that the behavior or process is optional or alternative, not always to be executed; Exception flow: Indicates the process to be performed for something that is not normal; Post condition: The state that the system is in when the use case is executed.   Two, use case diagram and use case description Example       here is a tutor site to simply analyze the use case diagram of the drawing and use case description of the wording. The parts of use case diagrams and use case descriptions are extracted. This tutor site is divided into front-end customer systems and back-office management system.      Front-End Customer System use case diagram:           Backend Management system use case diagram:     Use case description for site announcements published in           backend management system:         

use case name : Website Bulletin Release

use case ID number : 202

participant : person in charge

Brief description : The responsible person used to fill in and modify the home page of the homepage of the announcement, the announcement finally displayed on the home page of the tutor website.

Pre-conditions: The person in charge has already landed the Tutor website management system

Basic Event Flow: 1. Responsible mouse click on "Modify Announcement" button 2. The system appears with a text box showing the original announcement content 3. The person responsible can modify the announcement on the text box, or it can be completely deleted, and the new announcement will be re-written. 4. The person responsible for editing the text box, press the "Submit" button, the first page announcement was modified 5. Use case termination

Other Event stream A1: Before pressing the "Submit" button, the owner can press the "back" button at any time, any changes in the text box will not affect the site home page of the announcement

Exception Event Stream : 1. Prompt error message, owner confirmation 2. Back to the admin system Main Page

Post conditions : The announcement information of the homepage of the website has been modified

Note: none

Iii. generalization, inclusion and extension examples

generalization (generalization) is ubiquitous in object-oriented technology, and its other name may be more famous as "inheritance." The following illustration shows a use case diagram that uses generalization: In the case diagram, roles and use cases can be generalized. The generalization/inheritance of a character is easy to understand, because a character is a class, and it is a class that is a version (stereotype) actor, so the inheritance of a character is intuitive and natural. However, the inheritance of use cases is actually divided into two cases, not simple generalization, but the use of extensions (extended) and the inclusion (include) of two kinds of generalization of the special case. Extending the action steps for a child use case is essentially the same as the action step of the parent use case, except for the addition of some additional steps. Contains an action for a child use case that contains all the parent use cases, which takes the parent use case as a large step, and the child use case often contains more than one parent use case. Figure below: