我有这种情况,我有多个共享相同用例的参与者。
我无法弄清楚我应该从哪个角度编写事件流并描述这个特定用例的序列图,有多个参与者。
我有这种情况,我有多个共享相同用例的参与者。
我无法弄清楚我应该从哪个角度编写事件流并描述这个特定用例的序列图,有多个参与者。
你: 我有多个参与者共享相同的用例。
...从哪个角度我应该写事件流
用例是面向目标的。它们不应该是功能分解或动作序列。不是我,而是用例的发明者 Ivar Jacobson,在用例 2.0中:
用例是使用系统为特定用户实现特定目标的所有方式。
(第 4 页)
因此,用例旨在提供全局。你的用例图应该确定这些独立的目标。当然,在每个用例背后,都有一些描述参与者和用例之间交互的叙述:
用例叙述的目的是讲述系统及其参与者如何协同工作以实现特定目标的故事。(...)
用例叙述可以在不同的细节层次上进行开发,从简单的大纲、识别基本流程和最重要的变体,到全面、高度详细的规范
(第 47 页)
描述此流程的一种方式是Geert Bellekens在评论中的解释:描述场景,告诉谁按什么顺序做什么。此表示的一个变体是表格形式:参与者动作的列和参与者动作的列。
现在,如果您处于设计的初期,特别是如果您有多个演员,这种 UC 描述会迫使您决定设计交互的方式。一个更有创意的变体是描述基本用例:不是描述事件流,而是制作一个表格,更详细地描述参与者的意图(即意图)(在一列或 n 列中)到相应职责的映射系统(在单独的列中)。
然后,您可以开始考虑可能的序列,以及可以提供更好的用户体验或更优化的信息流的替代序列。灵活性是如此之高,以至于您甚至可以设计语音驱动或 NLP 驱动的界面,其中的顺序不是预先确定的,但对于每个用例执行来说可能是不同的。