我正在创建一个用例图,系统与自身交互。例如,它是一个患者监测系统,它读取信息并将其提供给站监测器。
将用例主要演员设为“系统”是否过于模糊或过于宽泛?我应该详细说明并指定系统的哪个部分是该演员。
用例图旨在显示主题如何带来与其actor相关的有用功能。每个用例都意味着对系统的参与者或其他利益相关者有一定的价值。 根据UML 2.5规范:
每个UseCase指定主题可以与一个或多个Actors协作执行的某些行为。 UseCases定义主题的提供行为,而不参考其内部结构。
Actor模拟由与其关联的UseCases的主题交互的实体所扮演的角色类型(例如,通过交换信号和数据)。演员可以代表人类用户,外部硬件或其他系统所扮演的角色。
所以原则上,系统本身并不是自己的演员。 actor应该对应于独立于系统表达的角色。请注意,我的措辞并不排除系统本身履行此角色。
因此,标记演员'系统'是一个非常糟糕的主意。 actor应该对应于独立于系统表达的角色。你可以想象一个演员:Supervision system
(可能是另一个系统,或系统本身):
另一种可能性是深入细节:
用例的主题可以是系统或可能具有行为的任何其他元素,例如组件或类。
所以你可以从一个子系统的角度来展示用例,例如有一个主题Measurement Subsystem
和一个演员Monitoring Subsystem
:
内省的用例可能是错误的图表选择的症状。
您可能不太关心系统如何为其用户的目标及其与外部环境的关系做出贡献,但更多的是在其内部。在这种情况下,检查activity,sequence或communication图表是否不能更好地满足您的需求。
将System作为演员完全没问题。看到类似的问题:
如果你想用用例编写更详细的规范 - 你必须更深入地在海底/功能级别编写第二组附加用例。当然,这意味着您必须引入新的演员将系统分解为单个组件。