views:

298

answers:

7

I need to model a system where by there will be a team who will consist of users who perform roles in the team and have skills assigned to them.

i.e. a team A 5 members, one performs the team leader role, all perform the reply to email role, but some have an extra skill to answer the phone

I'm trying to determine how I can best model this.

This problem must have been solved before, are there any good resources on how to model this?

EDIT: I need to determine what a user is allowed to do, which could be because they are in a certain team, perform a certain role or have been assigned a certain skill

+1  A: 

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.

Cheery
It gets a bit more complicated when can assign roles and skills to team and roles and skills to individuals and then take into account inheritance from teams. Also you need to think about having a privileged user who controls a team where by you don't want to inherit from then
Craig Angus
Yes, but I'd go to approach the problem from this direction anyway. Hm. Well.. if It'd be modified to what you say, it'd be more useful to change it a bit...
Cheery
+2  A: 

I Googled this, so take it with a grain of salt. I found this paper on Role Modeling and Objects. On page 30 there is a Role Pattern. Hopefully this is not a wild goose chase for you. Here is the summary

The Role pattern lets you design a Component which can be extend at runtime with new Context objects, called Roles. A Component is extended with Roles according to the Context Object pattern. The Component corresponds to a Decorator’s Component, and a Role corresponds to a Context Object. State integration of a role-playing Component is achieved by applying Property and Strategy. Property is used to define the Component’s state space, and Strategy is used to provide the Property dependent behavior.

David Robbins
+1  A: 

It sounds like you may use a variation of the composite pattern here, at least for part of the problem. You can start with the Unit which acts as a superclass, then you can have a Team as a subclass of Unit. Team is a container that may contain other units. In addition you can have User subclass Unit. Thus you can write code that simply targets the Unit and treat all Teams and Users the same way. You may then be able to create some complex teams that are composed of other teams.

So you can then provide a class for each type of User or type of Team that you need.

If the number of roles grow dramatically and you end up with too many classes (class explosion) you can then apply the Decorator pattern. Thus you wrap (decorate) an object with another object with a similar interface but different (or additional) functionality.

So You can have a BasicUser and the AnswerPhoneDecorator. Take any BasicUser object wrap it in AnswerPhoneDecorator and you have a user that can answer the telephone.

Vincent Ramdhanie
I think the use of the decorator pattern should be able to solve this. I'll need to add a another class, employee, to be decorated with, skills, then role, then team and the Composite pattern for teams. Mostly "in my head design so far" but I will looking into the design s next week, Ill update then
Craig Angus
This means that, for example, one employee can have several roles. That's ok if you want your employees to have different roles in different teams to which they belong, but then how are you going to figure out what the employee's role is in a specific team?
Sandman
And, there are also the problems of several users possibly having the team leader role for the same team, employee working in just one team and yet having several roles and of an employee working in one team and having the same role applied to him/her multiple times.
Sandman
Yip. you can see why this is a big problem! I think there would need to be some soft configured constraints around the employees, as defined by a user, so there would need to be some dynamic construction of the the employee at runtime
Craig Angus
Well, in the end you'll be the one designing the app, not me, so ultimately it's your own opinion on the matter that counts. But i still think that there are too many problems with this design and that you ought to approach it from a different angle. Don't use a pattern just for the sake of it.
Sandman
A: 

In your example I would have at least TeamMember BaseClass and 2 interfaces (iEmail and iPhone). Any new Roles will inherit from the TeamMember class, and depending on what it can do, implements the appropriate interfaces... In short, roles would be implemented as a class that inherits from TeamMember, and skills would be implemented as an interface.

For example, Team leader is allowed to make a phone call. Then I would have TeamLeader class inherits from TeamMember and implements the iPhone interface

RWendi

RWendi
A: 

Although I believe that design-patterns are a great tool, I don't think I'd use any specific pattern for this problem. Rather, I'd try to approach it from a different angle. What I propose is using a database which will store data about your teams, team-members and their roles. Now, databases aren't exactly my stronger side, but I'll give it a shot:
Create a table to hold all your team members, from all the teams. The table should have attributes: Name, Role, Team, Skills that represent the name and role of a member,a team to which he/she belongs, and his/her skills respectively.
Now, let's say you have the following roles in your app: RoleA (for those that can answer the phone and send e-mail), roleB(can only send e-mail) and role TeamLeader(can answer phone, send e-mail and go to meetings, for example. The roles table will hold all the roles in your app, the attributes would be (in this case): name (name of the role), canAnswerPhone (boolean saying whether a user with this role can answer the phone), can send e-mail(boolean saying whether he/she can send e-mail) and so on...
The third table can, for example, hold all the teams in your app, and various data about them (like, the projects the team is working on etc....).
Now, you can easily get all the members in a team, what they can do, change their roles, see who the leader is,change what a certain role does and so on...

I hope this makes sense for you. Best of luck designing your app!

Sandman
A: 

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.

Justin Bozonier
Your approach is really unique. I like the out-of-the-box thinking.
David Robbins
A: 

I found that chapter 5 in Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML discusses how to model the relationships pretty well

Craig Angus