当前位置：文江博客话题详情

是否有对包含团队、角色和技能的结构进行建模的设计模式？

发布于 2024-07-06 11:33:56 字数 249 浏览 9 评论 0原文

我需要对一个系统进行建模，其中将有一个团队，该团队由在团队中执行角色并分配有技能的用户组成。

即A队5人，其中一人担任队长角色，全部执行回复电子邮件角色，但有些人具有接听电话的额外技能

我正在尝试确定如何最好地对此进行建模。

这个问题之前肯定已经解决了，有没有关于如何建模的好资源？

编辑：我需要确定允许用户执行哪些操作，这可能是因为他们在某个团队中，执行某个角色或已被分配某种技能

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

琴流音 2024-07-13 11:33:56

我用谷歌搜索了这个，所以要持保留态度。我找到了这篇论文关于角色建模和对象。第 30 页有一个角色模式。希望这对你来说不是一场徒劳的追逐。这是摘要

角色模式允许您设计一个可以在运行时使用新组件进行扩展的组件
上下文对象，称为角色。根据上下文使用角色扩展组件
对象模式。 Component对应的是Decorator的Component，Role对应的是
到上下文对象。角色扮演组件的状态集成是通过应用来实现的
财产和战略。属性用于定义组件的状态空间，并且
策略用于提供属性相关行为。

回复收藏 0 原文

兰花执着 2024-07-13 11:33:56

听起来您可以在这里使用复合模式的变体，至少对于部分问题来说是这样。您可以从充当超类的 Unit 开始，然后可以将 Team 作为 Unit 的子类。团队是一个可能包含其他单元的容器。此外，您还可以拥有 User 子类 Unit。因此，您可以编写仅针对单位的代码，并以相同的方式对待所有团队和用户。然后，您可以创建一些由其他团队组成的复杂团队。

因此，您可以为您需要的每种类型的用户或类型的团队提供一个类。

如果角色数量急剧增加并且最终类过多（类爆炸），则可以应用装饰器模式。因此，您可以使用具有相似接口但不同（或附加）功能的另一个对象来包装（装饰）一个对象。

所以你可以有一个BasicUser和AnswerPhoneDecorator。将任何 BasicUser 对象包装在 AnswerPhoneDecorator 中，您就有了一个可以接听电话的用户。

回复收藏 0 原文

过气美图社 2024-07-13 11:33:56

我没有听说过什么，但它很简单，可以通过多种方式解决。

所以有团队、成员、角色和技能。团队只是成员容器，成员有角色和技能。

这里还有一个小伪代码可以让您了解整个想法：

class Team
    container[Member] members

class Member
    container[Role] roles
    container[Skill] skills

然后您可以实例化或子类化角色和技能，具体取决于它们是什么类型以及您的编程语言的功能。

..另一方面，在实践中，使团队类类似于角色和技能类（成员类的属性）可能是有意义的。如果您需要了解某个成员有权访问哪些内容等信息。

Not really anything I've heard from, but it's simple enough to be solved in variety of ways.

So there's Teams, Members, Roles and Skills. Teams are just Member-containers and Member has roles and skills.

Here's yet a small pseudo to give you the whole idea:

class Team
    container[Member] members

class Member
    container[Role] roles
    container[Skill] skills

Then you instantiate or subclass roles and skills, depending about what kind of things they are and the capabilities of your programming language.

..In other hand, In practise it'd may make sense to make a Team -class similar to Role and Skill -class - a property of Member -class. If you need to find out things like what one member has access into.

回复收藏 0 原文

恏ㄋ傷疤忘ㄋ疼 2024-07-13 11:33:56

在您的示例中，我至少有 TeamMember BaseClass 和 2 个接口（iEmail 和 iPhone）。任何新的角色都将从 TeamMember 类继承，并根据它的功能，实现适当的接口...简而言之，角色将被实现为从 TeamMember 继承的类，而技能将被实现为接口。

例如，团队领导可以打电话。然后我会让 TeamLeader 类继承自 TeamMember 并实现 iPhone 接口

RWendi

回复收藏 0 原文

帅冕 2024-07-13 11:33:56

尽管我相信设计模式是一个很棒的工具，但我不认为我会使用任何特定的模式来解决这个问题。相反，我会尝试从不同的角度来处理它。我建议使用一个数据库来存储有关您的团队、团队成员及其角色的数据。现在，数据库并不是我的强项，但我会尝试一下：

创建一个表来容纳所有团队的所有团队成员。该表应具有属性：姓名、角色、团队、技能，分别表示成员的姓名和角色、他/她所属的团队以及他/她的技能。
现在，假设您的应用程序中有以下角色：角色A（可以接听电话和发送电子邮件）、角色B（只能发送电子邮件）和角色TeamLeader（可以接听电话、发送电子邮件）例如，去参加会议。
角色表将保存应用程序中的所有角色，属性为（在本例中）：name（角色名称）、canAnswerPhone（布尔值，表示具有此角色的用户是否可以接听电话）、can send e- mail（布尔值表示他/她是否可以发送电子邮件）等等...
例如，第三个表可以保存应用程序中的所有团队以及有关他们的各种数据（例如团队正在开展的项目等......）。
现在，您可以轻松获取团队中的所有成员，他们可以做什么，更改他们的角色，查看谁是领导者，更改某个角色的职责等等......

我希望这对你有意义。祝您设计应用程序好运！

回复收藏 0 原文

◇流星雨 2024-07-13 11:33:56

这取决于您要建模的内容。根据上面的示例，您是否希望能够找到最适合特定问题的团队成员？

如果是这样的话，那么我会推荐这样的东西：
将角色和技能想象为无向图中的顶点。给定的角色（通过边缘）与其所具备的每项技能相关联（假设技能是按角色赋予的，而不仅仅是基于个人）。现在，将所有团队成员连接到他们在团队中担任的任何角色，并将团队成员连接到适当的团队。

该图现在模拟了您的团队、团队成员、他们的角色以及他们应该具备的角色技能之间的关联。

现在，要将给定问题映射到团队成员（甚至团队），请考虑一个问题并将其与您认为需要的每种不同技能（即电子邮件、数据库、Web UI、Web 服务等）联系起来。现在您也可以将问题与这些实体联系起来。

我不会详细介绍您可以使用它运行的每种类型的报告，但这是一个简单的报告。如果您想找到一个可以解决该问题的人（如果存在），我会推荐像这样的图形遍历：

class Problem
{
  find_problem_solvers()
  {
    var problem_solvers = null
    for each (skill in skills_required)
    {
      var possible_problem_solvers = skill.find_problem_solvers()
      if(problem_solvers == null)
      {
        problem_solvers = new list().add_range(possible_problem_solvers)
      }
      else
      {
        for each problem_solver in problem_solvers:
        {
          if(problem_solver not in possible_problem_solvers)
            problem_solvers.remove(problem_solver)
        }
      }
      //No point continuing if we eliminated everyone!
      if(problem_solvers is empty) break;
     }
     return problem_solvers
   }
 }

正如您在这方面所看到的，我对其他海报的模式没有太多用处。如果您正在尝试对域安全性或某种不同的业务逻辑进行建模。他们的技术很可能是正确的。

顺便说一句，应该指出的是，上述算法并不是最优的。

It depends on what you're modeling. Given your example above do you want to be able to find the team member best suited to a given problem?

If that is the case then I would recommend something like this:
Imagine roles and skills as vertices in an undirected graph. A given role is linked (via an edge) to each skill it is capable of (assuming skills are given by role and aren't just based on individual). Now connect all team members to whatever roles they have on the team and the team members to the appropriate teams.

This graph now models the associations between your teams, team members, their roles, and the skills they should have given their roles.

Now to map a given problem to a team member (or even team) take a problem and connect it to each of the different skills you think it'll need (ie. Email, DB, Web UI, Web Services, etc.). Now you can relate problems to these entities as well.

I won't go over every type of report you could run with this but here's a simple one. If you want to find a single person (if they exist) that can resolve that issue I would recommend a graph traversal like this:

class Problem
{
  find_problem_solvers()
  {
    var problem_solvers = null
    for each (skill in skills_required)
    {
      var possible_problem_solvers = skill.find_problem_solvers()
      if(problem_solvers == null)
      {
        problem_solvers = new list().add_range(possible_problem_solvers)
      }
      else
      {
        for each problem_solver in problem_solvers:
        {
          if(problem_solver not in possible_problem_solvers)
            problem_solvers.remove(problem_solver)
        }
      }
      //No point continuing if we eliminated everyone!
      if(problem_solvers is empty) break;
     }
     return problem_solvers
   }
 }

As you can see in this regard I don't have much of a use for the other posters' patterns. If you're trying to model domain security or a different business logic of some sort. Their techniques could very well be the right ones.

By the way it should be noted that the above algo is not optimal.

回复收藏 0 原文