Software Engineering accumulation-UML use case diagram

1. Introduction to UML

UML (Unified Modeling Language) is a visual modeling language that is well defined, easy to express, powerful, and universally applicable. It integrates new ideas, new methods, and new technologies in the software engineering field. Its scope is not limited to supporting object-oriented analysis and design, but also supporting the entire process of software development starting from requirement analysis. In the system analysis phase, we generally use UML to draw many diagrams, including the use case diagram, status diagram, class diagram, activity diagram, sequence diagram, collaboration diagram, construction diagram, and configuration diagram, which images should be drawn depends on the actual situation. In fact, a simple understanding is also a personal understanding. The role of UML is to use a lot of diagrams to fully describe the system we will develop from the static and dynamic aspects.

II. Introduction to case Modeling

Case modeling is a part of UML modeling and the most basic part of UML. The main function of case modeling is to express the functional requirements or behaviors of the system. In my understanding, Case modeling can be divided into use case diagrams and case descriptions. A Use Case chart consists of actors, use cases, system boundaries, and arrows. The use case description is used to describe each use case in the use case diagram in detail and is completed in a text document.

1. use case diagram

A participant is not a specific person, but a role outside the system in the use of a system or in interaction with the system. Therefore, participants can be people, things, time, or other systems. Note that participants do not refer to people or things themselves, but to the roles played by people or things at the time. For example, James is the administrator of the library. He participates in the interaction of the library management system. At this time, he can take the role of the Administrator to participate in management, or as a borrower to borrow books from the library, here, James plays two roles, two different participants. The participants are illustrated with simple characters, and the names of the participants are attached to the figures.

A use case is a description of a group of action sequences, including variables. The system executes these actions and generates the observed results that pass the value of a specific participant. This is the formal definition of the use case in UML, which may be difficult for beginners. We can understand that use cases are what the participants want the system to do. For case naming, we can give the case a simple and descriptive name, generally a word with attention. The use case is represented by an ellipse in the drawing. The name of the use case is attached to the ellipse.

The system boundary is used to represent the boundary of the modeling system. Within the boundary, it indicates the components of the system, and outside the boundary, it indicates the system exterior. The system boundary is displayed in a box in the drawing, and the system name is attached. 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, I personally understand that it can be omitted when drawing.

Arrows are used to indicate the associations between participants and the system by sending signals or messages to each other. The tail of the arrow is used to indicate the Start side of the interaction, and the head of the arrow is used to indicate the Start side. The use case is always started by the participants.

2. use case description

The use case diagram simply describes the system with a diagram, but we also need to have a detailed description of each use case so that others can have a more detailed understanding of the system, in this case, we need to write the case description.

There is generally no hard format for the content of the case description, but some of the necessary or important content must be written into the case description. Use case description generally includes: Brief description (description), prerequisite conditions, basic event stream, other event streams, abnormal event streams, and post (post) conditions. The following describes the meaning of each part:

Brief description: a brief description of the role and purpose of the use case;

Prerequisites: conditions that must be met or in the system before the execution of the use case;

Basic event stream: describes the basic process of this case. It refers to what happens when every process is "normal" and there is no alternative stream or abnormal stream, and only the most likely event stream;

Other event streams: indicates that this action or process is optional or optional, and does not always need to be executed;

Abnormal event stream: indicates the process to be executed when an abnormal event occurs;

Post condition: the status of the system after the use case is executed;

3. use case diagram and use case description Design Example

Here, I developed a tutor website to analyze the usage case diagram and use case description. I used UML for a complete analysis of this website. Below I extracted the use case diagram and use case description. This tutor website is divided into the front-end customer system and the back-end management system.

The example of the front-end customer system is shown below:

The following is an example of the background management system:

The use case description is limited. Here I only describe how to publish website announcements in the background management system. As follows:

Case name: Website announcement

Use Case ID202

Participants: Owner

Brief Description: The owner is used to fill in and modify the home page announcement of the tutor website. The announcement is displayed on the home page of the tutor website.

Prerequisites: The Administrator has logged on to the tutor website management system.

Basic event stream: 1. The owner clicks the "Modify announcement" button. 2. The system displays a text box showing the original announcement content. 3. The owner can modify or delete the announcement in the text box and re-write the new announcement. 4. After editing the text box, press the "Submit" button to modify the homepage announcement. 5. Use case termination

Other event streams A1: Before you press the "Submit" button, the owner can press the "return" button at any time. Any modification to the text box will not affect the announcement of the website homepage.

Abnormal event stream: 1. An error message is displayed. The owner confirms the error message. 2. Go back to the Management System homepage.

Post Condition: The announcement information on the homepage is modified.

Note: None

Iv. Summary

In fact, Case modeling is not so simple. It involves a lot of knowledge. Here is a brief introduction.

Thanks to: http://www.51cto.com Source: 51cto.com Finishing

Supplement:

There can also be relations between use cases, such as inclusion, extension, and generalization:

(1) Inclusion relationship: A use case can simply contain the behaviors of other use cases and Use Case behaviors contained in it as part of its own behaviors. This is called an inclusion relationship.

(2) extended relationship: the extended relationship is the relationship from the extended case to the basic case. It shows how the behavior defined for the extended case is inserted into the behavior defined for the basic case. It is inserted in implicit form, that is, the extended use case is not displayed in the basic use case. You can use extended use cases in the following situations:

A. indicates that a part of the use case is an optional system action (in this way, you can separate the optional and mandatory actions in the model );

B. indicates the branch stream that is executed only under certain conditions (such as exceptions;

C. It indicates that there may be a group of behavior segments, one or more of which can be inserted at the extension points in the basic use case. The inserted behavior segments and Insertion Sequence depend on the interaction with the main character when executing the basic use case.

Figure 2.3 provides an example of an extended relationship. In the course of returning a book, the branch stream of the lost book will be compensated only when the exception (the reader loses the book) occurs.

(3) Generalization relationship: Use Cases can be specifically listed as one or more sub-use cases, which are called generalization of use cases. When a parent use case can be used, any child use case can also be used. For example, in Figure 2.4, ticket booking is an abstraction of telephone booking and online booking.

------------------------------------------------------------

Generalization, inclusion, and expansion

Generalization(Generalization) is everywhere in object-oriented technology. Another name of it may be more famous, namely "inheritance ". A general example is provided:

We can see that in the use case diagram, roles and use cases can be generalized. It is easy to understand the generalization/inheritance of a role. Because a role is a class, it is a class with a fixed type (stereotype) as an actor. Therefore, the inheritance of a role is intuitive and natural. However, the inheritance of use cases can be divided into two types: extended and include.

The action steps used for the extension are basically the same as those for the parent case. However, when additional steps are added. Contains actions used for a subcase that contain all parent cases. It uses the parent case as its own big step. A subcase often contains more than one parent case. For example:

 

From: http://blog.csdn.net/dl88250/article/details/1826713