• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Use cases and system actors

 
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Panagiotis Varlagas
Ranch Hand
Posts: 233
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 233
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


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).]
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Desai Sandeep
Ranch Hand
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 1157
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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).]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic