您将如何在 UML 中对以下情况进行建模:
服务员使用餐厅管理系统来跟踪餐桌上的服务。它还用于跟踪哪些服务员为哪些桌子服务。
这意味着服务员的概念既是参与者(因为服务员是系统的用户)又是实体对象(因为系统会跟踪哪个服务员服务于哪些表)。
然而,根据 UML,一个概念不能既是实体又是参与者,因为根据定义,“参与者是与系统交互的外部实体”。
我总是可以使用不同的名称来区分这些概念,但这似乎是人为的。
你怎么看?
您将如何在 UML 中对以下情况进行建模:
服务员使用餐厅管理系统来跟踪餐桌上的服务。它还用于跟踪哪些服务员为哪些桌子服务。
这意味着服务员的概念既是参与者(因为服务员是系统的用户)又是实体对象(因为系统会跟踪哪个服务员服务于哪些表)。
然而,根据 UML,一个概念不能既是实体又是参与者,因为根据定义,“参与者是与系统交互的外部实体”。
我总是可以使用不同的名称来区分这些概念,但这似乎是人为的。
你怎么看?
代表服务员的系统实体与实际服务员不同,后者是作用于系统的外部代理。
要么使用不同的名称,要么将参与者和实体放在不同的命名空间或模型中。
仅仅因为服务员使用该系统并不会强迫您将该演员命名为“服务员”。想想其他可能以同样方式使用该系统的员工,例如主持人/女主人或轮班经理。
使用该系统的演员通常履行可以在不同演员之间共享的角色。你必须概括演员所扮演的角色。如果任何员工可以参与该用例,则角色可能是“员工”。
即使您没有采用这种方法,您仍然可以使用其他同义词来区分实体和参与者。演员可能是“服务员”,实体可能是“服务员”。值得花时间想出好名字,尤其是常用术语。如果归根结底,请忘记 UML 关于使用不同名称的“说法”。自从UML问世以来,人们就一直在使用它,如果你决定重用一个名字,没有人会让你失望。
我想说的是 UML 试图给你一些好的建议,如果你使用相同的名字,它会在以后引起问题,也表明故事还有更多。