UML领域模型和上下文图有什么区别答案

【问题标题】：What is the difference between UML Domain Model and Context DiagramUML领域模型和上下文图有什么区别
【发布时间】：2014-12-04 17:00:09
【问题描述】：

首先，我对 UML 还是很陌生；但是，非常感兴趣，并且正在尝试尽可能多地了解它。

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

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

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

现在我的问题从这里开始。我正在使用 Enterprise Architect，创建我的项目，然后开始创建模型。它属于领域模型还是组件模型？这两者有什么区别？甚至更多。由于它是帮助确定需求的助手，它应该去那里吗？还是仅仅取决于我想要传达什么以及如何传达它？

【问题讨论】：

上下文图和域图都不是 UML 中定义的术语。如果您使用它们，请说明您使用它们的方法，并可能添加定义。

标签： uml enterprise-architect

【解决方案1】：

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

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

【讨论】：

这有助于理解它们在何处、为什么以及如何应用。您对域模型的解释非常有帮助。我对 Domain 有相当高的理解；然而，这个描述填补了许多空白。我很感激。

【解决方案2】：

您（可以）通过组合任何元素来创建上下文图。然后将元素本身作为链接（而不是实例！）拖到该图表上，并通过使边框变粗一点来突出显示它。最后从上下文菜单中插入相关元素（因 EA 版本而异）。布局图表，现在您在上下文中拥有了您的元素。

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

【讨论】：

虽然我很欣赏这种努力，但我对绘图方面感到满意。它了解一些领域，根据它们的名称，以及它们如何与目标及其各自的图表相关联。绘图很容易。这似乎是所有各种模型、图表和文档之间的相互连接，以及它们应该如何组织和捆绑在一起，这是我最苦恼的
好吧，那么这可能不是 StackOverflow 上要问的问题。无论如何：上下文图侧重于单个元素并显示它们与其他元素的关系。这是一个单一的图表。相比之下，域模型是（它所说的）模型 - 也是一组图表。在域模型中，您将所讨论的域抽象为表示域对象的多个类。领域模型有助于理解整体。上下文图有助于理解单个元素。
/OT @ThomasKilian 我一直在告诉你，你很快就会在这里获得声望。我承诺太多了吗？希望你喜欢它，cya！
是的。这真的很有趣:-) TY

【解决方案3】：

正如您所说，上下文图本身不是 UML 规范的一部分。有很多方法可以制作上下文图，但 UML 方法是使用用例图，有或没有支持叙述和场景。从this 开始，这是对不同类型上下文图的广泛概述。然后，研究用例图、用例叙述和活动图。如果您需要比用例叙述更容易做到的细节，请进入用例场景和序列图。 Here 是一个很好的用例叙述模板（如果“范围和级别”之类的部分超出您的需要，请随时省略，并考虑添加有关触发用例的内容以及完成后去向的信息它——如果你走那么远，这两个是场景所必需的）。

请记住，用例叙述和用例场景经常混淆。（有人会说我是糊涂的，我请你自己判断。）叙述是对整个（单个）用例的解释，可以用活动图来支持。场景是通过单个用例的单个路径的解释，并且可以通过序列图来支持。

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

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

【讨论】：

阅读您的回复后，我感觉到一种建议的语气是追求用例，而不是上下文。我认为我同意上下文图不是 UML 的一部分，当我仍处于尝试学习它的婴儿期时，我该偏离谁。话虽如此，我对此别无选择，因为正如我之前所说，我被指示生成一个“上下文图”。我被困在这里了。所以我会尽力而为，尽我所能学习。
续。除此之外，我尊重你提供的东西。我从你给我的东西中学到的东西比我在过去 2 到 3 年的零散努力中学到的东西要多。你的层次分解比我迄今为止发现的任何东西都能帮助我更好地理解。我在任何地方都找不到。我发现这里有一个图表，它的用途，如何制作，等等。 1张图没有删减。我找不到他们应该如何为大局联系在一起的细分。你可能没有让我成为 UML 专家，但你肯定改进了我的工具箱，以扩展用例并使它们更有用。
如果你被指示创建一个上下文图，你最好问问这样做的人应该是什么。 UML 中没有定义上下文图。
Lee，转到我提供的第一个链接，并查看上下文图类型列表中的底部项目符号。您会注意到，它将 UML 用例图称为几种类型的上下文图之一。上下文图是映射问题域的图表的广义定义。用例图用于此目的。这实际上只是语义问题。您的“用例而不是上下文”只是对这一点的误解。用例图是上下文图；众多之一。
@BobRodes 非常感谢。这是完全有道理的，而且几乎就是我的接受方式。经过多次搜索和阅读，我收集了非常相似的用例和上下文图。以用户为中心的用例和以系统为中心的上下文。