4

在设计域模型和类图时，我在理解要放入其中的内容时遇到了一些麻烦。

我将举例说明我的意思：

我正在做一个假期调度程序，它有一个Administrator和End-Users。他们Administrator做了一些事情，比如End-Users在程序中注册、更改他们的特权等。他们End-User可以选择他的假期等。

我最初在领域模型中将Administratorand定义End-User为概念，后来在类图中定义为类。在类图中，两个类最终都有几个方法，比如

Administrator.RegisterNewUser();
Administrator.UnregisterUser(int id);

等等

过了一段时间，我才意识到实际上两者Administrator都是End-User演员，也许我完全错误地设计了这个设计。我可以从域中定义其他类来执行它们，并让控制器处理用例，而不是用方法填充管理员和最终用户类来执行我的用例请求（实际上，我决定为每个用例）。例如，我可以有一个UserDatabase.RegisterNewUser()and UserDatabase.UnregisterUser(int id);，而不是在Administrator类上使用这些方法。

这个想法是尝试将整个假期调度程序视为一个“封闭程序”，它具有一组功能并且不打扰诸如身份验证之类的事情，应该是内部/受保护的，是唯一的公共我让外界看到的东西就是它的控制器。

这是正确的方法吗？还是我完全错了？将 Actors 放在域模型/类图中通常是个坏主意吗？对此有什么好的经验法则？

我的讲师正在关注Applying UML and Patterns，我觉得这很糟糕，所以我想知道在哪里可以查找有关所描述的演员模型情况的更多信息。

我对这一切仍然有些困惑，因为这种新方法与我以前做过的任何事情都完全不同。

4

2 回答 2

4

正如您所推测的那样，我不会说您的设计是完全错误的，实际上管理员和最终用户是应该在类图中以某种方式表示的有效域对象。仅仅因为您将这两个实体标识为参与者并不意味着它们应该被排除在域之外，请记住，您的域是您的范围或“相关上下文”，即在您的领域中扮演相关角色的有用对象的集合解决方案。

您可以从构成模型的基本对象开始，只需将它们写下来，无需进一步分析，例如头脑风暴……

  • 假期
  • 地点
  • 旅行社
  • 日程
  • 用户
  • 预订
  • 预订服务（这可以是访问假期预订资料的接口）

然后尝试建立这些对象之间的关系，如果您找不到任何关系，这意味着您没有选择正确的对象，如果它们是同一问题域的一部分，那么它们必须以某种方式相关。

一段时间后，您会发现缺少对象，尝试尽可能多地封装并表示正确的抽象，设计模式可能会帮助您解决这个问题。

当每个可能的对象都用它的所有属性和方法来表示时，那么你应该有一个完整的（虽然还没有完成）功能设计。

我知道你脑子里应该有很多理论，所以开始吧，不要害怕，我自己在工作中已经成功地使用了很多次这种方法。

最后得到一份UML Distilled

问候，

于 2010-06-05T03:02:24.563 回答
2

我认为您应该更多地了解领域建模和从用例到类图的过程。作为分类器的参与者可以是类图的一部分，但是对于用于分析和设计的类图来说，是对您开发的系统进行建模，并且参与者是外部实体。当您使用用例和用例图时，目标是识别功能性和非功能性需求，因此定义要开发的系统范围以及与您正在开发的系统交互的外部实体（角色或系统）。在用例图中，您有时会发现一个表示系统边界的框，它包含所有用例，这些用例将在您的系统中实现，但参与者是开箱即用的。在进行域建模时，您通常会完全忘记系统，因为您想捕捉域的工作方式。通常特殊的图表和建模元素用于领域建模。正如我所说，关键是要了解系统将在其中使用的领域。分析和设计阶段的类图描述了您正在开发的系统，因此没有参与者可以在里面。

于 2010-06-05T10:57:55.580 回答