审查费用跟踪工具的 UML 用例图
Review of an UML use case diagram for an expense tracking tool
我需要创建一个费用跟踪工具。该工具将允许个人用户记录他们的开支，并预测特定日期的财务状况。
用户界面
这将构建为 .NET C# windows 表单桌面应用程序。您可以根据需要自由设计用户界面，但这里有最低要求。
界面必须至少有这些视图：
- 用于输入和更新联系人详细信息的联系人视图（付款人
或收款人）。
- 用于输入和更新费用详细信息的费用条目视图
某天
- 财务报告视图 – 显示所选日期范围内的所有费用。
- 一个视图，使用户能够在某个时间查看他们的预测财务状况
某个日期。
加分项：
- 用于输入事件的视图：约会和任务。
- 显示每日活动和费用的每周视图。
如何设计表单取决于您。我们故意不给你一个
设计示例以避免每个人都有相同的设计。建议您
创建模型和故事板，并在开发设计文档时迭代修改它们。
您的设计决策应包含在您的报告中。
永久存储运行时间数据
费用数据将由允许
为日期输入的费用规范，这应该是一个程序化的动态接口。用户完成后，您需要保存
费用数据作为 XML 文件和您选择的数据库。当。。。的时候
应用程序再次 运行（关闭后）系统应使用 XML 数据来
填充界面上的数据。它应该使用数据库数据
财务报告。写入或读取数据库时 activity
应该是线程化的（以使接口在写入时可用
外部数据库）
我的 UML 图
你能看看下图吗？
使用动词命名您的 UC，收入、费用、收款人、数据范围和每周视图不是 UC，但它们主要对应到数据。
缺少一些 UC，未涵盖用户可以向系统提出的所有问题
我不知道 DataRange 的正确 UC 是什么，因此很难检查您的扩展/包含，但作为 Thomas Kilian，我对它们有疑问
用例是否适合 UI 要求？
一个use case代表一个演员想要达到的目标。它是一种行为（通常是一个动作）。这不是用户应该如何实现目标；既不是用户界面的描述；甚至更少的数据模型。
如果你必须设计一个用户界面（正如你的练习的叙述似乎需要的那样），你可能不需要 UC，而是 wireframes 来勾画UI。
您要求的 UC 是什么？
考虑到这一点，我会在您的要求中确定以下 UC：
Manage contact details (#1) - 我用 Maemphasized textnage 来缩短 Enter or update -Open question:毕竟可能是两个 UC：Manage Payer details + Manage payee details。 Manage expenses for a day (#2) - 日期的选择是 UI 的细节，而不是 UC !Report expenses (#3) - 日期范围的选择是 UI 的细节，而不是 UC ！ Forecast financial situation (#4)Enter (maintain?) events (#5)Report weekly situation (#6)
你的图表有哪些地方可以改进？
现在回顾一下你自己的 UC 图：
Select data range 可能是 include 对于 Add transation 和 Generate reports（注意：打字错误），因为它是行为的一部分并且包括 UC 是 不完整 没有随附的 UC。请注意，将它作为一个单独的 UC 在我看来是人为的详细信息，不推荐使用。 Select data range原则上不应该是Add transation的extension，因为扩展是可选的并且扩展的UC应该是完整的没有扩展名。在这里，在不知道日期的情况下 Add a transaction 是没有意义的。 - 我建议将 UC 名称从更改为活动行为：Chose/select 数据范围, Generate/Report 每周浏览量
- 您目前使用 generalization in your use case. Although it is not the most common practice, this is perfectly legal: the UC is a classifier and classifiers can be generalized. However, when generalization is used in an UC, it's generally with the same graphical flavour as all the other "links", separate and between only two elements, and usually not in the shared target form (example)。请注意，您的专业化命名听起来像是对应于数据对象的名词（例如 Payer），而不是行为（例如 Manage payers）。另请注意，拼写错误导致 Payee 出现两次
编辑：更多关于 UC 中的泛化
在 UC 中使用继承存在一些争议，因为它的实际意义不如其他类型的关系直观。
当同一 UC 有 several variants 时，继承可能很有用。这就是抽象原则。但是 UC 应该提供一个简单的概述，而不会在细节上失去读者。因此，更好的做法是保留您的图表而不显示专业化，并有第二张图表专门用于这些细节。
但就个人而言（并查看评论和其他答案，我并不孤单）我建议不要使用它。它制作了一个简单易懂的图表，在具有不同抽象级别的更复杂的事物中。在这方面，值得一提的是 Ivar Jacobson，UC 的发明者：
- 在 UML 中包含继承之前，他没有在他的 UC 中使用继承。
- 他在最近关于 Use Case 2.0 的工作中也没有使用它，他在其中提倡使用用例切片来处理变体。
我需要创建一个费用跟踪工具。该工具将允许个人用户记录他们的开支，并预测特定日期的财务状况。
用户界面
这将构建为 .NET C# windows 表单桌面应用程序。您可以根据需要自由设计用户界面，但这里有最低要求。
界面必须至少有这些视图：
- 用于输入和更新联系人详细信息的联系人视图（付款人 或收款人）。
- 用于输入和更新费用详细信息的费用条目视图 某天
- 财务报告视图 – 显示所选日期范围内的所有费用。
- 一个视图，使用户能够在某个时间查看他们的预测财务状况 某个日期。
加分项：
- 用于输入事件的视图：约会和任务。
- 显示每日活动和费用的每周视图。
如何设计表单取决于您。我们故意不给你一个 设计示例以避免每个人都有相同的设计。建议您 创建模型和故事板，并在开发设计文档时迭代修改它们。 您的设计决策应包含在您的报告中。
永久存储运行时间数据
费用数据将由允许 为日期输入的费用规范，这应该是一个程序化的动态接口。用户完成后，您需要保存 费用数据作为 XML 文件和您选择的数据库。当。。。的时候 应用程序再次 运行（关闭后）系统应使用 XML 数据来 填充界面上的数据。它应该使用数据库数据 财务报告。写入或读取数据库时 activity 应该是线程化的（以使接口在写入时可用 外部数据库）
我的 UML 图
你能看看下图吗？
使用动词命名您的 UC，收入、费用、收款人、数据范围和每周视图不是 UC，但它们主要对应到数据。
缺少一些 UC，未涵盖用户可以向系统提出的所有问题
我不知道 DataRange 的正确 UC 是什么，因此很难检查您的扩展/包含，但作为 Thomas Kilian，我对它们有疑问
用例是否适合 UI 要求？
一个use case代表一个演员想要达到的目标。它是一种行为（通常是一个动作）。这不是用户应该如何实现目标；既不是用户界面的描述；甚至更少的数据模型。
如果你必须设计一个用户界面（正如你的练习的叙述似乎需要的那样），你可能不需要 UC，而是 wireframes 来勾画UI。
您要求的 UC 是什么？
考虑到这一点，我会在您的要求中确定以下 UC：
Manage contact details(#1) - 我用 Maemphasized textnage 来缩短 Enter or update -Open question:毕竟可能是两个 UC：Manage Payer details+Manage payee details。Manage expenses for a day(#2) - 日期的选择是 UI 的细节，而不是 UC !Report expenses(#3) - 日期范围的选择是 UI 的细节，而不是 UC ！Forecast financial situation(#4)Enter (maintain?) events(#5)Report weekly situation(#6)
你的图表有哪些地方可以改进？
现在回顾一下你自己的 UC 图：
Select data range可能是 include 对于Add transation和Generate reports（注意：打字错误），因为它是行为的一部分并且包括 UC 是 不完整 没有随附的 UC。请注意，将它作为一个单独的 UC 在我看来是人为的详细信息，不推荐使用。Select data range原则上不应该是Add transation的extension，因为扩展是可选的并且扩展的UC应该是完整的没有扩展名。在这里，在不知道日期的情况下Add a transaction是没有意义的。- 我建议将 UC 名称从更改为活动行为：Chose/select 数据范围, Generate/Report 每周浏览量
- 您目前使用 generalization in your use case. Although it is not the most common practice, this is perfectly legal: the UC is a classifier and classifiers can be generalized. However, when generalization is used in an UC, it's generally with the same graphical flavour as all the other "links", separate and between only two elements, and usually not in the shared target form (example)。请注意，您的专业化命名听起来像是对应于数据对象的名词（例如 Payer），而不是行为（例如 Manage payers）。另请注意，拼写错误导致 Payee 出现两次
编辑：更多关于 UC 中的泛化
在 UC 中使用继承存在一些争议，因为它的实际意义不如其他类型的关系直观。
当同一 UC 有 several variants 时，继承可能很有用。这就是抽象原则。但是 UC 应该提供一个简单的概述，而不会在细节上失去读者。因此，更好的做法是保留您的图表而不显示专业化，并有第二张图表专门用于这些细节。
但就个人而言（并查看评论和其他答案，我并不孤单）我建议不要使用它。它制作了一个简单易懂的图表，在具有不同抽象级别的更复杂的事物中。在这方面，值得一提的是 Ivar Jacobson，UC 的发明者：
- 在 UML 中包含继承之前，他没有在他的 UC 中使用继承。
- 他在最近关于 Use Case 2.0 的工作中也没有使用它，他在其中提倡使用用例切片来处理变体。