-
Hi everybody
This is my first post here. So I'm hoping I get some good feedback.
My questions is sort of a simple one. When you finish identifying all actors (let's assume human actors for this example), how do you go about optimizing this list of actors?
I mean, if I have two actors, who have different job titles, but perform pretty much the same functions in the system, with maybe some variation, is it feasible to consider both of them as one actor and assign it a general name? What's the "rule of thumb" in these situations?
Currently, I have about 20 actors corresponding to every role, or position, in our client company. These actors will be interacting with the system in one way or another. I feel like if I did some optimizing I can bring this list down to maybe 10 or something. That's if I elminate actors who will perform the same functions (use cases) as other ones.
Love to get your feedback.
Thanks.
AL
-
Hi everybody
This is my first post here. So I'm hoping I get some good feedback.
My questions is sort of a simple one. When you finish identifying all actors (let's assume human actors for this example), how do you go about optimizing this list of actors?
I mean, if I have two actors, who have different job titles, but perform pretty much the same functions in the system, with maybe some variation, is it feasible to consider both of them as one actor and assign it a general name? What's the "rule of thumb" in these situations?
Currently, I have about 20 actors corresponding to every role, or position, in our client company. These actors will be interacting with the system in one way or another. I feel like if I did some optimizing I can bring this list down to maybe 10 or something. That's if I eliminate actors who will perform the same functions (use cases) as other ones.
Love to get your feedback.
Thanks.
AL
HI Al,
You've fallen into the Conceptual Modelling problem of making Role and Position the same thing. Now, your ontology may vary, but over many years (20+) I've found that differentiating between the Position (a titled slot in the company hierarchy) and the Role(s) (what kinds of things the occupants(s) of that position can do) REALLY helps...
In UML, actors should be roles, that is, people (or things) that can do stuff.
Now, once you do that, you may find that a Role generalization hierarchy exist (which is likely to be different from the Position hierarchy).
You optimize the list by moving Use Cases to the most general role that can effectively undertake that Use Case.
HTH,
Paolo
-
Great! This helps alot. :)
So to sum up, discard company's positions when it comes to system actors and instead base actors identification on the their kinds of interaction with the system.
Also, generalization should be used when a use case is shared by multiple actors who have some common factors (or requirements). In this case, the use case should be associated with the super actor.
One last thing, could you gvie me a little example of breaking away from the position-based identification scheme and adapting the role-based scheme whereby you focus more on requirements rather than the actor's position in the company?
Thanks!
-
Hi Al,
Just 0.02 CAD more...
Paolo is correct Al, and you've got the high level view of what to do. But, to answer your original question more directly:
An actor may represent more than one person (those who perform that role).
A person may be represented by more than one actor (when that person performs several roles).
Thus, break down - or design - the system based on the functions it performs. Determine the roles that affect or are affected by these functions, and assign actors accordingly. To the extent necessary, map real users to these roles. Note that it may or may not be practical or helpful to perform the final step. What you really want to concentrate on are the first two. In many cases it is enough to identify and support the roles; the people will sort out what roles they play.
You are correct about determining the hierarchy. A common example is an "administrator" role. The administrator might be the only role that can add, change or delete system codes (or whatever), while the "user" role may query and select these codes (for whatever purpose). This does not imply that these two roles are filled by different people, or even performed at the same time. The administrator is a specialization of the user, and can perform all the functions thereof. Depending on the complexity and detail of the system you may or may not choose to model this relationship explicitly.
HTH a bit more,
David
-
[size=13][SNIP][/size]
One last thing, could you give me a little example of breaking away from the position-based identification scheme and adapting the role-based scheme whereby you focus more on requirements rather than the actor's position in the company?
Hi again Al,
If David's response doesn't sort it for you, can you explain exactly where you need help in differentiating between the two paradigms?
It should be pretty obvious that a given position in the company can perform many roles (and vice versa). I'd just create a spreadsheet relating the two and placing the use case in the intersecting cell. You should then be able to refactor the set of use cases by role.
HTH,
Paolo
-
Alright, now I understand the distinction between a role and a position in the company.
This calls for a complete redefinition of my actors.
But I'm still feeling little doubtful about something, and I'd really really appreciate your help (you've so helpfull so far!! thanks).
Maybe a little background would help bring you guys into picture. I'll keep it breif though. Keep in mind this is my first UML-based project that I'm entirely responsible for the analysis and architecture. So I'm careful in every step of the way.
Our client is a field marketing company. They contract with FMCG distributors in order to maintain their brands at shops. They send out merchandisers to do variety of on-field activities like shelf restocking, reporting inventory etc.
Now the plan is to develop a handheld application with a backend one. The handheld application will collect data to be used in reporting in the backend application.
So far so good.
Now I finished writing the SRS document which has all the requirements categorized and everything. I've also managed to link every position in the company with their functional requirements. And so I made the initial mistake of considering every position an actor which is clearly wrong and should be corrected.
My question is this:
Having defined the requirements (for either the handheld device application or the backend), how can I figure out the actors (as opposed to positions) from these requirements.
[glb]Hold on I just got an idea![/glb] ::)
Being UML experts, what do you think of having the following actors:
1. User = Abstract actor class. Not associated with any use case but nevertheless contains common attributes.
1.1 Mobile Worker = users of the handheld device
1.2 System Operator = users of the backend system
1.2.1 System Administrator = administrator of the backend system and whole system in general.
I think those fit well with my requirements.
And then we can have permissions and stuff in order to implement the idea of company positions. So a certain position will have so and so permisssions and so forth.
Am I on the right track here?
(sorry i took so long :-/)
-
Just to be certain...
You explicitly mention administrators being able to user the whole system in general. However, you do not mention this for operators or mobile users.
Does the user of the system in general apply throughout the hierarchy? If so, and if this is an inheritance hierarchy, then you should probably remove the (now redundant) clause at the end of the administrator definition. Administrators, would inherit this from Operators who in turn, like mobile users, inherit this from the base user role.
Finally, why would the user role be abstract? Depending on your specific application of course, there might be users who are not mobile, and have no operator (and thus no administrator) duties. Thus, the user role would not be abstract, even though there might not be any personnel assigned to that role at any given time.
-
Oops.
Does the user of the system in general apply throughout the hierarchy? If so, and if this is an inheritance hierarchy, then you should probably remove the (now redundant) clause at the end of the administrator definition. Administrators, would inherit this from Operators who in turn, like mobile users, inherit this from the base user role.
My bad. I should have just said:
1.2.1 System Administrator = administrator of the backend system and whole system in general.
Depending on your specific application of course, there might be users who are not mobile, and have no operator (and thus no administrator) duties
I can see how the term "System Operator" created confusion here.
On a second thought, I'm going to revise the heiarchy to the following:
1. User = Abstract actor class. Not associated with any use case but nevertheless contains common attributes.
1.1 Mobile Worker = users of the handheld device
1.2 System Operator = users of the backend system
1.3 System Administrator = administrator of the system
Now any possible user if the system must be an instance of any of the 3 possible actors mentioned above. The reason why User actor is an abstract actor is because any system user must be either a Mobile Worker (handheld device user), System Operator (uses the functionality of the backend application), or System Administrator (sets up the system settings, user accounts, etc).
I can't imagine any user falling outstide the range of these actors. Could you?
-
Ahhh, "the" handheld device, you say...
With that clarification it looks just fine.
Depending on just how the system comes together, the administrator role might still be a specialization of operator. This would depend, of course, on just how the system is conceptualized and realized. The beauty of UML is that it can gracefully handle either case.
David
-
I agree.
Well thanks David, Paolo. This was very helpful.
This forum looks awesome, just as EA and UML is. I think imma stick around. Who knows, I might be able to answer a question someday 8)
Good day.
AL
-
I am not completely sold on this approach. Classifying actors seems a bit like an exercise in over-modeling a problem. What value does this provide to the use cases itself? How does this translate to the real world? To me a use case is a single service provided to an actor of the system. Once you start generalizing either you start to lose focus on the real goal of clearly defining the use. Define all your actors clearly as individuals with specific roles. The rest only adds confusion to less technically oriented readers.
-
That would likely depend on the local (corporate or whatever) standards for how you do things.
As an example of why this might be done, such hierarchies might translate directly into security and authorization hierarchies in a system.
-
Classifying actors seems a bit like an exercise in over-modeling a problem.
Sometimes it sure is - sometimes it helps. At the moment I have an actor heirarchy that relects the fact that there are definite subsets of use cases available to each type. Last project it was necessary to treat each actor type as a unique entity. Same system - same business product - different user interfaces (call centre v public internet).
It is probably a mistake to try to (sub)classify them formally at the outset. Let 'em fall into a structure naturally when and only when it helps resolve the mapping problems and simplify the model.
Things to look for are:
a) "hang on I just modelled the last n use cases for another actor a minute ago". Try and see if a generalistaion works here and makes sense.
b) "hmm, if I restructured this use case a bit it looks like it might become a common set of "code" that I could use across those 3 actors.
hey AL
Who knows, I might be able to answer a question someday
how about going to the wiki and adding something to the use case modelling section from what youve learned here.
bruce
-
It is probably a mistake to try to (sub)classify them formally at the outset. Let 'em fall into a structure naturally when and only when it helps resolve the mapping problems and simplify the model.
Agreed. YAGNI (http://www.c2.com/cgi/wiki?YouArentGonnaNeedIt) is a good guiding principle here.
hey AL
how about going to the wiki and adding something to the use case modelling section from what youve learned here.
bruce
Go here (http://wiki.eausergroup.org/index.php?title=Actor) and click on [edit] :)
-
Agreed. YAGNI (http://www.c2.com/cgi/wiki?YouArentGonnaNeedIt) is a good guiding principle here.
I believe it depends on which model you are talking about. Agile says "model only what you need". Which is valid, but begs the question - what does need mean? In my experience, the best approach I've found is to define your domain of discourse - that is that part of the real world your system needs to interact with and then go out one more relationship. That way, if you do need to come back and extend the model in any direction, it's already contextually valid.
Now, from an implementation point of view, you should implement only what you need for that iteration - but you should implement it in as high a level of genericy (or genericity - what a clumsy word - as Bertrand Meyer calls it) as you can. That way you maximise the flexibility without endangering the requirements. Obviously, functionality formally planned for a near future release will more strongly influence the design than more hazy possibilities.
Now, in the current context - of creating generalization hierarchies of actors. In my view, if the hierarchy exists, then use it, implement it. Refactor all interactions to the highest level of genericy possible. If you have to change the hierarchy later, then it's a great indicator of what needs to be changed in the code.
Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]
-
Now, in the current context - of creating generalization hierarchies of actors. In my view, if the hierarchy exists, then use it, implement it. Refactor all interactions to the highest level of genericy possible. If you have to change the hierarchy later, then it's a great indicator of what needs to be changed in the code.
Right on!
-
I believe it depends on which model you are talking about. Agile says "model only what you need". Which is valid, but begs the question - what does need mean? In my experience, the best approach I've found is to define your domain of discourse - that is that part of the real world your system needs to interact with and then go out one more relationship. That way, if you do need to come back and extend the model in any direction, it's already contextually valid.
Now, from an implementation point of view, you should implement only what you need for that iteration - but you should implement it in as high a level of genericy (or genericity - what a clumsy word - as Bertrand Meyer calls it) as you can. That way you maximise the flexibility without endangering the requirements. Obviously, functionality formally planned for a near future release will more strongly influence the design than more hazy possibilities.
Now, in the current context - of creating generalization hierarchies of actors. In my view, if the hierarchy exists, then use it, implement it. Refactor all interactions to the highest level of genericy possible. If you have to change the hierarchy later, then it's a great indicator of what needs to be changed in the code.
Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]
As always there is no 1 right way to do anything. My point was when modeling your actors you only need to be as detailed as your use cases require. Creating actors like Administrative User is only useful if the actor can directly participate in a use case in some meaningful way. Almost every actor in every use case invented could be generalized as Adminstrator, User, Operator, and so on. But doing so would possibly take away important details. I completely understand that there are plenty of instances where having some sort of actor heirarchy is a critical element to the use case. But, in the case of this thread, (Titled: Question about optimizing actors catalogue), I am not sure that generalizing is a good solution.
-
As always there is no 1 right way to do anything. My point was when modeling your actors you only need to be as detailed as your use cases require. Creating actors like Administrative User is only useful if the actor can directly participate in a use case in some meaningful way. Almost every actor in every use case invented could be generalized as Adminstrator, User, Operator, and so on. But doing so would possibly take away important details. I completely understand that there are plenty of instances where having some sort of actor heirarchy is a critical element to the use case. But, in the case of this thread, (Titled: Question about optimizing actors catalogue), I am not sure that generalizing is a good solution.
Actually, I think we may be in violent agreement.
You mustn't generalize if you loose important details - what the ancients used to call Differentiae.
My point is that you should use the right level of Actor for the Use Case.
If (and it needs to be veriffied) you can, without loss of generality (or in this case applicablity), replace a specific Actor with its ancestor in the Actor generalisation hierarchy, then one should.
You are thus validating that you haven't lost any important detail.
Paolo
-
Actually, I think we may be in violent agreement.
You mustn't generalize if you loose important details - what the ancients used to call Differentiae.
My point is that you should use the right level of Actor for the Use Case.
If (and it needs to be veriffied) you can, without loss of generality (or in this case applicablity), replace a specific Actor with its ancestor in the Actor generalisation hierarchy, then one should.
You are thus validating that you haven't lost any important detail.
Paolo
Actually we seen to be in a more non-violent agreement than you think. Perhaps I am wording things wrong. I was trying to say the same thing you just said. I completely agree that a heirarchy can give more details when applicable. I am just not sure that every generalization is applicable to the problem at hand. The point of this thread seemed to be to lessen then number of actors defined in the system and use more generalized actors instead. That's why I got a little concerned.
Generalizations always add more details I agree. But if you start to become too generalized in your use cases you could lose details. For example you could define the following heirarchy for a bank teller:
Teller <- Teller System User
To me this doesn't make any sense and just creates a Teller System User actor that is too general. To me this example represents what I saw in this thread. Another example would be:
Teller <- Branch personal <- Full time employee <- Bank Employee
In this example I agree it gives more details.
-
[size=13][SNIP][/size]
Teller <- Teller System User
To me this doesn't make any sense and just creates a Teller System User actor that is too general. To me this example represents what I saw in this thread. Another example would be:
Teller <- Branch personal <- Full time employee <- Bank Employee
In this example I agree it gives more details.
I agree that the first example is a bit specious.
The second example smells wrong to me. I'm not sure all the items are roles.
We have to be really careful that we are actually moving up an inheritance hierarchy. that all the items do indeed belong to the same Genera (in ancient speak).
I'm not sure full time employee is a role. It's a specialization of Employee which (in my view) is a tuple between Person and Business Entity.
So, although we now agree in principle, we may be differing in practice! :D
Paolo
-
Hi
I've been following the discussion between Paolo and TrtnJohn and I kind of see where the principle lies, and just to be sure, I'm going to explain what I conclude to be the best practice for defining actors heirarchy:
The following diagram illustrates the latest heirarchy that I envisioned for my actors (which, afterall, may not be as optimal as I think):
(http://www.geocities.com/mhdhallak/actors.GIF)
The diagram completely illustrates the types of users who'll be intereacting with my system. In order to eliminiate any confusion of the naming, here's a breif explanation of each:
- Mobile Worker: Users of the handheld device
- Backend Worker: Users of the backend, server-side, web application.
- Client: Non-human actor. This "software" actor connects to our database through a web service in order to retreive data specific to a client of the field marketing company.
- System Administrator: A type of backend worker who has elevated privileges to modify system-wide settings
Now based on the discussion in this thread, I conclude that if any of the actors who descent from the User actor do not define any additional attributes (i.e., details) besides the ones defined in the User actor, then they are practically redundant.
But if I were to remove the redundant actors, then the use case diagrams, to say the least, will be kind of confusing as one won't know if the type of functionality being modelled is intended to be delivered on the handheld device or the backend application or the client data API.
Can you please shed some light on this specific example of mine.
Thanks!
-
Just a few general comments. If you intend the Client Actor to be the software that is the proxy for the end client, I'd call them End Client Proxy.
You need to determine what things each actor can do. Then, basically, you go through this "Pattern".
Start at the lowest Actor (in this case System Administrator) Ask: Can this interaction that I do, be done by my parent also?
If so, move it up to my parent.
If The node has children, ask: Can this interaction that I do be done by all my children? If not, move it down to those children that can do it.
Straight forward Generalization - Specialization, but this time with UseCase Associations.
If at the end of the recursive process, an actor ends up with nothing to do, you've eliminated them!
HTH,
Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]
-
I see.
Then what I'm gonna do now is define and fully-describe all my use cases, associate them with their appropriate actor(s), then run this pattern you've suggested to identify actors candidate for elmination.
-
Just a few general comments. If you intend the Client Actor to be the software that is the proxy for the end client, I'd call them End Client Proxy.
You need to determine what things each actor can do. Then, basically, you go through this "Pattern".
Start at the lowest Actor (in this case System Administrator) Ask: Can this interaction that I do, be done by my parent also?
If so, move it up to my parent.
If The node has children, ask: Can this interaction that I do be done by all my children? If not, move it down to those children that can do it.
Straight forward Generalization - Specialization, but this time with UseCase Associations.
If at the end of the recursive process, an actor ends up with nothing to do, you've eliminated them!
HTH,
Paolo
[size=0]©2006 Paolo Cantoni, -Semantica-[/size]
Using this pattern will make me happy :)