我有一个我写的 Access db，在过去 3 年里我用它来做我的支票簿和预算。我以前从未编写过程序，但我决定将数据库编写成一个独立的程序。除了数据库本身的简单 VBA 之外，我唯一的经验是 C++ 类的介绍和 OO 逻辑类。
即使我知道我想让程序做什么（因为这是我的数据库现在所做的）我想尽可能正确地进行规划和设计，所以我可以尽可能正确地编写程序，以便功能添加和维护更容易。
我需要帮助计划。我想 UML 图应该是第一位的。我需要做什么 UML 图？并按什么顺序？我试图做一个用例，但由于程序只涉及我、我的钱、银行和商店，这似乎毫无意义。还是我想错了？我需要在我的账户中绘制我的资金和预算吗？我不知道。我需要有关如何进行的帮助。谢谢。
拥有一组 UML 图来跟踪正在发生的事情是很好的，但最终要记住文档会衰减——您的代码就是您的设计。也就是说，UML 有利于规划和召回位和部分。这里涉及大量的个人经验，所以请随意拿走你想要的，而忽略你认为不适用的。
用例图
跳过这个，只写用例。
类图
我发现它们对于规划架构的全局视图很有用，但我通常会省略所有方法名称，或者只保留相关的 . 我用它来说明你的类的逻辑模型
序列图
更有用的图表之一，尤其是对于业务逻辑和数据流。我总是发现自己在为复杂的数据流绘制序列图，尤其是在调度事件时。
对象图
显示运行时对象的交互。我通常为复杂的对象交互绘制那些，而不是“学术上正确”的那些。我认为它不如序列图有用。
流程图
如果您的流程复杂，则适用于网站
状态转换
如果您的应用程序有许多状态，这很重要。同样，只需勾勒出最复杂的系统，没有必要为每个子系统都有一个。
ER图
我知道这不是 UML，但前期良好的数据库设计很重要，ER 图将帮助您组织和规划不同表之间的关系
由于您的应用程序是供个人使用的，我认为您实际上只需要两个图表，也许三个。如果需要，您可以使用用例图，但最好只使用用例列表。由于没有其他人声明过，因此用例是您声明要使用它的东西的要求。这些可帮助您定义所需的功能。
接下来，您需要有关如何组织程序的类图。类图显示您拥有哪些类以及它们是如何连接的。这对于确定您的程序是否过于复杂或者您是否使用称为 blob 的反模式很有用。如果您有很多线将类相互连接，您可能需要重新组织以查看是否可以使每个类更具凝聚力，如果您看到的类很少，您可能需要检查 blob 反模式。反模式是一种常见的现象，它不利于可读性或可维护性。类的凝聚力是由每个类是否具有它所需要的东西来定义的。例如，如果您决定为您的帐户开设一个课程，它不需要知道与您的帐户无关的信息，例如街道地址或银行名称。
我认为您需要的最后一个 UML 图是一个序列图，它显示了程序中的不同对象将如何交互。这将帮助您更好地了解您的类正在执行的交互，并决定如果它们变得过于复杂，您是否需要更好地组织它们。
这些是您可能需要的 UML 图。您可能还需要一个网络图来了解您的数据库将如何连接到银行的网站并获取您需要的信息。
这些图表只是为了让您了解自己在做什么并让您保持正轨。我想你已经知道了。在您的情况下，我相信一个详细的用例就足够了，只是为了确保您处理所有功能并且不要忘记任何事情。（提醒：用例不是图表。它是文本）