Uml 用例图在扩展和包含方面有问题

我对UML非常陌生，尤其是用例图。我试图为我的应用程序绘制一个用例图，其中包括一个承租人、一个卖家和一个普通用户。我的租客和卖家扩展了普通用户。我在Include和extends方面遇到了问题。例如，当您查看办公空间时，还可以在页面底部查看该空间的评论。以及当租客想要写评论时，他/她必须在查看办公空间页面上这样做。我不确定这是扩展还是包含。如果我的箭头方向有错误，请纠正我。另外，可以说租客和卖家都包括登录吗

---

您通常不应该为登录用例建模，因为它们不会直接帮助用户完成他或她所关心的任何事情

包含和扩展是用例之间的关系，而不是参与者之间的关系。UML 2.5规范规定：

• 扩展名为：
  从扩展用例到扩展用例的关系，指定如何以及何时将扩展用例中定义的行为插入扩展用例中定义的行为

• 其中包括：
  包含关系指定一个用例包含在另一个用例中定义的行为

---

演员之间的泛化/专业化关系是完美的。那只是一个概括的箭头。（例如，一条带有空心箭头的实线。）

正如Jim所说：I/e是为UCs而不是为演员而设计的。我想您在这里指的是泛化，所以两者都继承自普通用户

一些进一步的意见：

• 对UCs标题使用动词实体
• 想想用例中的“用法”。IOW：附加值。如果您没有发现它的附加值，那么它就不是用例
• 一般避免I/E。它们通常表示您尝试使用功能分解，而这不是UC合成的目标
• 您在UCs之间绘制的关系在任何情况下都是错误的。没有带点的填充三角形关系。您可能打算使用一些
  依赖项（带有一个打开的箭头）。但如上所述：避免它。只需创建与演员的关联。只要在评论和普通用户之间画一条线就足够了，因为承租人将继承这种关系
• 登录/退出没有UCs（没有附加值）。是对其他UC的约束（写入{必须登录}并连接到连接器）

---

hmmm。。。我将查看UML2.5规范，以确保我是正确的。。。谢谢你指出这一点。同时，我也以此为指导。技巧4也在扩展它，谢谢！如何显示一个通用的参与者（一个参与者从另一个参与者继承）？我见过一个实心箭头包含一个未填充箭头的例子。@unconditionalcoder:我为您的答案添加了更多内容。我还提到了一个错误的说法，即UML中的参与者之间允许包含和扩展。I/E是为UCs设计的（只要我正确理解第639页的规范），而不是为演员设计的，因为在这里，泛化是选择的关系。谢谢！你说两者都是一般用户的概括。如何在UML图上显示这一点？我应该保持箭头不带延伸吗？一个概括显示为一条实线，并以一个未填充的三角形结束，指向一般类。因此，只需将虚线替换为没有原型的实线，并使箭头成为未填充的三角形。