Question about optimizing actors catalogue

[mhdhallak]

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

[Paolo F Cantoni]

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

[mhdhallak]

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!

[«Midnight»]

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

[Paolo F Cantoni]

[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

[mhdhallak]

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  :-/)

[«Midnight»]

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.

[mhdhallak]

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?

[«Midnight»]

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

[mhdhallak]

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  

Good day.

AL

[TrtnJohn]

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.

[«Midnight»]

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.

[sargasso]

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

[KP]

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 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 and click on [edit]

[Paolo F Cantoni]

Agreed. YAGNI 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]