问题标签 [use-case]

协程的概念听起来很有趣，但我不知道，在真正的生产环境中是否有意义？协程的用例是什么，协程实现比其他方法更优雅、更简单或更高效？

我通过尝试模拟汽车服务车库如何使用图表和文档来学习 UML。我遇到的一个问题是后置条件（或者更确切地说，GOTO）语句。

虚线 << include >> 关系仅用于前提条件吗？用例气泡可以相互连接并遵循逻辑路径吗？

所以这就是我到目前为止所拥有的...... 1）“结算付款”泡沫在错误的地方吗？是否应该将其 << include >>ed 到其他气泡中？2）我是否应该将“请求服务”气泡也与技术人员联系起来，因为他将是修理汽车的人？

图片

我记得几年前读过一本关于用例的方法书。（这可能是在用户故事取代这部分术语之前。）

手头的任务类似于添加新客户。

大约有一个 1 页的偏移部分描述了几个开发人员，他们说“我们不需要任何臭名昭著的用例。我们一直这样做。不会超过几个小时。”

第二天，他们带着你经典的 CRUD 类型的表维护屏幕回来了——因此与从一个好的用例开发的 UI 相比，它们被咀嚼了。

有人认出这个吗？它在当时给人留下了深刻的印象，它仍然是一个很好的警示故事。我想再次找到它。

用例只是多个用户故事吗？

使用用户故事而不是用例有什么好处……反之亦然……何时使用一个而不是其他……所有敏捷方法都使用用户故事吗？

谁负责编写用例？

在用例图中是否绝对有必要使用“箭头”来显示参与者和用例之间的关联？

我最近不得不为我的软件工程作业画一张。但是，在对来自许多其他大学的许多文章、论文、在线书籍和讲义进行了一些在线研究之后，似乎大多数用例图，无论它们有多少潜力显示某种“流程”或“可导航性” "，没有箭头，而有些例子有箭头。

所以我咨询了我的朋友，他是最后一年的学生，并且已经研究了我告诉我的我的演员和用例之间不应该有箭头，甚至他的需求工程讲师也教学生不要使用箭头。所以我有意识地决定不使用箭头，而是使用实线来显示我的用例关联。

这是我的图表-点击

然而，当我收到作业的分数时，我惊讶地发现我因为不使用箭头而得了零分。即使强制使用它们，也有大量证据表明实线可用于双向关联。所以我不应该得到至少一些分数吗？

显然，我要求我的讲师做出解释，我将在下周见到他来讨论这一点，但如果她告诉我我应该使用箭头，我能提出什么反对意见？如果有人可以适当地参考一些专业资源，给我很好的建议，我将不胜感激。

非常感谢您的阅读，我希望尽快阅读您的回复。

编辑

谢谢你们。我真的很感谢你给我的答案。这整个混乱开始了，因为讲师提供的唯一符号是一个单一的、非常简单的图书馆用例图示例，其中一个讲义有箭头。但并不清楚它是否是最终的符号。我不认为它是强制性的另一个原因是因为在解释绘制数据流图的符号时，她非常清楚地使用了她的特定符号，但 DFD 有不同的符号并不少见不同的来源，而我发现很少有证据表明在用例图中使用箭头是必要的。

也就是说，即使在没有箭头的情况下，我记得在辅导课上问过一位导师（不是讲师），有箭头线和实线有什么区别，他说没有，我可以同时使用。显然，我只有我的话，从你们所说的来看，我怀疑任何处于学术地位的人都会承认说出可能使他们处于防御位置的事情。我的错误是没有直接与讲师交谈，但事后看来我显然会这样做。

无论如何，我会就所有这些信息与她交谈，并要求她考虑到这个“诚实的错误”。不仅是用例图，还有其他几个问题，我的分数不寻常，尤其是当我的答案与她提供的模型答案几乎相同时。我也知道很多其他要求他们的作业的学生都被评论了。

希望她会善良并使用良好的判断力来提高我的分数。当我发现时，我会回到这里。

再次感谢您的帮助，请发布您可能拥有的任何其他信息/建议。:)

编辑 2

对不起各位，我还有一个问题。

这是作业中给出的用于绘制用例图的场景。

CONTHETICKET 是一家经营音乐会和剧院门票的票务代理机构。音乐会和剧院场地为 CONTHETICKET 提供关于即将举行的活动的源源不断的信息流，然后经理使用这些信息来编制一份固定清单，供销售人员使用，以响应客户的电话。经理选择了一些活动，CONTHETICKET 将为其提前购买多张门票，从而从与场馆协商的折扣中受益。

他亲自将门票订单连同约定的款项一起发送到场馆，一旦收到门票，他就会将其归档在门票档案中。

当客户打电话给销售团队时，他们的票证请求将根据票证文件进行检查。如果有预购票，则将它们放入标有客户姓名和地址的信封中，并归档在临时订单文件中。如果没有，销售团队会填写一张票务申请表并将其放入托盘中，以供邮递员收集。

付款部分每天检查临时订单文件。他们向客户发送发票并等待付款。发票的副本保存在档案中。收到付款后，付款部分会将付款与相应的发票进行匹配，如果满意，则将发票的另一份副本放入发货文件中，并附上发送机票的说明。

邮递员每天检查发货文件并从临时订单文件中检索相应的票证并将其发送给相应的客户。

正如您从我的图表中看到的那样，我有一个“音乐会和剧院场地”作为演员。

来自 UML 2.0 风格的元素，Scott W. Ambler：

“参与者是在与您的系统的一个或多个交互中发挥作用的个人、组织或外部系统（参与者通常在 UML 用例图上绘制为简笔画）。”

然而，在我的标记作业中，讲师评论说它不应该是演员。你能告诉我你是否认为它应该是一个演员，为什么。

我的理由是 CT&V 提供事件信息，然后经理使用这些信息来订购/归档门票，也由 CT&V 提供。

非常感谢你。

对于学校作业，我们必须制作一个用例图。但是我们拥有的文档不是很扩展。它只是描述了一个用例由哪些组件组成，以及一个示例。
我们必须制作一个关于图书馆系统的用例。我们已经找到了 11 个用例，但我不会用所有这些用例来打扰您。

IIRC，用例描述了系统的典型用法，对吗？但是什么东西属于用例图，它们是如何连接在一起的？

我们现在有四个参与者（成员、员工、经理和会计师）。我们遇到最多的问题是会员和员工。
员工是使用该系统的人。成员仍然属于这里的演员吗？

我们拥有的一些用例：

• 会员加入图书馆。
• 成员更改他的记录。
• 会员借书。
• 成员部分图书馆（退订）。
• 会员预订文章。
• 会员还书。
• 会员支付（部分）费用和罚款。

这些成为图表上的用例。但是应该有更多的用例，比如员工输入会员编号，员工输入账簿编号等等（用途？）。

任何人都可以（？）对此有所了解吗？

编辑： 如何描述动作序列？有人告诉我，您可以看到使用关联，例如对某种重复例程的方法调用？这是正确的吗？以及如何扩展使用？

好吧，关于一个真正的错误问题：

a) 系统的参与者仅由人类或其他软件组件代表。

我说是，老师把它标记为错误，不是因为他认为我错过了硬件组件（我想我会部分承认），而是因为，用他的话来说：

“TIME也是演员。”

用例图如何将 TIME 视为参与者？

请参阅任何将时间视为演员的参考书目。我没有找到任何东西，说实话，我认为这没有任何意义。时间不会自己行动，它要么是一个系统，要么是一个按计划工作的人。

截至目前，我已经根据经验和最近使用功能点进行了工作量估算。

我现在正在探索 UCP，请阅读这篇文章http://www.codeproject.com/KB/architecture/usecasep.aspx。然后，我检查了基于用例点 (UCP) 的其他各种文章。我无法弄清楚它是如何工作的以及它是否正确。

例如，我有一个登录功能，用户提供用户名和密码，然后我检查数据库中的表以允许或拒绝登录。我将用户参与者和登录定义为用例。

根据 UCP，我将登录用例分类为简单，将 GUI 界面分类为复杂。根据 UCP 系数表，我得到 5 和 3，因此总数为 15。在应用技术因素和环境因素调整后，它变为 7。如果我将生产力因素设为 20，那么我将获得 140 小时。但我知道它最多需要 30 小时以及文档和测试工作。

我在这里定义用例时做错了吗？UCP 说如果界面是 GUI，那么它就很复杂，但这里的 gui 很简单，所以我应该降级这个因素吗？简单的因素也是 5，我应该将另一个级别定义为非常简单吗？但是我不是在这里把事情复杂化了吗？

如果您认为事件的用例流创建了一个参与者，您将如何对其建模？

我有一个创建 Windows 服务的用例，它（在我看来）是另一个具有自己的用例和参与者集的系统。

目前，从用例图中并不能明显看出参与者是作为事件流的一部分创建的。

艾丹。