*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Use cases and system actors Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Use cases and system actors" Watch "Use cases and system actors" New topic
Author

Use cases and system actors

Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
Says Fowler in "UML Distilled" (p. 43):
"... you should always question use cases with system actors, find out what the real user goals are, and consider alternative ways of meeting those goals."
Why is it so? What is the problem with system actors? Why should alternatives be considered?
Thanks,
Panagiotis.
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Panagiotis,
I would relate this with the POST design which Larman explains in his book.
If the Customer makes a payment, he can do it using 3 different ways - Cash Payment, Credit Payment and Check payment.
So the the Customer (although it would be be Cashier who enters information on behalf of the Customer), would be the System actor.His real user goal is to make Payment by cash.But he may consider alternative ways of meeting those goals (i.e. making Payment), by Check or Credit-Card.These alternatives must be reflected in an use case.
Hope this helps,
Sandeep

<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
Let me clarify:
Fowler has two notions: that of a "human actor" (Trading Manager, Trader, Salesperson) and that of a "system actor" (Accounting System). So, "system actor" in Fowler's lingo are _other_ systems that perform/initiate use cases on our system of interest. It is the use cases with such actors (e.g. Accounting System) that Fowler is wary about. I just don't see why and I wonder if anybody in this forum does.
Panagiotis.
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Panagiotis,
Actors could be any external thing which interacts with the system you are going to build.Larman confirms, what you have said (and also what Martin Fowler writes).
Here is an excerpt from Larman's book :

Actors are usually the roles that humans play,but may be any kind of system,such as an external computerized banking system.Kind of actions include

  • roles that people play
  • computer systems
  • electrical or mechanical devices


Hope this helps,
Sandeep
Panagiotis Varlagas
Ranch Hand

Joined: Nov 27, 2000
Posts: 233
Desai,
You are correct.
So, "human actors" are "the roles that humans play", and "system actors" are any kind of system (computer systems, electrical or mechanical devices).
But what is with what Fowler says, i.e. that "... you should always question use cases with system actors, find out what the real user goals are, and consider alternative ways of meeting those goals." I don't understand the rationale here.
Panagiotis.
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157

Orginally posted by Panagiotis Varlagas:
So, "human actors" are "the roles that humans play", and "system actors" are any kind of system (computer systems, electrical or mechanical devices).

I think you can consider everything as a "System actor", or rather as an "actor" - since it implies any external thing (or human being) interacting with the system you build.
"System Actor" only emphasis the fact that you are one of the actors interacting with the system."Human actors" could be one of types of "System Actors"
Hope this helps,
Sandeep
[This message has been edited by Desai Sandeep (edited May 19, 2001).]
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4447
    
    5

The text quoted from "UML Distilled" does make a distinction between "system actor" and "human actor".
My take on it is that use cases with system (non-human) actors may be an indication that the use case is wrong or incomplete. It could be an indication that the real requirements have not been correctly identified.
It could also mean that the system boundary has not been properly demarcated and the system actor actually fulfills a goal of a real human actor. By taking a closer look at a system actor, you can decide whether or not you need to do further modeling of the system actor. In the example given in the book, the system actor "Accounting System" was deemed to be outside of the system boundary, so further modeling was not needed.
In the case of an analysis use case, a system actor may indicate that some design/implementation details have been improperly incorporated and that there may be other ways of meeting the real goals.
Call it a "hint of a bad analysis smell" if you will, that should be examined more closely just to make sure that no errors or omissions were made.
My $0.02
Junilu

[This message has been edited by JUNILU LACAR (edited May 19, 2001).]


Junilu - [How to Ask Questions] [How to Answer Questions]
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Junilu,
I can't figure out the difference between a "System actor" and a "Human actor".In either case, you have to identify the most crucial use cases.
Probably, since "human roles" are easier to play, the risks of incomplete or wrong use cases are considerably lesser than in case of "System roles".However, using CRC cards, playing "System actor" as a "Human actor", could be minimize the risk of incomplete or wrong use cases.
Thanks,
Sandeep
Desai Sandeep
Ranch Hand

Joined: Apr 02, 2001
Posts: 1157
Junilu and Panagiotis,
I think I got this wrong.If you read that section further, Martin suggests the following :

[..] Think about all the events from the outside world to which you want to react.A given event may cause a system reaction that does not involve users[..]

Also, in the same Chapter he defines System use cases as an interaction with the software.
I believe,Martin is emphasizing on identifying those hidden use cases, which does not surface out by looking at actors interacting with the system.He wants us to investigate further and find out value-added actors in the context of a larger system.
For example, in a Credit Card system, an actor (Customer) may interact with the system to make Payments.So "Making Payments" could be one use case.But to break this huge credit card system further, you may have to find out a "hidden need" - say, decision to allot a Credit card to the Customer.So we may have a System Actor (Credit Decision Management) which will interact with a use case, say "Make a Decision".Identification of such a use case would reveal a need to model one more sub-system within the context of a larger system - An example of breaking a large component into smaller components.
Would like to know your views on this.
Thanks in advance,
Sandeep
[This message has been edited by Desai Sandeep (edited May 23, 2001).]
 
Don't get me started about those stupid light bulbs.
 
subject: Use cases and system actors
 
Similar Threads
OOAD : Do I need an interface?
innovation games: can it relate to writing use cases?
Use Case Diagrams
Functional Specification and analysis
If u r interested to help me in designing a system using UML then please participate