Существуют ли шаблоны проектирования при моделировании структуры, содержащей команды, роли и навыки?

Asked
Viewd436

3

Мне нужно смоделировать систему, в которой будет группа, состоящая из пользователей, которые выполняют роли в команде и имеют назначенные им навыки.

т.е. команда A 5 человек, один выполняет роль руководителя группы, все выполняют ответ на электронная почта, но у некоторых есть дополнительные навыки, чтобы отвечать на телефонные звонки

Я пытаюсь определить, как лучше всего это смоделировать.

Эту проблему, должно быть, уже решали раньше, есть ли хорошие ресурсы о том, как это смоделировать?

РЕДАКТИРОВАТЬ: мне нужно определить, что пользователю разрешено делать, что может быть связано с тем, что он находится в определенной команде, выполняет определенную роль или имеет определенный навык

7 ответов

0

Я обнаружил эту главу 5 в

0

В вашем примере у меня было бы хотя бы TeamMember BaseClass и 2 интерфейса (iEmail и iPhone). Любые новые роли будут унаследованы от класса TeamMember и, в зависимости от того, что он может делать, будут реализовывать соответствующие интерфейсы ... Короче говоря, роли будут реализованы как класс, наследующий от TeamMember, а навыки будут реализованы как интерфейс.

Например, руководителю группы разрешено звонить по телефону. Тогда у меня будет класс TeamLeader, унаследованный от TeamMember и реализующий интерфейс iPhone

RWendi

1

На самом деле я ничего не слышал, но это достаточно просто, чтобы решить его различными способами.

Итак, есть команды, участники, роли и навыки. Команды - это просто контейнеры участников, а у участников есть роли и навыки.

Вот еще небольшой псевдоним, чтобы дать вам всю идею:

 class Team
    container[Member] members

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

Затем вы создаете или подклассифицируете роли и навыки в зависимости от того, что они собой представляют, и от возможностей вашего языка программирования.

.. С другой стороны, на практике может иметь смысл сделать Team -class подобным Role и Skill -class - свойству Member -class. Если вам нужно выяснить, к чему имеет доступ один участник

  • Да, но я все равно подхожу к проблеме с этой стороны. Хм. Что ж ... если это будет изменено на то, что вы говорите, было бы полезнее немного изменить это ...

    Cheery14 октября 2008, 14:03
  • Все становится немного сложнее, когда можно назначать роли и навыки команде, а роли и навыки отдельным лицам, а затем учитывать наследование от команд.

    Также вам нужно подумать о том, чтобы иметь привилегированного пользователя, который контролирует команду, от которой вы не хотите наследовать

    Craig Angus14 октября 2008, 10:43
2

Я погуглил, так что отнеситесь к этому с недоверием. Я нашел эту статью по ролевому моделированию и объектам. На странице 30 есть шаблон ролей. Надеюсь, это не погоня за дикими гусями для вас. Вот резюме

Шаблон «Роль» позволяет вам разработать компонент, который можно расширять во время выполнения с помощью новых Объекты контекста, называемые ролями. Компонент расширяется ролями в соответствии с контекстом Образец объекта. Компонент соответствует компоненту декоратора, а роль соответствует к объекту контекста. Государственная интеграция Компонента ролевой игры достигается путем применения Недвижимость и стратегия. Свойство используется для определения пространства состояний Компонента, и Стратегия используется для обеспечения поведения, зависящего от свойства.

0

Это зависит от того, что вы моделируете. Учитывая приведенный выше пример, хотите ли вы найти члена команды, наиболее подходящего для решения данной проблемы?

В этом случае я бы порекомендовал что-то вроде этого: Представьте себе роли и навыки как вершины в неориентированном графе. Данная роль связана (через край) с каждым навыком, на который она способна (при условии, что навыки даны по ролям, а не только индивидуально). Теперь подключите всех членов команды к тем ролям, которые у них есть в команде, а членов команды - к соответствующим командам.

На этом графике теперь моделируются связи между вашими командами, членами команды, их ролями и навыками, которые они должны были дать своим ролям.

Теперь, чтобы сопоставить данную проблему с членом команды (или даже с командой), возьмите проблему и свяжите ее со всеми необходимыми навыками (например, электронная почта, база данных, веб-интерфейс, веб-службы и т. д. .). Теперь вы можете связать проблемы и с этими объектами.

Я не буду останавливаться на всех типах отчетов, которые вы могли бы использовать с этим, но вот простой. Если вы хотите найти одного человека (если он существует), который может решить эту проблему, я бы порекомендовал такой обход графа:

 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
   }
 }
 

Как вы можете видеть в этом отношении, я не особо использую образцы других плакатов. Если вы пытаетесь смоделировать безопасность домена или какую-то другую бизнес-логику. Их методы вполне могут быть правильными.

Кстати, следует отметить, что приведенный выше алгоритм не является оптимальным.

  • Ваш подход действительно уникален. Мне нравится нестандартное мышление.

    David Robbins20 октября 2008, 22:14
0

Хотя я считаю, что шаблоны проектирования - отличный инструмент, я не думаю, что я бы использовал какой-либо конкретный шаблон для этой проблемы. Скорее, я бы попытался подойти к этому под другим углом. Я предлагаю использовать базу данных, в которой будут храниться данные о ваших командах, членах команды и их ролях. Базы данных не совсем моя сильная сторона, но я попробую:
Создайте стол для всех членов вашей команды из всех команд. В таблице должны быть атрибуты: Имя, Роль, Команда, Навыки, которые представляют имя и роль участника, команду, к которой он / она принадлежит, и его / ее навыки соответственно.
Теперь предположим, что у вас есть следующие роли в вашем приложении: RoleA (для тех, кто может отвечать на телефонные звонки и отправлять электронную почту), roleB (может отправлять только электронную почту) и роль TeamLeader (может отвечать на телефонные звонки, отправлять электронную почту). и ходить на собрания, например. Таблица ролей будет содержать все роли в вашем приложении, атрибуты будут (в данном случае): name (имя роли), canAnswerPhone (логическое значение, указывающее, может ли пользователь с этой ролью отвечать на телефонные звонки), может отправлять электронные сообщения. mail (логическое значение, указывающее, может ли он / она отправлять электронную почту) и так далее ...
Третья таблица может, например, содержать все команды в вашем приложении и различные данные о них (например, проекты, над которыми команда работает и т. Д.).
Теперь вы можете легко собрать всех членов команды, узнать, что они могут делать, изменить свои роли, увидеть, кто является лидером, изменить то, что делает определенная роль, и так далее ...

Надеюсь, это имеет для вас смысл. Удачи в разработке вашего приложения!

2

Похоже, вы можете использовать здесь вариант составного шаблона, по крайней мере, для решения части проблемы. Вы можете начать с юнита, который действует как суперкласс, затем у вас может быть команда в качестве подкласса юнита. Команда - это контейнер, который может содержать другие юниты. Кроме того, у вас может быть подкласс User Unit. Таким образом, вы можете написать код, который просто нацелен на модуль и одинаково относится ко всем командам и пользователям. Затем вы сможете создавать сложные команды, состоящие из других команд.

Таким образом, вы можете предоставить класс для каждого типа пользователя или типа команды, которая вам нужна.

Если количество ролей резко возрастает и у вас получается слишком много классов (взрыв класса), вы можете применить шаблон декоратора. Таким образом, вы оборачиваете (украшаете) объект другим объектом с аналогичным интерфейсом, но с другой (или дополнительной) функциональностью.

Итак, у вас могут быть BasicUser и AnswerPhoneDecorator. Возьмите любой объект BasicUser, оберните его в AnswerPhoneDecorator, и у вас будет пользователь, который может отвечать на телефонные звонки.

  • Ура. вы понимаете, почему это большая проблема! Я думаю, что должны быть некоторые мягко настроенные ограничения для сотрудников, как это определено пользователем, поэтому потребуется некоторая динамическая конструкция сотрудника во время выполнения

    Craig Angus19 октября 2008, 21:19
  • Что ж, в конце концов приложение будет разрабатывать вы, а не я, так что в конечном итоге имеет значение ваше собственное мнение по этому поводу. Но я по-прежнему считаю, что с этим дизайном слишком много проблем и что к нему следует подходить под другим углом. Не используйте узор только ради него.

    Sandman20 октября 2008, 08:07
  • Кроме того, существуют проблемы, связанные с тем, что несколько пользователей могут играть роль лидера одной и той же команды, сотрудник, работающий только в одной команде, но при этом имея несколько ролей, и сотрудник, работающий в одной команде и имеющий одну и ту же роль, применяемую к его / ее несколько раз.

    Sandman18 октября 2008, 11:36
  • Это означает, что, например, у одного сотрудника может быть несколько ролей. Это нормально, если вы хотите, чтобы у ваших сотрудников были разные роли в разных командах, к которым они принадлежат, но тогда как вы собираетесь выяснить, какова роль сотрудника в конкретной команде?

    Sandman18 октября 2008, 11:32
  • Я думаю, что использование шаблона декоратора должно помочь решить эту проблему. Мне нужно добавить еще один класс, сотрудника, который нужно украсить, навыки, затем роль, затем команду и шаблон Composite для команд. В основном «дизайн в моей голове пока», но я изучу дизайн на следующей неделе, а потом обновлю

    Craig Angus17 октября 2008, 21:25