0

请原谅标题，正确解释我需要帮助的内容有点困难，但我会试一试。

我正在开发一个 Java 项目，一个订单管理应用程序。我有几个类用于应用程序中不同类型的功能，例如 Order 类、Client 类、Task 类等。这些任务中的每一个都有与它们所做的事情相关的方法，例如 Order 类有一种称为的方法newOrder()-您明白了。

现在发生了变化，我需要向应用程序添加一些新内容：应该有三种不同类型的帐户可以访问应用程序：管理员、项目经理或开发人员。这些帐户中的每一个都将对应用程序的功能具有不同类型的访问权限。管理员和项目经理将拥有相似级别的访问权限，但开发人员只能访问由管理员授予访问权限的项目（订单）。

我正处于为此绘制UML图的阶段，我真的很挣扎我应该如何可视化它。我的第一个想法是创建一个 User 类和三个子类（Admin、Project Manager 和 Developer），它们都扩展到 User 类。这三个类中的每一个都将包含允许它们执行的方法，例如，Admin 和 Project Manager 类将具有该方法newOrder()，但 Developer 类将没有该方法。

我敢肯定，您可以说我对此很陌生，但是非常感谢您在这一点上给我的任何帮助！

4

2 回答 2

1

首先，让我们摆脱一个歧义：OOP 语言通常所说的访问级别、访问修饰符、访问说明符在 UML 中称为可见性。它在类成员的左侧显示了一个额外的字符：+用于公共、#用于受保护、-用于私有和~用于包。

但是很明显，您对 OOP 意义上的访问级别不感兴趣，而是对应用程序中的授权和访问控制感兴趣。并且没有通用的 UML 解决方案。这完全取决于您的要求和您的设计：

  • 你可能确实有不同的特化一个更通用的User并在编译时定义什么子类可以做什么操作。你的方法将是一个好的开始。不幸的是，同一个用户不能同时拥有多种类型的访问权限。
  • 或者，您可以只有一个 class ，User 也可以有一个 class Role，并且每个都User可以有一个或多个角色。这使用组合而不是继承，并且更灵活。
  • 或者，每个业务实体，例如Order可能影响到一个AccessControlGroup（例如，用户部门？附属代码？或只是一个访问代码？）：Role将与一个或多个相关AccessControlGroup。
  • 或者，如果您想将例如数据组与操作组结合起来，您甚至可能需要更复杂的访问控制组，以更好地控制谁可以对哪些数据执行什么操作。

如您所见，不同的要求可能需要非常不同的设计。

最后，有一个问题：在哪里放置newOrder()：

  • 它在Order课堂上吗？然后该方法可以User作为参数，以动态检查用户是否被授权。
  • 在User课堂上吗？但是不同类别的具有相同权限的用户是否应该执行相同的newOrder()方法？
  • 它是代表业务交易还是用例的类？
  • ...

如您所见，有很多解决方案。这不仅是需求，还涉及架构选择、类职责和关注点分离。如果您想进一步挖掘，则针对这些主题编写了整本书。

结论： UML 不会告诉您您的解决方案应该是什么样子：您需要做出选择，然后您将在 UML 中显示您的决定:-)

于 2020-09-23T21:23:05.847 回答
-1

这是 OOP 思想的基础。您已经确定了所需的对象以及确定属性和操作的边缘。您需要从不同的来源获得正确的需求，然后确定开发人员、PM 和管理对象（Actor）的可能操作。当然，现在可以将一组常用操作移至用户（父级）。

我觉得，你的想法正朝着正确的方向发展，只需要更清楚地了解需求，以确定正确的动作集，这些动作将变成一系列方法。

进行 UML 设计的步骤可能是...

  1. 识别用例/流程
  2. 识别物体（你已经做过）
  3. 识别每个对象的可能操作
  4. 识别对象的可能属性以保持对象的状态
  5. 提出序列图来显示用例中对象之间的交互

请注意，从简单和最少的细节开始，然后从那里发展。你已经走在正确的轨道上了。

于 2020-09-23T10:40:23.557 回答