C 应用程序建模
我想知道是否有任何工具可以帮助我对 C 应用程序（即函数式编程）进行建模。 例如，我目前正在构建一个共享库。 但为了直观地传达我的设计，我需要类似 UML 的东西。 我想这样做，这样审查我的设计的人就不需要阅读数百页的函数、变量等。
我读过有关 C 的 UML，我正在考虑。 如果有更好的东西，请告诉我。 最重要的是可视化 C 应用程序和模块的设计，而无需阅读数百页的文本，因为这需要时间并且对于审阅者来说很困难。
非常感谢这里的专家在这方面的任何帮助。
谢谢。
I would like to know if there are any tools that can help me model C applications i.e. Functional programming.
E.g. I'm currently building a shared library.
But to communicate my design visually, I need something like UML. I would like to do this so that the person reviewing my design need not read through 100s of pages of functions, variables and so on.
I have read about UML for C, which I'm considering.
If there is anything better out there, please let me know.
The bottom line is to visualize the design of C applications and modules without reading through 100s of pages of text, because it takes time and is difficult for the reviewers.
Any help in this area from the experts here would be much appreciated.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一份写得好的文本文档可以让你走得更远。 比任何 UML 图所能达到的目标都要远得多。
A well written text documentation brings you a far. Much further than any UML diagram could ever achieve.
您应该将其分为两部分：
无论您使用什么形式来回答第二部分，您都应该确保它没有歧义。
UML 的优点在于，许多语义已经由语言定义，因此您不必在协作图中包含这些框、线和箭头含义的定义。
但最重要的是，记录某些内容意味着为其他人创建一条了解您正在记录的主题的路径。 非常精确的描述如果没有提供如何阅读的线索，那还不如没有。 因此，可以使用 UML、有限状态机、ER 图、简单英语，无论您想要什么，但一定要包括一条逻辑路径，您的“读者”可以遵循该逻辑路径来理解正在发生的事情。
我有一个朋友是“不惜一切代价追求精确”的粉丝，它会要求我们在某种意义出现之前仔细检查所有细节。
我曾经让他做这个实验：在他下次去一个未知的城市旅行时，他必须携带他能得到的最精确的地图。 更好的是，他必须携带一张 1:1 的城市地图，每一个细节都按比例准确记录。 这样他就不会迷路了！
他拒绝了，但我很乐意看到他尝试使用那张地图。 甚至折叠它！ :)
You should split this in two parts:
Whatever formalism you use to answer the second part, you should be sure it's not ambigous.
The good of UML is that a lot of semantic is already defined by the language so you don't have to include a definition of what those boxes, lines and arrows mean in a collaboration diagram.
But most importantly, documenting something means create a path for others to understand the subject you are documenting. A very precise description that offers no clue on how to read it is as good as none. So, use UML, Finite state machines, ER diagrams, plain English, whatever you want but be sure to include a logical path that your "readers" can follow to understand what's going on.
I had a friend that was a fan of "preciseness at all cost" and it would ask us to go through all the details before some sort of meaning would emerge.
I once ask him to do this experiment: on his next trip to an unknown city, he would have to carry the most precise map he could get. Much better, he would have to carry a 1:1 map of the city with every single detail exactly reported in scale. That way he couldn't get lost!
He declined but I would love to see him trying to use that map. Just even folding it! :)
随你喜欢。 它不是标准，但许多开发人员使用它并理解它。 如果它确实有助于您与其他人沟通并记录您的工作 -> 这是给你的。 如果它花费太多时间并且你认为它没有效果，那就放弃它。 另外，不要理会所有细节，只要它类似于 UML 并且您的团队可以使用它，就可以了。
它的目的是帮助你，而不是浪费你的时间。
Whatever you like. It's not a standard but many devs use it and understand it. If it does help you to communicate with other people and document your work -> its for you. If it just takes too much time and you think it's not effective, drop it. Also, don't bother with all details, as long as it resembles UML and your team can work with it, it's fine.
It's meant to help you, not waste you time.