包含或扩展(UML java)

包含或扩展(UML java),uml,Uml,有人能告诉我是要使用包含依赖项还是扩展依赖项吗 用例A:选择并加载文件 用例B:显示波形 每当用户选择并加载音频文件时,立即显示波形 我认为用例A和用例B应该通过扩展来连接。。。。 我说得对吗? 谢谢我想说包括而不是扩展 原因:从用户的角度来看,目的是显示波形。选择和加载文件是实现这一目的的手段,而不是目的本身。很难看到选择并加载文件,因为它本身并不代表有价值的最终用户功能。只有在多个“真实”UCs中存在一个公共步骤时,它才会作为UC存在 hth.在我看来,这两个用例不一定是独立的。在识别用例时

有人能告诉我是要使用包含依赖项还是扩展依赖项吗

用例A:选择并加载文件

用例B:显示波形

每当用户选择并加载音频文件时,立即显示波形

我认为用例A和用例B应该通过扩展来连接。。。。 我说得对吗?
谢谢

我想说
包括
而不是
扩展

原因:从用户的角度来看,目的是显示波形。选择和加载文件是实现这一目的的手段,而不是目的本身。很难看到
选择并加载文件
,因为它本身并不代表有价值的最终用户功能。只有在多个“真实”UCs中存在一个公共步骤时,它才会作为UC存在


hth.

在我看来,这两个用例不一定是独立的。在识别用例时,试着考虑用户的观点。向用户显示文件可能是打开文件整个过程的一个步骤

如果您只有一种文件类型,并且这种情况经常发生,那么一个用例就足够了。如果用户可以选择和加载不同的文件类型,并且每次发生不同的事情时,最好提取第一部分以避免重复,但这取决于具体情况。在这种情况下,使用extend。(尽管如此,这也可以通过其他流程处理)

有几点:

1-请注意,包含和扩展不是依赖关系,依赖关系是UML中的另一种关系

2-好的用例是那些独立于UI的用例。关注用户想要实现的目标。编写用例时不要做出与UI相关的决策

3-当“A”包括“B”时,每次“A”发生时,“B”都发生。这就像从“A”到“B”的无条件函数调用。所以“B”可能永远是“A”的一部分。我们将“B”分隔为可重用性和模块化

4-一些专业人士建议尽可能避免延长。拥有扩展和包含并不一定意味着专业的UC图。它们可能会降低可读性和清晰度