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

Question

我需要创建一个费用跟踪工具。该工具将允许个人用户记录他们的费用，并预测特定日期的财务状况。

用户界面

这将构建为.NET C＃windows窗体桌面应用程序。您可以根据需要自由设计用户界面，但这是最低要求。

界面必须至少包含以下视图：

1. 用于输入和更新联系人（付款人或收款人）详细信息的联系人视图。
2. 用于输入和更新特定日期的费用明细的费用输入视图。
3. 财务报表视图 - 显示所选日期范围的所有费用。
4. 一种视图，使用户能够在特定日期查看其预测的财务状况。

额外信用：

5. 输入事件的视图：约会和任务。
6. 每周视图显示每日活动和费用。

由您决定如何设计表单。我们故意不给你一个设计实例，以避免每个人都有相同的设计。建议您在开发设计文档时创建模型和故事板并迭代修改它们。您的设计决策应包含在您的报告中。

持久存储运行时数据

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

我的UML图

你能查看下图吗？

Answer 1

Are use case suitable for UI requirements ?

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

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

What are the UC in your requirements ?

考虑到这一点，我会根据您的要求确定以下UC：

• Manage contact details（＃1） - 我使用了Maemphasized textnage来缩短Enter或更新 - 打开问题：毕竟可能是两个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）

What can be improved in your diagram ?

现在回顾一下你自己的UC图：

• Select data range可能是include和Add transation（警告：拼写错误）的Generate reports，因为它是行为的一部分，并且包括UC在没有包含UC的情况下是不完整的。请注意，将它作为一个单独的UC在我看来是人为详细的，不建议使用。
• Select data range原则上不应该是extension的Add transation，因为扩展是可选的，并且扩展的UC应该是完整的而没有扩展名。在这里，没有知道约会对Add a transaction没有意义。
• 我建议将UC名称更改为活动行为：选择/选择数据范围，生成/报告每周视图
• 您目前在用例中使用generalization。虽然这不是最常见的做法，但这是完全合法的：UC is a classifier和分类器可以推广。然而，当在UC中使用泛化时，它通常具有与所有其他“链接”相同的图形风格，仅在两个元素之间分开，并且通常不在shared target form（example）中。请注意，您的专业化的命名听起来像对应于数据对象（例如付款人）的名词而不是行为（例如管理付款人）。另请注意，拼写错误导致收款人在那里两次

Edit: more about generalization in UC

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

当存在相同UC的several variants时，继承可能是有用的。这是抽象的原则。但UC应该提供简单的概述而不会丢失读者的细节。因此，更好的做法是保留您的图表而不显示专业化，并有第二个专门用于这些细节的图表。

但个人（并看到评论和其他答案，我并不孤单）我建议不要使用它。它使一个简单易懂的图表，在不同抽象层次的复杂事物中。在这个重新考虑中，值得一提的是UC的发明者Ivar Jacobson：

• 在他们被纳入UML之前，他没有在他的UC中使用继承。
• 他不会在最近的Use Case 2.0工作中使用它，在那里他推广使用用例切片来应对变体。

Answer 2

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

有些UC缺失，用户可以向系统询问的所有内容都不包括在内

我不知道什么是正确的UC DataRange如此难以检查你的扩展/包括但是作为Thomas Kilian我对它们有疑问