用例图混淆：泛化和依赖关系

Question

我正在研究一个大学项目。我有以下问题。这是一个发布系统的用例图。正如你所看到的那样，它有一个混乱。我不知道如何以及在哪里使用扩展包含关系。还有如何使用继承UCs。所有的报告是否应该从主要的报告 - 统一通信？我们在哪里可以包含扩展关系？

Answer 1

警告

“使用案例” 通常以动词开始，指示动作。

快速简答

也许，你可能要坚持到标准的“用例”。

“继承”&“包含”可能有帮助，但是，也可能会让您更加困惑。

龙镗扩展回答

1.继承

您的发布系统的几个用户。其中一些用户由不包含的通用“用户”代表，需要登录到系统中。

例如，您可能有一个通用的“管理员”，有权执行一些操作，而您的“经理”演员&从您那里继承。

o 
-+- 
| 
/\ 
"Administrator" 
^   ^
|    | 
| "inherits" | "inherits" 
|    | 
o    o 
-+-   -+- 
|    | 
/\   /\ 
"Manager" "Responsible" 

这些参与者共享几个用例，但并没有完全相同的用例。

“继承”更关注“演员”（“人”），而不是“用例”（“bubles”）。

2.扩展/包括

中的“扩展/包含”更集中在“使用情况”，而不是“演员”。

这种情况需要几个可能独立的“使用案例”，而其他组成的“使用案例”需要独立的案例。

您可能有“与作者签订合同”用例。该使用案例包括更多的使用案例：

2.1“与作者签订合同”，即其为手动操作，而不是电脑操作。

("Make a Contract with the Author") --includes--> ("Deal the Contract with the Author") 

2.2“登录系统”，即在系统中的模块，可以包括在其他使用案例，并通过自身及其上独立。

("Make a Contract with the Author") --includes--> ("Login into the System") 

2.3“注册与作者的合同”，即在系统中的模块，需要“登录到系统”的使用情况，如果合同数据被捕获。

("Make a Contract with the Author") --includes--> ("Register the Contract with the Author") 

摘要

我学到的第一U.M.L.不包括“继承”或“扩展/包含”的“用例”图的版本。后来，我发现了，如何使用它们。

作为一项家庭作业，您的项目是否需要实施它们？