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

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

用户界面

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

接口必须至少具有以下视图：

用于输入和更新联系人（付款人）详细信息的联系人视图 或受款人）

用于输入和更新项目的费用明细的费用输入视图 某一天

财务报告视图–显示选定日期范围内的所有费用

一种视图，使用户可以在某一时间查看其预测的财务状况 确定日期

额外学分：

用于输入事件的视图：约会和任务

显示每日事件和费用的每周视图

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

运行时数据的持久存储

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

我的UML图

你能看一下下面的图表吗

---

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

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

我不知道什么是适合DataRange的UC，因此很难检查您的扩展/包括，但作为Thomas Kilian，我对它们有疑问

用例是否适合UI要求？ A代表演员想要达到的目标。这是一种行为（通常是一种行为）。这不是用户应该如何实现目标；不是用户界面的描述；更不用说数据模型了

如果您必须设计一个用户界面（正如您练习的叙述所要求的那样），您可能不需要UC，而是需要来绘制UI

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

• 管理联系人详细信息

  （#1）-我使用了强调文本管理来缩短输入或更新-开放性问题：毕竟可能有两个UC：

  管理付款人详细信息

  +

  管理受款人详细信息

• 管理一天的费用

  （#2）-日期的选择是UI的一个细节，而不是UC

• 报告费用

  （#3）-日期范围的选择是UI的一个细节，而不是UC

• 预测财务状况

  （#4）

• 输入（维护？）事件

  （#5）

• 报告每周情况

  （#6）

在您的图表中可以改进什么？ 现在回顾一下您自己的UC图：

• Select data range

  可能是

  Add transaction

  和

  Generate reports

  （注意：输入错误），因为它是行为的一部分，并且包含的UC在没有包含UC的情况下是不完整的。请注意，在我看来，将其作为一个单独的UC似乎是人为地详细，而不是推荐

• Select data range

  原则上不应是for

  Add transaction

  ，因为扩展是可选的，扩展的UC应该在没有扩展的情况下完成。在这里，在不知道日期的情况下添加事务是没有意义的
• 我建议将UC名称从更改为活动行为：选择/选择数据范围，生成/报告每周视图
• 您当前在用例中使用。尽管这不是最常见的做法，这是完全合法的：和量词可以概括。然而，当在UC中使用泛化时，它通常与所有其他“链接”具有相同的图形风格，只在两个元素之间分开，并且通常不在（）中。请注意，专业化的命名听起来像是与数据对象（例如付款人）对应的名词，而不是行为（例如管理付款人）。还请注意，打字错误导致收款人出现两次

编辑：更多关于UC中的泛化 在UC中使用继承有一些争议，因为它的实际意义不如其他类型的关系直观

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

但就个人而言（看看评论和其他答案，我并不孤单），我建议不要使用它。它使一个简单易懂的图表变得更加复杂，具有不同的抽象层次。在本书中，值得一提的是，UC的发明者：

• 在继承之前，他没有在UC中使用继承