让我们以社会团体系统为例;
用例:
(删除帖子)
/
主持人---(Report Post)
⬆⬆<<<<<<<<
管理员-(管理角色)
管理员可以更改主持人的帖子,例如管理员可以禁用某些主持人的报告帖子。
问题是 :如何针对这种情况模拟用例图?
答案 0 :(得分:0)
答案 1 :(得分:0)
一个actor可以更改另一个用户的角色(从而使该用户属于另一类演员)这一事实对use case diagram毫无影响。
为什么?因为用例参与者是classifier。因此,它并不代表用户的出现(即,角色可能发生变化的具体用户),而是代表具有给定角色的一类用户。
要知道的很重要,用例并不代表工作流程。用例表示用户可能具有的目标。 include
和extend
关系表示目标和同一用户的关系,而不是行为之间的关系。因此,如果用户属于另一个演员类,那么他/她就拥有不同的目标,而旧目标就不再重要。
如果您打算代表workflows,则应考虑使用activity diagrams(或非UML BPMN diagrams)。在这些图中,如果用户角色的更改可能影响工作流程,则您需要预见操作的过程。