首先，我还是UML的新手;但是，我非常感兴趣，并试图尽可能多地学习它。
话虽如此，我的情况是我被指示组装一个'Context Diagram'。我觉得好像我理解了上下文图是什么以及如何创建上下文的概念，所以我觉得我很好。基本上它是识别系统以及它将与之交互的组件或参与者。它将重点放在系统上，而不是演员身上。有点像用例图，但不关注演员。如果我错了，请告诉我。
我在某处读到了Context Diagrams实际上并不是UML的一部分。我还在某处读到，如果你使用了Context Diagram，那么它就属于Component的一部分。当我读到关于域模型时，它似乎应该存在。
对于我目前的情况，我知道一个简单的答案就是简单地创建图表并继续前进，因为这就是所需要的。但是，为了更好地理解和利用UML，我知道有正确的方法和错误的方法。如果我是一个更大的项目，那么正确的方法是什么？
现在我的问题就在这里。我正在使用Enterprise Architect，创建我的项目，并开始创建模型。它属于域模型还是组件模型？这两者有什么区别？甚至更多。因为它是帮助识别需求的助手，它应该去那里吗？或者仅仅依赖于我想传达的内容和方式？
答案 0 :(得分：3)
您可以通过使任何元素合成来创建上下文关系图。然后将元素本身拖动到该图上作为链接（而不是实例！）并通过使边框稍厚来突出显示它。最后从上下文菜单中插入相关元素（不同于EA版本到版本）。布置图表，现在您可以在上下文中使用元素。
域模型通常是一个类图，显示更高抽象级别的（业务）域。
答案 1 :(得分：3)
域模型是标准化项目中每个人将用于以一致方式进行通信的词汇表的地方。开发团队是软件开发方面的专家，但他们可能没有任何领域（例如银行，空中交通管制，医疗保健）的经验。因此，您将领域专家和建模专家聚集在一起，构建一个描述域的模型，回答重要问题，如“如何计算帐户费用？”以及“飞行员如何知道要遵循的路线？”然后将此模型传递给开发团队，为他们提供他们需要的重要领域知识。我会使用UML类图来创建域模型。
上下文关系图显示了与外部系统建立关系的系统。它可以显示从外部系统流入和流出的数据，由数据流图（不是UML的一部分）建模。它可以显示系统与外部“参与者”之间的行为交互，以UML用例图为模型。它可以显示系统与其他系统的物理连接，由SysML框图建模。无论您选择哪个，它都将在您的设计文档的第1页上，因此请明智地选择！
答案 2 :(得分：2)
正如您所说，Context Diagrams 本身不是UML规范的一部分。有很多方法可以做上下文关系图，但UML方法是使用用例图，有或没有支持叙述和场景。从this开始，这是对不同类型的上下文图的广泛概述。然后，研究用例图，用例叙述和活动图。如果您需要更详细地了解叙述可以轻松完成的用例，请参阅用例场景和序列图。 Here是一个非常好的用例叙述模板（如果它们超出您的需要，可以随意省略诸如“范围和级别”之类的部分，并考虑添加有关触发用例的内容以及何时触发的信息你完成它 - 如果你去那么远，这两个是场景所必需的。）
请记住，用例叙述和用例场景经常被混淆。 （有些人会说我很困惑;我会邀请你自己判断这个问题。）叙述是对整个（单个）用例的解释，并且可以用活动图表来支持。场景是通过单个用例的单个路径的解释，并且可以用序列图支持。
例如，一个用例通常会有一个基本的事件流，以及一些备用流。叙述描述了整个过程。基本流程和每个备用流程都是一个单独的用例场景。
我怀疑您不太可能必须达到用例场景的水平。您可能希望将用例图放在一起，并可能为图中的每个用例准备叙述和活动图。
