what is the definition of Actor?

[rezaTech]

hi
My system has loan module and deposit module. Credit users use  most of the functions of loan module and deposit user use most of functions of deposit module.
But My security system has only 2 types of users. Admin and normal user. whoever have the permission of a screen can access the screen regardless loan or deposit.
In this case for the use cases of loan module, which actor shall I put. is it credit user or normal user.
can anybody help me to get my concept clear?
cheers

[Paolo F Cantoni]

There was some recent discussion in the forum on this topic.  Have a search within the last month - it should turn up.  You can then extend that.

Interestingly, I've come to the view that "being an Actor" is an aspect (or role) of any arbitrary item in a model.  One could view "being an Actor" as a "rendering" of the item.  So just as in EA we often have a "native" form and "rectangular" form of rendering, we might include "actor" form and "partition" (separate concept) form.

My AU$0.05
Paolo

[Transition Technologies]

Hi rezaTech,

This is the definition of an actor:

Actors are the users of the system being modeled. Each Actor will have a well-defined role, and in the context of that role have useful interactions with the system.

A person may perform the role of more than one Actor, although they will only assume one role during one use case interaction.

An Actor role may be performed by a non-human system, such as another computer program.

[«Midnight»]

Just adding another 0.02 CAD...

Very true, as far as it goes. That's the OMG take on things, which of course works fine for UML as it was conceived and standardized.

Of course the idea of use cases has been around for quite some time, well before UML was even an idea. Throughout this time they (use cases) have been used across a much broader spectrum than UML was originally intended for - business scenarios and such.

The bottom line is that concepts that relate to use cases, like 'Actor' and such, have evolved both independently and outside the scope of UML. Not only that, but use cases have much less cohesion (for lack of a better term) with the rest of UML than the other UML 'parts.' [This situation has been addressed to an extent in UML 2.x, but the point still holds true.]

One (really strong) saving grace is that among the real framers of use case concepts are some of the original framers of UML. Use cases did not get bent out of shape when UML was created, so observations and improvements across many use case disciplines still hold up well.

So keep the definition to heart lest you lose your way, but Paolo's caution should be heeded regardless.

David

[sargasso]

Try something along these lines.

I think you have three actors : admins, normal users who are credit customers and normal users who are deposit customers.

The System (the big thing that includes the smaller "computer system") is what you are trying to model, not the system.  As Paolo points out, there is nothing wrong with including conceptual ideas in the model.  Occasionally this may even disclose issues that make the system hard to implement.

the ghost