Question

有两个类：问题和答案。问题实例包含答案列表，每个答案都指向一个后续问题。因此，每个选定的答案会触发相关的下一个问题，直到选择没有后续问题的答案为止。

UML图表最能描述如下问卷流：

Q1: "Are you hungry?" [Yes, No]
  Yes->Q2: "What do you want to eat?" [Apple, Pear, Banana]
      Apple->Q4: "Green or red?" [Green, Red]
      Pear ->Q5: "Big or small?" [Big, Small]
  No ->Q3: "Are you thirsty?" [Yes, No]
      Yes->Q6: "What would you like to drink?" [Tea, Coffee, Water, Vodka]
          Tea  ->Q7: "Any sugar?" [1 spoon, 2 spoons, 3 spoons]
          Vodka->Q8: "Are you old enough for it?" [Yes, No]

类图将描述类之间的关系，而不是问题 - 答案流。

对象图中有太多关于对象与对象内部结构之间关系的信息，这使得我们很难阅读我们感兴趣的问题/答案流。

如果问题是真或假，活动图会很好用，那么决定菱形图标可用于真假流程。但如果一个问题有7个可能的答案，那就行不通。

所以我的问题是找到一个图表类型，以最基本和最清晰的方式描述这样的流程。

Answer 1

不同的图表用于不同的事物，并提供不同的细节模型。如果要在模型中显示类之间的关系，则使用两个关联的类图

Question 1 <-- answers --> 1..* Answer
Answer 1 <-- follow-up --> 0..1 Question

会很好（我故意不对这些课说什么，因为我不想建议实施）。在某些工具中，例如Enterprise Architect，您可以使用此图表生成源代码。基于你的问题，我认为这就是你想要的。

如果您另一方面想要显示控制流，那么您应该使用behaviour diagrams之一。序列或通信图表显示模型的对象如何相互交互（使用哪些方法）以实现特定的用例。如果您在模型中使用状态，则可以在状态机图上显示它。

Answer 2

您似乎对描述/建模＆＃34;流程的两种可能性感到困惑＆＃34;：

在您描述Q＆amp; A流程类型的类型级别
在对象/实例级别，您可以在其中描述特定的Q＆amp; A流程，例如关于Q1，Q2等的流程。

您可以使用对象/实例级模型来描述示例或设计内容。

但是，对于设计软件应用程序，您需要在类型级别进行建模。但是你的问题的流程模式非常简单，你真的不需要任何行为模型。它从类图中完全不可判（如马雷克阿达梅克的答案所示），其中流程从一个问题循环到一个可能的答案，然后回到这个答案的后续问题（然后到下一次迭代）。

最好的方法来描述这个树，就像UML中的多选题/答案算法一样

2 个答案: