This week's book giveaway is in the Clojure forum.
We're giving away four copies of Clojure in Action and have Amit Rathore and Francis Avila on-line!
See this thread for details.
Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

actor in system interactions

 
Vikrama Sanjeeva
Ranch Hand
Posts: 756
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Vikrama Sanjeeva
Ranch Hand
Posts: 756
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Somebody can help here ?
 
Matthew Brown
Bartender
Posts: 4549
8
Java Netbeans IDE Scala
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1048
4
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4549
8
Java Netbeans IDE Scala
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 756
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic