用例图(辅助角色)
我有一份描述在线电子商务系统的问题陈述：
正在开发一个电子商务软件系统。该系统允许客户浏览商店目录，挑选商品，并将其放入电子购物车中。客户可以下订单并输入他的运输细节，信用卡信息。它提供了一种安全的信用卡支付服务。它应向客户提供一套装运方法，这些方法是通过当地运输机构进行的，下一个营业日则通过DHL。该系统有一个管理后端，允许管理员添加新产品、管理库存和处理客户退款(如果存在的话)。该制度应符合所有适用的地方和国际法。它也应该符合公司的标准STD0945。客户端的需求不过是网络浏览器和计算设备上的合理内存。该系统应具有较快的响应时间，并能容忍常见的故障类型。
问题是如何获得功能性和非功能性需求:在Customer的功能中，我有“请求退款”，而Admin的功能是‘流程退款’，我认为Admin是次要参与者，因为他/她从Customer (主)响应了启动的用例。
我有两个问题：
1-我是否可以将Admin视为主要参与者，因为他/她有一些他/她可以启动的用例？
2-描述系统的下列用例图中哪一个是正确的？(我做了三个，但我不确定)
a)
b)
c)
我确信C是正确的，但我想听听你对A和B的看法。
回答 1
Software Engineering用户
发布于 2020-10-31 08:24:49
主参与者和次要参与者不是在系统级别上定义的，而是在用例级别上定义的。这意味着相同的参与者Admin可以是：
- 第二个参与者为用例“请求退款”，因为这个请求不是
Admin的S目标，但他/她仍然参与了这个客户目标； - 是用例“添加新产品”的主要参与者，因为这个活动是
Admin's自己职业能力目标的一部分。
将次级行为者置于系统右侧的做法只是一种非正式做法。从形式上看，B和C是等价的。当一个参与者在同一关系图中既是主的也是次要的时，您可以选择最易读的布局。直觉上我会选择B，但这是味道的问题。
无论如何，A是错误的，因为两个用例之间不允许关联(即请求与处理退款)。
不是相关的，而是为了改进：
- 用例图不是用来对需求进行功能分解的，也不是用来建模用户界面的。总的来说，这个图表看起来非常详细，所以我的建议是，批判性地质疑什么是真正对用户有价值的用例(独立于其他用例)。
Shipment method是一个名词，不描述用例。它要么是Select shipment method(但之后您可以通过DHL或local没有专门化；充其量您可以考虑扩展)，要么是Process shipping instructions(假设之前就已经做出了选择，但应该是Process shipping instructions via DHL和Process shipping instruction via local来澄清它实际上是一个专门化而不是图形错误)。Pay with credit card可以被看作是一个子目标(即使很难独立于封闭的用例来想象)。但Place an order对此进行了扩展，似乎令人困惑。这似乎是简单的功能分解。我真的会把最后一个从图表中删除。
https://softwareengineering.stackexchange.com/questions/418514
复制相似问题
腾讯云开发者
