您多久使用一次正式UML？

我使用临时MUML（虚构建模语言）来相当频繁地设计和解释系统。它看起来与UML相似，并且易于理解。

但是，我有一位或两位教授曾试图使用严格，正式的UML（尽可能接近规范）。我一直怀疑严格的UML并不像他们声称的那样普遍。那么，如何“折腾”-您实际上多久绘制一次使用所有适当的行尾，多重性，成员类型符号等的完整图表？

决不。

哎呀，距离我上次创建任何 UML 已有好几年了。白板上的折线图和碎纸片不算在内。

实际上，我们只是从访谈过程中使用的指南中删除了唯一的UML问题，因为我们当中没有人真正关心答案。

我只使用了足够的UML（就图的类型和图中信息的内容而言）来阐明我的观点，以允许我自己或其他人实现系统或子系统。我使用UML的唯一原因是因为它包含一组众所周知的符号，每个符号都具有非常特定的含义，因此没有歧义-任何软件工程师都应该能够查看该图并理解我要说的内容。系统。

具有讽刺意味的是，UML应该是灵活的。

在现实世界中，它不应该是一个迂腐演习做一个正确的方式。它与有效地沟通和记录系统/过程/想法有关。

为了回答您的问题，我和其他人在一起。我从未充分利用过完整的正式UML。

我将UML定期使用约四年的时间来生产从Rational Rose生成其所有（大部分）代码框架的产品。

在过去的五年中，出现了更多的“盒子和箭头”，它们大多是当场发明的，通常足以使人们理解该总体思想。在此期间，仅几次正式校正UML。

但是，我有一位或两位教授曾试图使用严格，正式的UML（尽可能接近规范）。

问问您的教授什么时候是他最后一次在实际系统上使用这种方法。说真的

当涉及到UML时，我会尽量做到正式，但前提是/在有意义时。双方的狂热分子（从牛仔到拘谨的形式主义者）都无法理解这一点。

在某些情况下，较不严格的方法（如您个人使用的方法）是最好的方法。一个很好的例子是小型系统或变更，这些系统的需求很小并且没有完全定义。负责组是有效的和有效的；做到这一点比使其完美更为重要。它是反复进行的，有些缺陷是可以接受的。

或者，也许您正处于一个客户化和素描阶段，而不是一个完整的正式建模阶段。这些就是我想到的例子。

在其他时候，您需要严格的正式UML方法。例如，您可能受合同约束；您在多个团队中有大量的开发人员（可能是分布式的）；项目范围可能以年为单位；它是一个非常大的系统（包括软件和硬件组件）；失败的代价很高，等等。

在其他时候，除了UML（诸如Petri网，CSP或时间逻辑之类的实际数学形式模型）之外，您还必须使用其他替代方法。例如，实时系统，灾难性灾难性系统（医疗设备）或受合同约束的地方（例如，在开发运输系统时在欧洲）

这完全取决于环境以及我们希望从每种方法中获得什么。一位坚持拘泥于形式的教授简直就是盲目的狂热分子。工程界不是黑与白，正确/错误的二分法。这是一个明智的权衡世界。

如果您足够聪明，可以以有效且合适的方式使用休闲的非正式模型来完成工作，那么就可以了。同样，您将被期望识别何时不使用非正式方法和/或何时不使用正式方法。

话虽这么说，您必须与教授们耳熟能详。给他们一根骨头，以便他们给您一个等级，如果这意味着最终屈服于他们的狂热者咒语，那很好。您知道什么对您有用，并且希望您知道何时在现实世界中使用什么以及如何使用。

作为博士研究的一部分，我研究了经验丰富的设计师如何在设计协作中使用UML（尽管在人工环境中）。

我的发现是借用了UML隐喻和符号，但是很少坚持使用这些工具的严格性。

后来，某些模型可能会迭代地转换为更严格的UML，通常当出于代码生成的目的而使用了要求苛刻的CASE工具时。

当然，通常需要进行学术研究的警告：）

链接到论文摘要和论文本身（如果你没有ACM访问）。

除此之外，我强烈推荐Ambler的“敏捷建模”。

我们使用正式的UML生成休眠ORM的代码。其他大多数东西是非正式的或白板的。对于我们来说，代码生成仅是重要的，因为缺乏形式化会破坏代码。

这取决于您所在的行业。如果您为需要经常进行技术审查的客户（例如PDR，CDR等）工作，则他们更喜欢某种标准化而不是临时的注释系统。特别是政府工作。它可以防止沟通不畅以及对您所发明符号的最初15分钟的解释。

同样，仅仅因为您正在使用UML并不意味着您必须按照标准对每个i进行点划线并对每个t进行交叉。仅当您要执行某种自动代码生成/执行时。我不知道有谁在一个以上的项目中做到了这一点。

另一方面，如果您仅与自己的开发人员团队一起为公司工作，那么谁在乎您使用什么符号。虽然，如果您选择了正确的工具，那么它可以节省大量时间。

综上所述，如果不使用UML进行设计，您将发现在某些行业很难实现。在其他行业，您将永远不会看到它。

另外，我认为您还会发现那些要求设计正确的行业之间的相关性，因为校正的成本相对较高，因为它们是UML的重度用户。与行业相比，设计校正的成本只不过是文档/代码更改而已，因为UML可能从未使用过。

关于原始问题。大多数大学倾向于为最经常招收学生的公司提供培训。如果您的教授认为UML很重要，那么从您学校招募的许多企业都使用UML不会令我感到惊讶。因此，您应该学习使用它。

当我读到有关UML的文章时，我尝试了在C ++课程中要解决的所有问题。幸运的是，我尝试的第一个示例是描述一个链表。
没用
话虽如此，再加上良好的建模过程，UML很有用。仅仅因为它是更好还是更坏的标准。
我希望看到模板元编程的描述语言。我认为这将有助于理解<<<>>>土地的状况

如果您还尝试模型驱动开发，那么UML会很痛苦。我的意思是，UML仅是一种非常有用的图形表示法，其他所有东西都没有用。我不花时间在建模上，而是每天使用UML来创建项目的结构。我要做的是在需求级别上快速绘制基本用例图，然后立即切换到类图。我在用例图和类图之间添加了需求可追溯性。我的类图还创建了代码，因为它是实时同步的。在所有模型的代码中，没有标签被保存在映射到Java项目的UML模型中。

我用几个类图创建应用程序的框架，然后切换到代码。完成代码后，将其与模型合并。它是代码与模型之间的一种迭代，其中代码运行模型。因此，我的类图给了我更高层次的抽象和代码，而我的代码给了我业务逻辑实现（例如方法）。

UML建模每天需要少于10分钟的时间，这是在我需要时间思考我需要开发什么以及如何开发时完成的。

UML很棒，很棒而且非常有用，但是模型驱动的开发是没有用的！

如果要记录我们已实现的系统，则尝试使用完整的正式UML进行设置。但是在其余时间里，我只会使用必要的时间来传达想法。我还发现自己使用的DFD比UML多，因为它们似乎更适合我们最近设计的系统。

我刚离开我所谓的一流大学（至少是暂时离开了），因为他们坚决坚持过度耗时的可视化建模活动，论坛琐事，过度冗余的软技能，这些人都是在计算机周围长大或曾沉思地学习过的人朝着用户界面的方向发展就足够了，因为陷入债务的想法会使人们想彻底挫败。

我必须在学习看到的入门级和初级职位要求以及大学CES为大学的ABET认证设置的条件之间做出选择，这使决策者在存在时间限制和不切实际的期望的明显问题时表现得愚蠢。 PERT评估会显示出来。大学不实践所教的内容。

在我看来，统一过程有很多优点，但是在铸造视觉工件的整个过程中，无论哪种建模语言都有点荒谬。包含序列表的迭代优化文档，例如可以使用Word，Workflowy，Evernote，OpenOffice或名称文字处理器生成的列表，完全可以记录统一流程所需的内容。这个纯洁的东西可以由多个用户轻松地进行处理，受版本控制，如果选择了正确的工具来进行安装，则团队甚至可以同时进行处理。这比UML似乎是将部落团结在一起的必要方式时要容易得多。