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

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

我们来看看：一个用户可以有很多配置文件，每个配置文件都绑定到一个且只有一个应用程序。配置文件定义了应用程序中的用户权限：同一用户可以是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; }
}

公共类用户
{
公共字符串用户标识{get；set；}
//仅存储应用程序的AppId，但它可以是IDictionary
公共IDictionary配置文件{get；set；}
}
公共枚举用户配置文件
{
BasicUser，
管理员
}
公共类应用程序
{
公共字符串AppId{get；set；}
}

正如您所看到的，

UserProfile

只是一个枚举，而

Application

可以是一个简单的字符串，但我需要一个类

---

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

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

您绘制的草图如下所示：

应用程序

与任何东西都没有关联，因此它是孤立的

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

字典！ 起初我的想法是，除了：

• 有一个with

  UserProfiles

  ：它是通过一个

  IDictionary

  实现的，其中一个

  字符串

  用于限定

  用户

• 这种关联在一个方向上是可导航的，因为从

  用户

  到

  用户配置文件

  都很容易，但从另一个方向进行则要困难得多（你可以，但你必须迭代所有的用法）

因此，该图可以如下所示：

关于此图表的一些附加说明：

• C#properties没有UML标准，它是UML属性和UML操作（通过隐式getter和setter）的混合体。通常的做法是使用UML概要文件来定义原型

  «属性»

  。我自己的首选选项是将其保留在类的属性中（如or），因为这是C#属性的语义。然而，一些人认为这个原型应该被视为UML操作的一种专门化（就像qwerty的答案中的和），这也是一个有效的论点，特别是当您定义自定义getter和setter时
• 注意限定关联中的多重性，因为它适用于使用字符串限定的

  用户

  。因此，0..1 UserProfile用于用户和字符串的一个特定组合。所以在现实中0…*如果我们考虑不合格的<代码>用户< /代码>。<李>

模型转换 我们必须记住，给定的实现可能对应不同的设计。实现是你如何编写代码，设计是你如何看待事物

因此，我们可以将第一个反向工程模型转换为与您的思维模型相匹配的模型。只有您可以告诉我们，您希望如何看到导致您实现当前实现的东西

例如，您可能对导航性不太感兴趣，您可以将重点放在非合格的

用户

和

用户配置文件

之间的多对多关联上。使用此方法，用作限定符的字符串将成为的属性：

不过，请注意，这是一种转变。合格的关联和一对多不是一回事，两个模型的意思并不完全相同

n元联想来了！ 现在关键问题是这个关联类中string属性的用途。我强烈怀疑它实际上是您的

应用程序的
id
（我让您在评论中确认）

如果是这种情况，我们将在关联类和
应用程序之间建立关联。我们可以从association类中删除string属性，因为它是冗余的

但是一个本身与其他类相关联的关联类表明，实际上存在一个（这里是三元的）。因此，我们可以明确这一点：


现在您有了一个n元关联。如果每个三元组（User、Application、UserProfile）都有其他属性要关联，那么您甚至可以在其后面有一个关联类

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

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

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

然而，如果三元关联是您对世界的看法，那么您可能迟早要检查当前的实现。可能您会提取这些概要文件来创建自己的类
 C#property
User:：Profiles
实现了
User
和
Application
之间的多对多关联类，该类具有类似
role:RoleEL
的UML属性，其中我将枚举名“UserProfile”替换为“RoleEL”，以便更好地使用