答案 0 :(得分:2)
您不应该在设计中使用SD。演员不会直接交换消息(好吧,他们以一种或另一种方式交谈或互相攻击)。相反,他们使用系统进行交互(因此系统可以支持交互)。为此,您需要知道系统的附加值是什么。一些枚举点可以直接写为UC。例如。 Approve request
。像Fills request form...
这样的其他人可能是File request
。它不是猜测Saves
的意思(你可能需要考虑它)。因此,将您的演员放在图表中,并将它们与代表附加值的气泡连接起来。正如预防措施:不要尝试开始功能分解。不要使用include / extend。只需为您找到的附加值放置气泡即可。还应该只有一个actor与一个用例相关联。可以连接次要参与者,但是您需要解释如何标记它们(例如,使用<<use>>
刻板关联)。
只有完成了这个UC综合后,才能开始创建与单个actor相对应的类。所以你的SD将从一个演员向一个实例发送消息开始,再做一些消息并最终回到演员。
我建议你谷歌用于Iconix。他们有一个非常巧妙的方法,构建了如何使用UML来设计系统。在任何地方都没有具体设置。但是几乎所有已建立的方法都使用了一些标志性建筑。
答案 1 :(得分:1)
您可以创建一个包含三个用例的用例图:
图表中的三列文本可以作为这些用例的文本形式。
您无法在用例图中指定用例的顺序。您可以将序列图用于此目的和/或您可以使用前置条件和后置条件(例如,Act2 / 3/4的前提条件是Act1的完成)。就个人而言,我更喜欢活动图(参见my white paper,图5)。
或者,如果每个actor都有一个要处理的任务收件箱,您可以在每个用例的末尾添加一个额外的步骤,说明“系统将任务X添加到actor Y的收件箱中。”
答案 2 :(得分:0)
您对图表的困惑是由于缺少实际用例造成的。只需这样做,写下用例(看起来你已经完成了大部分工作来理解这个过程),你将对图表有一个愿景。或者至少是更具体的问题。
请记住,图表仅仅是一种表示,用例 - 这是实际创建的地方。图表来自用例并补充它们。