Question about optimizing actors catalogue

[mhdhallak]

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!

[TrtnJohn]

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.

[Paolo F Cantoni]

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

[TrtnJohn]

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.

[Paolo F Cantoni]

[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!  

Paolo

[mhdhallak]

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

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!

[Paolo F Cantoni]

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]

[mhdhallak]

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.

[TrtnJohn]

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