使用 UML 进行敏捷开发
Using UML for agile development
我在阅读时遇到了一些令人困惑的问题
“UML 由 Martin Fowler 提炼。”
问题一
本书中提到：
The three ways of using UML: sketch、blueprint, and programming language.
我们的教授，要求我们把class和运算的“全部”画出来，然后开发，而我们在做系统分析和设计。
所以我很怀疑是不是martin说的“伪迭代开发”
是“蓝图”用UML吗？
问题二
本书中提到：
"Each iteration doesn't start from scratch;
rather, it modifies the existing body of documents, highlighting the changes in the new iteration."
然而，教授要求我们在 existing class dev.
的每次迭代中修改并添加更多 classes
以设计Class图为例。第一阶段，我们只有很少的“class”，但是教授让我们继续添加
first stage class diagram
更糟糕的是，这样，到最后阶段，class变得太多了，甚至无法理解，也不会用来交流（如图）。
tenth stage class diagram
因此，如果教授误解了“修改现有文档主体”的含义，我很困惑？
如果教授教的不对，"怎么用，什么时候"修改现有文件主体"？只有相关的class吗？图？
谢谢。
详细回答您的问题会使我们相距甚远。
理论上是的。但实际上您只会在前两个步骤中使用 UML。曾经也有使用 UML 进行编程的想法，但老实说，编程语言在这方面要好得多。将 UML 保持在某个抽象级别。编程时要具体。并想方设法不在两者之间造成太大的裂痕。蓝图只是比草图更具体，但仍然是通往最终程序的抽象方式。
您可以通过将行为置于操作中来使用 UML 进行编程。这通常只是简单的程序代码。状态机也可以转换为目标代码。还有可执行的 UML，但我没有这方面的计划。如果你好奇，就 google。
迭代确实从某个现有的先前版本开始。但现在你有很多方法可以带你去罗马。使用和不使用 UML 建模工具，按现状和未来建模都是一项艰巨的任务。您需要确定允许从当前步骤到达下一步的规则集。您可以通过引入版本号 and/or 原型来做到这一点。非常复杂。无论如何，您所描绘的第10阶段没有任何发展，只有增加。你需要找到结构。包是实现结构的一种方式。而且你最终不会得到一个大的 class 图，而是每个子域都有一对。
您在正常设计中所做的是创建处理系统各个部分的子域（例如 I/O、UI、持久性等）。现在您可以为这些子域制作包，您将与它们一起创建 class 图。此外，您还创建了图表来显示包和其中的 classes 如何相互关联。在这里您将使用包和 class 图。请注意，UML 与图表无关。这些图表只是向人们展示整个模型是如何构建的。
Q1
是的，作为蓝图使用。
Q2
你的教授理解正确。
就像一本书上说的，你从有限的范围开始，只有一些 classes。在进一步的迭代中，您可以使用目前创建的内容，并根据需要添加更多 classes、属性和操作，因为系统的复杂性会增加。有时您需要重新考虑并稍微 remodel/redesign（然后获取代码！）您已经创建的内容。这正是敏捷的意义所在。
您可能缺少的是您不需要将整个系统放在一个图表上。使用包来组织您的 classes（并使用包图作为项目内容的一种 table）。将您的单个图表分成更小的块，重点关注围绕特定主题的元素（这些将或多或少地反映您的包）。仅在其 "main" 图（显示包含此 class 的包的图）上显示 class 的所有详细信息，而在其他图上只显示 class 矩形和 class 名称以及特定关系所需的最终属性和操作（如果您的建模工具支持的话）。
由于您通常会按特定区域构建范围，因此您会发现您主要是在创建新包，而现有包只会有很小的变化（除了像 Tools 这样的包。那么您你会知道你走的路是对的。
我在阅读时遇到了一些令人困惑的问题
“UML 由 Martin Fowler 提炼。”
问题一
本书中提到：
The three ways of using UML: sketch、blueprint, and programming language.
我们的教授，要求我们把class和运算的“全部”画出来，然后开发，而我们在做系统分析和设计。
所以我很怀疑是不是martin说的“伪迭代开发”
是“蓝图”用UML吗？
问题二
本书中提到：
"Each iteration doesn't start from scratch;
rather, it modifies the existing body of documents, highlighting the changes in the new iteration."
然而，教授要求我们在 existing class dev.
的每次迭代中修改并添加更多 classes以设计Class图为例。第一阶段，我们只有很少的“class”，但是教授让我们继续添加
first stage class diagram
更糟糕的是，这样，到最后阶段，class变得太多了，甚至无法理解，也不会用来交流（如图）。
tenth stage class diagram
因此，如果教授误解了“修改现有文档主体”的含义，我很困惑？
如果教授教的不对，"怎么用，什么时候"修改现有文件主体"？只有相关的class吗？图？
谢谢。
详细回答您的问题会使我们相距甚远。
理论上是的。但实际上您只会在前两个步骤中使用 UML。曾经也有使用 UML 进行编程的想法，但老实说，编程语言在这方面要好得多。将 UML 保持在某个抽象级别。编程时要具体。并想方设法不在两者之间造成太大的裂痕。蓝图只是比草图更具体，但仍然是通往最终程序的抽象方式。
您可以通过将行为置于操作中来使用 UML 进行编程。这通常只是简单的程序代码。状态机也可以转换为目标代码。还有可执行的 UML，但我没有这方面的计划。如果你好奇，就 google。
迭代确实从某个现有的先前版本开始。但现在你有很多方法可以带你去罗马。使用和不使用 UML 建模工具，按现状和未来建模都是一项艰巨的任务。您需要确定允许从当前步骤到达下一步的规则集。您可以通过引入版本号 and/or 原型来做到这一点。非常复杂。无论如何，您所描绘的第10阶段没有任何发展，只有增加。你需要找到结构。包是实现结构的一种方式。而且你最终不会得到一个大的 class 图，而是每个子域都有一对。
您在正常设计中所做的是创建处理系统各个部分的子域（例如 I/O、UI、持久性等）。现在您可以为这些子域制作包，您将与它们一起创建 class 图。此外，您还创建了图表来显示包和其中的 classes 如何相互关联。在这里您将使用包和 class 图。请注意，UML 与图表无关。这些图表只是向人们展示整个模型是如何构建的。
Q1
是的，作为蓝图使用。
Q2
你的教授理解正确。
就像一本书上说的，你从有限的范围开始，只有一些 classes。在进一步的迭代中，您可以使用目前创建的内容，并根据需要添加更多 classes、属性和操作，因为系统的复杂性会增加。有时您需要重新考虑并稍微 remodel/redesign（然后获取代码！）您已经创建的内容。这正是敏捷的意义所在。
您可能缺少的是您不需要将整个系统放在一个图表上。使用包来组织您的 classes（并使用包图作为项目内容的一种 table）。将您的单个图表分成更小的块，重点关注围绕特定主题的元素（这些将或多或少地反映您的包）。仅在其 "main" 图（显示包含此 class 的包的图）上显示 class 的所有详细信息，而在其他图上只显示 class 矩形和 class 名称以及特定关系所需的最终属性和操作（如果您的建模工具支持的话）。
由于您通常会按特定区域构建范围，因此您会发现您主要是在创建新包，而现有包只会有很小的变化（除了像 Tools 这样的包。那么您你会知道你走的路是对的。