为入口系统创建UML类图吗？

Question

我正在看登山健身房的入口系统。客户进入大楼，向接待员提供他们的详细信息，接待员将详细信息输入到数据库中，验证详细信息，如果客户不是会员并且客户进入内部接待员就会收到付款。

我有四个类：客户，接待员，管理员，数据库。 我有非会员和会员概括在客户之下。 客户与接待员之间存在多对一的关系（许多客户端）。接待员和数据库之间是一对一的关系。接待员和管理员之间一对一的关系。

是我的类和关系是否正确？

Answer 1

这不容易回答。你谈论类，所以我假设你正在创建一个类图。如果是这样，我不确定我会包括一个接待员班（至少不包括那个用例）。接待员可能存在于数据流图中。在班级图中，接待员班可以存在于职员轮班或员工支付过程中。从编程的角度来看，在入门系统中，您的客户课程如何与接待员课互动？接待员类为这种交互包含什么方法？我假设没有，真正的人类接待员会与真实生活中的顾客互动，但除非您记录接待员处理交易，否则客户类别不会与接待员班级互动。

即使在这种情况下，我会认为这将是另一类管理该行为。

如果你只是映射真实人类之间的相互作用，那么我建议，许多客户可以由许多个人接待员服务。我假设他们聘用多个。

Answer 2

因此，这里是我的意见：

• 所有属性/操作应使用小写字母开头（和你做的所有类以大写字母）。这是我知道的所有语言列表中通用的惯例（绝对不是完整的，但它不止一个或两个）
• 您使用与Member和Non-Member共享作文。它看起来应该是一个泛化关系。所以你需要使用和未填充的三角形而不是钻石。
• 您应该对关联使用角色名称。那就是你应该注意到administrator对Administrator类。这将使其在Receptionist内administrator类型Administrator的属性。
• 您不应在草稿/业务模型中定义ID属性。通常在稍后从对象地址编译时导出ID。所以你引用对象本身，而不是一个ID。
• Receptionist和Database之间有一个关系。我不认为这是一个明智的设计决定。目前还不清楚该数据库将用于什么。可能每个类和任何类都会以某种方式映射到数据库中。所以相反，这些类应该实现一个Serializable接口，它允许在数据库中镜像它们。将Database作为商业模型中的类别是不正确的。只需专注于业务对象并在稍后阶段实施持久层。
• 从你的描述看，我没有看到Administrator进来。每个接待员有一个管理员似乎很偏执。