This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes actor in system interactions 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 "actor in system interactions" Watch "actor in system interactions" New topic
Author

actor in system interactions

Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,

In my case; my system (A) is publishing a web service which another system (B) invokes to make payment. There is a series of interactions between A and B where A fullfill demands/needs of B by providing required services.

My question here: Whether system B can be shown as ACTOR in Use Case ?

Bye
Viki


Count the flowers of your garden, NOT the leafs which falls away!
Prepare IBM Exam 340 by joining http://groups.yahoo.com/group/IBM340Exam/
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756

Somebody can help here ?
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4344
    
    8

I'd say: sure, no problem. Actors can be anything external to your system that initiates an interaction. If you're trying to model system A, that sounds like what you're describing.
Ryan McGuire
Ranch Hand

Joined: Feb 18, 2005
Posts: 1006
    
    3
Matthew Brown wrote:I'd say: sure, no problem. Actors can be anything external to your system that initiates an interaction. If you're trying to model system A, that sounds like what you're describing.


I agree and I've done exactly that in the past. However, I'd also point out that you might want document some use cases of the complete system (yours plus the other system). That way you can verify that the combined system really will be satisfying some end-user requirements. This practice is more useful when you're developing the "other" system or at least have the ability to influence the design of it. The practice of developing use cases for the combined system is relatively less useful when the other system is already set in stone.
Matthew Brown
Bartender

Joined: Apr 06, 2010
Posts: 4344
    
    8

Ryan McGuire wrote:However, I'd also point out that you might want document some use cases of the complete system (yours plus the other system).

Very true - I almost mentioned that, then decided to keep things simple. Be clear about the scope of the system you're analyising (System A, System B, System A + B), and your actors should be external to that.
Vikrama Sanjeeva
Ranch Hand

Joined: Sep 02, 2001
Posts: 756
Hi,

In my case; System B is completely a separate System. Actually, we own System A which provides payment services by publishing required Web Services. Whereas other systems (B1,B2,Bn) integrates with System A in order to make payments.

After above replies, I am concluding that System B can be shown as (Primary) Actor as it will be the one who will be initiating interaction (s) with System A.

Bye
Viki
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: actor in system interactions
 
Similar Threads
Use Cases
IBM486 Mock test questions
Shared Library.......Actor ???
IBM 486 - Use Case
Use case and sequence diagram