Uml 工作网站用例图

这是我的工作网站用例图。我不知道我所做的是否正确。 有什么帮助吗？

编辑1

---

以下是在线作业门户系统的修改版本：

该系统包含两个复杂的用例：“帐户管理”和“作业应用程序”。 以下是帐户管理的示意图：

以及职位申请示意图：

---

我需要你的意见。

你完全没有看到系统的边界（上面标有“系统”的中间框）

在概念层面上，理解系统的边界是什么非常重要，什么只是人为驱动的附带/必然劳动。把那些东西放在边界之外（在纸上甚至不要为它画一个用例，在你的脑海中理解它是系统的一部分，但不是你在代码中实现的东西，它将是文档、培训或法律），但把它放在侧边栏的图表中

侧边栏（自然语言的语义基础）应该用简单的单词和句子书写。如果你做不到这一点，你应该尝试更好地理解这个领域，简化这个图，并把它分成许多图

将其分解为3或4个不同的图表，每个图表都应该关注那些具有内聚性的用例。对不相关的用例和系统的不同方面使用不同的图表。 在复杂性和简单性之间找到正确的切入点，我怀疑您在扩展方面做得有点过头了

记住：UML图是外科手术工具，尽可能集中使用它们。更多并不是更好，它只是混乱或分散

最后，为更复杂的用例（那些具有许多扩展的用例）写下实际场景。您将看到考虑所有扩展点是多么困难。这将很好地表明该系统将有多复杂

---

在这个早期阶段，您可以简化的越多，对以后的设计和实现就越好。

考虑到您的意见，下面是我的图表的修改版本。我有两个复杂的用例来开发“帐户管理”和“假设”。但是在采取这一步之前，我想知道所附的图表是否正确，或者是否有一些改进需要引入？

---

以下是在线工作门户系统的修改版本：

该系统包含两个复杂的用例：“帐户管理”和“作业应用程序”。 以下是帐户管理的示意图：

以及职位申请示意图：

---

我需要你的意见。

不错，但是有一些问题

• 工作申请是一个过程，也是一个用例。但（对任何人）的叙述不是一个行动或过程。它是应用程序中的一个内部术语。它应该首先出现在组件图中，甚至更晚
• “延伸”是指指向的主体是指向主体的变体。你显然误用了它
• 帐户管理是一个子系统矩形，它是大矩形的一部分，包含适当的用例。如果绘图不方便，请使用（子）系统小矩形和容器依赖项（容器侧面有圆圈交叉），并通过简单的连接器将它们连接到用例。当然，您不必将与所有子系统的对话放在同一个图上
• 网站的维护与任何实际用例都没有联系。这是单独的管理任务。或者你指的是别的什么？然后更改名称
• 您有未连接到任何参与者的用例。这是一个错误
• 登录不是职务申请的一部分。视图空缺也不是它的变体。最受欢迎的空缺是扩展视图空缺
• 请尽量减少用例图中“包含”和“扩展”的使用。在90%的情况下，当人们错误地描述用例图上的结构信息时，他们会使用它们。在这里，你只写谁将对谁做什么，也许可以稍微将这些Who和Who组织成组织和子系统。注意，您可以在用例上面描述结构，而不是在用例下面

小细节：

你可以考虑从管理员那里分为主持人。
• 编辑您的连接线-它们被扼杀得太多了

（非常感谢你的翻译——我的法语太糟糕了，无法胜任模特工作）

关于@pid答案的更多信息

---

恐怕，我不能同意忽视纯粹的人工操作。相反地。把它们放在这里，只有它们的用例连接的不是actor-（子）系统，而是actor-actor。看到它们有助于更好地规划整个系统。忽略它们，就不可能为用户创建一个好的系统。IT系统是更大系统的一个组成部分，我们正在创建更大的系统，包括规划支持、流程、信息交换、部门和依赖关系

毫无疑问。你可以用英语写在这里。我在这里用捷克语写图表。SO的语言是英语，喜欢还是讨厌。OK@Gangnus。我会尽量制作一个干净的英文版本。谢谢你的评论。由于（任何人的）帐户不是一个操作或过程，我必须从用例图中删除它？所有这些。他们是班级。或者由某些类组成的组件，如果它们更复杂的话。但它们不是行动或过程。它们甚至不可能是子系统，但帐户管理可以是子系统。帐户注册，或者注册帐户可以是用例。删除或编辑帐户也一样。我同意更大的系统，但玛丽正在努力掌握基本知识。从辅导经验中，我可以告诉你，如果她把这个系统看作是一个程序，她将不得不设计和实施一个明确的界限，那就更好了。用自然语言编写系统的非实现特性有助于她理解这种差异。但这是真的，我同意