查看费用跟踪工具的UML用例图

Question

我需要创建一个费用跟踪工具。该工具将允许单个用户保留其支出记录，并预测特定日期的财务状况。

用户界面

这将作为.NET C＃Windows窗体桌面应用程序构建。您可以随意设计用户界面，但这是最低要求。

该界面必须至少具有以下视图：

1. 用于输入和更新联系人（付款人）详细信息的联系人视图 或收款人）。
2. 费用输入视图，用于输入和更新费用的详细信息 某一天。
3. 财务报告视图–显示选定日期范围内的所有费用。
4. 一个视图，使用户可以在以下位置查看其预测的财务状况 特定日期。

额外的信用额：

1. 用于输入事件的视图：约会和任务。
2. 每周视图，显示每日事件和费用。

由您决定如何设计表单。我们故意不给您一个 设计示例，以避免每个人都具有相同的设计。建议您 创建模型和情节提要，并在开发设计文档时对其进行迭代修改。 您的设计决策应包括在报告中。

永久存储运行时数据

费用数据将通过一个视图创建，该视图允许  指定要为日期输入的费用，这应该是程序化动态界面。用户完成后，您需要保存 费用数据作为XML文件并在您选择的数据库中。当。。。的时候 再次运行应用程序（关闭后），系统应使用XML数据 在界面上填充数据。它应该将数据库数据用于 财务报告。写入数据库或从数据库读取活动时 应该是线程化的（以使接口在写入 外部数据库）

我的UML图

能否请您查看下图？

Answer 1

用例是否适合UI要求？

use case代表演员想要实现的目标。这是一种行为（通常是一种行为）。这不是用户应如何实现目标的方法。既不是用户界面的描述；甚至更少的数据模型。

如果您必须设计一个用户界面（似乎需要练习的叙述），则可能不需要UC，而需要 wireframes 来绘制UI。

您要求的UC是什么？

考虑到这一点，我将在您的要求中确定以下UC：

• Manage contact details（＃1）-我使用Ma 强调文本 nage来缩短 Enter或更新-公开问题：也许毕竟是两个UC：{{ 1}} + Manage Payer details。
• Manage payee details（＃2）-日期的选择是UI的细节，而不是UC！
• Manage expenses for a day（＃3）-日期范围的选择是UI的细节，而不是UC！
• Report expenses（＃4）
• Forecast financial situation（＃5）
• Enter (maintain?) events（＃6）

您的图表中有哪些可以改进的地方？

现在查看您自己的UC图：

• Report weekly situation可能是Select data range和Add transation的{​​{3}}（警告：错别字），因为它是行为的一部分，并且包括UC都是不完整而没有包含的UC。请注意，在我看来，将其作为单独的UC似乎是人为地详细说明的，因此不建议这样做。
• Generate reports原则上不应该是Select data range的{​​{3}}，因为扩展名是可选并且扩展的UC应该完整而没有扩展名。在这里，Add transation在不知道日期的情况下毫无意义。
• 我建议将UC名称从更改为活动行为： 选择/选择 数据范围， 生成/报告 每周视图
• 您当前在用例中使用include。尽管这不是最常见的做法，但这是完全合法的：extension和分类器可以泛化。但是，当在UC中使用通用化时，它通常具有与所有其他“链接”相同的图形风格，它们分开且仅在两个元素之间，并且通常不在generalization（UC is a classifier）中。请注意，专业名称的命名听起来像是对应于数据对象（例如 Payer ）而不是行为（例如 Manage payers ）的名词。另请注意，输入错误导致 Payee 出现两次

编辑：有关UC泛化的更多信息

在UC中使用继承存在一些争议，因为它的实际含义不像其他类型的关系那样直观。

当同一UC中有shared target form时，继承可能很有用。这是抽象的原理。但是，UC应该提供一个简单的概述，而不会使读者失去细节。因此，一个更好的做法是保留您的图表而不显示专业知识，而让第二张图表专用于这些细节。

但是我个人（并看着评论和其他答案，我并不孤单）我建议不要使用它。它使图表变得简单易懂，但在抽象程度不同的情况下更为复杂。在这次回顾中，值得一提的是UC的发明者example：

• 在将继承人纳入UML之前，他没有在UC中使用继承。
• 他在several variants的最新作品中都没有使用它，而是在其中提倡使用用例切片来应对变体。

Answer 2

使用动词命名您的UC，收入，费用，收款人，数据范围和每周视图并非UC，但它们主要对应于数据。

缺少一些UC，用户可以向系统提出的所有要求均未涵盖

我不知道什么是 DataRange 的正确UC，因此很难检查您的扩展/包含，但是作为Thomas Kilian，我对此感到怀疑