是否应该在用例中定义异常？
假设您有一个名为“安排会议”的用例。规范中定义，会议只能安排在当前时间或将来。在用例中是否应该包括“如果给定的日期/时间是过去的，消息框将显示‘会议时间不能是过去的’”的流程？
就像我说的，规范中定义了日期/时间不能是过去的，但是在用例定义中，也应该在那里定义吗？
Say you have a use case called 'schedule meeting.' Defined in the spec, meetings can only be scheduled for the current time or the future. In the Use Case should it include the flow where "if the date/time given is in the past, a message box will show 'meeting time cannot be in the past'"?
Like I said, it's defined in the spec that the date/time cannot be in the past, but in the use case definition, should it be defined there as well?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果可以避免的话，业务工作流程就不应该是技术性的。
说“用户在这些条件下将看到错误...”是可以的，但是由开发人员来定义如何实现它。异常可能是一个好方法，但业务利益相关者应该对此漠不关心。实施细节。
The business work flows should not be technical if they can be avoided.
Saying something like 'The User shall see an Error under these conditions..." is ok, but it is up to the developers to define how to implement that. Exceptions might be a good way, but the business stake holders should be indifferent to the implementation details.
我很高兴找到这个旧线程！我刚刚阅读了关于用例异常的 wiki 条目，它给我带来了一些问题。
我只想说，据我了解要正确使用的用例，您不应该将过去的会议作为例外。
在本例中，用例表达了安排会议的要求。处理无效的会议请求实际上是安排过程的一部分，而不是例外。
需求毫无例外地存在，用例也是如此。无效日期是一个详细项目。将您的用例视为更通用的目录。
如果您正在迭代建模，则在详细阐述模型/文档时，您将“发现”并管理拒绝无效会议请求的要求。
,
I'm glad that I found this old thread! I've just read the wiki entry for use-case exceptions, and it threw up some problems for me.
Let me just say that, as I understand a use case to be properly used, you should not make a past-date meeting an exception.
A use case expresses a requirement, in this case, to schedule a meeting. Dealing with invalid meeting requests actually is a part of the scheduling process, and not an exception to it.
The requirement exists, without exception, as does the use case. Invalid dates are a detail item. Think of your use case as a more general, table of contents.
If you are modelling iteratively, you will 'discover' and manage the requirement to reject invalid meeting requests, as you elaborate your model/document.
,
我很高兴找到这个旧线程！我刚刚阅读了关于用例异常的 wiki 条目，它给我带来了一些问题。
我只想说，据我了解要正确使用的用例，您不应该将过去的会议作为例外。
在本例中，用例表达了安排会议的要求。处理无效的会议请求实际上是安排过程的一部分，而不是例外。
需求毫无例外地存在，用例也是如此。无效日期是一个详细项目。将您的用例视为更通用的目录。
如果您正在迭代建模，则在详细阐述模型/文档时，您将“发现”并管理拒绝无效会议请求的要求。
更简洁地说，您描述了安排会议功能。 UML 用例不应该用于功能驱动的开发。
I'm glad that I found this old thread! I've just read the wiki entry for use-case exceptions, and it threw up some problems for me.
Let me just say that, as I understand a use case to be properly used, you should not make a past-date meeting an exception.
A use case expresses a requirement, in this case, to schedule a meeting. Dealing with invalid meeting requests actually is a part of the scheduling process, and not an exception to it.
The requirement exists, without exception, as does the use case. Invalid dates are a detail item. Think of your use case as a more general, table of contents.
If you are modelling iteratively, you will 'discover' and manage the requirement to reject invalid meeting requests, as you elaborate your model/document.
Put even more succinctly, you have described a schedule meeting function. A UML use case should not be used for functional-driven development.