逆向工程：C# 字典的表示？

Question

我已经编写了我的代码，但就我个人而言，我想知道如何对其进行建模。

我们开始吧：一个用户可以拥有多个配置文件，每个配置文件都与一个且唯一的应用程序相关联。配置文件定义了应用程序内的用户权限：同一用户可以是 app1 范围内的管理员，同时是 app2 的基本用户...

伪代码如下：

public class User
{
   public string UserId { get; set; }

   // Only store the AppId of application but it could be an IDictionary<Application, UserProfile>
   public IDictionary<string, UserProfile> Profiles { get; set; }
}

public enum UserProfile 
{
   BasicUser,
   Administrator,
}

public class Application
{
   public string AppId { get; set; }
}

如您所见，UserProfile 只是一个枚举，而 Application 可能是一个简单的字符串，但我需要一个类。

如何在类图中表示这 3 个实体？我认为类关联不是一个好的选择，因为它没有任何属性。但我不知道还有什么可能。

Answer 1

我在您的代码中没有看到任何 n 元关联。

你的草图是这样的：

Application 与任何东西都没有关联，因此它是一个孤儿。

属性可以用不同的方式表示，并且是特定于语言的。以上将用于 C#

Answer 2

字典很重要！

一开始我的想法是qwerty_so，除了：

• 有一个qualified association 和UserProfiles：它通过IDictionary 实现，其中string 用于限定User。
• 此关联可在一个方向导航，因为您可以轻松地从 User 转到 UserProfile，但要反过来则要困难得多（可以，但您必须遍历所有用途)。

所以图表可能如下所示：

关于此图的一些补充说明：

• 对于 C# 属性没有 UML 标准，它是 UML 属性和 UML 操作的混合体（通过隐式 getter 和 setter）。通常的做法是使用定义原型«property» 的UML 配置文件。我自己的首选选项是将其保留在类的属性中（例如 here 或 here），因为这是 C# 属性的语义。然而，有些人认为这种刻板印象应该被视为 UML 操作的特化（如here 和 qwerty 的答案），这也是一个有效的论点，尤其是在您定义自定义 getter 和 setter 时。
• 注意限定关联中的多重性，因为它适用于使用字符串限定的User。所以 0..1 UserProfile 是针对用户和字符串的一种特定组合。所以如果我们考虑不合格的User，它实际上是 0..*。

模型转换

我们必须记住，给定的实现可能对应于不同的设计。实现是你编写代码的方式，设计是你看待事物的方式。

因此，我们可以转换第一个逆向工程模型以匹配您的思维模型。只有您才能说出您希望如何看待导致您实现当前实施的事物。

例如，您可能对可导航性不那么感兴趣，您可以将重点放在不合格的User 和UserProfile 之间的多对多关联上。使用这种方法，用作限定符的字符串将成为association class 的属性：

但请注意，这是一种转变。合格的关联和一对多不是一回事，这两个模型并不意味着完全一样的东西。

n-ary 关联来了！

现在的关键问题是这个关联类中字符串属性的用途。我强烈怀疑它实际上是您的Application 的id（我让您在 cmets 中确认）。

如果是这样，我们将在关联类和Application 之间建立关联。我们可以从关联类中删除字符串属性，因为它会是多余的。

但一个关联类本身与某个其他类相关联，表明实际上存在一个n-ary associaton（此处为三元）。所以，我们可以明确表示：

现在你有了一个 n 元关联。如果每个三元组（用户、应用程序、用户配置文件）有额外的属性关联，你甚至可以在它后面有一个关联类。

但请注意，此图不太精确。例如，在 n 元关联中指示可导航性约束更加困难。而且它不再完全对应于您的实现：此模型表明您可以从应用程序开始找到用户，而在您的实现中则更加困难。

结论/建议

就个人而言，我发现 n 元关联很难使用，我更喜欢将它们分解为一组类和二元关联（必要时还包括关联类）：这可以消除很多歧义并提供更严格的控制。我只能向您推荐相同的方法。

还要考虑您的实现：如果该实现代表您对世界的看法，则使用限定关联，因为它是 UML 等价于字典。

但是，如果三元关联是您的世界观，您可能迟早必须审查当前的实施。可能您会提取配置文件以创建自己的类。

Answer 3

您的 C# 属性 User::Profiles 实现了 User 和 Application 之间的多对多关联类，该类具有像 role: RoleEL 这样的 UML 属性，其中我已将您的枚举名称“UserProfile”替换为“RoleEL”更好的可读性（注意“EL”代表“枚举文字”）。这显示在下面的类图中：

我认为这种设计模型比@qwerty_so 和@Christophe 建议的模型更简单、更自然。

请注意，qwerty_so 的模型不是（逻辑）设计模型，而是实现模型，因为它不显示 User 和 Application 之间的关系，而是将其隐藏在代码中profiles 财产。此外，它不必要地复制了 UML 属性（使用令人困惑的原型关键字 «property»）。