【发布时间】:2019-04-06 23:45:25
【问题描述】:
我正在创建一个用例图并且系统与自身交互。例如,它是一个病人监护系统,它读取信息并将其提供给工作站监护仪。
将用例的主要参与者设为“系统”会不会太模糊或太宽泛?我是否应该详细说明并指定系统的哪个部分是那个演员。
【问题讨论】:
标签: uml specifications use-case
我正在创建一个用例图并且系统与自身交互。例如,它是一个病人监护系统,它读取信息并将其提供给工作站监护仪。
将用例的主要参与者设为“系统”会不会太模糊或太宽泛?我是否应该详细说明并指定系统的哪个部分是那个演员。
【问题讨论】:
标签: uml specifications use-case
用例图旨在展示一个主题如何为其参与者带来有用的功能.每个用例都意味着对系统的参与者或其他利益相关者具有一定的价值。
根据 UML 2.5 规范:
每个用例都指定了主体可以执行的一些行为 与一名或多名演员合作。用例定义了提供的 对象的行为不参考其内部结构。
Actor 模拟了一个实体所扮演的角色类型,该实体与 其相关用例的主题(例如,通过交换信号 和数据)。演员可能代表人类用户扮演的角色,外部 硬件或其他系统。
所以原则上,系统本身并不意味着它自己的参与者。参与者应该对应于独立于系统表达的角色。请注意,我的措辞并不排除系统本身就可以完成这个角色。
因此将参与者标记为“系统”是一个非常糟糕的主意。参与者应该对应于独立于系统表达的角色。例如,您可以想到一个演员:Supervision system(可能是另一个系统,或系统本身):
另一种可能是深入细节:
UseCase 的主题可以是系统或任何其他元素 具有行为,例如组件或类。
因此,您可以从子系统的角度展示用例,例如有一个主题 Measurement Subsystem 和一个演员 Monitoring Subsystem:
内省用例可能是图表选择错误的征兆。
您可能对系统如何为其用户的目标做出贡献以及它如何与外部环境相关联不太感兴趣,但更关注其内部。在这种情况下,请检查 activity、sequence 或 communication 图表是否能更好地满足您的需求。
【讨论】:
让 System 成为演员是非常好的。查看类似问题:
如果您想用用例编写更详细的规范 - 您必须更深入并在海底/功能级别编写第二组额外的用例。当然,这意味着您必须引入新的参与者,将系统分解为单独的组件。
【讨论】: