Uml 您是否先设计/绘制/绘制开发解决方案，然后再进行开发？如果是，怎么做？

我经常与希望在业务中更好地使用技术的决策者合作。我发现，一张图片抵得上千言万语，在某种图表中原型化一个系统总是有助于讨论。我使用了Visio、UML（有些）、思维导图、流程图和模拟WinForms来启动这些赞助商的愿景，以确保每个人都在同一个页面上。我似乎一直在寻找一种通用的流程，它可以用来将业务愿景与开发流程结合起来，这样我们最终都会走到同一条路，“解决问题的功能性流程”

我正在寻找关于如何处理设计过程的建议或注释，以使其适用于可能只需要一周时间开发的应用程序，但也可以用于包含更大的项目

我知道这是对UML领域的深入研究，但我发现我很难找到适当使用各种图表类型的指南，更不用说帮助业务用户理解图表并与之相关

您使用什么来捕获系统/应用程序的愿景，然后向项目发起人展示？（在编写一行代码之前）.

纸张或白板

对于孤独的开发者，我推荐纸张。至少在一开始，最终您可能希望用UML对其进行形式化，但我认为这不是必要的

对于一组一起工作（实际工作）的开发人员，我建议使用白板。这样每个人都可以看到，每个人都可以改进和做出贡献。再一次，你可能想在这一点上正式化，但我仍然不认为这是必要的

当我第一次开始做OOP（或设计一个算法）时，我会在编写代码的时候在脑海中完成这一切。但是在做了一些合理的复杂项目之后，我肯定看到了绘制系统中不同对象之间交互的好处

我自己做项目，所以我使用很多索引卡来设计课程，并为互动撰写论文。关键是它需要容易改变。我曾经使用Dia，一个图表编辑器，来进行UML，但是进行更改太困难了。我希望能够快速做出改变，这样我就能找出最有效的方法

值得一提的是，TDD和“spike”[1]项目在设计系统时也会有所帮助

[1] 摘自《C#中的极限编程冒险》，第8页：

“Spike”是一个极端的编程术语 意思是“实验”。我们用这个词 因为我们认为钉子是一种 快速的，近乎蛮力的实验 旨在学习一件事。 想一想把一个大钉子穿过一个洞 董事会

摘自詹姆斯·亚当斯：

智力障碍会导致一个错误 心理策略的低效选择 还是智力不足 弹药。1.解决问题 使用错误语言的问题 （口头、数学、视觉）——如 试图解决一个问题 在数学上，当它可以更容易 目不转睛

（第71页，第3版）

不用说，如果你选择用图表来捕捉那些可能用数学捕捉得更好的想法，那同样糟糕。当然，诀窍是找到正确的语言来表达问题和解决方案。当然，用一种以上的语言来表达问题和解决方案可能是合适的

我的观点是，你认为图表是最好的方法。我不确定我是否愿意做出这样的假设。通过其他一些框架需求和建议设计的方法，您可能会得到更好的答案（客户可能会对结果更满意）

顺便说一句，强烈推荐阅读概念封锁。

阅读Kruchten的文章

这里有一个方法可以继续

将用例收集到用例图中。这将显示参与者和用例。这个图表不是从很多细节开始的

对用例进行优先级排序，以关注高价值用例

写故事。如果需要，可以绘制活动图

以上是完全非技术性的。UML对要使用的形状强加了一些规则，但除此之外，您可以用最终用户术语描述事物

您可以进行名词分析，绘制类图来说明实体和关系。首先，这些将是用户术语。没有古怪的技术内容

您可以展开活动图或添加序列图来显示处理模型。这将从最终用户、非技术性的处理描述开始

您可以迭代类和活动图，从分析过渡到设计。在某个时刻，您将脱离分析，进入工程模式。用户可能不想看到所有这些图片

您可以为开发视图绘制组件图，为物理视图绘制部署图。随着您对系统概念的扩展和细化，这些也将不断迭代

---

在设计应用程序时（我主要创建web应用程序，但这也适用于其他应用程序），我通常创建用户故事来准确确定最终用户真正需要什么。这些构成了典型的“业务需求”

在确定用户故事之后，我创建流程图来展示人们在使用该应用程序时将采取的路径

在这一步之后（有时需要审批流程），我创建了界面草图（钢笔/铅笔和图表纸），并开始数据库的布局。这一步和下一步通常是最耗时的过程

下一步是绘制草图并将其转换为清理过的线框。这一步我使用OmniGraffle——它比Visio早了几光年

在这之后，你可以