在开发之前对现代应用程序建模的标准是什么？

我正在处理我的第一个企业级应用程序，我希望我的团队在提取代码之前就对整个ASP.NET MVC C＃应用程序进行建模。

更新：这并不是要对何时记录/建模应用程序进行哲学上的讨论。请仅提供有关“如何”文档/模型的答案。

事实是，我一直在这个部门中工作过，而且从未真正建模过应用程序。这样做的标准方法是什么？应该使用哪种类型的图表以及文档外观如何？链接到示例图和文档表示赞赏。

在搜索时，我可以在网上找到很多东西，但是我想看看是否存在关于如何执行此操作的现代共识。

提前致谢！

结束语

我不知道这是一个棘手的话题。谢谢所有能够抛弃明显争议并提供有用答案的人。至少可以说这是一个有趣的讨论：)

我发现的另一个有用链接是：https : //stackoverflow.com/questions/61487/do-you-use-uml-in-agile-development-practices/61519#61519

当前的现代共识

事实是：当前，这是现代软件开发所缺乏的-关于建模的共识。UML似乎是某种最小的公约数，但实际上在符号上只有共识，而在语义上却没有共识。关于应如何解释UML来创建代码，存在许多不同的意见（也许您可以找到一种对您的团队来说可行的解释）。

另一方面，在那些说“不要建立正式模型，更好地编写工作代码”的“敏捷”人与那些在思考诸如“解决方案是“ MDA”（模型驱动的体系结构）。

其他人（重新）发现了用于现代软件设计的基于流的编程，以作为UML的替代方案。在此处和此处阅读以了解有关此内容的更多信息。

我希望我的团队为整个ASP.NET MVC C＃应用程序建模，然后再抽出一行代码

我通常用这种方法发现的问题是，一开始我对解决方案的理解总是不完整的。只有随着工作的进行，我才能最终确定解决方案。

试图在没有任何代码（除了最简单的应用程序之外的所有代码）之前先设计整个应用程序通常是愚蠢的。

您真的相信您可以预先详细安排每个类，方法和数据结构吗？

我只想知道一些好的建模解决方案。

至于制作模型的实际工具，我已经尝试了几次，并且最终还是回到Microsoft Visio。

在我尝试过的所有产品中，这似乎是最直接，最稳定的（我在建模工具方面的经验是它们非常有缺陷）。公平地说，我很少进行建模，因此建议您花点时间。

编辑：实际上，我应该说，我的大部分建模工作都是在桌上的记事本上完成的。因为我很少进行建模，所以我尽量保持简洁。对我来说，用纸和笔草绘图表比使用软件要有效得多。

您可能会发现手写图表在形成图表软件之前，对形成您的想法很有用。

应该使用哪种类型的图表以及文档外观如何？

这些天我建模的大部分都是交互图。再说一次，我并没有做太多的建模工作，只是在我真正感觉到绘制模型的练习有助于我理解的地方。

UML图表是一个很好的起点，有很多简单的方法可以使用免费或付费软件来实现。制作UML的工具的一个简单示例就是google docs绘图，更高级的软件包是Visio或OmniGraffle。

编辑：正如许多人提到的那样，如果您要走UML道路，那并不意味着您必须对所有内容进行完全建模，但是您可以就正在建模的内容以及模型需要的详细程度达成共识。是。简单的UML图通常可以帮助您在编写代码之前对代码进行布局，并在出现潜在问题之前将其清除。

正如@Brett所建议的那样，UML图是最好的。使用UML最好具有类图和工作流程图。这两个将满足大多数设计需求。

使用类图，您可以对每个实体的成员，其安全级别等进行建模。

使用工作流程图，您可以对哪个方法调用，哪个方法调用，工作流程的结果以及可能弹出的异常进行建模。

虽然我坚信在编写代码之前先制作一些基本的架构图，但我认为对整个应用程序进行详细的图面工作太多了。

我通常在Visio中创建一些轮廓图，经常使用“流程图”构建块来形象化我的意思。使用UML常常让人感到形式化，并吸引了太多细节。Visio绘图显示了该应用程序的基本构建块以及哪种功能类型适用于何处。如果您使用的是MVC框架，通常只需从网络上抽取样本并进行复制即可完成。

一个好主意是从其他角度制作一些图纸。除了绘制所有内容，我通常更喜欢采用系统的一种特定功能，然后将其可视化为：

• 用例图（UML）
• 流程图或UML泳道（非常高级）
• 建筑组件概述。

然后我们开始编码。编码时，我使用带有点集成的doxygen来获取即时的类图，继承等。查看doxygen生成的概述通常是查看代码结构的好方法。