用例描述和实现
程序员文章站
2022-05-19 12:31:55
...
用例名称
用例的简短的名称，可以看成是应用中的菜单项目
管理编号
唯一的编号，可以用来跟踪用例的实现过程
作者
就是编写此用例的人
简要描述
用例的简单描述，可是此用例的简单的功能描述。说明中应简要表述用例的作用和目的。一个段落即足以作此说明。
对用例的角色、目的的简要描述；
基本事件流
基本完成功能的流程。
当主角有所行动时，此用例随即开始。总是由主角来带动用例。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内-您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。
简单的备选流可以在用例文本中提供。如果只需几句话就可说明存在备选流时将发生的事件，则可以直接在事件流一节中说明。如果备选流较为复杂，则需要用另外一节来单独说明。例如，备选流小节解释如何说明较复杂的备选流。
虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。请切记，您的目的是要阐明问题，而不是混淆问题。
描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
备选事件流
在正常执行的情况下，某种条件下，需要转入的流程。
子事件流
比较复杂的流程可以在子事件流中再分成几步来描述。
前置条件
执行用例之前系统必须要处于的状态，或者要满足的条件；
后置条件
用例执行完毕后系统可能处于的一组状态。
特别需求
对时间，并发数等的需求
相关资料
DEMO页面
Table 6.0
Use Case #
DATAENTRYPROJECTCUST-1009
Use Case name
Maintain Customer
Description
This Use Case depicts full maintenance of customer from project "Data Entry".
Scope and level
* Data Entry System (Internal)
* Credit Card System (External)
Level
User Goal Level (If this property is not understood, look at the reference for the book Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans and technology)
Primary and secondary actors
Data Entry operator.
Stakeholders and interests
Trigger
Data entry operator clicks on menu: "Add New Customer"
Preconditions
* Data entry operator should be logged in.
* Data entry operator should have access to Internet.
Assumptions
Customer information received is entered manually. No automated import routine is in the scope.
Failed End condition
* Customer is not added to database and appropriate error message is displayed.
* Customer code already existing in the customer database.
* Customer code length limit is exceeded.
* Customer credit card limit is exceeded.
* Customer credit card validation failed with the payment gateway.
Action
Add new customer
Main success scenario (or basic Flow):
1. Data entry operator receives customer information.
2. Data entry operator enters following information:
* Customer code
* Customer name
* Customer address
* Customer phone
3. Customer code is checked if it exists in Customer table.
* If the customer code is existing then "Duplicate Customer Code" error is raised.
* If the customer code is more than 8 length, then "Customer code length limit crossed" error is raised.
4. After step 3 is passed OK. Data entry operator enters credit card information. If the credit card length is more than 10 length, then "Credit card length limit crossed" error is raised.
5. Credit card information is send to the external payment gateway. Appropriate APIs of the external payment gateway will be used for validity.
6. External payment gateway returns "OK" if credit card is validated or else will return "NOT VALID" flag.
7. Data entry operator then adds the customer in database.
Alternate scenario (Extensions):
Update Existing Customer
1. Data entry operator enters customer code to retrieve the customer who has to be updated.
2. Data entry operator makes appropriate changes to the customer information. All steps and business validation from 1 to 6 of Add new Customer is repeated.
3. Data Entry operator updates the customer information.
Alternate scenario (Extensions):
Delete Existing Customer
1. Data entry operator enters customer code to retrieve the customer who has to be deleted.
2. Data entry operator deletes the customer. Data entry operator is alerted "Are you sure you want to delete the Customer?”
* If the data entry operator clicks "Yes", then the customer is deleted from the database.
* If the data entry operator clicks "NO", no action is taken.
Success Guarantee (Post conditions):
* Customer is added to Customer database.
* Customer is updated to Customer database.
* Customer is deleted from Customer database.
Special Requirements (including business rules):
Technology and Data Variations List:
If credit card payment gateway API changes, the interaction of the data entry customer module will have to be changed accordingly.
Frequency of occurrence:
Notes and Open Issues:
用例的简短的名称，可以看成是应用中的菜单项目
管理编号
唯一的编号，可以用来跟踪用例的实现过程
作者
就是编写此用例的人
简要描述
用例的简单描述，可是此用例的简单的功能描述。说明中应简要表述用例的作用和目的。一个段落即足以作此说明。
对用例的角色、目的的简要描述；
基本事件流
基本完成功能的流程。
当主角有所行动时，此用例随即开始。总是由主角来带动用例。用例应说明主角的行为及系统的响应。应按照主角与系统进行对话的形式来逐步引入用例。
用例应说明的是系统内发生的事件，而不是事件发生的方式和原因。如果进行了信息交换，则需指出来回传递的具体信息。例如，只表述主角输入了客户信息就不够明确。最好明确地说主角输入了客户姓名和地址。通常可以利用词汇表让用例的复杂性保持在可控范围内-您最好在词汇表中定义客户信息等内容，使用例不至于陷入过多的细节。
简单的备选流可以在用例文本中提供。如果只需几句话就可说明存在备选流时将发生的事件，则可以直接在事件流一节中说明。如果备选流较为复杂，则需要用另外一节来单独说明。例如，备选流小节解释如何说明较复杂的备选流。
虽然清晰明了的叙述性文字是无可替代的，但有时一幅图要比千言短文更具说明性。只要表达得简洁明了，您就可以在用例中任意粘贴用户界面和流程的图形化显示方式，或是其他图形。如果流程图有助于描述复杂的决策流程，那么一定要充分利用它！同样，对于与状态相关的行为，状态转移图通常比数页文字更能清晰地描述系统的行为。根据问题来选用妥当的表示方法，但应慎用您的读者可能不太明了的术语、符号或图形。请切记，您的目的是要阐明问题，而不是混淆问题。
描述该用例的基本流程，指每个流程都“正常”运作时所发生的事情，没有任何备选流和异常流，而只有最有可能发生的事件流；
备选事件流
在正常执行的情况下，某种条件下，需要转入的流程。
子事件流
比较复杂的流程可以在子事件流中再分成几步来描述。
前置条件
执行用例之前系统必须要处于的状态，或者要满足的条件；
后置条件
用例执行完毕后系统可能处于的一组状态。
特别需求
对时间，并发数等的需求
相关资料
DEMO页面
Table 6.0
Use Case #
DATAENTRYPROJECTCUST-1009
Use Case name
Maintain Customer
Description
This Use Case depicts full maintenance of customer from project "Data Entry".
Scope and level
* Data Entry System (Internal)
* Credit Card System (External)
Level
User Goal Level (If this property is not understood, look at the reference for the book Writing Effective Use Cases (**PRE-PUB. DRAFT#3**): Alistair Cockburn Humans and technology)
Primary and secondary actors
Data Entry operator.
Stakeholders and interests
Trigger
Data entry operator clicks on menu: "Add New Customer"
Preconditions
* Data entry operator should be logged in.
* Data entry operator should have access to Internet.
Assumptions
Customer information received is entered manually. No automated import routine is in the scope.
Failed End condition
* Customer is not added to database and appropriate error message is displayed.
* Customer code already existing in the customer database.
* Customer code length limit is exceeded.
* Customer credit card limit is exceeded.
* Customer credit card validation failed with the payment gateway.
Action
Add new customer
Main success scenario (or basic Flow):
1. Data entry operator receives customer information.
2. Data entry operator enters following information:
* Customer code
* Customer name
* Customer address
* Customer phone
3. Customer code is checked if it exists in Customer table.
* If the customer code is existing then "Duplicate Customer Code" error is raised.
* If the customer code is more than 8 length, then "Customer code length limit crossed" error is raised.
4. After step 3 is passed OK. Data entry operator enters credit card information. If the credit card length is more than 10 length, then "Credit card length limit crossed" error is raised.
5. Credit card information is send to the external payment gateway. Appropriate APIs of the external payment gateway will be used for validity.
6. External payment gateway returns "OK" if credit card is validated or else will return "NOT VALID" flag.
7. Data entry operator then adds the customer in database.
Alternate scenario (Extensions):
Update Existing Customer
1. Data entry operator enters customer code to retrieve the customer who has to be updated.
2. Data entry operator makes appropriate changes to the customer information. All steps and business validation from 1 to 6 of Add new Customer is repeated.
3. Data Entry operator updates the customer information.
Alternate scenario (Extensions):
Delete Existing Customer
1. Data entry operator enters customer code to retrieve the customer who has to be deleted.
2. Data entry operator deletes the customer. Data entry operator is alerted "Are you sure you want to delete the Customer?”
* If the data entry operator clicks "Yes", then the customer is deleted from the database.
* If the data entry operator clicks "NO", no action is taken.
Success Guarantee (Post conditions):
* Customer is added to Customer database.
* Customer is updated to Customer database.
* Customer is deleted from Customer database.
Special Requirements (including business rules):
Technology and Data Variations List:
If credit card payment gateway API changes, the interaction of the data entry customer module will have to be changed accordingly.
Frequency of occurrence:
Notes and Open Issues:
上一篇： 大学里好玩,毕业就发愁
下一篇： 好多原来都不是那么美好了