This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Also notice that the bubbles in use case *diagrams* are just placeholders for the *actual* use cases, which are textual.
Depending on the reason for modeling use cases, getting the different types of actors right probably isn't particularly important.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Showing different types of actors is sometimes helpful when communicating with business folks, but they don't always affect the software much. If you know you have to have a mechanism for things some users can do and others cannot, it will probably handle 2 types of actors or 200 the same. Non-human actors are interesting to me because they imply some kind of protocol and API with other systems.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Dec 12, 2003
The line between an actor and a use case implies an interface of some sort. When the actor is a human, it's a user interface. When the actor is a system, it's a system interface.