C++ 不深入了解底层库的UML建模

对于我的下一个项目，我想尝试UML建模。有几个原因-主要是文档+为开发打下基础，以避免一次又一次地重新编码所有内容

在过去我已经尝试过好几次了，但是我有一种感觉，如果不深入了解我的工作所依赖的背景库，这不是一个简单的任务，因为在一开始我不知道我需要什么样的成员变量和函数

通常我编写代码是为了熟悉库和API，我的应用程序是接口，我进入了一种状态，工作几乎完成了，或者说是从50%准备就绪开始，开始建模对我来说毫无意义

我是真的吗？你真的需要很好地理解背景，还是有方法/技巧来克服这个问题

另一点是，您是从下到上还是从上到下构建模型，还是取决于用例

---

感谢您提供如何继续的建议。

如果我理解得很好，您的主要挑战是了解您正在使用的库和API

如果您打算创建一个UML图来对库进行反向工程并理解它，那么您可能会浪费时间：只有在您理解了各个部分是如何组合在一起的情况下，您才能创建一个有意义的模型。对于这一发现和知识获取，您已经使用了最有效的方法：

通常我编写代码是为了熟悉我的应用程序接口的库和API

现在，如果库或API与UML模型一起交付，那就是另一回事了：现有的设计模型（不是实现的所有细节，而是设计的核心元素，以及难以从代码中理解的交互场景）可以帮助您更快地理解库的工作方式，这将帮助您更快地完成探索阶段

---

当你在设计一个没有文档的应用程序时，情况也不一样：你没有教程，而且很难编写代码以有意义的方式使用现有的元素。在那里，事后记录系统是有意义的。但同样，不要迷失在一个包含所有细节的详细实现模型中：关注核心元素，这些元素的理解对您的维护人员非常重要

开发应用程序时创建UML类模型的三个主要目的是：

描述应用程序问题域的实体类型，以便在概念（域）模型中分析和更好地理解应用程序的需求

设计应用程序底层数据库的模式（这通常是一个RDB模式，由一组CREATETABLE语句定义）

设计应用程序数据模型的模型类，这些类将被编码，例如，作为Java实体类或带有EF注释的C#类

对于1和2，您可以查看我的书，而对于3，您可以查看一本关于基于模型的开发的书，例如For或

---

如果您的目标是为应用程序的依赖关系建模，那么这可能确实是另一个目的。然而，正如@Christope所说，对库进行反向工程本身就是一个大项目，可能比开发应用程序花费更多的时间。

UML建模最擅长描述业务逻辑，外部库不应成为业务逻辑的一部分。我同意最终的应用程序是否独立。然而，它依赖于其他的库，在这些库中，它的功能被设计。克里斯多夫，NoPE，主要的挑战是在嵌入式系统上编写C++应用程序。此应用程序依赖于两个主要库。更确切地说，我想写一个音频前端类。该类表示一个接收麦克风输入、过滤麦克风输入并输出结果的门。播放也一样。对于过滤，有一个库，对于音频，也有一个库。现在，我想对我的类及其与底层库的交互进行建模。