为入口系统创建UML类图？

Question

我正在看一个攀岩馆的入口系统。客户进入大楼，向接待员提供他们的详细信息，接待员将详细信息输入数据库，验证详细信息，如果客户不是会员且客户进入内部，接待员会付款。

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

我的班级和关系是否正确？

Answer 1

所以这是我的观察：

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

Answer 2

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

即使在那种情况下，我也会认为这将成为管理该行动的另一个类。

如果你只是简单地描绘真实人类之间的互动，那么我建议，许多客户可以由许多个人接待员服务。我认为他们雇用了不止一个。