Use case analysis modeling

Use case analysis is a simple and convenient modeling method. The basic process is to analyze the existing use cases and find the relationship between the model classes, attributes and models in the domain. Therefore, the main input to modeling in this way is use cases. Writing a complete use case takes a lot of time and requires professional training. In real work, I have never seen a project with a complete use case. The most common one is the required PRD. I discussed using instantiation requirements to analyze the use cases. PRD analyzes and obtains business rules. We can use business rules to replace use cases.

Find nouns: We can simply list all the nouns in the use case. These nouns will be used as candidates for model classes or attributes.

Find verbs: Verbs can often be found between models.

Determine the model class and attributes: Determine the model class and attributes from the first step, mainly to determine which nouns should be used as classes and which as attributes; generally if they are single-valued nouns (or they can be (represented by basic data types) can often be used as attributes, or a noun is only associated with one concept

Determine the relationship between models: analyze the relationship between models through verbs

The whole step is very simple. You only need to find the nouns and verbs in the use case, and then assemble the scenario analysis. I have also seen on the intranet that the subject-predicate-object structure of the use case is analyzed, and the method is more refined. However, from the perspective of the analysis process, the two methods have similar effects. It will be more troublesome to analyze the steps through subject, predicate and object.

In addition, since the improvement of use cases will not only promote the continuous improvement of the model, the existing model can also be verified and modified through additional use cases.

Recently I encountered a requirement at work, which required adjusting the graying rules for Alipay payment methods at the cashier. After decomposing the requirement by instantiation, the business rules are as follows:

1. Find nouns: User, payment amount, lower limit of amount (more than 50,000), lower limit of amount (less than 100,000), crowd (whitelist is also a kind of crowd), payment tool (Alipay)

2. Find verbs: gray, belong (Within the crowd)

3. Models and attributes:

Model: users, payment tools, crowds, graying rules, consultation behavior; among which consultation behavior is based on existing models. (You can also refer to existing models in the industry), the graying rule is the implicit subject in the above use case

Attributes: upper limit of amount, lower limit of amount, payment amount

4. Confirm Relationship: grayed out indicates that the rule is associated with the payment method; belonging indicates that the user is associated with the crowd

The final model obtained is as follows

What is obtained above is the problem domain model, which is implemented in the real system It is time to make appropriate adjustments to the model as needed, such as representing the crowd as an attribute of the user, etc.