UML领域模型和上下文图之间的区别是什么

首先，我对UML还是相当陌生的；但是，我对此非常感兴趣，并试图尽可能多地了解它

话虽如此，我的处境是，我被指示组装一个“上下文图”。我感觉好像我理解了什么是上下文图以及如何创建上下文图的概念，所以我认为我在这方面还可以。基本上，它是识别系统及其将与之交互的组件或参与者。它将焦点应用于系统，而不是参与者。有点像用例图，但不关注参与者。如果我错了，请告诉我

我在某个地方读到，上下文图实际上不是UML的一部分。我还从某个地方读到，如果你使用一个上下文图，它就属于事物的组件方面。当我读到关于领域模型的文章时，它似乎应该在那里

就我目前的情况而言，我知道一个简单的答案就是创建图表并继续前进，因为这就是所需的全部。但是，为了更好地理解和利用UML，我知道有正确的方法和错误的方法。如果我在一个更大的项目中，正确的方法是什么

---

现在我的问题从这里开始。我正在使用企业架构师，创建我的项目，并开始创建模型。它属于域模型还是组件模型？这两者有什么区别？甚至更多。因为它是帮助确定需求的助手，它应该去那里吗？还是仅仅取决于我想表达什么和如何表达

正如您所说，上下文图本身并不是UML规范的一部分。有很多方法可以制作上下文图，但UML的方法是使用用例图，无论是否支持叙述和场景。首先，它是对不同类型的上下文关系图的一个广泛概述。然后，调查用例图、用例叙述和活动图。如果您需要深入到比用例叙述更详细的地方，那么进入用例场景和序列图。是一个很好的用例叙事模板（如果超出了需要，就可以随意删除诸如“范围和级别”这样的章节，并考虑添加关于触发用例的信息，以及当你完成的时候你去哪里的信息——如果你走得那么远，这两个场景都是必需的）。 请记住，用例叙述和用例场景经常混淆。（有些人会说我是困惑的人；我会请你自己来判断这件事。）叙述是对整个（单个）用例的解释，可以用活动图来支持。场景是通过单个用例对单个路径的解释，并且可以由序列图支持

例如，一个用例通常有一个基本的事件流，以及一些备用流。叙述描述了整个过程。基本流和每个备用流都是一个单独的用例场景

我怀疑您不太可能必须深入到用例场景的级别。您可能希望将用例图放在一起，并可能为图中的每个用例准备叙述和活动图

您可以通过组合任何元素来创建上下文关系图。然后将元素本身作为链接（而不是实例！）拖到该图上，并通过使边框稍微加厚来高亮显示它。最后从上下文菜单中插入相关元素（不同版本的EA不同）。布局图，现在您的元素就在上下文中了

---

域模型通常是一个类图，在更高的抽象级别上显示（业务）域。

域模型是一个标准化词汇表的地方，项目中的每个人都将使用该词汇表以一致的方式进行交流。开发团队是软件开发方面的专家，但他们可能在被要求工作的领域（如银行、空中交通管制、医疗保健）没有任何经验。因此，您可以让领域专家和建模专家一起构建一个描述该领域的模型，回答一些重要问题，如“如何计算帐户费用？”和“飞行员如何知道应该遵循什么路线？”然后这个模型被传递给开发团队，为他们提供他们需要的重要领域知识。我将使用UML类图来创建一个领域模型

---

上下文关系图显示了与外部系统相关的正在建模的系统。它可以显示从外部系统进出的数据，由数据流图（不是UML的一部分）建模。它可以显示系统和外部“参与者”之间的行为交互，由UML用例图建模。它可以显示系统与其他系统的物理连接，由SysML框图建模。无论您选择哪一个，它都会出现在您的设计文档的第1页上，所以请明智地选择

虽然我很欣赏你的努力，但我对绘画方面很满意。它理解了一些领域如何按照它们的名称，以及它们如何与目标和它们各自的图表相关联。这幅画很容易画。这似乎是所有各种模型、图表和文档之间的相互连接，以及它们应该如何组织和绑定在一起，这是我与mostWell斗争的问题，那么这可能不是StackOverflow需要问的问题。总之：上下文图关注单个元素，并显示它们与其他元素的关系。这是一个单一的图表。相反，域模型是（它所说的）一个模型，也是一组图。在域模型中，您将相关域抽象为表示域对象的多个类。域模型有助于理解整体。上下文关系图有助于理解单个元素。/OT@ThomasKilian我已经告诉过你，你很快就会获得成功