我可以清楚地看到使用UML图表显示应用程序的基础结构（类名，成员，彼此之间的通信等）的好处。
我现在正在开始一个新项目，并且已经构建了数据库（使用可视范例）。我想使用一些设计模式来指导我如何编写类。
我想，我应该在创建它的UML图之前先编码类（可能是代码中的......似乎可能）或者我应该首先创建UML图然后编写代码（或者从UML生成代码，似乎也可能。）
你有什么经验告诉你最好的方法？
答案 0 :(得分：12)
重要的是，您在编码之前，期间和之后思考。如果UML帮助你这样做，你应该使用它。根据您编写的程序，您可能希望在编写代码之前关注算法，体系结构或用户界面。
即使在你开始考虑如何你应该编写程序之前，你也应该考虑你应该编程什么。再一次，你写的那种程序决定了你应该考虑什么。
答案 1 :(得分：7)
我总是在开发过程中创建它们。这是个人偏见。
以迭代开发为例，意味着您的代码将随着项目的进展而发展。因此，预先创建UML图表是浪费时间，因为一段时间后，您的最终结果将与您开始使用的图表完全不同。即使使用迭代开发，测试驱动开发之类的东西也不会阻止UML图。在故事/任务的规划/设计过程中，UML图表可以派上用场。但是，这并不是说你应该盲目地为你编写的每一段代码编写UML。
相比之下，UML图允许您通过一些简单的图像向其他开发人员表达大型创意。从图中，其他开发人员可以掌握应用程序/组件的链接方式。
你最好使用UML图作为工具，而不是我认为的手段。拥有行业经验我可以向您保证，只是因为书籍会在编写任何代码之前告诉您编写UML /进行大量设计，所以很少（如果有的话）就是这样。
答案 2 :(得分：4)
我认为出于文档目的，UML图表几乎毫无价值，因为保持它们是最新的几乎是不可能的。但是我认为它们在开发之前和开始阶段都是很好的工具，可以考虑设计并与其他团队成员一起审查。所以我的答案在开始阶段之前会有一点点，而在此之后不会那么多。
答案 3 :(得分：3)
我在编码之前做模型（当我这样做时），用铅笔和纸，但我不做3周的图表或类似的事情。只是，1天或每次迭代开始。
花时间在图表工具中是失去宝贵编码时间（恕我直言）的最荒谬的方式。
过去，使用铅笔/纸和手机相机已证明是有用的。
答案 4 :(得分：2)
在开始之前设计一个设计总是好的做法。该设计是定义为UML图还是其他地方并不重要。问题是你需要什么样的细节？
如果您在工作的环境中需要进行设计审核，那么您将需要UML图表。他们只需要足够完整，以传达你将要做的事情。
我最近工作的每个地方都需要UML图作为可交付成果。我所做的是预先创建一些基本的，然后在最后修改它们，通常是通过逆向工程代码。
答案 5 :(得分：2)
我不是专业人士，在个人项目中只使用有限容量的UML。我在编码之前严格使用UML 的经验往往会导致我的个人项目陷入绝望之中。我认为这源于试图绘制尚未存在或未经适当探索的想法。
他们说“一张图片胜过千言万语”。我对此的解释是，在绘制图片之前，你必须有一个想法（或用文字）。艺术家不会画出日落的照片，然后决定画一幅日落的照片。反过来了。
Diagrams是一个文档工具。文档总是过时，意味着任何文档都是关于您过去做出的决定。根据我的经验，我发现最好以书面形式记录我的想法，然后绘制图表。像艺术家一样，你需要先确定你的图表，然后才能绘制图表。如果你不知道你在表达什么想法，你怎么画它的照片？
例如，用例图表示您决定用户应该从您的系统中获得哪些功能。类图是您对程序类的结构及其相互关系的决定的图示。
对于类图，从需求中选择名词并制作图表是无效的。您如何知道这些类是否实际支持支持用例所需的功能？研究系统，将想法分成模块，写下关于模块交互的决策，写一些初始类（或至少是他们的接口）巩固了你的想法。在图表中记录这些想法只会使人们更容易快速掌握您做出的决定。
如果您制作数据库图表，假设购买系统，您必须先决定订单有多个订单项，然后才能创建显示该图表的图表
实际上，我想说的是，我认为图表像所有文档一样过时。你有个主意;你把它写下来，这就是文档。你有文件;你绘制一张图片，以便更容易理解。我认为在分析问题并创建一个心理和书面模型后创建图表会更好。是否在做出每个决定后逐步添加到图表中，或者在做出多个决策后构建完整的图表取决于您。在你拥有它们之前，或在你理解它们之前制作想法图表，我认为只会导致困扰。
答案 6 :(得分：1)
what are you experiences telling you is the best way?
我正在使用UML进行建模，如果涉及到接口和类以及序列图表，使用IDE并声明它们并进行往返工程并看到所有这些方法和属性都出现在UML图表中会更加舒适。
在UML工具中声明所有内容太繁琐了。
只是我的意见。
答案 7 :(得分：0)
最好是让用户按照自己的意愿行事。 我的意思是如果他们想首先建模数据库然后建模应用程序，你需要将数据库转换为代码，然后将代码转换为UML。 如果您想先建模然后生成代码和数据库，那么您需要创建图表然后使用代码生成器。 如果你想用爱代码和模型同步建模和编码，那么你可以使用Hibernate工具在设计完成后将你的设计映射到数据库。
通常的UML循环是使用MDD技术建模然后生成代码。我更喜欢迭代方法，但除了Omondo UML之外，其他工具更喜欢使用MDD而不是简短的UML迭代周期。我不知道为什么...... ....
答案 8 :(得分：0)
这还取决于您使用哪种编程/脚本语言。 作为长期的php开发人员，我经常遇到麻烦，无法将现有代码可视化为UML。我所知道的大多数图表工具都不支持PHP脚本中经常使用的混合数据类型。 @see Is it possible to visualize a bunch of functions in UML
您写道，您是以可视化的范例制作了数据库的结构，因此我假设您也想在该程序中制作UML图表。 使用Visual Paradigm，只有在使用付费版本时，您才能导入源代码并获得uml表示。在免费社区版本中，该功能被禁用。 如果使用免费版本，则在编码之前，期间或之后绘制UML都无关紧要。 在大多数情况下，当开始一个新项目时，一切并不清楚，在对项目进行编码和测试时，会出现在讨论项目时未考虑的问题。但是，在开发过程中，通常还会有客户提出的更改/适应要求，因此无论如何都必须更新图表。因此，我很少使用UML，通常在编码时使用。
但是正如我的前任所写，每个人都可以按照自己的意愿去做。 UML是创建文档的多种方法之一。绝不应该忽略的是内联注释。它应该说明谁编写了代码，应该执行什么代码以及期望使用哪些参数和数据类型。我已经不得不在没有这些信息的情况下调试很多代码，并且可以说这很麻烦。