draw使用UML驯服需求工程难题
所有职业在施加给从业人员的特殊挫折中都是独一无二的，软件开发也不例外。软件具有相同的物理无形特性，使人们更难以识别风险和要求，这也可以使人们普遍认为，软件开发比实际要容易得多。结果往往是对计划正确完成工作所需的成本和时间的不切实际，不明确的期望和错误判断。
这些不正确的需求定义是软件产品中缺陷和不足的最常见原因之一。一项针对GitHub开发人员的民意测验将这种不切实际，含煳不清或不断变化的需求确定为压力的特殊来源。但是，它们当然不是让开发人员感到沮丧的唯一原因。让我们看看其中的一些其他挫败感，并探讨如何通过在draw.io中使用UML来缓解这些挫败感。
BUG
毋庸置疑，开发人员的主要烦恼来源是在代码库中查明不良或意外行为来源的熟悉的必要性。最令人震惊的例子是那些特别难以追踪的例子，那些拒绝消失的例子，意外离开左侧领域的错误，以及当然需要花费大量时间和精力来修复的那些。
劣质代码
无论您是从同事那里继承它，还是在您还年轻，天真时编写自己的代码，编写不好的代码都是开发人员痛苦的另一个明显原因。不清楚或不存在的评论只会使情况变得更糟。
代码维护
然后，需要理解，建立或简单地维护不熟悉的旧代码（尤其是当它是由一位已故的同事编写的代码时），或者更糟的是，“由委员会构建”并在一段时间内由开发人员传递给开发人员。
但是足够解决问题。您已经知道开发人员面临的问题。让我们谈谈解决方案。简单易懂的通讯是任何行业中解决许多问题的最有效解决方案之一。
跟我说话
因此，我们无需深入探讨沟通为何如此重要的所有细节。那是一个不同的博客。但是我认为我们都可以同意，就软件开发而言，准确而完整的沟通对于取得一致的积极成果至关重要。不过，在谈论交流时，记住乔治·伯纳德·肖所说的话很重要：“交流中最大的唯一问题是它已经发生的幻觉。”
有时，尽管我们尽了最大努力，但我们进行交流的尝试却失败了。或更糟糕的是，我们最终会造成混乱，而不是清晰。正是在这些时候，我们需要研究使自己清晰的其他方法。
给我看看
我们之前已经讨论过可视化在成功学习中的重要性。我们甚至引用了研究来证明这一点。但是，除了帮助实际学习或保留信息之外，视觉传达还只是将信息从一个人准确而有效地转移到另一个人的一种更有效的手段。就像威廉·阿尔伯特·阿拉德（William Albert Allard）所说的那样：“文字和图片可以一起协作，比单独使用时更有效地进行交流。”
为什么会这样呢？原因很多-包括：
时间–研究表明，大脑处理图像的速度比文本处理速度快60,000倍。太快了
语言/文化–口头交流本质上仅限于语言。即使共享一种语言，不同的文化也会增加另一个难度。图像比单词更能被普遍理解。
简洁性：好的，我会说：一张图片值得一千个字。如果有选择，您宁愿创建哪个（或花点时间阅读）？
统一语言
您可能已经熟悉UML，但让我们花一点时间确保我们都在同一页面上。创建UML是为了标准化软件设计中使用的符号系统。它代表统一建模语言，由一组集成的图表组成，可帮助软件和系统开发人员可视化，记录，指定和构建软件和非软件系统。在业务建模中也很有用。它是最佳实践的汇总，这些最佳实践随着时间的推移在复杂系统的建模中取得了成功。
在这里，它可以减轻所有前面提到的烦恼。
UML的一些好处包括：
使每个团队成员都处于相同的地位，并迅速带动新的团队成员全面了解系统。而且，一旦团队成员了解了他们要构建的内容，他们就可以委派任务，在工作开始之前确定可能的问题，并更有效地朝着一个共同的目标努力。
使您可以灵活地定制图中的建模交互和元素以适合您所使用的技术或领域。
在对新功能进行编程之前，应对它们进行规划和评估。与重新编程整个代码段的繁琐且耗时的任务相比，更改UML图更容易，更便宜。
与技术和非技术受众进行更轻松有效交流的能力。
无需花费数周的时间进行学习。您只需要了解20％的UML即可满足80％的建模需求。
但是，利用UML带来的所有强大优势的最简单，最有效的方法是什么？
draw.io
draw.io是Confluence团队使用图表进行协作的最简单方法。这很直观。功能强大。它会挡住您的路。它可以帮助您构建从流程图到组织结构图再到ERD，思维导图的图表，是的，UML。
要为您的UML图使用draw.io，只需启用UML形状库。这是如何做：
在左侧面板中，单击“其他形状”。
向下滚动以在左侧的“软件”部分中找到UML形状库，确保已选中复选框，然后单击“应用” 。
如果您的团队在Confluence中大量使用UML图，则可以 自定义draw.io以默认显示此库。如果您需要图表遵循UML 2.5规范，我们也有一个用于该 图表的库：diagrams.net/blog/uml-2-5。
在我们的档案中，您可以在draw.io中找到有关UML的更多信息。