Demand Analysis of Use Cases-Reading Notes

[Sina Vivi] [poco network Abstract] [365key] [bo cai] [Yi You Xiang] [you abstract] [younote] [Tianji network Abstract] [Hexun network Abstract]

 

I. system boundaries and participants
Participant actor definition: Anything that makes meaningful interaction with the system outside the system through system boundaries
Reveal the characteristics of the participants:
1. does not belong to the System
2. Determine the system boundary through the system boundary and system interaction-> the determination of participants
3. Make meaningful interactions
4. Everything

Note: If a customer buys a ticket via a ticket conductor, the ticket conductor is a participant in the ticket sales system, but the customer is not.
This leads to the difference between business modeling and System Modeling: For the ticketing system, when business modeling, we describe customers to book tickets, there may be ticket center directors asking about tickets and other events. however, during system modeling, they are not our objects. We describe the event that the conductor wants to sell tickets and provide ticket sales information. Therefore, the two are different at different stages of modeling.

In some automatic systems, time is often an external thing that triggers system work. Therefore, participants are time and cannot be ignored.

How to identify participants: In the face of a system, you should ask these questions:
Who uses the system?
Who changes system data?
Who gets information from the system?
Who needs system support to complete daily work?
Who is responsible for managing and maintaining the normal operation of the system?
What hard devices should the system handle?
Does the system need to interact with other systems?
Who is interested in the results produced by the system?
What about external conditions such as time and climate?
After you answer these questions, your answers cover the candidates of the participants.

Importance of identifying participants:
1. Identify system use cases based on participants: therefore, to complete the functions of the system, you should not recognize fewer system participants.
2. During the testing and deployment phase, you may understand the system integrity from the perspective of the validator.
3. In the case document writing stage, participants are not very important, but you should consider the generalization relationship of participants to avoid repeated use cases.

Ii. Event Identification
Listing System events is a necessary condition for correctly establishing system use cases.

System events are classified into two types: system external events and system internal events.
External events are the specific work of external participants on system interaction, and internal events are the work triggered by the system, usually triggered by time.

How to identify events: brainstorm-Subject + Predicate + object: Describe what may happen in the system as comprehensively as possible, however, you can sort events by importance, which can deepen your understanding of the system.

Generally, the identified events are listed in a table named 3A.
Actor Action Aim
What are the business objectives of participants?
.........

Iii. Identify Use Cases
Use case definition: Use Cases are a group of use case instances.
Case instance definition: a series of actions performed by the system to generate the expected result values of the participants

Use case highlights:
1. Located in the system -- must be run by the System
2. Goal Orientation-Use Case operation must be purposeful
3. Stop at the boundary-results can be observed and interact with the outside.
4. User opinion-participant observation
5. granularity-it is composed of a group of instances with a common goal or a similar target.

The identification case starts from business modeling. That is to say, we describe the case to identify behavior from the user's point of view, that is, from the user's point of view. The description case is a pure business language rather than a technical language. for example, it is described as tax clearance, rather than J2EE architecture. therefore, the user name is also from the user's point of view, describing a user to do a purposeful and fruitful behavior through the system.

The granularity of use cases should not be too small. A detailed decomposition may lead to incorrect use case description:
1. Make the interaction step a use case instead of a series of steps as a use case. For example, user login is a use case, and the incorrect method is to use the user name entered in the request as a use case.
2. Some internal activities in the necessary processing process are called Use Cases: user verification, database connection, and SQL request sending are called use cases. In fact, they are all steps for users to log on to this interaction.
3. regard the work of identifying use cases as the work of relational database analysis: the error called a carriage, that is, crud (create read update delete ). for example, a user is managed as a use case, but it may become an intellectual mistake to add users, query users, modify users, and delete users. The system is the addition, deletion, modification, and query of data.

A key principle for identifying use cases is to analyze the user's purpose from the user's perspective, rather than from the system perspective, or from the data perspective.

The system events created can be used to draw Use Case Diagrams smoothly, but remember that "the nature of use cases is text". Therefore, we need to convert the use case diagrams into use case documents. you can use the following example to write the case document:
Case No:
Use Case Name:
Case Description:
Participants:
Prerequisites: the required system and environment status when you start the use case.
Post condition: the system and environment status at the end of the case
Basic path:
1 ..... ××××
2 ...... ××××
3 ..... ××××
Extension points:
2a. ××××
2a1 .... ×××××
Note:

Preconditions and preconditions can reflect the dependency between use cases. They can also prevent missing use cases.

Relationship between use cases: Extended extends, including include, Generalization