• 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
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • paul wheaton
Sheriffs:
  • Ron McLeod
  • Devaka Cooray
  • Henry Wong
Saloon Keepers:
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Tim Moores
  • Mikalai Zaikin
Bartenders:
  • Frits Walraven

actor in system interactions

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

Somebody can help here ?
 
Bartender
Posts: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Bartender
Posts: 1205
22
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 4568
9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
The glass is neither half full or half empty. It is too big. But this tiny ad is just right:
Gift giving made easy with the permaculture playing cards
https://coderanch.com/t/777758/Gift-giving-easy-permaculture-playing
reply
    Bookmark Topic Watch Topic
  • New Topic