Shared Library.......Actor ???

[Tara Shankar Maji]

Hi,
I have a query related to the modeling of a shared library in UML.
I don't know whether a shared library be modeled as an actor or not. I have two cases....
CASE#1: My system performs read-write operations with this shared library and so does other subsystems.
CASE#2: My system can read-write but other subsystems can only read from it.
Basically i would like to know when can i call a shared library a part of my system.
I would appreciate a quick response.
Thanks & Regards

[Frank Carver]

To my understanding it is certainly part of the system, but I doubt that it could be counted as an "actor". An "actor" is typically some entity which initiates a process or use case. I can't see a shared library ever initiating something.

[Muriel Boutefeu]

Remark for Frank:

An "actor" is typically some entity which initiates a process or use case.

This is not the definition of an Actor.
An Actor can be:

A Primary Actor. It has user goals fulfilled through using services of the System.

A Secondary Actoror Supporting Actor provides a service to the System. Often it is another computer system but it could also be a person.

Often the Primary Actor initiates the Use Case but it is not always the case.

Now to answer to Tara, my opinion is this one:
[list]1. If you have to define your shared library then it is in your system. You can model it as a UML [B]

<<subsystem >>

[/B].[/list][list]2. If your shared library has already been defined then you can consider it as external to your system and so is an actor. In UML either you drawn an actor and add the stereotype [B]

<<system>>

[/B] or you draw a box and add the stereotype [B]

<<actor>>

[/B].[/list]
What you can do also is first define your shared library. And then use it as an external actor. In this case you change the border of your system and it becomes mandatory to precise in what is your system when you write your Use Case.
If you use Cockburn template (http://members.aol.com/acockburn/papers/uctempla.htm then you have a Scope element in the CHARACTERISTIC INFORMATION of your Use Case:
Scope: <what system is being considered black-box under design>
So

1. when you first define your shared library:

Scope: shared library YourSharedLibraryName

2. And then when you use it as an Actor:

Scope: system YourSystemName

[Muriel Boutefeu]

It seems that you cannot nest UBB code.
So what is missing in my previous Reply is:
1. If you have to define your shared library then it is in your system. You can model it as a UML
<<subsystem>>
2. If your shared library has already been defined then you can consider it as external to your system and so is an actor. In UML either you drawn an actor and add the stereotype <<system>>
or you draw a box and add the stereotype <<actor>>
in the CHARACTERISTIC INFORMATION of your Use Case:
Scope: <what system is being considered black-box under design>

[Muriel Boutefeu]

Last attempt:
It seems that you cannot nest UBB code.
So what is missing in my previous Reply is:
1. If you have to define your shared library then it is in your system. You can model it as a UML
subsystem
2. If your shared library has already been defined then you can consider it as external to your system and so is an actor. In UML either you drawn an actor and add the stereotype system
or you draw a box and add the stereotype actor
in the CHARACTERISTIC INFORMATION of your Use Case:
Scope: what system is being considered black-box under design

[Frank Carver]

An Actor can be:

A Primary Actor. It has user goals fulfilled through using services of the System.

A Secondary Actor or Supporting Actor provides a service to the System. Often it is another computer system but it could also be a person.

Sorry. I didn't mean to give a strict definition of an "actor", just the typical use. An "actor" to me has always implied something external to the system under consideration, so I looked it up.
In my copy of "The Unified Modeling Language User Guide" (Booch, Rumbaugh, Jacobson), an actor is defined as: "a coherent set of roles that users of use cases play wben interacting with the use cases" (p457). This is clarified again on page 222: "An instance of an actor, therefore, represents an individual interacting with the system in a specific way. Although you'll use actors in your models, actors are not actually part of the system. They live outside the system".
In "UML Distilled, Second Edition" (Fowler), it becomes clearer: "An actor is a role that a user plays with respect to the system. ... (yes, I know it would be better to use the word 'role', but apparently there was a mistranslation from the Swedish.)". (p42)
While I'm happy to use models with non-humans playing the roles, the essence of the concept of "actor" is the role(s) it plays. It shouldn't make a lot of difference to the model if the roles associated with any given actor are played by a human, a machine, or a monkey.
If, in the original model which started this thread, the "shared library" is really independent enough to represent roles which could be played by other systems or even by people, then it might be useful to consider it an actor. Otherwise it's part of the system.

[Tara Shankar Maji]

Well, Frank as per the analogy you have put
"If, in the original model which started this thread, the "shared library" is really independent enough to represent roles which could be played by other systems or even by people, then it might be useful to consider it an actor. Otherwise it's part of the system."
Are the read/write operations (so called roles) by the other systems suffice to make the 'shared library' independent enough to be called an actor?
(If yes, then all the shared file objects in any system in this world should be modeled as an actor.)
Please clarify how do u visualize the independence of 'shard library' through its roles to call it an actor.
Thanks.

[Frank Carver]

Are the read/write operations (so called roles) by the other systems suffice to make the 'shared library' independent enough to be called an actor?
I doubt it, but the whole point of this is that it is impossible to give a general answer to such specific questions. Whethere something is usefully referred to as an "actor" is a decision which can only be made in the context of the system being described.
"Roles" are things like "customer", "product advisor", "planning office". If you can imagine different people, organizations or systems filling a role ("Hi, I'm Frank, I shall be your product advisor for today", "The power is out at the Denver planning office, so we're routing all calls to Boulder"), then it is a good candidate for an actor designation.
If there is only one shared library for this task, which must be used for the system to work, then it's almost certainly not a role or an actor, just a resource.