ea uml创建项目_在项目上不使用UML是致命的

ea uml创建项目

OMG在大约20年前的1997年将统一建模语言 （ UML ）用作标准。 但是，尽管它具有很长的使用寿命，但令我不断惊讶的是，很少有组织真正使用它。

代码是软件的终极模型，但它就像森林的树木。 您可以看到一对夫妇，但是只有很少的人仅通过查看代码就可以看到整个森林。 对于我们其他人来说，图是查看森林的方式，而UML是图的标准。

他们说：“ 一张图片值得一千个单词 ”，这对于代码来说是正确的； 即使在大型显示器上，您也只能看到很多行代码。 所有其他工程学科都有复杂系统的图，例如飞机的设计图，建筑物的蓝图。 实际上，需要在创建飞机或建筑物之前创建并批准这些图。

与很少生成UML图表的软件相比，或者如果生成了UML图表，则将它们作为事后思考来生成。 具有讽刺意味的是，推动构建架构的人们很快说没有时间制作图表，但是当架构糟糕时，他们是第一个抱怨的人。 UML是计划的关键（请参阅不为失败者准备计划 ）。

我认为发生这种情况是因为开发人员像所有人一样，都专注于他们现在可以看到和触摸到的东西。 尝试编写GUI交互或解决数据库更新问题要比通过GUI与数据库之间的交互在抽象级别进行工作要容易得多。

但这就是所有架构所在的地方。 良好的体系结构使中型和大型系统的一切都变得不同。 架构是将软件组件固定在适当位置并通过结构定义通信的胶水。 如果您不计划系统的层和模块，那么以后您将不断做出妥协。

特别是，如果不考虑体系结构问题，则大中型项目（> 10,000个功能点）极有可能遭受失败。 考虑到10个软件项目中只有3个是成功的，只有傻瓜会跳过对体系结构的规划（请参阅Failed？您得到了应有的！ ）

好的图表，尤其是UML，可以使您抽象化实现的所有低级细节，并让您专注于计划体系结构。 这种更高级别的计划可以带来更好的体系结构，从而带来更好的软件可扩展性和可维护性。

如果您是一名优秀的编码人员，那么您将能够通过更高层次的抽象工作，从而在解决大型问题方面取得巨大的飞跃。 我们多久发现自己仅由于架构不支持简单功能而无法实现简单功能？

架构不支持它，因为我们花费很少的时间来开发系统架构的蓝图。

UML图需要在两个级别上生成：

• 分析或“什么”水平
• 设计或“如何”级别

分析UML图表（类，序列，协作）应在项目早期生成，并支持所有需求。 理想情况下，您使用一种需求方法，该方法可让您轻松地将需求从需求追踪到图表上。

分析图上没有实现类，即没有供应商特定的类。 目的是确定高级概念（用户，仓库，产品等）如何相互关联。

这些分析级的UML图将帮助您在进行设计之前确定需求中的差距。 这样，当您在走得太远之前识别出缺失的要素时，可以将您的BA和产品经理送回去，以收集缺失的需求。

一旦分析图确认需求相对完整且一致，就可以使用实现类创建设计图。 通常，分析图是设计图的一对多。

由于您已经在分析级别验证了架构，因此现在可以在设计级别进行操作而不必担心会损害架构完整性。 设计级别完成后，您可以在不影响设计级别的情况下进行编码。

完成分析UML，设计UML和代码后，所有这些都将同步。 良好的软件要从上至下正确计划和执行。 用这种方法来创建软件在心理上更加困难，但是替代方法是连续修补程序，并且永远不会结束错误修复周期。

因此，请记住以下来自科维“高效人才的七项原则”的示例：

您进入一个空地，一个人正在狂怒地锯大木头，但是他没有任何进展。 您会注意到锯很钝，无法切割木头，所以您说：“嘿，如果您将锯磨尖，则锯木会更快。” 该名男子回答说：“我没有时间，我正忙于查看日志”。

不要成为一个无聊的家伙

UML是使锯锐化的工具，它确实需要花费一些时间来学习和应用，但是您将节省更多的时间并获得更大的成功。

参考书目

• 科维，斯蒂芬。 高效人才的7种习惯
• OMG， 统一建模语言™（UML®）资源页面

翻译自: https://www.javacodegeeks.com/2014/12/not-using-uml-on-projects-is-fatal.html

ea uml创建项目